CIA exploits of IoT devices, What lessons can we learn?
Recent WikiLeak documents allege that the CIA developed, or sought to develop, or even ‘borrowed,’ cyberattack technology that could target a wide range of IoT devices, including smart TVs, connected cars and mobile phones. In the case of smart TVs and mobile phones, the attacks allowed these devices to be used to eavesdrop on either voice communication, data communication or both.
The concepts of using connected devices for gathering intelligence or perpetrating malicious acts is certainly not new, but the scope of activities reported in the WikiLeak documents is startling to some. However, as someone working on security for IoT devices I didn’t find this particularly surprising. I certainly don’t have any inside information on the activities of the CIA or other government agencies, but have seen companies make the same mistakes over and over again in building their IoT devices.
Why IoT devices are targets
All too often, companies building connected devices either ignore security completely, try to bolt it on late in the development cycle, or treat it as a ‘nice to have’ feature. The companies viewing security as a critical feature and taking a comprehensive approach to securing their devices and networks are in the minority.
It is not surprising an organization with the resources of the CIA could develop effective cyberattacks against a wide range of IoT devices. All too often devices contain easily exploited vulnerabilities that don’t require sophisticated cyber-attacks. In many cases the devices have back-doors for remote access by service technicians, weak authentication methods, or default passwords that are never changed. It doesn’t take a nation-state attack to exploit these vulnerabilities.
Even devices including basic cyber-security defenses often fall short. They may provide a level of protection by encrypting network traffic or harden the device using code signing for trusted boot or provide other defenses against cyber-attacks. In many cases however, these measures don’t go far enough. Each device is different, but many fail to provide security on all the device’s interfaces, leaving something open to attack. For example, a number of IoT devices have implemented SSH to provide secure communication, but have used an identical shared key for an entire product line. If that shared key is then compromised, all devices using that key are vulnerable.
Lessons from WikiLeaks
The glaringly obvious conclusion is that security can no longer be viewed as a ‘nice to have’. It is critical to address security during the earliest design stage of a device. While creating a ‘completely secure device’ is a huge challenge, it is important to set the bar as high as possible. And even if it is not practical to implement a full security roadmap in your next product release, it is important to get started. If you can create a base of security in your device, you can build upon it in subsequent releases.
Adding secure remote update capability, intrusion detection, and security management are critical features and a great starting point. These features allow detection of attempted cyber-attacks against your devices, receiving notifications of those attacks, and to take action to mitigate attacks. The Miria botnet was extremely effective, in part because there were no automated methods to patch the vulnerability. Remote software update capabilities solve the problem.
I’m often asked by industry insiders if they should be worried about the CIA hacking their device and eavesdropping on their conversations. While that might be a concern for some, the bigger fear is with so many vulnerable IoT devices, a malicious cyber-attack could potentially impact critical services either in the US or abroad. That scenario played out in 2015 when the Ukrainian power grid was hacked, causing power to be lost in a third of the country.
The only way to stop these attacks is to begin taking security seriously. Regardless of the device or application, it is critical to build in security from the beginning.