How to Test the Security of IoT Smart Devices

Just when we thought we had our applications secured, they pull us back in.

No, this isn't a case of directory traversal bugs reappearing in IIS, access bugs resurfacing in Tomcat, or trained web developers deciding to abandon sound security principles. Instead, it is a result of up to 300,000 toasters, cameras, cars and other "smart devices" being added to the Internet every hour.

Learn IoT Security

Learn how ethical hackers exploit the growing number of internet-connected devices and become a Certified IoT Security Practitioner.

Get Started

Before you think this is a minor problem, consider this recent quote: "As part of a large-scale hack over a number of weeks, [Proofpoint found that] more than 750,000 malicious emails were sent from more than 100,000 everyday devices, including - astonishingly - a refrigerator." (CapGemini, October 2014)

WASP Internet of Things (IoT) Top 10 List

Fortunately, our security peers at the Open Web Application Security Project (OWASP) have noticed the problem too. Since their "OWASP Top Ten" list has become the most popular collection of potential risks to web applications, they decided to compose a similar list for the "Internet of Things" (IoT).

Released in June 2014, the OWASP IoT Top 10 list covers concepts familiar to application security experts, concepts familiar to network security experts and a few new items as well. The complete list for 2014 is provided below.

• I1 - Insecure Web Interface
• I2 - Insufficient Authentication/Authorization
• I3 - Insecure Network Services
• I4 - Lack of Transport Encryption
• I5 - Privacy Concerns
• I6 - Insecure Cloud Interface
• I7 - Insecure Mobile Interface
• I8 - Insufficient Security Configurability
• I9 - Insecure Software/Firmware
• I10 - Poor Physical Security

Staying with the idea that some items on this list will be new to you, whatever your security background, the rest of this article digs into every item on the OWASP IoT Top 10 list and offers practical guidance that you can use to evaluate the security of any IoT device.

Testing an IoT Device for Insecure Web Interface (OWASP I1)

The fact that your TV, toaster or baby monitor includes a web server is often a surprise. The fact that the web application it hosts was written by someone who missed the last ten years of application security developments is often an unpleasant one.

The most famous example of this to date is the case of the web application on TrendNet cameras that exposed a full video feed to anyone who accessed it. In this case, there was enough of a "sign on" interface to make end users believe that only authorized people could access the feeds remotely. However, a hacker group called Console Cowboys quickly demonstrated that the authentication mechanism was just for show. In the end, the United Stated Federal Communications Commissions (FCC) stepped in and required TrendNet to redesign their products and submit to an independent security assessment for 20 years.

On IoT devices, OWASP recommends looking specifically for default credentials that should be changed during initial setup, ensuring complex passwords are enforced, checking for cross-site scripting (XSS), SQL injection (SQLi) and cross-site request forgery (CSRF) vulnerabilities.

Fortunately, testing for these kinds of vulnerabilities on IoT devices will be second nature to many of you in the application security community. Tools such as OWASP's own Zed Attack Proxy (ZAP) and a number of commercial penetration testing packages (also called "dynamic application security testing" or "DAST") can also be used to look for these types of vulnerabilities.

Some unique challenges presented by IoT device web applications are that the apps are often on unusual ports (e.g., not 80 for HTTP or 443 for HTTPS), that the apps are sometimes disabled by default, and that different apps (e.g., for device administrators and users, or two different applications) may listen on different ports. To mitigate these challenges, you should plan on using a standard port scanner or (shudder) reading the manual to discover what web services a particular device offers.

Testing an IoT Device for Poor Authentication/Authorization (OWASP I2)

When security professionals like us, who are used to working in corporate environments, think of "weak authentication," we might think of passwords that aren't changed regularly, or 6-to-8 character passwords that are nonetheless easy to guess. Unfortunately, the bar is much lower with many smart devices.

Many IoT devices are secured with "Spaceballs quality" passwords like "1234", put their password checks in client-side Java code, send credentials without using HTTPS or other encrypted transports, or require no passwords at all.

An example of this revealed before my eyes at DEFCON 2014 was the simple password

(slide 67) on Zoll X series defibrillators, but there are many, many

Fortunately, you probably already know how to test for weak passwords by checking the initial installation, trying to set no or weak passwords, and using proxies and sniffers to look for passwords in the clear or weakly encoded with schemes such as BASE64. If you can get access to any storage on a device (as a USB-attached drive, for example), it is also a good idea to scan the available files for any passwords left in the clear at rest.

Testing an IoT Device for Insecure Network Services (OWASP I3)

In your modern corporate network, you may think Telnet and FTP are dead, but the IOT smart device world would disagree. Old and/or potentially insecure services like Telnet, FTP, Finger, TFTP, SMB and others are common on devices, especially if they were built on top of a Linux or Windows kernel that never underwent hardening.

