Pwned By Your Possessions: Is IoT Worth The Trade-Off?

Remember the good old days when the worst that could happen was your identity being compromised via your computer?

The Internet of Things (IoT)is bringing unprecedented levels of user exposure and your data is being amassed across physical devices that taken together provides a multi-faceted version of you.

By combining virtual and real world activity it becomes possible to determine habits and quirks, patterns, and to predict and manipulate behaviour and that means the IoT will see an end to privacy as we know it and the beginning of ‘always on’ access to us.

Devices are already collecting audio and visual data on us, from our TV to our toys, which can be used to carry out surveillance by manufacturers and unscrupulous types.

It’s for this reason that consumer groups have been lobbying against IoT devices; a move which saw the My Friend Cayla doll banned in Germany and similar opposition against children’s connected toys in the US. So why isn’t more being done to protect us and to prevent these devices from being compromised?

Too little trial, too much error

Manufacturers shoulder the responsibility but they’re on a steep learning curve. Development now entails partnering with designers, app developers, mobile networks, as well as providing technical support.

They’re no longer simply responsible for the product for the warranty period but issuing patches for its entire lifespan. They’re in unfamiliar waters, have very little guidance or regulation, and priorities are inevitably reduced to price and time to market which leads to the same security errors cropping up.

The most common point of failure is the mobile app. Often, there’s a failure to implement SSL or it’s done badly, allowing data to be intercepted. Data stored in the app is often unsecured and some store passwords in the mobile app itself.

An attacker may then reverse engineer the app to gain access to the web service and if this too is poorly secured this can lead to the compromise of mass consumer data. Poor session management can allow logged in users to see other accounts, while a lack of encryption together combined with an injection attack can see data extracted.

Another common issue is poor implementation of the wireless standard used to convey data. This not only results in data leakage but even the ability to track and locate users, paving the way for targeted drive-by attacks with online databases such as wigle.net and Shodan. Bluetooth devices are trackable but tend to be hacked due to the use of default PINs for pairing while Zigbee and Z-Wave, both sound standards in themselves, are sometimes implemented insecurely.

Hardware again tends to be dictated by price and functionality but it’s here where choice can make the difference. External flash and RAM, as opposed to embedded memory, make it much easier to hack the firmware while poor PCB design can make it easier to tap data signals.

Leaving out an authentication mechanism may cut costs and be better for ease of use but without secure key storage the device is wide open to attack. Similarly, firmware needs to be encrypted and signed or the attacker can simply download and unpack it.

 Loading ...

Buy now, fix later

There’s also a tendency for manufacturers to leave in place unused functionality such as serial ports, JTAG, Telnet or hidden debug ports due to erroneous assumptions that such connectivity might be useful in future.

One obvious example of this is the DVR firmware used across countless IoT devices, including CCTV and routers, in which Telnet was enabled, providing a door for the Mirai malware to propagate over. This saw an army of IoT devices used to carry out mass DDoS attacks late last year culminating in attacks against Krebs Security, Dyn, and OVH.

DVR manufacturer XiongMai took the laudable step of trying to fix the problem by disabling Telnet. The only trouble was that the manufacturer failed to take into account other security issues. Consequently, it was possible to connect via another port, use the default password which mirrored that used by the web interface, and to re-enable the Telnet port. Voila. The device was vulnerable to Mirai again.

Continues on page 2…