IoT pentest process - Exploitation

2. Exploitation

After finding a satisfactory number of potential vulnerabilities, we move on to the exploitation of our device (or segment of devices). Below are some guidelines that can be useful when conduction the exploitation phase. As with the information gathering, the exploitation techniques differ for different areas of the device (hardware, firmware etc.) and among different devices. Remember to document the used methodology of both successful and unsuccessful exploitation tests. Even if no vulnerability has been successfully exploited or even if no vulnerability was found, it is possible to write a valuable thesis report as long as the process is systematically documented.

Several valuable sources exist online. Exploit databases with existing exploits for known vulnerabilities can save time, such as packetstorm or ExploitDB and rapid7’s metasploit framework may contain useful exploits that can be executed without much effort.

2.1 Hardware and firmware

The hardware penetration testing section contains detailed information about various types of hardware hacking together with a collection of links and tutorials that can be useful.

We want to spend considerable efforts on analysis of physical interfaces and firmware reversing. Exploitation of the hardware’s physical interfaces includes dumping firmware, backdooring firmware, granting shell access, changing code execution, misusing test functionality, exploiting known vulnerabilities in 3rd party chips, examining external media interfaces, sensitive data exposures, and tamper resistance.

After the firmware dumping we can extract the file system inside for analysis. Exploitation of firmware includes searching for sensitive data within the file system, such as hashes, passwords, private certificates, API keys, and staging URLs. After that, libraries that often contain sensitive data are reverse engineered (for certain architectures ARM and MIPS) to identify specific vulnerabilities, command injection and buffer overflows. In general, critical functions are disassembled in detail and main binaries are emulated for dynamic analysis (debugging). The firmware is also fully emulated to perform network testing and web application pentesting on the firmware. In addition, pentest cases include analyzing update mechanisms for malicious updates, local data storage for unencrypted sensitive data, and configurations for security settings. It can be good to look through the firmware pentest methodology by OWASP or our own

2.2 Network

The traditional network pentest approach can be applied to the IoT device’s network services. We want to exploit a network service to gain user-level access to the device and then escalating our privileges. Semi-automated tools such as the metasploit framework contain several networking exploits that may be applicable to the device for convenient exploitation of known vulnerabilities. If needed, we can perform brute force attacks against the authentication mechanisms and decrypt insecure network traffic. When a vulnerability has no public exploits, we can develop our own.

2.3 Web, cloud, and mobile exploitation

We perform traditional web application pentesting for the web applications related to our selected IoT device. The main objective is to exploit a webpage to execute commands on the device (remote code execution). Then, if possible, we also want to bypass the authentication. When web application scanners find vulnerabilities they usually provide primitive payloads for proof of concept. These can assist us in designing the real working exploit codes. Once again, some vulnerabilities could be exploited with semi-automated tools (such as Metasploit), we may want to use brute force attacks against some authentications and if no publicly available exploit exists for a vulnerability, we can develop our own. OWASP’s Web Security Testing Guide is a good source of information on how to conduct a web based penetration test from scratch.

When performing cloud exploits, we are often interested in obtaining sensitive and unauthorized data. For mobile devices relating our IoT device, we can apply traditional mobile pentesting schemes, such as reverse engineering of the Android and iOS code. The device may be set up with default credentials such as admin/admin or similar which we can also test for. The credentials may otherwise be derived from a pattern that can be cracked or understood, such as the AutoPi vulnerability where the device’s password could be derived from the ID, which in turn could be reduced to a 8 digit hexadecimal number. The mobile app may be ignoring certificate issues, (i.e. the application communicates over an insecure channel with non-trusted CA for the SSL certificate). For more information, the Owasp Mobile Security Testing Guide is useful.

2.5 Radio communication

BLE (Bluetooth Low Energy), Software Defined Radio (SDR), and ZigBee are common in many IoT devices. Depending on the communication protocol, specialized equipment may be required to perform specific radio pentesting. Please refer to the lab equipments section to see which tools are available. If you need to purchase additional equipment, contact your supervisor. If possible, we want to extract sensitive information in clear text from the radio packets. The TLS connections can be inspected to find whether they are vulnerable to MitM attacks. If certificate validation is missing, we can usually conduct further attacks depending on the context. If there is no message verification we can retransmit captured data for a reply attack. If there is a message verification, it may still be possible to jam the signal to capture unused radio packets for re-transmission. It can also be relevant to perform reverse engineering and fuzzing of unknown or custom protocols and decode data packets. More information can be found in our wireless hacking guides