Bricker Bot – A Silver Lining to Force Accountability for IoT Security?

The Bricker bot made the news a couple of weeks ago as being responsible 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 the 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 whatever might please the threat actor behind it.

While the Bricker bot may not be a worm with mass adoption yet, it could be a precursor of things to come. It has all the early indications of being potentially very dangerous (even more than it is today) as it gains more mass 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 together 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 ability of IoT devices to connect to the internet. Highlighting the vulnerability of IoT devices is the alleged reason why the author of the Bricker bot is doing what he is doing. The argument goes, if vendors are not keen about making sure that 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 pretty 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 couple of 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.

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

Figure 2. Yearly data on attempted breaches per country

Other applications of such an attack are very likely. Imagine receiving a message from an attacker that says, “pay 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:  

The purported reason behind what the author of Bricker is trying to achieve, as per his own words (taken from a hacker forum – identity to be confirmed) is to force a change in the security of IoT, which security experts have known for a long 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, and constant reuse of insecure code across and between vendors of completely different devices. This goes back to our 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.

The problem with the Bricker approach, besides the fact that it illegally causes damage, is that such an attack can easily be twisted to be even more disruptive. Perhaps even opening up an entire new lucrative threat landscape where the devices we rely on can be held for ransom.

Right now, the ones who are suffering are the individuals and carriers that use these insecure products. But soon enough, this trend is likely 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.

FortiGuard Protections

Since this attack is carried out after brute forcing credentials against telnet and SSH servers, our FortiGuard IPS engine has been able to identify and stop this attack since its inception. Here are the IPS signatures used to identify and stop a brute force attack:

SSH.Connection.Brute.Force

Telnet .Connection.Brute.Force

Also, if the device still needs to be accessed from the internet via SSH, make sure that it is restricted to a few IP addresses, and that all attempts are logged.

Network behavior analysis, as offered through FortiSIEM, can also be leveraged to identify potentially malicious activity related to this attack.