Imagine a fast moving bot attack designed to stop its victim from functioning.
Called Permanent Denial-of-Service, PDoS is an attack that damages a system so badly that it requires replacement or reinstallation. By exploiting security flaws or misconfigurations, PDoS can destroy the firmware and/or basic functions of a system permanently.
It is a contrast to its well-known cousin, the DDoS attack, which overloads systems with requests meant to saturate resources through unintended usage but generally the functioning of the system is restored to normal as soon as the DDoS attack stops.
Discovery
On the week of the 10th April, we identified a new form of PDoS attack – which we dubbed ‘BrickerBot’ – through our honeypots. Over a four-day period, Radware’s honeypots recorded 1,895 PDoS attempts performed from several locations around the world.
The honeypot that identified the BrickerBot attacks is a custom developed piece of software that makes conversations with bots. It does not execute any commands, it simply replies to any received commands with what the bot expects to see as an output. That way it is completely safe and can be quickly adapted to emulate any environment or response that bots expect. So in many ways, it’s like a chatterbot for IoT bots – talk about fighting fire with fire!
Analysis
Unlike Mirai, which aimed to exploit insecure IoT devices and recruit them into a botnet army, BrickerBot’s sole purpose is to compromise IoT devices and corrupt their storage.
[easy-tweet tweet=”The BrickerBot attack used Telnet brute force to breach a victim’s devices” hashtags=”BrickerBot,IoT”]
Besides this intense, short-lived bot (BrickerBot.1), Radware’s honeypot recorded attempts from a second, very similar bot (BrickerBot.2) which started PDoS attempts on the same day with lower intensity but more thorough and its location(s) concealed by TOR exit nodes.
The BrickerBot attack used Telnet brute force – the same exploit vector used by Mirai – to breach a victim’s devices. Upon successful access to the device, the bot performed a series of Linux commands that could ultimately lead to corrupted storage, followed by commands to disrupt Internet connectivity, device performance, and the wiping of all files on the device.
While I do not believe a lot of servers will be vulnerable to the attack – most servers are installed with best practices for securing access and telnet is not enabled by default in recent Linux installs – what I am concerned about is the amount of IoT devices that may be vulnerable, as has been proven by the Mirai botnet.
Damage
BrickerBot is not damaging the storage inside the devices it attacks – they are still useable after reformatting. It is attempting to corrupt the information on the storage and its partition table (the layout of the file systems on the storage card). If the device has field replaceable flash storage, the device can be recovered through ordering a new flash card with pre-installed software image and replacing it. If the device has a USB port and the manufacturer provides a procedure to boot and reformat and repartition the storage and flash the cards from a USB mounted the image, that might be enough to recover a device.
Needless to say that this process is time-consuming and not a basic task that can be performed without a serial connection or special recovery sequences built into the device. The bot will not damage the device in such a way that it is not recoverable. But we still refer to it as a PDOS attack because even after the attack is over, the damage persists and intervention is required to get the devices back in an operational state.
Author(s)
Right now, the motives and author(s) behind BrickerBot are unclear. Some theories have emerged, but we have no supporting evidence to favour one theory above another. The bot leaves a very limited trace, only a set of commands that proves the purpose is to corrupt and break unsecured Linux devices that are directly exposed to the Internet through their telnet service and use factory default credentials.
- So who could be the author(s) behind BrickerBot? It could be that the author wants to get back at the IoT industry: imagine the number of support calls and RMA manufacturers could receive if the attack is successful.
- It could be a grey hat that is punishing careless users and manufacturers of unsecured IoT devices, forcing them to upgrade their software and reconfigure their devices with hopefully more recent and less vulnerable images and parameters, eventually solving the IoT problem – but in a very unethical way.
- It might be a hacker that had his botnet compromised by security researchers and is now trying to get revenge through breaking their honeypots – although less likely because to do so the hacker should have extensive analytics on the connections and infection attempts combined with C&C connections to be able to find potential honeypots in a large list of victims ; or he doesn’t care and turned his back for good to the IoT botnet industry and tries to break whatever smells like an IoT device or honeypot.
Securing the network
While the first PDoS attacks from BrickerBot.1 have stopped, the attacks from BrickerBot.2 are still active and on-going.
My advice to businesses worried about their IoT devices is:
- Check and upgrade the software of your devices as often as possible
- Change the device’s factory default credentials, look further than the web based GUI and check for CLI access – manuals and getting-started notes might not always reveal the existence of a CLI access, therefore check the forums of your device manufacturer for CLI, telnet, SSH and default credentials
- Disable Telnet access to the device, if CLI access is required, SSH is a better option – if no CLI access is required, disable both of them
- Network Behavioural Analysis can detect anomalies in traffic and combined with automatic signature generation provides protection against 0day network exploits
- User and Entity Behaviour Analytics (UEBA) can spot granular anomalies in traffic early.