A glimpse into the future of IoT Botnets
On Oct 16th, Sam Edwards and Ioannis Profetis from Rapidity Networks published a report on a new malware they discovered and named “Hajime.” The report came in the aftermath of the release of the Mirai source code and Mirai’s attacks on Krebs and OVH. Before Hajime was able to make headlines, Mirai was attributed to the attacks that took down Dyn on Oct 21st and lead to a large array of Fortune 500 companies such as Amazon, Netflix, Twitter, CNN, and Spotify being unreachable most of that day. Hajime evaded the attention but kept growing steadily and breeding in silence.
Until a few weeks ago, Hajime was not a headline, but rather a subject many researchers were studying and analyzing, trying to uncover the mystery behind its purpose and the intentions of its author. One week ago, Waylon Grange from Symantec published more quantitative research which assesses the size of the beast.
After the report from Sam and Ioannis, which found a vulnerability in the encryption code of the command and control channels, the author of the malware updated his botnet with a newer, improved version that is not vulnerable anymore and adopted the name ‘Hajime’.
No attacks have been attributed to Hajime and it doesn’t carry a payload to do so. But it is sophisticated, well designed and flexible enough to be repurposed in the blink of an eye. In my personal opinion, there are enough elements to believe there is a real and present danger in Hajime.
Hajime has been gaining considerable IoT market share for the last six months. Infection attempts by Hajime account for nearly 50% of the IoT bot activity in our honeypots. In a timespan of a little over five weeks, we counted almost 15,000 infection attempts from more than 12,000 unique IPs. We discovered that upon infecting, the Hajime bot sometimes leverages other infected nodes to download its malware, which increased our coverage and brought the current total number of unique infected IPs we could identify to almost 19,000.
The above graph shows the geographic spread of the botnet. Every dot accounts for a unique IP we were able to identify as an infected device.
In terms of infected countries, Vietnam is leading with Brazil, Iran, and Turkey following closely – but it being a global threat, most countries with well-established internet take a fair share of the infection pie.
HAJIME, THE NEXT GENERATION IOT BOT
Hajime is a sophisticated, flexible, thoughtfully designed and future-proof IoT botnet. It is capable of updating itself and provides the ability to extend its member bots with ‘richer’ functionality efficiently and fast. The distributed bot network used for command and control and updating is overlayed as a trackerless torrent on top of the well-known public BitTorrent peer-to-peer network using dynamic info_hashes that change on a daily basis. All communications through BitTorrent are signed and encrypted using RC4 and private/public keys.
The current extension module provides scan and loader services to discover and infect new victims. The efficient SYN scanner implementation scans for new victims through open ports TCP/23 (telnet) and TCP/5358 (WSDAPI). Upon discovering open Telnet ports, the extension module tries to exploit the victim using brute force shell login much the same way Mirai did. For this purpose, Hajime uses a list consisting of the 61 factory default passwords from Mirai and adds two new entries ‘root/5up’ and ‘Admin/5up,’ which are factory defaults for Atheros wireless routers and access points. In addition, Hajime is capable of exploiting ARRIS modems using the password-of-the-day “backdoor” with the default seed as outlined here.
Hajime does not rashly follow a fixed sequence of credentials, from our honeypot logs we could conclude that the credentials used during an exploit change depending on the login banner of the victim. In doing so, Hajime increases its chances of successfully exploiting the device within a limited set of attempts and avoid the system account being locked or its IP being blacklisted for a set amount of time.
Upon execution, Hajime prevents further access to the device through filtering ports known to be abused by IoT bots such as Mirai:
• TCP/23 (telnet) – the primary exploit vector of Mirai and most IoT botnets
• TCP/7547 (TR-069) – as first used in the DT attack by a Mirai variant
• TCP/5555 (TR-069) – alternate port commonly used in TR-069
• TCP/5358 (WSDAPI) – see separate section at the end about WSDAPI
At the same time, Hajime also tries to remove existing firewall rules with the name ‘CWMP_CR’. CWMP refers to the CPE WAN Management Protocol or TR-069. Removing any potential CWMP rules set by an ISP to allow specific management IPs or subnets that will now be locked out leaving ISPs without control of the CPE device.
Besides locking down the device, Hajime opens up port UDP/1457 and a random higher port number (> 1024) for UDP and TCP, and in doing so, allowing itself to use BitTorrent DHT and uTP from port UDP/1457 to build its peer-to-peer command and control network. The random higher port serves the purpose of the loader service used by the infection process to remotely download the malware onto new victims.
The extension module also has traces of a UPnP-IGD implementation which allows Hajime to create dynamic port forwarding rules in UPnP enabled gateways, allowing it to operate effectively from inside a protected home network. Even when all incoming traffic is blocked by a default ISP managed ruleset on the gateway, UPnP-IGD allows to punch pin-holes and expose internal services to the public internet.
Hajime has binaries for the arm5, arm6, arm7, mipseb and mipsel platforms. User Psychotropos maintains a log of updated binaries and file hashes on his Github repository. Since January 28th the main binary has been updated six times, with the last update discovered on March 5th 2017. The extension module has been updated four times between January 18th and February 26th. Since the discovery of Hajime back in October 2016, the extension module changed names from ‘exp’ to ‘atk’. The main binary name remained ‘.i’ and the downloader stub used during some infections is still called ‘.s’.
Hajime prefers the use of volatile file systems as a working directory, ensuring any indicator of compromise is gone after a device reboot. Hajime is not persistent, meaning that rebooting the device will clean it from infection, but only until the next infection…
There has been lots of speculation about the greyness of the author and the intent and purpose of Hajime. If we set aside the speculation and the motivation of the original author, but focus on the potential purpose of such large IoT botnets, consider for a moment that this botnet could be hijacked from its original owner. Sam and Ioannis from Rapidity Networks uncovered a vulnerability in the encryption implementation of the initial Hajime malware and were able to reverse the messaging protocol. The vulnerability has been patched and updated, but a botnet this size with a flexible backend and high potential for criminal behavior will certainly attract the attention of black hats… Whoever has the ‘keys’ of the botnet will decide its fate!
Because of its flexible and extensible nature, Hajime can easily be repurposed and leveraged to perform tasks such as the following:
• DDoS attacks
• Massively distributed vulnerability scanning, allowing hackers to detect vulnerable, public exposed services and exploit them within hours after the disclosure of a new vulnerability (most systems are not patched within a few hours… as history taught us). Custom exploit modules can be written in any language, as long as they compile to a binary for one of the supported platforms, and distributed through the torrent overlay to be executed by 10,000, maybe even 100,000 distributed nodes across the internet.
• Massive surveillance network – the extension module could tap into RTSP streams from cameras.
• IoT Bricker network – leveraging the work of BrickerBot, it would be a small and easy change to the atk program to perform a self-destructive sequence upon receiving a ‘plan B’ command through the C2 channel. For example, a hacker could target and put a specific region or city in the dark by bricking all the infected devices corresponding to that region or city based on geography.
For now, however, Hajime is still under control of its original author (or so I hope) and mostly we are considering his intentions to be good. Still, I wonder why this white knight keeps growing his botnet and keeps the devices hostage – searching and scanning aggressively for the next potential victim. If his intentions are good, why not just leave the CWMP rules and improve on them? If the ISP did not apply adequate security, why not make the iptables rules persistent, or keep them volatile but release the device, and don’t keep it indefinitely hostage until it is rebooted?
I hope our report and blog have given you a better view on what Hajime represents. If Hajime is a glimpse into what the future of IoT botnets looks like, I certainly hope the IoT industry gets its act together and starts seriously considering securing existing and new products. If not, our connected hopes and futures might depend on Rob the Janit0r and grey hat vigilantes to purge the threat the hard way…
For more statistics and a more technical analysis on Hajime, please read our ERT alert here: Hajime – Friend or Foe?
Read the 2016–2017 Global Application & Network Security Report by Radware’s Emergency Response Team.
As the EMEA Cyber Security Evangelist for Radware, Pascal helps execute the company's thought leadership on today's security threat landscape. Pascal brings over two decades of experience in many aspects of Information Technology and holds a degree in Civil Engineering from the Free University of Brussels. As part of the Radware Security Research team Pascal develops and maintains the IoT honeypots and actively researches IoT malware. He discovered BrickerBot, provided the updated Hajime report and follows closely any development and new threats in the IoT landscape. Prior to Radware, Pascal worked with the largest EMEA cloud providers on their SDN and next gen data center strategies as a consulting engineer for Juniper. As an independent consultant Pascal architected sensor networks, automated and developed PLC systems and lead security infrastructure and software auditing projects. At the start of his career he was a regular presenter at IBM conferences for Perl and Unix kernel development.