BrickerBot – The Dark Knight of IoT
Over the course of the last week, you have probably heard about the attacks designed to render Internet of Things (IoT) devices across the internet useless. We called the originator of the attacks “Brickerbot,” but should we have called it the “Batman of IoT”?
Permanent Denial of Service
PDoS is an attack that damages a system so badly that it requires replacement or reinstallation of its factory default software image. By exploiting security flaws or misconfigurations, this type of cyber-attack can destroy the firmware and/or basic functions of system usage. Recall the purpose of DDoS attacks, which overload their victim with requests up to the point they cannot perform their intended function anymore. When the attacks stop, however, the victim resumes its intended function as if nothing happened. PDoS, in contrast to DDoS, is more permanent. The attack is very short, but it leaves the device in such a state that it is not able to perform its intended function, even after the attack is terminated. After a PDoS, a device requires an on-site, manual intervention to recover it and restore its normal functioning.
Some PDoS are more severe than others. Recall the USB stick that discharges 200 volts into the host computer and fries it. Or the demonstrations at EUSecWest back in June 2008 about how corrupted hardware could be delivered to flash a device and make it unusable, referred to as phlashing.
[You might also like: IoT Threats: Whose problem is it?]
BrickerBot
The PDoS attempts we discovered and discussed in our ERT Alert last week are performed remotely, through telnet access, and using commands that could ultimately corrupt storage, break connectivity and render the device unfunctional. The PDoS in question is targeting software rather than flashing or frying the hardware of its victims, which does however not make it less permanent, less damaging and less impacting. The discovered attacks were using the same exploit vector as Mirai, brute forcing their way in through Telnet. We coined it ‘BrickerBot’ because instead of enslaving IoT devices, like Mirai does, it attempts to destroy or “brick” them.
BrickerBot.1: Over a four-day period, from March 20th through 25th, our honeypots recorded 1,895 PDoS attempts performed by a limited number of devices around the world. Tracing back the origin of the attacks, we discovered the use of outdated wireless access points and directive beam devices to perform the assault. There was no immediate indication of who might be the author of the attacks as there was no correlation between the location of the devices, besides them all running an older version of the Dropbear SSH server. After March 25th, 1.22am CET, the BrickerBot.1 attacks were gone and never showed up in our honeypots again.
BrickerBot.2: Our honeypots recorded a series of very similar attempts that started within the same hour of BrickerBot.1, but were less intense. From March 20th till April 10th, a bot or a network of bots that operate from the Dark Web and are concealing itself behind TOR exit nodes were performing PDoS attempts nearly every 2 hours. Since April 10th, the frequency has dropped to about 1 attempt per day.
Who is being targeted?
The use of the ‘Busybox’ command combined with the MTD and MMC special devices means this attack is targeted specifically at Linux/BusyBox-based Internet of Things (IoT) devices. The similar exploit vector as Mirai means the devices must have their Telnet port open and exposed publically on the Internet. Mostly this would match IoT devices that have been proven vulnerable to Mirai.
Because the process does not perform malware infection, but has a clear purpose of corrupting and disabling the device, there is no binary to study and there is not much we can say about how the bot finds its targets. Because BrickerBot.2 is hiding itself behind TOR exit nodes, there is no indication on the location of the bots or even how many bots might be out there. We could assume a random public IP scan to detect potential victims much like Mirai bots are performing. However, because there is no infection, the thread is not becoming larger and growing exponentially as with Mirai – so there must be a botnet harvested in a different way or a set of VPS owned by the author on the Dark Net that perform these attacks.
The Brick Test
Being convinced about the impact the commands would have on certain devices, there was still the question of how it would perform in the real world and how much a device like an IP cam would be left unrecoverable. Not the nicest task to volunteer for, but my good friend and colleague Ron stepped up in the name of science and volunteered his Sricam AP003 Metal Gun Type Waterproof Outdoor Bullet IP camera for the experiment. The camera is known to be supported by Mirai and represents the common class of devices that get enslaved by hackers for their large IoT botnets.
[You might also like: The Expansion of IoT since Mirai.]
Upon running the sequence of commands from BrickerBot.1, the camera got disconnected from the network and upon reboot was not responding anymore. Last hope was to perform a factory reset – there is a button for that purpose on the camera according to the manual. Unfortunately, even after performing the factory reset, the camera was not recovered and hence it was effectively bricked. Sorry Ron, thank you for giving up your IP cam! I owe you one (literally)!
Why?
This is the biggest mystery surrounding BrickerBot! Why would someone destroy IoT devices without benefiting from them? Unfortunately, right now there is no clear answer. When we discovered BrickerBot, at first we believed it was a drastic attempt to destroy existing and stop new IoT botnets, basically calling a halt to the growing IoT DDoS threat. But after some reflection it became clear that there might be benefiting conditions, such as hackers who are attempting to take out competition by targeting attacks to specific devices. Would this be a war of DDoS-for-hire suppliers fought on the Deep Web?
Upon discovery of the second BrickerBot the theory slightly changed, as the second one is not using the typical ‘Busybox’ command and which could indicate a hacker trying to target and compromise honeypots or sandboxes based on actual Linux images and performing and auditing or tracing commands. The question then rises how a list of potential honeypots could be obtained. Also, this would not affect purpose-built honeypots like ours, which is more of a chatterbot for IoT bots which does not actually execute commands.
Then again, throughout the whole thought process I could not keep away from the idea that there might be a vigilante at work. Someone who had enough of the threats and attacks, who wants the security issues posed by IoT devices eradicated and to punish the owners and manufacturers in the process. Ethically speaking, we can only condemn this behavior, but I keep thinking of the words from Commissioner Jim Gordon in the movie “Batman: The Dark Knight”:
“Because he’s the hero Gotham deserves, but not the one it needs right now. So we’ll hunt him. Because he can take it. Because he’s not our hero. He’s a silent guardian, a watchful protector. A dark knight.”
