Events / News / Technology /

Dyn’s DDoS Attack Reveals the Internet of Things’ Security Woes

24 Oct 2016 8:16am, by

The massive internet outage last Friday that took out Twitter, GitHub, Spotify and others, was caused by a tsunami of incoming requests to Dyn, the DNS service provider supporting these companies. Where did all these requests pour in from? Hacked  CCTV video cameras, digital video recorders and other IoT devices.

The Internet of Things has arrived. And it brings huge security issues.

Even before the outage, IoT security was a topic of conversation, at least during one insightful panel, at the Stream Conf 2016, held in San Francisco last month.

No longer just a buzzphrase about a future technology, IoT is already ubiquitous. The average mid-priced car is a rolling OEM (original equipment manufacturer), having has 300-350 IP-enabled devices, coming from 40-50 different companies, explained Scott Montgomery vice president and chief technical strategist in Intel’s security division of Intel, during the panel.

He explained that this supply chain is inherited in any device that a chip is put in. You are definitely going to inherit all of your partners’ supply chain whether you want to or not.

The scary part? The car manufacturer is responsible for the end-use case for the IP-enabled devices, not for testing each internal component that makes up that delivery system individually. So if one of the chips is not secured, your entire system becomes vulnerable.

For instance, Samsung, among other manufacturers, is building out connected household appliances, such as refrigerators and stoves. If the chips on these refrigerators are breached and all the connected devices are shut down? Samsung will have hundreds of thousands of consumers with tons of rotting food along with a public relations nightmare.

Assume that every chip you deploy in the field is going to be fully available to anyone who has access to it, summarized Stephen Blum, founder and CEO of hosted app provider PubNub, in the panel.

It should contain no secrets, no hidden access, no keys to anything. It doesn’t matter where the chip will be deployed. “For chips,” he said, “Physical access is full access.”

What’s the difference between securing a laptop and an IoT Device?

The difference comes down to two things, said security strategist Billy Rios, on the same panel.

Connectivity is one issue, because any device with an IoT chip may now be connected to the internet — locomotives, jet bombers and your thermostat are now all connected.

The second difference is the function of IoT. The U.S. Defense Department, which Rios has done some work for, calls these devices, Cyber-Physical Systems. Cyber-Physical Systems will cause a physical change to something. Which is the point of IoT — to cause or track a physical change. Which makes them scary when not secured.

 

cpsconceptmap

From the “Cyber-Physical Systems” site.

Rios said the most common mistakes his company finds is stuff that just should not be there. Sometimes it’s funny like error messages that use profanity, but sometimes it’s really serious like credentials to infrastructure.

He broke it down: “If you think just because your software is on a chip, that they can’t get it off of there, you are mistaken. If you think that someone will never be able to understand your custom vertical, you are mistaken. If you think no one will ever find that hidden account you have in there to do debugging or to access to certain features that you don’t want your customers to get access to, you are certainly mistaken.”

Sure this is important for corporations, but there’s no need to secure a quick program you wrote and tossed onto GitHub to turn on and off your lights, right? You’re just going to be using it in your apartment.

Wrong.

Every single thing, Rios stressed, needs to be secured. The software that you write will be put in places you didn’t think of. For example, when he was brought in by the Defense Department to ensure intercontinental ballistic missile (ICMB) systems security, he found the missiles have off-the-shelf parts embedded into the extensive custom software.

That quirky code to turn on or off lights? It could end up in end up in a hospital or in a mine where it controls a life-or-death situation.

The devs who wrote the software that ended up in the ICBMs certainly had no way of knowing their code would end up there (and may still don’t know that it did).

Blum chimed in, saying, If you think you don’t have to security the low-security thing, hackers will look for any way into your system. They’ll use any unsecured devices to get access you’re your system, then use that to crack higher security items from within your system.

Holy Moly, Batman, What Can I Do?

Luckily, the panelists were full of advice.

The cheapest lowing hanging fruit, according to Montgomery, is still the data level certificate for the device. It is not a complete solution, but it’s a good start and is alarming how many devices are shipped without it.

The next step is to determine what the device is supposed to do. Then limit its activities and permissions to only that. Regular, routine permission is something that is often overlooked.

“If your default is to have root level permissions for your device all the time,” Montgomery stated, “we are going to see you in the paper.”

The biggest problem is that engineers don’t think things through, so they wind up like Mattel with Barbies that can spy on kids and Phillips with light fixtures that contain root-level permission in the lighting systems that are installed within someone’s house, he said.

“Just because you started programming with root level permissions doesn’t mean you should ship it that way,” he said.

Best way to secure data, said Blum, is to turn the device off, so no data can be transmitted. So if the device does not need to be on 24/7, configure it so it is not always on. After that, security needs to be strongest at the point that is accepting the signal.

He suggested companies create a set of tools that help you prevent your engineering team from building some access to a remote system.

There’s a huge advantage to choosing the right framework, agreed Rios. The biggest success stories he’s seen are from people using well-established frameworks like SQL injections. Protections are built in and you’re automatically protected.

For the long term, he said, it’s critical to invest in your update story. You will be updating the device, so if you build in a strong update mechanism, that will protect you in the long run.

For additional security measures, check out this excellent guide from the U.S. Federal Trade Commission.

Intel is a sponsor of The New Stack.

Feature image: Stream Conf’s security panel.


A digest of the week’s most important stories & analyses.

View / Add Comments