This year has been very fruitful for Quarkslab with lots of research, new challenges, newcomers, open source success. It is now a tradition to look back at what we have done during a small conference named “Quarks in the Shell” or just "QITS", where we share the year experience with our customers, partners and friends. QITS meeting is one of the output channels for our research work that is also reflected in internal tools, our open-source projects (e.g. Triton, LIEF and QBDI), and our products (IRMA Enterprise and Epona).
As a company dealing with security and research, we focus mainly on two topics:
Securing the “content”: content is mostly data, whether they are personal data, cryptographic keys, music, video, … We do that with both cryptography and obfuscation.
Securing the “container”: not talking about Docker here, but everything handling content (data), e.g. a VPN, a browser, a mobile app, an ECU, a game console, … So, it is about vulnerabilities (finding and removing them, killing class of bugs, detecting and containing exploitation) and about software architecture.
"Securing" is not only about building proper tools and using them. The way we perform security is changing a lot also, mostly because security goes everywhere. The consequence is that it requires more and more processing and assessments, to be able to deal with the multiplication of code everywhere: desktops and servers are only a small part of today's IT. Every car has many calculators, a mobile phone gets up to 3 main CPU each with its own purpose, and our toaster and coffeepots are connected to the Internet through our home network. Being able to automatize and schedule security becomes mandatory because of that change.
QITS is a good opportunity to discuss face to face with a lot of different people about their expectations and their problems, and to present some of the works we did during the past year.
Let’s now have a quick overview about what we discussed this year.
Obfuscation: from both an offensive and defensive point of view
Lastly, we have studied the state of the art of mobile game protections and compared them to desktop gaming situation. The conclusion is crystal clear: there are almost no protections on mobile games. Desktop games have years of experience in anti-cheat and licence protection with virtual machines, kernel engines, anti-tampering and complex tricks, but so far, mobile games rely mostly on quite weak rooting and jailbreak detections and server-side protections.
We also looked into the hardware protections used in the Wii-U and Switch gaming consoles. Controlling the hardware, with a root of trust and a trusted execution environment, clearly raises the bar for attackers. Unfortunately for Nintendo, although they do quite a nice work backporting Webkit’s patches to their browser, they missed one which did not seem critical except it allowed to access the OS. Hence, 4 exploits are needed to get into the Switch from a browser. Earlier this year, a full compromise was released due to a USB buffer overflow in Tegra X1’s Boot Rom found by fuzzing. Hardware is unforgiving, one mistake completely kills the device's security standing.
On the defensive side, we went back to our work on obfuscation. Epona has evolved quite a lot this year. We improved the mixed boolean arithmetic (MBA) used in several obfuscation layers, and worked on the diversity of these expressions. We also worked on some code and data integrity mechanisms. An underestimated challenge when it comes to designing a compiler / obfuscation toolchain is also to make it user-friendly, by not being intrusive in the target code, and give full control on the level of obfuscation strength to the user. We also explained white box cryptography and introduced new directions we currently explore. We presented the latest side channels attacks and the state of the art of WB crypto, and some ideas we are experimenting with to provide WB with different properties. Not much more on that for now, in order not to spoil later updates.
IRMA at scale with Cyber Test Systems
IRMA Enterprise is a flexible file analysis platform, using multiple analysis engines to increase threat detection and provide assurance in many different use cases.
We also provide IRMA as an open-source tool, but IRMA Enterprise comes with more advanced capabilities. In both cases, we focus on user privacy and no information is shared outside of the user's environment.
We partner with Stamus Network to extract files from network traffic with Suricata, then submit them to IRMA. In order to get good enough response time, we also partner with Cyber Test Systems to deal with network traffic and an appropriate appliance.
We presented how CTS-IRMA was used in several cyberdefense exercises, national and international. The contestants were using IRMA to analyze many files transmitted over the network, on hard drives or USB sticks. They also had to share information about these files, which was made easier since we added a simple export report feature to facilitate the gathering of the information.
The second part of the talk was about benchmarking IRMA Enterprise <https://irma.quarkslab.com>.
Probes are the components in IRMA digging into files and allowing the scalability to process really many files. It can be a simple script extracting some information (e.g. LIEF based), anti-virus, or whatever. Probes, including ours, which are not anti-virus are usually quite easy to handle. But with the anti-virus, that is another story. The main benefit from combining several anti-virus is that if one is failing to detect a malware, we expect (hope) another one will not. It reduces the likelihood of success for malware. So, we tried that with more than one million samples. It is also interesting to study the behaviour of the anti-virus: not all of them are equal for a given type of files. Some are crap with MS Office files or archives, some are less efficient with binaries, some consider all packed files as dangerous, some remove some signatures from their database more quickly than others. To go back to the benchmark, with so different behaviors from the anti-virus and a huge number of files, we used our monitoring system to track the performances (in time and quality of response) for what types of file, and tuned IRMA Enterprise accordingly. The appliance CTS-IRMA can then the optimized to fit the needs depending on the typology of threats and detection expected.
We intend to provide regular and detailed test results on that in the coming months.
Automation for vulnerability research
Vulnerability research is becoming more and more complex in modern systems, because they are bigger and updated quite often. Also, we are moving toward the end of /Wintel/ (Windows + Intel^w x86) era, with ARM’s dominance in mobile and some embedded systems, without forgetting MIPS, PowerPC and other architectures from the nineties (at least) still kicking. So, the low-hanging fruits are less common: finding vulnerabilities is not only about luck but also skills, and exploiting them is much harder with all the new protections.
Hence, we need to automate a lot of simple and stupid tasks so that security researchers can focus where brain matters. This is a strong belief at Quarkslab, and that is why we develop and provide so many open-source tools (feel free to contribute or support us :).
One may need dedicated tools, like a debugger for a firmware or a baseband, or a disassembler to be able to read the instructions properly. Or, it can also be about specific techniques, like static, dynamic, symbolic, …, execution. We developed QBDI (QuarkslaB Dynamic binary Instrumentation) to observe the execution of programs anytime during runtime and automate the data collection. The goal is to transform a program into its own measurement tool. We designed it to be very modular and that is why integration with tools like Frida is really smooth.
We are also working on guided fuzzing, combining QBDI with our symbolic execution engine, Triton and some fuzzers to target closed-source programs.
Our research work would be meaningless if it was not tested in real-life situations. To that end, we dug into the Windows Kernel Shim Engine. Basically, there is a database storing the shims (patches) to be applied to the kernel. Database is stored unauthenticated, with shims inside. Of course, the database and shim have a dedicated format. which usually means a good attack surface, especially when it is parsed in the kernel. A closed source target and a file format form an excellent test case for our guided fuzzing system even with some additional work on the format. Problem: when / if we crash the Windows kernel, the whole system dies. Therefore, we lifted the parser code from the kernel, made small adjustments so that it becomes a userland application for Linux (e.g. replacing kernel functions by userland equivalent and calling convention tricks). We packaged that in a single function calling the parser with arbitrary parameters. We got about 700 crashes quickly. The question is: are they interesting? We automated the crash validation in order to test the sample on a real Windows 10 and made some simple analysis remove duplicates to go down to 165 crashes. We still are investigating some of these, but so far, the ones we analysed were not exploitable.
From IP cameras to set-top-boxes: when hardware facilitates attacks
Embedded devices are everywhere: PLC, cameras, cars, Set-Top-Box, coffee machine, … and many people hack into them to modify them, upload custom firmware, and have fun. In this session, we covered an introduction about hardware attacks, and gave 2 examples where they helped us.
When working on some embedded devices, we just have the device, and nothing else: no documentation, no firmware image, but non-destructive physical tampering might be allowed. We then have to choose between 2 kinds of attacks:
/In-circuit/: we don't touch the chip, probes and logic analyser are our friends.
/Chip-off attacks/: we physically remove the chip and use a flash programmer to read the content.
You can read our previous blog posts to get more on that. For now, we will focus on use cases. But the conclusion to these hardware attacks is that 1) they give us access to firmware when we cannot get one easily on the Internet, 2) they can be surprisingly cheap due to both more accessible hardware tools and a lot of unsophisticated hardware devices deployed in the nature. Hardware attacks are definitely becoming another arrow in the software analyst's quiver (if you refrain from sneezing when reballing a BGA chip...).
In the case of the STB we analysed, we managed to do both: dump it and find it on the Internet. Then, the next stage was to understand its format, as it is usually compressed and encrypted, sometimes with custom algorithms. Once we got a clear access to the image, we were happy to find a custom RTOS, fortunately using some well-known libraries and programs like openssl. Fortunately, the signature for this firmware was poorly implemented as only some parts of the firmware were involved. For instance, one of the signed parts contained a checksum. So, we simply had to modify a few things here and there, and add garbage to generate a collision with the checksum: we had our modified firmware with root access to the device. From there, we could do whatever was needed.
IP cameras are another use case as this kind of devices is more and more widespread, with a quite poor security history. The method is the same as for STB: hardware analysis, firmware analysis then exploit vulnerabilities. We won’t spoil too much the results here as this will be presented in a dedicated blog post and / or a conference, but let’s just say that having a web server able to send back the configuration file of the camera, configuration file which is containing the clear text password to the camera is not a good idea. ;)
Under the hood, ECU: when cars become computers with wheels
Cars are experimenting what happened to planes 10+ years ago: computers are coming in. And that changes a lot of things, of course. One can view a car like a miniature industrial plant. The challenge of connected cars is a requirement for the autonomous cars. Lately, we have been involved in several jobs for the car 2.0.
Many tools (debuggers, compilation, CAN message management, high level integration like Autosar, …) are available to the automotive industry, but when it comes to reverse engineering, it is all about JTAG debugger, some disassembler and a CAN simulator. And most of the time, these tools are proprietary. Of course, there are still some good old reversing tools when it comes to ECUs (Electronic Control Unit), like IDA, oscilloscopes, bus analysers, flash readers/programmers, … So, we went to our mechanic and asked for his diagnostic device to sniff CAN messages, create a fuzzer and learn more about proprietary CAN messages. Also, we developed a tool to identify the CAN database in a firmware. This database is very useful as it contains all commands an ECU can understand, and pointers to callback functions handling each of these commands. So this tool provides the starting points that can be hard to find without it, and help us reversing an ECU firmware.
But before reversing a firmware, we have to extract it from the ECU. While some methods allow us to do it through the CAN network, we found that the Flash dumping method, when available, offers great successes. This method consists in reading the electronic chip containing the firmware. In order to dump a chip, we have to desolder it and use an adapter to plug it back into a Flash reader. We found that ordering an adapter each time we encounter a new chip is time consuming: it usually takes one week to order a new adapter, or to create one with a PCB making company. An interesting alternative is to buy or make our own PCB engraving machine. After studying the state of the art in this field, we decided to build a laser CNC. This machine is a huge time saver when dumping a Flash chip containing an ECU's firmware as it enables us to create an adapter PCB and dump a Flash chip in less than one day.
Conclusion
The QITS is an amazing opportunity for Quarkslab. Customers, partners and new members can see the variety of work we do and the overall logic fueling it. Our vision is driven by the idea that we are and want to remain experts in “analysing files” as we say internally, whether it is to understand a binary, find or understand vulnerabilities, play with protocols, or assess the crypto and the obfuscation, and thus no matter the nature of the file (Windows PE, boot loader, browser, ECU firmware with no datasheet, ...)
Presenting one's work is important in security to continuously test ideas, and confront them with expectations of real-life situations. The feedback we get from customers, partners and friends is invaluable in keeping us digging into dark corners of security. The niche for reverse engineering, vulnerability research and cryptography is still a niche, but everyone gets more and more concerned by the consequences a single flaw can have. So we will keep analysing files for one more year.
See you next year.