AUGD: Hijacking a Macbook in 60 Seconds or Less
AUGD: Hijacking a Macbook in 60 Seconds or Less
- Subject: AUGD: Hijacking a Macbook in 60 Seconds or Less
- From: Gilberto Palau <email@hidden>
- Date: Thu, 3 Aug 2006 09:04:14 -0400
My fiancee is in the Blackhat conference and she was telling me
yesterday about a conference where to guys demonstrated how to hack a
macbook in 60 secs or less. I tought it might be a good idea to get
the article through so our people know about this.
Gilbert
______
Hijacking a Macbook in 60 Seconds or Less
Black Hat
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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Augd mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden