Tech is the only sector of the economy that makes its products and services better, faster, and cheaper on a year-over-year basis. The smartphone in your pocket contains so many transistors, that it would have taken up several city blocks a few decades ago. If the tech sector ran healthcare and education, having a baby would cost $999.95, and a college degree could be paid for by cutting grass.
However, all this cheap tech comes with a major downside; mainly the proclivity to connect anything and everything to the Internet, creating all manner of potential attack vectors and privacy problems. This isn’t just an issue with consumer electronics either; we cyber wonks see the same problem in the commercial and government sectors as well. This is just one of many reasons why it is imperative to sandbox IOT, and scan your networks for vulnerabilities and unauthorized devices on a routine basis.
At the risk of sounding like a broken record, this week brings us yet another “D’Oh!”, this time from a product line known as iSmartAlarm.
From The Register:
iSmartAlarm ships a variety of app-linked security products, including door sensors, motion sensors, cameras, locks, and a controller unit (called the Cube), with iOS and Android apps, Alexa capabilities … pretty much the full suite of ShinyHappySmartLife™ must-haves.
Now, it’s time to get out your bingo cards, because the list of vulnerabilities includes issues with SSL certificate validation, authentication errors, an access control blunder, and a denial of service.
The vulnerabilities were turned up by Ilia Shnaidman of Bullguard Security, which makes a gizmo called Dojo that monitors Wi-Fi networks for threats to IoT devices. Shnaidman requested CVE ID numbers for the bugs, with one request rejected as being in error.
So let’s stick with the vulnerabilities that got CVE allocations, the discovery of which is detailed here.
The SSL certificate validation bug is in the CubeOne that handles communications between the iSmartAlarm-protected home and the smartphone app.
During the SSL handshake with its server, the CubeOne doesn’t check the server certificate’s validity, so Shnaidman only needed to forge a self-signed cert to get control over CubeOne-to-server traffic.
Security is almost always an afterthought when designing these devices, so installing mostly any IOT device on your network carries some level of risk – risk that must be managed. If you absolutely must connect IOT devices to your corporate network, just assume that they are already compromised and configure your security policies accordingly.