Update to ‘BrickerBot’ Attack
Thursday, April 20, 2017 @ 02:04 PM gHale
There is an update to the open-source reports of “BrickerBot” attacks, which exploit hard-coded passwords in IoT devices in order to cause a permanent denial of service (PDoS), according to ICS-CERT.
This family of botnets, which consists of BrickerBot.1 and BrickerBot.2, ended up described in a Radware Attack Report (‘BrickerBot’ Results In PDoS Attack).
ICS-CERT is working to identify vendors of affected IoT devices in order to collect product-specific mitigations and compensating controls. ICS-CERT issuing an alert to provide early notice of the report and identify baseline mitigations for reducing risks to these and other cybersecurity attacks.
The design of this bot attack is to render a connected device useless by causing a PDoS, or “bricked” state, according to Radware. BrickerBot.1 and BrickerBot.2 exploit hard-coded passwords, exposed SSH, and brute force Telnet.
According to Radware’s Attack Report and open source reporting, the following details regarding BrickerBot.1 and BrickerBot.2 are available:
• BrickerBot.1 targets devices running BusyBox with an exposed Telnet command window. These devices also have SSH exposed through an older version of Dropbear SSH server. Most of these devices were also identified as Ubquiti network devices running outdated firmware. Some of these devices are access points or bridges with beam directivity. BrickerBot.1 was active from March 20 to March 25. According to Radware, BrickerBot.1 attacks have ceased.
• BrickerBot.2 targets Linux-based devices which may or may not run BusyBox and which expose a Telnet service protected by default or hard-coded passwords. The source of the attacks is concealed by TOR exit nodes.
• No information is available at this time about the type and number of devices used in performing these attacks.
ICS-CERT is working to identify vendors of affected devices in order to collect more detailed mitigation information.
Radware recommended taking the following precautions:
• Change the device’s factory default credentials
• Disable Telnet access to the device
• Use network behavioral analysis to detect anomalies in traffic and combine with automatic signature generation for protection
• Set intrusion protection systems to block Telnet default credentials or reset telnet connections. Use a signature to detect the provided command sequences
• Update your Ubiquiti Networks devices with the latest firmware
Leave a Reply
You must be logged in to post a comment.