IoT pentest process - Planning

PatrIoT: Practical and agile threat research for IoT

Emre Süren, Fredrik Heiding, Johannes Olegård, and Robert Lagerström from NSE have developed an IoT penetration testing methodology called PatrIoT. You can read more about it here.

Penetration testing of Connected Households

Additionally, a new article based on the previous research done at the NSE Lab has been published. In it, you can find an overview of how devices have been hacked in the lab and inspiration for future hacking. You can access it at Science Direct.

1. Planning

Depending on the goal of the penetration test, the aim may be to assess the security of a segment of IoT products (such as smart home products), assess the security of an individual IoT product, such as a JISIWEI I3 Robotic Vacuum Cleaner or a number of other variations. When we have selected a device, or a segment of devices to test, we usually start with gathering as much information as we can about this specific area. Remember to document all your findings. Even if no vulnerability is found in the device, it is possible to write a valuable thesis report as long as the process taken to identify vulnerabilities is systematically documented.

1.2 Information gathering

In the reconnaissance phase we aim to gather as much relevant information as possible about our device. If a larger segment of products is chosen, every device belonging to the segment is examined. We may start with a comprehensive documentation review of the device, as well as physically examining it. Finally, certain active and passive scanning and enumeration techniques can be applied for hardware, firmware, radio protocols, network services, web applications, cloud APIs and mobile applications. We want to find all potential attack vectors that can be tested and potentially exploited in the next phase of the penetration test. In the light of these inquiries, all hardware, communication protocols, and software components are identified and their functionality are categorized.

Hardware and firmware

A smart device is an embedded system that can be a Hub (a smart IoT gateway), a smart sensor that collects data from the environment, or a controller (actuator) that performs an action upon user request, or analyzes and displays the data.

Visual observation and physical examination of the device involves identification of available ports, slots, buttons, etc. and may include physical disassembly of the device. IoT devices typically have some modules on PCBs (Printed Circuit Boards), a processor, RAM, ROM, peripherals, connectors, antennas, screens, and ribbon cables etc. The board also exposes debugging ports (JTAG, SWD, etc.) and communication interfaces (UART, SPI, I2C, etc.) and particular pins (Tx, Rx, TDO, etc.) that can be interesting.

The modules on the PCB vary in size, shape, and other aspects depending on the functionality of the device, this is known as packaging (DIL, SMD). The packaging type of a module is important, since associated hardware adapters and other utilities are required to interact with them when pentesting. Particularly, for hardware testing it is important to take photos of the components inside the PCB. The official technical specifications are carefully interpreted including user and developer manuals. The processor’s datasheet usually contains information about interfaces, I/O ports, interrupts, and more. Also, available public documentation (i.e. fccid.io) is explored to reveal incomplete information (i.e. chip pinouts). An additional search can be executed on repositories of known data-sheets for still missing specifications on the manufacturer’s website. Moreover, we can search online for modules that do not contain a model number. Finally, to be able to derive use case diagrams later on, relevant information is summarized, including what each device does and how they work, how devices communicate among themselves and between each other, how the input and output of the device works, and the functionality of the buttons and external interfaces.

Radio communication

IoT devices often communicate and exchange data via radio protocols such as Bluetooth Low Energy (BLE), Software-defined radio (SDR), and ZigBee. The radio chipsets on the PCB provide information about the radio protocols supported by a device. Manufacturer documentation and public resources can reveal useful information such as the operation frequency of the device. It is also valuable to investigate whether there are similar devices operating in the same frequency range as these devices. Additionally, radio traffic is captured for preliminary analysis. It is vital to capture radio traffic while devices have just started sending and receiving their first bits, otherwise the collected data may not be accurate, since some types of data may only be exchanged when the device is first introduced to the network. We can find useful information such as the component that initiates the authentication and pairing mechanism, the internals of the pairing operation, how many devices each component can handle simultaneously, the nature of the data transmitted through protocols, transmission commands, operating frequencies, and default encryption keys among other things.

Network services

Modern firmware has evolved into an operating system (i.e. Linux) that provides some network services such as SNMP, FTP, and HTTP, especially for remote access. Traditional port scanning techniques (nmap) are performed to identify open ports along with the running applications and their versions. In addition, services which require authentication are identified and network traffic is captured.

Web applications

Firmware may also have an HTTP service hosting a website designed for management, configuration, and status information. Traditional webpage crawling and enumeration techniques are performed (i.e. dirb, dirbuseter, wfuzz, gobuster, nikto) to discover all web pages and the development technologies with their versions.

Cloud APIs

IoT devices usually send the collected data to a cloud service, accessed via an APIs. It allows the user to monitor the device, view data analytics and usage information, control permissions of who can control the devices, etc.

Mobile application

