IoT Security Hardening: Mirai and Reaper Botnet, Turf Warfare and Malware Analysis


The Mirai botnet, powered primarily by IoT devices, was responsible for the DDoSing of several high-profile targets in 2016-2017 — serving as a wake-up-call to IoT manufacturers and security professionals to increase the baseline security of IoT devices. Since its open-source release, Mirai’s source code has fuelled an almost exponential development for more other botnet variants like IoT_reaper, Hajme and BrickerBot.

Background – Incident Timeline



Coined ‘Mirai’ – meaning ‘for future’ in Japanese, the botnet was first identified in August 2016 by the security research group ‘MalwareMustDie’. Soon after, Mirai will be known as the vehicle for some of the most effective DDoS attacks in history – scanning and attacking vulnerable IoT devices with a short list of 62 default usernames and passwords.  

In September 2016, KrebsOnSecurity was DDoSed by 620 Gbps of traffic driven by Mirai. Paralleling this attack, the French webhost cloud service provider OVH was also DDoSed – breaking the record for the largest recorded DDoS attack. This attach was timed at 1.1-1.5 terabits per second where OVH was victim to more than 25 DDoS attacks on its servers. Shortly after, the source code of the botnet was made open source by ‘Anna-Senpai’ in the infamous ‘Hack Forums’. Anna-Senpai offered 400,000 simultaneously connected devices for rent. Following the publicised source code, more attacks followed, including an October 2016 attack against ‘Dyn’ – the service provider that affected hundreds of websites including Twitter, Amazon, Spotify, Netflix, Reddit and Github. 

In November 2016, 900,000 Germans were taken offline following the DDoS of German ISP Deutsche Telekom. The malware discovered a router vulnerability that allowed ISPs to remotely upgrade firmware on routers manufactured by Zyxel and Speedport. In the same month, Mirai was discovered as the culprit of several short-duration attacks on the infrastructure of Liberia. (Liberia has one internet cable installed in 2011 – providing a single point of failure).

In December 2016, TalkTalk and Post Office telecom were also hit by the Mirai botnet – affecting around 100,000 customers. Figure 1.1 below demonstrates the growth of Mirai across various port numbers – where it hit a peak of 600,000 devices around December 2016. In February 2017, Kaspersky Labs published a discovery of a Mirai variant that was infiltrating Windows SQL-servers connected to network devices with embedded Linux systems (IP cameras and media centre appliances). The new strain of the malware was found to be “richer and more robust” according to Kaspersky. 

Figure 1.1 – Spread of Infected Devices (Source)


Mirai Internals


Mirai operates through a rapid scanning of ports between 23 and 2323 – statelessly sending TCP SYN probes to IPv4 addresses excluding a range of blacklisted IP addresses that included Department of Defence, GE and HP. The bot then engages in a brute-force attack, establishing a Telnet connection, running through 62 default credentials that are hardcoded in Mirai. Once logged in, Mirai sends the device IP and associated credentials back to the hard-coded report server.



Asynchronously, a loader program then attempts to download and execute an architecture-specific binary (via a GNU Wget or FTP) to gain a shell before promptly forwarding device information to the command-and-control (C&C) server. To obfuscate operations, Mirai then removes the downloaded binaries and encodes the name of the processes in pseudorandom strings (the downside of this is the lack of persistence of the malware upon system reboots). 

Each bot will then communicate with the C&C server via a domain name that’s been hardcoded in the executable – i.e. cnc.changeme.com. The attacks run by the bots can range anywhere from TCP, HTTP floods, GRE (Generic Routing Encapsulation – a tunnelling protocol developed by Cisco where sending GRE packets with large amounts of encapsulated data results in resource consumption), UDP floods, DNS floods to STOMP (Simple Text Oriented Message Protocol) floods.

Botnet Turf Warfare

Analysis of the source code below, reveals Mirai’s territorial nature as it contains several scripts designed to eradicate other malwares – worms, Trojans as well as blocking incoming Telnet and SSH connections.

killer_kill_by_port(htons(23))  // port 23
killer_kill_by_port(htons(22))  // port 22
killer_kill_by_port(htons(80))  // port 80

Hardcoded in the source code, Mirai also has a piece of code to eradicate the Anime malware – another IoT based malware focused on CCTV devices with the file extension ‘.anime’ or ‘.kami’ that also uses hard-coded telnet credentials as its primary attack vector.


if (util_stristr(realpath, rp_len - 1, table_retrieve_val(TABLE_KILLER_ANIME, NULL)) != -1) {
           unlink(realpath);
           kill(pid, 9);
}
table_lock_val(TABLE_KILLER_ANIME);

