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.
Sign up for CIO Asia eNewsletters.