Hardware Backdooring is practical

Jonathan Brossard (Toucan System)

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

Epic evil remote carnal pwnage (of death)

Why cryptography (Truecrypt/Bitlocker/TPM) won't save us...

Backdooring like a 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 Pheonix-Award Bios

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...)

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)

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 : embedded features

Remove NX bit → executable heap/stack.

Make every mapping +W in ring0

Remove CPU updates (microcodes)

Remove anti-SMM protections → generic local root exploit

Disable ASLR

Bootkitting (modified Kon-boot payload*)

*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) :

No-Execute Enable (NXE) Bit. Bit 11, read/write. Setting this bit to 1 enables the no-execute page-

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

 

movl

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

supervisor-level procedures from writing into read-only pages; when clear, allows supervisor-level procedures to write into read-only pages (regardless of the U/S bit setting; see Section

4.1.3and Section 4.6). This flag facilitates implementation of the copy-on-write method of creating a new process (forking) used by operating systems such as UNIX.

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 -rf ./coreboot/microcodes/

Remove anti-SMM protections (1/2)

Intel® 82845G/82845GL/82845GV Graphics and Memory Controller datasheets, Section 3.5.1.22:

SMRAM—System Management RAM Control Register (Device 0), bit 4 :

SMM Space Locked (D_LCK)—R/W, L. When D_LCK is set to 1, D_OPEN is reset to 0; D_LCK, D_OPEN, C_BASE_SEG, H_SMRAM_EN, TSEG_SZ and TSEG_EN become read only. D_LCK can be set to 1 via a normal configuration space write but can only be cleared by a Full Reset. The combination of D_LCK and D_OPEN provide convenience with security. The BIOS can use the D_OPEN function to initialize SMM space and then use D_LCK to “lock down” SMM space in the future so that no application software (or BIOS itself) can violate the integrity of SMM space, even if the program has knowledge of the D_OPEN function.

Remove anti-SMM protections (2/2)

D_LCK is not supported by CoreBoot currently

anyway...

;disable D_LCK in Coreboot shellcode ;) nop

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

Bootkit future OSes

Update/remove/reflash firmwares (PCI, BIOS)

Currently capable of Bootkitting any version of Windows (32b/64b) thanks to special version of Kon-boot

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 !

DEMO : Evil remote carnal pwnage

(of death)

I can write blogs too... Muhahahaha...

How to properly build a botnet ?

HTTPS + assymetric cryptography (client side certificates, signed updates)

Fastflux and/or precomputed IP addresses

If Microsoft can do secure remote updates, so can a malware !

Avoid DNS take overs by law enforcement agencies by directing the C&C rotatively on innocent web sites (are you gonna shut down Google.com?), use assymetric crypto to push updates.

Why crypto won't save you...

Why crypto won't save you (1/2)

We can fake the bootking/password prompt by booting a remote OS (Truecrypt/Bitlocker)

Once we know the password, the BIOS backdoor can emulate keyboard typing in 16b real mode by programming the keyboard/motherboard PIC microcontrolers (Brossard, Defcon 2008)

If necessary, patch back original BIOS/firmwares remotely.

Why crypto won't save you (2/2)

TPM + full disk encryption won't save you either :

1)It's a passive chip : if the backdoor doesn't want explicit access to data on the HD, it can simply ignore TPM.

2)Your HD is never encrypted when delivered to you. You seal the TPM when you encrypt your HD only. So TPM doesn't prevent backdooring from anyone in the supply chain.

How about Avs ??

Putting an AV on a server to protect against unknown threats is purely cosmetic.

You may as well put lipstick on your servers...

Example : 3 years old bootkit

Example : 3 years old bootkit (+

simple packer)

Realistic attack scenarii

Realistic attack scenarii

Physical access :

Anybody in the supply chain can backdoor your hardware. Period.

Flash from a bootable USB stick (< 3mins).

Remote root compromise : If (OS == Linux) {

flash_bios;

} else {

Pivot_over_the_MBR ;

}

Realistic attack scenarii

Purchase pre-backdoored hardware

BONUS : Backdooring the

datacenter

Remediation

Remediation (leads)

Flash any firmware uppon reception of new hardware with open source software you can verify.

Perform checksums of all firmwares by physically extracting them (FPGA..) : costly !

Verify the integrity of all firmwares from time to time

Update forensics best practices :

1)Include firmwares in SoW

2)Throw away your computer in case of intrusion

Even then... not entirely satisfying : the backdoor can flash the original firmwares back remotely.

Side note on remote flashing

BIOS flashing isn't a problem : the flasher (Linux based) is universal.

PCI roms flashing is more of a problem : flasher is vendor dependant...

Detecting network card

manufacturer from the remote C&C

IPXE allows scripting. Eg : sending the MAC address as an URL parameter.

From the MAC, get the OUI number serverside.

From the OUI number, deduce manufacturer

Send the proper flashing tool as an embedded OS to the backdoor...

Backdooring like NSA China

Backdooring like a state

Rule #1 : non attribution

-you didn't write the free software in first place.

-add a few misleading strings, eg : in mandarin ;)

Rule #2 : plausible deniability

-use a bootstrap known remote vulnerability in a network card firmware

(eg : Duflot's CVE-2010-0104)

« honest mistake » if discovered.

-remotely flash the BIOS.

-do your evil thing.

-restore the BIOS remotely.

More DEMOS

Outro

This is not a vulnerability :

-it is sheer bad design due to legacy.

-don't expect a patch.

-fixing those issues will probably require breaking backward compatibility with most standards (PCI, PCIe, TPM).

Questions ?