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 ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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/ |
|
|||
|
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 |
|
|||
|
>> 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/ |
|
|||
|
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 |
|
|||
|
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 ;-) |