inei@cs.glasgow.ac.uk (Nick Nei) (05/14/91)
What I dread has finally happened - our students have discovered
Cayman's Watch program and with glee watched user's login passwords
fly by on their screens while running Watch.
Does anyone have any suggestions?
Mail: Nick Nei, Computing Science Dept.,
Glasgow Univ., 17 Lilybank Gardens,
Glasgow G12 8QQ, UK. Tel: (041) 339 8855 x 5457
ARPA: inei%uk.ac.glasgow.dcs@nsfnet-relay.ac.uk USENET: inei@cs.glasgow.uucpmakmur@paul.rutgers.edu (Hanz Makmur) (05/15/91)
In article <23491.9105141352@crete.dcs.glasgow.ac.uk> inei@cs.glasgow.ac.uk (Nick Nei) writes: > What I dread has finally happened - our students have discovered > Cayman's Watch program and with glee watched user's login passwords > fly by on their screens while running Watch. > > Does anyone have any suggestions? Yes it is a problem . This is the biggest problem with tools like this. I am afraid this is a clasical problem that can only be solved with two way encryption. The user must know what to do and have to really inspect each packets to see the password. Cayman Watch program is very dangerous on the the ethernet side and not that dangerous on the localtalk side unless some one is using NCSA Telnet to login to other machines. On the ethernet side, it is very dangerous since it can see all the packets that fly by the cable it is connected to. Suggestions ?? - May be remove Watch from public access mac. - Pray that no one know how to use it. - Tough policy. May be add this line: "Death Sentence" if got caught using unauthorize account. Hanz Makmur Rutgers University
gjb@cs.brown.edu (Gregory Brail) (05/15/91)
In article <23491.9105141352@crete.dcs.glasgow.ac.uk> inei@cs.glasgow.ac.uk (Nick Nei) writes: > >What I dread has finally happened - our students have discovered >Cayman's Watch program and with glee watched user's login passwords >fly by on their screens while running Watch. It sounds to me that the security threat is in your file server (or whatever) software that transmits clear-text passwords over the net rather than encrypted ones. AppleShare encrypts passwords before transmitting them, so using it should be more secure than using other file server software. As for passwords typed when logging into to other computers (like UNIX boxes), I don't know. Either that or wait until someone solves this problem at the OS level (like with Kerberos or something.) Good operating systems do things in such ways that people who listen to the network can't find out passwords and other confidential information. Watch isn't the only program that lets people see what goes over the network. It's just easier to use and easier to get. -greg +----------------------------------------------------+ Greg Brail Internet: gjb@cs.brown.edu BITNET: gjb@browncs.bitnet UUCP: ..uunet!brunix!gjb Home: (401)273-1172
moyman@ECN.PURDUE.EDU (Mike Moya) (05/15/91)
What I would very much like to see (and VERY trivial to do by the
developers of these programs) is that all of these programs (Watch,
ApplePeek, etc...) that sniff the AppleTalk NBP *REGISTER* themselves on
the NET. That way anybody else with an ounce of programming knowledge and
can read IMXX can write a trivial watchdog program that simply looks for
the registration of any "sniffing" programs running on the AT net... It
would never stop somebody from writing their own (not *that* tough)
sniffer, but much tougher to do than downloading an app. Granted it's not a
perfect solution (and older copies would remain out there) BUT, IMHO it
would be one more level of protection.
So, what *could* be done:
1) PD programs that sniff the AT register themselves at startup:
...like "ChooserName:Watch@*" for Watch
...or "ChooserName:ApplePeek@* for ApplePeek (You get the
idea)
2) PD sites remove older copies and put on the newer.
3) Write a watchdog program to monitor AT for PD rogue sniffer apps
running.
Just a thought...
--moya
--Mike Moya
--Macintosh Systems and Networking
--Engineering Computer Network, Purdue University
--moyman@ecn.purdue.edu steph@kona.cs.ucla.edu (Stephen Sakamoto) (05/15/91)
In article <9105142111.AA08420@aquarium.ecn.purdue.edu> moyman@ECN.PURDUE.EDU (Mike Moya) writes: >What I would very much like to see (and VERY trivial to do by the >developers of these programs) is that all of these programs (Watch, >ApplePeek, etc...) that sniff the AppleTalk NBP *REGISTER* themselves on >the NET. That way anybody else with an ounce of programming knowledge and >can read IMXX can write a trivial watchdog program that simply looks for >the registration of any "sniffing" programs running on the AT net... It >would never stop somebody from writing their own (not *that* tough) >sniffer, but much tougher to do than downloading an app. Granted it's not a >perfect solution (and older copies would remain out there) BUT, IMHO it >would be one more level of protection. > > If you wanted to know when somone was running a program like this it would work. If you want to know who was running it, this would offer no protection at all. Most software that I have seen that does any kind of registration uses the Chooser name. I consider that information pretty useless since anyone can change it to anything. It looks like the only real solution is to stop send any password over the network even if it's encrypted. > >Just a thought... >--moya > >--Mike Moya >--Macintosh Systems and Networking >--Engineering Computer Network, Purdue University >--moyman@ecn.purdue.edu -- Stephen Sakamoto UCLA Computer Science Department steph@cs.ucla.edu
jean@BIOMAC.UNIV-LYON1.FR (05/15/91)
> >Cayman Watch program is very dangerous on the the ethernet side and not >that dangerous on the localtalk side unless some one is using NCSA >Telnet to login to other machines. > It is also VERY dangerous on the LocalTalk side: you can peek username/password for accounts on remote hosts (using NCSA Telnet), but you can also peek username/password for AppleShare volumes (but not for TOPS which seems to use password encryption). You can also grab whole Postscript files sent by someone to a LaserWriter, without anyone knowing anything (care of examination subjects). The only workaround I can see is to have separate subnets for Macs containing "classified" informations. > >On the ethernet side, it is very dangerous since it can see >all the packets that fly by the cable it is connected to. > You can also use subnets: username/password pairs are only available on the subnet(s) from/to where you are login in. >Suggestions ?? >- May be remove Watch from public access mac. It is freely available from Cayman... >- Pray that no one know how to use it. It is so easy to use it... >- Tough policy. May be add this line: > "Death Sentence" if got caught using unauthorize account. > >Hanz Makmur >Rutgers University This last suggestion maybe a good thing for "honest" pirates. I think that the only good solution is to use separate networks for Macs (and LaserWriters) containing "classified" informations. Jean Jean Thioulouse | e-mail: | Universite Lyon 1 - Laboratoire de Biometrie | jean@biomac.univ-lyon1.fr | 69622 Villeurbanne CEDEX - France. | Bitnet: THIOULOU@FRCISM51 |
Jim.Matthews@dartmouth.edu (Jim Matthews) (05/15/91)
In article <9105142111.AA08420@aquarium.ecn.purdue.edu>, moyman@ECN.PURDUE.EDU (Mike Moya) writes: > What I would very much like to see (and VERY trivial to do by the > developers of these programs) is that all of these programs (Watch, > ApplePeek, etc...) that sniff the AppleTalk NBP *REGISTER* themselves on > the NET. This trick is anything but trivial. An sniffer typically works by bypassing all the standard network drivers and putting the network hardware in "promiscuous" mode so that it will capture all the packets on the wire. To make it respond to some of those packets (i.e. NBP lookups with a certain name) would require a re-implementation of a subset of NBP and DDP (since the .MPP driver won't be around to take PRegisterName calls). Not only that, but looking for and responding to those packets would probably cause the sniffer to miss other packets. A better answer (IMHO) is to stay away from monolithic networks (i.e. 1000 users on an ethernet segment) so only a small fraction of the user population can be monitored from any given location. People should also try to move away from systems that require the sending of clear-text passwords (i.e. standard Unix logins) towards client-server systems that support random-number exchange (i.e. Kerberos, AppleShare). This is much easier said than done, of course. But networks are never going to be secure from people who have access to the media, and software systems should evolve to deal with that. Jim Matthews Dartmouth Software Development
gwhite@arco.com (05/16/91)
>What I dread has finally happened - our students have discovered >Cayman's Watch program and with glee watched user's login passwords >fly by on their screens while running Watch. Actually there are several PC and Unix programs that do the same thing, although maybe not with the easy Mac approach. Let's not blame Watch too much for doing what is not uncommon. The long-term answer would be Kerberos or something similar, which avoids allowing clear-text passwords on the net. -Gary
tom@wcc.oz.au (Tom Evans) (05/16/91)
In article <23491.9105141352@crete.dcs.glasgow.ac.uk>, inei@cs.glasgow.ac.uk (Nick Nei) writes: > > What I dread has finally happened - our students have discovered > Cayman's Watch program and with glee watched user's login passwords... The "proper solutions" to this have been covered (encryption, two-way passwords etc.). Here's a less serious suggestion (with obvious problems :-). Classify "unauthorised use" of Watch, Peek et.al. as being the same as a Virus. Persuade the authors of commercial virus-checking INITs/apps to check for the presence of network monitoring programs (that open the network hardware in "promiscuous" mode) and do something appropriate. moyman@ECN.PURDUE.EDU (Mike Moya) writes: > What I would very much like to see (and VERY trivial to do by the > developers of these programs) is that all of these programs (Watch, > ApplePeek, etc...) that sniff the AppleTalk NBP *REGISTER* themselves on > the NET. I agree, but I thought that all these programs "took over" the hardware, thus preventing any other activity (like responding to an NBP LookUp) on that Mac. Might be impossible unless the monitoring program independently interprets received packets and duplicates the NBP layer. How about requiring ALL Macs to run Responder, and have a central monitoring program look for and log Macs that have gone "off air" (Responder not responding). This could be done with the CAP programs getzones, atlook and a small shell script (which sends you mail). You can then appear behind perpetrators and look over their shoulder and pointedly ask what they're doing. This might deter them somewhat. ======================== Tom Evans tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") ** Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455
dnb@meshugge.media.mit.edu (David N. Blank) (05/16/91)
> How about requiring ALL Macs to run Responder, and have a central > monitoring program look for and log Macs that have gone "off air" > (Responder not responding). ... > You can then appear behind perpetrators and look over their shoulder > and pointedly ask what they're doing. This might deter them somewhat. Of course, they may answer "I was turning off my mac to go home for the night." Peace, dNb -- David N. Blank o/ \ / \ / / \o M.I.T. Media Laboratory /# ##o # o## #\ E15-473F, (617) 253-2169 / \ / \ /o\ / |\ / \
cmclark@predator.rs.itd.umich.edu (Charles Clark) (05/18/91)
tom@wcc.oz.au (Tom Evans) writes: > >Classify "unauthorised use" of Watch, Peek et.al. as being the same as >a Virus. Persuade the authors of commercial virus-checking INITs/apps >to check for the presence of network monitoring programs (that open >the network hardware in "promiscuous" mode) and do something appropriate. Like what? Not let you use your network? So then anybody who can start up a "sniffer" can instantly blow away everyone else's ability to use their network? Cool <-sarcasm >moyman@ECN.PURDUE.EDU (Mike Moya) writes: >> What I would very much like to see (and VERY trivial to do by the >> developers of these programs) is that all of these programs (Watch, >> ApplePeek, etc...) that sniff the AppleTalk NBP *REGISTER* themselves on >> the NET. > >I agree, but I thought that all these programs "took over" the >hardware, thus preventing any other activity (like responding to an >NBP LookUp) on that Mac. Say what? This would basically make all "sniffer" products worthless. If I am trying to debug network problems by capturing packets, and my presence on the net *changes* how the other machines are acting, then it would be poor debugging tool, wouldn't it? >How about requiring ALL Macs to run Responder, and have a central >monitoring program look for and log Macs that have gone "off air" >(Responder not responding). Except that there are myriad reasons why macs go "off air"... cmc
inei@cs.glasgow.ac.uk (Nick Nei) (05/22/91)
Many thanks to all who responded and participated in the discussion.
Briefly, my problem: in a student lab, some students are spying on
fellow student's UNIX login passwords using Cayman's Watch which
samples AppleTalk packets on LocalTalk.
Suggested solutions:
* Cut off fingers of perpertrators and parade them in public.
(We will be doing that - not literally!)
* Use kerberos. (But will it work with NCSA Telnet? Is there
an NCSA Telnet version that is kerberos compatible around
somewhere?)
* Remove Watch from disc. (It never was on public hard disc
and not to ask students to remove their copies is not
a workable solution.)
* Ask Cayman to produce copies of Watch which register themselves
on network. (A case of closing the stable door after the
horse has bolted?)
* Subnet the network and minimise the damage. (Not really
satisfactory. Everybody is still nervous/paranoid.)
* Write a watchdog program which watches AppleTalk for sniffer
programs like Watch. (Not a bad idea, but does not prevent
hackers from writing a sniffer themselves, and how will I know
the name of the hacker? I can't believe the name in the Chooser
is real.)
* Make all Macs run Responder, and when one goes off air, check
what user is up to. (Won't work for us - we have over 500 Macs
in dispersed labs.)
* Pray no one uses Watch, Peek, etc. (Have been doing this!)
No one has offered a satisfactory solution. How about augmenting
NCSA Telnet and telnetd on the UNIX site? Using one-way encryption,
NCSA Telnet sends encrypted password to telnetd, which decrypts it
before giving it to login. Proviso: this solution only protects
password and nothing else. Can any expert out there tell me if this
is feasible?
Mail: Nick Nei, Computing Science Dept.,
Glasgow Univ., 17 Lilybank Gardens,
Glasgow G12 8QQ, UK. Tel: (041) 339 8855 x 5457
ARPA: inei%uk.ac.glasgow.dcs@nsfnet-relay.ac.uk USENET: inei@cs.glasgow.uucpbrad@CAYMAN.COM (05/22/91)
Humm. Good thing I didn't add the "reconstruct telnet session with vt100 emulation" (which I had thought about doing ;-) As the author of Watch, I feel inclined to comment. I don't have *the* answer, rather some comments... - The benefit most of our customers have received from using watch has been large. They can capture packets when problems arise, send them to us and we can help them solve problems. That's why I wrote it. - As with any "sharp" tool, it can be misused. Perhaps decoding the telnet sessions and displaying the actually data was not a good idea, but the data is there in the hex dump anyway, so... - MIT's "netwatch" or what ever it's called has been available for years and would allow you do the same thing. It runs on a PC. There seem to be a lot more PC's with ethernet cards around than Mac's with ethernet cards (but, perhaps the Mac is easier to use and then abuse... ;-) - One solution which places like MIT use is to run rlogin with kerberos. My understanding is that this works with all the BSD derived systems (sun, ultrix, etc) and never sends any passwords in clear text. If you use telnet, you get passwords in clear text. I don't know if there is a version of NCSA which does rlogin with kerberos (but is there isn't, I'll offer to create one) - I agree with the person who said, "the problem is not with the tool, it's with the server"; I realize this may a non-solution for you (i.e. you've got a lot of existing servers which can't be changed easily). -brad