Application Security Testing: An Integral Part of DevOps
The Internet of Things (IoT) and the level of interconnectedness it can provide opens up the door for many new applications and a new level of functionality within the devices we use in our daily lives. Yet, an ever increasing number of networked appliances, and applications that interact with them, also results in a rapidly increasing attack surface that black hats can use to compromise devices and gain a foothold in home and corporate networks.
To help minimize the growth of this attack surface, it is critical that developers of IoT devices, and the applications that run on them, make security a top priority and there is no better illustration of this than the recent DDoS attack on the DNS provider Dyn. The attack on Dyn resulted in widespread outages for several large Web sites on the East Coast of the United States and the attack is largely attributed to the Mirai botnet.
The Mirai malware is also responsible for the DDoS on the Kreb's on Security news site, where it generated a DDoS attack that created over 600 Gbps of network traffic. What makes this attack so scary, however, is not the level of sophistication of the malware itself, but actually its lack of sophistication in how it gains control of IoT devices. The source code for the Mirai malware was released and its mechanism for gaining control of IoT devices is very straightforward. It has a list of just over 60 username and default password pairs and hunts out devices for which these credentials have not been changed.
Many of the devices it targets use insecure protocols, such as telnet, for establishing remote connectivity. Estimates by the AV vendor Sophos estimate that these 60 passwords are enough to easily compromise hundreds of thousands of public-facing IoT devices. Moreover, Mirai is not the only the IoT-based malware to take control of devices using default credentials and insecure protocols, as the malware behind the Bashlight botnet has been shown to make use of similar techniques.
Although consumers can take measures to mitigate such threats by ensuring that default credentials are changed and by configuring firewalls to restrict network connectivity, that does not mean that the security of the IoT devices themselves cannot be improved upon. Network Administrators looking to check their environments for IoT devices with default credentials can consider using a tool such as IoT Crusher to identify such devices for remediation, but it would be far better if device manufacturers took steps to ensure that default credentials did not end up on installed devices in the first place. In that vein of thought, this article will be discussing some techniques that IoT device developers should consider implementing to help protect their devices against threats such as Mirai.
10 Must-have IoT Application Security Controls
Because the space constraints of a single article prevent a comprehensive discussion of all possible IoT security controls, this discussion will center around vulnerabilities listed in the OWASP Top IoT Vulnerability list because many of the vulnerabilities on this list are also the vulnerabilities exploited by Mirai and Bashlight. This top 10 vulnerability list will be used to create a list of 10 security controls that any developer involved in the development of IoT software or firmware should be implementing.
|Vulnerability Rank||Vulnerability Name|
|1||Insecure Web Interface|
|3||Insecure Network Services|
|4||Lack of Transport Encryption/Integrity Verification|
|6||Insecure Cloud Interface|
|7||Insecure Mobile Interface|
|8||Insufficient Security Configurability|
|10||Poor Physical Security|
Table 1: OWASP Top IoT Vulnerabilities
A quick look at Table 1 shows us that, of the top 10 vulnerabilities listed, three of the vulnerability types deal with insecure interfaces. Whether we are dealing with Web, cloud, or mobile interfaces, these types of vulnerabilities are largely centered on having easy-to-guess credentials that can be used by an attacker to gain access to the device. Moreover, as the insufficient authentication\authorization vulnerability type indicates, devices that allow the use of simple passwords and the transmission of passwords in clear text are also prominent, which can work to further compound the issues seen with insecure interfaces.
Insecure network services includes devices that expose unnecessary ports and have vulnerable services listening on those ports. Vulnerabilities concerning lack of transport encryption mainly involve the use of insecure protocols such as HTTP instead of HTTPS, which makes transmitted data much easier to harvest. Privacy concerns deal with IoT devices collecting more data than needed to fulfill their functions and other factors that can potentially lead to the exposure of personally identifying information (PII). Insufficient security configurability deals with users having a lack of options with regards to setting up security features, such as selecting password complexity filter parameters or being to grant different access levels to different accounts. Insecure software/firmware deals with the inevitable vulnerabilities that will be found in an IoT device and the in place mechanisms for updating them.
Lastly, physical security vulnerabilities deal with whether or not data at rest is encrypted and whether or not USB and similar ports are accessible and can be used to attack an in-hand device. These vulnerabilities lead us to the need for implementing the following security controls.
- No default passwords or hardcoded passwords post initial setup: Ideally, devices should not be allowed to go online until after setup is complete and a unique user-generated password is put into place. This helps ensure the security of the device by avoiding compromise due to users not being able to change passwords or forgetting to. For example, many Sierra Wireless devices fell victim to Mirai, because even though they supported custom credentials, many users never bothered to change the defaults. Credential changes should be mandatory at the time of setup to prevent these types of issues.
- Account Lockouts after 3-5 failed logins: Changing your password is critical, but provides little security if attackers can easily conduct a dictionary attack, brute force attack, or some other credential guessing scheme against the device. After 3-5 failed login attempts, further login attempts should be prevented for a period of at least 30 minutes, because such lockouts will dramatically increase the time required to conduct such attacks.
- Password complexity filters: Having a custom password is a good thing, and properly configured lockouts can help to really boost the security of interfaces against password attacks, but all the security in the world is not going to keep a device safe if a user is allowed to choose 1234 for their password of choice. Password complexity filters help ensure that passwords meet a required length and use a variety of character types.
- No unsecured connections: All connections should be required to use a secure protocol, such as SSH, in place of telnet, or HTTPS in place of HTTP. This will make it more difficult for passwords and session information to be captured and used to attack or compromise an IoT device. Moreover, secure connections also help to ensure that the privacy of data is maintained because it will make the viewing of transported data significantly more difficult.
- No administrative access on internet facing interfaces: Internet-enabled access to device administrative functions should be opt-in only. Devices should be configured to allow only local administrative access to the device or administrative access from the local network.
- Network level access controls: The device should have the ability to turn off network-enabled features that are not currently in use and should have the ability to restrict communication to a user-defined list of IP addresses. This is especially important when devices are targeted towards the home user market where the budget and/or knowledge may not exist to properly deploy an IoT device behind a firewall.
- Update Mechanisms: Vulnerabilities are inevitable because bugs will be found in pretty much any non-trivial application, no matter how carefully crafted. IoT vendors need to be sure that there are mechanisms in place for their devices and/or applications to check for updates, ensure the integrity of updates, and to apply those updates.
- Encryption at rest: IoT devices should ensure that passwords and all data that could be considered sensitive, like PII, is stored in an encrypted format. Potential attackers should not be able to remove an SD card from a device, pop it into a reader, and suddenly have the stored password used to access the device.
- Differing Account Access Levels: Devices should have the ability to be set up with user-level accounts as well as administrative accounts and these accounts assigned to different interfaces. This allows for further segregation between the accounts used for device administration and for Internet-based access to the device.
- Privacy by Design Principles: Not really an individual security control, but following privacy by design principles will help ensure that privacy is integrated into the device from day 1 and that the device will not further expose users to the risk of identity theft. More comprehensive coverage of Privacy by Design can be found here.
Although far from a comprehensive list of the controls that should be implemented to protect IoT devices from compromise, the preceding 10 are controls that will greatly help mitigate some of the most commonly observed IoT vulnerabilities and are especially relevant given the recent rise of the Mirai and Bashlight malware strains. When developing IoT device software, keep in mind that security needs to be incorporated into the device from day 1 because application security cannot be bolted on later. Use this article as a base to begin thinking about what kinds of vulnerabilities are commonly exploited and what can be done to mitigate these risks.