BlackHat EU 2019
Raw Notes
wo 4 dec 2019 12:01:49 CET contactless payments https://www.blackhat.com/eu-19/briefings/schedule/#first-contact---vulnerabilities-in-contactless-payments-17454 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 https://www.blackhat.com/eu-19/briefings/schedule/#mobile-network-hacking-ip-edition-17617 5 classes of attacks intercept impersonate track fraud dos 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 https://www.blackhat.com/eu-19/briefings/schedule/index.html#fatal-fury-on-esp-time-to-release-hardware-exploits-17336 limiteresults 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?) `espefuse.py 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 espefuse.py 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 persistence! 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: https://www.blackhat.com/eu-19/briefings/schedule/#bitleaker-subverting-bitlocker-with-one-vulnerability-17245 --- do 5 dec 2019 17:33:39 CET breaking bootloaders https://www.blackhat.com/eu-19/briefings/schedule/index.html#breaking-bootloaders-on-the-cheap-17518 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
Last update:
November 8, 2020