Fingerprinting Wireless Drivers

jfleck writes with news that researchers at Sandia National Laboratories have released a paper on a technique they have developed for passively fingerprinting wireless device drivers (PDF). The researchers comment, "This technique is valuable to an attacker wishing to conduct reconnaissance against a potential target so that he may launch a driver-specific exploit." They sketch the loose language in the 802.11 standard describing the way client devices should probe for access points. Because probing is not spelled out in any detail, the authors say, "...implementing active scanning within wireless drivers [is] a poorly guided task. This has led to the development of many drivers that perform probing using slightly different techniques. By characterizing these implementation-dependent probing algorithms, we are able to passively identify the wireless driver employed by a device." This technique beats Wi-Fi Fingerprints by a country mile.

Um.

[Lord Aurora]

This technique beats Wi-Fi Fingerprints by a country mile.

Because beating them by a city mile just wasn't quite enough.

Re:

[Architect_sasyr]

That's because 100m's aint that far for an hour travel ;)

easy way

[Lehk228]

if it blows up to 300 megs in a day or two it's an intel driver

Re:

[Tyger]

Bravo, you linked the same past story that the summary linked and commented on this technique being better than. Yes, it does look similar, but you can figure out the differences just by reading the summary, let alone the article.

That said, I'm sure more ways will be discovered to fingerprint wi-fi devices. I do hope at some point soon it will stop being newsworthy when a new one is discovered.

Re:

[couch_potato]

Who reads the articles? Really, a quick skim of the summary is all that anyone needs to make gross assumptions about the content and meaning of the article.

Cool links. [blogspot.com]

By a country mile?

[fatboy]

They are not the same thing. One is for dectecting the type of client, the other is for detecting a specific client.

Error: Incompatable Types

[Kesch]

I'm not sure why the submitter brought up WiFi Fingerprinting since these two techniques address different issues. The technique described in the pdf refers to identifying a device driver by categorizing the probing algoritm used. Because the 802.11 spec is loose regarding the probing method, implementations between drivers are inconsistent enough to spot the differences using passive scanning. This allows attackers to then exploit the known vulnerabilities in the specific driver.

OTOH, WiFi Fingerprinting monitors the fluctuations in the radio output caused by minute differences in the hardware(.04% differences between transistors, etc.) which give every single piece of wifi hardware a unique signature. Personally, I'd say that WiFi fingerprinting is cooler and useful for something other than hacking since it can defeat MAC spoofing. I don't know why the submitter thinks that determining the driver used instead of unique characteristics of the hardware is better by a country mile.

Re:

[russ1337]

Additionally, the method described in the article also pertains to wired networks. Each manufacture and each version of a driver will return slightly different results to network probes, allowing you to identify the exact driver thus exploit its flaws. The mention of wireless, as you correctly point out, has made people confused with Emmitter fingerprinting, which in the electronic warfare world is called Specific Emitter Identification (SEI).

idiot

[Dun Malg]

This technique beats Wi-Fi Fingerprints by a country mile.

Yes, because no two people are using the same driver. Moron.

Parallel research

[Pheersome]

Given a quick skim of the Sandia paper (and a closer read of a couple of the important sections), it looks like these Sandia group got results roughly similar to a portion of the work that Maynor and Cache presented [11mercenary.net] (sorry, PPT) at BlackHat and DefCON. From what I can tell, the techniques used by Maynor and Cache were a little more ad-hoc than the Sandia group's machine-learning approach, but unless they write up their results with more depth than a Powerpoint presentation, doing a strong comparison is sort

Re:

[jnf]

Send Cache an email, he has something much better than a PDF or a PPT, he has code implementing 802.11 device driver fingerprinting.

Ways to Prevent Fingerprinting

[Kesch]

TFPDF lists some ways to prevent this attack vector.

• Configurable Probing
  Drivers should include this one anyways to be nice to laptop users. Give the users control of wether active probing is enabled or not. Access points send out announcements by default so you should be able to passively find most access points while conserving power and remaining unidentifiable.
