Problem solve Get help with specific problems with your technologies, process and projects.

Bricker bot: A silver lining to force accountability for IoT security?

The Bricker bot made the news a couple of weeks ago for knocking unsecured IoT devices offline rather than hijacking them into other botnets and using them for a DDoS attack like the massive event we saw last year against DYN. This is the third botnet that targets insecure IoT devices, but the only one that is destructive. The second, dubbed Hajime, breaks into IoT devices, but instead of bricking them, it makes them more secure by disabling remote access to the device from the internet. Of course, Mirai was the first, but it has the same purpose as other botnets, which is to enslave IoT devices and use the computing power of its collection of bots for the purposes of the threat actor behind it.

While the Bricker bot may not yet be a worm with mass adoption, it could be a precursor of things to come. It has all the early indications of potentially being very dangerous (even more than it is today) as it gains greater appeal.

There are millions of unsecured devices just waiting for someone to hijack them, with hundreds of thousands more of them coming online every single day. Because so many of these devices have little to no security, they pose a serious risk to the digital economy. As we have seen, because of their pervasive deployment, marshaling them to engage in attacks like the massive DDoS attack last fall would almost certainly bring a considerable segment of the internet to a grinding halt, disrupting business, affecting services and potentially impacting critical infrastructure.

The Bricker bot is different, as it simply disables the internet connectivity of IoT devices. The alleged reason for the Bricker bot, according to its author, is to highlight the vulnerability of IoT devices. The argument goes that if vendors are not keen about making sure they ship devices that are secure by default, and if the owners aren’t concerned about security either, then it is just a matter of time before these devices are breached and become part of a botnet. So, to warn the market about this problem, the Bricker bot author chose to simply knock them offline.

More info about Bricker

The Bricker bot is fairly straightforward. It functions through a couple of TOR exit nodes, continuously scanning the internet for open telnet and SSH devices — more specifically, the “DropBear” version of SSH, which usually ships with “tiny” Linux distros that have what is called a busybox (a couple of Unix-like utilities for embedded Linux distributions).

When it finds such a service, it tries a brute force attack by sweeping for the known passwords that are usually the default password on these devices — oftentimes hardcoded directly into the device. Once the worm gains access, it performs a few crippling commands on the box in order to make it impossible for it to become operational — ever again, in some cases. Even though it is very simple, it is currently able to identify and destroy more than 80 types of devices. This new form of attack even has its own name now: “permanent denial of service” or PDoS.

santos-bricker-attacks

Figure 1: March – April of 2017 we saw a significant increase in the number of attempted brute force attacks targeted against Telnet/SSH

Other applications of such an attack are very likely. Imagine receiving a message from an attacker that says, “Pay us or we will permanently kill your TV (gaming system, printer, router, smart appliance, internet service or other connected device) permanently.” This sort of ransomware attack could easily be performed instead of simply bricking the device.

Context

santos-bricker-breaches

Figure 2: Yearly data on attempted breaches per country

The purported reason behind Bricker, per the author’s own words (taken from a hacker forum — identity to be confirmed), is to force a change in the security of IoT devices, which security experts have known for a long time were almost as insecure as leaving your front door open.

This lapse in security encompasses everything, from weak hard-coded passwords to lack of testing for security issues to poor implementation of the networking stack to constant reuse of insecure code across and between vendors of completely different devices. This goes back to Fortinet’s predictions for 2017 that vendors need to accept responsibility for the security of their products, especially as they are becoming more ubiquitous in our lives and the infrastructure that we rely on.

Right now, the ones who are suffering are the individuals and carriers that use these insecure products. But soon enough, this trend is likely to piggyback onto the vendors selling devices built around junk code. And maybe it will be enough to force them to start thinking a little more about security and not just profiteering.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Well nothing new to be heard of. A recent study found 80 percent of Internet of Things apps aren't tested for vulnerabilities and there is still a lack of urgency to address the risk.

The “2017 Study on Mobile and IoT Application Security”, conducted by the Ponemon Institute and sponsored by IBM and Arxan Technologies surveyed 593 IT and IT security practitioners to explore how companies are unprepared for risks created by vulnerabilities in IoT apps.

Proactive testing, fixing vulnerabilities and binary code as well as cryptographic key protection are some of the ways that companies can mitigate the risks and better secure IoT devices and while companies may go through the software development lifecycle with security in mind, once they throw those out in the wild on end point devices or mobile, binary code and cryptographic keys are vulnerable and easy for hackers to attack. Came across this nice article on IoT which is a must rea for everyone concerned with IoT security.

https://www.purevpn.com/blog/four-areas-of-security-vulnerabilities/

Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close