Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
10/15/2019
10:00 AM
Marc Laliberte
Marc Laliberte
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Why Bricking Vulnerable IoT Devices Comes with Unintended Consequences

Infosec vigilantism can cause serious harm in the era of industrial IoT and connected medical devices.

For several years now, security experts have been trying to bring attention to the growing threat that insecure Internet of Things (IoT) devices pose to networks around the world. The enormous growth in popular connected devices like webcams, DVRs, and smart watches has made it possible for hackers to amass huge botnets that can launch devastating distributed denial-of-service (DDoS) attacks.

Unfortunately, some vigilante hackers have tried to solve this problem with "bricker" malware that infects and destroys insecure IoT devices before they can become part of a botnet. This might seem like a positive on the surface, but this tactic creates serious, sometimes life-threatening risks as more IoT devices are used in industrial networks and healthcare organizations.

Let's start at the beginning. IoT security became a top-of-mind issue in late 2016 thanks to the record-breaking DDoS attacks by the Mirai botnet and its subsequent source code release. In a perfect world, this should have been the wake-up call to improve IoT security. Unfortunately, slim profit margins and rapid development times kept IoT security considerations on the back burner and led some individuals to take matters into their own hands. The first instance of IoT vigilantism was in 2017 when a strain of malware known as BrickerBot began making its rounds.

Similar to the Mirai botnet, BrickerBot exploited flaws like insecure, hard-coded passphrases to log in to vulnerable IoT devices. But once it connected to a device, it didn't add it to a massive botnet. Instead, it deleted files, corrupted the system storage, and disconnected the device from the Internet, effectively making it unusable. While it is possible to restore the device to factory defaults, the average IoT user likely doesn't have the technical skills to do this. The author of BrickerBot, known by the pseudonym Janit0r, explained in an interview that his malware was intended to prevent devices from being infected by Mirai. Janit0r believed that if IoT manufacturers and owners weren't going to take security seriously, then the devices shouldn't exist to begin with.

In the end, BrickerBot destroyed over 10 million devices in just nine months before Janit0r retired it from service. While that may sound like a lot, it's still less than one-tenth of 1% of the estimated 14 billion IoT devices online worldwide.

But the end of BrickerBot wasn't the end of IoT bricking malware. In early 2019, a new variant of IoT bricking malware called Silex began infecting devices worldwide. Within a few hours, Silex had infected thousands of devices, deleting system file and firewall rules, and effectively rendering them useless. With the Mirai source code public, it's not a stretch to think there are other similar malware variants lurking undiscovered in the wild today. Thankfully, individual IoT owners can also protect themselves from both botnets and brickers by changing the default passwords on their IoT devices, not exposing the telnet port (which BrickerBot uses to infect devices) and performing basic network segmentation and monitoring.

Bricker malware is dangerous because it doesn't discriminate between different types of IoT devices. Almost every industry is incorporating IoT technology in some way. "Smart city" technology is becoming widely adopted across the globe, with municipalities connecting everything from power grids to traffic lights to networks. Healthcare is another sector that's quickly adopting IoT technology, with the Internet of Medical Things projected to reach $136.8 billion worldwide by 2021. While some might question the need for refrigerators to connect to the Internet, there is no arguing that the ability to quickly share data from an ECG/EKG machine could be the difference between life and death. As widespread IoT adoption continues to grow within these sectors and overall, bricking malware can have some devastating consequences.

The problem is that many of these new IoT applications exhibit the same security lapses as consumer IoT devices, but with significantly higher risks if they fail. A rash of bricked industrial IoT sensors could cause widespread power outages, and an infusion pump or medical monitor that unexpectedly shuts off could put patients' lives at risk. The authors of BrickerBot and Silex might not have been so ready to claim their work was for the good of the Internet if they truly considered the serious collateral damage that they might cause along the way.

There are other options to improve IoT security that don't involve such a high degree of risk. Security researchers can work on raising awareness about connected device security, participating in public education initiatives and trying to drum up consumer demand for secure devices. Just last year the state of California, the fifth-largest economy in the world by GDP compared with other sovereign nations, passed Senate Bill 327, which mandates that manufacturers of connected devices equip their products with reasonable security features by January 2020. While the bill will have little effect on the masses of inexpensive IoT devices imported from foreign countries every year, it's a step in the right direction that can be built upon with future legislation.

There is no denying the IoT industry needs to fundamentally change its approach to security, but vigilantism is not the answer. There are less destructive ways to convince both manufacturers and consumers that developing and deploying secure devices is worth the investment.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Works of Art: Cybersecurity Inspires 6 Winning Ideas"

Marc Laliberte is a senior security analyst at WatchGuard Technologies. Specializing in networking security protocols and Internet of Things technologies, Marc's day-to-day responsibilities include researching and reporting on the latest information security threats and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: -when I told you that our cyber-defense was from another age
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-3349
PUBLISHED: 2019-11-19
lightdm before 0.9.6 writes in .dmrc and Xauthority files using root permissions while the files are in user controlled folders. A local user can overwrite root-owned files via a symlink, which can allow possible privilege escalation.
CVE-2019-10080
PUBLISHED: 2019-11-19
The XMLFileLookupService in NiFi versions 1.3.0 to 1.9.2 allowed trusted users to inadvertently configure a potentially malicious XML file. The XML file has the ability to make external calls to services (via XXE) and reveal information such as the versions of Java, Jersey, and Apache that the NiFI ...
CVE-2019-10083
PUBLISHED: 2019-11-19
When updating a Process Group via the API in NiFi versions 1.3.0 to 1.9.2, the response to the request includes all of its contents (at the top most level, not recursively). The response included details about processors and controller services which the user may not have had read access to.
CVE-2019-12421
PUBLISHED: 2019-11-19
When using an authentication mechanism other than PKI, when the user clicks Log Out in NiFi versions 1.0.0 to 1.9.2, NiFi invalidates the authentication token on the client side but not on the server side. This permits the user's client-side token to be used for up to 12 hours after logging out to m...
CVE-2019-19126
PUBLISHED: 2019-11-19
On the x86-64 architecture, the GNU C Library (aka glibc) before 2.31 fails to ignore the LD_PREFER_MAP_32BIT_EXEC environment variable during program execution after a security transition, allowing local attackers to restrict the possible mapping addresses for loaded libraries and thus bypass ASLR ...