Download code from GitHub
Although the term IoT is known to have been coined in 1999 by MIT's Auto-ID Labs, embedded devices have been long-standing in technology for decades. The difference between new IoT and the embedded device world pertains to the legacy of design decisions and configurations that were never intended to be made public on the internet. Without manufacturing companies considering the consequences, widespread exploitation of IoT devices is now taking place, causing some of the world's biggest Distributed Denial of Service (DDoS) attacks ever recorded. We will cover various aspects of IoT pen testing and practical security guidance to provide preventative measures against the attacks we are currently seeing in the market.
To understand the origin of IoT you can visit this link:
http://autoid.mit.edu/iot_research_initiative
Note
Details on the aforementioned DDoS attacks can be found via the following link: https://www.us-cert.gov/ncas/alerts/TA16-288A
In this chapter, we will cover the following topics:
- Defining the IoT ecosystem and pen testing life cycle
- Firmware 101
- Web applications in IoT
- Mobile applications in IoT
- Device basics
- Introduction to IoT's wireless communications
- Setting up an IoT pen testing lab
The goal of this chapter is to set a foundation for IoT penetration testing, which will then be used in the subsequent chapters ahead.
This chapter focuses on the foundational knowledge that is required when performing an IoT penetration test. It provides basic concepts about the many attack surfaces within IoT and lays the groundwork to assist testers with jump-starting an IoT testing lab.
We will discuss the current state of IoT penetration testing and each area of possible attack surface to address how testing has advanced over the years. Then we will go over the basics of firmware security, web application security, mobile application security, hardware security, and radio communication.
Finally, we will walk you through how to set up the software tools and hardware tools required for testing.
Over the last few years, the spotlight has been on IoT devices due to the sheer amount being deployed, the conveniences they provide, their ease of use, and the potential security risks they pose in our society. With the IoT boom taking place before our eyes, we as a people are closer to a technology singularity. The dependence on IoT and the internet, which powers them raises concerns about safety, privacy, and security. Due to the spread of devices infiltrating all industry verticals, such as consumers, entertainment, commercial, medical, industrial, energy, and manufacturing, it has been proven that consumers, as well as commercial technology operators and owners, are unable to properly ensure the security of these devices. The reliance on device manufacturers to provide the proper assurance that devices are built with methodologies such as security-by-design is heavily dependent on the industry in which the device was made for.
Each industry vertical and region has its own respective regulations for testing devices. It is important to do your own due diligence prior to testing in order to ensure laws are not being broken. In some regions, such as the United States, security research for consumer devices is allowed and exempt from the Digital Millennium Copyright Act (DMCA), so long as the research is acting in good faith, is lawfully acquired, conducted in a controlled environment, and does not violate the Computer Fraud and Abuse Act (CFAA) of October 2016. This means security research for connected vehicles, cameras, various smart home devices, video game consoles, and jailbreaking mobile devices are now legal. After a long road of battles with the DMCA and the security community, this is a big win.
Now that such laws have passed, this is where we come in; we will go through assessing device firmware, web applications, mobile applications, hardware, and radio communications. First, we need to understand what the full scope of IoT is, including penetration testing approaches, and life cycles, to recognize all of its attack surfaces. Let's discuss the fundamentals of each IoT component in order to understand the attacks.
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.
Black box assessments are common and known to be performed for a relatively low cost. These types of assessments are performed with no prior knowledge of the technology or device implementations employed. More often than not, black box assessments are performed by security researchers or third-party consulting firms, but can also be conducted by internal security teams for risk assessment purposes.
Note
Note on responsible disclosureIf vulnerabilities are discovered through security research, it is important to follow disclosure policies as per the vendor's website. If the vendor does not have a disclosure policy, CERT can assist with disclosing the reported bugs appropriately. Details on CERT's vulnerability disclosure policy are located at http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm?.
White box assessments are when testers are given full access to source code, network diagrams, architecture diagrams, data flow diagrams, and various other pieces of detailed information on the technology employed by the target device. Generally, the more information on the target device or application(s) given to testers beforehand, the better the test results will be. White box assessments are more expensive but also ensure a more thorough review of a device's security controls and its implementation.
Grey box assessments are performed when testers have limited or partial knowledge that an insider of the organization is aware of. These assessments can consist of testers only knowing the application stack and libraries utilized, but not having detailed documentation on the API.
Note
For more information on the DMCA for security research, please visit the following link: https://www.ftc.gov/news-events/blogs/techftc/2016/10/dmca-security-research-exemption-consumer-devices.
