Re: references to password sniffer incident
I know of three systems that have been attacked in the last month or so. One was attacked by social engineering the password out of an user. Another was attacked by installing NETBUS on an user's machine. The third was attacked by having the attacker subscribe himself to the mailing list used to distribute passwords. (Mailing list!) With this being the state of the art in protection, why bother with intercepts, cryptoanalysis etc? - Bill Frantz | Macintosh: Didn't do every-| Periwinkle -- Consulting (408)356-8506 | thing right, but did know | 16345 Englewood Ave. [EMAIL PROTECTED] | the century would end. | Los Gatos, CA 95032, USA
Re: references to password sniffer incident
At the 2600-coordinated Beyond HOPE conference (NYC, 1997), it was made very clear to users that passwords transmitted in-the-clear would be Right, passwords always have been the weakest link. panel singled-out an unlucky telnet user, announcing a domain name and Not just telnet is vulnerable, as you know. I've watched as security consultants ssh to a site, logout, and procede to login to another site using stock ftp. The people are not stupid or anything, they just don't think - hey, this protocol sends passwords in plaintext. You can get around that by establishing a secure tunnel or using Skip/an IPSEC implementation, but most folks don't do that yet. Perhaps that the kind of shock factor that's necessary to get people (certain people, anyhow) thinking realistically about security. We even Ding ding ding, you've been awarded the "have clue" prize of the day ;). Think I mentioned this on coderpunks, but Schneier has two "reality check" essays on Counterpane's site. Good reading. considered sniffing passwords and hooking up a line printer in a central location. nah! :) Someone I knew who was using a weak password (a foreign word from a semi-obscure foreign language) challenged me one day, claiming I would never find it out. A few keystrokes and a sniff later, the password was in hand. Using pop3 to transfer your mail to and from an offsite system can be very revealing ;) Seriously though, it's frightening to think of all the possible ways an account can be compromised, and the limited public education on how to prevent or delay many of these attacks. Dan
Re: references to password sniffer incident
While on the topic of password-sniffing anecdotes from conferences -- At the 2600-coordinated Beyond HOPE conference (NYC, 1997), it was made very clear to users that passwords transmitted in-the-clear would be sniffed. To hammer home the point, one participant in the Tiger Teaming panel singled-out an unlucky telnet user, announcing a domain name and hinting at the password over the loudspeaker system. It got a pretty good laugh from the audience. Perhaps that the kind of shock factor that's necessary to get people (certain people, anyhow) thinking realistically about security. We even considered sniffing passwords and hooking up a line printer in a central location. nah! :) ||| Dominick
RE: references to password sniffer incident
Phil Karn wrote (amongst other things) The people who run today's MIS/IT departments are the direct descendents of those who ran big computer centers in the old days. No we're not their descendents - we are the same guys. Those "old days" aren't that long ago we haven't been put out to grass yet. They've watched as most of their reason for being has been eroded out from under them by the personal computer. The network is the only thing they have left. H I don't think my "reason for being" has much to do with computers or work of any sort. But our employer's reasons for paying us to come in to the office haven't been eroded. If anything the more complex systems we have now generate more work, not less. The more stuff the users get up to the more there is for us to do. And on the whole we tend to be fans of de-centralised management. And, of course, we love playing with new toys. They justify their tight central control of it with strident appeals to security fears, just as governments have for centuries whipped up fears about crime to justify the creation of police states. Deploy good security mechanisms in host systems so they no longer depend on (largely illusionary) security mechanisms in the network, and you've taken away the very last reason these people have to go on living. Expect a big fight. It's, honestly, very often exactly the other way round. Management (mainly accountants in the UK or lawyers in the US) are often paranoid about what they see as legal problems. They use "security" as a mantra to oppose any change. They *love* doing big deals with suppliers they have heard of, they *hate* their IT departments, and they are often willing to take advice from any cowboy who turns up in the right kind of smart suit. There are companies that won't use SSL even, or *anything* that involves certification or encryption because the management the legal people want to have a "corporate strategy" first won't let those IT departments implement anything until it is all complete. Trying to talk to these people about IPSEC would be like chatting up a brick wall. Us IT department types spend a lot of our time *telling* them that the security they need really has to be implemented end-to-end, in the hosts. And they spend a lot of their time ignoring it. There are others who simply don't trust electronic media of any kind. They want everything on paper, they somehow don't think it is "real" unless it is written down. There are managers who demand that all email they receive gets printed automatically employ staff to file it - what does that do to encryption? Discussions go like this: Faceless Corporate Beauraucrat: "My application is really important no-one must read my files or messages" Me: "it's only safe if you encrypt it". FCB: "We are encrypting it, we use MS Exchange NT". Me: "well, that's not all that safe, we really ought to be thinking about insert widely available strong encryption method of your choice" FCB: "But isn't that illegal?" Me: "No, not really insert brief explanation of crypto export saga" But the FCB's eyes have glazed over they have made their excuses and left. Thrusting Corporate Lawyer: "we really need to communicate fast with these law firms" Me: "That's easy, you just send them some Internet mail." TCL "Oh no, I've heard that the Internet is crawling with hackers and criminals! We have to use x.400!" Me: "yeah, you can do that, although it makes the address book harder to manage, and it's usually slower, and it isn't really that much more secure - if you want to keep it secret you need to encrypt it." Insert discussion about encryption as above TCL: "That sounds hard. I think I'll stick to fax". Greed-is-Good Corporate Trader Type: "We have to get these contracts out yesterday! And your bloody email to telex system isn't working!" Me: "That's because us lazy, old-fashioned, non-business-orientated, mainframe-mindset, crypto-fascist-fom-hell system-administrators were all down the pub plotting to Rule the World through Network Management; and we couldn't be bothered to pull our fingers out to fix the server. But why are you still using telex anyway? Why don't you just send your customers email? Everybody is on the Internet these days it is much faster, 2,000 times cheaper and you won't have to use all those naff upper-case letters." GICCTT: "But... "insert fruitless discussions on encrytption, security, reliability " and anyway, Telexes are Legal Documents and email is Not a Legal Document." Me: "I'm going back to the pub. Call me if you ever actually make a profit." But it could be worse - I have seen people who insisted on having remote users (at over 200 locations) use a PC and modem to dial up a server, with no dial-back, and log on to Unix; all sharing one userid and password (because it made the admin easier), that userid having rwx access to the entire directory tree that contained the application and all its
Re: references to password sniffer incident
I'm going to go off on a bit of a tangent here... this is really a security issue, not a crypto issue, but I think it's something that we'd all do well to think about. Derek Atkins wrote: sniffible, none of my passwords were. I happen to be one of the lucky few who has made it through the politics of large companies to "open up the firewall". Yes, corporate IT people see something even as secure as SSH as 'opening the firewall'. I'm one of those corporate IT people and I let Ssh in through our firewall, but I'm not very happy about it. With Ssh, other secure tunneling protocols, or IPSec tunneling I'm providing a secure communications channel for some machine on the outside to access a wide range of network services inside our network. The problem is that I know nothing about this outside machine... this may be a Windows machine with a fixed IP# (say on a cable modem) which is wide open, running a half-dozen totally unsecured services, and infected with Back-Orifice to boot. An attacker can now easily get into this machine and install a little IP forwarder on it and he has a perfect little gateway into my network! Yes, I could demand that all my remote users be running NT4.0SP4 with some additional security patches and have all their services turned off (or better still, Linux or *BSD configured by my network engineers), but how am I going to enforce this? Simply put it's administratively impossible... the machines of the remote users are beyond my control and must be assumed to be completely insecure. The approach I'm hoping to take (for lack of a better alternative) is to give people IPSec access but to try to ensure that at any time that they are tunneling into our network their machine is not reachable by any means /except/ through the tunnel. Establishing the tunnel will require authentication with a hardware token (this is what we're currently doing for Ssh, too... I've learned the hard way that I can't trust people to use strong passphrases even after practically pleading with them to do so). The result will be that at least their machine can't become an outright gateway into our network, although it might still be used as a springboard by an attacker aware of the mechanisms. Compromises, compromises. Anyway, my point is that as we all make progress in developing secure means of communication, of course we want to use these means to make life more convenient... we have IPsec, so of course we want direct remote access to our network filesystems, etc., not just a terminal session! But we just because the communications channel is secured does not mean the end-points are, so we are opening ourselves up to many new avenues of attack. Phil Karn wrote: The real problem with SSH, IPSEC, encrypted Telnet and the like is that they're much too *decentralized* for their taste. Yes, that's exactly right... And that directly threatens their power base. Some IS managers may be concerned with maintaining their power base, but many of us /love/ decentralization as a means of pushing responsibility back out to the users and thereby making our own lives easier. Believe me, there's nothing I like better than telling a user "DIY" because we've taken the steps to decentralize that particular task and empowered them to do so. The problem in this case is that the decentralization pushes the responsiblity for maintaining /security/ back out to the user (the owner of the endpoint) and the reality is that the users just can't be trusted with this. I mean if my users were the members of this list it might be a different story... (maybe!)... but they are people who are far too busy to worry about such details as whether or not they left an unsecured Frontpage server running on their laptop or whether it might be dangerous to accept that active-X control their browser just offered to automatically download. Once again; cryptography is helping us secure the communications channels and the authentication mechanisms at the end-points, and so we rely on them more heavily, lulled by a possibly false sense of security. We must not lose sight of the fact that as we use these mechanisms to decentralize more we are potentially expanding the chains around our networks to include many very weak links in the form of end-points whose security depends on humans who are sure that it isn't their job to worry about security. - Jürgen
Re: references to password sniffer incident
At 08:35 AM 3/25/99 -0800, Jurgen Botz wrote: Yes, I could demand that all my remote users be running NT4.0SP4 with some additional security patches and have all their services turned off (or better still, Linux or *BSD configured by my network engineers), but how am I going to enforce this? Simply put it's administratively impossible... the machines of the remote users are beyond my control and must be assumed to be completely insecure. The approach I'm hoping to take (for lack of a better alternative) is to give people IPSec access but to try to ensure that at any time that they are tunneling into our network their machine is not reachable by any means /except/ through the tunnel. Establishing the tunnel will require authentication with a hardware token (this is what we're currently doing for Ssh, too... I've learned the hard way that I can't trust people to use strong passphrases even after practically pleading with them to do so). The result will be that at least their machine can't become an outright gateway into our network, although it might still be used as a springboard by an attacker aware of the mechanisms. Compromises, compromises. Its no worse than allowing laptop telecommuters (with possibly compromised systems) dial-in, as is now the common practice. --Steve
Re: references to password sniffer incident
On Tue, 23 Mar 1999 14:54:15 -0800 (PST), Phil Karn [EMAIL PROTECTED] said: Phil Actually, things are getting much better in the IETF terminal rooms. Phil SSH is now *very* widely used, with encrypted Telnet and IPSEC Phil trailing well behind. Phil Phil The same for every USENIX (regular, Security and LISA) I've been to for the last two years. Also at ISOC NDSS last three years. A few hardy souls brought floppies with various SSH binaries, as well as one person who downloaded the source from his home site, and then compiled it on the local machine with a GCC binary which he had also brought from "home". I'm not that paranoid :-) --tep
Re: references to password sniffer incident
...And of course nobody has compromised any of the ssh binaries on the workstations... Workstations? What workstations? Anybody serious about security brings their own laptops. And then they worry about them being tampered with by the hotel custodial staff. Laptops are also easier to lug into a working group meeting so you can read your mail during the more boring presentations. Phil
Re: references to password sniffer incident
-BEGIN PGP SIGNED MESSAGE- Actually, things are getting much better in the IETF terminal rooms. SSH is now *very* widely used, with encrypted Telnet and IPSEC trailing well behind. ...And of course nobody has compromised any of the ssh binaries on the workstations... Phil slainte mhath, RGB - -- Richard Guy Briggs -- PGP key availableAuto-Free Ottawa! Canada rgb at conscoop dot ottawa dot on dot cahttp://www.flora.org/afo/ http://www.conscoop.ottawa.on.ca/ FreeS/WAN:http://www.flora.org/freeswan Please send all spam to [EMAIL PROTECTED] Marillion:http://www.marillion.co.uk -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQCVAwUBNvgp3d+sBuIhFagtAQG8dgP/bEBcWyPe7GddKqDQ8AF2xCf2ktf7+NnT axWKvQyzoFD3J7CwI4hvtWrXJamtPuHWK0ohAs5e4tUhPr40187/wnbOMVXdbvtF Stb3yIevk3Gjq44a1aXDlo4KDVKMcY27/cxQV6oe90/f5PF+9idCx8zM8k8ZkDnH fzXQZlNsfx8= =Fm6Z -END PGP SIGNATURE-
RE: references to password sniffer incident
as one person who downloaded the source from his home site, and then compiled it on the local machine with a GCC binary which he had also brought from "home". So he trusted the libaries and headers on the local machine? That seems less secure than bringing statically-linked binaries on a floppy, where you only have to trust the kernel.
Re: references to password sniffer incident
Catching up on email, I will point out that every major service provider is probably compromised to one degree or another as frequently as 3 times per year from terminal rooms. For example, in addition to Usenix meetings: IETF meetings, NANOG meetings, and every other computer meeting or show that hosts an unsecured unswitched local net At IETF, I've certainly known folks that have snooped the traffic from the terminal room. This is routine, over the past 5-6 years. The last time that I went (Chicago), such folks discovered that there was only one person on the net using IPSec (they tracked it down to me). They found nobody even using OTP. (heavy sigh) We go to all the trouble of designing these security techniques, but then don't use them in our own production environments! These were security folks, and I'm pretty sure they didn't save the passwords after laughing at them -- but anyone else in the room could. Remember, we have a lot more "unknown" folks attending. Meanwhile, I know that Merit and UMich reorganized the backbone topology a few years back after some major servers were compromised. Now, most traffic flows over links with no machines other than routers. General purpose servers are segregated, and on switched links to the extent practical. That doesn't help the dorms, or other public access unswitched networks on campus. And with MediaOne finally deploying cable access this year in Ann Arbor, I'd expect the whole kit and kaboodle to get worse before it gets better! Date: Tue, 09 Mar 1999 17:19:24 +1100 From: Greg Rose [EMAIL PROTECTED] I had no idea there had been so many, so well hushed up! MILNET, JANET (4 independent incidents in the UK in Q3 1995 alone), Panix and other ISPs, several universities, the USENIX terminal room, ... [EMAIL PROTECTED] Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: references to password sniffer incident
Actually, things are getting much better in the IETF terminal rooms. SSH is now *very* widely used, with encrypted Telnet and IPSEC trailing well behind. Phil
Re: references to password sniffer incident
Thanks for the good pointers that a number of people gave. The particular incident I remembered was the BARRnet one http://www.geek-girl.com/bugtraq/1993_4/0032.html (thanks Dan Riley). I had no idea there had been so many, so well hushed up! MILNET, JANET (4 independent incidents in the UK in Q3 1995 alone), Panix and other ISPs, several universities, the USENIX terminal room, ... Some other URLs: http://email.tqn.com/library/nus/bl110498-3.htm http://www.chips.navy.mil/chips/archives/94_jul/file14.html http://www.nic.mil/ftp/mgt/bul-9402.txt I was also reminded of a paper by Nathaniel Borenstein and others at First Virtual, about sniffing (network and keyboard) for credit card numbers using the check digit to identify them. I haven't found the actual paper, but it was a precursor to: http://www.inet-one.com/cypherpunks/dir.96.01.25-96.01.31/msg00618.html thanks Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Re: references to password sniffer incident
Greg Rose [EMAIL PROTECTED] writes: I wanted to refer to the incident where someone mounted a password sniffer at a major network hub (MAE-West?) a couple of years ago. But I haven't turned up anything useful in a Web search. I didn't dream this incident, did I? Does anyone have any references? There was an alleged incident in 1993, where a sniffer had access to the BARRNet low-speed router traffic--a lot less damaging than a sniffer on MAE-West, but that's the only incident of the type I can recall. http://www.geek-girl.com/bugtraq/1993_4/0032.html is the only useful reference I could find. -- Dan Riley [EMAIL PROTECTED] Wilson Lab, Cornell University URL:http://www.lns.cornell.edu/~dsr/ "History teaches us that days like this are best spent in bed"
Re: references to password sniffer incident
I don't specfically know about MAE-West, but there are any number of attacks on ISPs that involved setting up password sniffers on major transit Ethernets. Phil
