End-to-end ecosystem methodology
When examining IoT technology, the actionable testing focus and methodology is often applied solely to the embedded device. This is short sighted and incomplete. An effective assessment methodology should consider the entire IoT solution or as we refer to it, the IoT Product Ecosystem. Every interactive component that makes the product function is included in this IoT Product Ecosystem.
- Embedded device and associated sensors receivers and actuators
- Mobile application and or command and control software
- Cloud API and or associated web services
- Network communication protocols:
- 802.11 Wifi
- Intra-component communication such as Zigbee, Z-Wave, Bluetooth, etc.
Figure 1: Product IoT Ecosystem
Rapid7’s motivations behind examining the entire ecosystem is to ensure all components of the technology are secure. Failure of any component of the product ecosystem can and will affect the overall security posture. As an example, a failure in the cloud API security can easily lead to unauthorized access control of the embedded hardware, allowing a malicious actor to carry out attacks that could potentially impact the safety and security of the product user.
In the following sections we discuss the various areas and processes that should be a focus to ensure a thorough assessment of an IoT product ecosystems is conducted.
When conducting a test on an IoT product’s ecosystem, first and foremost an IoT product should be set up and configured within normal specifications. We generally prefer to set up two separate environments, which will better facilitate vulnerability testing, such a cross account and cross system attack and can also be used to make comparisons between normal and altered configurations. Leveraging a fully functional environment, we can then more effectively map out all functions, features, components and communication paths within the products ecosystem. Using this data we can next build out a test plan, which covers the products ecosystem from end-to-end.
We start each IoT security assessment by conducting reconnaissance and open source intelligence gathering (OSINT) to enumerate information about the components and supporting infrastructure. This enumeration can include, researching the make and model of the components and software used by the device, and identification of any external presence that makes up the cloud component of the product.
Cloud focused testing
IoT technology uses various web services for remote control, data collection, and product management. Often web services and cloud API can be the weakest link within an IoT product ecosystem. To validate the security, we conduct a very comprehensive assessment of the associated cloud services using functions and communication between the cloud services and all components in the product ecosystem. This allows us to validate the overall security posture of the product and determine impact and risk caused by security issues between components of the ecosystem. This also includes focused testing of the OWASP Top 10.
Mobile application/control system-focused testing
Generally IoT technologies commonly leverage various forms of remote control services such as mobile application (android, iOS) to remotely manage and control IoT technology. During this phase of testing we conduct in-depth testing and analysis of the mobile and remote application used to manage the IoT product. Again similar to the cloud testing, Rapid7 tests all functions and communications between the mobile applications and all components in the product ecosystem to validate the overall security posture of the product. This testing also focuses around the OWASP mobile top 10 to assure the application meets all security best practices.
IoT technologies commonly expose services via standard network communication paths such as ethernet and wifi, which can create an elevated level risk. During this phase of testing, we will identify all exposed TCP and UDP ports within the IoT ecosystems infrastructure. With this list of ports we can then conduct a thorough penetration test to identify all vulnerable or misconfigured services, which can be leveraged to compromise the system and or gain access to critical information.
We also perform a physical inspection to assess the physical attack surface of an IoT device. This inspection includes examining the device for JTAG and Serial pin-outs, as well as identifying the pins used for power, data, and control of individual components. Each device will have different components or elements but some common attack vectors include:
- Exterior USB Access
- Exterior port access
- Location and medium of storage
- Availability of debug console access
- Availability of serial console access
- Efforts required for disassembly of the device
- Risk to compromise based on brief physical access to the device
- Risk to compromise based on extended physical access to the device
- Risk to compromise based on allowed connectivity medium (Wireless, Wired, Bluetooth, etc.)
Physical device attacks
Physical inspection of the device is key to identifying the most logical physical attacks. After inspection, we conduct physical tests against the IoT device. Though these attack vectors may differ, they often follow common themes. Often, this testing will resemble the following actions:
- Compromise through available ports.
- Circumvention of device protections such as boot loader restrictions or restricted bios.
- Access to modify the configuration of the device.
- Access to storage to pull configuration keys used by the cloud component.
- Access to firmware that would otherwise be restricted.
- Access to the console or logs to isolate traffic destinations during communication with the cloud component.
Most IoT devices also use radio based communication (RF) methods. We focus our communication testing methods to identify security issues to help determine risk and impact. To accomplish this we conduct specialized testing and analyses of the radio-based communication to identify if the communication:
- Conforms to expected encryption techniques.
- The component pairing processes cannot be subverted.
- Allows unauthorized access or control.
- Can be easily used to map out the underlying command and control traffic
- Is vulnerable to replay attacks.
原文作者：Deral Heiland IoT – IoT Research Lead Rapid7 Nathan Sevier – Senior Consultant Rapid7 Chris Littlebury – Threat Assessment Manage Rapid7