Garbled data in 802.11 management frames - missing FCS check?

[maximcherny]

It appears that sometimes (rarely, bit still often enough to be inconvenient) Scapy-based probes and beacons sniffing engine is fed garbled data. By garbled I am referring to:

• SSIDs that contain invalid char sequences
• MAC addresses that cannot be matched to a known vendor (even when using the most up-to-date - refer to Provide the ability to update the MAC vendor lookup listings #6)

While I assume the root cause is external to Scapy itself - e.g. noise / interference, Scapy does not offer a mechanism to ensure that only the frames that pass the Frame Control Sequence (FCS) check are processed.

There is a proposed patch dating back some years here:

http://bb.secdev.org/scapy/issue/109/incorrect-parsing-of-80211-frame-with

I haven't tested the patch myself, but first of all would be interested to find out whether you share this concern.

Being able to capture reliable (read - discard garbled) data is a must-have requirement for me, which means I am facing the possibility of switching to a custom tshark-based 802.11 frame capture plugin. Unfortunately, this also means more CPU + memory usage to run an additional process.

Have you experienced this issue throughout your data collection?

[glennzw]

I should have listed this in the bugs section - certain wireless cards are prone to this, for example the TPLINK TL-WN722N. Other cards, like the Alfa Awus036h seem to perform better. I spent a lot of time last year trying to implement the Wireshark FCS algorithm from C (in Wireshark) to Python to patch Scapy, but didn't succeed in the end. Read my question on the Scapy mailing list here:

http://comments.gmane.org/gmane.comp.security.scapy.general/4918

And the Wireshark C code for the FCS:
https://gist.github.com/glennzw/6365693

I'm trying to find my Python FCS implementation (that was not quite working) to see if you'd have any insight into fixing it. I think it's on a VM back at home, I'll check and update this thread when I find it.

We'd add this to prefilter.py (https://github.com/sensepost/snoopy-ng/blob/master/plugins/mods80211/prefilter/prefilter.py) You can see the dirty hack I've got in there at the moment.

Also, I've recently discovered Impacket:

https://code.google.com/p/impacket/

It has native support for FCS checking, and potetially better performance than Scapy. Well, I'll re-implement and compare performance.

[maximcherny]

Yes, TP-LINK - exactly what I'm using in my tests. Happy to check out the Python FCS implementation if you can resurrect it.

Impacket looks very promising indeed, I haven't seen that before myself.

I've actually got a tshark-based probe and beacon sniffing PoC here in the meantime:

https://github.com/maximcherny/snoopy-ng/blob/headway/plugins/tshark.py

If you are interested in pulling that in that please let me know. This one does not deal with handshake capture or cookie snarfing though.

[glennzw]

That'd be useful to have as a separate plugin perhaps - wifi-maxim or some-such?

[maximcherny]

Going back to this - using scapy_ex it is also possible to determine the presence and the value of the FCS flag, I have got working code here:

https://github.com/maximcherny/snoopy-ng/blob/headway/plugins/mods80211/wifi_clients.py

if p.Flags is not None:
    if p.Flags & 64 != 0:
        self.droppedCount += 1
        fcs = 0
    elif p.Flags & 64 == 0:
        fcs = 1

However, I've collected almost 3 million probes and the flag only appears in roughly 75% of the data, remaining unknown for the rest. While it can be an improvement, it's not a silver bullet. Happy to organise a pull request.