Internet of Things devices have become more and more popular within the past few years, changing our lives and making things more efficient. However, just like computers, smart embedded devices can also be exploited. In fact, it is sometimes even easier for hackers to compromise an IoT device than it is to compromise a personal laptop. Similar to consumers, IoT manufacturers have a tendency to overlook security problems that arise in their systems. Vulnerabilities range from sensitive information leakage to a complete takeover of the system. Hackers can take over your car or home security system within seconds.
Here we will introduce the tools and processes involved in IoT device hacking and use the Kevo smart-lock as a case study.
IoT Hacking sounds challenging! Where should I start?
Since IoT devices vary in the types of processors they use, the first step of IoT hacking is information gathering. Usually at this stage we take apart the physical device to get as much information as we can. Some of this information would be the microcontroller's architecture/datasheet, mechanical structure, sensor type/datasheet, peripherals they have, etc. Taking Kevo as an example, we found out that it has a MSP430 microcontroller and a Bluetooth Low Energy module. One of the most useful pieces of information we might get during this stage is the presence of on-chip debugging pins. Manufactures usually have on-chip debugging pins on the circuit board for testing purposes. But these pins can also be really helpful for hackers. On Kevo, these pins do exist and they give us the ability to dump the firmware.
I found the pins! How do I extract the firmware?
IoT devices are particularly amenable to reverse engineering due to the ease of retrieving firmware, which is in the user's possession. For some devices, the firmware updates are sometimes even available online. There are also a handful of devices that don't encrypt their traffic when they pull their updates from the Internet so if you can intercept the traffic, then you can obtain a copy of the firmware. If neither of these techniques works, you can try dumping the firmware from the on-chip debugging pins that were detected from the previous step. For IoT developers, if you don't want hackers to have the ability to dump the firmware, there are usually fuses that you can blow out to make sure that your code can not be reverse engineered.
I have the firmware, now what do I do?
Once you have the firmware you can start reverse engineering using your favorite tool such as IDA Pro, radare2, or Binary Ninja. During this stage, you'll need to often read assembly code, a low-level representation of the machine language. You can also use on-chip debugging pins to help you debug the CPU or view different parts of the processor's internal state when you need. Once you have a general idea of what each function does, what each memory region maps to, and where most of the hardware peripherals are, you can start looking for vulnerabilities.
What type of vulnerability am I looking for?
There are some common attack vectors that are particularly easy for a hacker to exploit that manufacturers should pay special attention to. One of the more common ones is hard-coded encryption keys in the firmware. Attackers who gain access to the key can either decrypt the traffic or contents of the system's memory. Storing hard-coded keys inside the firmware is generally a bad idea for IoT system designers because of the particular ease of access. Remote update of firmware might also be an interesting attack vector if the update's authenticity isn't checked when an attacker uploads a custom firmware. Specifically for smart locks, attackers might attack the sensor to trick the lock into thinking it is locked, while it is actually not.
There are various ways that an IoT system can be attacked. In this post, only a few are introduced. It’s important that manufacturers realize that IoT devices are part of our daily lives and that IoT hacking is just not a thing from the movies but rather an essential activity to apply pressure on them to better secure their devices.
Written by Bo Wang, Security Innovation Intern