BrickerBot.3: The Janit0r is back, with a vengeance

In early April, we identified a new botnet designed to comprise IoT devices and corrupt their storage. Over a four-day period, our honeypots recorded 1,895 PDoS attempts performed from several locations around the world. Its sole purpose was to compromise IoT devices and corrupt their storage. Besides this intense, short-lived bot (BrickerBot.1), our honeypots recorded attempts from a second, very similar bot (BrickerBot.2) which started PDoS attempts on the same date – both bots were discovered less than one hour apart –with lower intensity but more thorough and its location(s) concealed by TOR egress nodes.

Yesterday we discovered a new version of the BrickerBot PDoS attack (BrickerBot.3) with a new command sequence on a different honeypot location. 1 hour after finalizing the report on the first 12h of BrickerBot.3 the article on the potential author of BrickerBot and the comments by this author were published by Catalin Cimpany on his blog.

The new PDoS attempt sequence, for which we named the bots that are responsible for performing the attacks BrickerBot.3, is the following:

For reference, the BrickerBot.1 command sequence:

Compared with the original BrickerBot.1, the sequence of commands is very similar. It does not start with fdisk – but goes straight to business. The first six block devices it tries to corrupt (up to and including /dev/ram0) correspond with the BrickerBot.1 attack. The devices mtd0,1 and mtdblock1,2,3 are new for the Busybox version of BrickerBot. The fdisk commands to try to change the geometry of the block devices are identical to what BrickerBot.1 attempted. The end sequence again tries to disrupt connectivity by removing the default route and disabling TCP timestamps, wiping the root and limiting the number of kernel threats to one. The fork bomb, which was signature for BrickerBot.2 is not present.

The first 12 hours

During the first 12 hours of the attack, a total of 1,118 PDoS attempts were recorded. The attacks all originated from a limited number of clear net IP addresses. ZoomEye and Shodan searches based on the source IPs of the attacks revealed all of them running an outdated version of the Dropbear SSH server (SSH-2.0-dropbear_0.51, SSH-2.0-dropbear_2013.58, and SSH-2.0-dropbear_2014.63).

[You might also like: The Expansion of IoT since Mirai.]

The attacks started at 12:00 GMT on April 21^st and in its first 12 hours, the number of bots performing the attacks grew up to 15 – the bot growth timeline is depicted in the graph below:

The devices used to perform the PDoS attacks on our honeypot do not correspond to the devices from BrickerBot.1. Although BrickerBot.1 was also abusing a limited number of clear net connected devices to perform its attack, there is no immediate correlation between both. For complete disclosure and transparency, the attacks were detected by a different honeypot than the one that detected the BrickerBot.1 and BrickerBot.2 attacks.

The devices that perform the attack are spread around the globe and do not concentrate in a specific region and do not correlate to the locations of the BrickerBot.1 sources.

Here is the geographic distribution of devices used by BrickerBot.2 to perform the attacks:

Exploit vector like Mirai

In line with BrickerBot.1 and BrickerBot.2, this bot is also using the Mirai exploit vector to compromise the target. Any ‘Busybox’-based Linux device that has telnet exposed publically and has factory default credentials unchanged are a potential victim.

BrickerBot.4

Between 5:22pm and 8:44pm GMT the same honeypot also detected yet another, very similar sequence of commands. The attack was only attempted from a single device which was located on the clear net and upon investigation also had an outdated version of the Dropbear SSH server (SSH-2.0-dropbear_2014.63). This isolated bot performed 90 attacks and was not seen again between 8:44pm and midnight.

The BrickerBot.4 command sequence has a few less block devices it tries to corrupt, as compared to BrickerBot.3:

[You might also like: 5 Recommendations for IoT Manufacturers]

Rob the Janit0r

A few hours after finalizing this report, Catalin Cimpanu published his article on the author of BrickerBot. A person who went by the name of “Janit0r” on Hackerforums alluded to being the author of BrickerBot on April 14^th.

The Janit0r reached out to Victor Gevers based on a comment Victor made in one of the first articles on BrickerBot.1 and .2. The person confirmed he is the Janit0r on Hackforums and he is the author of BrickerBot.

The Janit0r:

Like so many others I was dismayed by the indiscriminate DDoS attacks by IoT botnets in 2016. I thought for sure that the large attacks would force the industry to finally get its act together, but after a few months of record-breaking attacks it became obvious that in spite of all the sincere efforts the problem couldn’t be solved quickly enough by conventional means.

Based on the Janit0r’s discussion, BrickerBot is more complex and most probably much larger than we initially believed it to be.

The Janit0r:

I consider my project a form of “Internet Chemotherapy” I sometimes jokingly think of myself as The Doctor. Chemotherapy is a harsh treatment that nobody in their right mind would administer to a healthy patient, but the Internet was becoming seriously ill in Q3 and Q4/2016 and the moderate remedies were ineffective.

For the time being, it does not seem like the Janit0r will stop BrickerBot attacks, or at least not until officials and hardware vendors take definitive action to improve the state of IoT security.

The Potential Damage

BrickerBot.3 and BrickerBot.4, like BrickerBot.1, are targeting ‘Busybox’-based Linux devices, typically IoT devices such as IP camera’s and DVRs. As mentioned in our BrickerBot blog from April 13^th, we put the BrickerBot.1 command sequence to the test and assessed its impact on a real life device. The device in question was a Sricam AP003 Metal Gun Type Waterproof Outdoor Bullet IP camera, which is known to be ‘supported’ by Mirai. Although the know invokes thoughts of robustness, upon running the sequence of commands from BrickerBot.1, the camera got disconnected from the network and upon reboot was not responding anymore. Factory reset though a special button on the camera did not recover the IoT device. It was effectively bricked!

Protecting your IoT Devices

It is not possible to assess how widely spread the attacks are, but the potential damage BrickerBot.3 can cause poses a clear and present danger for any IoT device with factory default credentials. As the attacks are still ongoing, we urge you to

• Change the device’s factory default credentials.
• Disable Telnet access to the device.
• Use Network Behavioral Analysis to detect anomalies in traffic and combine this with automatic signature generation for fast and effective mitigation.
• Use User/Entity behavioral analysis (UEBA) to spot granular anomalies in traffic early.
• Gateway devices allow blocking Telnet default credentials. Use a DPI signature to detect default credentials and/or provided command sequences.