Getting Hacked Through Your Terminal

hdm writes "My company recently published a paper on security issues with common terminal emulator applications. The interesting thing about these vulnerabiltiies is that many of them only require the victim to be running tail on their log files (apache, syslog, etc) for the attack to be successful. The paper (TXT) can be found here."

Comments

A simple solution

[Giant Ape Skeleton]

Given the profliferation of exploits related to race conditions, predictible file creation, etc,
we should henceforth re-tool our code to only make use of stateless protocols!
;-)

Reinventing

[Sarcazmo]

So they discovered ANSI bombs over again.

Simple! Just tell Linux not to load ANSI.SYS, problem solved!

BBS ANSI Bombs

[Leeji]

Back in the day, "Ansi Bombs" were considered an art form. With the art scene so active, you could usually embed some evil escape string in a good looking graphic and know that you were going to get people.

The problem was DOS' overly-powerful ANSI.SYS interpreter. It let you remap any key to an arbitrary set of keys, making keyboard macros pretty easy. However, it also let evildoers remap "Space" to, for example, "del *.*, enter, y, enter." Luckily, there were third party ANSI interpreters that didn't suffer this vulnerability.

One time, when I was about to reformat my HD, I even wrote an ANSI bomb to do it. Crazy stuff. There's an interesting (and of course, old) paper about it here.

PuTTy

[Dark Lord Seth]

seth@Discordia:~$ echo -e "\e]2;;echo This is to see how queer putty is\a\e[21t\e]2;xterm\aPress Enter>\e[8m;"
Press Enter>;
seth@Discordia:~$ l;echo This is to see how queer putty is

I dare to say that putty IS vulnerable. This is what happens when I run a similiar command. Sure, it still expects an enter and anyone who takes his time to read stuff on his/her screen before blatantly hitting enter will notice the command. This was done with the latest build which I just downloaded from the site.

Also known as the "ANSI standard trojan horse."

[Ungrounded Lightning]

So they discovered ANSI bombs over again.

Looks like it.

I recall the "ANSI Standard Trojan Horse" (though it was misnamed). It became quite common after ANSI standardized a cross between the VT100 and Ann Arbor Terminals escape sequences.

Simplest form was to send a "talk" mesage to a root user containing an escape sequence that programmed a hotkey with your command-to-be-run-as-root and then "hit the key" by remote control. (You could even bury it invisibly in an otherwise innocuous-looking message.)

ANCIENT stuff. What-early '70s?

Re:TXT?

[spinlocked]

In my neck of the woods TXT is practically synonymous with text messaging. No, actually it's, synonymous with the delivery of TXT msg svrl hrs aftr u snt thm...

Thread

[taviso]

The author went on to have an interesting converstaion with Micahel Jennings, author of Eterm on Bugtraq here.

CORRECTION to terminal emulators not susceptible

[chongo]

Sorry .. I made a BAD cut and paste on my original posting! SORRY!!!

The following terminal emulators were found, according to the article, to NOT be susceptible to screen dump or window title attacks:

• aterm: 0.42
• konsole: 3.1.0 rc5
• gnome-terminal: 2.0.2 (libzvt 2.0.1) [2.2 indirectly]
• SecureCRT: 3.4.6
• aterm: 0.42

Some asked about my Perl filter for tailing log files.

Sans typos, here is an example that removes certain types of messages and fields, checks the file every 60 seconds, picks up trailing on the new file when the log file gets rotated (moved away), trims to 224 characters and replaces unusual chars with ~'s (assuming you use ASCII).

/usr/bin/tail --retry --follow=name --max-unchanged-stats=60 /var/www/logs/access_log |
/usr/bin/perl -ne '
$line = $_;
chomp $line;
next if $line =~ m{... some regexp you want to ignore ...};
next if $line =~ m{... etc ...};
$line =~ s/... some field you want to ignore ...//;
$line =~ s/... some common phrase you want to ignore ...//;
$line =~ s/^(.{1,224}).*$/$1/;
$line =~ s/\t / /g;
$line =~ s/[^ -~]/~/g;
print "$line\n";'

As they say in perl, there is more than one way to do it. The above code fragment is just to give you the general idea.

Tailing logs...

[Urchlay]

The paper mentions injecting escape sequences into log files which are being tail -f'ed... and that there's nothing new about terminal exploits.

When I first heard about this (a couple of years back) I started using less +F for tailing logs. less will convert the escape character into the token ESC (in bold or inverse video), avoiding any escape-sequence exploits.. and also adds the benefits of being able to scroll back and search, which would make it worth using even if there were no such thing as a terminal exploit.

If you're going to leave it running for a long time, you might want to also look into the -b and -B options, to limit the amount of buffer space it will allocate: something like `less -b1024 -B +F /var/log/apache/common.log' would limit less to 1024K (1M) of buffer, which means old data will eventually be discarded, but keeps less from malloc'ing all your core. As always, Read The Fine Manual for details :)

