SSTIC 2015 – Day One
As every year, Intrinsec was present at the most anticipated IT security conference in France: SSTIC. This was the 13the edition which was held in Rennes.
You will find all the proceedings, presentations and videos from this 2015 edition at the following address:
Other summaries are available online:
- A look back at some conferences by XMCO
- NoLimitSecu Podcast by Nicolas Ruff, Stéphane Sciacco and Christophe Chasseboeuf
- Liveblogging from n0secure
Security and engineering (in Chromium) — Julien Tinnès
Julien is a member of the Chromium security team. During this presentation, he shared his perspective on the evolution of security since his first talk at SSTIC in 2005. At that time, awareness of security vulnerabilities (such as Blaster and Sasser) was just beginning, and security in engineering was very rare. Now, in 2015, vulnerabilities appear on the front page of news outlets with "fun" names (POODLE, Heartbleed, BEAST, etc.). Julien then presented some security features implemented in Chromium: Privilege Isolation (process separation), Sandboxing, and Seccomp-bpf (presented as a kernel firewall). He also discussed ways to bridge software engineering and security engineering. For example, separating tabs into processes improves stability (software engineering) and makes it easier to implement sandboxing mechanisms (security engineering). In conclusion, Chromium's development is driving simultaneous improvements in performance and security. Nevertheless, further efforts are needed to ensure a secure connection between the browser and the user.
PICON: Control Flow Integrity on LLVM — Thomas Coudray, Arnaud Fontaine and Pierre Chifflier
This presentation wasn't about PICON beer, but a completely different topic: "Protect Integrity of Control Flow." The idea is to design a tool to limit the potential for exploiting vulnerabilities in a program by verifying the integrity of its execution flow.
The tool's creators examined existing solutions and realized that while interesting, they were incomplete. Each defined integrity control in its own way, and none implemented all the principles. To develop their tool, they based their work on four core principles:
- Protect all function calls and function returns;
- Protect the connections;
- Detect as soon as possible if the execution flow is compromised in order to terminate the program;
- To have information available for a forensic analysis.
In conclusion, this is still only a proof of concept, but the work done is promising. To test the tool: https://github.com/ANSSI-FR/picon
Triton: A concolic execution framework — Florent Saudel and Jonathan Salwan
Triton was originally a final year project by Florent and Jonathan as part of their Master's degree. Today, this project is supervised by LaBRI (Bordeaux Laboratory for Computer Science Research) and sponsored by Quarkslab.
Triton is a concolic execution framework. The term "concolic" refers to the combination of two approaches: concrete execution (dynamic analysis of a program) and symbolic execution (static analysis).
Triton builds upon Intel's Pin tool, dedicated to code instrumentation, and extends its functionality. It notably provides:
- A symbolic execution engine;
- A color analysis engine;
- An API.
Currently, the tool only supports 64-bit binaries.
The tool is available on Github: http://github.com/JonathanSalwan/Triton
REbus: A communication bus facilitating cooperation between security analysis tools — Philippe Biondi and Xavier Mehrenberger
As the presentation title suggests, REbus is a tool for automating the execution of analytical tools. Why create such a tool? The problem is that in certain fields, such as network reconnaissance, threat intelligence, or forensic analysis, an analyst will use different tools to solve a problem. These analyses generally involve repetitive tasks.
The goal of REbus is therefore to provide a framework that allows:
- To easily add features and tools;
- To automate repetitive tasks;
- To store the intermediate results of the tools.
To achieve these objectives, REbus was designed as a decentralized workflow, i.e., a workflow for each tool, which share a communication bus.
REbus is available here: https://bitbucket.org/iwseclabs/REbus A demo is available here: https://bitbucket.org/iwseclabs/REbus_demo
Abyme: A Journey to the Heart of Recursive Hypervisors — Benoît Morgan, Eric Alata, Guillaume Averlant, Vincent Nicomette
The authors' idea is simple: is it possible to create a "recursive" hypervisor? What is the advantage of a recursive hypervisor other than for performing inception? It notably allows for adding security features at each virtualization level, for example, by using a hypervisor dedicated to a specific function (e.g., porting a network card driver without accessing the rest of the system). The implemented architecture was presented, along with a proof of concept. In conclusion, performance is not yet satisfactory.
Defense and attack strategy: the case of game consoles — Mathieu Renard and Ryad Benadjila
This presentation provided an overview of the evolution of game console security, focusing on four examples:
- The PlayStationBy default, there was a lack of security in the design. From 1995 onwards, this console was widely counterfeited. The games (CD-ROM boot track) and the consoles (BIOS) were region-locked. The absence of security mechanisms allowed for the rapid development of modchips that bypassed these restrictions.
- The XboxSeveral security measures were implemented, including a trusted boot chain, hard drive access control, and binary signing. However, the boot ROM's 512-byte limit and identified security vulnerabilities within it allowed the trust chain to be broken.
- The Xbox 360: good software architecture and a well-designed boot chain. However, an implementation error in the hypervisor allowed code execution (the King Kong attackThis vulnerability was exploitable only with the King Kong game (hence its name), but was patched before becoming public. Unfortunately, it was possible to downgrader the console kernel to a version vulnerable to attack.
- The PS3 : an interesting exotic hardware platform with protections against DMA attacks.
In conclusion, security vulnerabilities can appear at both the hardware and software levels; the security of a product must take into account the existence of these two distinct attack surfaces.
Hardware reverse engineering for reversers Software: The Case of an Encrypted External Hard Drive — Joffrey Czarny, Raphaël Rigo
The Airbus Group wanted to test the effectiveness of an encrypted hard drive. Joffrey and Raphaël explain the approach used to test the Zalman ZM-VE400 enclosure. The goal was to ensure that the implemented encryption was correctly designed and robust. In this case, the enclosure uses the AES-256-XTS encryption algorithm. Their research indicates that the encryption is independent of the enclosure (everything is stored on the hard drive), a reserved area is located at the end of the hard drive, and firmware updates are encrypted. Although the authors were unable to identify the data at the end of the drive, and therefore bypass the encryption mechanism, this presentation demonstrated various embedded hardware testing techniques.
CLIP: A pragmatic approach to designing a secure OS — Vincent Strubel
For those who attended this year's JSSI (French National Cybersecurity Days), this presentation was quite similar. The idea was to showcase CLIP, the hardened and secured Linux operating system developed by ANSSI (French National Cybersecurity Agency). This OS is not intended for public use, but is primarily for the French government and critical infrastructure operators (OIVs) for office applications.
CLIP primarily uses Linux capabilities to partition the system into different areas based on their sensitivity. For example, a high level for confidential information and a low level for public information.
Voice command injection on smartphones — José Lopes Esteves
José Lopes Esteves demonstrated a method for sending voice commands to a smartphone. The idea is simple: modern devices can receive voice commands (Siri for Apple, "OK Google" for Android, etc.). For some devices, voice commands must be activated with a button, while for others, a keyword is sufficient. The attack requires the victim to use headphones, the cable of which acts as a radio antenna (FM and AM). By transmitting on this frequency band and modulating it, it's possible to generate waves that the smartphone interprets as voice commands. The attack's range is limited (between 2 and 5 meters) due to the required transmitter power.
RowHammer – Nicolas Ruff
Nicolas Ruff presented the Rowhammer attack, which can be performed on DRAM. Google's Project Zero team had already published a detailed post on their blog: http://googleprojectzero.blogspot.fr/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
The idea behind the attack is simple: it involves regularly accessing specific memory locations in order to trigger... bits flips on adjacent portions on the memory modules. Thus, the Project Zero team was able to elevate a user's privileges on a Linux system using this technique.
FlexTLS: From prototypes to exploiting vulnerabilities in TLS
FlexTLS is a tool designed to test the security of the TLS protocol. The motivations are clear: over the past four years, more than twenty vulnerabilities have been discovered in the protocol and its implementations (BEAST, CRIME, Heartbleed, FREAK, etc.).
FlexTLS is based on a cryptographic library called miTLS which is formally verified and implements TLS (www.mitls.orgThe use of this tool has made it possible to identify new vulnerabilities in the protocol (FREAK, SKIP and Logjam in particular).
It should be noted that a detailed presentation on Skip, Freak and Logjam attacks was given at OSSIR: http://www.ossir.org/paris/supports/2015/2015-06-09/p.pdf
