UEFI exploitation, DARPA and moving on

Howdy, It has been a while since my last post. Seems like this has gotten into my bloodstream and became a bad habit, sigh. But last year was pretty busy for me and this includes various areas from the work field to the personal life (I will skip this part).

Lets start with work. I have spent last 11 months working on two separate projects for DARPA (Defense Advanced Research Projects Agency) Cyber FastTrack program. It was an amazing experience, I have learnt a lot and I'm very happy that was able to participate. I would like to thank everyone involved in this program, hopefully it will be resurrected one day. At this point I'm looking for a new job opportunities and contracts so feel free to contact me if you have something interesting in your sleeves :)

As for kon-boot fans new version is going to be released this month (with support for Windows 8.1 both x86 and x64 archs).


As for UEFI exploitation few months ago I was experimenting with some stuff and I found a little vulnerability that was pretty interesting. The bug itself was already patched in EDK2 sources. I believe more curious readers will find the one I'm referring to. The payload is designed to write some silly output to the serial port since writing to screen is kinda no-go. The cool fact about this bug is that it happens very early - before user can even enter UEFI setup. Same thing happens on my mac mini machine.

Bug itself is a heap corruption (heap overwrite) vulnerability. I wouldn't say exploitation is reliable. It heavily depends on the hardware devices installed and the memory layout -- even though I'm using only one hardcoded value which is stable among different VMware machines. Even though UEFI is the new standard custom vendors use custom UEFI implementations (AMI, PHOENIX, APPLE). Each implementation typically includes different set of drivers and different memory layout. Debugging this on real hardware is a mess. Anyway since the UEFI images can be relocated in memory I would suggest using the BIOS ROM memory (0xFFE00000) for some further exploitation voodoo (obviously still different vendor = different firmware but at least you have some stable memory address).

Since users do not really patch their firmware the same vulnerability still exists on Apple MAC computers (for example on my mac mini which I kinda bricked trying to debug this crap).

UEFI HEAP CORRUPTION EXPLOITATION ON VMWARE from Piotr Bania on Vimeo.

That is all people, GODSPEED!

I guess we are who we are
Headlights shining in the dark night I drive on.