Posted by Robert Vamosi on July 19, 2017
A vulnerability in a single software component, found in an internet-connected security camera, may leave thousands of different security camera models (and other Internet of Things devices) at risk. But Devil’s Ivy and other such flaws can be avoided with effective software supply chain management.
On Tuesday, IoT researchers at Senrio disclosed a hackable flaw they’re calling Devil’s Ivy. Officially known as CVE-2017-9765, the vulnerability is a stack buffer overflow that, if successfully exploited, could lead to remote code execution. Given the prevalence of the vulnerable components within the IoT software supply chain, various unpatched security camera models and other IoT devices may be at risk.
“Pervasive vulnerabilities in third-party libraries are a well-understood problem that also highlights something that we, as a community of both security experts and software engineers, need to work together to resolve,” said Chris Schmidt, senior manager, research security technology and applied research at Synopsys. “Software will continue to depend more and more on code reuse and third-party libraries and frameworks.”
The flaw resides in gSOAP, a simple object access protocol from Genivia. At least 34 companies use gSOAP as a toolkit, according to the vendor. Genivia claims more than 1 million downloads of gSOAP to date.
In the Synopsys State of Software Composition 2017 report, based on analysis of 128,782 software applications uploaded and tested through the Black Duck Binary Analysis cloud service from Jan. 1 through Dec. 31, 2016, of the 16,868 unique software components and versions identified, there were 713 observed instances of gSOAP. That places it in the top 4% of all components and versions observed.
Senrio said it found the vulnerability while researching an Axis Communications security camera, specifically the M3004 model. Senrio since learned that Devil’s Ivy is present in 249 of the Axis Communications camera models.
“We made this discovery in a single camera, but the code is used in a wide range of physical security products,” Senrio chief operations officer Michael Tanji told Wired.com. “Anyone who uses one of the devices is going to be affected in one way or another.”
Axis has since patched the firmware and is now prompting partners and customers to upgrade to gSOAP version 2.8.49, released July 11, 2017.
Senrio also offers a video demonstrating the exploit:
Last September and October, a flaw in a different security camera allowed for a botnet, known as Mirai, to take hold. Botnets by themselves are common annoyances on the internet. They string together thousands (if not millions) of compromised devices to leverage their combined computational resources. Usually botnets are used for widespread spam and phishing campaigns.
In October, someone modified the Mirai botnet to create a distributed denial of service (DDoS) attack on Dyn, an internet resolution service. The result was a loss of service in the United States to several of Dyn’s high-profile customers, such as Twitter, Amazon, and PayPal. Until the attack on Dyn, the power of compromised IoT devices had only been theorized.
“This problem stems from a paradigm shift in how software is written,” said Schmidt. “Engineers often go out of their way to select a library from a catalog of hundreds of possibilities which most closely match the capabilities they desire with the smallest possible footprint. More often than not, this results in the use of immature code, which compounds when applications inherit the risks, bugs, and flaws that exist across all those purpose-built libraries, libraries they’ve imported to support the capabilities they require for the application.”
In 2016, Black Duck Binary Analysis identified several distinct versions of gSOAP. However, many more were unidentified versions. This suggests they were forked from the original, available from repositories other than the vendor’s site. “Organizations can help temper the wildfire of these types of pervasive security issues by enforcing policies that require verification and independent review of third-party code before it’s used,” Schmidt concluded.
Get the latest AppSec news and trends sent directly to you.