Description

Nowadays, firmware are everywhere: mobiles, routers, ECU, IoT devices, Set-Top boxes, … Sometimes, they are as simple as a filesystem, which can just be accessed like every other filesystem. But most of the time, they are compressed and encrypted, sometimes using custom algorithms.

However, when one wants to analyze what is inside the firmware, the first step is always to reach its inside, hence opening it.

The goal of the internship is to work on a generic engine able to deal with multiple kinds of firmware to access the files it contains.

• Improve our framework to handle file systems

• We will select multiple firmware, and you will have to support them in the framework

  • Study encryption and compression if any
  • Develop the appropriate unpacking capabilities
  • Test on various firmware of the same family (yes, sometimes, there are surprises ;)

• Automate unpacking based on our Irma framework

Required skills

• Fluent in Python
• Good knowledge in cryptography and algorithms
• Preferably some experience in reverse engineering in ARM and/or unpacking malware

Reference

20-internship-unpacking-firmware

Description

On 9 August 2019, Huawei officially unveiled Harmony OS. Huawei described Harmony as an open source, microkernel-based distributed operating system for various types of hardware, like smart TV, in-car entertainment or wearable devices. Huawei launched Harmony OS 2.0 at the Huawei Developer Conference on 10 September 2020 and intends to ship the operating system in smartphones in 2021.

Another critical piece of what Huawei is building is Ark, a compiler allowing, among other things, to port Android applications natively to HarmonyOS, removing the need of an interpreter. This compiler is open source, and supposed to help Huawei to build its own environment if they were banned from working with US companies. So far, the expectations put in it might not exactly meet the actual results.

The internship intends to dive deep into both HarmonyOS and the Ark compiler:

• Set up a working environment to play with a running instance of HarmonyOS
• Describe the security model both in userland and kernel.
• Map code base: identify new components, or code reuse, as open source libraries for instance
• Implement some tools (IDA/Ghidra plugins) or adapt (some of) ours to that environment (QBDI, LIEF, Triton, ...)
• Fuzz "interesting" components

Of course, depending on the stage of reliability of HarmonyOS, other tasks could be explored more deeply: how to gain persistence on the system, boot process, hooking the kernel or critical part of the OS, ...

The goal for the intern is to gain extensive knowledge on the OS while it is still young, and be creative.

Required skills

• Good understanding of how an OS works (no matter which one)
• Good knowledge of C/C++
• Knowledge in vulnerability research in source code OR fuzzing OR Android malware.

Assignment

• Choose between CVE-2020-0245 and CVE-2020-0408
• Analyze the bug: find the root cause, explain why there is a bug
• Trigger the bug: build the appropriate code, and explain how / why the bug is triggered
• Send us a report in English explaining all that

Reference

20-internship-harmony-os

Description

At Quarkslab, it is quite common that we need to do some fuzzing campaigns either for clients or for our internal needs.

Fuzzing should be simple to integrate and be a no-brainer when you need to use it during a constraint timeframe.

We are looking for someone who likes to code and do fuzzing (and want to take that knowledge to the next level). Being familiar with the container ecosystem (docker and kubernetes) is recommended.

The purpose of this internship is to improve various tools used during a fuzzing campaign. Depending on the desires and knowledge of the candidate, it can go from developing or improving fuzzing tools (crash triaging, coverage visualization, snapshot-based coverage-guided fuzzing, ...) to tackle continuous fuzzing issues (scaling, corpus sharing, ...).

Required skills

• Be familiar with fuzzers
• Be familiar with docker
• Some knowledge of kubernetes would be great too.
• Fluent in either Python or Rust

Assignment

• Write a fuzzing harness for a publicly available software on github by using either libfuzzer, afl, or honggfuzz (don't take one with harnesses already available)
• Explain why you choose this target. A particular attention will be paid to the quality and reproducibility of the results. (e.g: it can be for example in a docker container)
• Explain how you would address the main difficulties encountered if you were fuzzing this target for a long time. For example how you would do crashes triaging, how you would scale to one or multiples machines, how you would proceed to reproduce the bugs, how you would find the root cause of the bug, ...

Reference

20-internship-fuzzing-monkey

Description

Cloud is everywhere offering more and more services to build applications. Devops tools are building the future as applications are continously deployed. But "cloud tools" are seriously changing the landscape of applications allowing to build them with microservices on top of cloud infrastructure. This trend will not slow down.

Clouds and systems to operate them like Kubernetes have become the new operating system. At Quarkslab, we use some tools like Kubernetes, Docker, Vagrant, Ansible, ... either to run or build our own products or to run fuzzing campaigns. When a new "Operating System" emerges, we are obviously curious about the security model it brings.

The goal of this internship is to study in depth how Kubernetes (and likely some of its friends) works and build a rootkit (persistant, stealthy, ...) to maintain an access to such an infrastructure. You will start by gathering information about CVEs and likely try to exploit a few of them in order to understand the internals of the systems. We will then assume you are in position to control the k8s infrastructure (directly or through the tools used by it). You will have to work on maintaining your access in a stealthy way: how to maintain access with either a normal or an admin access? how to steal secrets and eavesdrop everything happening in the infrastructure?

To summarize, you will have to :

• Study known vulnerabilities in these tools
• Learn how they work from the inside and manipulate them
• Be creative in order to find unexpected ways to have them misbehave
• Look at how the main cloud providers are working with these tools

At the end of your internship, you will have built a set of tools to "play" with a Kubernetes infrastructure. The multiple tools (payloads) will allow various actions on the infrastructure (dump secrets or whatever a compromised pod can access, eavesdrop some encrypted communications, and so on).

Bibliography

• Advanced Persistence Threats: The Future of Kubernetes Attacks Ian Coldwater & Brad Geesaman https://www.youtube.com/watch?v=auUgVullAWM.

Required skills

• Development in Python or Go
• Go knowledge
• Good Linux understanding (possibly with experience in sysadmin)
• Some knowledge of Docker or Kubernetes is obviously a bonus

Assignment

Provide your own security analysis of a CVE in Kubernetes or Docker: explain the root cause, and your own exploitation way.

Reference

20-internship-kubernetes-rootkit

Description

Writing a packer that interacts correctly with other obfuscations is far from easy. Where should the packing be done? In the compiler intermediate representation? Before obfuscations? Afterwards? If it's done too early, the packed code won't benefit from other obfuscations. If it's done too late, the code may be too obscure to identify a single piece of code for packing. In the first scenario, it's enough for the attacker to collect traces of the code during the execution to recover the un-obfuscated code, while in the latter, the whole application must be packed as a single piece, which incurs a big performance hit.

A better approach is to span the packing strategy across several levels, doing a part of the work in the intermediate representation, and another part in the binary code. This allows to inject unpacking code early enough, so that it can be obfuscated together with the user's code, and to inject placeholders that will be later filled by a later transformation directly on the binary code.

The objective of this internship is to do a first implementation of this strategy, and explore some improvements to this protection.

Required Skills

• C++ programming
• Low-level and systems interest
• Knowledge of the internals of LLVM is a plus !

Assignment

0 READ
1 DUP
2 PUSH 0
3 GT
4 PUSH 8
5 JMPZ
6 POP 1
7 PUSH 0
8 DUP
9 MUL
10 WRITE

Reference

20-internship-multiple-stage-packer

Description

Virtualization solutions such as Microsoft Hyper-V, VMWare Workstation, Virtual Box, etc. provide isolation from the outside world and everything is executed inside the limits of the virtual machine. However, can these limits be bypassed from a malicious guest? How difficult is it to interact with the outside world and escape from the matrix? That's what our intern will find out by focusing on the emulation of hardware components.

The purpose of this internship is to study in-depth how virtualization platforms handle the emulation of hardware components (low level) to understand how secure they are.

Of course, the topic is broad and the first task will be to choose a virtualization solution (Hyper-V, VirtualBox, VMWare, QEMU, etc.), depending on the intern experience, existing work and discussions with the team. Then the intern will study its ecosystem, the different components composing it and how they interact between each other. These first steps should give them an overall understanding about how things work and how to tackle the rest of the topic.

Then, they will have to conduct a more in-depth analysis of how the virtualization solution handles the emulation of hardware. There are three possibilities: full emulation of the devices, para-virtualization and direct access (passthrough) to the guest. They will choose with the team one of these mechanisms for further research.

Finally, they will use all the knowledge gained during the research phase in order to attack the studied emulation mechanism. Different approaches such as fuzzing, manual reverse engineering or whatever techniques they can think of can be used in order to test the strength of the virtualization platform and try to escape from the matrix by exploiting the hardware emulation interface.

At the end of the internship, we should have an in-depth knowledge (and documentation) of the hardware emulation mechanisms of the chosen virtualization solution and an evaluation of the possibilities to escape this virtualized environment by exploiting the hardware emulation interface.

Assignment

You have the choice between the two following exercises:

• Choose two virtualization platforms (for example Microsoft Hyper-V and Virtual Box) and

  • describe succinctly their overall architectures,
  • compare them and comment on their advantages and drawbacks.

• Mount a USB key in a virtual machine (either Microsoft Hyper-V or VMWare Workstation) and explains how the virtual machine is able to see the files in the key. The level of details expected is at the binaries or modules level (not functions). Describe the set up you use for your experiment and your analysis.

Required skills

• Curiosity
• Ability to understand C or C++
• Experience with OS internals
• Understanding in reading assembly language and using debugging tools
• Ability to use a programming language
• Experience working with disassemblers such as IDA Pro

Reference

20-internship-hardware-emulation