Charlie Miller On Hacked Batteries, Cloud Security, And The iPad

Exploiting Hardware Vulnerabilities

Alan: Let’s talk about the battery exploit. How did you even come up with the idea about looking for vulnerabilities in the battery?

Charlie: At Black Hat last year I saw Barnaby Jack's ATM hacking talk and thought the coolest thing about it was how you could explain what he did to someone with no technical know-how. "You see that ATM? I can make it spit out money." I wanted to work on something like that and thought about the risks of battery safety for laptops. I set out to see if a remote attacker could blow up my laptop. I still don't really know the answer to that question, but I do know that 1) attackers can certainly get far into that subsystem and 2) I can't blow up a battery :) It was a fun (but long) project because I don't know that much about hardware, so I had to learn a lot as I went.

Alan: This exploit would be resistant to reformatting, right? The ultimate pre-boot malware.

Charlie: So, one of the things I show you can do is make modifications to the firmware that runs on the main chip on the smart battery. You can make it do whatever you want because Apple used default passwords on the chips (made by Texas Instruments). Code you put there would survive reinstallation of the OS, new hard drives, new motherboards, and so on. However, the code cannot directly affect the OS or hard drive, so in order for it to be malware, it would have to attack the OS through some kind of vulnerability in the way the OS handles messages from the battery. Now, I don't know if such a vulnerability exists, but I do know that whoever wrote that code wasn't thinking that the battery would be sending malicious data, so I wouldn't be surprised to find one!

Alan: What about systems implementing trusted boot and things like Intel Trusted Execution Technology? Could that have prevented this attack?

Charlie: No, that wouldn't help. The boot process would all be fine and dandy and after the OS was up and running, the battery would attack it (if such a vulnerability exists) and then inject code.

Alan: When you or any other security researcher discovers system vulnerabilities like this, it’s natural for people to assume that this is the "first discovery" of the problem. Indeed, often times it is only days after a vulnerability is reported that attacks show up based upon the newly-published vulnerability. But we know the bad guys are talented. The bad guys may actually have more money behind them. As the stakes get higher, when do we begin to assume that the bad guys have beat us to discovery and that any vulnerability that is reported is already actively being exploited and we just didn’t know?

Charlie: This is a really interesting question. I'm always worried that other researchers are going to discover the same things I discover before me. In fact, I had a Mac OS X exploit ready to go at Pwn2Own this year and didn't get a chance to use it because someone else beat me to it. Then, a few days later, Apple patched it, so someone else had independently found it (or pwned me and stole!) That was something I liked about the battery research. because I thought nobody would ever think of this wacky idea and I could take my time looking at it. But it turns out that Barnaby Jack (the ATM hacking guy I mentioned earlier) had looked at exactly the same thing and discovered many of the same things I found about a year ago and never told anyone because he didn't catch his laptop on fire. So no matter how clever you are, the odds are that somebody else already knows how to do what you're trying to do. People think I find good stuff, but I'm one guy doing this in the evening for fun with no budget. Compare that to all the money the U.S. government (or China) spends on cyber security. It is hard to imagine they don't know some things we haven't figured out yet.

  • Darkerson
    Pretty interesting read. Keep up the good work!
    Reply
  • pepe2907
    Good call, but whoever actualy read the license agreements knows software manufacturers refuse any possible liability for any damages.
    If something is going to change, this should be the first. With these license agreements you can't claim anithing. But this change will not be easy.
    Reply
  • DavC
    interesting read!
    Reply
  • mayankleoboy1
    No matter how much security you build into a system, if the user really wants to run a piece of malware they think will show them some naked pictures, they're going to figure out a way to run that program.

    exactly
    Reply
  • mayankleoboy1
    if only software could be people-proof.
    Reply
  • jacobdrj
    mayankleoboy1if only software could be people-proof."A farmer notices his chickens are getting sick, he calls in a physicist to help him. The physicist takes a good look at the chickens and does some calculations, he suddenly stops and says "Ive got it, but it would only work if the chickens were spherical and in a vacuum."" - Big Bang Theory...
    Reply
  • slicedtoad
    So is it safe to say that as an end user we shouldn't be over concerned about personal computer security?
    Here's my checklist. Don't download unknowns, don't password reuse (for the important stuff anyway), get a decent av (like eset) and keep your computer up to date.
    Multi-layered security on a home pc doesn't make sense, nor does 15 character alpha-numeric passwords (in most cases). No one is going to specifically target you or your pc.
    Reply
  • weaselsmasher
    An awful lot of "people like me" "researchers like me" "guys like me" "me me me me me" there.

    What's this article really about, security or celebrity?
    Reply
  • christop
    Enjoyed this..Wish I had a few 0days sitting around to sell..
    Reply
  • PreferLinux
    pepe2907Good call, but whoever actualy read the license agreements knows software manufacturers refuse any possible liability for any damages.If something is going to change, this should be the first. With these license agreements you can't claim anithing. But this change will not be easy.Yes, but whether that is fully legal or not is another story.
    Reply