IoT devices are usually controlled through mobile applications. The application exposes the functionality of the IoT device and can show how the device works, as well as revealing sensitive data. Information gathering of mobile applications can utilize the following questions:

  • Which devices are controlled by the mobile app?
  • Which control commands are sent to the device over which protocols (BLE, WiFi)?
  • What are the main functionalities of the mobile app (add/remove device/user, switch on/off)?
  • What are the other useful features of the mobile app (activity log, update firmware)?
  • How does certain actions work (action X works with a one-time key/PIN code)?
  • Summarize what functionality provides what?
  • What other actions are triggered automatically right after an action is started (log generated after switch on/off)?
  • What are the types of users and what access rights do they have?

Reverse engineering can be performed to learn more. Automated toolkits such as Apktool and jadx help us decompile the source code and perform static analysis of the mobile app. If performed successfully the compiled application code, dependent native libraries, resource files, and requested mobile device permissions can be revealed. The source code of modern applications is often obfuscated to prevent unauthorized knowledge of the operation logic, this may make reverse engineering harder and more time consuming. Therefore, an analysis can start with quickly inspecting files that seem promising. In addition, applications may store some data locally on the devices, these files are also valuable.

1.2 Threat and vulnerability analysis

Several threat scoring systems exist for classifying the vulnerabilities, such as STRIDE, DREAD, and CVSS. We can utilize a combination of these to create a comprehensive analysis of the threats and vulnerabilities.

When collecting information about the vulnerabilities, we must remember to examine previously known and publicly found vulnerabilities for the components, or similar components. For assistance, we have composed a spreadsheet of common vulnerabilities and a list of some common vulnerabilities for different parts as listed below. The vulnerabilities in the spreadsheet and the segments found below are derived from Mitre’s list, OWASP’s section of IoT vulnerabilities, and various more specialized sources as listed below. However, it is always important you make your own research to find the most relevant and up to date vulnerabilities for the given product segment you are testing.

Hardware vulnerabilities

We can connect to the Hub or device via its Ethernet port if one is available, the SD card slot can be used for firmware upgrades, and the processor’s Wi-Fi stack may contain known vulnerabilities. Below are 20 potential hardware vulnerabilities.

  • Senstive data exposure - Device ID/serial no
  • Insecure external media interfaces
  • Insecure 3rd party hardware components
  • Resettable to insecure state
  • Firmware/storage extraction - Download from the Web
  • Firmware/storage extraction - Insecure SPI interface
  • Firmware/storage extraction - Insecure I2C interface
  • Firmware/storage extraction - Insecure UART interface
  • Firmware/storage extraction - Insecure JTAG interface
  • Firmware/storage extraction - Insecure SWD interface
  • Firmware/storage extraction - Insecure SoC
  • Firmware/storage extraction - Tapping eMMC chip
  • Firmware/storage extraction - Unsoldering eMMC chip
  • Backdoor firmware - Insecure UART interface
  • Backdoor firmware - Insecure JTAG interface
  • Backdoor firmware - Insecure SWD interface
  • Grant shell access - Insecure UART interface
  • Grant shell access - Insecure SPI interface
  • Change code execution flow - Insecure JTAG/SWD interface
  • Lack of tamper resistance

Firmware vulnerabilities

The firmware can be a proprietary software where binary reverse engineering is relevant, especially for ARM and MIPS architectures. The reverse engineering can reveal sensitive information such as credentials, secret encryption/encoding keys. Below we define 26 potential firmware vulnerabilities. In addition to the vulnerability links listed above, OWASP has a specific section for firmware vulnerabilities.

  • Sensitive data exposure - Backdoor accounts
  • Sensitive data exposure - Hardcoded credentials
  • Sensitive data exposure - Encryption keys and algorithms
  • Sensitive data exposure - URL disclosure
  • Sensitive data exposure - Other sensitive information
  • Update mechanism - Missing update mechanism
  • Update mechanism - Lack of manual update
  • Update mechanism - Lack of transport encryption
  • Update mechanism - Lack of signature on update file
  • Update mechanism - Lack of update verification
  • Update mechanism - Lack of update authentication
  • Update mechanism - Intercepting OTA update
  • Update mechanism - Backdoor firmware
  • Update mechanism - World writable update location
  • Update mechanism - Lack of anti-rollback mechanism
  • Local data storage - Unencrypted data
  • Local data storage - Static and same encryption keys
  • Local data storage - Data encrypted with discovered keys
  • Local data storage - Lack of data integrity checks
  • Local data storage - Lack of wiping device
  • Authentication bypass - Device to device
  • Authentication bypass - Device to mobile application
  • Authentication bypass - Device to cloud
  • Configuration - Insecure customization of OS platforms
  • Configuration - Insecure filesystem permissions
  • Configuration - Lack of security configurability

Network service vulnerabilities

