IoT Penetration Testing Cookbook.: Identify vulnerabilities and secure your smart devices

Testing applications, networks, and devices for security flaws are vital for keeping the internet more secure and safe. Whether testing occurs by the manufacturers, third-party consulting firms, enterprise security teams, or security researches, approaches vary depending on the information given to the testers who are performing the assessment. Ideally, a comprehensive test should include the entire IoT system as well as its infrastructure, and not just the device itself, but it is not uncommon for testing to include only a subset of an IoT system due to pricing or technical ability.

Let's first have a look at the bootloader. A bootloader's responsibility is to initialize RAM for volatile data storage, initialize serial port(s), detect the machine type, set up the kernel tagged list, load initramfs (initial RAM filesystem), and call the kernel image. The bootloader initializes hardware drivers via a Board Support Package (BSP), which is usually developed by a third party. The bootloader resides on a separate Electrically Erasable Programmable Read-only Memory (EEPROM), which is less common, or directly on flash storage, which is more common. Think of the bootloader as a PC's BIOS upon start up. Discussing each of the bootloaders' responsibilities in detail is beyond the scope of this book; however, we will highlight where the bootloader works to our advantage. Some of the common bootloaders for ARM and MIPS architectures are: Redboot, u-boot, and barebox. Once the bootloader starts up the kernel, the filesystem is loaded.

There are many filesystem types employed within the firmware, and sometimes even proprietary file types are used depending on the device. However, some of most common types of filesystems are SquashFS, cramFS, JFFS2, YAFFS2, and ext2. The most common filesystem utilized in devices (especially consumer devices) is SquashFS. There are utilities, such as unsquashfs and modified unsquashfs that are used to extract data from squashed filesystems. Modified unsquashfs tools are utilized when vendors change SquashFS to use non-supported compressions, such as LZMA (prior to SquashFS 4.0, the only officially supported compression was .zlib), and will have a different offset of where the filesystem starts than regular SquashFS filesystems. We will address locating and identifying offsets later in this book.

For additional reading on filesystems for embedded Linux, please visit the following link: http://elinux.org/images/b/b1/Filesystems-for-embedded-linux.pdf.

Similarly, there are many types of file compression utilized for firmware images, such as LZMA, .gzip, .zip, .zlip, and .arj, to name a few. Each has pros and cons such as the size after compression, compression time, decompression time, as well as the business needs for the device itself. For our purposes, we will think of the filesystem as the location that contains configuration files, services, account passwords, hashes, and application code, as well as start up scripts. In the next chapter, we will walk you through how to find the filesystem in use as well as the compression in use.

Within the filesystem, device-specific code resides, written in C, C++, or other programming languages, such as Lua. Device-specific code, or even all of the firmware itself, can be a mix of third-party developers contracted out, known as Original Design Manufacturers (ODM), or in-house developers working with the Original Equipment Manufacturer (OEM). ODMs are an important piece of the embedded device development supply chain. They are often small companies in Asia and are a dime a dozen. Some OEMs have trusted ODMs they work with on product lines, while others will do business with ODMs that have the lowest fees for only one product. Depending on the industry, an ODM can also be referred to as a supplier. It is important to note that ODMs are free to work with a number of different OEMs and can even distribute the same code base. You may be familiar with this notion or even wondered why a critical public advisory affects ten plus device manufactures for a software bug. This occurs due to a lack of secure development life cycles processes by the ODM and verification by the OEM. Once an ODM completes their application deliverables, which may be an SDK or firmware to the OEM, the OEM will merge its code base(s) into the firmware, which may be as small as OEM logos on web interfaces. The implementation varies depending on how the ODM and OEM merge their code; however, it is not uncommon for an ODM to provide a binary file to the OEM. OEMs are responsible for distributing the firmware, managing firmware, and supporting the device itself. This includes firmware security issues reported by third-party researchers, which puts a strain on OEMs if ODMs retain the source code and the OEM only has access to a binary image.

