Released on January 1st 2016, the ESP32, the System-on-Chip (SoC) from Espressif Systems, becomes quickly popular among the IoT industry and electronic hobbyists, due to its wireless connectivity, a low-power consumption and a free development framework supporting plenty of functions. Espressif is supporting a 12-years-longevity commitment for ESP32, and has already achieved the 100 Millions Target of IoT chip Shipments in January 2019 [1].
This SoC, based on Xtensa LX6 dual-core, contains built-in security features such as:
- Crypto-Hardware accelerator. The HW crypto accelerators are nowadays used to speed up cryptographic primitives like AES, SHA and even RSA, which will be used by crypto library like ARM MbedTLS [2].
- Secure Boot. The Secure boot is the guardian of the firmware authenticity and integrity stored into the Flash memory.
- Flashencryption. The Flashencryption is used to protect the firmware confidentiality, for example to avoid the loss of IP or to a readout of persistent and sensitive data like Wi-FI credentials in IoT devices [3].
- One Time Programmable (OTP) memory. The OTP memory, based on eFuses, is considered as a Root-of-Trust to store the security configuration and the secret AES-256 keys, dedicated to secure boot process and Flashencryption. This memory is R/W protected (obviously).
This talk presents, in a methodical way, how to defeat one by one the previously listed security features, having physical access to the device and using low-cost hardware techniques such as voltage glitching, analog side-channels, micro-soldering and reverse (of course).
To the best of my knowledge, Built-in ESP32 security features such as Secure boot and FlashEncryption were never broken until now. Defeating these protections on a popular platform such as ESP32 should be considered as a serious threat by all the developers using the ESP32 as a main CPU platform or even as a WIFI/bluetooth peripheral, in their final products. Some discovered vulnerabilities cannot be patched without silicon redesign, leading to a lot of vulnerable devices on the field for the coming years.
[1] - https://www.espressif.com/en/products/hardware
[2] - https://os.mbed.com/docs/mbed-os/v5.10/porting/hardware-accelerated-crypto.html
[3] - https://limitedresults.com/2019/01/pwn-the-lifx-mini-white/
ESP32 is one of the most widely used microcontrollers, and is present in hundreds of million devices such as IoT applications, mobile devices, hardware wallets, etc. In 2019, Limited Results published a fault injection attack at Black Hat Europe which resulted in breaking the security of ESP32-V1 chip family. Therefore, Espressif patched this vulnerability and then advised its customers to use ESP32-V3, which is a hardened silicon revision.
In this talk, we present an in-depth hardware security evaluation for ESP32-V3. The main goal of this evaluation is to extract the firmware encryption key in order to decrypt the encryptedflash content that may possibly contain secret data.
First, we use Fault Injection (FI), using our homemade electromagnetic fault injector, in an attempt to access the flashencryption keys stored in the read-protected eFuses. We show by experimental results that this new silicon revision contains a bootloader protected against these attacks.
Therefore, we then explore a different attack path using Side-Channel Attacks (SCAs) on the firmware decryption mechanism, by measuring the information leakage of the firmware decryption operation during the power up. Using this knowledge, we demonstrate that the full 256-bit AES firmware encryption key can be recovered using Side-Channel (SC) analysis in a few hours with a 100% success rate. Finally, as a practical example, we apply our attack to decrypt the contents of a hardware wallet.
Jiska Classen Jiska Classen is working on her PhD at the Secure Mobile Networking Lab, with topics covering wireless and IoT security. She started reverse-engineering Fitbit firmware to enable encrypted wireless firmware flashing.
With the ongoing conversion of radio systems from traditional to digital P25 around the world the race is on to find out how to monitor, listen and abuse this technology. Some projects such as OP25 from Osmocom made very good progress enabling users to tune in and listen to them using software defined radios. However, many of the P25 features such as trunking remains to be understood and implemented. Many radio scanners made by Uniden or Grecom licensed the technologies behind P25 some years ago and produced convincing implementation. Up until now their secrets stayed protected under firmware encryption and, probably unwillingly, obscure cpu's.
This talk is a story about the process of reversing such a radio, it covers:
- Hardware analysis
- Firmware file analysis
- Format definition
- Firmware updater reversing
- Firmware encryption bypass (in a clever and utterly lazy way)
- Firmware Flash protocol definition
- Scanner code analysis
- Running custom code (yes, it works)
Today’s web surfing experience is more riddled with landmines than ever, which results in compromises of enduser systems by the use of perpetually insecure browsers, plugins, and sometimes just bad user behavior. A few changes to approaching how you surf the web can raise the bar on the risks to compromise, such as using TOR, removing Flash and Java, and more.
Additionally, many of us run or validate the security of web servers. There are a few things web server owners can do that also aid users with a secure browsing experience. More and more users are looking for these same security enhancements, and such as the ISRG Lets Encrypt project’s free SSL/TLS certificates.
This discussion will give you a short list of changes to better secure the web surfing experience both for users and customers.
After completing this session, participants will be able to:
1) Learn some optimal browser configuration options
2) Learn some browser best practices
3) Learn some web server configuration best practices
4) Learn about The Onion Network (TOR)
5) Learn about free HTTPS certificates for Web Servers.
The Fitbit ecosystem is briefly introduced to show how server, tracker
and smartphone app work under normal conditions when transferring all
data to the proprietary Fitbit cloud.
We explain in detail how we reverse-engineered Fitbit Flex firmware,
including functions such as encryption libraries, BLE communication,
proprietary protocol parsing, and accelerometer processing.
Apart from understanding the software running on the trackers we also
introduce modifications in the firmware via binary patching. We show
how we modified the Nexmon framework to alter Fitbit firmware.
A demonstration of wirelessly flashing custom firmware on a Fitbit
Flex is shown. Firmware flashing requires understanding of the
proprietary protocol, encryption, and a bunch of validity checks. In
contrast to wired flashing, no hardware teardown is required.
We publish new firmware modifications along with this talk that enable
raw accelerometer readings.
Many of the latest Flash exploits seen in the wild (CVE-2013-5329, CVE-2013-5330, CVE-2014-0497, etc) are protected with commercial tools like DoSWF and secureSWF. Malicious Flash redirectors are also utilizing the same tools. Static analysis of protected Flash objects is slow and frustrating: you need to identify the encryption algorithm and the key, implement the decryption routine, and extract the encrypted data from the Flash object. Code obfuscation techniques can also be a real pain in the *** when static analysis is the only option. If only there were a decent tool for dynamic analysis Flash files...
In this presentation, we will release and demonstrate the first tool that enables dynamic analysis of malicious Flash files. There is no need for decompilation - the tool utilizes binary instrumentation to log the interesting method calls. This approach not only significantly speeds up the analysis of individual files but also enables detailed automatic analysis of malicious Flash files.
At all times there have been bad guys, who tried to steal money. ATM machines containing vast amounts of money have always been attractive targets. Until recently, criminals were only using physical weaknesses. Skimmers and shimmers for stealing magstripe-tracking data, fake pin pads and cameras for stealing pin codes, and even fake ATMs were created.
Time passed and ATM software started to unify. Where there is unification, there are viruses. Trojan.Skimmer.*, Ploutus and other named or unnamed trojans.
And what did we see on the public scene? Vendors started discussing the skimmers problem only after they were detected in the wild. As you remember, Barnaby Jack presented "Jackpotting Automated Teller Machines" at Black Hat USA 2010. He used some vulnerabilities in ATM software. He showed that malware, was injected into the OS of the ATM via bootable flash drive or via remote management TCP port.
Barnaby Jack's work was based on assumptions that most vulnerabilities were concentrated in the host machine and that we can and should reuse software made by ATM vendors. And that's quite true, but... antiviruses, locked firmware upgrades, blocked USB connectors, and encrypted hard drives can mitigate such risks. But, what about connecting not to the host machine, but to devices themselves? What countermeasures exist, when we will try to impersonate ourselves as an ATM host? Hacking ATMs with small computer like Raspberry Pi should be impossible, but it isn't.
The point of our presentation is to draw attention to the problem, which has existed for quite a long time. The problem is usage of common interfaces (like RS232 or USB) and protocols of communication from host machine to such devices as card readers, pin pads and/or dispenser units.
For years, eFuse-based memories were used to store sensitive information such as encryption keys, passwords, and other potentially confidential pieces of information. This practice was encouraged by several vendors who leverage such memory types for protecting the debugging interfaces using a password or for official way to store encryption keys for external flash memories.
However, with the advances in technology and threat actors’ creativity, eFuse-based memories may take a hard hit on their confidentiality assurance as their physical properties could allow for a relatively easy extraction of the stored information.
In this talk we will walk you through the journey of revealing one such data storage from decapsulating the chip itself, delayering it using common household items all the way to using advanced tools such as Scanning Electron Microscope (SEM) to read value of an encryption key and thus break the confidentiality of the encryptedflash memory.
1. "Solving Chip Security's Weakest Link." Design & Reuse, April 1, 2023, [link](https://www.design-reuse.com/articles/51232/solving-chip-security-s-weakest-link.html)
2. Laurie, Adam. "Fun with Masked ROMs - Atmel MARC4." Adams Blog, rfidiot.org, 1 Jan. 2013, [link](http://adamsblog.rfidiot.org/2013/01/fun-with-masked-roms.html)
3. Hoover, William. "Looking Inside a 1970s PROM Chip That Could Change Computing." RightO, 19 July 2019, [link](http://www.righto.com/2019/07/looking-inside-1970s-prom-chip-that.html)
4. Chen, Nick. "The Benefits of Antifuse OTP." Semiconductor Engineering, 19 Dec. 2016, [link](https://semiengineering.com/the-benefits-of-antifuse-otp/)
Recent years saw a significant increase of research in GSM attacks: The weaknesses of A5/1 encryption have been demonstrated and exploited, several GPRS networks in Europe have been shown to be insecure, and an ever-growing number of Open Source projects in the area of GSM and GPRS are gaining significant attraction.
Despite the availability of attack methods, the tools are often hard to use for security professionals due to their limited documentation. The published attacks are often difficult to reimplement when assessing the vulnerability of GSM networks.
This two-day workshop will spend about half the time re-visiting the key aspects of GSM's security features and their publicly known weaknesses.
During the other half, attention is being paid to the hands-on practical sessions, where attendees will be walked through how to use the various tools for GSM security analysis like OsmocomBB, OpenBSC, airprobe, SIMtrace and others. All tools will be provided pre-compiled and pre-installed on a USB flash drive with a Linux-based live distribution.
The target audience of this workshop are GSM network operators and IT
security professionals. As attendee, you should be familiar with
working on a Linux/Unix command line shell. Prior knowledge of GSM/GPRS
network architecture is a plus, but not absolutely necessary.
Fuzzing, as a native software testing technique, is an extremely popular approach to vulnerability hunting in today's security field. The reasons are plenty: it is relatively easy to start with, features out-of-the-box tools which can be used with little to no development, only requires an initial time to set up, scales extremely well, and most importantly – often achieves good results against modern software. All of the qualities make fuzzing complementary to manual security reviews, if not replacing them altogether in some cases.<br> <br> However, fuzzing also follows Bushnell's law, as it is "easy to learn, but hard to master." While it is trivial to flip bits in the input data and wait for programs to crash, it is similarly easy to forget that there is much more to it. The overall process consists of a number of stages, and the final outcome is a product of the effectiveness of all of them. In order to get the most out of fuzzing, it is necessary to answer many questions: How to generate or mutate the inputs? How to create an initial corpus of data? How to detect software failures? How to minimize the offending samples, and recognize unique bugs? How to deal with programs expecting user interaction, using data consistency checks, compression or encryption? The list goes on and on.<br> <br> The aim of the talk is to address each question as comprehensively as possible, sharing the methods, ideas, measurements and algorithms we have developed during many years spent on fuzzing both open and closed-source software. The information will be supported by our corresponding results of two years of fuzzing FreeType, Wireshark, Hex-Rays IDA Pro, Adobe Reader, Adobe Flash Player and the Windows kernel (among other software), for a total of over 130 vulnerabilities fixed in a wide range of commits and bulletins. We will demystify fuzzing as a black box technique that "just works" regardless of the technical details, and show how each of its parts can be taken apart and optimized for maximum performance, enabling us to find new waves of bugs in mature code bases which could have been previously thought of as fuzz-clean.
"Smart" devices using BTLE, a mobile phone and the Internet are becoming more and more popular. We will be using mechanical and electronic hardware attacks, TLS MitM, BTLE sniffing and App decompilation to show why those devices and their manufacturers aren't always that smart after all. And that even AES128 on top of the BTLE layer doesn't have to mean "unbreakable". Our main target will be electronic locks, but the methods shown apply to many other smart devices as well...
This talk will hand you all the tools you need to go deeply into hacking smart devices. And you should! The only reason a huge bunch of these products doesn't even implement the most basic security mechanisms, might be that we don't hack them enough!
We start by looking at the hardware layer, dissecting PCBs and showing which chips are usually used for building those devices. Even if the firmware is read protected they still can be used as nice devboards with unusual pheripherals - if you can't flash it, you don't own it!
But you don't always have to get out your JTAG interfaces. The most simple part is intercepting an Apps communication with its servers. We show an easy Man-in-the-middle setup, which on the fly breaks the TLS encryption and lets you read and manipulate the data flowing through. This was enough to completely defeat the restrictions on a locks "share to a friend" feature and of course helps you recover your password...
Understanding the API also is the best way to actually OWN your device - giving you the option to replace the vendors cloud service with an own backend. We show how this can be for example used to continue using your bike lock when the kickstarter you got it from goes bankrupt after a presentation about it's bad crypto. Just kidding, they are already notified and working on a patch.
Also going for the wireless interface and sniffing BTLE isn't as difficult as it might sound. Turning a cheap 10 EUR devboard into a sniffer we show how to use Wireshark to dissect the packets going from and to the device and analyze the payload. In some cases this is all what's needed to get the secret key from a single interaction...
Finally we will turn into reverse engineers, showing how to decompile an android app and analyze it's inner working or even modify it to your needs. Using this we show, that a quite popular electronic padlock indeed correctly claims to use AES128, but due to a silly key exchange mechanism we can break it by listening to a single opening command. All details of this 0-day attack will be released during the talk - the vendor has been notified in May.
Last but not least we will go back for the hardware layer, showing that sometimes even simple things like magnets or shims can be used to defeat $80+ electronic locks in seconds...
Thunderbolt is a high-bandwidth interconnect promoted by Intel and included in laptops, desktops, and other systems. Being PCIe-based, Thunderbolt devices possess Direct Memory Access (DMA)-enabled I/O. In an "evil maid" DMA attack, where adversaries obtain brief physical access to the victim system, Maartmann-Moe (Inception), Frisk (PCILeech) and others have shown Thunderbolt to be a viable entry point in stealing data from encrypted drives and reading and writing all of system memory. In response, Intel introduced "Security Levels", a security architecture designed to enable users to authorize trusted Thunderbolt devices only. To further strengthen device authentication, the system is said to provide "cryptographic authentication of connections" to prevent devices from spoofing user-authorized devices.
We present Thunderspy, a series of attacks that break all primary security claims for Thunderbolt 1, 2 and 3. So far, our research has found seven vulnerabilities: inadequate firmware verification schemes, weak device authentication scheme, use of unauthenticated device metadata, downgrade attack using backwards compatibility, use of unauthenticated controller configurations, SPI flash interface deficiencies, and no Thunderbolt security on Boot Camp. Finally, we present nine practical exploitation scenarios. In an "evil maid" threat model and varying Security Levels, we demonstrate the ability to create arbitrary Thunderbolt device identities, clone user-authorized Thunderbolt devices, and finally obtain PCIe connectivity to perform DMA attacks. In addition, we show unauthenticated overriding of Security Level configurations, including the ability to disable Thunderbolt security entirely, and restoring Thunderbolt connectivity if the system is restricted to exclusively passing through USB and/or DisplayPort. We conclude with demonstrating the ability to permanently disable Thunderbolt security and block all future firmware updates.
All Thunderbolt-equipped systems shipped between 2011-2020 are vulnerable. Some systems providing Kernel DMA Protection, shipping since 2019, are partially vulnerable. The Thunderspy vulnerabilities cannot be fixed in software, impact future standards such as USB4 and Thunderbolt 4, and will require a silicon redesign.
A year ago in November 2012, Nintendo released their latest home video game console: the Wii U. While most video game consoles use controllers that are very basic, the Wii U took the opposite route with a very featureful gamepad: wireless with a fairly high range, touch screen, speakers, accelerometer, video camera, and even NFC are supported by the Wii U gamepad. However, as of today, this interesting piece of hardware can only be used in conjunction with a Wii U: wireless communications are encrypted and obfuscated, and there is no documentation about the protocols used for data exchange between the console and its controller. Around december 2012, I started working with two other hackers in order to reverse engineer, document and implement the Wii U gamepad communication protocols on a PC. This talk will present our findings and show the current state of our reverse engineering efforts.
When the Wii U was released, a few console hackers and I were talking about potential uses for the Wii U gamepad. However, before being able to use a Wii U gamepad as a remote controller for a robot or a quadricopter, the first step was to understand how it worked and how to communicate with it. This started our long journey of soldering wires on Flash chips, reading the h.264 specification and complaining about the lack of features in most Wi-Fi drivers and devices (on all platforms, Linux and ath9k devices being the least horrible).
While some “journalists” reported that the Wii U gamepad is using the Miracast™ technology, a Wi-Fi standard, it turned out that this was never the case. Instead, Nintendo decided to reinvent four different protocols (video streaming, audio streaming, input streaming as well as a light request-reply RPC protocol), and embed them in a slightly obfuscated version of WPA2, sent over the air using 5GHz Wi-Fi 802.11n. A small ARM CPU is embedded in the Wii U Gamepad (codenamed DRC) and runs a realtime operating system to handle network communication. In the Wii U, another ARM CPU (codenamed DRH) does the same thing.
In this presentation, we will go into the details of how we went from a 32MB binary blob to a proof of concept of Wii U gamepad “emulation” on a PC, including full documentation of the wireless communications obfuscation layer and partial documentation of the four data exchange protocols used on the gamepad.
<p>There are some reasons why vendors keep their details of controller and flash chip information confidential. One of the reasons is that their unique management techniques are deployed differently, that is relevant to SSD capacity and speed, such as TRIM, Garbage Collection, and Wear Leveling are preserved code on flash. Despite these techniques being used by vendors, we show that SSD do not erase all the stored physical data because it might wear lifespan sooner.</p><p>We figured out that SSD still leaves sensitive data when overwritten to the same logical block, so they do not overwrite to fixed physical block, they only grab other empty physical block and write over that, so they leave the erased data. For these analyses, we perform extract the Nand chip data with only internal controller PBA manipulation because logical block address cannot be used anymore in normal. In the case of SSD used to crypto engine built into the SSD's controller encrypt every block data stored on the flash memory, we recover old LPN which used before erased/overwritten to be decrypted naturally in the controller.</p><p>As a practical case, we study how to recover data after a Ransomware attack even if prior L2P table's value has changed with new one. We also analyze that feasibility to recover data depending on the number of overwrites on same physical block.</p>