[VOIPSEC] FWD - Hotel and Wfi Insecurity, including SIP

[Robert Moskowitz]

Note that SIP is included..


========================================================================
SECURITY ADVISER: ROGER GRIMES                 http://www.infoworld.com/
========================================================================
Monday, November 7, 2005

A CONSTANT STATE OF INSECURITY


By Roger A. Grimes

Posted November 4, 3:00 a.m. PST Pacific Time

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.

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.

InfoWorld Test Center Contributing Editor Roger A. Grimes is a computer
security veteran and author who has done consulting work for many
Fortune 500 companies.
Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of Cybertrust, Inc.
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      rgm at icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit