Internship Offers for the 2021-2022 Season

Binary diffing aims at measuring the similarity between two given binary objects (programs, functions ...). Given two inputs, it generates a mapping from elements of the first input to the second one. Such a technique is essential for various security workflows like silent fixes detection, 1-day analysis, malware analysis, patch analysis or binary plagiarism detection. Numerous methods have been presented over the years, from the widely used tools (BinDiff, diaphora) to more experimental academic results.

Security audits performed at Quarkslab often involve analyzing different versions or variants of a same or similar binary samples. The internship aims at lifting all valuable information that can be extracted from computing the difference between two or more samples. It also, implies solving complex uses-cases where binaries are obfuscated or answering complex questions like is sample A closer from B or C?

The internship requires many practical experimentations, some development and the taste to dig more into exploratory techniques in a more theoretical and experimental manner.

Quarkslab already have some internal tooling for diffing [2] and a whole lot of data to play with. The goal of the internship is to improve and automate the diffing process to let data speak at scale.

• very basic knowledge in assembly and program analysis

• knowledgeable in Python

• a taste to explore academic diffing approaches

Using the two provided binaries that represent two versions of the same library, find all the differences between the two. Extract all differences that seems relevant to you (from functions names to their content itself). The only constraint is to make that process as automated as possible. The expected output is a script (in any language of your choice) taking the two binaries as input and outputing the list of the differences. Additional question: can you identify what has been modified/patched and why?

Note: We are more interested by the thought process and the methodology rather than a complete exhaustive dump of differences.

[#] https://blog.quarkslab.com/weisfeiler-lehman-graph-kernel-for-binary-function-analysis.html

eBPF is a Linux technology that extends the kernel functionalities. Instead of loading a kernel module, or recompiling a kernel, it is now possible to dynamically run an eBPF program to extend Linux capabilities. Nowadays, eBPF is mainly used in four areas:

• networking: enhance packets processing

• tracing and profiling: troubleshoot issues and performance bottlenecks

• observability: report metrics

• security: detect and block threats

While these topics are well explored, we believe that eBPF could also be leveraged to help security researchers. For example, it could be used to fingerprint a process, and follow its network communications. Similarly, eBPF could be weaponized to modify userland memory.

This internship consists in exploiting eBPF as a security research tool, and to highlight its weaknesses from a security perspective. You will have to learn eBPF and evaluate its possible usages for security research such as fuzzing or sandboxing. After getting a good understanding of the technology, your will investigate eBPF shortcomings that could be leveraged by attackers.

• familiar with the Linux Kernel source code

• experience with security tools

• good understanding of C and Python

• being already familiar with eBPF tricks is a plus

Your task consists in developing a tool that uses eBPF to automatically identify processes communicating using the TLS protocol with the OpenSSL library. Your code should display the destination IP adress and port, the PID and the process name. You are free to choose your prefered programming language for the task. The expected output is the documented source code of the tool, accompagnied by its installation and usage methodology.

To get you started, pick a command line tool such as curl and observe it behavior on a recent Linux distribution like Ubuntu 21.04.

Bonuses

• identify other TLS libraries

• discard all TLS traffic that do not use the OpenSSL library on the 443 TCP port

Paris

6 months

21-internship-ebpf-security

How comfortable do you feel when leaving your personal computer out of your reach? By joining us for this internship, you will learn about physical attack scenarios, in which every port left open on your computer is a potential threat. More specifically, we want you to explore the PCIe attack surface that lies behind the Thunderbolt 3 port available on modern laptops.

Your goal will be to help us assess the security of a modern desktop operating system against malicious PCIe devices communicating over Thunderbolt 3. To this end, you will implement a programmable malicious physical device with the ability to impersonate a variety of PCIe devices. You will use this device to challenge the security of the operating system and of the underlying drivers against this attack scenario. We will elect together the most suitable target operating system (GNU/Linux, macOS, or Windows), based on your personal preferences and on the internal knowledge available at Quarkslab.

During this internship, you will acquire and practice a very broad range of skills. This range includes using a disassembler, debugging a kernel, and the use of fuzzing techniques. You will also become knowledgeable about exploit mitigation in modern CPUs and operating systems, in particular memory isolation. Any prior experience related to these topics is appreciated but not required.

You should be at ease:

• using a FPGA board

• programming in C

• reading technical papers and blogposts

• reading hardware specifications

• writing technical reports

Prepare a 15 to 20 minute presentation in French or English about some exciting technical blogspot or paper of your choice. The topic should be somewhat relevant for the internship. You are completely free regarding the format of the presentation (simple talk, whiteboard, pen and paper, having some support slides, etc.).

The presentation should briefly explain why you chose this specific document and how it relates to the internship. Then, most of the time should be used to explain the technical contents with your current level of understanding. We do not expect you to have a complete understanding of the document. Instead, you should highlight the parts that remain misunderstood, which could then be subject to further discussion.

Before preparing the presentation, we ask that you first send us a link to the document that you would like to explore for this exercise. This way, we can validate together that the document is a good candidate before you start working on it. In case of doubt, feel free to send us multiple documents and we will decide together which is the best candidate.

[2]	http://xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1 Eli Billauer (Xillybus Ltd.), "Down to the TLP: How PCI express devices talk (Part I)"

[3]	http://xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-2 Eli Billauer (Xillybus Ltd.), "Down to the TLP: How PCI express devices talk (Part II)"

[4]	https://thunderclap.io/thunderclap-paper-ndss2019.pdf A. Theodore Markettos et al., "Thunderclap: Exploring Vulnerabilities in Operating System IOMMU Protection via DMA from Untrustworthy Peripherals"

[5]	https://docs.microsoft.com/windows/security/information-protection/kernel-dma-protection-for-thunderbolt Microsoft, "Kernel DMA Protection"

[6]	https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html Gal Beniamini (Google Project Zero), "Over The Air: Exploiting Broadcom’s Wi-Fi Stack (Part 2)"

[7]	https://googleprojectzero.blogspot.com/2017/10/over-air-vol-2-pt-3-exploiting-wi-fi.html Gal Beniamini (Google Project Zero), "Over The Air - Vol. 2, Pt. 3: Exploiting The Wi-Fi Stack on Apple Devices"

Fuzzing is now ubiquitous in the bug discovery and exploitation research field. It is usually the first step to cover code, uncovering weird behaviors and possibly finding vulnerabilities. Another approach is Dynamic Symbolic Execution (DSE) aka concolic execution that offers fine-grain reasoning capabilities but at some costs. Especially, it is notoriously slower than fuzzing. Leveraging these two approaches to work together is an open research problem.

The internship lays at the crossroad of these two approaches. The goal is to work on these two techniques to improve them separately in order to address harder targets and weird systems but also to make them work together for the best. Quarkslab already have multiple internal tools for instrumentation, fuzzing and DSE. Finding bugs/vulns and improving these tools will be an essential part of the internship.

• familiar with Fuzzing

• knowledgeable in Dynamic Symbolic Execution

• desire to mix both concrete challenges and more theoretical ones

• familiarity with Cyrillic alphabet is appreciated ;)

