Symantec is a giant in IT security for both consumers and enterprises, but the company is extending its reach way beyond computers and routers into the devices and hubs that comprise the Internet of Things (IoT). That includes the end devices, whether they communicate over Wi-Fi, ZigBee, Z-Wave, Buetooth or proprietary home automation protocol.

As such, Symantec created a white paper in 2015 called “Insecurity in the Internet of Things” that is fairly readable even for relatively non-technical people like me.

For this report, Symantec evaluated 50 smart-home devices and concluded, “Despite an almost constant stream of media reports of cyberattacks and hacking incidents, there are still many devices that do not use encrypted communications or proper authentication.”

The company warns: “IoT devices often have less memory and slower CPUs, so they may be unable to use the same encryption methods as a traditional computer does, but that is no excuse for the lack of strong encryption. There are efficient cryptographic methods designed for small scale devices, such as Elliptic Curve Cryptography (ECC), which can be used.”

In its report, Symantec covers the obvious points of vulnerability, such as communications between the home and the cloud, but the white paper goes granular when discussing home automation devices, where “security” goes beyond encryption.

As an example: “For IoT devices such as smoke alarms, it is also crucial that the vendor has considered what happens when there is a power outage or the network gets jammed. Will the user be notified or will the malfunctioning safety device go unnoticed?”

Bitter Exes, Pranksters and Other Potential IoT Security Threats

In its white paper, Symantec covers potential attacks over local Wi-Fi/Ethernet networks, cloud infrastructures and more. But one section I find particularly interesting addresses vulnerabilities at home when someone has physical access to the owner’s devices, settings and apps.

“An attacker can gain the highest level of access to the smart home device if they get physical access to it,” according to Symantec. “Although this might seem like an improbable attack vector, it is still a plausible threat.”

To me it seems this area is overlooked by 1) manufacturers in their product designs and best practices, 2) consumers in their complacence and 3) dealers in their failure to design systems and advise customers with these threats in mind.

Symantec lays out these scenarios, which are not unreasonable:

• Your friends could gain physical access to your IoT device to play a prank while visiting you.
• An ex-boyfriend or girlfriend could attempt to reconfigure some of the devices while they still have access to the home.
• For some devices, such as security camera, an attacker could simply cut the cables to turn them off.
• Some users might buy a used device off the Internet, but could end up with a device that has been compromised to spy on people.
• In a supply-chain hack, attackers can compromise a supplier company’s network and “Trojanize” their software updates, threatening the spread of the poisoned update to any device in the chain.

 “Unfortunately,” warns Symantec, “there is currently no easy way to verify that an IoT device has not been tampered with.”

The company further warns that having physical access to connected devices allows an attacker to alter configuration settings: “These could include issuing a new device pairing request, resetting the device to factory settings and configuring a new password, or installing custom SSL certificates and redirecting traffic to a server controlled by the attacker.”

Now here Symantec goes into some pretty paranoid terrain, but still not too far-fetched in higher-end homes and enterprises that have a whole lot of people coming and going:  

Physical access may also allow a skilled attacker to read the device’s internal memory and its firmware. They could do this by accessing programmatic interfaces left on the circuit board, such as JTAG and RS232 serial connectors. Some microcontrollers may have disabled these interfaces, but could still allow direct reads from the attached memory chips if the attacker solders on new connection pins.

Reading the internal memory and reversing the firmware allows an attacker to better understand how a device works, allowing them to find vulnerabilities, cryptographic key materials, back doors, or design flaws that could be used to perform further attacks.

If the attacker gains a full understanding of the firmware, they could use this knowledge to create their own malicious version of the firmware and upload it to the device. This could give the attacker full control over the device. This act of re-flashing the device may be conducted through the JTAG or RS232 connection.

Most new devices offer ways for users to update the firmware throughout the lifecycle of the device. These updates could arrive through a USB connection, an SD card, or over the network. The majority of tested devices did not use encrypted nor digitally signed their firmware updates, making it easy for an attacker to generate a valid, malicious firmware update that could be installed.

In the end, Symantec advises:

• Any code that is run on a smart device, be it the firmware or application, should be verified through a chain of trust.
• Protecting the code and securing the device creates a trusted baseline.
• Vendors should provide a simple and automated way for users to update their device in order to ensure that common security issues can be fixed quickly and efficiently.
• IoT devices should only accept signed firmware as standard.
• Where applicable, security analytics features should be provided in the overall device management strategy.
• Cloud control interfaces present another weak point of many IoT. Users should not be forced to use cloud setups if all they want to do is to do basic tasks such as turning on the lights in their homes.
• And more …

Also included in the white paper is a list of best practices for both users/installers, as well as manufacturers building connected devices.

Read the white paper here (pdf).

• Page 1