• Standardization
  Just make the time frame duration for probing requests part of the 802.11 standard and this problem goes away.
• Automated Noise
  They say that this isn't a good solution since you'll eat up more power and bandwith. Additionally, signal processing algorithms are getting good at filtering out noise.
• Driver Code Modification
  For the hacker elite. Get your own copy of some OSS wifi drivers and modify the timing in the probing algorithm so that you have your own unique fingerprint and no one knows what the heck you are running.
• MAC Address Masquerading
  Another not so great solution. Their detection method maps the radio signal to your MAC. So if you have two devices with the same MAC both within scanning radius of the fingerprinter then it will get messed up. Still, not a real solution.
• Driver Patching
  One of the weaknesses of the fingerprinting method is that it cannot tell what version driver you are running. More secure drivers and better driver patching mechanisms will narrow this attack vector in the future.

Re:

[merreborn]

Driver Patching
One of the weaknesses of the fingerprinting method is that it cannot tell what version driver you are running. More secure drivers and better driver patching mechanisms will narrow this attack vector in the future.

That's only true assuming the probing method doesn't change between patches. Granted, usually it *won't*, but there are probably going to be cases cases where does.

Why Bother?

[loose electron]

Why are they wasting their time on this? 802.11 is "reasonably secure" for something that is only designed for 30 meters of distance.

You want tight security on something? Disconnect all the transmitters, receivers and ethernet cables. This is an utter waste of government money...

Oh... so ***that's*** why they are wasting time on this...
Government funded research in a government run lab. Better to give the money to universities, at least there useful things (sometimes) happen.

Re:

[robbak]

Um, what? 802.11n has takes that up to 50 metres, and we all know that a good directional antena can pick up signals from a great distance. And there is no reason to think that somone attempting to crack a system will use legal wattages to do it! I hope I am not feeding a troll here....

Re:

[zippthorne]

Actually there's a very good reason to assume they will use legal wattages. If their transmitters are above legal limtit, their recievers will not be sufficient. They could overpower an installation using illegal wattages, but if they want to hear it, they can't rely on transmit power.

Re:

[BLKMGK]

While it might have been designed for 30 meters it has been braodcast as far as 124+ miles UNAMPLIFIED. That's a full link at 10megs using 802.11b. Yes large directional antennas were used on both sides of this connection. However it very clearly demonstrated that with a proper antenna you can go FAR further than the design specified. A mile or three with a reasonable antenna isn't beyond reason so I wouldn't get too comfortable with the 30meters thing...

I may be missing something, but ....

[RallyDriver]

.... this doesn't seem to add a lot of practical value for an attacker.

A table of MAC address ranges and manufacturers would yield a much more specific data point about the hardware, implying a short list of potential drivers.

I guess it does give you the added info of a potential OS id (Linux / OSX / Windows) but in the typical scenario of a public (unencrypted) wireless system, sniffing application layer data (an HTTP User-Agent header springs to mind) provides a more precise way to get that data.

Re:

[pasko]

I think you're right, however, sometimes there's no traffic between client and AP, and higher level application data is simply not available.

OTOH, I'm surprised (and happy) to see that my ubuntu is able to use the broadcom's reverse-engineered kernel driver + kismet to make passive sniffin'with very good results. This is something that even the windows driver is not able to do.

Those pesky drivers!

[autophile]

Man, I really get a burr up my backside whenever I think about all those motorists using cellphones and then not getting fingerprinted...

...oh.

Never mind.

--Rob

Some info

[anildip]

I am kind of new to this but based on some research on this topic which i got from the internet to share with you, it seems that video and keyboard drivers are generally not exploited because of the difficulty in attaining physical access to those systems, leading some to beleive device drivers are also immune to vulnerabilities. However physical access is not necessary with some classes of drivers, including wireless cards, Ethernet cards and modems. A hacker need only be in relatively close physical proxi