SSTIC 2018 Part 1
From the 13 to 15 June, I was happy to attend for the first time the 0X10 edition of the SSTIC, that traditionally takes place in Rennes every year in June. This year, the event gathered 800 participants, mostly security experts, pentesters or researcher, in the luxurious and brand new Couvent des Jacobins.
I will share some of the notes I took during these 3 days of conferences. Unfortunately, I only report the presentations relevant to my field, or that caught my attention: #iot #embedded #hardware #sidechannel
Note that the conference proceedings and video recording are already available on the SSTIC web site. Awesome!
Opening Keynote: Closed, heterogenous platforms and the (defensive) reverse engineers dilemma
Halvar Flake
“Halvar Flake” gave us a retrospective on the reverse-engineering from his experiences. In fact, tools have changed a lot since it started 20 years ago.
IDA has not changed a lot in 20 years and remains his favorite tool for binary reverse engineering. After 13 years of RE, Halvar made a break of 6–7 years during which he managed dev and security teams. And he came back to RE:
Many things have evolved: the solvers have become usable to generate entries for programs, a lot of tools for RCE has been developed: r2, frida, angr, … But when you try them on real cases, it does not work. Example with MPENGINE.DLL for which is difficult to obtain coverage traces. The live debug on mobile systems are difficult to get, etc.
Why does not it work very well? Some reasons are external to the reverse community, others are related to this community. Platform providers like iOS or Android sacrifice “debuggability” to stop the reverse for “security” purposes. However, that is in favor of “big” players (hackers groups or state hackers) who have the means. POn the other side, defenders who do not have the means are left behind.
Example with iOS, for which you must set up ridiculous and expensive hacks to debug an application correctly. Manufacturers are often advised to remove the JTAG, even when physical attacks are not part of the threat model. Consequently, we lose observability, breaking the analysis and investigation capabilities of these devices.
Reducing the access to debugging means on a device decreased the population able to work on its security. In fact, fewer hackers make the curing of a platform slower, which benefits real attackers.
Time-to-market has forced developers to reduce the dev, deployment & testing time. So they often work on WIP devices, not very debuggable. That complicates the diagnosis of bugs and threats in these applications, reducing their safety.
The market for RE products is very small and as a result support only between 12 to 60 engineers in the world.
The “technical” cost of designing RE tools is not covered by benefits because of the small market
Also, RE scripts, are often written in a hurry and become later tools used in the long run because anything else exists. The problem is that the RE community does not take the time to think about the future and invest in it. For instance, they do not pay attention to the memory footprint of scripts, or the ability to distribute the computation on multiple nodes.
In addition, a large number of RE frameworks have similar features but do not cover all your needs. Some of them are far from stable, or CPU/memory efficient. Ha said that “It looks like the JavaScript community”, and a lot of stuff is done twice or three times, on X frameworks. And they are sometimes developed in a hurry, just before CFP deadlines.
Also, in the literature, many problems have been “solved”, but in reality, for everyday work, these tools are far from keeping their promises. In fact, published results are rarely reproducible, data are not available, and sources are rarely published. Consequently, when we read a paper, we can no longer distinguish if the author exaggerates, or if the problem has been really solved.
The RE tools often focus on the source code and the recovery of the latter, but rarely on the understanding of the software package we reverse.
Finally, Halvar introduce some proposals:
- it is necessary that the developers of software or hardware platforms make them debuggable to facilitate the analysis.
- it would be necessary to find a way to exchange the RE data, using a standard step to move from the binary to the assembler, to the assembler to CFG, etc
- intermediate representation adapted to the different data used and generated by the reverse tools should be standardized. Thus, we could switch from one tool to another without having to re-develop all existing scripts & tools for this new framework
- a Linux distribution for the reverse as there is for the pentest, on which we could have all the necessary tools
- to improve the reliability of RE tools, we need data to test and validate them.
With the cloud, any software can run on machines all over the world. But debugging in the cloud is painful because there is no “cloud debugger” to manage such system. Dealing with CPU/GPU/μC/FPGA infrastructures is a big challenge for RE tools. These components are not well documented. Thus, a vulnerability on this type of components will be very difficult to manage for defenders (e.g. Spectre / Meltdown …)
Backdooring your server, but its BMC: the HPE iLO4 case
Alexandre Gazet, Fabien Perigaud, Joffrey Czarny (Airbus)
This talk presents the pentest of the iLO4 HP system and some critical vulnerabilities the author found. iLO systems are widely used by many server manufacturers as a stand-alone and independent ARM-based chipset with its own RAM and network interface. This system starts as soon as the server is powered. These iLOs are exposed on production VLANs, and often exposed even on the internet. A first exploit allows them to retrieve information in memory on the system managed by the iLO and write code arbitrarily to obtain a shell via netcat on the main server.
The iLOs web service have been the subject of two CVEs in 2017. The webservice makes a massive use of scanf to parse HTTP headers. Unfortunately, there are some buffer overflows, with one in the Connection header that allows an attacker to overwrite a variable, ann thus bypass the authentication and access the REST API of the iLO with admin rights.
Relying on this RCE, the speakers have worked on the ILO firmware to patch the bootloader, to later patch the kernel and insert a backdoor in the userland, in the iLO flash memory. The authors choose the web server as the target to install the backdoor since it has all the communication primitives, along with a DMA access to the memory of the main machine.
To install the backdoor in the Linux system, an attacker must create a thread in the kernel, allocate memory for the communication channel between the iLO and the Linux, and set up the execution primitives of the commands received on the memory buffer
T-Brop — Taint-based Return Oriented Programming
Colas Le Guernic, Francois KHOURBIGA (ANSSI)
The speaker began introducing the exploitation of a buffer overflow vulnerability by re-using the existing code in the binary. They reminded the protection that must be circumvented.
Code reuse attacks reuse bits of code, called gadget. These gadgets often en with a ret instruction. The DEP is not enough, it must also use the CFI, etc ...
To find these gadgets in a binary, 2 approaches exist:
- the syntactical approach, where the tool makes a
grepin the program (e.g. rp++) - the symbolic approach, where the tool does it in symbolic. It is more efficient but is very costly in time (e.g. angrop).
With RP ++, it is fast but we are fig to build the ROP chain using grep à la mano the gadgets we want. With angrop, it is very and can take between 15 in fast mode and hours.
In order to take the best of these 2 approaches, the speakers propose, T-Brop, a hybrid approach that is faster than symbolic analysis, and more expressive than syntactical approaches. So we have a tool less efficient than syntactic but faster than the symbolic.
T-Brop is a little faster (7min) and offers some interesting gadgets based on rsp & esp, or data above the stack. In a nutshell, Angrop is good for highway cases, RP++ is for regexp lovers, and T-Brop sometimes offers some tricky stuff.
T-Brop is based on hue to manage which register depends on which other in the chain of gadgets. This influence is represented as dependency matrices for each gadget. To determine the impact of the sequence of gadgets on the registers, it is enough to make a product of matrix. By generalizing that, it is possible to identify whether or not it is possible to influence a target register by linking together a set of gadgets, and which registers to target in order to use the ropchain we built. T-Brop implementation is based on python3 and is available on Github
Risques associés aux signaux parasites compromettants : le cas des câbles DVI et HDMI
Emmanuel DUPONCHELLE, Pierre-Michel Ricordel
There are radio signals transmitted willingly (radio, WiFi, Bluetooth, etc), and radio signals emitted unbeknownst of the system. For example, the cathodic screens of the past that generated radiations that could be received and decoded by means of an antenna. Now with the Software Defined Radio (SDR), capturing these signals only requires a small dongle with a tiny antenna. Although cathodic screens have disappeared, many components emit on our behalf, especially video cables between computer and screen. The speakers present a demo using a small USRP and the tempestsdr, SDR tool to recover this kind of signal. The speakers can intercept the signal of their own laptop they were using during the presentation.
The talk follows with some insights on VGA, HDMI and DVI signals. Faster is the potential variation, stronger the radiation. In VGA, it does not go fast, so the fronts are soft, and the radiation is weak. With DVI, the frequency is fast, and the changes of fronts are strong, and so the radiation level is high.
To avoid radiation, the armor must be complete and if there is a hole, it will leak … and so your screen with.
Three vulns, one plug
Gwenn Feunteun, Olivier Dubasque, Yves Duchesne (Acceis)
The 2 speakers introduce the reverse engineering of a WiFi smart plug and the threat they found in the WiFi PSK exchange mechanism between the plug and the smartphone.
The “smart” plug use WiFi with a “smart” pairing technology avoiding to manually enter on the plug the PSK of the WiFi AP. That is not based on WPS but the configuration is achieved using an android application. In the application, the user must type the WiFi password, and choose the plug that has been detected by the application.
The authors begin by sniffing the network and look at the WiFi packets exchanged to send the security information. They found broadcast messages that consist of a series of fixed-size messages and then variable-sized packets. If fact, the plug manufacturer built a side channel using the size of the encrypted broadcast packets to encode the PSK. Then, reading the doc of the WiFi module, we can see that the wireless module is listening on a UDP port and accepts AT commands that can everything in the WiFi module configuration. Also, on the PCB, a UART can be leveraged to recover the key of the WiFI network, or to change the module configuration. The speakers have developed a patch to enable WPS sending the right AT command with an Arduino.
Escape room pour la sensibilisation à la sécurité informatique
Eric Alata, Erwan Beguin, Vincent Nicomette (INSA Toulouse)
The speaker presented an escape room his team developed in a student project at the INSA Toulouse. The escape room aims to teach the good habits of computer security and how to protect themselves from current social engineering attacks. Two scenarios are proposed. The first one aims to secure a working environment. In the second one, 3 participants must steal documents from a company.
Du PCB à l’exploit: étude de cas d’une serrure connectée Bluetooth Low Energy
Damien Cauquil (Digital Security)
During this talk, Damien Cauquil (@virtualabs) introduce a methodology to conduct the pentest of an IoT device, considering hardware and software attacks. Unfortunately, the speaker laptop rapidly went wrong and the presentation was a bit hashed. In any case, I highly recommend to read the paper in the conference proceedings.
Hacking hardware is not always as easy as taking a logical parser, wiring a uart, and so getting a shell. In practice, a methodology is needed:
- Functional analysis of the device to be tested
- Hardware vulnerabilities research
- PCB reverse engineering
- Firmware, mobile application collecting and disassembly.
- Software vulnerabilities research
Damien then applies his methodology, giving a smart lock use case. Studying the lock usage is essential, and a careful observation gives the following insights:
- 18 hours of autonomy implies the use of a low energy technology
- there are no electrical protections against the over tension on the USB port
- there is no component to detect the position of the rotor of the lock, which means that the software does not know in which position is the lock
- on the lock PCB, there is a nRF52 BLE module and an engine driver for the motor.
Then, the interconnections between the components can be determined by using a multimeter or studying their datasheet. Once the JTAG / UART / SWD are identified, the attacker can try to recover the firmware from the MCU, and begin its analysis. The firmware can also be recovered at the network level or on the smartphone during the firmware update.
The firmware, as the Android application, can be disassembled using IDA PRO and JADX respectively.
After a quick look on the code, Damien discovered that the authentication part of the lock is broken. In fact, the pseudo-random nonce used for encryption is … always set to 1. Also, the BLE connection between the smartphone does not require pairing meaning that a man in the middle can easily be performed.
Finally, the speaker presents this BLE MITM attack using the BtleJuice tool it developed. The attack allows him to capture the authentication token, and to replay it.
Wookey: USB devices strike back
Arnauld Michelizza, Jérémy Lefaure, Mathieu Renard, Philippe Thierry, Philippe Trebuchet, Ryad Benadjila
The authors present a device that is robust against BadUSB attack. Their device should not be too expensive and be shareable in open-hardware / open-source.
As part of the USB standard, it is the device that declares its functionality to the OS. Thus if the device is lying on its features, the OS keeps trusting the key: that is the BadUSB attack scenario. Along with this attack, the speakers also want to protect themselves against the theft of crypto data, so it needs a SoC solid enough to allow their implementation in a safe way. The use of a secure-element to store encryption keys, a keyboard/touchscreen independent of the host for entering the pin code, a μSD slot to host the storage, and two USB ports.
The firmware of the keys contains a bootloader firmware and a backup firmware in case of a glitch. One part is reserved for crypto signature, and a release mechanism triggerable by pressing a physical button.
Each software module managing each function of the keys must be isolated from the others. The speakers implement their own micro-kernel, called Ewok, and manages application modules of crypto, USB, pin code, secure-element. The MPU is used to define rights and attributes on memory regions to ensure isolation without an MMU.
To secure the syscall, which is the only attack surface between the app code and the kernel, the speakers used Ada and SPARK. Thus, depending on the criticality of a functionality, the speakers chose the appropriate programming language, from the least restrictive (the C), to the most constrained (SPARK).
Dump de flash sur circuit imprimé
Emma Benoit, Guillaume Heilles, Philippe Teuwen
The speakers give their feedback on developing their own chip adapter to dump the memory of a flash chip. When we want to recover the content of a flash, we often try to connect to the pins of the chip and dump. But sometimes we come across a chip whose pins are under the chip, so we must unseat the flash, and then use the right adapter or make our own. The speaker decided to make his own. The authors designed a PCB using KiCAD and present few methods to build it:
- a chemical method
- using a CNC to cut the tracks directly into the copper, then adding a green insulating paste
To solder a BGA component by hand, it is necessary to use a microscope, and it looks very painful.
As soon as the homemade chip adapter is built hardware attack, we can micro solder the “adapted”
The global investment cost is about 1200 € for both techniques, the per PCB cost is negligible. If the BGA component pitch is very tiny (~um), a CNC laser must be used to gain precision.
That’s all for the first part! But you can go to the 2nd part of my notes