I just checked: the `more' command on my Linux and Solaris boxen seems to pass escape sequences through, so you really do want `less' (or alias less=more, if you're used to typing `some_command|more'), not to mention `more' has no equivalent to `less +F' or `tail -f'.

Hope this helps someone...

tail -f log | cat -v

[e40]

will take care of the tail of a log file problem...

Re:Unstable xterm

[NewWazoo]

I'm feeling artistic, so I'll write.

This, in a nutshell, is why you'll never be a Great Hacker. I'm most likely projecting my own insecurities upon you, but I'm writing and you're not, so there.

I tend to notice little things like you noticed - that catting a binary file will crash my terminal. And then in a fit of boredom, I might even do as you've done and start trimming away sections of the file to find the offending string. I might even write a one-liner that will parse through it for me, automating what would otherwise be a tedious task. I'll eventually end up with a file that is 23 bytes long, and when catted, crashes the terminal.

But I won't ever find out why. That file will remain a curiosity in my $HOME/misc/, to be pondered at until I find that it no longer crashes whatever terminal program I'm using. It might even remain for a while, until one day I have a directory purging session and delete it, wondering "What the hell is this?".

And that, in my opinion, is what separates Great Hackers from the myriad of wannabes. I'm definitely a wannabe. I'm proficient at everything I do, but I'll never spend the (quite possibly small number of) hours actually finding out why that string crashes xterm, and maybe doing something useful with it. The rewards are definitely there, and I've tasted their sweetness in flashes of inspiration, but I just don't have it.

What is it? I don't know. I don't suspect that I ever will, in this particular field. I think that I might just have it in another field (racing cars), but I think it's likely that I'll be Just Proficient at that, too, much as I have been at most everything for my whole life. And that's a pretty depressing thought.

Great Hackers have it, I think. They must. In fact, part of me wants to disbelieve that it exists; that if I'd just push myself a little bit harder, that if I'd just concentrate a little more, that if I would simultaneously dig deeper into and maintain a broader view/mindset of whatever it is that I'm doing, that suddenly I'd become a Great Hacker. I'd know the formula of self-motivation, and from then on it'd be easy. But it just doesn't seem to work that way - I read the exploits of Great Hackers, and marvel at how they do their work, just knowing that I could never do that! Knowing that given the same set of curiosities, my interest or drive or whatever would sputter out, and at best I'd end up with something nifty, that I might be able to make use of in my next bout of Adequate Hacking.

I'm sitting here thinking that I want to type some sort of sage-like advice to you (whoever you are) about forcing yourself to go the extra mile, or don't be lazy, or to eat your Wheaties before you start hacking. Fact is, I know that I've missed the opportunity to grab it. I also know that I've no clue what I did "wrong", and wouldn't know what to do differently, even could I go back in time and change something. I wish that I could have it, but I know that I never will.

I'm still pretty young (19)... maybe I'll figure out how to grab it between here and there.

Re:Mac OSX

[Waffle Iron]

It is possible to alias different escape sequences to commands like lm and ll to make the terminal full screen, send it to the background, make it tall, etc.

The bad news: Evil black hat hackers can use remote exploits to move the OSX terminal around the screen.

The good news: With the velvet smooth animated motion, harmonizing colors, translucent effects and drop shadows, being 0wned has never looked better!

The more things change... 1979 version

[billstewart]

"Hackers At Berkeley Find Security Hole in the Unix, a computer made by DEC". From the Oakland Tribune or some other Bay Area paper in spring 1979. Not an exact quote, but they did say the Unix was a computer made by DEC.

A long long time ago, on a uucp-net far, far, away, we didn't use terminal emulators, we used real hardware terminals. Most of them didn't run ANSI (I don't remember if the ANSI terminal standards were defined yet, but they looked very much like a DEC VT-100 terminal), but that meant there were lots of types of terminals, all trying to achieve market differentiation by having cool features or small size or large screens or cool plastic cases. Lots of different cool features means lots of vulnerabilities. The hackers in question had REDISCOVERED AN OLD TECHNIQUE - they found ways to hand escape sequences to VT100 terminals that would get the terminal to send arbitrary text back to the computer, which in those good old command-line days meant they could do anything they wanted. All you needed to do was email somebody a message with carefully crafted character strings in it, or use the talk program to write them to their terminal (back when everybody left their ttys writeable so talk would work.) Some of the popular techniques were to abuse programmable function keys (send a sequence to put some string in F1, then another sequence to auto-trigger the F1 key), or automatic whoami-responders (VT100 had one of these), or put the terminal into loopback testing mode (letting you type anything you want.)

The Hewlett-Packard HP2621 and its relatives had two easy things to do, which didn't let you send arbitrary characters but still hosed the user - one did a reboot on the terminal (and thereby dropped the connection), while the other put it into test pattern mode (sending a long string of UUUUUU to the computer.) There may have also been some block-mode things that let you send arbitrary characters to the computer, but these two were the easiest and best-documented. A couple years later, when I was a newbie learning Unix programming and security at Bell Labs, and Robert Morris Senior (father of RTM the Worm Author) was a department head for computer security (before he went to NSA), we'd had a discussion about some techniques I was trying (which he cracked through personally :-), and a few days later, when I'd patched those holes, I was playing rogue in the evening, and one of his people talked the test pattern sequence at me. For a few seconds, I though Umber Hulks were suddenly going to eat my character, but then realized I'd been hacked, and it was one of RTM's people following up on what I'd patched and what I hadn't...

Terminology note on "hacker" as opposed to "cracker" or "vandal" - The folks at Berkeley really were hacking - tinkering with things to find their limits - and while they could potentially use their knowledge for evil, they instead told people about it, which reminded lots of us to check for potential security holes in our systems.