Given the samples, the goal is to trigger the bug using both the fuzzer and the DSE of your choice. The fuzzer and DSE can be used to solve the challenge independently but any collaborative (yet naive way) would be very much appreciated. Write a small report and provide any relevant code used for solving the challenge.

Note: We are more interested by the thought process and the methodology used rather than a complete exhaustive dump of what you did: in short be readable and relevant instead of exhaustive and unreadable.

• familiar with automated vulnerability research

• good understanding of Android runtime

• experience in native reverse engineering and instrumentation of Android applications (Frida, QBDI, etc.)

• plus if already proficient in C++

Pick out an open-source library that parses buffers (e.g. image rendering) and can be compiled with the Android NDK. Write a harness function for fuzzing a piece of code you find interesting using libFuzzer, compile it and run it on an Android emulator or a physical device.

Answer those questions:

• what is your executable doing internally while fuzzing?

• what would it take to make it work on a closed-source target library?

• applied to the Android application ecosystem and especially JNI functions, what challenges would we face?

The Intel Management Engine (ME) is an autonomous subsystem that is present in all Intel's processor chipsets. It is the root of trust of multiple security features and runs at the highest security level on a machine. Having an arbitrary read/write primitive on such a system may seem like being in God mode on the target. Okay, sure, that's a win, but now what? While being in ring -3, ME is at a very low level and it can be problematic if the purpose was actually to tamper with the OS running on top of it.

This internship aims at studying in-depth the Intel ME ecosystem and think about how an attacker could subvert this engine to climb on higher layers of the system. The main goal induced by this topic is first to better understand the component and start a knowledge base that could benefit the team but also to think and implement various scenarios to show the feasibility of subverting the different features offered by ME.

• good understanding of how an OS works (no matter which one);

• good understanding of C and assembly languages;

• low-level and systems interest;

• being motivated and ingenious. :)

Here is an x64 OVMF firmware. Reverse it and find the key. The expected output is a write-up describing what you understood about this image and how you managed to complete the assignment.