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

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.

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.

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

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.

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.