Hijacking a Macbook in 60 Seconds or Less
UPDATE, 6:45 p.m. ET: Watch the video of the Ellch/Maynor presentation on a new method they discovered for remotely circumventing the security of an Apple Macbook computer to seize total control over the machine. For background and details, see the text below the video player for this morning's post.
Original Post -- 7:30 a.m. ET, Aug. 2:
If you want to grab the attention of a roomful of hackers, one sure fire way to do it is to show them a new method for remotely circumventing the security of an Apple Macbook computer to seize total control over the machine. That's exactly what hackers Jon "Johnny Cache" Ellch and David Maynor plan to show today in their Black Hat presentation on hacking the low-level computer code that powers many internal and external wireless cards on the market today.
The video shows Ellch and Maynor targeting a specific security flaw in the Macbook's wireless "device driver," the software that allows the internal wireless card to communicate with the underlying OS X operating system. While those device driver flaws are particular to the Macbook -- and presently not publicly disclosed -- Maynor said the two have found at least two similar flaws in device drivers for wireless cards either designed for or embedded in machines running the Windows OS. Still, the presenters said they ultimately decided to run the demo against a Mac due to what Maynor called the "Mac user base aura of smugness on security."
"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," Maynor said. "The main problem here is that device drivers are a funny mix of stuff put together by hardware and software developers, and these guys are often under the gun to produce the code that will power products that the manufacturer is often in a hurry to get to market."
Maynor said he and his colleague opted in favor of a videotaped demonstration versus a live one because of the possibility that someone in the audience could intercept the traffic sent to a potentially live target and deconstruct the attack -- possibly to use the exploit in the wild against other Macbook users.
One of the dangers of this type of attack is that a machine running a vulnerable wireless device driver could be subverted just by being turned on. The wireless devices in most laptops -- and indeed the Macbook targeted in this example -- are by default constantly broadcasting their presence to any network within range, and most are configured to automatically connect to any available wireless network.
But according to Maynor and Ellch, this attack can be carried out whether or not a vulnerable targeted laptop connects with a local wireless network. It is, they said, enough for a vulnerable machine to have its wireless card active for such an attack to be successful. That's a trivial demand, given that most wireless devices embedded in laptops these days are switched on by default and are configured to continuously seek out available wireless networks.
Because the software that powers these wireless devices operates at such a fundamentally low level of the operating system, traditional system safeguards like firewalls and anti-virus software most likely will not stop the operating system from accepting a maliciously crafted network probe from an attacker seeking to exploit device driver-specific flaws. The result, said Maynor, is that a system using poorly designed device drivers is vulnerable to compromise just by doing what it was programmed to do.
But that explanation eclipses the larger point that Maynor and Ellch said they are trying to get across: Namely, that wireless device drivers are largely developed and written by an odd mix of hardware and software developers in an environment where time-to-market often trumps any thorough code review for potential security flaws.
Apple -- like many computer manufacturers -- outsources the development of its wireless device drivers to third parties. In Apple's case, the developer in question is Atheros, a company that devises drivers for a number of different wireless cards, each designed with drivers specific to the operating systems on which they will be used.
Maynor and Ellch also found two different device driver flaws for wireless products aimed at Windows systems. This is notable because it points out a security loophole in the way that Microsoft has traditionally processed device drivers. Any time a Windows XP user tries to install a device driver, the system checks whether that driver has been "signed" or approved by Microsoft so as not to cause system stability problems. Many third-party wireless cards designed for Windows systems are not signed by Microsoft, and the system will throw up a warning to that effect any time a user tries to install an unsigned device driver.
But according to Maynor and others, Microsoft only recently began testing whether its approved or "signed" device drivers introduced unforeseen security weaknesses into the system. Microsoft is trying to rectify that problem with Windows Vista -- the next version of its operating system by only allowing the installation of device drivers that have met the company's security testing procedures.
After the demo, Ellch (who is currently pursuing his master's degree in computer security at the Naval postgraduate school in Monterey, Calif.) will talk about a new tool he's developing that can remotely scan and figure out the chipset and driver version of a wireless device on a target computer. So far, Ellch said the tool currently recognizes 13 different wireless device drivers, breaking them down by operating system and firmware version.
"I'm getting this tool to the point where it can tell you not only how many people in a room are running, say, Centrino or Broadcom devices, but that 'x' number are running them on a Windows box with a specific version of the driver," Ellch said. "The userful thing for that information is that if you have a device driver exploit and it's version-specific, you could tweak [the exploit] before you launch it."
Maynor said he and Ellch have been in contact with Apple, Microsoft and other companies responsible for vetting the device drivers that power the embedded or third-party wireless card devices meant for those systems, and that both companies are working with wireless card vendors and original equipment manufacturers (OEMs) to remedy the problems. Assuming the wireless device driver makers affected by these flaws fix the problems, it may be an uphill battle for those vendors to find an easy way for users to upgrade that software.
I should note here that while the bad guys may or may not have known about these security weaknesses for some time, there is not a single shred of evidence that these flaws have been exploited "in the wild" (as security companies like to say). That said, it might not be terrible idea to take advantage of the button your laptop that allows you to turn off the machine's constant search for wireless networks when you're not actively trying to go online.
The comments to this entry are closed.