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.
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 Networks – using
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
Post a Comment