This blogpost contains summaries of talks from this year’s TROOPERS19 Active Directory Security Track.

Microsoft IT (Secure) Journey to IPv6-Only

Veronika McKillop, Network Architect, Cloud and Connectivity Engineering (CCE)

The speaker, Veronika McKillop, working at Microsofts network infrastructure services, has given a talk about the process of switching a company network from IPv4 to IPv6-only.

Within the talk the following topics were introduced: Dual Stack, Drivers for IPv6, Status of IPv6 in Networks and Security in IPv6 Networks. The talk covers the reasons why a company would like to switch from IPv4 to IPv6. Technics like NAT64 and DNS64 are introduced. The requirements to software and especially drivers to work in IPv6 environments are described. Also the problems to switch from IPv4 to IPv6-only in heterogeneous networks are addressed.

The reason for switching from IPv4 to IPv6-only is, at the end of the day, money. The costs to rent some IPv4 addresses are increasing every year. To switch to IPv6-only there are some issues which have to be solved, for example some VPN clients can not work through NAT64 and Android doesn’t support DHCPv6. Also some network monitoring and security solutions can not work within IPv6 networks.

So the conclusion is that it would save money and ensure compatibility with the rest of the internet to switch to IPv6, but there are some usability impacts for the users that have to be addressed properly.

Hitting the Gym: Anatomy of a Killer Workout

Right after the IoT Keynote a talk was given by Ioannis Stais and Dimitrios Valsamaras from Census Labs. The goal of the talk was to present their research on IoT devices in wellness and fitness environment and their security implications on both users and enterprises.

At the beginning, the guys showed how these IoT equipments differ from the ordinary ones and also shed light on some of the attack vectors exposed by such gadgets. One of the given examples for such attack vectors is a result of using Android OS, which is not mainly meant to control hardware and comes by default with many features and options than required, which mostly lead to improper security. The guys then spoke a bit about some requirements by law to be included in IoT gym machines in some global markets and showed how cybersecurity is unfortunately not one of these requirements. More definitions came after to point out the differences between a medical and wellness equipment, which turned out to be a decision made by the manufacturer.

Diving to the technical information started with showing the possible ways to use Android to control IoT gym devices and how the environment can be controlled by using Mobile Device Management (MDM) solutions. Then they explained the so called smart fitness device stack and the different components involved.

The smart IoT gym machines, which were tested by Ioannis and Dimitrios were the treadmill, steppers and exercise Bike. This test was part of a red team assessment, which aims to take control of the hardware and used it as pivot to start attacking the rest of the infrastructure integrates such equipments. The showcase, which was introduced during the talk was the treadmill, with which a jogger/user can set up his daily program or use some multimedia functions using the device user interface (UI). Using cloud service to control his daily progress.

The first step as explained in such scenarios is usually to circumvent the UI and get access to the Android WebView, because its richness of features and most of time it is not well-hardened by developers. As shown, they were right in their decision, because they found some corners in the UI through which they accessed to the WebView and loaded their own malicious content. At this point they found that the OS is not properly managed by the MDM solution and could download a malicious APK, which contained their evil backdoor binary. Interestingly, after they managed to load some content and got the file manager opened in the WebView, it turned out that the file manager used is a third party application, which has additional features, such as installing APK files ^^, you know what happened then, don’t you?

Moving on, because the hackers are eagers and want a full control, the guys skimmed the binaries/services running on the OS and surprisingly they found an unprotected privileged service, which gave them ROOT on the system. Armed with this privileges, they hunted and extracted private keys, domain control credentials, Facebook token and other sensitive data.

Next step was to try controlling the hardware, which started by understanding the over all architecture of the treadmill, which is basically broken into two parts. The first part is called the Hi Kit (Display Board), which contains the CPU Board and a micro control, which receives signals from components such as NFC reader and USB ports. The second part of the architecture is the Low Kit, which the one with the lower assemblies such as communicating with the speed motor.

