Exploiting X-11 forwarding in SSH
Introduction
According to a presentation entitled “Towards Evil Honeypots ?! When they bite back...” (http://cansecwest.com/csw04/csw04-Oudot.pdf)
that was at Cansecwest in 2004 it is possible to hack back at attackers in some cases. For example, it is possible to capture the keystrokes and view the screen of an attacker who has SSHd into your machine, if they have x-11 port forwarding enabled.
These are the commands mentioned in the presentation:
sshd -i … & #this sshd should be jailed
sleep 15
xwd -display localhost:10 -silent -out $ipsrc.pic
xspy -display localhost:10...
A normal X-11 connection
To understand how this works, we must first understand how X Windows normally works, and how it works under SSH. The following diagrams were taken from a lecture from the
In a normal X connection, the user starts an application on the remote host with the DISPLAY environment variable set to local:0. The remote host will connect back on port
6000 on the local host. Port 6000 corresponds to local:0 in the on the remote host.
A X-11 connection using SSH with X11 forwarding
Under secure shell, it works a bit differently. The local host connects to port 22 (sshd) on the remote. SSHD on the remote host then forks a process that listens on port 600n and forwards that to the through an ssh tunnel to port 6000 on the local host. The DISPLAY environment variable would be set to remote:600N on the remote host. (It will use the first port available past 6000.
Magic Cookies
Magic Cookies are designed to prevent other users from being able to run X-11 applications on your machine. The way it works is that there is a secret number called the Magic Cookie. It is stored in the .Xauthority file. Whenever an x-client application wants to talk to the X-server, it must provide this value or it will not be allowed to do so.
According to http://csociety.org/~sigos/projects/ssh/forwarding/, when using X-11 port forwarding under SSH, it will automatically place a Magic Cookie into your .Xauthority. file. This is different than the magic cookie that you have on local. Instead, this magic cookie is specifically for the fake X-11 server that SSHD runs on remote.
The following is an example from http://www.acm.uiuc.edu/workshops/cool_unix/xauth.html shows how to use the xauth command:
dwalin[17]:xauth list dwalin.acm.uiuc.edu:0 MIT-MAGIC-COOKIE-1 3bbdd486c11d2ddfbb7111ab088e69c6dwalin.acm.uiuc.edu/unix:0 MIT-MAGIC-COOKIE-1 3bbdd486c11d2ddfbb7111ab088e69c6 In this case, the first cookie is used for inet sockets, and the second for UNIX sockets. You can say
xauth add dwalin.acm.uiuc.edu:0 MIT-MAGIC-COOKIE-1 3bbdd486c11d2ddfbb7111ab088e69c6
This will add the magic cookie to your .Xauthority file.
So, in theory, if a hacker has brute forced the “hacker” account on our local machine. Then the following commands ought to allow us to run X-applications on their display:
xauth –f ~hacker/.Xauthority extract ~/auth remote:11.0
xauth merge ~/auth
This was abstracted from http://www-acs.ucsd.edu/home-pages/bparent/ssh-x11.ps . Actually, the scenario is slightly different, but this should work.
The “11.0” part will depend on their display number. If the hacker logs in just after you do, then their display number will be one more than yours.
Once you have stolen their magic cookie, you should be able to connect to their X-Server and watch what they are doing.
A few useful programs:
Xkey (http://www.deter.com/unix/software/xkey.c) is a remote X-windows keyboard logger.
Xspy (http://www.deter.com/unix/software/xspy-1.0c.tgz) tricks X-windows into giving up passwords from the xdm login window or xterm secure-mode.
XWatchWin (http://www.deter.com/unix/software/xwatchwin.tgz) will connect via a network socket and display the window on your X server.
| Permalink | E-mail this post 
