Penetration testing was much like taking a battering ram to the door of the fortress. Keep pounding away and maybe find a secret backdoor to enter through. But what happens if pieces of the network are outside of the fortress? With the flurry of Internet of Things devices, is it harder to conduct a pen test with that many devices and end points?
Claud Xiao, principal security researcher, Unit 42 at Palo Alto Networks, said for just testing some network services on IoT devices in a black box way, the difficulty level and the steps are similar with regular pen testing. But if you're discovering vulnerabilities via analyzing firmware or via analyzing wireless communications (e.g., Bluetooth or ZigBee), that's much harder.
“Every step above may fail due to diversity existing everywhere during IoT devices' and embedded Linux system's design and implementation. Even if a security flaw was discovered, some additional knowledge may be required in order to write a workable exploit code,” Xiao said.
The benefits to pen testing Iot include strengthening device security, protecting against unauthorized usage, avoiding Elevation of Privileges, Lowerreducing the risk of compromise, better user and data privacy, and settrong Encryptionencryption to avoid man-in-the-middle (MTM) attacks.
Don Green, mobile security manager of Threat Research Center at WhiteHat Security, also agrees that IoT assessments are inherently more complicated because there is more hardware, software, and communication protocols involved. “This translates into a larger attack surface and a wider array of attack vectors. A successful IoT assessment requires that the electronic ecosystem for a specific IoT device is thoroughly mapped and a detailed assessment plan is developed,” he said.
While the IoT has not introduced new technology per se, he said it has introduced a more complicated environment for developers and security teams. Understanding the complexities of the environment, adequate research of components, and development of a thorough assessment plan are the keys to success for securing the IoT.
Daniel Regalado, principal security engineer at ZingBox, said when you focus on IoT the challenges are different and harder. “You are dealing with different architectures, operating systems, communication protocols, etc. This is totally different than what the Penetration Tester faces with traditional networks.”
Most attacks start by luring the end user to open an email or click a malicious link, within the world of IoT it is different. There is no end-user behind those devices. Therefore, there is no person to lure, making it more challenging to break into embedded devices (low-hanging fruits like default credentials or plain text login protocols, like telnet, are not considered as challenges and therefore out of scope during Penetration Testing), he said.
The main difference between traditional and non-traditional penetration testing is the diversity in IoT. With traditional testing, the penetration tester is usually confronted with Windows or Linux x86/x64-bits systems, known TCP/UDP protocols and applications. But, when you switch to IoT, you have new architectures that are uncommon for most penetration testers (ARM, MIPS, SuperH, PowerPC, etc.).
Different communication protocols like ZigBee, SDR (Software Defined Radio), BLE (Bluetooth Low Energy), NFC (Near Field Communication), that requires new expertise and tools to test them. Regalado said dealing with Real-Time Operating Systems (which are very common in infusion pumps) may require the penetration tester to create new tools from scratch to support this kind of technology. Traditional penetration testers can get completely lost in the vulnerabilities of embedded devices and these protocols.
Dean Weber, CTO, Mocana, said IoT pen testing is a knowledge-based approach with homegrown and commercial tools mixed together to accomplish an objective -- but that is only at the device level. “Going up a layer, it's IoT systems that are at risk, based on individual vulnerabilities,” he said.
Today, most IoT/IIoT penetration testers have either migrated from network penetration testing, or have been involved with industrial testing and are adding penetration testing to their portfolio. “This will not last forever, and you will then see things like nmap for industrial protocols in the hands of everyone, while a definitive suite like Metasploit will include a well-rounded device and protocol library that can then be set as a baseline for platforms and network in the IoT/IIoT spaces.”
Spirent described what’s an IoT environment consists of in order to appropriately assess the attack surface. An IoT environment mostly consists of includes the following components:
- Network: An IoT environment runs on and is updated over a network, such as the Internet, BLE, 4G, LTE, Zigbee, LoRA, WiFi, MQTT, 802.11.15.4, etcor others.
- Applications: IoT applications manage device- Web App, Mobile App,, and they can be web apps, mobile apps, or APIs (SOAP, REST)).
- Firmware: This is the device’s software and operating system.
- Encryption-: Encryption protects communications and data stored on the device.
- Hardware: This is the IoT device hardware (Chip, such as a chip set, Storagestorage, JTAG, UART ports, Sensors, Camera etc.) port, sensor, camera, or other device.
“With five levels of functionality required to operate an IoT solution, you can see the vast threat surface. That’s why penetration testing for an IoT device should encompass network, applications, firmware, encryption analysis, and hardware pen-testing. A single pen-test will not be sufficient,” said Sameer Dixit, senior director of Spirent Security Labs at Spirent Communications.
Pen-testing in the IoT era requires greater knowledge of non-traditional devices operating systems, communications and protocols - connected TVs, cameras, smart buildings and other assets are unlike PCs and servers, said Mike Spanbauer, vice president of strategy for NSS Labs. The skills and experience of how data paths work can be leveraged between compute platforms and IoT, however the priority on OT vs. IT and that uptime rules all (at least in industrial and business IoT) changes the mindset, and approach required to design and assess the weaknesses of the system.
“Companies should avoid ‘over-correcting’ in pen tests to hyper focus on just IoT devices. Bear in mind that a lot of these devices are actually compromised by weaknesses in things like their accompanying cloud accounts, management consoles and other aspects of the ‘regular’ attack surface of PCs, apps and servers,” he said.
Those who look to investigate IoT vulnerabilities will be quite skilled in the established pen space as well due to many of these devices possessing Windows or Linux monitoring or management apps that must be thoroughly pen tested too.
“The concept of discrete element is difficult to pin down in IoT due to very nature of distributing the monitoring and compute elements,” he said.
The main challenge with any pen-test exercise is that it yields a point-in-time look at vulnerabilities, and the reality is that IT environments are constantly changing - *particularly* due to IoT, Spanbauer said. Organizations must prepare for and adopt a continuous validation model, where key services and devices are monitored for behavioral anomalies in addition to vulnerability scanning, protocol inspection, and more.
“There is no substitute for context based intelligence, which only comes from knowing your environment and continually monitoring and validating it,” he said.
Deral Heiland, research lead at Rapid7, said what can make pen testing IoT more problematic is when IoT components are approached separately. If tested separately, a tester does not take into consideration the interaction of the component within the products ecosystem. This can lead to critical security issues being overlooked. To avoid this, a fully functioning IoT product ecosystem must be set up and operationally tested to map out all interaction between the parts.
Praetorian CEO Nathan Sportsman said when it comes to the security of embedded devices (“Internet of Things”), many companies have a tendency to rely on the assurances given to them by the OEMs. If they conduct their own review, it is typically limited in scope, and often consists of a limited security assessment and vulnerability scan.
What are the steps?
Larry Trowell, associate principal consultant at Synopsys Software Integrity Group, said in order to test IoT devices you have to have a good mix of skills from every other security testing practice, plus a few unique to embedded devices:
- A tester has to be good at network security to determine what protocols are being used and what information may be at risk.
- A tester has to be good at normal web tests, to see if there are any weaknesses with any web based configuration interface on the device.
- A tester has to be good at embedded engineering, and usi.ng engineering tools to find and back door testing interfaces
- A tester has to be good at testing obscure OS instances. While a large number of these devices will run some variation of Linux, there are many running QNX, VXworks, Windows embedded, and sometimes custom one-off operating systems.
- A tester has to be good at reverse engineering and decompiling applications from extracted firmware. Some devices, will not have an OS and will run straight on the metal. For these tests the tester will have to fully reverse engineer the application to determine if it’s vulnerable to attack.
IoT solution pen-testing involves testing the network, API, and applications. This can be done remotely if the IoT environment is accessible over internet or a wireless network. For hardware, encryption, and Wi-Fi pen-testing, the device is connected in a lab and analyzed for logical and physical security weaknesses, said Dixit.
You may need to deconstruct the device, identify its hardware debugging interfaces or storage chips, dump the firmware via some different hardware hacking techniques, said Xiao. Then you need to analyze the firmware and extract internal executables and configurations from it. Last you'll reverse the executable files and discover security flaws in them.
Green describes the process in a micro and macro level. Mapping happens at a macro and then a micro level, he said. From the macro perspective, the mapping needs the breadth to encompass all the devices and components that participate in the functionality of this ecosystem.” This means everything. All devices, all communications, and all software components,” he said.
At the micro level, one must understand the depth of each component and the potential weaknesses. What kind of hardware, what kind of firmware, what kind of communications, what software language, what third party add-ons? This requires significant research to understand weaknesses of individual components and weaknesses in the interaction of components, he said.
“Armed with this comprehensive map, the assessor has a blueprint to develop an assessment plan and chose the appropriate tools from their hacker tool box. At this point, the tester has completed the required heavy lifting. They understand the IoT device, the landscape in which it functions, and have developed a comprehensive assessment plan which includes the specific tools for the job. Now the fun part begins. Execute your assessment plan and hack that device!,” Green said.
Regalado said first, define the scope. Second, identify the type of devices you are targeting. Penetration testing in IoT involves black-box and white-box testing. Within black-box testing, the hacker has no knowledge of the company’s network. He is acting as a real hacker. The black-box tester is simply given the company name and told to “go for it.” The black-box tester must find the IT assets and start attacking them.
Within white-box testing, a company gives more information to the penetration tester such as, credentials to access systems, source code of applications, access to the local network etc., with the purpose to thoroughly assess every single path within its network.
Within black-box testing, any vulnerability a penetration tester finds will be like a real-world hack. In other words, if the penetration tester can break into the local network via a company’s web site, it is very likely a real hacker will be able to do the same, if it has not already been done.
Ragalado said most important, some companies believe they are safe simply through a black box test. However, it is key to remember that a white-box approach will help to understand what an attacker is able to.
Dixit said apps and networks that are scanned and pen-tested regularly, and the same security habits should be followed for IoT solutions, because they are a conglomerate of app, network, and hardware. Minimally, IoT solutions should be tested with every new update/ or release in order to assess the impact of the new release on device and to test for new vulnerabilities that might appeared since the last scan or pen-test.
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 CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.