levy@ttrdc.UUCP (Daniel R. Levy) (09/18/87)
# 3) eye - # This is the gem of the bunch. Written for a Sun # computer, it watches TCP/IP connections on the # ethernet. This lets you see exactly what a user # is doing... both input and output. Also, it # lets you keep a transcript of the conversation. Triggers # exist on it to start watching a connection when the # user types "su\n" and when a connection starts up. # # Very useful for breaking into computer systems and watching # what others are doing at any given time. # # I wrote this one.... # I will not pass out ... eye to anybody. # ... eye only works on Suns. The # current version of eye is nothing but a machine cracker. I don't # see a reason to pass this around. # In a few weeks, I plan on posting a new version of eye that is a # ethernet debugger. I never plan on posting my cracking version. Are you sure that your code will be written so that it takes a true guru to readily modify it to add the "cracking" functions? If not you might want to think twice about sending it out, or post a uuencoded binary instead. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | vax135}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer: i am not a Yvel Nad |--------Skokie, Illinois--------|
tjacob@umn-cs.UUCP (Thomas Jacobson MSC) (09/22/87)
In article <1903@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > > Are you sure that your code will be written so that it takes a true guru to > readily modify it to add the "cracking" functions? If not you might want to > think twice about sending it out, or post a uuencoded binary instead. > -- > |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, > | an Engihacker @ | vax135}!ttrdc!ttrda!levy > | AT&T Computer Systems Division | Disclaimer: i am not a Yvel Nad > |--------Skokie, Illinois--------| Most SUN's require su priv to get to the ethernet card, or, if it's reading data out of /dev/kmem, there are more security holes than I care to think about. The real problem with ethernet watchers is that anything on the net is available for viewing. At the U of Mn, where there is a campus wide network, many of our terminals are connected via terminal concentrators to the network, and as such, almost all su's and associated passwords get sent across the net. I don't think that you should worry about posting source code because anyone following the MIT PC/IP discusisoons can pick up a free software package that can very easily be modified to do what you're against. ( NOTE: my position is the same as Dan's - I don't like to see software like this used with the intent to break a system. As one of these network guru's working on networks for the SuperComputer Center here, this has caused no end to the headaches... ) In conclussion, I like to see such software posted, in source form, and think it's unreasonable to expect the author to supervise or watchdog it's use.
tjacob@umn-cs.UUCP (Thomas Jacobson MSC) (09/24/87)
Humm - seems I may have implied things in my last article which I didn't intend to. 1) Security is not just a problem here ot the U, but the same techniques can be applied to any network. 2) Just because it's possible to do something, doesn't mean it can be done. More on point two. There are several ways of preventing eavesdropping on your ethernet as described before. Here, we use several means. One is that our cable is physically secure. i.e. no one outside a trusted group of people can place taps on the network. Connections to outside networks are filtered. Sensitive information is placed on physically seperate cables from main production network. etc, etc, etc... Other ways of stopping intrusion are to diable forwarding and/or redirects, TDR the line at random times to detect new taps, use encryption and so on. As to using an ethernet watcher to crack SU passwords, that can be avoided by using good unix practices of changing passwords, only allowing root logins on consoles, only allow root su on hardwired terminals, routinely checking for abnormal root usage or setuid programs. I'm sure others have addressed these issue too. How about some input as to how others have done this ?? ( ie made networks/systems secure from prying eyes... ) Joseph Thomas arpa: jpt@uc.msc.umn.edu ---------------------------------------------------------------------------- Disclaimer: The above did not/does not/will not necessarily reflect the opinions of the attached name or his employer, but may or maynot be those of a minion. ----------------------------------------------------------------------------
cyrus@hi.UUCP (09/27/87)
In article <2182@umn-cs.UUCP> tjacob@umn-cs.UUCP (Thomas Jacobson MSC) writes: > > As to using an ethernet watcher to crack SU passwords, that >can be avoided by using good unix practices of changing passwords, >only allowing root logins on consoles, only allow root su on hardwired >terminals, routinely checking for abnormal root usage or setuid programs. > > Joseph Thomas Hmm? Well, only allowing root su on hardwired terminals is great if you have hardwired terminals. Here at UNM though, in the EECE department, the ONLY hardwired terminals are the consoles. Everything else is via ethernet terminal servers. It would be prohibitively inconvenient for us to have to go to the console to do anything as root. This in itself is not all that bad because, like you, only certain people can add taps. Our problem is that the number of PC's being put on the network, by the administrative types who like the benifits of fast communications, is increasing daily. The number of PC's in labs is also gaining popularity. These will be the main problem and the only way to solve this problem is to put PC's on there own ethernet cable and then pass everything through a 'smart' gateway. We do, as you mention, weekly 'find's looking for setuid programs and comparing that list against a prepared list. If a new setuid program pops up, we will be notified (cron does it). You also have to consider that "root"s are trusted people. If I have root on one machine, I can EASILY get root on anyother machine by just following .rhosts of root and other privledged users. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of EECE - Hypercube Project @__|_______@ | Albuquerque, New Mexico 87131 | | | | | | hc | | e-mail: | @.......|..@ cyrus@hc.dspo.gov or | / | / seismo!unmvax!hi!cyrus @/_________@/
mjr@osiris.UUCP (Marcus J. Ranum) (09/28/87)
In article <16434@hi.UUCP>, cyrus@hi.UUCP (Tait Cyrus) writes: > Hmm? Well, only allowing root su on hardwired terminals is great if you > have hardwired terminals. Here at UNM though, in the EECE department, > the ONLY hardwired terminals are the consoles. Everything else is via > ethernet terminal servers. It would be prohibitively inconvenient for us > to have to go to the console to do anything as root. Actually, the hardwired terminal idea was to keep people from logging in as "root" on anything but the console. Remember the "su" command ? THAT doesn't need to be run on the console, though some versions read /etc/securettys to determine if the tty is "ok". I'm sorry to hear that system security is prohibitively inconvenient. That is something you get to work out among yourselves. --mjr(); -- If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I get as crude as possible. These days, though, you have to be pretty technical before you can even aspire to crudeness... -Johnny Mnemonic