After digesting all the necessary information on how the training APK is communicating with all the services and certain components to control the device, it was possible for the guys to mimic the same signals sent to increase the speed of the treadmill. This was done by collecting variety of information and reverse engineering the equipment APK, which let them send the proper parameters and values. This kind of attack is really a fatal and dangerous one, which causes really serious injuries. As they also showed, the attacker can also disable all the software and hardware buttons, which can be used either to decrease the speed or to stop the machine. On top of that, they can easily disable the emergency stop button on the machine through the service menu. This menu was accessed after they found the proper Android Intent signal to send and the its PIN, which was as usual hard coded within the APK. However, the button was still working even after changing the parameter responsible to deactivate the emergency button.

At the end a summary of the vulnerabilities they found in the device was shown, but without disclosing neither the Vendor nor the device model.

The talk from in my humble opinion was great and very interesting even for non technical users, just to be aware of how far can things go wrong with these devices.

Before I forget, check the video and be safe while you are training!

Bluetooth, does it spark joy?

After the lunch break on the first day of Troopers in Breaking IOT track, an interesting technical talk took place, which was hold by Dennis Mantz and Jiska Classen. The talk was mainly an outcome of Dennis Master thesis from last year, which was supervised by his co-speaker Jiska.

The essential goal behind choosing this topic as Dennis said is to reverse engineer the firmware of the Broadcom Bluetooth controller chip. He also mentioned that the goal was driven by some incentives, such as reverse engineering topics are always fun and on top of that is to assess the firmware from security perspectives.

The talk started by showing the main components of the Bluetooth stack. As explained the stack is divided into two halves, an upper half, which is implemented by the host (Android, Linux OS, etc) and a lower half which is implemented by the Bluetooth controller. The main protocols within the stack are the Host Controller Interface (HCI) and the Link Manager Protocol (LM). The HCI is considered to be the interface between the host and the Bluetooth controller and because it is implemented also on the host, the protocol can be locally sniffed via network sniffers, such as WireShark. On the other hand, the LM protocol does the most valuable stuff to manage the link with other devices (i.e. transmitted on the air), for instance connection setup and negotiating the Cryptographic parameters. Additionally, LM implemented on the Bluetooth controller and consequently this results in being invisible to the OS (i.e. can not be captured and monitored.).

At this point, Dennis introduced the framework “InternalBlue”, which was developed by him during writing his thesis at the point when he found that he is able to modify the firmware of the Bluetooth chip. The framework is basically a python module, which either can be used by importing it into Python script or as a command-line interface (CLI). The framework however was initially built around the Android Nexus 5 OS, but currently Jiska and other students as well working on adding support to other platforms and more features. The framework communicate with the Nexus device over Android Debug Bridge (ADB) protocol to communicate then with Bluetooth chip on the Nexus 5.

Dennis then showed how they were able to find some interesting HCI commands, which gave them possibilities to read and write into the memory space (RAM) of the Bluetooth controller. These helped in reading the firmware and patched some parts of the ROM memory. By having this framework, it was possible to modify things in the firmware e.g. to see the LM protocol packet and also to experiment some old vulnerabilities such as CVE2018-5383. It also helped them in discovering a new vulnerability CVE2018-19860, which causes a DoS and some sort of code execution.

At this point Jiska took the stage and showed how was the struggle at the beginning to understand the firmware, by reading the standards and trying to discover the important functions and so on. She showed the first demo of how can be easy to capture the LM protocol and monitor the different commands sent over the air. The second second demo shown by her is the so called Nino attack, which is basically a MITM attack. As explained, this can be done by telling the attacked device that you have no input device and then the device will have no pairing number, but only No/yes options.

Another demo showed a proof of concept (POC) for the so called fixed coordinate curve invalid attack, which affects DH key exchange, where no verification for the y-coordinate is done by the vulnerable devices. This leads to a predictable key by a MITM attacker, who can zero out the y-coordinate during the key exchange. However, this attack is not deterministic as told by Dennis, because the private keys of both devices have to be even. This POC was mainly performed by patching the firmware on the nexus 5 and try to connect with another device, which wants to be checked against the vulnerability.

Jiska shares some parts of her journey to find new bugs in Bluetooth and how she discovered a new vulnerability that caused a crash, which also affects the WiFi channel. Finally she finished the talk by talking a bit about features included in the InternalBlue framework such as tracing and gave ideas about fixing bugs in older devices, which are not fixed yet.

To those who love technical talks, I would really encourage you to see the video.

Thanks for reading and be safe while using Bluetooth ^^,

 

Thanks for reading!

Ali Hardudi, Rene Puder