[HackerNotes Ep.89] The Untapped Bug Bounty Landscape of IoT w/ Matt Brown

Justin and Matt Brown discuss all things IoT, including the specializations and challenges in hardware hacking, Matt’s personal Methodology, what hardware you'll need to get started and a whole lot more. Check it out below!

Author

gr3pme
September 20, 2024

Hacker TLDR;

  • IoT Hacking as a Specialization: IoT can have quite a high barrier to entry in terms of knowledge and equipment. If you’re looking for a basic equipment list that will allow you to hit most IoT targets, you’ll need:

    • Hot air device

    • Chip reader

    • Soldering setup

    • Usb to 3.3v UART cable

    • Multimeter

    • Further details are in the blog below

  • Decrypting SSL to Chinese Cloud Servers: A common requirement when approaching IoT is to find a way to intercept traffic and beat any SSL/TLS mitigations that are in place to stop this from happening. A general overview on how Matt does this is via:

    1. Mitmrouter: For, as the name suggests, performing MiTM attacks

    2. A transparent proxy (Burp has a transparent mode for this use case)

    3. Certmitm: A one-stop shop for testing certificate validation vulnerabilities

  • General IoT Hacking Methodology: When Matt first approaches a target from a black-box perspective with no prior access or knowledge, the initial steps can be broken down into:

    • Gaining a shell: Trying UART or JTAG connections on a device to dynamically debug and interact with it

    • Chip-off techniques: Failing this, pull the chip from the device and dump the firmware for static analysis. More on this below.

    • Static analysis: Performing static analysis to uncover the underlying certificate validations (if any) to then intercept and modify data in transit

    • Certificate validation bypass: Using tools such as Certmitm or flashing the firmware with a new certificate to intercept and modify the traffic from the device for testing

  • Attack Surface, Network Services and Data in Transit: The IoT threat model can be quite different when compared to traditional applications or infrastructure. Some code is only ever executed upon the first power-on when registering the device for the first time, or when connected to other IoT devices. Equally, unique services such as Bluetooth, NF, RF, and many other types of services are exposed on some devices. Let’s dive in below.

IoT Hacking as a Specialization

Matt Brown is no stranger to IoT hacking - having taken home an MVH award at a previous live hacking event on an IoT target, he clearly knows a thing or two about the IoT hacking landscape. Let’s jump into some of the IoT knowledge dropped on the pod.

IoT hacking requires a lot of knowledge to get started. The very nature of IoT touches just about every discipline and skill set when approaching a target - you have the networking aspect, the API and application aspect, the code review, physical hardware and sometimes even mobile… the list goes on.

Furthermore, every IoT hunt usually starts black box - you have a device but you have no idea of its inner workings, how it operates, what services or protocols are in use or even what is actually running under the hood.

If you aren’t familiar with IoT hacking like myself, there are a few things to consider when jumping into a target. Equally, the IoT hacking path would very much suit someone who’d like to be a generalist and dabble in all of the above areas rather than specialising in web, mobile, infra, etc.

Here are some things to consider if you decide to approach an IoT target:

Problem #1: It requires a lot of upstart time before you start finding vulnerabilities

  • Pro: Once you get past the massive barrier to entry and finally have access to source code, you can be pretty certain that the attack surface hasn’t been looked at by many people, which could mean more bugs and more $$$$

  • Con: If you’re reliant on bug hunting as a source of income, you’ll have a longer run-up time before finding any bugs

  • Con: Attack vector ideation can be difficult if you aren’t familiar with IoT hacking

  • Con: CVSS doesn’t lend itself more towards IoT-based attack vectors, but good IoT programs will consider this and understand the threat model will bump it up.

Problem #2: It requires equipment and expensive hardware

  • Pro: As seen in problem #1, the higher barrier of entry likely means fewer people have looked at the attack surface

  • Pro: Once you have it, you’re good to hit most IoT targets

  • Con: Initial expenses can set you back

Note: We aren’t endorsing any of these products, but a rough equipment list to get started would look like the below:

Problem #3: It requires a lot of cross-field knowledge

  • Pro: For the hardware aspect, you can practice on older hardware from Ebay/E waste/second-hand stores without having to worry about bricking or breaking a device

  • Con: If you’re starting from scratch the learning curve will be incredibly high (but undoubtedly fun)

I think it's safe to say the IoT hacking path would very much suit someone who’d like to be a generalist and dabble in all of the above areas, rather than specialising just in web, mobile or infra.

You may have already seen this video as it has done incredibly well on YouTube, but one of Matt's videos which can give you a bit of a walkthrough on how he would approach and attack an IoT device can be found here, with the target being a VStarcam CB73 security camera: https://www.youtube.com/watch?v=3qSxxNvuEtg

