New Vulnerability Hits IoT Cameras

Since this is the week of Black Hat, it's likely that there will be a number of articles on different vulnerabilities and hacks here at SecurityNow.com. Today, though, before I even get on an airplane heading into the desert, there's a new vulnerability with a reach that could be epic. And before I get into the vulnerability, there's something I have to type: Just because the Internet of Things involves devices of little intelligence there's no need for system architects and developers to act equally dim.

I felt the need to start with that because the latest vulnerability, dubbed "Devil's Ivy" by the researchers at Senrio who found the flaw, is a problem that could hit millions of devices -- because it's a weakness in a code library rather than in a specific device.

The problem was found in dome cameras made by Axis Communications, a company that specializes in cameras for industrial, surveillance and other non-broadcast installations. The Senrio researchers discovered that the cameras were susceptible to a stack buffer overflow in a routine that exists in the gSOAP open source library.

Senrio acted responsibly, alerting Genivia, the company that manages the library, that the flaw existed, and not releasing details of the vulnerability to the public until after the flaw had been patched. That's the good news. Unfortunately, the bad news pretty much overwhelms the good, in this case.

Start with the fact that common code libraries are frequently used by scores of companies on software that is inserted into millions of devices. Some commenters have focused on the open source nature of the library, deciding that reusing the code is a bad practice that leads to widespread vulnerabilities.

They're right, in one sense: A vulnerability in frequently reused code, whether that code is in a library, function, operating system or applet means that the vulnerability will end up on far more endpoint devices than if the code were custom-developed for each instance. In another sense, though, they're quite wrong: code reuse is not limited to open source projects and is one of the fundamental principals behind agile development and DevOps. Blaming this on open source is wrong.

For that matter, blaming it on code reuse is wrong, too. Not to put too fine a point on it, but if every application team had to independently recreate every display and communications function, every network stack, and every data retrieval method, we'd have far, far fewer applications in the enterprise world than currently exist, and the IoT would have three dozen applications that did creative things like tell the temperature but nothing more.

You're invited to attend Light Reading's Virtualizing the Cable Architecture event – a free breakfast panel at SCTE/ISBE's Cable-Tec Expo on October 18 featuring Comcast's Rob Howald and Charter's John Dickinson.

No, if there's a problem here it's that development teams are still not adequately testing for things like stack buffer overflow. It's not like this sort of vulnerability is unheard of. And it's not like we've never seen a vulnerability in a common library. It's time to start testing far more thoroughly, starting with the foundations.

It's also time we realized that, if the Internet of Things is going to develop, it has to develop safely. Among many other things that means designing endpoint devices so they can be safely updated and their user ID and passwords changed from factory defaults. Pretending that the rules for security don't apply just because the endpoints are sensors and controllers hasn't really worked out -- and developers are too smart to think that the magic IoT fairy will sprinkle security dust on their system to protect the users.

Finally, the owners and users of the IoT deserve some blame, too. Follow me, here: You're about to put lots of devices on your network that can't be secured in the same way that you secure your computing devices. They watch your people, control critical functions and collect data that would be of great interest to your competitors. Don't you think you should add network protection in the form of firewall rules, IDS and IPS conditions, and meaningful segmentation? Yeah, me, too, but far too many individuals and organizations don't.

Another week, another vulnerability. Perhaps, in this week of Black Hat, we'll learn something meaningful from this one. Perhaps.

Related posts:

— Curtis Franklin is the editor of SecurityNow.com. Follow him on Twitter @kg4gwa.