CanSecWest was great!. Here, the presentation slides.
Ok, so, CanSecWest has finished. And i must say, It was an excellent conference.
We ‘ve talked on the second day and, although it was very early, there was a lot of -amazingly not drunk- people there.
I’ve met *a lot* of interesting people there and we had so much fun at the Vancouver’s nights.
After the second day, Dragos has given an awesome party on the top of Grouse Mountain, that is a very cool place.
BTW, this place is excelent. The ppl at vancouver is very kind and open minded. I really hope to come back here the next year.
The slides are available here
A few reporters covered the talk, here are the links:
SecurityFocus
ZDNet
Threat Post
CORE’s Press Release
Informationweek
And also on Slashdot
Based on your slides (which I assume are current?):
http://i.zdnet.com/blogs/core_bios.pdf
it seems like you tested your attack on some old Phoenix-Award BIOS (and also on VMWare’s BIOS, that, however, doesn’t count as a real BIOS) that didn’t require the updates to be digitally signed. AFAIK most of the recent BIOSes do require the updates to be digitally signed… Any comments on this?
Hi joanna, it’s great to see you here.
Well, you’re right. We have not tested our attack on the newest Phoenix-Award BIOS available. We´ve just targeted the most common BIOS firmware around us (and its updates, so i think that maybe there arent digitally signed firmwares available for every motherboard).
In fact, we also havent tested it against EFI or motherboards with TPM because our intention was only to show that the BIOS firmware can be easily readed and modified. This is enough to “infect” normal and forgotten BIOS in most of the machines.
At the other hand, vmware is a very interesting vector attack because it would be very simple to patch the main vmware executable to get our injected code executed by every vmware booted up.
Vmware also allowed us to show in a very clear way (i hope) how malicious things can be done from the BIOS through the int 0×13 as injecting malicious code, modifying data, detecting and patching running Antiviruses, etc.
Before finishing i would like to add that in our talk we said that this kind of attacks could be mitigated with TPM and digitally signed firmwares.
)
So, now that you mention it, i think we should take a look to the more recent BIOS firmwares (if my boss gets me some of it to break
See ya!
If we would have breached into a signed BIOS that means that we have beaten RSA or EC, and by now we would be rich and/or dead. As Anibal said, that wasn’t the target of this attack.
But I just want to add, there are many signed BIOS solutions, as cited by John Heasman’s 2007 Blackhat paper. I’m not familiar with all of them, but there should be two basic ways to verify the BIOS:
1) Doing it on a Read-Only Boot Block (Using TPM or whatever): this can be easily bypassed if you have physical access.
2) Using something better like Intel TXT where Boot Block is no longer the root of trust. But I have heard that some researchers have broken that just weeks ago…
BTW this presentation was only for the first stage of our research. The second stage will be ready in a couple of months, and will put (hopefully) this technique to shame…stay tuned!
“If we would have breached into a signed BIOS that means that we have beaten RSA or EC [...]” — that’s a hell of an assumption. And totally wrong! Just e.g. look at how we bypassed Vista x64 kernel protection (2-3 years ago) that allowed only signed code to be loaded. We didn’t break the RSA nor the X509 cert scheme. Same examples with other work, e.g. Xbox and iPhone cracking.
I was really looking forward to your presentation, thought it would be the most interesting at CanSecWest. But then was disappointed when saw the slides. I think it is unfair not to mention the obvious prevention against your attack in the slides, prevention that has been used for *years* on many BIOSes…
http://news.zdnet.co.uk/security/0,1000000189,39118129,00.htm
BTW, the requirement that the BIOS accepts only signed updates doesn’t require any Read-only bootblock, TPM or TXT technologies! Trusted Boot it a different thing than BIOS flash protection.
Take it easy guys..
Besides the technical discussion about what can or cant be done (and there is a lot to talk about that topic ), I think that what alfred means is that wasn´t our purpose to bypass the most recent firmware protections (breaking or avoiding it) but rather to offer a real probe that this kind of infection really works, and can be used in the most common scenery around there.
With this we tried to show that really makes sense to apply any of the available protection method, at least disabling the Write enable pin, as we’ve mentioned on the talk. So, to avoid future misunderstandings from who wasn`t there and because of the big impact of the presentation, we agreed that would be better to mention it on the slides. We will do it ASAP.
We are open to any other suggestions related to this talk.
First of all; thanks for the slides, I’ve been wanting to look at persistence rookits which sit on things other than hard disks for a while, and they seem to be closer to what I was looking for than Heasman’s slides so they will probably help a great deal
It seems a lot of the work in doing this is done by coreboot, which is pretty sweet, since there’s an easy way to get my hands on that code
I was wondering though, do you have any plans to release any of the code your wrote for this?
kuza55, we are thinking on doing a proper paper, but I doubt that Core would like us to release any code. Anyway, the attack is extremely simple to do. As you say, Coreboot does the heavy lifting with the Flashrom tool, then you only have to find free space, put code any place that is uncompressed (the decompressor block was our choice, but there are many more places) and the compensate the checksum. It’s really that easy. Now, the hard part is the debugging. Good luck with that…