Examples of these types of services abound in IoT documentation and are regularly lit up by security researchers. In August 2014, a sweep of more than 32,000 devices found "at least 2000 devices with hard-coded Telnet logins." A slightly more sophisticated example can be found in the October 2014 research that demonstrated more than a million deployed routers were vulnerable to misconfigured NAT-PMP services.

Fortunately, you probably already know how to use both port scan tools like Nmap and penetration testing tools like Nessus or OpenVAS to look for these types of dangerous services. You also already know how to track and block them with firewalls, but they may still pose a threat within your walls that can only be mitigated by locking them away in their own network.

Testing an IoT Device for Lack of Transport Encryption (OWASP I4)

When IoT devices fail to use transport encryption to protect the data and credentials they send, they put those items at risk the same way an insecure web application would. Since this type of vulnerability is familiar to any security researcher, we won't spend much time on it in this article, except to point out that insecure transport is a contributed component to most of the other types of vulnerabilities covered in the OWASP IoT Top 10.

Testing an IoT Device for Privacy Concerns (OWASP I5)

Home users may not understand computer security, but they do understand physical security ("is my door locked?") and privacy ("is that camera watching me?"). Furthermore, their fears are widespread. For example a Fortinet "Connected Home Survey" in June 2014 suggested that "69% of respondents were concerned that a connected appliance could result in data breach of sensitive information."

While the OWASP IoT Top Ten is a little light on its evaluation of IoT privacy from the perspective of a consumer (a gap that groups like IoT Security Labs are working on), it does cover three important points: ensure minimal data is collected, data is protected, and data is encrypted if possible. It also calls out three common examples of sensitive data: personal data (e.g., home address), financial data (e.g., credit card numbers) and health information. However, in its current state, OWASP's list should not be considered to be an exhaustive list of sensitive data, since information such as social security numbers, medical test scores, private images and other examples of sensitive information are not listed.

Examples of violations of privacy are unfortunately very common. Some are due to insecure devices, such as the TrendNet issues that let Peeping Toms into the bedrooms of thousands of unsuspecting people. However, other violations are due to unnecessarily expansive privacy policies, such as the TV that allegedly came with a "46-page" document which included the following phrase: "please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party."

In the case of specific classes of devices, such as medical devices, you may have the advantage of industry regulation. For example, the FDA has released guidance on securing wireless medical devices since at least October 2013. However, many classes of devices, such as cameras, can span many different types of use, so the privacy rules you need to follow can change radically depending on the purpose and location of the deployed device.

All this ambiguity means that determining the appropriate level of privacy a device needs to deliver is a decision that often involves people outside our traditional disciplines of application and network security. It might even involve your legal department.

Even after you determine the appropriate level of privacy needed from your devices, testing privacy compliance can still be a challenge. Your device's terms of use or explicit privacy policy may tell you exactly what a device will and will not record, how the information will be protected, and how it is used, but many devices omit this information. You may also need to determine whether or not a device actually performs these functions as advertised, for example by checking to see if a device's stated retention policy is actually enforced on its storage.

As a security professional, you should already have many of the skills to perform this kind of technical analysis, but you should also plan to spend additional time with IoT devices evaluating claims around secure storage, retention, and the parties who will get copies of data or statistics from the devices.

Testing an IoT Device for Insecure Cloud Interface (OWASP I6)

Many IoT devices exchange information with an external cloud interface or ask end users to connect to a remote web server to work with their information or devices. These web applications and web services can suffer from the same vulnerabilities that all other web applications can. In addition to obvious vulnerabilities such as a lack of HTTPS, the OWASP IoT Top Ten list asks you to look for authentication problems such as username harvesting (a.k.a. "user enumeration") and no lockouts after a number of brute-force guessing attempts.

Since most security professionals already know how to evaluate systems for these types of vulnerabilities, we won't spend much time on it in this article, except to remind you that you should get the permission of any remote cloud service before you attempt to perform any type of penetration test against it. (Fortunately some leading cloud services, such as Amazon, now provide well-documented procedures that let you perform your job.)

Testing an IoT Device for Insecure Mobile Interface (OWASP I7)

In addition to unexpected web, Telnet and other application-level services, people are often surprised to find that their IoT devices may also act as wireless access points (WAPs).

In my own office I was surprised one day to see one of the 48-inch smart TVs we use for teleconferencing appear in a list of available wireless access points. Apparently there was an onboard feature that allowed people to connect directly to the TV for advanced streaming functionality, but since it appeared in a secure business setting (and was already connected to the Internet as a wireless client for updates) it was a most unpleasant discovery.

The official OWASP advice for mobile interfaces is currently almost identical to its advice for cloud interfaces (I would expect this to change in future releases) and covers basic authentication issues like username harvesting, lockouts and appropriate levels of transport security (e.g., WPA2).

