July 18, 2017

Axis Communications — a maker of high-end security cameras whose devices can be found in many high-security areas — recently patched a dangerous coding flaw in virtually all of its products that an attacker could use to remotely seize control over or crash the devices.

The problem wasn’t specific to Axis, which seems to have reacted far more quickly than competitors to quash the bug. Rather, the vulnerability resides in open-source, third-party computer code that has been used in countless products and technologies (including a great many security cameras), meaning it may be some time before most vulnerable vendors ship out a fix — and even longer before users install it.cam2cam

At issue is a flaw in a bundle of reusable code (often called a “code library“) known as gSOAP, a widely-used toolkit that software or device makers can use so that their creations can talk to the Internet (or “parse XML” for my geek readers). By some estimates, there are hundreds — if not thousands — of security camera types and other so-called “Internet of Things”(IoT) devices that rely upon the vulnerable gSOAP code.

By exploiting the bug, an attacker could force a vulnerable device to run malicious code, block the owner from viewing any video footage, or crash the system. Basically, lots of stuff you don’t want your pricey security camera system to be doing.

Genivia, the company that maintains gSOAP, released an update on June 21, 2017 that fixes the flaw. In short order, Axis released a patch to plug the gSOAP hole in nearly 250 of its products.

Genivia chief executive Robert Van Engelen said his company has already reached out to all of its customers about the issue. He said a majority of customers use the gSOAP software to develop products, but that mostly these are client-side applications or non-server applications that are not affected by this software crash issue.

“It’s a crash, not an exploit as far as we know,” Van Engelen said. “I estimate that over 85% of the applications are unlikely to be affected by this crash issue.”

Still, there are almost certainly dozens of other companies that use the vulnerable gSOAP code library and haven’t (or won’t) issue updates to fix this flaw, says Stephen Ridley, chief technology officer and founder of Senrio — the security company that discovered and reported the bug. What’s more, because the vulnerable code is embedded within device firmware (the built-in software that powers hardware), there is no easy way for end users to tell if the firmware is affected without word one way or the other from the device maker.

“It is likely that tens of millions of products — software products and connected devices — are affected by this,” Ridley said.

“Genivia claims to have more than 1 million downloads of gSOAP (most likely developers), and IBM, Microsoft, Adobe and Xerox as customers,” the Senrio report reads. “On Sourceforge, gSOAP was downloaded more than 1,000 times in one week, and 30,000 times in 2017. Once gSOAP is downloaded and added to a company’s repository, it’s likely used many times for different product lines.”

Anyone familiar with the stories published on this blog over the past year knows that most IoT devices — security cameras in particular — do not have a stellar history of shipping in a default-secure state (heck, many of these devices are running versions of Linux that date back more than a decade). Left connected to the Internet in an insecure state, these devices can quickly be infected with IoT threats like Mirai, which enslave them for use in high-impact denial-of-service attacks designed to knock people and Web sites offline.

When I heard about this bug I pinged the folks over at IPVM, a trade publication that tracks the video surveillance industry. IPVM Business Analyst Brian Karas said the type of flaw (known as a buffer overflow) in this case doesn’t expose the vulnerable systems to IoT worms like Mirai, which can spread to devices that are running under factory-default usernames and passwords.

IPVM polled almost a dozen top security camera makers, and said only two (including Axis) responded that they used the vulnerable gSOAP library in their products. Another three said they hadn’t yet determined whether any of their products were potentially vulnerable.

“You probably wouldn’t be able to make a universal, Mirai-style exploit for this flaw because it lacks the elements of simplicity and reproduceability,” Karas said, noting that the exploit requires that an attacker be able to upload at least a 2 GB file to the Web interface for a vulnerable device.

“In my experience, I don’t think it’s that common for embedded systems to accept a 2-gigabyte file upload,” Karas said. “Every device is going to respond slightly differently, and it would probably take a lot of time to research each device and put together some kind of universal attack tool. Yes, people should be aware of this and patch if they can, but this is nowhere near as bad as [the threat from] Mirai.”

