Tools to sniff/interpret XDMCP?

This is a discussion on Tools to sniff/interpret XDMCP? within the Linux Security forums, part of the System Security and Security Related category; To provide some brief background [ http://www.tldp.org/HOWTO/XDMCP-HOWTO/ ] XDMCP (X Display Manager Control Protocol) allows X ...


Go Back   Usenet Forums > System Security and Security Related > Linux Security

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 09-18-2004
Jem Berkes
 
Posts: n/a
Default Tools to sniff/interpret XDMCP?

To provide some brief background [ http://www.tldp.org/HOWTO/XDMCP-HOWTO/ ]
XDMCP (X Display Manager Control Protocol) allows X hosts to run remote
sessions, sending key/mouse and graphic events using IP. Kind of like VNC.

One doesn't use XDMCP over the Internet because it is inherently insecure.
It's suited for LANs, and we're using it in a student lab environment. I am
trying to gauge the possibility that a malicious host on our LAN might spy
on XDMCP data and interpret the contents (i.e. more than tcpdump).

Searching google didn't bring up anything. Does anybody know if spying on
sessions over XDMCP is something that is feasible? The risk is already
quite low because we're talking about a LAN, but I still wonder...

--
Jem Berkes
http://www.sysdesign.ca/
Reply With Quote
  #2 (permalink)  
Old 09-19-2004
P Gentry
 
Posts: n/a
Default Re: Tools to sniff/interpret XDMCP?

Jem Berkes <jb@users.pc9.org> wrote in message news:<Xns9568AC95B39BDjbuserspc9org@130.179.16.24> ...
> To provide some brief background [ http://www.tldp.org/HOWTO/XDMCP-HOWTO/ ]
> XDMCP (X Display Manager Control Protocol) allows X hosts to run remote
> sessions, sending key/mouse and graphic events using IP. Kind of like VNC.
>
> One doesn't use XDMCP over the Internet because it is inherently insecure.
> It's suited for LANs, and we're using it in a student lab environment. I am
> trying to gauge the possibility that a malicious host on our LAN might ...


> spy on XDMCP data and interpret the contents (i.e. more than tcpdump).


Not clear what you mean here. You mean something that _re-assembles_
the app layer payload? That would depend on the app wouldn't it? If
you just mean the XDMCP Xwindows "management" messages -- why bother?
Playback? As you can see I'm easily confused ;-( BTW, while tcpdump
can be a pain to eyeball there are a number of analysis tools. And
opening a tcpdump file in ethereal even makes eyeballing quite
revealing.

> Searching google didn't bring up anything. Does anybody know if spying on
> sessions over XDMCP is something that is feasible? The risk is already
> quite low because we're talking about a LAN, but I still wonder...


As you should ...

Depending on the topology and devices used to construct your lan, you
are always _more_ (very much more) or less at risk using XDMCP.

Any "shared media" network -- ie., thinnet _or_ hubs -- gives any nic
operating in promisc mode a view of all packets on the wire. The
possibility of laptops or handhelds "plugging" into the net makes this
_very_ insecure.

Quality switches used to "micro-segment" the packet streams will help
a lot as someone would have to place the sniffer at or on the switch
itself -- difficult, but can be done.

Using SSH to forward X is usually not practical/useful for _all_
traffic but can be used to protect sensitive sessions.

Don't underestimate the value of tcpdump or ethereal to capture
packets for later viewing -- all the app data such as usernames and
passwords are in the clear. In fact, without MIT-MAGIC-COOKIES, the
initial logins are in the clear! And specialized (ie., password)
sniffers will fit on a floppy. Even with MIT-MAGIC-COOKIES all
subsequent traffic is in the clear unless the app encrypts it -- very
rare.

Then there is the server/home dir itself that can be a risk. Users
can place $HOME/.rhosts files that open up their accounts to "outside"
access. There is also the chance (likelyhood?) that users will place
and run unfriendly apps from their accounts. Remember, you are giving
all these students access to the server (via XDMCP) just as if they
were sitting in front of it. In effect, they have already "broken in"
and have an account on the lan. After that it's a question of picking
off admin passwords and/or escalating priviledges.

We won't mention NFS issues as you did not bring it up ;-)

My experience is with high school students and on the whole even the
few mischievous attempts are more "see if I can" than with any
planned, nefarious goal. This is often the result of a dare or
boredom or just curiosity. The school lab is probably the first
"real" network they have had a chance to explore "hacking" on and the
temptation to "learn" is irresistible. More so as the students get
familiar with the network layout.

But every 2 or 3 years there are those that do have bad intent, have
practiced at home, and have come to school meaning to do harm -- to
other students, teachers, admins, or grades. Password sniffing or
keystroke loggers are the usual tools. This goes with the territory
and you just have to design with secuity in mind, be vigilant,
monitor, and have a pre-established policy re: breaches that everyone
is aware of.

Using XDMCP and X terminals can be very fruitful. Unfortunately, the
means to secure it are not so widely known/used as "workstations"
replaced terminals and people lost interest/need to secure it -- they
simply weren't using it anymore. Today, especially in schools, it is
being used again and the security aspects have not been adequately
outlined -- too many people are "assured" by the knowledge that they
are not using XDMCP across the internet without realizing how insecure
it is on the lan "out of the box".

If you've not already looked at these, you should (and they barely get
you started IMO):
From: http://www.ltsp.org/
http://204.182.52.180/fom-serve/cache/18.html
http://204.182.52.180/fom-serve/cache/19.html

Anyway, the point is that you _must_ take care of security issues
before learning just how more vulnerable you _may_ be by using XDMCP.

hth,
prg
email above disabled
Reply With Quote
  #3 (permalink)  
Old 09-20-2004
Mike
 
Posts: n/a
Default Re: Tools to sniff/interpret XDMCP?

I'm far from expert when X is the question, but probably you can
investigate the following tools (i.e., Read The Fine Manual available ;-)

xscan
xlswins
xlsclients
xwatchwin
xwd / xwud

and of course xhost [+|-]

Cheers,

--
Mike
Reply With Quote
  #4 (permalink)  
Old 09-21-2004
Jem Berkes
 
Posts: n/a
Default Re: Tools to sniff/interpret XDMCP?

>> Searching google didn't bring up anything. Does anybody know if
>> spying on sessions over XDMCP is something that is feasible? The risk
>> is already quite low because we're talking about a LAN, but I still
>> wonder...

>
> As you should ...
>
> Depending on the topology and devices used to construct your lan, you
> are always _more_ (very much more) or less at risk using XDMCP.


Thanks for the replies. I should point out that this is for a university
students lab for members-only to begin with, not highschool or open access.
I'm not too worried about our members screwing around with the Linux
server, because they really could punch the code on the door and walk away
with the entire server if they wanted to.

My only concern with respect to the LAN is foreign equipment that might be
connected to ports on our switch. Then again it is a switch, so individual
lines don't see the others' traffic -- I'm going to test this out just to
make sure. If indeed other hosts' traffic is not visible in promiscuous
mode, then there probably is nothing to worry about.

--
Jem Berkes
http://www.sysdesign.ca/
Reply With Quote
  #5 (permalink)  
Old 09-21-2004
Mike
 
Posts: n/a
Default Re: Tools to sniff/interpret XDMCP?

Jem Berkes <jb@users.pc9.org> wrote in
news:Xns956AC6B6D330Cjbuserspc9org@130.179.16.24:

> My only concern with respect to the LAN is foreign equipment that
> might be connected to ports on our switch. Then again it is a switch,
> so individual lines don't see the others' traffic -- I'm going to test
> this out just to make sure. If indeed other hosts' traffic is not
> visible in promiscuous mode, then there probably is nothing to worry
> about.
>


And then someone can do some ARP poisoning and get all the traffic for a
given IP re-routed to his/her machine for capturing before issuing it to
the real destination.
Switched environments are not as safe as any guys could have imagine
centuries ago ;-)
Cheers,

--
Mike
Reply With Quote
  #6 (permalink)  
Old 09-21-2004
P Gentry
 
Posts: n/a
Default Re: Tools to sniff/interpret XDMCP?

Jem Berkes <jb@users.pc9.org> wrote in message news:<Xns956AC6B6D330Cjbuserspc9org@130.179.16.24> ...
> >> Searching google didn't bring up anything. Does anybody know if
> >> spying on sessions over XDMCP is something that is feasible? The risk
> >> is already quite low because we're talking about a LAN, but I still
> >> wonder...

> >
> > As you should ...
> >
> > Depending on the topology and devices used to construct your lan, you
> > are always _more_ (very much more) or less at risk using XDMCP.

>
> Thanks for the replies. I should point out that this is for a university
> students lab for members-only to begin with, not highschool or open access.
> I'm not too worried about our members screwing around with the Linux
> server, because they really could punch the code on the door and walk away
> with the entire server if they wanted to.


Actually installing a rootkit on the server would be _much_ more
valuable than walking away with it -- physically or via a disk image.
College students (if what I can judge from news postings and bar talk)
are more likely to "extend" the services it offers -- either p2p or
out-of-lab access for convenience. Cron jobs can usually take care of
this sort of thing and are good maintainence in any case to avoid an
"accident" that borks the server.

BTW, you don't imagine that those resourceful and knowledgable
high-schoolers don't go to college, do you? Or do they acquire halos
when they matriculate?

> My only concern with respect to the LAN is foreign equipment that might be
> connected to ports on our switch. Then again it is a switch, so individual
> lines don't see the others' traffic -- I'm going to test this out just to
> make sure. If indeed other hosts' traffic is not visible in promiscuous
> mode, then there probably is nothing to worry about.


A good switch will help a lot, but if anyone can plug into the switch
then all bets are off.

Not sure what you mean by "foreign equipment that might be connected
to ports on our switch", but it sounds like (other) people do have
access to the switch itself. Not good -- unless you can more-or-less
keep an eye on it.

Seems you pretty much trust your students and that it's not an open
lab. Probably the greatest "risk" is a boo-boo when someone well
intentioned tries to "fix" something by accessing the switch.

Placing something like dsniff on the switch or arp poisoning (which
also requires an extra hub and laptop to carry out MITM eg.,) are the
most likely serious dangers re: the network itself and neither one can
be considered "innocent" under _any_ circumstances (without your
approval, that is). But they are not pariticularly easy to carry off
without being noticed _if_ you keep an eye on things. Good logs and
reviewing them should be enough under your circumstances and is good
maintainence anyway.

But you do need to be _aware_ of the dangers that a _determined_
effort poses, assess and implement what you consider "reasonable"
safeguards under your circumstances, and keep an eye on things.
That's about all you can realy do.

regards,
prg
email above disabled

PS. it's been my experience that if you "befriend" the gurus in the
class (and there will usually be at least one that knows some corner
of Linux networking better than you do), they are less likely to get
_you_ into trouble by something _they_ do ;-)
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 11:44 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0