Slashdot Log In
The Black Hat Wi-Fi Exploit
Posted by
ScuttleMonkey
on Wed Aug 09, 2006 12:22 AM
from the plot-thickens dept.
from the plot-thickens dept.
Joe Barr writes to tell us that while many have heard that an Apple was exploited in order to install a rootkit at the recent BlackHat security conference, most people don't know the details of how it works. This is no mistake, it seems that the researchers who demonstrated the flaw were intentionally vague. Some theorize that this is in response to the real or perceived threat of legal action similar to the situation with previous Blackhat presenter, Michael Lynn.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Atheros at the exploiter side? (Score:4, Interesting)
Re:Atheros at the exploiter side? (Score:2, Informative)
Re:Atheros at the exploiter side? (Score:4, Interesting)
The Atheros exploit shores up OpenBSD's [openbsd.org] stance on binary "blob" drivers perfectly. EVERY OS using these binary drivers are vulnerable. OpenBSD refused to include blob, reverse engineered the drivers and wrote their own secure drivers.
End result? OpenBSD is secure while most other OSs out there are at the mercy of Atheros.
Parent
This seems a bit misleading... (Score:5, Insightful)
Re:This seems a bit misleading... (Score:5, Insightful)
Making the details vague, especially by not telling which card to avoid using, makes the users unable to do anything to prevent being victims. That very much GIVES the attackers the upper hand.
Without knowledge, the users are defenseless. Heck, I have a laptop here with a built in wifi-card. So does everyone else in the office. If I knew the card was a risk, putting in a different card would make me safe. But as it is, the built in one could be safe and the one I would put in instead could be the risk. Heck, I don't even know if disabling the card through software solves anything. If the exploit really works on any OS, it doesn't sound like a software problem, but a hardware/firmware problem.
The only thing being protected by not informing the users is the image of the manufacturer.
Parent
Re:This seems a bit misleading... (Score:3, Interesting)
if you were aware of the (limited) details that have been released, you'd know that while the vulnerability that the presenters (Jon Ellch and David Maynor) used was vendor specific, it still worked on the macbook's internal airport card [arstechnica.com]
The demonstration was not really intended to point out the specific problem with these mac drivers. It was more intended to highlight several industry wide problems.
I'm not about to say that letting consumers know about these problems will help or hinde
Re:This seems a bit misleading... (Score:3, Informative)
Re:This seems a bit misleading... (Score:3, Interesting)
Re:This seems a bit misleading... (Score:5, Informative)
You can throw money at me instead, if you feel the need.
Parent
Re:This seems a bit misleading... (Score:3, Informative)
Re:This seems a bit misleading... (Score:3, Informative)
For those attackers that can replicate the exploit, yes, it does. However, in some cases, it can be considered ethical to not release the information.
For example, I took a wireless security class led by Joshua Wright, who some may know as the creator of several wireless attack tools such as asleap and lorcon (the lat
don't be so sure (Score:3, Interesting)
If I can take over the card's internal CPU (probably running a tiny real-time OS) then I can use that to write anywhere in memory. I can patch any part of your kernel I like. It doesn't matter if your driver is good or not.
Flogging a dead Story (Score:5, Insightful)
ScuttleMonkey writes to tell us that apparently the 'plot-thickens' as some guy somewhere emailed that some people are 'theorizing' alternate motives for the Blackhats keeping wraps on their so-called 'exploit' (that they tried unsuccessfully to smear a OSX security with).
There is no new substance. This bone [slashdot.org] has been gnawed clean already. Sounds more like some people are making excuses for something...
Re:Flogging a dead Story (Score:5, Insightful)
Parent
Re:Flogging a dead Story (Score:5, Interesting)
Intel PRO/Wireless Network Connection Drivers Remote Code Execution Vulnerabilities [securityfocus.com] . Look at that, a remotely exploitable security hole in the Wifi driver. Anyone using one of these things is vulnerable if they have not upgraded their Wifi drivers, regardless of OS. This was disclosed by the vendor (Intel).
I guess you were right. No facts, just theories.
Parent
Re:Flogging a dead Story (Score:3, Insightful)
Re:Flogging a dead Story (Score:2, Funny)
This is news? (Score:5, Funny)
Slow news day, I'd say.
dang! (Score:4, Funny)
what a load of crap (Score:3, Interesting)
That's why in the video they used a "generic" wifi card when they admitted the standard apple wifi driver is broken as well
They said they haven't released the code because "they need to check all the apple platforms that are effected" IE they are waiting for apple to deliver them a whole bunch of free hardware
These guys were complete sell outs -- no live demonstration because they were afraid that the WIFI would be sniffed at DEFCON..... so coming to a full disclosure conference they are basically saying they don't trust disclosing to the attendees...
In the video they call the script "bad seed" so it's probably something to do with a PRNG in the crypto somewhere (or IV)
Re:what a load of crap (Score:2, Informative)
I've got a Sonnet PCMCIA card in my PB400Mhz who's chipset is the same as the Apple Extreme Card, when I plug it in, it's found as an AirPort card and I had nothing to install to make it work!
Sad thing is, it's supposed to work on Windows 98/ME/2K/XP, but I did'nt manage to do so yet!
Can anyone confirm... (Score:3, Interesting)
Re:Can anyone confirm... (Score:2)
Re:Can anyone confirm... (Score:2)
Video of the exploit (Score:2, Informative)
Wifi Card used in exploit (Score:4, Interesting)
Not an apple wifi card. (Score:2, Informative)
So, which card was it? Considering that most companies only threaten legal action, and researchers usually ignore the threats, a good guess that this is a company that is known to not only threaten. One that ISS had problems with before. In short: I bet it was a Cisco card. Not
Re:Not an apple wifi card. (Score:2)
Re:Not an apple wifi card. (Score:2)
Whoever says something about security gets blame for "snake oil", "paid by micro$oft" and other things. Even poor BBC blogger guy got shocked by the response he had from Mac users not so long ago.
Well That's a Biased Article (Score:5, Insightful)
Now there are reasonable people who believe this increased danger is pretty much always offset by the benefits of public knowledge of the risk, i.e., a vulnerability you know about is sufficently less risky to justify disclosure. However it is disgustingly biased and misleading to not even acknowledge that some people and companies might reasonably believe total public disclosure harms the end customers. This is especially true when we are talking about the difference between revealing the existance of the exploit and revealing info that might enable someone to copy the exploit.
Moreover, I didn't see the slightest evidence that it was outside pressure that caused this pair not to reveal the details. The tone of this [com.com] cnet article seems to imply they made the choice themselves to be responsible which seems totally reasonable.
Also I don't understand who would put this pressure on them unless it is the network card manufacturer. Macs, linux and windows machines are supposedly all affected so no one company would take a PR hit relative to others. Unlike the case with the cisco vulnerability.
Yes it's true that vendors tend to be biased toward maintaining their good name. Just like real people they tend to be biased toward the answers that help them out but this is hardly dastardly. True I think they sometimes go to far and chill free speech and harm security research but this seems fairly rare and I see no reason to believe it is happening here.
Equal opportunity sploit (Score:5, Interesting)
Bottom line, assuming the demo is not a hoax, it will work against *nix, Windows, and Mac equally.
Re:Equal opportunity sploit (Score:3, Insightful)
Yep, and we still haven't been told which card driver they installed.
That it wasn't the one Apple provided should be obvious - they would have used the buildin Apple Wireless, then.
k2r
Re:Why not demo it on multiple platforms then? (Score:3, Informative)
So no, it's not speculation that exploitable on other platforms, because the presenters themselves said it was, and specifically said they ultimately chose to demo it on the Apple platform for the reason stated above.
On that note, though, I do agree that the reasoning to use a third-p
The real problem (Score:3, Insightful)
However, these guys have given almost no information about the hack, making it impossible to protect yourself. Does your wireless card have problems? Do all wireless cards have problems? What can you do to protect yourself? Should you avoid using wireless at all? Is it a remote hack that can actually somehow enable the wireless card (through a secret back door or something)? We don't know. And by keeping these details secret, companies are hurting end users.
It is good to let the company create a fix before the exploit is released, but it is also good to give the user enough information to defend himself.
Re:The real problem (Score:2)
Was it root (Score:3, Informative)
My main reason for believing that he had the logged in user's access is due to the fact that wireless is not system wide on Apple, but is started when a user logs in. If you change users(fast user switching etc...) then all your network connections drop as the wireless is restarted with the new user.
Re:Was it root (Score:2)
Re:Was it root (Score:3, Informative)
Re:Was it root (Score:2)
So discuss it at DefCon but not on Slashdot?
This was a kernel-level (as it was driver-based)
This is a microkernel which places lots of drivers in the user-space. I still believe it is valid to ask for a demonstration of touching something of real value on a system.
There is absolutely no root v user shell debate in this exploit.
Show me a demo of them doing root activities... until then I give you nothing.
Re:Was it root (Score:3, Interesting)
In essence, based on my understanding of the exploit and the way the 802.11 device drivers work, the shellcode exploit is actually executing in the kernel. It's executing below the point (On the OSI model) where a root v non-root account would make any difference. I'll grant that a demo of root activities would be more visual, but I believe that academicall
Re:Was it root (Score:3, Insightful)
WHO has theorized? (Score:4, Insightful)
Occam's razor (Score:5, Insightful)
attention (Score:2)
Methods of Disclosure (Score:3, Informative)
I'm not buying the people who are upset at a lack of full disclosure because they are "unable to protect themselves". If there was a way to protect yourself, sure, perhaps you could tell people how to do it. However, judging from the presentation itself (at Defcon), there really IS no way other than mutilation of the driver itself (see the slide with the nintendo DS) to quickly defend one's system. Not only would this significantly break a lot of things, most users wouldn't know the first thing about doing it.
The root causes as outlined in the presentation were a combination of a poorly planned and thought out protocol (802.11) and a quick-to-market rash of sloppy driver implementations, and it's going to take nothing less than at least a driver patch (or in a fantasy world, an overhaul of existing wireless protcools...802.11 lite if you will).
So quit accusing the presenters of being motivated by greed, stupidity, or other such notions - the best way to secure users at this point is to speak with the manufacturers directly and attempt to achieve a patch, not to detail how to break in to every last miscreant on the planet. The authors are starting to do this by their dealings with Apple.
Oh, and for those of you that missed the FAQ at the end of the presentation:
-Yes, it affects the kernel, which means it's >= root/Administrator on any system
-It's a driver/spec implementation issue, which means it's not an OS-specific problem. The use of an Apple machine in order to show that "any" platform is at risk was meant to illustrate this.
-The money slide was a joke meant to show how lightly many people were taking this issue. I have no way of proving the intentions of the presenters, of course, but I believe this was the case - they stated their intention was to get this problem addressed through discussion, not money.
All in all, easily my favorite defcon session (unless you count the shots of 151 distilled through peppers). Thanks, guys!
When to disclose exploits (Score:3, Informative)
This exploit was kept underwraps to allow vendors to release security fixes before the exploit spreads to every two-bit kiddy scripter around. It doesn't make much sense releasing information on how to implement this exploit when there really isn't too much you can do to stop it. It's the reason why the presentation was done on video and not live.
Of course, once the exploit is known to exist, it is only a matter of time before someone else finds it and implements it. I already know at least one person who is on his way to duplicate it, so the vendors better hurry up and fix the security hole. Apple and Microsoft can't take their merry ol' time fixing this one.
Really, look we know how to make a bomb... (Score:2)
See, you take some playdough and mash it up until you have this nice grey colour, and then you poke some wires it in and add batteries.
See? Watch this video and you'll see it go boom.
(Show video with big explosion).
See? We have to ban playdough as it's dangerous.
That is about the credibility of using an add-on card to prove that there is an available exploit in a particular laptop that has built in wireless. It doesn't matter if it's true or not, they presented it i
Re:Still fishy... (Score:5, Insightful)
This is not a simple matter of exploiting a serivce. The machine might does not even need any publicly accessible services for this attack to be effective.
We all know that wireless cards require soft firmware and drivers in the OS these days. The point is that it's possible to exploit the drivers with specially crafted packets and make the OS run arbitrary code that it thinks is the Wireless driver.
Running code at the level of the OS brings with it full control over the machine. The OS trusts the drivers 100% on almost every system I've used. This means your newly running code can take full control of the machine, and probably even download more code, sniff on you, etc.
It should be possible to exploit this attack even if the machine is connected to a trusted network. All you need to do is send it packets on that network (or pretend to be on that network).
The demo might have been vague, but it still points out some serious flaws with wireless systems on modern operating systems - anyone can send you packets and the OS trusts the software processing those packets 100%...
Parent
Re:Still fishy... (Score:4, Interesting)
That is the claim being made, and it would be frightening if true. We have not seen any reliable evidence of this so far.
''We all know that wireless cards require soft firmware and drivers in the OS these days. The point is that it's possible to exploit the drivers with specially crafted packets and make the OS run arbitrary code that it thinks is the Wireless driver.''
That is the claim that has been made. We have not seen any reliable evidence of this so far. I think it would be quite easy to own a Macintosh running MacOS X if you use an external card needing a driver, and you install your own, specially crafted driver on the machine that will do exactly what you want. We have no evidence that this works when using the preinstalled Apple driver or the manufacturer's driver for the card.
''Running code at the level of the OS brings with it full control over the machine. The OS trusts the drivers 100% on almost every system I've used. This means your newly running code can take full control of the machine, and probably even download more code, sniff on you, etc. ''
May be true, but there is no evidence that you can take control of a driver as it was claimed.
''It should be possible to exploit this attack even if the machine is connected to a trusted network. All you need to do is send it packets on that network (or pretend to be on that network).''
And possibly go to the machine you want to exploit first with a CD in your hand, and install your replacement drivers.
''The demo might have been vague, but it still points out some serious flaws with wireless systems on modern operating systems - anyone can send you packets and the OS trusts the software processing those packets 100%...''
The demo may have been vague because it was a hoax. So far this seems much more probable to me.
Parent
Re:Still fishy... (Score:2, Informative)