Search Results for: IoT security

Written by Paul Karazuba, head of product, Rambus Security

Passed by former California governor Jerry Brown, cybersecurity law SB-327 is slated to go into effect on January 1, 2020. This proactive legislation requires manufacturers to equip IoT devices with “reasonable” security features to prevent unauthorized access, modification and data leaks. Specifically, SB-327 requires manufacturers to implement a unique preprogrammed (default) password for each device. Additionally, manufacturers must ensure that users create a new password the first time a device is activated. Together, these steps are expected to help protect California consumers, as hackers are known to routinely target vulnerable devices shipped with generic or default login credentials.

From our perspective, SB-327 is clearly long overdue. Indeed, unprotected IoT devices continue to pose a threat to both consumer privacy and security across the country. For example, a Ring camera installed in the Memphis bedroom of a young girl was recently hijacked by a hacker who seized control of the device to spy on the 8-year-old, taunt her with music and encourage destructive behavior. Another instance of a Ring camera falling victim to a hacker was reported in December by a Houston family who heard an eerily disembodied voice ask if “anyone [was] home” and promised it was “gonna find out.”

According to various reports, the recent spate of Ring hacks likely involved basic attack techniques such as credential stuffing. This simple process involves accessing accounts with stolen account credentials and large-scale automated login requests. Consequently, Ring users who don’t enable the optional two-step authentication skip setting a unique password or recycle credentials across multiple online services, and are at a greater risk of being hacked. To be sure, malicious hackers have coded dedicated software for breaking into Ring security cameras. Beyond Ring cameras, a wide range of vulnerable consumer IoT devices are frequently targeted by hackers who actively search for devices with default or weak login credentials such as “admin” usernames and “1234” passwords.

Although SB-327 sets an important precedent by requiring a unique preprogrammed (default) password for each IoT device, we believe much more needs to be done to secure connected devices. Security starts at the hardware level, and it should begin on day one of product design. Device designers need to prioritize security as a primary design goal of a connected device; not an afterthought, and certainly not lip service. A solid start to security is basing the foundation of your security in silicon; specifically, a siloed security co-processor capable of executing all security-centric processes completely independently of the main CPU.

Our CryptoManager Root of Trust is an ideal implementation. While located on the same chip as the main CPU, its physical separation and 7 layers of hardware security ensure that secure processes remain exactly that – secure. The root of trust can better help protect consumers by enabling robust remote access authentication and monitoring of anomalous system activity. This siloed approach to security ensures that a potential compromise of the main processor does not expose critical keys and credentials – or impair the execution of security applications that monitor system operation and detect tampering.

Cybersecurity law SB-327 is a good start for California consumers, although far more needs to be done to comprehensively protect IoT devices. Implementing a unique preprogrammed (default) password for each device and requiring users to create a new password can help prevent basic attacks, although a siloed security co-processor is necessary to thwart determined adversaries and complex hacking techniques.

 

Additional Resource:
California’s IoT Law Is A Good Start, But More Needs To Be Done

Earlier this summer, a new strain of destructive malware known as Silex began to spread and effectively brick IoT devices. As ZDNet’s Catalin Cimpanu reports, Silex victims can resurrect their devices by manually reinstalling firmware. However, most device owners typically consider the re-installation process to be overly complicated and time consuming.

“Silex works by trashing an IoT device’s storage, dropping firewall rules, removing the network configuration, and then halting the device,” writes Cimpanu. “It’s as destructive as it can get without actually frying the IoT device’s circuits. It’s expected that some owners will most likely throw devices away, thinking they’ve had a hardware failure without knowing that they’ve been hit by malware.”

Akamai researcher Larry Cashdollar, who first identified the malware in late June, tells ZDNet that Silex exploits known default credentials for IoT devices to log in and kill the system. More specifically, the malware strain writes random data from /dev/random to any mounted storage it finds. Subsequently, Silex deletes network configurations, runs rm -rf / to delete any remaining data, flushes all iptables entries, and adds an entry todrop all connections.

Ben Levine, a Senior Director of Security Product Managementat Rambus, tells Rambus Press that Silex is one of multiple malware strains that actively seeks out devices with default or weak login credentials such as “admin” usernames and “1234” passwords.

“Essentially, Silex exploits unprotected system functions to brick IoT devices,” he explains. “However, it is important to understand that a hardware-based root of trust can help protect against malware like Silex by ensuring robust remote access authentication and monitoring anomalous system operation.”

A hardware-based root of trust, says Levine, can be implemented as an independent security co-processor that is integrated into IoT devices. Put simply, a hardware-based root of trust allows execution of security applications, provides tamper detection and protection, and enables secure storage and handling of keys and security assets.

“An independent hardware-based root of trust offers chipmakers a siloed approach to security. Although it is typically placed on the same silicon as the main processor, the secure processing core is physically separated,” Levine elaborates. “This means that compromise of the main processor does not expose critical keys and credentials – or impair the execution of security applications that can monitor system operation and detect tampering. The root of trust can continue to provide security functionality – even if the attacker gains access to the device.”

A hardware-based root of trust can also implement strong authentication for remote access to a device, avoiding reliance on simple credentials that are often left in a default state.

“A hardware-based root of trust can be used to provide secure and flexible control over who and what can access a device. Different entities can be given different amounts of access based on how much they are trusted, and all of this can be enforced in hardware,” he concludes.