Mirai was the successor a malware known as BASHLITE designed to infect Linux systems, performing DDoS attacks – launching attacks of up to 400 Gbps through exploiting the ShellShock vulnerability (CVE-2014-6271)  in devices running on BusyBox. BASHLITE also used a client-server model for C&C, propagating through brute-forcing a list of hardcoded credentials. Of the identified infected devices by BASHLITE, up to 96% of all devices were IoT devices. However, in contrast to BASHLITE, Mirai has deployed a stateless scanning that made it more efficient in identifying vulnerable devices.

Mirai’s aggressive nature aims to maximise the botnet’s attack potential as well as prevent similar attempts of eradication from its ‘competitors’. This predatory behaviour highlights another interesting development in botnet turf wars where botnet controllers are fighting to gain the greatest control over the breadth of IoT devices.

Mirai Variations & Other IoT Botnets

Upon the release of the source code, the number of bots almost doubled 
(213,000 to 493,000) with a wide range of Mirai variants emerging that use a 
whole different suite of ports including 7547 (used by ISPs to remote into 
broadband routers). Over 24 unique binaries corresponding to Mirai were 
uploaded to VirusTotal between August 2016 and September 2016 when the 
source code was initially released on Hack Forums. Analysis of the new strains 
of Mirai show a few changes in the malware internals including an upgrade from 
the original IP-based C&C operations to a domain-based system, increase 
sophistication in malware obfuscation of pids and further, additional features 
including larger host of credentials and closures of infected ports.

Below are some variants noted:

> Hajime botnet discovered in October 2016 by Rapidity Networksusing
BitTorrent DHT for peer discovery and uTorrent Transport Protocol for data 
exchange with RC4 encryption

> BrickerBot discovered in April 2017 by Radware – leverages SSH credential 
defaults / misconfigurations to attempt DoS attacks against IoT devices that 
include erasing files, reconfiguring network parameters 
or defacing firmware

> Persirai discovered in April 2017 by Trend Micro – targeted towards accessing 
interfaces of vendor-specific webcams, through port 81 using a zero-day attack 
rather than brute-forcing. Upon access, the bot uses the universal plug and 
play (UPnP) vulnerability to download the payload – where upon execution, also 
deletes the binaries. 

> IoT_Reader discovered in October 2017 by Check Point and Qihoo 360 Netlab 
targeted at IoT devices that are missing patches. The primary difference is in 
its propagation method where Reaper, rather than scanning for open Telnet 
ports, uses exploits to infiltrate unpatched devices. On record, nine 
vulnerabilities are currently being exploited by Reaper – focusing on D-Link 1 
and 2, Netgear 1 and 2, Linksys, GoAhead, JAWS, Vacron and AVTECH. 
Currently over two million infected devices are sitting and waiting to be 
processed.

Even now, naïve approaches to construct / infiltrate IoT devices can still gain control of a large range of devices. The allure of targeting IoT devices to create a botnet include the following:

> Constant and uninterrupted attack traffic - unlike computers which can be shut down, often surveillance cameras are on 24/7. This means C&C can gain access to these devices around the clock without peaks and troughs in attack times.

> Easy attack vectors via weak security protocols most IoT devices are manufactured by companies working to lower costs to meet high demands. The direct result of focusing on market penetration means weaker security protocols are in place.

> Non-interactive nature of most IoT devices – as most devices are configured, then left on – requiring minimum user interaction – most infections tend to go unnoticed. 

Protection Against Mirai


The most effective means for protecting against Mirai infection or other similar IoT botnets is to ensure all generic / default passwords have been changed to something with higher security. The success of the Mirai outbreak was almost entirely due to the prevalence of default credentials used across IoT devices and the lack of proper device configuration.

In addition to changing default logins, device owners should also disable all remote (WAN) access to the devices as well as ensure their devices are not open to remote access. Further, owners should also ensure all ports that are not required for operational purposes are closed – i.e. SSH, Telnet and HTTP/HTTPs. Consumers should also consider limiting the capabilities of the devices to only the strict set of actions they’re required to perform. In the case that remote access to the devices is required, consumers should implement strong levels of device authentication for the different levels of access required.

At an enterprise level, network admins can actively scan for vulnerable / compromised devices on their own networks as well as their customers’ networks. This can be done by monitoring and identifying any ‘strange’ TCP/23 and/or TCP/2323 activity on any of the ports Mirai use. They can then work on isolating the infected devices as well as reboot the systems and change the login credentials. Network segregation and access controls should further be instilled to avoid any single point of failures where infected IoT devices can penetrate into the network and pivot to other devices. On top of this, these admins can further enhance security to protect against DDoS attacks through DDoS mitigation companies like Cloudflare or Arbo TMS, and/or consider source-based remotely-triggered black holes (S/RTBH).

Broader Impact: Security Hardening & Regulations


The impact of Mirai stands two-fold: the challenges of securing commercial devices and regulatory / policy-based defences that subsequently follow. The difficulty in securing IoT devices lies in the tight nature of industry – where a smaller number of vendors dominate most of the supply-chain. The debate then becomes a question of responsibility – does the onus lie on the user to ensure their devices are configured correctly, or does the onus lie in the manufacturer ensure inbuilt security? 


