IoT has already proven to be quite the attractive target for malicious attacks. Unfortunately, while most industry experts understand how risky a vulnerability in IoT related code can be (or are at least talking about it), the security tech and research worlds are still trying to catch up with the speed in which IoT software and devices are evolving and how fast the market is to adopt them.
Just this month we discussed the troubling state of IoT security, based on the alarming results of a study that surveyed IT and IT security professionals about their organization’s security practices during the development lifecycle of IoT applications.
As security experts continue to predict the fallout that can be caused by an attack on IoT code, platforms and devices, a new vulnerability was discovered last week.
Meet Devil’s Ivy, otherwise known as CVE-2017-9765: a stack-based buffer overflow vulnerability that could enable cyber attackers to remotely access a video feed, or deny authorized users access to the feed.
The flaw was discovered by IoT security startup Senrio, and described in their blog: researchers were analyzing the remote configuration services of Axis Communication’s IoT M3004 dome camera, and discovered the stack overflow bug, which occurs when sending a large XML file to a vulnerable system's web server.
Axis Communications is one of the world’s largest security camera manufacturers, and the bug that the Senrio team found affects 249 of their different camera models. Considering that the cameras are used for security and positioned in places like banks and airports, an attack on the video feed could be both extremely lucrative for a hacker and dangerous for the institutions that use the cameras – not to mention their customers: the possible fallout is scary – ranging from sensitive information being stolen, or a robbery being enabled.
But wait – there’s more: it appears this is only the tip of the vine. According to Senrio researchers, who also provided a technical breakdown, the vulnerability was found in the product’s communication layer, in an open source third-party code library called gSOAP managed by Genivia: a web services toolkit used as part of a software stack to enable devices of all kinds to talk to the internet.
Senrio researchers named Devil’s Ivy after the plant: for its ability to spread quickly through code reuse and the fact that it’s nearly impossible to kill – and spread quickly it can. According to Genivia, their gSOAP communications library has had over a million downloads, and services many corporations aside from Axis – including Microsoft, IBM, Adobe and Xerox.
The Senrio team also reported that Axis is a member of the ONVIF Forum, an unofficial international consortium of hardware vendors that includes thousands of companies and is responsible for maintaining software and networking protocols used by members, covering a wide range of physical security products. The members of the forum rely on SOAP to support the ONVIF specifications. Approximately 6% of the forum members use gSOAP.
Considering these numbers, Senrio researchers estimate that tens of millions of products, including software products and connected devices, are affected by Devil’s Ivy to some degree. Though the reach of the exploitation is difficult to qualify, researchers say that any software or device manufacturer that incorporates gSOAP in their products could be at risk: “Based on our research, servers are more likely to be exploited. But clients can be vulnerable as well, if they receive a SOAP message from a malicious server.”
While Senrio report that Axis addressed the issue swiftly: fixing the vulnerability, releasing patched firmware, notifying Genivia – who also published a patch, and confirming with ONVIF that all forum members are aware of the issue; Devil’s Ivy is out there. This means a countless amount of connected surveillance tools, IoT devices and servers are at risk.
Senrio’s recommendations following their discovery of the vulnerability include:
1. Keeping security devices off the public internet;
2. Placing defense mechanisms like a firewall or utilizing Network Address Translation (NAT) for IoT devices, and
3. Updating software for patches as frequently as required.
While these security practices are imperative, they still don’t guarantee complete safety, and most of them include the human factor – which is always a risky component. When integrating open source software, it’s important to create and comply by the security policies and processes required when working with open source components, in addition to implementing traditional network and cybersecurity practices.
Open Source has always been a great match for IoT solutions. It offers developers an easy mix and match option for practically every IoT development framework and component, hardware, software or operating system. It’s easily scalable, and it offers great solutions for IoT connectivity.
As long as developers continue to rely substantially on open source components to create IoT software and devices that will keep them on top of the market, they need to put open source security management practices in place to ensure re-using the next un-patched Devil’s Ivy. As Dustin Childs, communications manager at Trend Micro, told LinuxInsider: “misunderstood or poorly implemented open source software allows attackers a path to bypass security mechanisms.”
In a reality where being first to market is a priority, and the Software Development Life Cycle (SLDC) can’t suffer bottlenecks or delays – even when they are for enhanced security, an automated tool that runs throughout the SLDC, tracking, detecting and remediating open source vulnerabilities could save organizations from unknowingly opening themselves and their customers to security risks.