Skip to content

BlackHat EU 2019

Raw Notes

wo  4 dec 2019 12:01:49 CET

contactless payments

loss data is not readily available
action fraud: average loss is 600, one over 400k pounds

1979 magstripe (cvc was just checksum, not security)
1996 emv
2005 contactless trial
2007 rollout

nfc has magstripe legacy modes
(some that had been discarded by emv)

terminal initiates contact with card
PODL: currency, amount, UN, TTQ
card sends list of modes supported

ctq/tiq is ignored by some vendors
"cryptogram" can be reused


wo  4 dec 2019 13:08:43 CET

mobile network hacking over ip

5 classes of attacks

big change is that 4g moves everything to IP
no more voice, no more sms
RCS is the new SMS
many are moving to voice over wifi, otherwise over lte

lower bound estimates (via dns queries) found hundreds of carrires

rcs has all the same classes of vulnerabilities
found many attacks
some via local networks
impersonation requires no special privs

sip protocol has no authentication for some queries
SIP OPTIONS can query status

thumbnails are automatically downloaded!

session tokens included in headers can be used to take over accounts

clever attack with a malicious hotspot that sends bogus javascript,
disconnects the phone, which falls back to lte with the malicious js
running, which can then do queries against the 3gpp server

can use config to retrieve otp to login to gmail

tls is done wrong, so mitm is easy


do  5 dec 2019 15:14:46 CET

esp32 glitching

over 100 million devices
"state of the art" security
lots of ports, but no usb...
System in Package (SiP) FCC certified, with shielding
arduino support
"AWS IoT" platform

threat model of physical access is plausible
- supply chain (so many random sellers)
- or attacks on installed systems

voltage fault injection
- skip instructions
- data changes
- sometimes very unexpected

3 power domains in the system
two power signals in cpu domain (RTC/CPU)
LDOs might stabilize against glitching
brownout detection triggers shutdown
prints to uart
only on VDD_RTC, but not VDD_CPU!

schematics for module are available
remove capacitors on cpu domain
expose trace, cut trace, install glitcher
homemade glitcher based on max4619
sync with scope
trigger by signal generator
(definitely could use spispy!)
fully automated
see glitch output on uart signal (idles high)

crypto-core used by mbedtls for acceleration
mbedtls probably not software vulnerabile
aes operation: initialize data into reg, write 1 to start, wait until idle goes 1, read from same reg.
"encrypt in place" is weak
glitch during start and clear text stays in the registers
lots of places in the code to glitch (loops are easy!)

weakness 2: prevent aes set key from running, leaving key at all zeros
many aes-cbc only set key once

six total vulnerabilities found in cryptocore
esp tried silent patch
arm and mbedtls did not pay any bounties

secure boot on the esp32
chain of trust from bootrom to bootloader to application
developer can fuse key into efuses
r/w protected from applications
used for aes256 ebc
ecdsa key pair for developer, stored in spi flash

reset -> rom -> load and check boot.img from flash with aes -> boot.img validate signature on flash with ecdsa -> XIP from flash
(toctou possible?)

` burn_key`
jtag fuses are not set automatically as well

if unsigned app is loaded, spins in stage0 bootloader
can single step jtag in bootrom!?!!!
weird architecture (register windows, etc)
ida plugin by madinventor
some symbol names published (by accident?)
using jtag verifies that the attack works

timing information from spi mosi, glitch vdd
after tuning found timing that causes it to jump into bootloader
not persistent, but...
boot rom vulnerability
requires rom update

disclosure: sent june 4, self published sep 1
esp issued advisory sep 2

flash encryption
hw enc/dec block in flash memory controller
fetch key from efuses
enc/dec into an i/d cache
sw should not be able to access key

use to set blk1 key
set in ecb mode (you can see the penguin)
not enough side channel leakage to extract key
but.... efuses "OTP"

blk0 = esp32 config
blk1 = flash enc key
blk2 = secure boot key
blk3 = user

found efuse_read/efuse_program in "special boot mode"
bootrom doesn't read otp values
download_boot mode - io0 gnd
management mode to flash fw and efuses, prints to uart
esptool can talk to uart
blk0 has read protection bits, ready by otp controller hardware

power analysis identify hw process that is reading the blk0 config
glitch during this read can lead to r/w bit
download_boot mode will then allow reading
but keys printed are not right
related to real key, requires some brute force and statistical analysis
downloade encrypted image to verify

can also extract iv from firmware image
and then re-encrypt a new image, reflash it
keys are probably not device unique, allowing class break

disclosure: july 24, sec advisory nov 1, public disclosure nov 13
no solution, but next version of esp32 will have fix
"forever day" bugs... 100 million deployed
some business models are protected by these keys


do  5 dec 2019 17:18:27 CET

to be researched:


do  5 dec 2019 17:33:39 CET

breaking bootloaders

no hardware attacks used
but physical attacks are in scope

many bootloaders have debuggers built in
lpc1343 vulnerability in write ram command
stm8/stm32 were not

many devices do not enable memory protection units

-- can glitch CRP check?

many devices do not unmap boot rom after boot
allowing user access to it
and reverse engineering

stm8 loads option byte "from its region (0x004800)" with one value
is that onboard flash or elsewhere?
could be glitched, but single instruction

stm32 has three levels
write command is prohibited in any level
could be glitched as well, with a loop

lpc1343 CRP1 (lowest secure level) has been glitched (akacastor)
also copies CRP register from flash to RAM
then checks the RAM value

CRP1 still allows writes, with limited ranges to protect secure config
no level has read memory

stack grows down from 0x10002000
which means that the stack is writable via the command!
stack is unprotected, no canaries, etc
ROP is doable

2019 Security Conferences

Last update: November 8, 2020