This failure to observe basic security best practice means a vast number of devices are susceptible to the same few attack vectors. These issues provide the attacker with that first foothold from where they are able to carry out further compromise, potentially gaining full control of the device, gather data or even using it to attack the user’s network.
So, what are the top ten fails that are threatening to derail the IoT?
1.Mobile apps
It’s often not the device but the mobile app it talks to that presents the single biggest threat. Decompiling the app allows the attacker to take advantage of issues such as a failure to implement SSL, either at all or incorrectly, allowing comms to be intercepted. For example, research into the Mitsubishi Outlander PHEV SUV mobile app provided access to the vehicle’s alarm, door entry, lighting and HVAC controls. Static credentials that see a password to the API put on the mobile app is another big no no, and we often find insecure storage of data on apps. Other issues include too many app permissions, enabling the attacker to masquerade as a legitimate connection.
2. API/web services
The mobile app interacts with a web service to send data to the vendor’s servers and that means the API is being published to the public internet. Vendors often assume that because it’s only intended to interface with the mobile app, the API is obscured. This isn’t the case and an attacker that reverse engineers the app will have direct access to the API and be able to interact with the web service. This can have severe repercussions. If the vendor has failed to put in place strong session management, users can view one another’s data.
Not implementing encryption properly is another common issue, as we saw recently with the Tapplock which had failed to implement AES 128 encryption properly. Injection attacks are another problem associated with web services which allow the attacker to potentially access all the customer data that service has access to.
3. Web apps
Some IoT devices allow the user to view their data via a web browser for ease of use such as in the case of fitness trackers. Web apps are notoriously flawed and this could again lead to customer data leakage, as seen in the Under Armour MyFitnessPal data breach.
4. Radio Frequency Communications
Standards such as Wi-Fi, Bluetooth, ZigBee and Z-Wave, if implemented insecurely, can expose customer data and the device itself to attack. Communications can be intercepted in a Man-in-the-Middle attack (MitM) or even hijacked and abused as we saw with children’s toys My Friend Cayla and the Teksta Toucan. Poor Bluetooth device pairing that uses default PINs is a common way to gain control of these devices.
The standards themselves can sometimes have issues. Recently we saw how the Z-Wave standard could see devices downgraded to an earlier version, allowing the attacker to exploit known vulnerabilities. Other issues include being able to use these location-based connections to track and locate user devices. For example, the wigle.net database can use Wi-Fi to track Wi-Fi devices.
5. Hardware
The hardware selected during device design contributes hugely to its security. Microcontrollers should be used that have embedded flash memory making it harder to recover firmware. However, there is a trade-off in that these have limited capacity compared to microprocessors with external flash and RAM.
Another common problem is for unnecessary functions to be left in place. Debug ports such as serial consoles, telnet and JTAG are key examples which should be physically removed from production devices or their fuses blown or disabled with software.
Additional security mechanisms can be put in place such as BGA (Ball Grid Array) packages which, when combined with good PCB design, can make it harder to tap into signals, while authentication mechanisms such as SAM modules, Atmel CryptoAuthentication or Maxi DeepCover devices can be used to store keys securely, although it is still necessary to consider key generation. Many embedded systems lack a good source of entropy making it difficult to generate sufficient randomness to issue keys securely.
6. Firmware
Again, the assumption is often made that no-one is going to look at the firmware, so it seldom gets encrypted and signed. This make it trivial for an attacker to reverse engineer and use the firmware to carry malicious updates into the device.
7. Infrastructure
Considering the impact on the wider network is essential whether the IoT device is deployed domestically or commercially. Security should at a minimum seek to ensure the implementation of least privilege, ensuring access is only awarded as needed, while password security should seek to eliminate the use of default, simple or re-used passwords, and the timely application of security updates and software patches should also be made mandatory.
8. Updates
IoT devices can start out secure but through the discovery of new issues become vulnerable or the addition of new functionality, such as an upgrade to the mobile app, can introduce vulnerabilities. It’s therefore vital to have an update mechanism in place in the event of new vulnerabilities becoming active. Typically, this will see support for over-the-air (OTA) updates, however, OTA can lead to complacency among developers who then assume any security issues can easily be fixed post-release. OTA can also become an issue in itself if not properly secured as it acts as a vehicle over which to propagate rogue or malicious updates.
| "Vendors are repeatedly failing to apply simple security best practise and are exposing their customers to attack." - Ken Munro |
9. Passwords
A failure to implement effective passwords is a major stumbling block for IoT devices. Default passwords may be left in place, or it may be hard for the user to change them, making the device vulnerable from the moment it is activated. It’s rare that we see the use of two-factor authentication on IoT products which seems crazy when it is so easy to put in place.
10. Customer data
Poor storage of customer data can also result in compromise. Even if the vendor has implemented database encryption the data is unlikely to be encrypted when in transit. It also pays to consider your service provider and how your cloud service is configured. As we saw recently in the case of the Swann security camera and FLIR camera made by Lorex Technology, one compromise can affect multiple vendors. In that particular instance, a vulnerability concerning weak authorisation at the cloud provider, Ozvision, saw users able to view one another’s camera feeds.
These ten examples illustrate how vendors are repeatedly failing to apply simple security best practice and are continuously exposing their customers to attack.
As we move into an ever more connected version of the IoT, away from isolated smart gadgets towards home hubs and smart services, the question becomes whether the current approaches taken by vendors will be fit for purpose.
Sadly, I suspect we are walking blind into a future of systemic failures where our personal data will perpetually be at risk.
| Author details: Ken Munro is a Partner at Pen Test Partners |