Karas said similar to most other cyber security vulnerabilities in network devices, restricting network access to the unit will greatly reduce the chance of exploit.

“Cameras utilizing a VMS (video management system) or recorder for remote access, instead of being directly connected to the internet, are essentially immune from remote attack (though it is possible for the VMS itself to have vulnerabilities),” IPVM wrote in an analysis of the gSOAP bug. In addition, changing the factory default settings (e.g., picking decent administrator passwords) and updating the firmware on the devices to the latest version may go a long way toward sidestepping any vulnerabilities.

14 thoughts on “Experts in Lather Over ‘gSOAP’ Security Flaw

  1. IRS iTunes Card

    This article is not in my wheelhouse ! LOL

  2. Nobby Nobbs

    Rack up another win for the Internet of (Broken) Things!
    Thanks, Brian!

  3. Nobby Nobbs

    Can’t resist, I just saw this comment on an El Reg story about the FBI alerting parents of the privacy problems with IoT toys, from user “ammabamma”:

    (Facepalm Icon)
    An important thing to remember with Internet of Things:

    The “S” in IoT stands for “Security”.
    lol! Too true!

    Link to story:

  4. JCitizen

    Good article! My thanks to Brian for digging up this data for us! It has been generally held at many forums I hang out at, that the best defense against Mirai is to change the factory defaults – especially passwords if applicable, also if possible, turn off WAN side administrative capability. Maybe not all IoT devices have those features. but many that I’ve investigated do.

    Perhaps it would be best to go with the companies that are aware of this vulnerability, even if they admit the files have not been updated. At least they admit there is a problem. Seems like you are 99% there with a vendor like that. Here’s to those that do something about gSOAP – otherwise they don’t have a right to brag about using open source software.

  5. Dennis

    Brian, what’s the technical details on this bug? Someone used int instead of unsigned int in the C code?

  6. SeymourB

    I do want to point out that just because a Linux installation is running an old kernel version doesn’t mean that Linux installation is vulnerable. The developer can backport security patches from newer versions onto the older kernel.

    Broadcom, for instance, produces drivers that are linked against the 2.6 kernel. But the libraries and kernel are updated with backported security updates from newer kernels, which makes it a secure environment.

  7. 10-4 Buddy

    I’m a bit confused by Van Engelen’s comment where he says it’s just a crash, not an exploit. Senrio writes on its blog that “when exploited, it allows an attacker to remotely access a video feed or deny the owner access to the feed.” I know sometimes it takes a while to see what effects the bug may have on different devices. Any clarity on that Brian?

    1. R. van Engelen

      10-4 Buddy: the reason why it is difficult to exploit this vulnerability is 1) the Apache server is commonly configured to allow max 2GB data upload, which makes it impossible to exploit this flaw, and 2) as Sanrio says “the tricky part of this was that we could not use any addresses which contained bytes with a value below 0x20 or 0x3F or 0xFF…” meaning it requires a specific attack approach for each device because the buffer is changed, assuming the device accepts 2GB data first. The problem is the vendor’s improper use of the software as the library in the documentation states clearly that the preferred way to deploy services is to use Apache or IIS. Common sense, right? I understand that they rolled out their own server. Not nice to be thrown under the bus by one ONVIF vendor who blames gSOAP and appears not to understand the importance of server deployment principles. I talked to several ONVIF vendors who are not affected because of the configuration with Apache and other protections already in place.

  8. Adrian Thornton

    Has anyone used Shodan to see just how big a problem this is?

  9. Ollie Jones

    I’ve worked with webcams from several vendors. (Cue the theme music from the spaghetti western movie The Good, the Bad, and the Ugly.)

    Axis is good. They release upgrades. They’ve provided the workflow stuff ya need to ingest and deploy their upgrades. Their upgrades don’t just sort out vulnerabilities, but improve their products in the field.

    Some of the other vendors … not so much. What you see is all you’re ever going to get.

  10. Haroon

    Thank you for the awesome POST.
    I appreciate this blog. I figured out this blog as one of the best Security tips providers.

Comments are closed.