codeblog code is freedom — patching my itch

I should qualify my comments from my prior blog entry and say that I’m appalled at Service Providers (not users) that continue to offer insecure services to their clients. Users, however, should be asking their Providers for secure services. Most don’t know to ask this, and that’s why I think the responsibility falls on the Provider.

Here’s my crash-course in simple anti-sniffing techniques.

• Evaluate your network: if you’re on open Wireless, any one interested can see all communications to/from your computer. Be paranoid. If you’re on a wired network, your communications can still be seen, but it tends to be much less likely.
• Evaluate your services: do you care about your various services? Do you have a different password for each service? Details below…

Evaluating your services requires creating a short list of all the things you send over the network from your computer. For basic anti-sniffing, there are two types of “encryption” available for most services:

• Authentication: logging into anything. Checking email, logging into IM, logging into websites, etc. Some services offer “encrypted” authentication. Modern AIM clients, “APOP” POP clients, etc. If your authentication is encrypted people can’t just sniff your account/password off the wire.
• Communication: all the traffic to any site/service. All services have a fully encrypted counterpart. Almost everything uses SSL for encryption, and appends an “S” to the protocol name. HTTP has HTTPS, POP has POPS, IMAP has IMAPS, SMTP has a TLS mode, Jabber has an SSL mode, good IRC networks have an SSL mode, etc. These SSL-protected services encrypt ALL of your communciation, including the username/password authentication.

It’s best to have fully encrypted communications, but if you can’t, just getting some kind of obfuscated authentication mechanism is better than nothing. Just ask yourself any time you type in a username/password, “How is this being sent to the remote server?”

So, here are some specifics to various common services:

• Receiving email: POP and IMAP have SSL modes that run on different ports. See if your email Provider offers these services and switch your client to using those instead. If that’s not available, see if POP or IMAP support other authentication modes besides the clear-text “Plain” and “Password”. For example CRAM-MD5, Challenge/Response.
• Sending email: SMTP has an SSL mode too. This is either called “STARTTLS” or “SSL”. A good Provider will offer SMTP on port 587 with STARTTLS. Hopefully your Provider requires you to authenticate before sending email. Instead of SSL, like POP/IMAP above, they may offer CRAM-MD5, etc.
• Web sites: only use “https://” for logging into websites. If there isn’t a little lock in the corner of your browser, don’t log in. The browser folks have done a lot to help folks with this part. Ecommerce has caused a huge push to avoid in-the-clear authentication on websites. Unfortunately, some sites will still let you log in without SSL. (Like flickr, it seems.)
• IM: I’m not sure about ICQ, MSN, etc, but Jabber offers a full SSL mode. The “old” style runs on a separate port (5223). The “new” style gets “turned on” during the initial jabber session setup. This would give you fully encrypted communications. I know AIM has both a Challenge/Response and MD5 mechanism for logging in, so at the very least, use those.

If you’re not sure if your communication is being encrypted or not, it’s very easy to install a network sniffer. Ethereal is available for almost every platform around, via the libpcap libraries. Just start it capturing before you use a service, use the service, and then go find the traffic in the capture log. Ethereal will identify almost all services by name (“HTTP”, “POP”, “IRC”, “AIM”, etc.) To see the traffic, click on the “Analyze > Follow TCP Stream”. This will show you all the communication for a given connection. (Click on “Clear” in the Filter bar to see all your traffic again.)

If you want to browse the traffic more easily, you can type in other filter terms. For example, to make sure your POP password isn’t being sent in the clear, enter “pop.request” in the Filter, and click “Apply”. Pick a packet, and select the “Request” section in the Packet Tree. If you see:

Request: USER omfg

Request: PASS intheclear

Then your “omfg” account is showing it’s password to the rest of the network. :)

Another alternative to all this pain is to have a VPN connection to some other network that you trust. This is the easiest to configure on the client side. If that’s not available, you can also tunnel all your traffic through an SSH connection. This is easiest to configure on the server side (no config). Here is an example of tunneling your POP service through SSH:

ssh -L 2110:pop.example.com:110 account@example.com

That’ll set up a local port 2110 that gets forwarded to “pop.example.com” port 110 (POP) after logging you in to some SSH account. This means you have to configure your POP client to use “localhost” port 2110 instead of “pop.example.com” on the regular POP port. And then you can only POP when your SSH connection is up.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

OSCON’s wireless network was okay. It didn’t seem to handle the load very well, but generally you could pick out an Access Point that was still responding to DHCP, and it would work well enough.

I feel like I’m beating a dead horse, but I’m appalled at how many people continue to not use encryption. I spent some time yesterday going through my 4.1G of packet capture logs. Generally, I scanned POP, SMTP, IRC, and HTTP traffic. I should probably find better tools than just ethereal, but after finding 45 different POP accounts that were authenticating in the clear, I stopped counting. That put me half way through Thursday, so that’s only a day and a half of OSCON wireless traffic. No one seems to protect their nick on FreeNode, so at least no one’s nick password was sent in the clear. One person logged into Flickr in the clear. One of the accounts was for the speaker I was listening to at one point. I recognized the POP account because it was up on his slides.

What’s really interesting is the number of people that didn’t authenticate in the clear but ran the rest of their traffic in the clear. For example, many people used various challenge/response systems to authenticate to POP, IMAP, SMTP, and AIM, but then all the traffic continued to stay in the clear. All their email and AIM buddy information was out on the wire.

I know there was at least one other person doing network sniffing, since I saw him running EtherPEG (which makes a live collage of all the incoming HTTP images on the wire). I started up a heavy download of images just for him, but I think he had bored himself with enless slashdot and oreilly GIFs and never looked back to see the fun I had sent over the air for him. :)

(If you don’t have a Mac and you want EtherPEG functionality, there is also DriftNet.)

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.