You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • The challenge of insecure IoT

    An attack on Dyn (a DNS service provider) through a distributed denial of service (DDOS) attack brought down Article: Mixed-Signal Methodology Guide-botnet-min-jpegGithub, Amazon and Twitter for a while and is thought to have been launched through IoT devices. Hangzhou Xiongmai, a provider of webcams and the most publicly pilloried source of weakness in the attack is now recalling all its webcams in the US.

    The problem, per one review, is that devices were all shipped with the same default credentials (login and password) and worse yet these were hardcoded into the firmware and not possible to change using software provided with the system. Further, the web interface for these devices either doesn’t check for credentials, or that check is easily bypassed. For this class of web weaknesses, it is believed that over half a million devices today are more or less trivially vulnerable. Which equally means that it can be rather easy not only to compromise a device but also to build botnets to launch DDOS attacks against whatever targets you want. To get a sense of hacker enthusiasm for this area, google “uc-httpd”.

    I’m guessing that some of the problem here is cost for the supplier – small margins don’t encourage significant investment in security. Some is probably lack of sufficient security understanding – “yeah, we got security features”. (A frightening number of engineers have told me that having a cryptography core in their design means they’ve taken care of security.) And some probably has been a lack of standard idiot-proof security platforms.

    The ARM Corelink SSE-200 subsystem, together with mbed and mbed Cloud, could go a long way to providing the idiot-proof part of a solution, since that takes away from the supplier control of credential management, among other security-related features. Of course the consumer of a webcam would have to do a little cloud work to establish their device with validated credentials but that doesn’t seem like it should be too onerous.

    But meantime there are 500k easily-hacked devices out there. It also seems improbable that at least some suppliers won’t continue to cut some corners, or simply take time to come up the security learning curve. There will likely be a lot of potentially hostile devices in the IoT for some time. A tricky problem here is that the threat posed by such a device is not necessarily to the owner since DDOS attacks simply use devices as launch points to attack some other target. The owner may not be aware, or if aware may not care that their device is part of a problem.

    So while it is important to protect devices and their link to the cloud, in some sense it is also important to protect “the system”. The network has to be protected because your well-protected, fully credentialed device can still be rendered effectively inoperative if network traffic is swamped by a DDOS attack. And devices within the network have to be protected because if even one is a little weak, an attacker can exploit that weakness to gain privilege, from which they can then run rampant through the network. Paradoxically, this becomes even easier if nodes in the network are based on a common architecture.

    Point being, while it is important to have solid protection for a device and its connection to the cloud (as provided by the ARM IoT integrated solution), it’s also important to think about system-level defenses which can isolate/disable distributed attacks and compromised devices. You can read a quick version of the Xiongmai role in the Dyn attack HERE and a little more technical detail HERE.

    More articles by Bernard...