Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Detecting Spoofed MAC Addresses On 802.11 Nets

timothy posted more than 11 years ago | from the leech-reduction dept.

Security 18

Joshua Wright writes "I have written a white paper on detecting spoofed MAC addresses on wireless LAN's. This paper describes some of the techniques attackers utilize to disrupt wireless networks through MAC address spoofing, demonstrated with captured traffic that was generated by the AirJack, FakeAP and Wellenreiter tools. Utilizing the techniques I describe, it is possible to identify users who utilize spoofed MAC addresses on 802.11 networks to launch denial of service attacks, bypass access control mechanisms, or falsely advertise services to wireless clients."

cancel ×

18 comments

Sorry! There are no comments related to the filter you selected.

First Post! (2, Interesting)

DarkKnightRadick (268025) | more than 11 years ago | (#5140967)

Can these methods be used on traditional wired lans, or is the techniques different for spoofing on a wireless lan?

First RTFA (0)

Anonymous Coward | more than 11 years ago | (#5141074)

Hey - read the %#^%^ article! If you did, you would understand that it only applies to WIRELESS LANS, much like the article summary stated.

Re:First Post! (2, Informative)

thebigmacd (545973) | more than 11 years ago | (#5141077)

From the amount of the whitepaper I skimmed through, it looks like this could be used over copper, but the type of attack that it detects is rare or non-existant on copper because of the inherent difficulty of taking down a single client with DoS without taking down the entire network itself.

Re:First Post! (1)

DarkKnightRadick (268025) | more than 11 years ago | (#5141087)

Thanks. :-)

((Can someone tell my why my post was moderated as redundant?!))

Re:First Post! (1)

gmhowell (26755) | more than 11 years ago | (#5141119)

((Can someone tell my why my post was moderated as redundant?!))

I'm not sure, but I think someone said 'First Post!' yesterday. Maybe it was last week.

Re:First Post! (1)

DarkKnightRadick (268025) | more than 11 years ago | (#5141176)

But how does that apply to this discussion? lol

Re:First Post! (0)

Anonymous Coward | more than 11 years ago | (#5141533)

lol. The only people who say that are totally gay and stupid AOL people. Stop saying that. It's like walking around with a sign on your head saying "I'm Steve Case's bitch."

Re:First Post! (0)

Anonymous Coward | more than 11 years ago | (#5141121)

A: comment labeled first post is redundant in slashdot space
B: comment requiring the response to RTFA is redundant

No, for one important reason... (2, Informative)

Anonymous Coward | more than 11 years ago | (#5141108)

No, it will not apply to copper. The packet generation in 802.11x includes a counter. This counter is not present in the 100/10tx packets. The counter is generated at the physical (hardware level), and so when an intruder attempts to DoS a valid user and usurp the mac address, the counter cannot be changed to what the user's counter was...

UNLESS...........

the intruder either waits until the user's counter is about to flip back to 0, then DoS the user, and reset his counter, then spoof the MAC address. Or perhaps a virus or trojan could be written that would reset the valid user's counter somehow.

Re:No, for one important reason... (1)

DarkKnightRadick (268025) | more than 11 years ago | (#5141198)

Ah. Thanks for the info. :-)

Re:First Post! (1)

Permission Denied (551645) | more than 11 years ago | (#5143279)

Can these methods be used on traditional wired lans

No. One technique relies on a bug in a script to detect anonomolous MACs from script kiddies; not generally useful or applicable. The second technique is much more interesting and useful: it uses sequence number analysis to find spoofed MACs. This is, of course, not relevant to wired nets because ethernet has no such thing as a sequence number (only source, destination and type). This might be worth investigating as some places do use MACs for authentication (eg, you have to "register" your NIC with a username/password before being allowed out of a sandbox network - very popular in wireless nets, but also used occasionally on wired nets). Off the top of my head, I can't figure out any way to reliably detect MAC spoofing over ethernet (you just have very little to work with - you might try detecting when there is a too small time difference between one MAC sending from a jack and another, but then the attacker could just wait; or you could try using some higher-level protocol stuff, similar to what's used to detect when a card goes promiscuous, but those are just heuristics and can be broken; and there are also valid reasons for MAC spoofing (like VMWare)).

Also note that the techniques he describes are not foolproof. If someone knows an IDS using these techniques is in place, they could launch an attack as follows: 1. listen for a valid MAC; 2. send out some valid traffic using your factory-assigned MAC until your sequence number almost matches the target's (eg, keep hitting their authentication web page - might be difficult if the target is also active); 3. DOS the target using the few packets you have left until you meet the sequence number, or just use a second NIC to DOS the target; 4. take over target's IP, with no discontinuity in sequence numbers.

Still a very interesting paper.

good effort, but not quite what it seems... (4, Informative)

ubiquitin (28396) | more than 11 years ago | (#5142261)

Basically what this guy did was realize that the MAC-generation algorithm in spoofing software Wellenreiter [remote-exploit.org] has a weakness, namely that the OUI's it generates aren't all legit. (OUI is the organizational unique identified which is in the first few bits of the MAC address.) Also see helpful Sourceforge description of Wellenreiter [freshmeat.net] .

He similarly points out limitations in denial of service tools: AirJack [11ninja.net] and FakeAP [blackalchemy.to] software. However, this isn't the same as giving a general technique for analyzing MAC addresses on 802.11b, something which was strongly implied in the original post.

Re:good effort, but not quite what it seems... (0)

Anonymous Coward | more than 11 years ago | (#5143302)

Basically what this guy did was realize that the MAC-generation algorithm in spoofing software Wellenreiter ... However, this isn't the same as giving a general technique for analyzing MAC addresses on 802.11b, something which was strongly implied in the original post.

You didn't read the whole paper. The part with the bug in the script is only the first few pagers. Later in the paper, he goes into using 802.11 sequence numbers to detect spoofed MACs. I'm not even sure why he mentions the bug, as that's pretty trivial. The sequence number analysis stuff is far more interesting. It's not foolproof, but it could be very useful.

Re:good effort, but not quite what it seems... (2, Informative)

iangoldby (552781) | more than 11 years ago | (#5150033)

An anonymous coward wrote:

Basically what this guy did was realize that the MAC-generation algorithm in spoofing software Wellenreiter ... However, this isn't the same as giving a general technique for analyzing MAC addresses on 802.11b, something which was strongly implied in the original post.

You didn't read the whole paper. The part with the bug in the script is only the first few pagers. Later in the paper, he goes into using 802.11 sequence numbers to detect spoofed MACs. I'm not even sure why he mentions the bug, as that's pretty trivial. The sequence number analysis stuff is far more interesting. It's not foolproof, but it could be very useful.

I don't have mod points, so I've reposted it with my +1 bonus (since the Score:5, Informative parent post is wrong).

Re:packet frame sequence analysis (1)

ubiquitin (28396) | more than 11 years ago | (#5150731)

That's a really good point. I went back and read it again, but still stand by my previous post. The sequence number analysis techniques apply only to weaknesses in FakeAP and AirJack which will be easily modified on their part. All they have to do is follow the sequence control frames of their spoofing victim. The man in the middle attack described later is a better example of how sequence analysis could be useful, but it still wouldn't let the access point operator distinguish from an a attacker and the case where a legitimate user simply left the network and came back a short while later. This isn't a trivial problem to overcome on the part of the access point operator. (!)

The most interesting part of the paper to me was the section where Josh mentions that Lucent cards aren't following 802.11b specification in their sequence generation. And I highly agree with his recommendation in the final paragraph for access point vendors to add extra processing power to their hardware to accomodate security tools- such as sequence analysis tools. But it is a two way street, since doing so will give attackers more potential when they've succeeded with an exploit.

Re:good effort, but not quite what it seems... (1)

Trepalium (109107) | more than 11 years ago | (#5151807)

Correct me if I'm wrong, but isn't there another flaw in the implementation. IEEE OUIs are supposed to change the 23rd bit of the OUI portion of the MAC address based on if it's a locally administered address or a globally administered one. If an attacker can set all the bits of the network card MAC address, isn't that a mistake in the hardware?

Either way, wireless networks remain vulnerable...

Infinite Whitepapers (1)

Master Rux (458819) | more than 11 years ago | (#5143357)

Will the white papers never end. When will computers be secure enough that there are no vulnerabilities to write white papers about. Oh yeah never. I'm unpluging everything as soon as I get home. Spoof that!

Some interesting stuff, but... (0)

Anonymous Coward | more than 11 years ago | (#5169048)

What benefit is there in AP hijacking or DOS?
The paydirt is in snooping and with radio, it can
only be prevented via encryption of content.
Another 'pay' area is in after hours spoofing.
Anyone who orders merchandise using a credit card
numbee over an unsecure connection is in for
trouble. Heck, even over a secure connection,
it's 'iffy'. Grab the cookie, log on later, change
the delivery address for that nifty new geegaw.

DOS of 802.11b/g is easiest by brute force radio
intereference. It's in an unlicensed ISM band and
therefore must accept intereference from other
devices using those frequencies. A roadside find
microwave oven, some tinsnips, a pop rivet gun,
some aluminum flashing, and some jumper cable to
glom power and one can easily 'block' the wideband
receivers used in these a/g cards.

800W to a homemade horn for a few KW ERP at
2.4 GHz will shut 'em down until they find the
'disposable' transmitter...
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>