|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
SSH and X11 forwarding
Rob Quinn (rquinn
POBOX.COM)
Fri, 8 Oct 1999 15:45:54 -0400
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Ron DuFresne: "Re: Window manager - implementation bug/feature ???"
- Previous message: Brock Tellier: "fbsd 3.3 ospf_monitor research"
> [from another thread] Unless you use SSH (YOU SHOULD BE USING IT!!), which
> defaults to let remote root to login. Anyhow.. This does bring one more
> question.. Why are you running X as root anyway?
About two years ago there was a bugtraq thread (started by Ulrich Flegel)
about the evils of ssh automatically passing X11 traffic back. Effectively this
makes the connections default to "two way trust". Nothing seems to have changed
since then, the documentation (at least on the commercial version I just
bought) doesn't suggest that this is bad thing, or attempt any education. How
many people are using ssh from a "secure hub" to manage external "insecure"
boxes, without realizing they are opening a two way channel?
So, are there any good X11 exploits? All of the ones I've seen are oriented
around passive monitoring of the display and keyboard. The stuff I've whipped
up by hand is just that - by hand, and incredibly slow. I can imagine something
small and quick that sits in a .cshrc, waiting for an inbound SSH session so
that it can spread worm-like back into a network. Anyone feel like working on
this, or does it already exist?
The core of my manual exploit is to set '*allowSendEvents: true' and then,
after waiting a long time, use "xse" to issue shell commands to an xterm. A few
xkill's in the right place can convince the victim to open up a new terminal
with SendEvents enabled. I picked xterm because it's so versatile, and it's
easy to debug text sessions. Other apps like emacs don't require the xrdb step,
so there would be no waiting.
Because the X server can be working with many machines at once, you can
compromise several remote sites without ever compromising the "middle man" site
that's running the ssh client. While practicing on a co-worker I didn't realize
the xterm I was hitting contained a root shell for his home box. Not knowing
the location of his home box made it hard to take advantage of this after the
fact.
Side comments:
Xse seems to be very powerful, the man page says it can send mouse and button
events too. Scripting the input files is difficult.
I think it's kind of odd that xterm has an option to disallow SendEvents, but
includes a way to disable that remotely. All of the xterm derivatives I checked
inherited this same feature.
How can you turn the screen blanker off once it's blanked the screen? Or
better, are there any screen dumpers that can show a real window, not just the
part that's mapped?
-- | Rob Quinn | | rquinnpobox.com |
- Next message: Ron DuFresne: "Re: Window manager - implementation bug/feature ???"
- Previous message: Brock Tellier: "fbsd 3.3 ospf_monitor research"
This archive was generated by hypermail 2.0b3 on Sat Oct 09 1999 - 00:27:07 CDT