[Previous entry: "HTML O' the Day"] [Next entry: "More on that 'security flaw'"]
08/03/2006: "Don't take your guns to town"
[updated Saturday evening following a very kind email message by "TjL (a) fomer English major w/ too much free time and insomnia" who corrected several errors in the original. Small amount of additional material added to clarify some positions. --jim]
Ah, I'd love to wear a rainbow every day,
And tell the world that everything's OK,
But I'll try to carry off a little darkness on my back,
'Till things are brighter, I'm the Man In Black.
So there is this "Hack into a Mac wirelessly" attack that is making the news these days.
Jon "Jonny Cache" Ellch and David Maynor showed a video at DEFCON earlier today, demonstrating the attack. Many people opine that the reason for the video (rather than a live demonstration) is that Ellch/Maynor don't want to expose the details of the attack by having someone 'sniffing' in the room @ DEFCON. Others say the attack isn't real, that Ellch and Maynor have somehow "staged" the attack. I think this opinion is closer to the truth, though I believe that Ellch and Maynor have real frames flying through the ether. That is, while others believe it is a fake film, I belive its that they are afraid of being exposed as frauds because if they exposed the details, everyone would walk away in disgust, because it's a trivial, straight-forward "we have code running in both machines" style of attack.
Glenn Fleishman writes in "My Guess on the Wi-Fi Exploit":
> A specially crafted beaconing frame is the only method I can
> conceive of in which a computer that is otherwise not engaged in
> specific behavior, such as connected to a network or connecting to
> one, could be attacked, and thats what the researchers claim can
> happen. Other thoughts?
Yeah, I have other thoughts...
The IEEE 802.11 standard requires all stations to listen to and honor many types of frames while in "State 1" (unassociated & unauthenticated).
Quoting:
The current state existing between the source and destination station determines the IEEE 802.11 frame types that may be exchanged between that pair of STAs (see Clause 7). The state of the sending STA given by Figure 8 is with respect to the intended receiving STA. The allowed frame types are grouped into classes and the classes correspond to the station state. In State 1, only Class 1 frames are allowed. In State 2, either Class 1 or Class 2 frames are allowed. In State 3, all frames are allowed (Classes 1, 2, and 3). The frame classes are defined as follows:
a) Class 1 frames (permitted from within States 1, 2, and 3):
1) Control frames
i) Request to send (RTS)
ii) Clear to send (CTS)
iii) Acknowledgment (ACK)
iv) Contention-Free (CF)-End+ACK
v) CF-End
2) Management frames
i) Probe request/response
ii) Beacon
iii) Authentication: Successful authentication enables a
station to exchange Class 2 frames. Unsuccessful
authentication leaves the STA in State 1.
iv) Deauthentication: Deauthentication notification when
in State 2 or State 3 changes the STA’s state to
State 1. The STA shall become authenticated again
prior to sending Class 2 frames.
v) Announcement traffic indication message (ATIM)
3) Data frames
i) Data: Data frames with frame control (FC) bits “To DS”
and “From DS” both false.
(end quote)
So the attack could be sending unsolicited RTS or CTS frames, perhaps with some very strange parameters. The problem here is that these (and ACK frames) are typically handled by the firmware or (in the case of Atheros and similar parts), directly by the hardware. Software generation of these frames is possible, of course, though typically not so if we limit the implementation to generating CTS and ACK frame in response under the strict timing of the 802.11 MAC protocol.
It could be CF-END or CF-END+ACK, or it could be malformed beacons, as Glenn states. It could be unsolicited probe-response frames (i.e. without an associated probe request), or it could just be data frames with both FC bits cleared. I believe this last possibility is the most likely.
The thing that suprises me about this (if its Macbook Pro specific, as Glenn states, though it is a (non-Pro) Macbook used in the video) is that the Atheros card driver from Apple is based on the well-understood "net80211" layer in FreeBSD (a very similar layer exists for linux in the 'madwifi' driver), yet the attack apparently doesn't work there.
Presumably the same attack works on the iMac and mini as well, since they both use the same Atheros part, and the same driver.
More likely: it doesn't. In the presentation, Maynor uses a "third-party wireless card". It looks like a ExpressCard/34 802.11 card, but the non-'Pro' Macbook doesn't have Express Card slots, and the card they hold is too big to be a USB device, yet the Macbook they use is definitely black.
Something is already smells like day-old fish.
In any case, why in the hell did they use an external card? Word coming out is that "Apple pressured them" to not show the attack working on an Airport card, but this has to be bullshit. Maynor stood up to Cisco last year, and got sued for his trouble. Why would he now not stand up to Apple? No security researcher knuckles under to strong-arm tactics without watching his credibility be destroyed.
Quoting the video, "The thing to keep in mind here is that although we attacked an Apple, the flaw is not specifically in the Apple Operating System, <someting uninteligible> ("having?") third-party hardware..."
Horatio: "He waxes desperate with imagination."
Marcellus: "Let's follow; 'tis not fit thus to obey him."
Horatio: "Have after.-- To what issue will this come?"
Marcellus: "Something is rotten in the state of Denmark."
I find it too likely that Ellch and Maynor wrote their *own* driver for the victim machine, and once they have their *own* AP (the other notebook in the video), they're running their *own* code on both ends of the link. Using this code, they can create a covert-channel, using one of the "Class 1" frames detailed above (which will potentially be passed to the driver, with the data intact.)
To reproduce the attack, we need an 802.11 ExpressCard/34, we'll use Google to see what's available:
http://www.gemtek.com.tw/pro_wpcb_143g.htm:: Broadcom. Click here if you don't believe me.
The Dell 1390 is a Broadcom-powered ExpressCard, but it doesn't have skins, or the right connector.
another Broadcom ExpressCard/34
and a pre-802.11n Express card (Dell 1500)
"... I sense a disturbance in the force ..."
Atheros-powered ExpressCards are available too, though these also lack the skins and appropriate ExpressCard connector.
Still, such cards are available, and the point is that these guys could have hacked their own driver, and probably did. They essentially admit that they have in the video. Once they have the driver they then turn to using a rogue AP (with special software on it, though this software is widely available). Using the combination of software on both sides of the link they simply send the frames they want over a covert channel. Once again, this is a cover channel that they planted in the "hacked" driver on the Mac. This stunt is also possible on Windows machine, if the firmware in the card passes class 1 frames to the driver as it must to be in compliance with the IEEE 802.11 protocol. Its also possible linux box, or but here they have a new problem in that they first have to move any driver that wants to claim the card to the side. The difference between Linux/FreeBSD and MacOS/Windows is that the former set ships with drivers for a lot of 3rd-party cards, and the later does not. Demonstrating their trick on a linux box would immediately set many more people in a suspicious mode, because on linux, most of the drivers are available as source code, and therefore easily modified.
But let's say Maynor and Ellch were in a hurry, and that they have a goal of getting more press by demonstrating "flaws" on the Mac, because the Mac people are "so snooty" about MacOS being superior to Windows in terms of security (and otherwise). Maynor and Ellch would elect to use an Open Source driver that was already running on MacOS X. While there are several Open Source 802.11 wireless drivers for MacOS, one, in particular stands out, the Intel Wireless driver.
Are there cards available that could use this driver? Highly likely.
While this may be the wrong flavor of ExpressCard (again, no skins/wrong connector), the mere fact of its existence means that a true ExpressCard/34 could be built. I find it likely that Intel (if nobody else) has made a handfull of ExpressCard/34 units available for development, both by its internal developers as well as third-party developers. Obtaining one of these would be as straight-forward as convincing the right product manager at Intel, or a host of other possible companies, that they had a business need for a few samples.
As Glenn reports: Intel Centrino adapters already have updated drivers that are ostensibly to fix two forms of this problem for their original 2100 adapter, and the later 2200BG and 2915ABG adapters. The 2100 has a “malformed frame privilege escalation” patch while the later units can be protected against “malformed remote code execution.”
The plot thickens... "malformed frame privilege escalation"... perhaps the Centrino firmware had a "bug" where it forwarded some "malformed" frame up the stack, but we allow for that in all of the above. All you need for exploitation on a Mac is a driver and an associated "external card". We know we have thed river, and the necessary chipset for the card is already in production. Reference designs exist, too. Check this 2005 issue of the Intel Technology Journal.
Quoting:
The ICH6-M also provides the interface for the Intel PRO/Wireless 2915ABG wireless module and ExpressCard devices. The latter removes the need for an additional PCMCIA controller, thus saving cost while providing higher performance and form-factor-friendly connectivity.
(emphasis mine)
Given all of the above, our pair of "security researchers" would not need to have the card in the Mac (or any other victim machine) associated with the "rogue" AP. The covert channel would be able to forward frames without association. Presto! That explains away the distracting claim by Ellch and Maynor that the wireless card, "doesn't have to be doing anything special."
The attack requires some infrastructure in the device driver to open a "shell" but this is very nearly trivial. The same attack would work over an Ethernet connection (say, from a special range of MAC addresses) but then it wouldn't be as "sexy". Doing this on a Windows XP machine is a cakewalk, doing the same thing on a machine running MacOS requires foreign code, and this HAS to be the reason for the insertion of the third-party ExpressCard in the MacBook.
The claim that the victim PC doesn't have to be "associated" or "doing anything special" is a head fake. While true, it serves to mystify and cloak what is really happening. Ellch & Maynor didn't present a paper titled, "we can create a covert channel by having control of the software on both sides of a communication link", because it is trivial to do so. (Avoiding detection when using a covert channel is a much more difficult problem.) Instead they performed the software equivalent of a "parlor trick", and in the tradition of shysters and con-men everywhere, colored the discussion so people would be mystified, perplexed and think that there was some new exploit buried deep in the 802.11 protocol, when, point-in-fact, there is not.
In the world of security research, this behavior is both dishonest and annoying.
In summary I don't think this is news, or newsworthy. It is "spin", and nothing more. As a none-too-subtle point, you're very very likely "safe" from this attack if your Mac only uses its Airport card, and you've located no other 802.11 cards in your Mac.
NBC news once did a story on side mounted fuel tanks on GM trucks. The claim of the story was that when such a truck was struck, it would burst into flames. GM insisted that its side mounted truck fuel tanks were more than sturdy enough to survive the average traffic collision. NBC produced and aired a video segment that showed a vehicle colliding with the side fuel tank of a GM truck at low speed, and the GM fuel tank exploded. It later turned out that the fuel tank had been rigged with explosive devices by NBC to manufacture the explosion seen in their news report. NBC was castigated by the public when the manipulation by the producers of "Dateline" was revealed.
The video that was shown at DEFCON bears strong resemblence to the NBC's "Dateline" segment. Ellch & Maynor have done the essential equivalent of rigging the MacBook with explosives. They should be required to apologise in public.
Finally, Ellch in particular, does a great disservice to the "Man in Black" via his "Nom de Plume".
“You've got to know your limitations. I don't know what your limitations are. I found out what mine were when I was twelve. I found out that there weren't too many limitations, if I did it my way." -- the real Jonny Cash