One of the big objectives in IoT hacking is to bump or downgrade the SSL/TLS down, so you can examine and modify the traffic going on under the hood. A general overview of what you’ll need to do this:

  1. Mitmrouter: One of the tools used to perform this attack was Mitmrouter for the traffic hijacking perspective. All this does under the hood is ducktape a few open-source utilities providing pretty similar capabilities to the Wifi Pineapple.

    1. HostAPD: Used by Mitmrouter and provides fine grained access over WiFi configurations. Also allows payloads in the SSID; try out <script>alert(1)</script>

    2. IPtables configuration: Also used by Mitmrouter and allows you to specify which connections to route through your MITM setup

  2. A transparent proxy (Burp has a transparent mode for this use case)

  3. Certmitm: A one-stop shop for testing certificate validation vulnerabilities. Check out the Defcon talks to get hands-on with this one:

    1. https://media.defcon.org/DEF CON 31/DEF CON 31 presentations/Aapo Oksman - certmitm automatic exploitation of TLS certificate validation vulnerabilities.pdf

    2. https://www.youtube.com/watch?v=w_l2q_Gyqfo&ab_channel=DEFCONConference

  4. WiFi card: Any Alfa wifi card with a mediatek chipset

General IoT Hacking Methodology

Gaining a Shell & Chip-off Techniques

Over time, Matt has developed a general IoT methodology he follows when approaching a device. The first logical step would be to try and get a shell from something such as a UART or JTAG port or even glitching (check out the episode here with SinSynology for more on this)

Before we dive into the first step, it’s important to know there are two distinct categories of devices. You have micro-controller devices and Linux-based devices which run fully fledged OS’s like Linux or Android. As you can imagine, each has a different attack surface and is therefore treated differently for this first step.

Microcontrollers

Microcontrollers usually have built-in flash storage and in some cases even external flash. If it's external you can pretty much take the storage device out and perform a straight read of firmware. Think of a microcontroller as one static program which is started on boot and when the process is exited, the CPU halts. Sometimes there’s not even a file system for you to play around with.

Equally, with microcontrollers, when compared to a Linux counterpart there will likely be a much smaller attack surface once you’ve eventually read the chip. With that being said, once you’ve got the firmware, you’ll be looking at a binary and will have to decompile and reverse it.

One quick win when looking at these kinds of blobs is to look for secrets - running strings and performing a few greps will take you far.

Linux

When approaching a Linux-based target, Matt's first goal is UART access. UART provides more than just the firmware - it allows you to communicate with the device and live debug it.

When taking apart a device and looking around for UART, you want to be using your multimeter and finding a pin which fluctuates in voltage when the device is booting or active which will usually be the transmit pin. Somewhere close to this, you’ll also find the receive pin, which you’ll use to transmit to it.

Chip off

If any of the above fails, it’s time to attempt to take the chip off the device. You’ll need to identify the flash chip first and hit it with hot air in order to pull it off. You then need to clean the chip and put it into a chip reader and you should be able to read it as the device would.

This sounds relatively straight forward but you need to have the right reader. To save you some time, read the serial number on the device and make sure your reader supports that BEFORE pulling the chip off.

You’ll encounter a bunch of different types of flash chips when pulling apart hardware and you’ll probably need to purchase additional sockets in order to read some of them.

Depending on the reader you use and the memory in use, you will either be able to interact with the device like it's an external storage device (ie you can browse to it like a USB on your file system) or it will be read out of the reader's software and will give you the contents of the chip in a single file. The latter means the files won't be partitioned, so you will have to go through with something like binwalk and extract the pieces you need.

The TL;DR of approaching a target:

  1. Try UART shell to dynamically debug a device, massively saves time and is more useful than just firmware alone

  2. Failing this, pull the chip from the device and dump the firmware for static analysis

  3. Blackbox approach: If none of the above is possible or you don’t have the hardware, you can try from a complete external black-box perspective. Be prepared to be trying to decipher pcaps and do lots of service enumeration on the device, however.

    1. Trying to MiTM the device and downgrading any TLS/SSL traffic would be the go to here, but be prepared that there could be defences set in place to prevent this from happening. More on this shortly.

Now you either have a shell and/or extracted the firmware, now what? Matt, depending on the context, will go down the network services route or data in transit.

Attack Surface, Network Services and Data in Transit

You’ll likely see common network services on IoT devices where the principles don’t change much - whether its a web server, API server or maybe even another more obscure service.

You might even encounter a custom network service which will lead you down the road of binary reverse engineering. If this is the case, you’ll be reliant on the chip-off techniques and static analysis to begin with.

Some other services to think about are Bluetooth, NF, RF.. any form of integration or means of communication that the device has. Threat modelling these and considering how they could be abused to adversely affect the device, or use cases of the device, should also be considered as after all, they provide additional attack surface to look at.

