Friday, February 29, 2008

NSM and VLANs

Sometimes I run across a pcap-aware utility that does something very cool, but just doesn't work right when it encounters 802.1Q VLAN tags in traffic. Most commonly, it fails to recognize these packets as IP.

To see why, take a look at this diagram of a sample Ethernet II frame. Most simple-minded code simply checks bytes 12 & 13 (the EtherType field) to see if they contain 0x08 0x00, which is the code for IPv4 traffic.

However, 802.1Q tags throw things off a bit. If present, the tag occupies an additional 4 bytes between the source address and the EtherType field. The first two bytes are a standard code for VLAN tags, 0x81 0x00. Then the following two bytes are an arbitrary numeric value identifying which VLAN the traffic belongs to.

The code is often something like:


if(etherframe[12] == 0x08 && etherframe[13] == 0x00) {
/* Process an IP packet */
}

Adding VLAN support simply involves an extra check. For a quick and dirty solution, if the VLAN tag is present, I usually just adjust the pointer to the beginning of the frame's data (etherframe, in the above case) by 4 bytes, then proceed as usual.

In most cases, this has the desired effect, but it does mean that I'm throwing away all VLAN tag information. In my experience, this has only been a problem once, on Shmoocon's "hack or halo" network, where each participant's computers were on a unique VLAN but had identical IPs. In the real world, I have never seen this, but I'm certain it exists somewhere.

In the meantime, if you can live with this restriction, you can try out some VLAN patches I wrote for PADS, tcpflow and tcpxtract. You may also want to check out this wiki page which tracks VLAN support in various libpcap-based analysis tools.

Wednesday, February 27, 2008

The awesomest

This is the awesomest thing I've ever heard on the Internet. Some guy recorded a 10 minute phone call with a phisher. My favorites are the wife, the FBI and the 357.

This is SFW, though there are two or three things bleeped out.

Go ahead, get pwn3d, you've got Norton.

So I open my inbox today and find an e-newsletter from Symantec. Normally, they barely register with me, and I just delete them an move on. This one though, had a great subject line:

Go ahead, You've got Norton


Really? That's the idea you're going with? It's safe to open that attachement/click on that link/view that malicious site, just because you've got Norton AV?

I know this was probably written by a marketdroid, as I sincerely doubt that the Norton AV product engineers would encourage you to engage in risky Internet behavior no matter which AV product you've got installed. Still, you'd think that someone, somewhere, when planning their marketing strategy, would notice the fundamental disconnect between that slogan and any actual good security practice.


As Richard Bejtlich is fond of saying, prevention eventually fails. C'mon, Symantec. How can you expect customers to trust your product if your own marketing efforts display an ignorance of fundamental security principles?