How to conduct an IoT pen test

Security experts explain the nuances

1 2 Page 2
Page 2 of 2

Rapid 7’s approach includes assuring that the tester is skilled in assessing all of the various components (Hardware, Mobile, Cloud API, Network). Second, by properly scoping the time needed to conduct a thorough test, and finally by following a solid testing methodology. The mythology Rapid7 focuses on the following approach and structure and has proven to be very effective:

  • Functional evaluation
  • Device reconnaissance
  • Cloud focused testing
  • Mobile application/control system-focused testing
  • Network-focused testing
  • Physical inspection
  • Physical device attacks
  • Radio-focused testing

Other issues

Trowell said the firmware for these devices often comes preloaded, with no method of updating or configuring the devices past simple interfaces, in order to extract the firmware to confirm the security of the devices. While occasionally the testers will get lucky and find some intact debug port, or unsecured memory access, many times they will not. Many times they will have to carefully remove epoxy blobs or reactivate blown circuits by means of carefully timed power fluctuations called glitches.

“While these challenges can be seen as physical security features, they do not greatly increase the security of the device. They merely facilitate the belief of security via obscurity as a valid stratagem in IoT. As we’ve seen from the recent attacks and botnets via IoT devices, this strategy is not valid,” he said.

Hardware also needs to be considered. Unlike a normal web assessment, a tester must consider the chips that make up the device in the security assessment. An IoT tester must also determine if the chips have any known weaknesses, such as debug ports that can’t be disabled or weaknesses to timing or voltage attacks? Is sensitive information discoverable that is common to multiple devices, like encryption keys? Where are the encryption keys stored on the board? Will the tester need to desolder a memory chip to extract the data or is there a testing port that allows access? Is the storage device encrypted? 

“Everyone wanted ‘Smart’ devices, and little thought was paid to what happens when they go bad. These devices were made cheap and quickly to market on the information bubble that was forming. Most of the current IoT devices were not developed with security in mind,” Trowell said. “An upsettingly large number of these devices come preloaded with default passwords that may not be changeable, firmware that cannot be updated or patched, or worse send unspecified data out over the network to unknown locations.”

Sportsman laid out a six-phase approach to IoT pen testing:

Phase One - Hardware Analysis

The security team should begin its analysis by evaluating physical and hardware controls to see if these are sufficient to prevent an attacker from tampering with the platform’s components and their normal execution flow.

Each underlying component must be examined for reverse engineering and subversion capabilities. For instance, remnant JTAG, SWD and USB interfaces that provide a “way in” are often useful for interacting with the underlying hardware. Techniques to circumvent hardware modules that enforce trust and protect sensitive data are of particular interest.

Phase Two - Firmware & OS Analysis

It’s important to ascertain if hardware and chip makers have fully implemented security best practices within the firmware and operating system.

To do this, the team will test the built-in security of the device firmware and its update distribution process, such as cryptographically signing firmware updates and using authentication capabilities in hardware devices to verify signatures. At the OS level, the team should examine software boot sequences, code execution, application core dumps and data confidentiality protections. As part of this analysis, security engineers will also need to examine memory to ensure sensitive data is properly erased by the application.

Phase Three - Wireless Protocol Analysis

A wireless configuration review should be conducted to validate the security and configuration of wireless communication protocols used for local device communication, such as ZigBee, 6LoWPAN and Bluetooth LE.

The security review begins by identifying device roles, cryptographic primitives, encryption keys, authentication and other algorithms related to security. After taking inventory of various security components, run an analysis of common attacks like man-in-the-middle, replay, unauthorized network commissioning and then (if applicable) fuzz test the protocol stack.

Phase Four - Mobile applications

If a mobile component is in scope, as is typically the case with IoT platforms, the security team will need to test several key elements: storage-level and transport-level data protection controls, authentication and authorization, session management and data validation.

Here’s what the team will look for with each of these:

    •       Storage level data - Proper use of native APIs for features like key stores; avoiding insecure storage of dangerous client artifacts (ex: user credentials, personal information or other sensitive application data); and properly erasing sensitive data.

    •       Transport level data - Vulnerabilities related to information disclosure, tampering and spoofing in the traffic between the mobile app and any remote systems.

    •       Authentication/authorization - Implemented authentication protocols, certificate validation, password policy enforcement and account lockout mechanisms. It should also examine data access controls, segregation (and principle of least privilege), confused deputy attacks and the accessibility of hidden functionalities.

    •       Session management - Resiliency of persistent sockets when faced with a severed connection. The entropy, length, timeout and rotation of session identifiers to see if they are susceptible to preset identifiers, brute force, session fixation, etc.

    •       Data validation - Any open ports, interfaces, IPC channels or other input modes that can be leveraged by an attacker or malicious application. Exposed interfaces should be fuzz tested to see how they handle erroneous input via filtering, sanitation and validation. Key vulnerabilities in scope: XSS, SQLi, command injection, mishandled exceptions and memory corruption attacks (RCE or DoS).

Phase Five - Web applications

Web application testing begins with the network and operating system to make sure the underlying platforms are securely configured.

Next, the team will move on to the web application layer - this requires significant attention and will comprise the majority of the engagement. For this part of the pen-test, it’s important to play multiple roles: first, as an attacker without valid credentials to the web application, and, secondly, as users who have valid credentials. In the latter instance, the testing should be conducted across all user roles in order to fully examine the app’s complicated authorization controls. This should test a user’s ability to access another user’s information within the same role, as well as a user’s ability to access another user’s information at a higher role (vertical privilege escalation).

Phase Six - Cloud services and infrastructure

All back-end platforms used to exchange data with IoT networks, applications, devices and sensors should be tested to see if an attacker is able to gain unauthorized access or retrieve sensitive information. These include any external cloud services (Amazon EC2, Google CE, Azure VM) or APIs.

Use network diagrams, documentation and cloud management console access to evaluate the security of the platform’s cloud deployment. Assess the security architecture and deployment by examining the following major components: key security architecture design assumptions, current network topology, inventory of existing security technologies, security policies, guidelines, and procedures, instance group policies, network access controls, and network segmentation, remote access and virtual private networks, authentication controls including two-factor authentication and single sign-on, datastore encryption and key management, containerization technologies such as Docker and Rocket, and logging and monitoring deployments.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2017 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
SD-WAN buyers guide: Key questions to ask vendors (and yourself)