For the 21st edition of the SSTIC, RandoriSec was represented by 9 people. As usual now, the conference took place at Couvent des Jacobins, in Rennes, from 7 to 9 June 2023.
This year, the conference was - again - very nice with technical talks and a very cool social event. Thanks for the organizers and the speakers!!!
Here is a quick recap of interesting talks from this edition.
Day 1
Ultrablue : contrôle d’intégrité du démarrage d’un PC via Bluetooth
Video talk / Slides / Tool
In this presentation, Nicolas Bouchinet presented Ultrablue, an open source project developed by the French National Cybersecurity Agency (ANSSI). The standard use case for this is when one wants to protect his computer against offline attacks, especially the “evil maid attack” scenario. The main goal of the tool is to validate the computer bootchain integrity. In order to do that, Ultrablue uses the TPM to compute hashes. Each hash corresponding to the different elements of the bootchain (UEFI, bootloader, kernel, etc.). Then, the Ultrablue mobile application (Android/iOS) is used to store an initial (non-compromised) reference state. After that, the bootchain integrity is verified during each computer boot, using the reference state. All the communications between the computer and the mobile app are done over Bluetooth.
Randomness of random in Cisco ASA
Video talk / Slides / Article
Entropy gathering on network devices is a task that has to be taken seriously. The boot sequence is deterministic, and such devices happen to generate certificates at boot time. If the device uses bad entropy sources, they might end up with collisions in generated private keys. This is a huge security risk since it can lead to a private key recovery.
Arnaud and Ryad were working on a dataset of 250M x509 certificates for development purpose. They noticed that 2 subsets of ~300k and ~200k certificates were containing key collisions. These two subsets contain respectively ECDSA and RSA certificates generated by Cisco ASA routers. They decided to take a look at entropy sources and the keys generated on these devices.
Key generation is a 3-step process. First, you need to get good entropy sources. Then, you need to lift these sources to obtain a high-entropy seed. Third, you can feed this seed to your favorite key generation algorithm to get your fresh key.
By reversing the Cisco ASA code, they were able to reimplement and reproduce exactly the whole key generation process of the device. They found out that poor entropy sources were used as a fallback when better sources were not available. Entropy sources include rdtsc (CPU counter), gettimeofday, rand/srand Linear Congruential Generators (LCG), uninitialised buffers/ASLR, hardware-based generator (Cavium crypto accelerator) and rdrand/rdseed API.
They found out that in the worst case, entropy sources were providing as low as 45 bits (rdstc + rounded gettimeofday), allowing bruteforce in a reasonable time.
They conclude by giving few advices on key generation on this type of device, such as not allowing really poor entropy sources (rdtsc or time-based sources) even in the worst-case scenario.
gmsad: usage of gMSA (group Managed Service Account) under a Linux environment
Video talk / Slides / Tool
In this talk, William BRUNEAU and Vincent RUELLO have presented the tool gMSAd (gMSA stands for “Group Managed Service Accounts”). They have presented a use case where few Linux service accounts needed to be managed from the Domain Controler and with redundancy. They showed that using the msDS-ManagedPassword attribute on a gMSA account will allow managing those service accounts. The tool gMSAd is written in Python, and it can retrieve the new gMSA password, update the service accounts password and manage the keytab on Linux servers (which contains the Kerberos keys).
In production, this tool can help manage a Kerberos service under Linux servers on Active Directory environment. In audit, the tool can be used to retrieve the keytab for a gMSA.
The tool is not easy to deploy and the speakers mentioned that this will be their next step in order to make it easier to install.
OpenWEC: a Windows logs event collector server based on the WEF protocol
Video talk / Slides / Tool
In this talk, William BRUNEAU and Vincent RUELLO have presented another tool that they have created to manage Windows events based on the WEF protocol (Windows Event Forwarding). The tool called OpenWEC, runs a service which collects Windows events retrieved by the agents deployed on the workstations. They created this tool because the built-in Windows Event Collector (WEC) have no redundancy, misses useful information, may be hard to integrate to a SIEM. They wanted to recreate the wheel in order to better understand the tool, adapt the tool to their usage, get any information needed. It uses the WEF protocol which is based on Web Services for Management (WS-Management) with a documented Microsoft layer, uses HTTP/SOAP, manage authentication and encryption. The events are compressed and few configurations are possible.
The tool is written in Rust, supports compression, the Kerberos protocol, and the “push” mode only. It has different supported outputs. The next step is to implement TLS, add the package to Linux distribution and add new output formats.
Batterie à bord : quand les jauges de carburant dépassent les limites
Mobile devices have a lot of sensors. Some modern ones ship with a fuel gauge, which is a chip that optimizes battery power management. In this research presented by Vincent Giraud, this gauge is abused for performing side-channel attacks.
Android 12 introduced a frequency limitation that prevents applications from probing sensors at a high rate, but this blacklist does not include the newly introduced fuel gauge sensors, which makes it possible to probe it at the maximum hardware-supported data date. By querying the battery status at a high frequency, the researcher was able to obtain data that leaks information from other apps through a side channel. He demonstrated his findings by running a test application that asks for a pin code, and by capturing a lot of data, doing some statistical analysis to determine the peaks, and bruteforcing the likely pin numbers using a recursive tree-based code-finding algorithm.
Day 2
Bug hunting in Steam: a journey into the Remote Play protocol
V. Ricotta came back this year for another presentation. He presented a way to search for security flaws in the implementation of a remote protocol in Steam. +Steam allows playing remotely some games from another account. This is the Remote Play Together feature. Valentino chose to target the protocol associated to this feature. The first step was the reverse engineering of the Steam application for Windows. He used the Android application which contains the same implementation with symbols. Once he had deeply reversed the application, he started to develop a fuzzer to fuzz this protocol. As Steam protocols are developed using protobuf, he implemented a mutation engine based on the protocol description in protobuf. +His fuzzer is able to target both client and server sides of the protocol. Finally, he was able to find several vulnerabilities. They have been reported to Valve. At the moment, none of the tools he developed have been publicly open sourced.
Abusing Client-Side Desync on Werkzeug to perform XSS on default configurations
Video talk / Slides / Article
In this talk, Kévin Gernot describes how he discovered a vulnerability in Werkzeug using a client-side desynchronization to exploit Cross-Site Scripting vulnerabilities on default configurations.
Werkzeug is a Python Web Server Gateway Interface (WSGI), that allows a developer to quickly set up an operational HTTP server. He noticed a parsing bug in Werkzeug: unused POST data in HTTP keep-alive requests are prepended to the next HTTP request. This is a client-side desynchronization (CSD) happening in the connection queue. CSDs are often used to leak cookies or authentication tokens. Here, Kévin tries to transform the CSD into an XSS vulnerability.
His idea is to use the CSD to desynchronize a JavaScript resource loading request to replace it with an attacker controlled resource via an open redirect (302). To find a working open redirect in Werkzeug, he relied on an old vulnerability (CVE-2020-28724) that wasn’t properly fixed, allowing a redirection when sending a complete URL in the HTTP GET path.
Using a POST form with an enctype of text/plain to prevent the browser from encoding the payload, he was successfully able to turn the CSD into an XSS using the previously found open redirect.
An interesting bonus is that since browsers are caching the location of resources, the XSS is triggered at each page refresh as long as the cache exists.
To fix it, Werkzeug disabled keep-alive connections, preventing the client-side desynchronization. It is important to note that Werkzeug is a development WSGI, not meant to be used in production.
Rétro-ingénierie et détournement de piles protocolaires embarquées, un cas d’étude sur le système ESP32
The ESP32 is a widely used System-on-Chip, it supports several communication protocols (Wifi, Bluetooth Low Energy, Bluetooth Basic Rate/Enhanced Data Rate).
During this presentation, two researchers (Damien Cauquil and Romain Cayre) managed to hijack the network stack of the equipment, by injecting code into the functions that transmit and receive Bluetooth low-energy packets. Reception was limited to packets from connections initiated by the ESP32. They were able to transmit data and control packets, and to carry out inter-protocol attacks, by disabling certain processing features carried out at the physical and data link layers (checksum verification, dewhitening, etc.). They managed to perform BLE and 2.4 GHZ Wifi jamming, and obtained a primitive for transmitting GFSK-modulated signals, which can be processed by other devices (wireless keyboards and other equipment).
Day 3
Analyse statique de code avec Semgrep
Claudio presented Semgrep, an open source static code analysis tool.
He presented the Semgrep internals and the core features (Search mode, Taint mode, etc.) He talked about the other static code analysis tools (CodeQL, Weggli, etc.) and in which way Semgrep differs from them. Then, he showed several examples on how to write patterns to identify vulnerabilities like SSRF or SQL injections. The talk was a bit short, but quite interesting.
Semgrep source code can be found on Github: Semgrep
Reproduction automatisée de vulnérabilités logicielles dans un environnement conteneurisé. DECRET : DEbian Cve REproducer Tool
In this talk, C. Parssegny presented a tool he developed with G. Thomas, M. Bacou, M. Bélair and O. Levillain. DEbian Cve REproducer Tool (DECRET) is a tool to automate the creation of vulnerable Debian containers to certain CVEs. It was initially created to test SNAPPY, a framework to program kernel-level policies for containers.
DECRET relies on Debian because it supports a vast number of Linux packages, has some open metadata on public CVEs (Debian Security Advisories) and makes regular snapshots of its repositories. DECRET first calls the Debian API with the CVE name to retrieve the source package, the impacted Debian release and the fixed package version. It then retrieves the previously vulnerable version, the hash of the package and the binary names. Finally, it retrieves using the hash the timestamp of the package to download the correct Debian snapshot. exploit-db is then used to retrieve a public Proof of Concept to test the vulnerability.
DECRET is a great tool to quickly reproduce environments to test CVEs. The limits of this tool are the lack of kernel exploits, public PoCs that are rare and the Docker isolation that’s not great (docker escapes can happen).
Sécurité d’un réseau mobile et responsabilité d’un opérateur
5G is the fifth generation of mobile networks. It brings new promises, in terms of performance and use cases, but also in terms of security.
In this presentation, Pascal Nourry presents the security architecture of 5G networks, and the improvements compared to previous generations of cellular networks. Among the novelties:
-
The protection of the identity of the UE, by avoiding the transmission of the UE identifier (the IMSI) in clear on the network.
-
The mutual authentication between the UE and the network, which allows avoiding attacks by fake mobile networks.
-
Encryption and authentication of messages on the control and user planes.
-
Mutual authentication between the virtual network functions within the core network, through the use of TLS.
-
Authentication and encryption of the signaling messages exchanged between different providers.
The network operator has some responsibilities to guarantee a secure environment, like ensuring data redundancy and availability, system hardening and the use of secure software, the use of hardware security modules for example, the activation of the optional security features of 5G networks, and the conduct of security audits on the network to ensure a good security level.