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

strings

[siliconshock.com]

just pipe your stuff through strings. it should help a bit

Not all terminal emulators were susceptible

[chongo]

For those who might be concerned (and in case the paper is /.-ed), the tested and found that the following terminal emulators were NOT susceptible to screen dump or window title attacks:

• xterm xf86 4.2.0 (patch 165)
• aterm 0.42
• rxvt 2.7.8
• Eterm 0.9.1
• konsole 3.1.0 rc5
• putty 0.53
• SecureCRT 3.4.6
• gnome-terminal 2.0.2 (libzvt 2.0.1) [2.2 indirectly]
• hanterm-xf 2.0

I always pre-filter my logs thru a Perl script. Besides removing verbose messages that are not useful, my filters replace such non-printable characters with a printable character. Not only does it make it easier to spot strange octets on the screen, it does not depend on the terminal emulator remaining secure.

Re:Not all terminal emulators were susceptible

[Moses Lawn]

Funny, I just did that and it worked fine (putty 0.52). Didja type it right?

The article did mention that Putty was not really susceptible to screen dump attacks, because

Although putty would place the title onto the command-line, we were not able to find a method of hiding the command, since neither the "invisible" character attribute nor the foreground color could be set. Putty has a relatively low limit to the number of characters that can be placed into the window title, so it is not possible to simply flood the screen with garbage and hope the command rolls past the current view.

This doesn't mean putty is "secure", but it's not as insecure as some others. The baddies seem to be eterm and rxvt. There's a nice description of a compromise scenario via eterm at the bottom of the article.

Re:Not all terminal emulators were susceptible

[KainX]

The baddies seem to be eterm and rxvt. There's a nice description of a compromise scenario via eterm at the bottom of the article.

Please note that the "case study" provided was contrived at best and damagingly inaccurate at worst. No official release of Eterm EVER could be used in the way they describe. Only people following CVS Eterm would ever have been open to such an attack, and those people would have updated to a fixed version almost 2 years ago.

The case study is intended to illustrate a "Worst Case Scenario" type situation, not be any sort of realistic portrayal of actual events.

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.

Uhm, no...

[loucura!]

If you had read the article, rather than just glancing through it... those were the terminal emulators he used.

Eterm was affected, Putty, Xterm, and Rxvt.

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...

Re:Tailing logs...

[sfe_software]

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'.

Actually that should be:

alias more=less

But otherwise, very helpful. I'd always been in the habit of using 'tail -f', even as root -- and personally I'll be using 'less +F' from now on.

Re: why 224 character trim?

[chongo]

My terminal emulator windows happen to use a font that, on my monitor, permits a window of width of 225 characters.

By trimming down to 224 characters, I avoid line wrap. System crackers cannot cause a very long line to wrap at just the right place to fake another entry.

Sure, I'll perhaps miss important text beyond the 225th char, but I'm willing to take that risk. Besides, the script converts tabs to a single space and removes some common fields and phrases which further cut down down on long lines. And I can always to back to the logs to look at really long lines if I want to.

And yes, maybe some terminal emulator has some long line bug somewhere. My perl script helps avoid testing it. :-)

tail -f log | cat -v

[e40]

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

Re:tail -f log | cat -v

[Alain Williams]

An easier way is to use 'less' - which filters out nasty characters. You hit 'F' and it acts like 'tail -f' with the nice bonus that you can hit '^c' if you see something and want to and go back up the file to see how it started.

It does help to reread the manuals occasionally.

Re:Fuzzy memory

[zztzed]

Wow, your memory really is fuzzy... either that or you used incredibly badly-written BBS software.

No BBS program I ever used (most of my experience is with TriBBS and RemoteAccess, but I also dabbled with Renegade and various Renegade-alikes) would parse the dynamic-content codes outside of files that would actually be displayed by the BBS. My memory's a bit fuzzy as well, so there might have been a few exceptions that I don't explicitly recall, such as allowing users with high enough access levels (e.g., sysops) to use them in messages, or allowing them in certain message bases, but under normal circumstances no one but the sysop would be allowed to use them and even then only in very limited circumstances.

Similarly, no BBS program I ever used had a "drop to DOS" sequence that could be embedded in a display file. Of course there was a menu command that would do it, but a) menus and the ANSI files displayed when users accessed them were always separate and b) the drop to DOS command would have to be explicitly defined in whatever menu for anyone to actually use it, and only insane sysops would allow a regular user access to it.

Re:Fuzzy memory

[maelstrom]

Could be, most of my experience as a Sysop was with RemoteAccess 2.02, Frontdoor 2.12, and various Renegade and WWIV boards.

And yes, it would be incredibly poor programming practice to have a code path that would allow a user to exploit this. But, consider that many boards had some kind of dynamic headers which would display on top of the regular menus or message boards.

So it could have been possible such that a user could embed a sequence in a forum message and then upon display the stupid software loads the header from disk, appends the part it has to display and then parses it for command sequences and finally displays it.

Perhaps I'm only remembering somone claiming this was possible, I never tried to exploit any BBS, I was on the other side trying to keep myself up to date so these things couldn't happen to me. Either way, it was a blast being a Sysop and its good to see I'm not the only one on Slashdot that got a start there :)

Re:Most exploits

[42forty-two42]

Here's how to do it on linux:

• Reboot the computer, somehow.
• Append 'init=/bin/sh' to the kernel command line at boot, then resume the boot. You will be dropped to a root shell.
• mount -t proc proc /proc
• mount -o remount,rw -t (root fs type) (root fs device) /
• passwd
• Enter the new password
• mount -o remount,ro -t (root fs type) (root fs device) /
• umount /proc
• exec /sbin/init
• The system will resume its boot. The root password will have been changed.

Re:BBS ANSI Bombs

[rjamestaylor]

Speaking of the BBS days, when using my Mac Classic and the terminal software of the day (the name of which I forget) whenever the string
NO CARRIER+++ was displayed beginning in position 0 (left to right) the modem connection dropped. I made the mistake of sharing this newfound knowledge with my friends who proceeded to disconnect me at every possible opportunity. Of course, today I could have them arrested under the anti-terrorism laws for their purposeful denial of service attack. Hmmm...is the law retroactive??

"write"?

[kris]

You do have "mesg n" set, do you?

If not, you are attachable by "write " as well.

And yes, this is very, very old. Many an administrators open terminals have been taken remotely using this when I was at university.

Kristian

Forget about emulators, just hack real terminals

[iamacat]

VT220s in my school lab used to have a feature that you can send them ACK character and they'll reply with a string configured in the terminal menu. I used to reprogram the string to do some UNIX commands and then put ^E in my .plan - back in the days when people used finger as a web browser. Also, you could just write a simple shell script that simulated the login sequence and leave it running without logging out. On older UNIX systems, this worked even over dialup if your shell script ignored SIGHUP.

But the later option was too risky for my taste, because the "login" process was owned by you. So instead, I wrote a doomsday shell script. It gave you a # prompt to make you believe you are running as root. It then emulated various UNIX commands. For example "jobs" showed [1] rm -rf / & and "kill" returned "Permission denied". It logged all the commands and responses to an obscure file in my home directory. Once I got our semi-knowlegable system administrator's assistant to "interact" with this script and it was quite fun reading him using kill 10 times in a row with the same arguments. She really thought the filesystem was going south.

Terrible abuse that can be inflicted on X terminals or public lab PCs with terminal emulators is left to the imagination of the reader.