Many connected-home devices lack robust security features, security firm claims
By Jake Widman
According to a report released this morning by security provider Veracode, many of the Internet of Things devices that consumers are buying for their increasingly connected homes are vulnerable to hacker exploits. While Veracode looked at different devices and vulnerabilities, its overall findings mirror those by Synack, which we reported on last month.
“The Internet of Things is getting more and more popular,” said Veracode security research architect Brandon Creighton, “and it’s grown into a phenomenon that doesn’t just exist in the realms of technical people who are buying little components and plugging them together. It’s now a consumer-level thing, and you can buy most of these devices at a Target or a Home Depot. Even though they’re packaged as hardware devices, in reality they’re just like any other technological system in that they’re primarily comprised of software.” And software can be hacked if it’s properly protected.
In designing the study, Creighton said “we wanted to choose devices that had an impact in the real world, or at least the potential for it.” To that end, his team looked at always-on systems that are marketed to end users who don’t possess any particular technical expertise. In addition to the Chamberlain MyQ Garage and the Ubi, the firm tested the Chamberlain MyQ Internet Gateway, the SmartThings Hub, the Wink Hub, and the Wink Relay.
Researchers conducted 10 tests, classifying the results into four categories: user-facing cloud services, back-end cloud services, mobile application interfaces, and device-debugging interfaces. They found vulnerabilities across most categories in all but one of the devices.
“The SmartThings hub did pretty well on the tests we applied,” Creighton said. “We didn’t do an in-depth security review on every aspect of the device—we didn’t go into the firmware. We’re not saying they’re secure, we’re saying that for these tests, they did pretty well.”
Veracode installed and configured the devices according to their included documentation, and then monitored and captured all the communication between the devices and their surroundings. “When you’re thinking about IoT devices as a consumer, it’s important to think about the fact that these are not just isolated things sitting in your house,” Creighton said, “there are any number of services they may be communicating with.
And the security of the system as a whole often relies on those services being secure as well. We didn’t have permission to scan those services, so the flaws we did find were mostly in the devices themselves, and related to the communication between the devices and the servers.”
Veracode’s researchers evaluated four elements of these products’ user-facing cloud services: whether the service allowed users to encrypt communications, whether it required encryption, whether it enforced a strong password, and whether any mobile applications that work with the device validated the server’s TLS (transport layer security) certificate. All the devices did pretty well in these tests, with the SmartThings Hub the only one requiring a strong password.
In testing the communications between the devices and their associated cloud services, Veracode examined whether they used a strong means of authenticating themselves to the service, whether communication was encrypted, and whether they offered protection against various common forms of attacks.
“We wanted to illustrate that the security of the system is not just about the security you have on the device,” Creighton said, “but it’s also determined by the security of all of the services run by the manufacturer. Everything the device talks to is another link in the chain.” All the devices passed the first test—authentication—but it was downhill from there, and once again the SmartThings Hub was the only device to pass all the tests.
The third category involved two tests: whether sensitive mobile-to-device traffic was secured, and whether the mobile applications validated the devices’ TLS certificates. Results on the first test were mixed, while none of the devices used TLS/SSL validation.
“Something that may be crucial for a developer to get their job done might turn into a security vulnerability if left turned on after the device is produced,” explains Creighton. “As a developer, you’re working in your closed laboratory with a local version of a service. That service is not Internet-accessible and probably doesn’t have a valid SSL certificate. So when you’re developing it, you turn off certificate validation and it works fine. The problem is, if nobody checks to see if that’s still turned off later, the device will work fine but it’ll be insecure.”
The final category, debugging interfaces, involved services or interfaces that aren’t mean to be accessed by the end user but are nevertheless available over the local network or the wider Internet. The testers looked at whether such interfaces were restricted to those with physical access to the device, whether an attacker could bypass whatever authentication process might be in place, and whether the device prevented running arbitrary code. In this case, the MyQ Gateway was the only device to restrict the interfaces to those with physical access, while results on the other two tests were mixed.
“Essentially you could call those debugging interfaces ‘unintentional back doors’ because of the level of access that they give,” Creighton said. “If you have access to the local network that these devices are running on, then you can use standard debugging tools to connect to that service and run commands on it and completely bypass any password or authentication. I’m sure that’s important for the manufacturers to do development and testing, but it should not be on in the real world.”
No need to panic
Despite the findings, Creighton cautions that these vulnerabilities aren’t catastrophic. “All of these are the same type of flaws we find in analyzing applications every day,” he said. “There’s nothing in here that’s Heartbleed-esque, that’s going to blow up everybody’s devices tomorrow. If we’d found something that was exploitable on a mass scale, we’d have made sure it had gotten fixed before mentioning it at all. But that doesn’t mean there aren’t risks here.”
And the companies involved have proven relatively receptive to learning about their products’ vulnerabilities. “We’ve reached out to these companies and let them know the details of these flaws we found, and we’re working with them to get them fixed if they’re interested,” Creighton said. “The fact is, flaws happen to everybody, and the companies that tend to do the best in modern times are the ones that can rapidly respond.”
Update: Representatives from Chamberlain and Ubi contacted us to point out that they’ve already addressed some or all of the vulnerabilities pointed out in Veracode’s report.
Chamberlain sent the following statement: Chamberlain has reviewed the Veracode study and confirms that the MyQ product test is out of date, as the Chamberlain Group continually reviews and makes improvements to its product security. Additionally, we disagree with some of the findings in the report and will work with Veracode to share our concerns.
Chamberlain takes the safety and security of the smart home very seriously. Our continuous security updates and processes include using industry standard encryption, applying the latest security techniques, and periodic security testing with respected outside services. This study is a good reminder to homeowners to keep their networks secure by using strong passwords and security settings.
Ubi CEO Leor Grebler wrote: We’re marketing the device as a product to prototype voice interaction in an environment rather than a consumer electronics product. As a result, we’ve enabled tools to allow for developing voice interaction that we wouldn’t enable in a retail product. We showed people how to get into their own Ubis on our forum (forum.theubi.com). We’re unsure of Veracode’s motivation in approaching us. Some of the issues that were raised by Veracode have been resolved or were in our roadmap for updates. Gaining access to the device locally does not compromise web services that are subscribed to by the Ubi user (e.g. Google Calendar or contacts). The scenarios mentioned would be pretty far fetched and would require someone 1) with access to the device or its network 2) who already has a lot of knowledge of that user 3) working knowledge of the lessons that the user has built and 4) can decipher/infer information from analyzing weeks of data.