Exploitable gSOAP flaw exposes thousands of IoT devices to attack

Researchers have unearthed a serious vulnerability in gSOAP, an open source, third-party code library used by thousands of IoT by many different manufacturers.

Senrio Labs exploit Axis Communications M3004 security camera with Devil’s Ivy exploit

Devil’s Ivy (CVE-2017-9765)

The stack buffer overflow vulnerability – nicknamed “Devil’s Ivy” – was discovered by researchers with IoT cybersecurity outfit Senrio, during their analysis of the remote configuration service of a web camera manufactured by Axis Communications.

More technical details about the discovery can be found here, but the important fact about the flaw is that it can be exploited to crash the system or achieve remote code execution.

According to the researchers, “when exploited, it allows an attacker to remotely access a video feed or deny the owner access to the feed. And, since these cameras are meant to secure something, like a bank lobby, this could lead to collection of sensitive information or prevent a crime from being observed or recorded.”

When it comes to other types of IoT devices that use a vulnerable version of gSOAP the consequences of a successful exploitation could be even more grave.

But, as analyst Brian Karas told Brian Krebs, the good news is that this type of flaw can’t be exploited easily or reliably enough to be used to widely spread IoT worms like Mirai.

For one thing, the exploit would require an attacker to upload at least a 2 GB file to the Web interface of a vulnerable device, and devices that accept such a big file upload are probably not common. Secondly, different devices would respond to such an upload differently, and it would take much effort to create a universal attack tool that would take into consideration these different responses.

Patching the flaw

Senrio researchers have notified Axis Communications of their discovery, and to their credit, the company has reacted quickly: they found that Devil’s Ivy is present in 249 of their camera models, created a fix, and began releasing patched firmware and, at the same time, urging partners and customers to upgrade.

Genivia, the company that manages the gSOAP library, has released in late June a new version (2.8.48) that includes the patch for the flaw.

“Software or device manufacturers who rely on gSOAP to support their services are affected by Devil’s Ivy, though the extent to which such devices may be exploited cannot be determined at this time,” Senrio researchers noted.

According to Genivia’s numbers, the library has beed downloaded millions of times, and has likely been added to many companies’ code repositories for future use.

“When developers share similar foundational code bases, bake these into the software running their devices, and fail to or miss vulnerabilities as a part of a well-oiled software development lifecyle, the impacts can be broad,” Chris Pierson, EVP, Chief Security Officer & General Counsel of Viewpost, commented.

In the present case, this flaw is present in the third-party code base adopted by companies like Bosch, Canon, Cisco, D-Link, Fortinet, Hitachi, Honeywell, Huawei, Mitsubishi, Netgear, Panasonic, Sharp, Siemens, Sony, and Toshiba, he pointed out.

“In addition, Axis is one of thousands of companies that are part of the ONVIF forum, an organization responsible for maintaining software and networking protocols that are general purpose enough for a variety of companies to use in a wide range of physical security products. The forum relies on SOAP [Simple Object Access Protocol] to support the ONVIF specifications, and approximately 6% of the forum members use gSOAP.”

It is the responsibility of all those manufacturers to push out a fix for Devil’s Ivy and urge users to update their firmware in order to plug the hole. And users would do well to proactively demand for a fix – for this and any other vulnerabilities found to affect the products they use.

Unfortunately, many IoT manufacturers drag their feet when it comes to issuing security updates, and users should consider beefing up the security of their IoT devices by keeping them off the Internet (i.e. connecting them to a private network instead) and by employing other security measures (e.g. a firewall between the Internet and the device).