A constant state of insecurity

For the past few months an acquaintance of mine has been sniffing various public wireless and wired networks around the world, looking to see what plain text passwords are visible. It was an eye-opening experiment.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

She used a bunch of different tools, but mostly Cain. At the moment, it collects 18 different passwords or password representations, including plain text passwords sent over HTTP, FTP, ICQ, and SIP protocols, and will automatically collect the user’s log-in name, password (or password representation), and access location.

Other than a few simple validity reviews and summary counts, my friend doesn’t look at the log-in names or passwords, and she deletes any collected information after obtaining the counts. She hasn’t used ARP (Address Resolution Protocol) poisoning or done anything other than to count plain text passwords passing by her traveling laptop’s NIC when she’s in a hotel, airport, or other public network.

Although some -- including me -- might question her ethics, the information she shared is useful in understanding our true state of insecurity.

She said about half the hotels use shared network media (i.e., a hub versus an Ethernet switch), so any plain text password you transmit is sniffable by any like-minded person in the hotel. Most wireless access points are shared media as well; even networks requiring a WEP key often allow the common users to sniff each other’s passwords.

She said the average number of passwords collected in an overnight hotel stay was 118, if you throw out the 50 percent of connections that used an Ethernet switch and did not broadcast passwords.

The vast majority, 41 percent, were HTTP-based passwords, followed by e-mail (SMTP, POP2, IMAP) at 40 percent. The last 19 percent were composed of FTP, ICQ, SNMP, SIP, Telnet, and a few other types.

As a security professional, my friend often attends security conferences and teaches security classes. She noted that the number of passwords she collected in these venues was higher on average than in non-security locations. The very people who are supposed to know more about security than anyone appeared to have a higher-than-normal level of remote access back to their companies, but weren’t using any type of password protection.

At one conference, she listened to one of the world’s foremost Cisco security experts as his laptop broadcast 12 different log-in types and passwords during the presentation. Ouch!

The high prevalence of HTTP-based passwords can probably be attributed to HTTP-based e-mail solutions. If you have or use an HTTP-based mail system, sniff the traffic to see if log-in credentials are sent in clear text. If you’re lucky, the e-mail system uses HTTPS for log-ins and authentication, or uses password hashes or some other respected technique. On a good note, many popular e-mail portals such as Hotmail, Googlemail/Gmail, and Yahoo!Mail do not send plain text passwords by default.

Unfortunately, e-mail protocols such as POP3, IMAP, and SMTP send plain text log-in names and passwords by default. Just like FTP, the user name is preceded by the identifier USER and the password is preceded by the word PASS. A password sniffer could define their capture filters to look only for packets with those identifiers, maximizing the number of passwords captured.

Make sure your company is not a victim. Most e-mail clients and e-mail servers allow the plain text password option to be disabled. For instance, in Exchange/Outlook combinations, simply enabling "Encrypt data between Microsoft Outlook client and Microsoft Exchange Server" in Outlook 2003 or "Secured Protected Access (SPA)" in previous Outlook versions will disable plain text password use.

Another interesting issue my friend noticed was how many HTTPS-enabled Web sites did not implement SSL correctly -- users' log-in names and passwords were being sent in clear text. This included communications to remotely accessed security devices, portals, and firewalls.

The lesson here is never to trust the browser’s padlock icon when connecting to a new Web site or protected device. Sniff yourself and confirm. I did this last year and discovered my awesome anti-spam appliance’s SSL connection wasn’t working.

My friend noticed that if SNMP was detected, the default public and private community strings were used almost 100 percent of the time. She also found passwords to people’s TiVos, online poker games, and online chatting communities. What disturbed her was that often these personal passwords were identical to the user’s corporate passwords.

Many network administrators conduct password audits on their network, but those audits are often directed at cracking weak password hashes for log-in accounts. If you want to know your true state of security, sniff your remote traffic heading across the Internet or coming across the wire from roaming or home users. If you have to use services or protocols that use plain text passwords, use a VPN tunnel of some type between source and destination.

I counseled my friend to stop her password sniffing ways, as it could only lead to trouble. She said she had stopped a few months ago because she found the idea of how many plain text passwords were being passed around, especially by security professionals, just too stressful and disturbing. I agree with that sentiment: If you’re a security person, sniff your own traffic the next time you go out of town to make sure you aren’t leaking any credential information.