This blogpost contains summaries of talks from this year’s TROOPERS18 Attack & Research Track.
Reverse Engineering Blackbox Systems with GreatFET & Facedancer by Kate Temkin and Dominic Spill
USB is everywhere, your phone, gaming consoles, IoT waffle irons, you name it. Due to its’ widespread use in everyday life it is typically trusted by the user. And even if one wanted to find out what’s happening behind the scenes, surely digging into USB communication is too much of a chore to be worth the hassle, right? This talk by Kate Temkin and Dominic Spill are about to prove that very wrong with an impressive display of their tools GreatFET and Facedancer.
Kate is a seasoned USB researcher who maintains a variety of open-source hardware and software tools on top of her educational work. Dominic is security researcher at Great Scott Gadgets and has a focus on sniffing and modifying communication protocols. “Processors such as those found in the Nintendo Switch (Tegra) had been around for a long time”. But publicly known vulnerabilities have only started popping up due to Temkin’s work [see this tweet], which relied on USB analysis.
During their talk, the researchers showcased their USB Proxy tool, which allows for easily proxying the connection between a USB host and device. This in turn enables logging of packets, modification of data, injection of new packages and capturing various side channel and behavioral information about devices. Pretty much everything networking people are usually doing when messing with network equipment or protocols, but for all things USB! This is a gateway to the mastery of systems whose internal software stack you cannot control. Think about all those devices you don’t really have any access to other than plugging in some USB cable. With the tools presented here, all of those can suddenly be analyzed easily.
The talk was demo and presentation heavy. The first one used Facedancer to monitor the traffic coming from a Nintendo Switch Controller. Within seconds they intercepted its traffic, and the packets started flying over the screen, changing in accord with the buttons being pressed. And you just have to agree, there is something inherently satisfying to this. So much for the sniffing part, but surely we can do more with this, right? Right.
The second small demo picked up were the first left off. They brought up the python code and with one line of code inside a filter-function
data[3] = 0xff - data[3]
they inverted the x-axis of the controller. This simple and quick demo, while not very impressive in and of itself, showed how rapidly and playful reversing and playing with USB devices has become due to their great work in terms of tooling. Watching them do this leaves the impression that discovering the responsible byte in the transferred controller data and flipping the axis can be done, together with the necessary bit of reverse engineering, in probably just under 5 minutes! Let alone the fact that with this information you could now possibly design your own controller.
The focus was then shifted to the security of the device itself. It turns out various devices read the firmware image update they are presented via USB twice. That’s curious. Why could that be? Well, you have to check your firmware before you apply it, right? Since you want to know whether it is broken, or somebody tampered with it. Okay, you say, but why read it in twice? Well, the assumption (That they drew for us from their experience) is that storage/memory on the embedded device is limited, too limited to store the firmware somewhere, perform the integrity check and then overwrite the old firmware with the integrity-checked new firmware. So instead, the device reads in the firmware without saving it and calculates the checksum. If it is happy, with the data it read in, it feels confident to read in the firmware again and directly overwrite the old one.
The assumption on the device side is obviously that the data won’t have changed after the first read-in. Why would it, right? Well maybe everything that does that deserves to end up as a brick, which is what happens, when you alter the data before it is read in a second time. They stressed that this behavior has been observed by them a couple of times in the wild. All in all the talk was both enlightening and playful. Hopefully it inspires people to delve into the field of USB research themselves.
Check out the slides here and the video here.
Hunting Android Malware: A novel runtime technique for identifying malicious applications by Chris Le Roy
At Troopers 2018 Chris Le Roy presented an instrumentation technique to identify Android malware by scanning for suspicious objects on the heap.
Chris Le Roy (who tweets under the handle @brompwnie) is a security researcher and regular BlackHat trainer. His many years of experience working as a software engineer and his skills of tearing apart things on the internet have resulted in multiple BlackHat Arsenal sessions in Las Vegas, Europe and BSides Cape Town.
At the beginning of his talk, Chris presented his tool kwetza which he used to backdoor the APK file of the stock Twitter app. The tool aims to rise awareness and shows that the modified app bypasses antivirus checks. Chris brings up static analysis as a defense technique and also explains some of the drawbacks it comes with: runtime code injections cannot be analyzed by a reverse engineer. Other techniques such as reviewing the app’s permissions also does not work well as today it is already hard to distinguish malware and common social media apps purely based on their permissions.
To overcome some of those drawbacks, Chris suggests to analyze an app at runtime and search for suspicious behavior by using the Frida framework. Frida is a powerful instrumentation framework for multiple platforms including Android which allows to analyze and modify the dynamic behavior of applications. The backdoored Twitter app Chris showed earlier instantiates the DexClassLoader class and establishes a TCP connection back to the attacker. Both events can be detected by using Frida to enumerate all objects on the heap and match them against a predefined list of suspicious objects. Additionally, Frida is capable of hooking interesting functions such as Runtime.exec().
In order to interact with the Frida server running on the Android phone directly from the device itself, Chris wrote a library called uitkyk (which translates to ‘look-out’) and a demo app.
At the end of the talk Chris also mentions the shortcomings of the presented approach: The instrumentation framework needs to be integrated into the Android system and therefore adds to the overall attack surface. It also has to be protected against abuse.
His slides can be downloaded here and the video on our TROOPERS channel
The Wolf In SGX Clothing by Marion Marschalek
One of the talks at TROOPERS18 was “The Wolf is SGX clothing” by Marion Marschalek. Marion is a former malware analyst and reverse engineer, who is currently working at Intel. In her talk she discusses the SGX technology and what malicious activities can it be used for.
SGX is a security technology that is used to protect data from disclosure and modification by hiding it in enclaves. Enclaves are encrypted isolated memory regions containing code and data. Their security properties include confidentiality of code/data, detection of integrity violation, isolation between enclave instances, and prevention of replay of enclave instances.
Enclaves live in ring 3 only, like normal user applications. Entry and exit are protected, and it is difficult for an analyst to inspect an enclave as one cannot attach a debugger and check the memory contents. Moreover, the enclaves are protected even from privileged code and isolated from each other. They come with their own crypto keys that are platform- and enclave-specific.
The usage of this technology is however limited, as there is a number of requirements (hardware, BIOS and runtime related) to use the SGX applications, and so they cannot be run on any machine.
During her presentation Marion demonstrated three ways of using malware inside SGX protected containers. First one was ransomware George running in an enclave; it encrypted files. The implementation consisted of application (untrusted part), enclave (trusted part) and helper functions (ecalls and ocalls) that make it possible for both parts to communicate with each other. The application part makes an ecall to the enclave to start the ransomware. SGX does not provide very extensive set of functionality, so for some things like e.g. enumerating, reading and writing files an enclave would need to rely on application to execute corresponding system calls. In order to trigger this, the enclave needs to make an ocall back to the application. The encryption itself is happening inside the enclave.
Enclave definition file (EDL) lists all trusted and untrusted functions that application and enclave provide for each other. These lists are later used to define the helper functions for transitions between them. The transitioned data will be checked on both sides by the runtime.
While to interact with the normal filesystem the enclave needs to make a call to the application, it has its own SGX protected file system to access, that cannot be accessed from the application.
Another important fact about enclaves is that before they are loaded into memory their binaries on the disk are not encrypted. That makes it possible to analyze parts of functionality, which means that an antivirus could find the ransomeware binaries even if they are used to be run out of an enclave. The problem is however that the most code that the enclave contains is a library code statically compiled into the binary, as there is no dynamic library loading into enclaves. This would take more time for anti viruses to create signatures for all the non-malicious code.
The second demo that Marion showed (called Martha) does not require an ocall, instead making syscall proxy. You would not find a malicious part in its binary as Martha loads its executable code at runtime.
The shellcode that will be run can come from the local disk or from a remote server. Enclave decrypts the shellcode and then copies it to RWX section and executes it, first marshalling the arguments and then jumping to pivot function. The pivot function does a proper exit out of the enclave memory and issues ocall to the syscall proxy. It unpacks the arguments and executes the syscall instruction. The order of the arguments can be obfuscated, because you define the parsing function on the other end.
The third demo called Franz contains the ransomeware in the shellcode that is hidden in the enclave memory and executed via syscall proxy. It still can be monitored with strace tool and activities like reading plain files on disks or writing encrypted files become visible.
So what does this mean from the perspective of malware creation and analysis? It seems not that feasible to put ransomware in the enclaves. Not every target is suitable for this, there are many prerequisites. It also requires a lot of effort to code such malware, including coding in assembly.
For threat detection the challenges are not as different as for common malware since the binaries are largely inspectable on the disk, although automation could be difficult because of static libraries present in the enclave binaries. As for monitoring, one could still figure out which behavior malware shows at runtime because the enclave still has to execute system calls via the application. Any remote connection that a piece of malware makes would also remain visible for monitoring. System wide monitoring of syscalls however remains a challenge.
The video of the talk is available here. Slides are currently unavailable for this talk.
How to Bring HID Attacks to the Next Level by Luca Bongiorni
“How to Bring HID Attacks to the Next Level” was a talk by Luca Bongiorni as part of the Attack & Research track at Troopers 2018. Luca Bongiorni is working as a Principal Offensive Security Specialist and does research in the areas radio networks, reverse engineering, hardware hacking, Internet of Things and physical security.
Human Interface Devices (HID) attacks are attacks via USB devices that act as a keyboard or a mouse. For example, the victim could be handed a device looking like a USB flash disk, but instead the device announces itself to the computer as keyboard and starts to enter commands (the payload) as soon as the device is plugged into the computer.
In his talk, Luca Bongiorni first presented the earliest HID attack devices. Teensy, an open source device from 2009, was quite limited in its functionality, but already supported multiple attack payloads. Rubberducky, released 2010, had more functionality, like changing the VID and PID of a device, therefore being able to simulate specific hardware. However, it was also more expensive compared to Teensy. In 2014, BadUSB was released, a software-based solution that changed a normal USB flash drive to behave like a keyboard by attacking the firmware if the flash drive. This device then could be used to infect PCs, which in turn could infect other flash drives. Later, it became known that the NSA had developed a device that was concealed within a USB cable and which communicated via an RF channel. This device could therefore be used to extract data from airgapped machines.
In the second part of his talk, Luca Bongiorni described two current HID attack implementations, WHID Injector and P4wnP1.
WHID Injector, designed by the speaker himself, is based on an Atmega32u4 and an ESP-12 chip for WiFi. The WiFi provides an easy way to bypass firewalls or air gaps. It also includes pinouts that can be used to weaponize USB gadgets. Today, most companies train their employees to not insert any unkown flash drives into their PCs. However, a mini fridge using USB to get powered might not look like a threat to them. A weaponized USB gadget might therefore have a higher chance of being plugged in. As Software Framework, ESPloitV2 is preinstalled. It works on all current operating systems and allows the creation of hidden SSIDs, live loading and execution of payloads as well as installation of firmware upgrades over the air and VID/PID spoofing. But other framework options exist, too. ESPortal Credentials Harvester can open a rouge access point. When a user connects to the access point, a fake login page can be displayed to them by redirecting HTTP traffic. USaBuse registers as a mouse and prevents the screen-locker to start by moving the mouse in an invisible way. Further, an access point is started to which the attacker connects. As soon as the attacker knows that the victim is not in front of their PC, they can open a powershell, execute an exploit and hide all relevant windows afterwards.
In the near future, a new revision of WHID, called WHID Elite, will be released. It will contain upgraded hardware, like a MicroSD slot and a microphone and might even get an LTE chip.
An alternative to WHID is P4wnP1, a HID attack device based on a Raspberry Pi Zero. It contains a way to extract data from airgapped machines. By using the HID RAW protocol, it can extract data even from machines that restrict the exfiltration of data with up to 50kB/s. This data can then accessed via an access point the device opens. Further, before patched by Microsoft in October 2017, P4wnP1 contained a lockpicker that steals the NetNTLMv2 password hash of the user on a locked PC, tries to crack the hash and then enters the password to unlock the PC.
As last part of his talk, Luca Bongiorni presented some mitigations for these attacks. First, of course, no unknown USB device should be plugged into a PC. For gadgets that use USB only for power, USB condoms exist that allow devices to be powered via USB but prevent any communication between the device and the PC. For Linux, the addition of new HID devices can be prevented. usbdeath and usbguard are two tools to regulate which USB devices are allowed. On Windows, duckhunt+ can be used. Further, plug-and-play and/or powershell event logs together with central log collection help identify attacks via HID.
While a video of this talk will not be made available you can find the slides here.
When Virtual Hell Freezes Over- Reversing C++ Code by Gal Zaban
Gal Zaban is a security researcher at Viral Security Group. In her talk “When Virtual Hell Freezes Over – Reversing C++ Code”, she is presenting the research she was doing in her free time. She studied the internals of C++ binaries and then build an IDAPython framework called Virtualor. This framework automates reverse engineering of binaries compiled from C++ code.
She starts with describing the main problems about reversing C++ code: At first, she shows how dynamic object creation is working: The application allocated memory for the object on the heap and constructor call afterward. The constructor creates the virtual table (vtable) and then initializes all the members of the object.
She continues with describing the purpose of the vtable: storing the pointer to the virtual functions of an object. The problem is that you do not know what function will be called on a virtual call. The reference to the function will be read from the vtable and the vtable will be determined depending on the object reference during runtime.
Another big issue she talks about is multiple inheritances when one class inherits from two different classes. She is showing both problems by some simple C++ code examples and the decompiled assembly instructions in IDA.
So there is much work to do when you want to reverse a C++ program, due to this issue. Gal wanted to make this process more “fluffy”: She used IDAPython and IDC to build the tool Virtualor, which automated tracing in IDA. She tried to create trace breakpoints on virtual calls and parse the trace files to determine which virtual function is called during runtime. However, this was not an ideal solution, because it is not fully automated and it provides only specific function calls and not the hole vtable. She wanted to make a more dynamic solution: She finds virtual calls first and then adds breakpoints to the vtable’s function assignment with IDAPython. Unlikely a typical breakpoint, she is using a conditional breakpoint as a hook to pause the execution for a short time, while fetching the information she needs. With that information, she creates the IDA structures of the vtable, connects these structures with the virtual calls and adds comments and references to the code/assembly.
The tool is currently only supporting MSVC compiler and x86. In the future, she wants to add structures for all objects in the local, static and dynamic memory. The second thing she wants to add are inserting relevant names to the functions in the vtable instead of sub_????.
If you are interested in learning more about the internals of compiled C++ binaries and reversing C++ applications, you should definitely take a look at the video of the talk.
Unfortunately, she has not released the tool, yet. So you need to stay tuned if you want to take a look at it ;-).
Cheers,
Hannes Mohr, Michael Kümmerlin, Dennis Mantz, Felix Rohrbach, Olga Yanushkevich, Tom Wellinger, and Sven Nobis