In the reconnaissance activity we may have found network services and their respective versions. We can search for the known vulnerabilities on these versions in a number of databases. Network vulnerability scanners can also provide matching vulnerabilities from their built-in databases automatically. It is not uncommon for IoT network services to run older versions that may have common vulnerabilities. Below we define 18 potential vulnerabilities for network services.

  • Sensitive data exposure
  • Lack of transport encryption
  • Insecure SSL/TLS issues
  • Authentication - Username enumeration
  • Authentication - Weak credentials
  • Authentication - Account lockout
  • Authentication - Known default credentials
  • Authentication - Insecure password recovery
  • Test or development services
  • Known vulnerable services
  • Exposed services running as root
  • Privilege escalation
  • Authentication bypass
  • Denial of Service (DoS)
  • Buffer overflow
  • Accepting connections without authentication
  • Insecure transport encryption
  • Sensitive data exposure

Web application vulnerabilities

We may have found interesting frameworks and their versions used by the web application of our IoT devices. These can be searched for known vulnerabilities. For a web application with a limited number of web pages, personal proxy toolkits can be utilized to examine the target and repeat modified web requests, in addition, various web vulnerability scanners can be used to search for vulnerabilities.

Web applications served on IoT devices are usually a wrapper for internal operating system utilities. User inputs are passed to these utilities to execute shell commands. Common injections are important vulnerabilities where unsanitized input can lead to remote code execution. Weak authentication mechanisms are also common. Below are 15 potential vulnerabilities for web application. In addition to the vulnerability links listed above, OWASP’s Web Security Testing Guide is a good source of vulnerabilities.

  • Sensitive data exposure
  • Lack of transport encryption
  • Insecure SSL/TLS issues
  • Authentication - Username enumeration
  • Authentication - Weak credentials
  • Authentication - Account lockout
  • Authentication - Known default credentials
  • Authentication - Insecure password recovery
  • Authentication - Lack of two-factor authentication
  • Authentication bypass - Web application to cloud
  • Lack of logging options
  • Command injection
  • Direct object references
  • Business and logic flaws

Mobile and cloud application vulnerabilities

Further reverse engineering and source code analysis may be required for vulnerability assessment of mobile applications. We may be able to find undocumented features or other loopholes that can generate attack vectors. Reverse engineering of communication APIs such as REST and SOAP may also be useful and reveal undocumented features that present attack vectors. Common hardcoded sensitive data includes firmware update URL, APK update URL, and cloud API authentication keys. In addition, the native components of mobile apps can help us understand various critical functions such as encryption. We also want to intercept the network traffic, we can do this by bypassing the SSL pinning and then perform a live analysis of the network traffic with a personal proxy. Finally, we can perform a dynamic analysis with a number of automated toolkits.

Common IoT specific security threats towards mobile and cloud application include insecure authentication and authorization mechanisms, business and logic flaws, insecure network communication, and outdated 3rd party libraries and SDKs. Below are 14 potential vulnerabilities for cloud apps and 26 potential vulnerabilities for mobile apps, partially derived from OWASP’s Mobile Security Testing Guide.

Cloud vulnerabilities:

  • Lack of transport encryption
  • Insecure SSL/TLS issues
  • Authentication - Username enumeration
  • Authentication - Weak credentials
  • Authentication - Account lockout
  • Authentication - Known default credentials
  • Authentication - Insecure password recovery mechanism
  • Authentication - Two-factor authentication
  • Vendor APIs - Inherent trust of cloud or mobile application
  • Vendor APIs - Insecure authentication
  • Vendor APIs - Insecure access controls
  • Vendor APIs - Undocumented backdoor API calls
  • Vendor APIs - User data disclosure
  • Vendor APIs - Device information leakage

Mobile vulnerabilities:

  • Sensitive data exposure - Hardcoded credentials
  • Sensitive data exposure - Encryption keys and algorithms
  • Sensitive data exposure - URL disclosure
  • Sensitive data exposure - Other sensitive information
  • Authentication - Username enumeration
  • Authentication - Weak credentials
  • Authentication - Account lockout
  • Authentication - Known default credentials
  • Authentication - Insecure password recovery mechanism
  • Authentication - Two-factor authentication
  • Authentication - Mobile application to cloud system
  • Insecure authorization
  • Implicitly trusted by device or cloud
  • Lack of transport encryption
  • Insecure SSL/TLS issues
  • Insecure data storage
  • Outdated 3rd party libraries and SDKs
  • Business and logic flaws
  • Lack of health checks
  • Insecure heartbeats
  • Device controlling commands
  • Lack of deprovisioning
  • Insecure pushing firmware updates

Radio communication vulnerabilities

A number of vulnerabilities may exist, ZigBee traffic can be sniffed and decrypted or we may be able to intercept the BLE traffic and session hijack. Different radio protocols have different vulnerabilities but several types are common among them, below are 11 vulnerabilities for radio protocols.

  • Sensitive data exposure
  • Lack of transport encryption
  • Interception and modification
  • Man in the middle attack
  • Replay attack
  • Jamming attack
  • Spoofing attack
  • Denial of service (DoS)
  • Lack of payload verification
  • Lack of message integrity check
  • Fuzzing custom protocols