This month the Mirai botnet waged the world’s largest DDoS attack in history against Dyn, a major domain-name server. The attack wreaked havoc across the entire internet, taking down major sites, gaming networks and other online services over the course of three massive waves throughout the day before Dyn was finally able to beat the hackers back.
IoT Vulnerabilities Enable Bad Botnets
IoT vulnerabilities are what made the Mirai botnet possible, helping attackers attain great scale across tens of millions of unique IP addresses.
A month before, the same botnettook down the website of independent security journalist Brian Krebs with a similarly massive DDoS attack leveled against Akamai, Krebs’ then hosting provider. The Krebs DDoS attack, well over 620 Gbps in size, was more than twice as large as the next biggest DDoS attack Akamai had ever faced up until then. That same month, separate attacks committed against OVH, an ISP, reached 1.1 Tbps; the botnet responsible reportedly used more than 145,000 smart cameras.
These aren’t the first instances of malevolent IoT hacks hitting the headlines. Hackers perpetrated the great Target attack of 2013 by compromising Target’s vendor-managed smart-HVAC system. Meanwhile, hacks have occurred in consumer IoT devices ranging from “smart” televisions to “smart” baby monitors.
White-hat researchers have also pointed out that connected cars are rife with frightening vulnerabilities. And on the enterprise side, even industrial SCADA systems managing critical infrastructure have been breached.
IoT devices have long been notoriously insecure, and it is only recently that the doom some pundits have been predicting for years has caught the attention of the hoi polloi. Accordingly, below are four tips from Internet of Things security experts on best practices for foiling would-be IoT hackers, gleaned from a recent IoT Security Summit in Boston.
Let’s hope that people listen this time.
Test and Verify Your IoT Code Extensively
When it comes to DevOps and IoT, “the most common [source-code vulnerabilities] are buffer overflows [and] memory leaks,” related Callie Frisch in an interview on the exhibition floor at this month’s IoT Security Summit. Frisch would know; she is communications manager of TrustInSoft, a Paris-based company that specializes in analyzing source code for developers and auditing safety- and security-critical software.
Because of the small size of most IoT devices, a lot of IoT source code tends to be written in C or C-related languages (such as C++ and C#); these languages are particularly prone to buffer overflow vulnerabilities and memory leaks.
The libsecurity-c project for IoT devices, for instance, employs an “extensive testing effort[,] using tools such as Valgrind, GCC and CLANG compilers, and IBM ExpliSAT for formal verification,” along with additional layers for further testing and verification.
Additional verification and protection methods to prevent buffer overflows can be deployed, including stack cookies. A stack cookie is a randomized data string that applications are coded to write into the stack just before the Instruction Pointer Register, to which data overflows if a buffer overflow occurs. If a buffer overflow occurs, the stack cookie will be overwritten as well. The application is thereby further coded to verify that the stack cookie string continues to match how it was initially written; if the stack cookie doesn’t match, the application is coded to terminate.
Secure Against IoT Device Identity Spoofing
It is important to secure against IoT device identity spoofing, said experts at the summit.
“You need to know what device you’re talking to, and [if it is] a legitimate device,” said Petr Peterka, CTO of Verimatrix, in a presentation on developer perspectives at the event, “[because] the ability to download critical software updates over the air is critical to security.”
“You want to have a unique identity for [an IoT] device,” Julia Cline, director of Product Management for Rubicon Labs, told eSecurity Planet in an interview at the summit, “because if you don’t, some other device can get on [the network] and say, ‘Hey, I’m that device!’”
Traditionally (to the extent anything can be traditional in the IoT realm), setting and managing unique identities has been difficult for IoT devices due to their small and low-end their chipsets. Rubicon specializes in providing these unique identities for IoT devices of all sizes; so there is, it would seem, no longer any excuse to not do so.
“We provide secure identification down to the lowest-end microcontrollers…that don’t at this point have any identity behind them,” said Cline. While standard device identity measures only go so far, she said, “we use symmetric cryptography to go below that.”
Pay Attention to Network Approvals Beyond Encryption
Still, certificate matching has its technological limits for IoT devices.
“A lot of IoT devices are tiny; they don’t have the space” for certificate matching, said Mike Mackey, CTO and vice president of Engineering of CENTRI, in another on-site interview at the IoT Security Summit.
So too with solutions like Rubicon’s encryption-based identity matching.
“Encryption is blindly trusted; you don’t sandbox encryption,” pointed out Scott Rice, senior manager of Strategic Initiatives for Venafi, in an interview at the summit. “The bad guys are getting into systems with encryption.”
“NIST this past August released a draft for … lightweight cryptography for IoT,” Mackey added. “They suggest [typical enterprise encryption] probably isn’t going to suffice for IoT.”
Accordingly, the network as a whole needs to be secure in order to keep IoT devices secure.
“If you can crack a device that has some kind of trust with an enterprise, that’s another attack surface,” said Rice.”[So] if there is stuff on the network that is bad, you [need to be] getting rid of it immediately.”
Carefully Vet — and Do Not Blindly Trust — IoT Vendors
To this end, Rice pointed to the recent controversy surrounding Aruba when the company was discovered to have sold IoT devices with factory-installed key and certificate patterns that were known to be compromised. Not only that, but Aruba reportedly was aware of this flaw for years. Accordingly, Rice advises deploying solutions (like Venafi’s) to discover all of the keys and certificates on your network — and, if you didn’t know you had them and they are compromised or otherwise unapproved, revoke them.
“This is one of those things where customers should know better,” lamented Rice, “but they’re not doing anything about it.”
Peterka, for his part, advises going even deeper — down to the OEM hardware level.
“We work with chip vendors,” said Peterka. “You need to start from the bottom [because] chip vendors … can put secrets in any device.”
Read More: Top IoT Security Solutions
Change Default Security Settings on Networking Gear
This would seem to be a no-brainer for network security in general, but many people — individuals and enterprise IT workers alike — leave the logins and passwords on their routers and other networking equipment set to their factory defaults.
“Change the default setting on [your] router,” network security writer Steve Zurier advised his readership three days after the Dyn attack. “Strong passwords on … routers can prevent the type of DDoS that happened last Friday to Dyn.” Additionally, implementing a mobile device management platform within your organization can help businesses manage all of the risks of IoT devices.
Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate communications and data privacy consultant, writer, speaker and bridge player. Follow him on Twitter at @JoeStanganelli.