The outbreak of Mirai, demonstrated a strong need for the security hardening of IoT devices due to the hundreds of thousands of devices infected via an unsophisticated, hardcoded dictionary of 62 login credentials. To mitigate this threat, IoT manufacturers could potentially consider the following:

> Evolving away from default-open ports to ensuring all ports are closed
> Limit the ability to remote address access to local networks or providers from the devices
> Employ isolation boundaries for the devices
> Include some privilege / access controls into the design
> Ensure consumers have access to information to guide them on their security choices

Adding to these considerations – IoT manufacturers could further consider deploying a system for automatic updating for the devices. This would allow time for developers to issue patches, log the vulnerabilities and manage bugs without putting the onus on the consumer to update their devices. Further, perhaps bug bounties can also be deployed to incentivise the security community to actively police devices for vulnerabilities – raising the overall security standards across the variety of devices.


Instilling a system for notifying device owners of infections or compliance breaches would also be a mechanism for actively engaging device owners and generate awareness of security implications. The difficulty here is in capturing notifications across the breadth of devices offered and the question of usability for the consumer when it comes to acting on the notifications and knowing what to do with the information.

Further, in order for security to be built within these devices, regulations and policies need to be put in place to set the standardization for all vendors and to raise the bar for manufacturers – incentivising change through the existence of penalties and breaches. In order for this to be feasible in practice, policy-makers and regulators will require the collaborative input from the security community for establishing compliance frameworks, certifications and standards.

IoT and the Future

Likely attacks of the future might evolve from brute-forcing to targeting actual software vulnerabilities in IoT devices. Since the emergence of IoT devices, they have been riddled with vulnerabilities all the way from the firmware level to the application level. As the number of security breaches increase across time, more and more pressure will be placed on the security community to create and/or generate standards for these security failures or design systems that are embedded with security measures. Overall, more work, discussion and agreement is required in this area to protect this technological frontier by raising the overall security standards.




More References


Dark Reading. (2017). IoT DDoS Attack Code Released. [online] Available at: https://www.darkreading.com/denial-of-service-attacks/iot-ddos-attack-code-released-/d/d-id/1327086 [Accessed 1 Oct. 2017].



Engineer, R. (2017). BASHLITE Affects Devices Running on BusyBox - TrendLabs Security Intelligence Blog. [online] TrendLabs Security Intelligence Blog. Available at: https://blog.trendmicro.com/trendlabs-security-intelligence/bashlite-affects-devices-running-on-busybox/ [Accessed 20 Sep. 2017].

EVOSEC. (2017). New IoT Malware? Anime/Kami | EVOSEC. [online] Available at: https://evosec.eu/new-iot-malware/ [Accessed 28 Sep. 2017].



Incapsula.com. (2017). Unknown. [online] Available at: https://www.incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html [Accessed 1 Oct. 2017].

Kolias, C., Kambourakis, G., Stavrou, A. and Voas, J. (2017). DDoS in the IoT: Mirai and Other Botnets. Computer, 50(7), pp.80-84.


Krebsonsecurity.com. (2017). Mirai botnet — Krebs on Security. [online] Available at: https://krebsonsecurity.com/tag/mirai-botnet/ [Accessed 23 Sep. 2017].



Krebsonsecurity.com. (2017). New Mirai Worm Knocks 900K Germans Offline — Krebs on Security. [online] Available at: https://krebsonsecurity.com/2016/11/new-mirai-worm-knocks-900k-germans-offline/ [Accessed 22 Sep. 2017].



Krebsonsecurity.com. (2017). Who is Anna-Senpai, the Mirai Worm Author? — Krebs on Security. [online] Available at: https://krebsonsecurity.com/2017/01/who-is-anna-senpai-the-mirai-worm-author/ [Accessed 24 Oct. 2017].


NJCCIC. (2017). Bashlite. [online] Available at: https://www.cyber.nj.gov/threat-profiles/botnet-variants/bashlite [Accessed 29 Sep. 2017].



Radware Blog. (2017). Let’s discuss facts: An insight into Mirai’s source-code. [online] Available at: https://blog.radware.com/security/2016/11/insight-into-mirais-source-code/ [Accessed 29 Sep. 2017].

Savage, K. (2017). A Post-Mortem on the Mirai Botnet: Part 1: Defining the Attack. [online] Pwnieexpress.com. Available at: https://www.pwnieexpress.com/blog/mirai-botnet-part-1 [Accessed 1 Oct. 2017].

Xiang, C., Lihua, Y., Shuyuan, J., Zhiyu, H. and Shuhao, L. (2013). Botnet spoofing: fighting botnet with itself. Security and Communication Networks, 8(1), pp.80-89.



Comments

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Successful 4624 Anonymous Logons to Windows Server from External IPs?