While it claims to be “smart,” a socket powered by the Internet of Things (IoT) suffers from a number of dumb security vulnerabilities.
Researchers at Bitdefender Labs came across the flaws as part of their ongoing efforts to raise awareness about IoT security in the home.
To set up the device, the research team plugged the socket (whose vendor was unnamed by Bitdefender, but has been identified as Edimax by The Register) into a normal power outlet and downloaded the mobile app, in which they selected and entered in the credentials for their test Wi-Fi network.
After successfully connecting to the network, the device registered with its vendor’s servers and sent various pieces of information – such as its MAC address, IP address, and firmware version – to the app for storage.
That little communication exchange marked the end of setup. At that point, the researchers could use the smart socket to schedule an electronic device to turn on and off from their smartphone.
Simple enough… but deeply flawed.
Researchers found the setup process suffered from the following vulnerabilities:
- The device’s hotspot, which the mobile app uses to connect with the socket, is protected by a weak username-password combination.
- Users receive no alerts for deciding to stick with the product’s default credentials.
- The socket transmits the user’s Wi-Fi credentials in cleartext.
- All device-to-application communication is encoded but not encrypted, meaning an attacker can easily reverse the encoding scheme.
- Users can configure the socket to send them notifications to their email, but for some reason, the device requires access to their email username and password to fulfill that functionality.
Together, those vulnerabilities enable baddies to conduct at least two different types of attacks. The first is a basic account takeover, as Bitdefender’s researchers explain in a blog post:
“If an attacker knows the MAC address of the device and the default password, he can gain remote control of the device to re-schedule it, or access all the information the device uses, including the user’s email address and password, if the email notification feature is enabled. This can lead to the full compromise of the linked email account, unless two-factor authentication is enabled.”
The second form of attack consists of command injection as a result of inadequate password sanitization. To illustrate, a program may misinterpret a “;” contained in a password as an executable command. Attackers can exploit that fact to overwrite the root password, open Telnet, and from anywhere in the world send commands to mess around with the plugged-in appliance’s schedule.
That’s nothing to laugh at, notes Bitdefender’s chief security researcher Alexandru Balan:
“This type of attack enables a malicious party to leverage the vulnerability from anywhere in the world. Up until now most IoT vulnerabilities could be exploited only in the proximity of the smart home they were serving, however, this flaw allows hackers to control devices over the Internet and bypass the limitations of the network address translation. This is a serious vulnerability, we could see botnets made up of these power outlets.”
This is not the first time researchers have found flaws in IoT devices. Barbie dolls, teddy bears, webcams, media streamers, and even hotel rooms have all threatened users’ privacy at one time or another.
From these experiences, we’ve learned that we need to be a lot more careful when it comes to purchasing an IoT device. That means doing our research online about a potential purchase, reading reviews about the product, and ideally testing how it works after setup is complete.
If this proves to be too much effort, we can always go with a non-smart option. In this case, a regular timer socket would be more than sufficient.
"encrypted but not encoded, meaning an attacker can easily reverse the encoding scheme." Does not make sense.
Perhaps he meant the other way around, "encoded but not encrypted". That would make sense…
There are a couple of variations that would make sense. I was hoping the article would be amended so we didn't have to guess which it is. :)
Indeed you're right, Chris. "Encrypted but not encoded" doesn't make sense. I meant to say the other way around. It's now fixed. I apologize for the confusion. Thanks for the catch. :)