IoT devices sometimes even reside within an ecosystem - ie a speaker can talk to the TV, or devices can connect to one another, or talk to a smart watch and so on. Ensuring that all devices possible are online and connected can unlock additional attack paths and hit code that otherwise wouldn't be accessible - this is another way to unlock additional attack surfaces in the IoT world that many people likely haven't looked at.

IoT devices often only enter some states or flows once. What do we mean by this? Well, Matt provided a few examples from IoT devices he’s pwned in the past:

One Shot Requests

Some requests are only ever sent during the setup or configuration process of an IoT device, and never after that point. The process of the initial setup and those requests made can be incredibly useful - one example mentioned was on an IoT device that only ever sent 1 HTTP request the first time the device was booted.

Despite doing factory resets and attempting to re-create it, the device only issued the request on the very first bootup in order to persist some data to the firmware. Pretty cool!

Device Boot Strapping

When first configuring a device, one of the big questions is how does the device gets its initial connection to the internet? There’s a few different choices a manufacturer can take as most IoT devices will at some point need access to your wifi. The process on how this device gets access can often be flawed.

Some devices spin up their own WiFi access point for you to connect to as a client, which then exposes an API or additional interface to the LAN it’s created. Looking at these exposed interfaces or APIs can yield some pretty interesting bugs.

Furthermore, if an IoT devices registers to a user account on a cloud service that’s used in conjunction with the device, a common design pattern is to retrieve the serial number of the device and match it to the user's account. These serial numbers are often ephemeral and could allow you to iterate through all serial numbers and associate them all with your account.

IoT Bug Stories

Missing Secure Boot - IoT Device

Not all companies care about missing secure boot in their threat model of IoT devices, but this particular target Matt approached did. The purpose of secure boot is to ensure that the firmware being booted has not been modified or tampered with in any way.

The target used a microcontroller-based device. As mentioned earlier, one of the first things to do is to try and debug the device or gain access to the firmware. In this instance, the device did have an external flash chip. This meant the chip could be pulled straight from the device and read.

Once pulled, the firmware was examined with binwalk. Whilst examining the firmware, some certificates were present on the device which suggests that the traffic will be encrypted when attempting to intercept it.

With this knowledge, the first step was to perform a MiTM on the device with Mitmproxy. Mitmproxy contains a CN of MitmProxy which is used to forge, and sign, certificates with the MitmProxy CA for any SSL/TLS traffic. This certificate is then presented to the client, but in this instance, the device did not accept the certificate and it wasn’t possible to intercept the traffic.

As Matt had no knowledge on this microcontroller but needed to view the traffic, he instead took a different approach. He generated a certificate which matched the exact byte size of the certificate identified from binwalk, and replaced the certificate on the device via the dd command with his own at the exact location, by byte specific, he identified the prior certificate.

This resulted in a new firmware image. The firmware was then flashed back to the chip, the chip soldered back onto the board and powered on. When the device started booting, MiTM proxy could intercept the traffic!

Now, it’s worth nothing that with the certificate replaced the firmware should, in theory, only support communications with the MiTM certificate. For one reason or another Matt didn’t have MiTM proxy running and checked the device status and.. it was still working? Communications on the device were still calling home successfully.

This meant that the certificate validation on the device was fundamentally flawed, resulting in a 2 bugs in one scenario - one for missing secure boot, and one for missing certificate validation.

Not bad for not turning on a proxy - when I do that, I’m usually sat wondering what’s happened to my internet.

Certificate Pinning and Certificate Validation

One thing worth noting when approaching an IoT device is that the communications, and how they are implemented, are often an integral part of the device and its threat model. You might even see some OOS certificate-related bugs on the program policy page, but it’s important to differentiate between certificate terminology.

Certificate Validation

In its simplest form, certificate validation is the process of verifying that a server's certificate is signed by a trusted Certificate Authority (CA).

Certificate Pinning

Certificate pinning adds an extra layer by specifying exactly which certificates or public keys are acceptable, ensuring the device only trusts specific certificates, even if they are issued by a trusted CA.

Certificate pinning is simply a stricter form of certificate validation. If a device is doing certificate validation, ie actually checking the server is presenting a cert signed by a trusted CA in its trust chain, but not pinning, that’s still an acceptable implementation.

If you can find a problem on the certificate validation on any of the communications the IoT device uses that also contain sensitive information, that will probably be a bug. If the device is doing neither of these, then that's a high/crit guaranteed.

HackerOne platform standards have also been updated to include IoT, which states certificate validation flaws should be rated as a high.

Very interesting episode this week, I think it’s even encouraged me to give IoT a go one day.

As always, keep hacking!