Unfortunately, this is an area where application security specialists are at a severe disadvantage to network security specialists. In addition to the items explicitly listed by application-centric OWASP, network security professionals would probably add eliminating unnecessary WAPs, turning off broadcasts of non-public SSIDs, disabling public wireless interfaces, considering the "two headed" ramifications of WAPs also connected to other networks, using strong wireless protocols to authenticate and secure traffic, and more.

Fortunately, the tools and procedures network security professionals already use to detect, test and deal with rogue WAPs apply equally well to IoT devices behaving like WAPs.

Testing an IoT Device for Insufficient Security Configurability (OWASP I8)

When OWASP talks about "security configurability" it is really talking about security features such as password policy enforcement, data encryption, and different levels of access. The good news is that most corporate environments now have an established security policy that tell you exactly what security controls your hardware and software need to have to be safely deployed in your environment. You probably also have the advantage of performing this type of analysis on dozens of things in your existing environment, usually from a remote interface.

Fortunately, all your experience evaluating hardware and software against the specific requirements of your security policy translates to performing the same kind evaluation against IoT devices. In some cases (such as a copier with a local flat-panel interface) you may also need to evaluate the available security features through a local user interface as well as any available web or other remote user interface. However, once you discover all the available interfaces on your devices, evaluating them against your security policy should be second nature.

If there is one additional aspect you need to be aware of when evaluating smart IoT devices is that they are often based on traditional operating systems such as Microsoft Windows or Linux which themselves have multiple levels of user access, including full administrator or root permissions. Known "privilege escalation" attacks against these operating systems should be attempted if they are ever found on a target device.

Testing an IoT Device for Insecure Software/Firmware (OWASP I9)

You already know why it is a bad idea for credentials and data to be sent across the wire in the clear: anyone who is listening can intercept your transmission. However, there are two additional threats posed to IoT devices that automatically download unencrypted and/or unsigned updates and configurations from HTTP-based sources.

The first problem is that the contents of updates could be changed or replaced before they get to automatically-updating devices. This has the effect of allowing any attacker to run any code that her or she wishes on the device, including backdoors or the data collection malware used in recent retail thefts at Target and Home Depot. The defenses against this are to cryptographically sign all updates, and to only use HTTPS (or other secure channels) where the identity of the providing server can be cryptographically established.

The second problem is that any sensitive data sent in updates, such as initial or hardcoded passwords or keys, can be read if not encrypted. Obviously, the defense against this is to encrypt updates whenever possible, both in transit and at rest.

Real life examples of corrupt update files abound, especially when people use "jailbroken" phones to disable the validation built in to their devices. Man-in-the-middle (MITM) attacks using insecure update sources, such as the HTTP-based update vulnerability that afflicted ASUS RT routers in October 2014, are also more common that you might think.

To test whether or not a device is using insecure updates, you generally need to use a proxy or sniffer to watch the data stream for use of secure transport. To examine the update itself, you can often use an attack proxy to divert the download or a simple URL (or utility) to download it to a desktop location for further inspection. For example, an online utility called "APK Downloader" lets you download and inspect Android installations and updates on any platform.

Testing an IoT Device for Poor Physical Security (OWASP I10)

OWASP asks security professionals to looks for at least five things when determining if a device's exposed ports can be used for malicious purposes. These are ease of storage media removal, encryption of stored data, physical protection of USB and similar ports, ease of disassembly and removal or disabling of unnecessary ports.

At DEFCON 2014 an extensive hack of an "Internet kiosk" was made possible through a tiny USB port left exposed near the floor in the back of the appliance. A related presentation called "Hack all the things: 20 devices in 45 minutes" also demonstrated how to break into many devices using externally-exposed USB ports, USB headers on circuit boards, simple serial-based "terminal headers" (e.g., "RX" and "TX") on circuit boards and bypasses of local storage components.

Some network security specialists may be familiar with some of the concepts required to examine devices for physical security, such as exposed interfaces, but many of the attack vectors here require training that has heretofore been reserved for (often, military or intelligence) professionals evaluating the security of hardened devices. Emerging concepts (at least in the commercial space) such as tamper-evident cases, sealed circuit boards and other technologies will likely be added to the list of things you are expected to know about when you evaluate IoT devices.

Conclusion

The rapid emergence of IoT devices will force you out of your comfort zone as a security professional. However, even as IoT security standards such as the OWASP IoT Top Ten evolve, you can take comfort in the fact that many of your skills as an application security or network security specialist will also be necessary to evaluate IoT security.

To help guide your IoT security education, a summary of the relative maturity of the OWASP IoT Top Ten items (in which "emerging" means "incomplete" or "likely to change significantly"), and the applicability of existing security skillsets is provided below.

Learn IoT Security

Learn how ethical hackers exploit the growing number of internet-connected devices and become a Certified IoT Security Practitioner.

Get Started