When you think about hacking laptops, it’s highly unlikely that you would ever consider the battery as a viable attack vector. Security researcher [Charlie Miller] however, has been hard at work showing just how big a vulnerability they can be.
As we have been discussing recently, the care and feeding of many batteries, big and small, is handled by some sort of microcontroller. [Charlie] found that a 2009 update issued by Apple to fix some lingering MacBook power issues used one of two passwords to write data to the battery controllers. From what he has seen, it seems these same passwords have been used on all batteries manufactured since that time as well. Using this data, he was subsequently able to gain access to the chips, allowing him to remotely brick the batteries, falsify data sent to the OS, and completely replace the stock firmware with that of his own.
He says that it would be possible for an attacker to inject malware into the battery itself, which would covertly re-infect the machine, despite all traditional removal attempts. Of course, replacing the battery would rectify the issue in these situations, but he says that it would likely be the last thing anyone would suspect as the source of infection. While using the battery to proliferate malware or cause irreversible damage to the computer would take quite a bit of work, [Charlie] claims that either scenario is completely plausible.
He plans on presenting his research at this year’s Black Hat security conference in August, but in the meantime he has created a utility that generates a completely random password for your Mac’s battery. He says that he has already contacted Apple to in order to help them construct a permanent fix for the issue, so an official patch may be available in the near future.
[Thanks, Sergio]
scary thought really I suppose that someone could press a key and cause the battery to shut off or even over heat and explode. It won’t be much longer then before people are needing to buy anti virus software for their batteries. hmm… I wonder if this extends to other lithium polymer powered devices (iPods, iPads and mobile phones extra)
Interesting research, but it looks like this is still quite a ways off from being a real threat.
Getting a new firmware on the battery means you need to run the installer on the Mac, which is obviously going to be tricky. Practically speaking you would have to use some kind of a trojan application that secretly writes the new firmware to the battery, as there are very few remote exploits that could get you that kind of level of access on Mac OS.
Once the compromised firmware is installed on the battery, it is easy enough to damage it, but going any farther than that seems unlikely. As he says in the original article, actually turning this into malware would require finding some exploitable bug in how the OS communicates with the battery, which is theoretically possible but far from certain.
Apple. Worst. Security. Record. Ever.
I am interested in what type of response he gets from them. In my experience, alot of companies be they large or small, can be quite hostile when you report problems.
@MS3FGX
What’s a EULA? I don’t know either, I just scroll to the bottom and hit “I Accept” and run the installer. BonzaiBuddy is supposed to be my friend anyways, right?
@MS3FGX
“there are very few remote exploits that could get you that kind of level of access”
It only takes one.
@MS3FGX I agree that infecting the battery from outside would be a bit of a stretch, but very much a threat to people buying replacement batteries from third party suppliers.
My company is seeing more and more Mac malware which is installed by user action. It is not inconceivable that social engineering methods or piggybacking with shady applications could be used to spread this sort of malware.
I see it as a very real threat, and one that will likely be exploited.
good luck with these ‘reinfect’ claims without memory corruption..not very professional..
Soon to be yet another reason not to buy cheap batteries from china.
It’s ironic that one of the reasons macs see less malware is because the proliferation of window machines make them a better return on investment for blackhacks. But there are probably more macbooks out there any single model from dell/hp/other, which could make them a more likely target for firmware hacks like this.
This makes me thing twice about replacing my battery with one of those cheap replacements from 3rd party’s.
Unsigned firmware with default passwords is a security problem.. no shit? hey, welcome to nsa class research.
Next week we’ll cover yet another webkit bug exploiting an os that has yet to enter the late 90s security wise. also, you need to pay me for my bullshit 1995 work because well theyre bullshit enough that no one else will buy them from me.
nice one. out of the box
One major “reason” we have a duty to expose security issues is *PREVENTION* of Very Bad Things.
In an ideal world, there would be ZERO malicious acts period. As we’d all be ethically above such things. Enlightened Self-Interest might be a good meme tag?
Batteries are so omnipresent in our world that someone seeking to cause “Fear Of Batteries” might well be accused of creating a FNORD! effect.
Call all the above “awareness Hacking?
The battery exploit vector is quite real and we’ve “known” of it back since someone found a way to change the reporting in one common controller chipset. Anything that CAN communicate with another system is an exploit vector either in or outbound!
It’s just never before been considered a credible threat or viable vector at all. Due to how tiny a payload one could carry in most battery controller’s memory+the usual lack of ways to push arbitrary code into anywhere useful for attack. Absent perhaps some “other code base” being seeded into the wild for being battery triggered?
Are we gonna see things like this in the news soon?
http://techbuket.net/68
but he says that it would likely be the last thing anyone would suspect as the source of infection
Seems to me that’s it’s the thing you do will alway’s fix it
People at blackhat will learn that you can update firmware from the SC on Mac and x86(where kernel allows it)..(scratches head as to how this is news)
I’m still wondering how this is anything more than a potential ddos via another attack. The author only makes sensational claims regarding code execution..that’s lame marketing technique and they will be called out on it by real talents and pros..
Exactly what happened to the PSP with pandora batteries. Sony has never been able (or never tried) to fix it without changing hardware.
Firmware will now have to be developped with security in mind.
I can see how changing the battery controller firmware could result in battery destruction. It might even result in a fire, although the cell physical construction attempt to prevent that even with a severe overcharge.
What I can’t see is a clear path to compromising the rest of the system. Battery communication is over SMBus (essentially I2C). Other critical parts of the system are also on SMBus, but not the same SMBus. For instance, I don’t think that you can write the BIOS over SMBus.
Even if you could figure out a path to the other SMBus branches, the battery controller is pretty tiny. It couldn’t hold much extra code. This might be a more realistic exploit if you replace the battery controller — not impossible, but a physical exploit rather than a remote exploit.
Oh, hacking batteries… Yeah, I can see that I live in 21st century. :-D It seems like discovering vulnerabilities in things like forks or spoons is only a matter of time. Or, maybe, spades will be the next? :-DD
@Donald Becker: They can’t see it either, it’s not mapped x86 code like with bios, it’s controller code updated via SC.
It’ll take a memory corruption in controller buffer to get code execution(patchable driver), they don’t have that, just the sensationalism.
The only thing remotely impressive is custom firmware, and that’s only if it’s not just a hexed copy..
This sales contracts and software despite the nuances though..
Ok- here’s the reality check list.
Starts with what’s been said RE “how” that battery controller com link works. Follows with just how many bytes of code can be put into a FUNCTIONING controller absent physical alterations or using a different chipset. Ends up at- First Evaluation, apparently an exploit is needing both code on battery AND in the device powered by that battery. Lacking both elements, an exploit appears unable to do anything beyond deny use of the battery/device or damage/destroy battery.
Now, the longshot of destroy battery=destroy device and surroundings is indeed NOT to be overlooked as a non-trivial event.
But, I’d worry more about more drop dead simple exploits like folks who charge phones from a USB port on their ‘puter. Here’s where some people will be getting very coldly afraid.
That Android phone you use, the one with that cute desktop icon that shows battery charge and temp in both C&F.. It’s got comms from the market application to the battery. How well do you trust all that code now? Including the code/controllers in the additional cheap batteries you bought online..
Cant wait to see the first “Breaking News” about this… scare people away from cheap Batteries, tell em to buy original certified batteries for a silly price to be safe from Malware.
Firmware should really be checked as a vulnerability, as [Charlie] says. Case in point: http://goo.gl/ynt09
***THEY DON’T HAVE CPU CODE EXECUTION***
geez..
post didn’t show
I posted something
This seems like the sort of thing that the darwin kernel would do a good job of preventing. (And that, ladies and gentlemen, is why macs are more secure than windows boxes. Good design, not product obscurity.)
Anyway. Very interesting idea. I’m curious what other manufactures use batteries with a host flashable eeprom on them.
Anyone who says this is not a problem because “There are very few vulnerabilities” or “it’s just a concept” would be wise to read the following article by Hack-A-Day regular and software and hardware hacker extroardinaire, SpritesTM himself:
http://spritesmods.com/?art=biostick&page=7
It only takes one security loophole and interest from the blackhat community(like what happened to Sony) developing the bootstrap tech, and every script kiddie in the world(Anonymous, as they like to be called) can do whatever they want to a system.
Nice work, Apple.
Well, thats what you get for having flashable firmware in a battery. You’d think that these things would be set read only at the factory, with some sort of special interface (i.e. hardware) needed to write them.
Rumour has it that pretty much all the common laptop manufacturers use this technique to allow them to fix common problems on the fly.
I can see this being the next laptop battery recall issue. “may be able to act as virus host or potentially vent with flame if infected”.. !
Also worth noting is that malware exploits aren’t the only possible use for this technology. The battery firmware is responsible, remember, for monitoring battery charge and temperature to ensure your battery isn’t drained too quickly(damaging the battery life), run too hot(damaging the battery chemistry) or overcharged(causing the battery to leak and possibly explode). All it really takes is someone who wants to hurt a lot of people(again, Lulzsec or the more hostile portions of Anonymous would love to get their hands on this) to make every single Macbook that Apple sells into a suicide bomb.
Doubt you could make the pack catch on fire this way, there are hardware failsafes to prevent this.
However you probably could “brick” the pack with no warning at all by having the controller overwrite the battery serial number etc.
I could be wrong however, if someone cut corners and implemented the failsafes in software then it might be possible to cause a meltdown in software, in which case a LOT of people in Homeland Security will be very very worried right now and on the phone to Apple right now ™ to resolve this via compulsory firmware update.
The compulsory firmware update of course is a zero day for some new Very Bad News.
well, great. can you reset my old iBook battery to a decent level, because i just know Apple battery management is bull
@GZ,
You said Worst security ever.
You were wrong.
So Wrong.
I only need say one word to make apple look good.
S o n y .
Now THERE is your worst ever most things.
Seriously though, Firmware updates in the battery?
I see 2012 to be the year that a computer finally spends more time updating than being used for actual productive work, by 2015 the world will collapse as the collective updates take more than 24 hours each day and all computers cease to function (or at least run like windows ME).
Cant they just make stuff that works to begin with and NOT have patches and updates. Jeez.
you may be able to return the batteries to apple for exchange.
just dont say that you was tinkering with the firmware.
you may be able to destroy the firmware to the point of making it unreadable or even accessible so even if apple puts the batteries on the diagnostic unit it will be undetectable even by the test unit.
if apple should ask for the laptop back just go out and get a new one to send back to prevent apple from detecting tampering
I’m going to put on my tinfoil hat for a second here:
Maybe this is a tool for Apple to remotely disable batteries. After x number of cycles, some code lingering in OS X decides to brick the battery.
Anyone saying OS X doesn’t have a huge amount of security flaws can look to the Pwn2Own competitions where Apple products are _always_ the first to fall (on the order of minutes).
This doesn’t mean I’ll sell my MacBook, though.
@Brian Benchoff: It’s not tinfoil hat after the HP expiring ink bit. IBM and more than one early big iron mainframe company used to have “suicide clock” code of a sort in leased machines.
Call this and several other situations Very Good Reasons to demand Open Source code even in microcontroller firmware. As if the code is Open- there’s “less chance” of exploits remaining unseen. Zero day stuff is also liable to become an endangered, hopefully extinct concept if all alpha and beta releases were compared to production code. That way- many categories of hidden malware would not have so wide an array of unpatched vectors to bite into. Apple’s just had another bite taken out of it’s arse. Call it a sacrifice on the altar of Closed code? You’d not think a battery and the powered device’s code are in the same realm of needing to be transparent. This is what happens more easily in secrecy than transparency. Stuxnet 2.0 in a battery controller- UPS? seems not implausible after all.
Uh- how many folks reading this have any UPS boxen with a comm cable to a networked ‘puter??
Sleep well while thinking that last implication over.
@Pyrofer: the exploit is based on the fact that the default copy protect password for Macbook batteries is always the same. Sounds a lot like the thing where the “random number” used to generate the verification keys for PS3 software was always the same. I’m gonna call a tie here.
@Oren Beck: Ironically, that’s exactly why I chose the Sony Reader over the Kindle or Nook. No network connectivity means that’s one piece of equipment Sony can’t remotely brick, so long as I never use their software to communicate with it.(and boy, they’d probably love to brick it so I have to buy the touch version.)
You can prevent people from charging there batteries if they run your code as sudo..yawn
batteries catching fire? If you don’t know the chip supplements analog components then you shouldn’t be ‘enlightening’ us hot shot..
I challenge anyone to prove any of these claims(except writing to the chip). If you’re going make sensational claims at least have a clue what you’re talking about..
I’m not really going to trust security advice from the guy who has lost all of his prior employers due to software security issues. All I really know is that you can never be too careful about security, and that requiring elevated permissions status to make critical changes to your system will never be sufficient if that same elevated permissions status is also required to install new software to the system.
with the recent changes of the ability to write to cmos and bios through OS, I can see the same happening to the overall system itself. EUFI bios implementation with a controlled killswitch is also a new possibility with advancement. EUFI is also another possible way to implement a new way of proprietary control for certain vendors that don’t want you to use other vendors not in the special associations they have.
@deathventure: “recent”? you obviously googled the wrong query. This has been possible since 8 bit with increasing component support..
This is why there is such thing as ring0..if you privilege software to modify firmware it’s your own fault..apple hasn’t done anything wrong..and the claim this gets cpu code execution is total BS as will be pointed out at blackhat when this marketing garbage goes on presentation..
The controller can’t overload cells because it only uses GPIO for power bus monitoring, and can’t get CPU execution without driver-based memory corruption which this incompetent marketing-puke only wishes he had..
A soon to be addition to backtrack linux lol.
Replace the battery too while your at it.