In case you were wondering, packet sniffing has everything to do with computer networks and nothing to do with getting high off of NutraSweet. Using a wifi connection under the wrong conditions is similar to pulling your pants and bending over to strangers. Using public wifi is the exact same, assuming you also tied your hands to your ankles . . .

Packets

Each computer network is a stack of protocol layers; the OSI network stack model actually has seven layers to represent the different network levels. When data is put out on a computer network, it's broken up into discrete units. When data is pushed from an upper layer to a lower layer, the original unit is encapsulated with some extra data at the lower level. As these discrete units travel down the layers they are called different things, but for the sake of our argument, we will call any discrete unit on the network a packet.

Sniffing

A computer must have a network adapter to connect to a network. In this day and age, that means an broadband Ethernet network interface card for the consumer, whether wired or wireless. In order for your computer to identify itself, the actual hardware itself comes with a unique identifier, the MAC address. Random Fun Time Fact: It's so important to the network that your network adapter have a unique identifier, one of the original ideas for generating the identifier was to copy the serial number from a $1 bill and then destroy the bill so that the number would never be copied on to another card. Unfortunately, that's a felony. Anyways, the MAC address and IP number are the main ways your computer is identified on a network. As far as incoming traffic is concerned, the IP number will route the traffic very close to your computer, at least in the right subnet. From there, a broadcast goes out on your local network to deliver the specific packet(s) to your MAC address.

The sniffing bit happens when a computer on the network picks up on traffic not destined for its own MAC address.

Identity Theft

So what actually happens is that every computer on your local network gets every packet destined for any computer getting inbound traffic on the local network. The only thing that keeps Computer A from getting Computer B's traffic is that A's network card discards all traffic not sent to its own MAC address. That system works great.

. . .for all of about fives minutes, until some geeks manage to tell their network adapter to grab other people's traffic. That's what happens when a NIC is set in promiscuous mode - all traffic that it sees is accepted, regardless of what MAC it was actually sent to. While this requires moving heaven and earth in Windows, it's very simple to do in Linux. Windows requires the WinPcap utility but daybreak's official position on that is "good luck." Linux has all kinds of fun toys like Wireshark (the successor to the GUI Ethereal) or the godly tcpdump.

The Problem

The security implications for this are horrendous. At the very least, if someone is conducting packet sniffing on your network they can see the URL you visit, read what the webpages display, read your instant messages as well as email, user names, passwords and file transfers. It's amazing how slack some web pages are, transmitting in either plain text or MD5 hashes, which may as well be plain text. Check it out:

0000  00 16 b6 28 7e 69 00 1d  7d 93 b1 8e 08 00 45 00   ...(~i.. }.....E.
0010  00 72 d0 51 40 00 40 06  4d c9 c0 a8 01 6e 40 0c   .r.Q@.@. M....n@.
0020  1a 49 9b 76 14 46 41 ba  cd 6f b2 8c 7b 64 50 18   .I.v.FA. .o..{dP.
0030  f6 87 00 61 00 00 2a 02  01 c4 00 44 00 04 00 06   ...a..*. ...D....
0040  00 00 00 00 01 05 33 31  31 39 39 31 30 00 00 01   ......31 19910...
0050  06 54 41 52 41 41 31 00  02 00 21 05 01 00 04 01   .USER_1. ..!.....
0060  01 01 02 01 01 00 15 00  00 00 00 6f 6b 2c 20 73   ........ ...ok, s
0070  61 79 20 73 6f 6d 65 74  68 69 6e 67 00 03 00 00   ay somet hing....

0000  UU VV WW XX YY ZZ JJ KK  LL MM NN OO 08 00 45 20   ..}..... .(~i..E
0010  00 d2 0d 4c 40 00 6b 06  e5 4e AA BB CC DD c0 a8   ...L@.k. .N@..I..
0020  01 6e 14 46 9b 76 b2 8c  82 65 41 ba ce a9 50 18   .n.F.v.. .eA...P.
0030  40 00 8b b8 00 00 2a 02  25 e0 00 81 00 04 00 07   @.....*. %.......
0040  00 00 8e 20 22 d1 35 37  31 35 39 30 38 00 00 01   ... ".57 15908...
0050  06 74 61 72 61 61 31 00  00 00 07 00 01 00 02 00   .USER_1. ........
0060  30 00 05 00 04 3f 45 60  d0 00 1d 00 09 00 01 00   0....?E` ........
0070  05 02 01 d2 04 72 00 27  00 04 48 5e 5c 35 00 0f   .....r.' ..H^\5..
0080  00 04 00 01 fd 77 00 03  00 04 48 5e 5c 34 00 29   .....w.. ..H^\4.)
0090  00 04 48 5e 5c 35 00 02  00 1a 05 01 00 04 01 01   ..H^\5.. ........
00a0  01 02 01 01 00 0e 00 00  00 00 73 6f 6d 65 74 68   ........ ..someth
00b0  69 6e 67 21 00 0b 00 00  00 13 00 01 06 2a 02 25   ing!.... .....*.%
00c0  e1 00 1d 00 04 00 14 00  00 8e 20 22 d2 00 00 00   ........ .. "....
00d0  00 00 00 00 00 00 01 06  74 61 72 61 61 31 00 00   ........ USER_1..

Looks pretty tricky, no? The raw data, all the hexadecimal, is what is actually captured. The left most column is just numbering; the rightmost column is the ASCII representation of what was captured. You can already see the simple message without complex analysis.

Oh, you want more analysis? Here's what Wireshark gives at the header for the second message, slightly truncated for size.

Frame 209 (224 bytes on wire, 224 bytes captured)
Ethernet II, Src: JJ:KK:LL:MM:NN:OO, Dst: UU:VV:WW:XX:YY:ZZ
Internet Protocol, Src: AA.BB.CC.DD, Dst: 192.168.1.110
TCP, Src Port: 5190, Dst Port: 39798 Seq: 1794, Ack: 350, Len: 170

First of all, I edited out the MAC address of both machines and the USER_1 IP address. My IP address was 192.168.1.110 in the above example; you're welcome to take it upon yourself to hack me there any day of the week. But the point is you can see how the weird hexadecimal is easily broken down to human readable elements, including source and destination IP and MAC addresses, the user name involved and the message that was transmitted among other things. And that's just from two packets captured. In the time it took me to sniff the above example, a total of 225 packets were captured in just under 300 seconds (mainly because I was not actively surfing or the number would be much higher).

Second of all, if I felt particularly malicious, I could start to interfere with the conversation taking place. Maybe change a message, inject some choice words, inject complete new words, masquerade as USER_2 to other users, etc. And that's just instant messages. What if this was email or some important browsing session?

The Good News

The good news is that this can only happen in certain cases. If you are connected to a network via a router, nobody on your local network can sniff your traffic. While this is true in the passive sense, aVheretic points out that you are still susceptible to MAC spoofing, where an attacker changes their MAC to match yours and intercept another user's traffic.* People beyond your local network may be packet sniffing, but that can't be helped. However, if you connect to a network through a hub, then someone could sniff your traffic very easily. This won't happen in home environments as much as it would in offices or perhaps libraries or other public terminals. Food for thought.

The Bad News

Actually, the title for this section should be "The 'Oh my God, I Just Shit My Pants' Bad News." All that stuff about sniffing your connection on a router versus hub only pertains to wired networks and the way those devices handle traffic. In the wireless world, every computer is broadcasting data to every other computer in cyber-earshot. It is no longer a question of who is on your physical wire, but who else is within 100 feet of you. Even when you're doing nothing, packets are sent out to check your email accounts, buddy lists, weather forecasts, etc.

Even if you are connected via a wireless encryption like WEP or a flavor of WPA, you're still at risk. Everyone else who has the wireless key can read your traffic. Furthermore, there are tools like air-snort and air-crack that are designed to blast the weak spots of traffic encryption and determine the encryption password. It's very easy to leave a laptop running with wireless packet sniffing software going full tilt in a backpack as you walk across campus, or downtown or even lying about in a cabinet somewhere. Just come back an hour or two later once you have a few hundred megs of traffic to read through for names, browsing histories, emails, instant messages or weakly encrypted packets so you can brute force the password and bust a network wide open. Hypothetically, I mean.

The first take home lesson here is NEVER, EVER trust a public terminal for anything. This whole writeup is disregarding trojans, viruses, keyloggers and all the like. We're focusing specifically on transmission security. Secondly, NEVER, EVER trust a public network for anything. Even if it's encrypted (especially with a publicly available key), WEP sucks and will not stand up to any significant attack. Most importantly, NEVER, EVER trust a public network with no encryption. Look back at the first paragraph for a vivid description of what that's like.

Light at the end of the tunnel

A surefire way to ensure transmission security is using SSH. I should make the distinction between using SSH on a public terminal as opposed to establishing an SSH connection using your own portable machine. If you have to type name, password and remote host into an SSH program on a public terminal, there is a chance that the information will be captured by a keylogger or other local software. You've pretty much lost the keys to the kingdom if this happens, but it's not the end of the world (just bring down the SSH server when you log out if this happens, but you wouldn't know it's happened, would you?).

Anyways, the safest way to use the public internet is setup an SSH tunnel on your laptop so that you get the benefit of a secure connection without the need of entering login details into a public terminal. SSH in no way guarantees that you cannot be packet sniffed, but it is very good encryption that will render all the captured packets useless to the attackers. In this case, the attackers just capture garbage. See the SSH tunnel writeup for a setup guide and explanation.

P.S. There are good uses

Just in case you were wondering about non-morally bankrupt uses for this . . . yes, this is a powerful tool for good. When you're writing software that acts as a network layer or sends messages directly to one of the network layers, it is imperative that you are able to see the raw data being written to the wire. If your application doesn't work properly, you have to know what's actually being sent. Alternatively, if you monitor the traffic into and out of your machine, you can keep an eye out for suspicious traffic. Someone may be poking at a port with a known vulnerability or a trojan may be 'phoning home' to some random IP in Russia. Lastly, um, it's kinda fun just to see what your computer is doing. Even if you aren't surfing the Internet or noding, a lot of information is being sent out from your computer. Buddy list updates, email, SNMP, ARP, RIP, ICMP, IGMP and a truckload of other protocols are talking to your computer. Don't you want to hear what it has to say?

---

*This is a valid threat when multiple users are on the same local network but it does not fit in to the theme covered in this writeup. Packet sniffing usually refers to capturing all traffic detected on a network, which is a passive attack. Other attacks like MAC spoofing and man in the middle are active and targeted as opposed to the passive and widespread threat of packet sniffing, especially in a public environment.