In Chapter 3, Analyzing and Exploiting Firmware we will learn how to reverse engineer firmware binary images by recognizing the filesystem, identifying compression, and emulating binaries for testing, to take advantage of common firmware issues.

The communication between browsers, embedded servers, and web application servers is typically done through a web service such as Simple Object Access Protocol (SOAP)/XML or an API which is based on Representational State Transfer (REST) over HTTP/HTTPS. SOAP requests consist of an envelope element, an xmlns:soap namespace, an encodingStyle attribute, and various elements such as the SOAP body element. Additional details on SOAP can be found by visiting the following link: https://www.w3schools.com/xml/xml_soap.asp.

An example of a HTTP SOAP request querying for an account balance is shown here:

POST http://example.com/soap/webservices HTTP/1.1 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-US,en;q=0.5 
Authorization: BasicYWRtaW46YWRtaW4= 
Content-Length: 821 
Content-Type: text/plain;charset=UTF-8 
DNT: 1 
Connection: keep-alive 
Host: example.com 
 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://example.com/webservices/BillingAccountSummary/V1"> 
   <soapenv:Header/> 
   <soapenv:Body> 
      <getAccountBalance> 
         <messageHeader> 
            <action>get</v1:action> 
            <scopeObject>AccountBalance</v1:scopeObject> 
            <revision>1.0</v1:revision> 
           <createdTimestamp>2017-01-13T09:15:01.469</v1:createdTimestamp> 
            <sourceInterface>WEB</v1:sourceInterface> 
            <messageIdentifier>00810187-101EDDA4</v1:messageIdentifier> 
            <functionName>getAccountBalance</v1:functionName> 
         </messageHeader> 
         <billingAccountIdentifier>1234566</v1:billingAccountIdentifier> 
      </getAccountBalance> 
   </soapenv:Body> 
</soapenv:Envelope> 

REST style APIs utilize various HTTP methods that may not be standard in traditional web applications, such as the PUT method, to update resource values as well as DELETE methods to remove values within an API. REST requests can utilize parameter calls via the URL (not recommended for sensitive data) or via the HTTP body in JavaScript Object Notation (JSON).

An example REST request subscribing the test@example.com email address to an email distribution list is shown here:

POST /rest/email/subscribe HTTP/1.0 
Host: example.com 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Content-Type: application/json 
Content-Length: 160 
Connection: close 
 
{ 
  "subscriberId":"12345", 
  "emailAdress":"test@example.com", 
  "confirmed":"Y" 
} 

In order to view SOAP or REST requests, a man-in-the-middle proxy is required. Tools such as Burp Suite and/or OWASP ZAP are used as web proxies to view all requests being made from the browser and the mobile application to the application's web backend infrastructure. We will go through setting up the configuration to proxy the application traffic later on in Chapter 4, Exploitation of Embedded Web Applications.

As it pertains to IoT, web applications are a common way to control devices and are just one attack entry point from both the internal and external network perspective. In Chapter 4, Exploitation of Embedded Web Applications, we will learn how to identify common IoT web application flaws and exploits.

Mobile applications installed on an Android, iOS, or Windows phone device can be hybrid or native. Although the terms hybrid and native have different meanings in the mobile application sense rather than web applications, the principals are similar. A hybrid application utilizes both web technologies, such as HTML/HTML 5, CSS, and JavaScript, as well as some native platform hardware, such as GPS or Bluetooth. Access to hardware resources is only through the use of plugins provided by the hybrid framework. Think of hybrid apps as web applications packaged up into a wrapper that the native platform can use. This means that a web developer can now code a mobile app without having the learning curve of a new language.

Hybrid applications use one code base for multiple platforms, such as Windows Phone, Android, and iOS, which is a huge plus when thinking of the first to market for IoT devices. Applications are called over the web using an embedded web browser known as WebView. There are many hybrid frameworks that the most popular apps use in the market today, such as Apache Cordova, Adobe PhoneGap, and Xamarin, to name a few.

Each of the mobile hybrid frameworks contains a third-market place which contains plugins for various features. Some frameworks such as Xamarin are written in one programming language (C#) and translated into a native language (Objective C and Java) for rapid development purposes. These mobile frameworks are known to have a number of security advisories ranging from critical remote code execution issues on the native platform to privacy concerns. If you happen to notice a certain mobile hybrid framework being utilized, it might be a good idea to have a look at a vulnerability database for easy wins.

To give you a better idea about the architecture it takes to run a hybrid application, the following diagram shows the different components between the application code, WebViews, plugins, and the mobile device itself. Keep in mind, most of the wrapper code and plugins are developed by the hybrid framework or third-party developers who contribute to the framework:

Hybrid application example

Native applications are built for specific operating systems and written within the device platform's native language, such Java, Objective C, Swift, and even C# for Windows phones. Native applications use their respective platform SDKs, which gives the app access to hardware such as the camera, Bluetooth, and GPS. Performance and security are better with native apps but they are dependent on an experienced developer who knows a native language. This may be difficult, in some cases, for staffing developers as platform APIs often update and deprecate language classes or methods. More and more, platforms such as iOS and Android are developing native security APIs that developers can take advantage of without the need for utilizing third-party libraries. This is important for secure communication and secure data storage.

A native architecture is much simpler than hybrid application architectures. The following diagram shows a native application running native code directly on the device without the need for third-party components to access hardware resources:

Native application example

It's important to understand the pros and cons of each mobile application model for efficient testing. As device control is delegated to mobile apps, they are another attack entry point into a device that can sometimes be easier than another entry point. In Chapter 5, Exploitation of IoT Mobile Applications, we will delve into some of the most common vulnerabilities in IoT mobile apps as we dissect an IoT device.

The EEPROM is a non-volatile storage location which is read and writable as single blocks of bytes. The EEPROM can be erased by electrical charges or UV exposure. Similar to other flash storage types, EEPROM allows a limited number of write cycles. EEPROM is a chip of interest, as firmware may be loaded on an EEPROM and can be removed from the PCB to an EEPROM reader for further analysis:

EEPROM Image source: https://cdn.sparkfun.com//assets/parts/3/0/5/EEPROM.jpg

NAND flash memory is written and read in blocks, which are commonly found in USB drives but are also in IoT devices as well as game consoles. The NAND flash typically contains a device's bootloader which follows various instructions to start the operating system and can be manipulated; we will walk you through this later on in this book.

UART is one of the most common ways to gain access to devices. Manufacturers use UART for diagnostics, log messages, and as a debug console for verifying configurations when deploying devices, which makes it one of the most common sources of input in firmware. Since it's used for debugging, root access is commonly granted once connected. However, there are times when UART access is password protected, which may add extra time for brute-forcing. UART contains about eight data lines with control pins and also has two serial wires which are the receive data and transmit data wires (RX/TX). No external clock is needed for UART. UART pinouts on the PCB are TX, RX, Vcc (voltage), and GND (ground). In order to connect to a UART, the TX, RX, and GND must be located using a multimeter. Sometimes, a locating UART may be more difficult on some devices, than others. Some manufacturers may remove the UART header pins from the PCB, requiring soldering to take place. Manufacturers may also cover UART header pins with various layers of silkscreen and cover the headers with another integrated circuit which may be a bit of a pain.

JTAG is another serial communication under IEEE 1149.1. It was created for chip-and system level testing. Manufacturers use JTAG as a source of debugging, similar to UART. There is the ability to password protect JTAG access, but the BYPASS mode should still work. Firmware can be dumped for analysis or upgraded using JTAG. It provides a direct interface to hardware on the board which means it can access devices connected to it, such as flash or RAM. There is a TDI (data in), TDO (data out), TMS (test mode select), TCK (test clock), and TRST (test reset). JTAG connects to an on-chip test access port (TAP) which regulates a state when accessing registers on chips. Similar to UART, manufacturers may obfuscate header pins or traces.

To view the PCB and locate components in an IoT device, one can either disassemble the device or search through third-party sites such as https://fccid.io. An FCC ID is a product ID that is assigned by the FCC in order to keep track of wireless products in the market. Fccid.io is awesome and provides us with loads of detailed information on devices! The FCC publishes various design documents, datasheets, internal images, external images, test reports, various manuals, wireless frequencies, and more. In Chapter 6, IoT Device Hacking, we will walk you through the methodology of hardware hacking to locate hardware details and connect to inputs.

Wi-Fi has been the most common wireless technology used in many devices for years. It operates on 2.4 GHz and 5 GHz ISM bands. There are a number of Wi-Fi standards in use, such as 802.11a, 802.11b, 802.11g, 802.11n, and 802.11ac. 802.11b and 802.11g operate on the 2.4 GHz band while 802.11a, 802.11n, and 802.11ac use the 5 GHz band. There are 14 wireless channels which operate on different frequencies. Depending on the region, there are certain channels that Wi-Fi routers are allowed to broadcast on.

ZigBee is based on the IEEE 802.15.4 specification for the physical and media access control layers, which support low-powered wireless mesh networking. ZigBee operates on different ISM bands based on region, but mostly on 2.4 GHz worldwide with 915 MHz in the US and 868 MHz in the EU. ZigBee is comprised of a coordinator (ZC), router (ZR), and end devices (ZED). The coordinator automatically initiates the formation of the network. There is only one coordinator in a network and it's generally the trust center for authenticating and validating each device that has joined the network and has a unique network key. The router passes data from other devices and associates routes to end devices.

Routers have to be continually powered in order to properly pass messages to the network. End devices are IoT devices such as light switches, sensors, cameras, or monitors. They cannot route data inside the network but can be put to sleep in a low power mode while not transmitting. ZigBee networks are based on two security keys known as the network key and link key. The network key is used to securely transport communication and is a 128-bit key shared with all devices in the network. The link key is used to secure the unicast communication in the application layer of ZigBee. The link key is also a 128-bit key which is only shared between two devices. Link keys can be pre-installed on devices or distributed through a key exchange. Vulnerable key exchanges during device pairing is a known flaw in consumer-based ZigBee networks, which has allowed attackers to sniff the exchange network key and compromise the entire network.

A good slide deck for referencing ZigBee security flaws can be found via the ZIGBEE EXPLOITED talk given at Blackhat in 2015:

https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly-wp.pdf.

Z-Wave is another low-powered wireless communication protocol that supports mesh networks with a master-slave model. It uses the sub-1 GHz band which varies by region (916 MHz in the US or 868.42 in the EU). Its physical and media access layers are ratified under ITU as the international standard G.9959. Z-Wave's range between two devices is 328 ft. or 100 meters, but it can reach up to 600 ft. or 200 meters when traffic traverses through Z-Wave products with in its mesh network. The Z-Wave network is identified by a 4 byte (32-bit) HomeID which is the controller or master node's unique ID. All nodes within the same network share the same HomeID. Each node is identified by a 1 byte (8 bits) NodeID which is provided by the controller once they are joined to the network. Nodes with different HomeIDs cannot communicate with each other. Z-Wave can use AES encryption, which is supported by Z-Wave hubs, but it is purely optional for manufacturers to implement. Z-Wave does include a nice signal jamming detection feature that prevents Denial of Service (DoS) attacks.

For additional specifications on the Z-Wave protocol, please visit http://www.z-wave.com.

Bluetooth is a commonly used wireless technology standard (IEEE 802.15.1) used for data communication over short distances. Bluetooth broadcasts at over 2.4 to 2.485 GHz and can reach up to 100 m but is more commonly used under 10 meters or 30 ft. This book will contain Bluetooth and Bluetooth Low Energy (BLE) testing techniques, as plenty of IoT devices do utilize a form of Bluetooth as a primary means of communication. For additional reading on Bluetooth, visit the following link:

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works

Software tools will cover firmware, web applications, and mobile application testing tools. The majority of testing tools are free for each of the three categories, with the exception of Burp Suite for web application testing. For convenience, time has been taken to set up and install most of the software tools for firmware analysis, web testing, mobile testing (limited), and radio analysis within a virtual machine for this book. However, a list of all tools has been compiled and is recorded here.

Mobile application software tools

Like firmware tools, most mobile application security tools are also free and open source. The mobile tools that will be used are broken down according to the mobile platform below.

Android

There are many Android testing tools and virtual machines available online as of the writing of this book. Some tools focus purely on statically analyzing an APK's code while other tools focus on app analysis during runtime. Most of the Android testing virtual machine distributions are free and contain the necessities for testing an Android app such an Android's SDK. Although Android testing tools are listed here, it is recommended you download an Android testing virtual machine distribution that suits your testing needs, and install any supplemental testing tools in that virtual machine.

Although not required, keeping your Android testing tools separate from your host computer will lead to a more stable mobile testing workbench and prevent dependency issues as well.

• Android testing virtual machine distribution:
  • Android SDK
  • Android emulator
• Enjarify
• JD-Gui
• Mob-SF
• SQLite browser
• Burp Suite
• OWASP ZAP

iOS

iOS testing tools are unique in that an OS X computer and a jailbroken iDevice are required for testing. Without these two prerequisites, the testing of iOS applications will not be possible. Here are some of the tools that may be utilized for iOS mobile testing:

OS X computer

The following listed items are software tools that are to be installed on your host computer for testing and/or assessing iOS applications:

• idb
• Xcode tools
• Class-dump
• Hopper (optional)
• Mob-SF
• SQLite browser
• Burp Suite
• OWASP ZAP

Jailbroken iDevice

The following list includes packages that need to be installed on to your jailbroken device in order to start testing:

• Cydia
• openURL
• dumpdecrypted
• ipainstaller
• SSL Kill Switch 2
• Clutch2
• Cycript

Hardware analysis tool requirements

Hardware tools vary for the specific device that is being analyzed; however, there are basic tools that are valid for all hardware and even electrical requirements. Manufactures will use different types of screws, housing, and security bits as a stopgap for hardware disassembly. Sometimes, the screws will be hidden under labels or rubber feet. It's important to identify the screw types. We will list toolkits available that can bypass this obfuscation technique used by vendors. The following figure should assist with some of the different types of screw type:

Image source: http://www.instructables.com/id/When-a-Phillips-is-not-a-Phillips/

Listed here are the options for hardware tools and hardware analysis software that will be used in this book.

Hardware tools

Hardware testing tools require some upfront investment to get started. Here are the required and optional tools needed for disassembling devices, finding ground, and accessing device interfaces:

• Multimeters
• IFixit classic pro tech toolkit for hardware disassembly
• Bus Pirate
• USB to serial adapters
  • Shikra, FTDI FT232, CP2102, PL2303, Adafruit FTDI Friend
• JTAG adapters
  • Shikra, JTAGulator, Arduino with JTAGenum, JLINK, Bus Blaster
• Logic analyzer (optional)
  • Saleae Logic or others

For more information, you can visit these following links:

• https://www.ifixit.com/Store/Tools/Classic-Pro-Tech-Toolkit-/IF145-072-1
• http://int3.cc/products/the-shikra
• https://www.sparkfun.com/products/12942
• http://www.grandideastudio.com/jtagulator/
• https://www.saleae.com/

Hardware analysis software

Here are some hardware analysis tools that are all free. These tools enable us to access hardware interfaces for things such as console access or side-loading firmware onto the device:

• OpenOCD
• Spiflash
• Minicom
• Baudrate