Poor security on many IoT devices makes them soft targets and often victims may not even know they have been infected. Attackers are now highly aware of lax IoT security and many pre-program their malware with commonly used and default passwords.
IoT attacks have long been predicted, with plenty of speculation about possible hijacking of home automation and home security devices. However, attacks to date have taken a different shape. Attackers tend to be less interested in the victim and the majority wish to hijack a device to add it to a botnet, most of which are used to perform distributed denial of service (DDoS) attacks.
Just this month the security vendor Sucuri reported on a large DDoS attack launched from 3 different types of botnets (CCTV botnet, home router botnet and compromised web servers). While not commonly seen in the past, attacks originating from multiple IoT platforms simultaneously may be seen more often in the future, as the amount of the embedded devices connected to the Internet rises.
Figure 1. New IoT malware families by year. The number IoT threats jumped in 2015 and many of these threats continue to be active into 2016
Vulnerable devices
Most IoT malware targets non-PC embedded devices. Many are Internet-accessible but, because of their operating system and processing power limitations, they may not include any advanced security features.
Embedded devices are often designed to be plugged in and forgotten after a very basic setup process. Many don’t get any firmware updates or owners fail to apply them and the devices tend to only be replaced when they’ve reached the end of their lifecycle. As a result, any compromise or infection of such devices may go unnoticed by the owner and this presents a unique lure for the remote attackers.
Majority of attacks originate in US and China
Analysis of a Symantec honeypot which collects IoT malware samples found that the highest number of IoT attacks originated in China, which accounted for 34 percent of attacks seen in 2016. Twenty-six percent of attacks stemmed from the US, followed by Russia (9 percent), Germany (6 percent), the Netherlands (5 percent), and Ukraine (5 percent). Vietnam, the UK, France, and South Korea rounded out the top ten.
These figures represent the location of IP addresses used to launch malware attacks on Symantec’s honeypot. In some cases, IP addresses used may be proxies used by attackers to hide their true location.
The threats seen most frequently on Symantec’s IoT honeypot this year were Linux.Kaiten.B and Linux.Lightaidra.
Figure 2. Top ten attack origins on monitored IoT honeypot in 2016, by count of unique attackers
Top passwords
Attacks on Symantec’s honeypot also revealed what the most common passwords IoT malware used to attempt to log into devices. Not surprisingly, the combination of ‘root’ and ‘admin’ leads the chart, indicating that default passwords are frequently never changed. The default Ubiquiti credentials (user name: ubnt and password: ubnt) also feature highly. As reported in May 2016, an old vulnerability in Ubiquiti routers allowed the worms targeting embedded devices to spread across thousands of Ubiquiti Networks routers running outdated firmware. It looks like the attackers behind IoT malware still count on the presence of unpatched Ubiquiti routers in the wild. Further down the charts we see the default credential combination for the Raspberry Pi devices (user name: pi and password: raspberry), which indicates a growing trend of attackers specifically targeting this platform.
| Top user names | Top passwords |
| root | admin |
| admin | root |
| DUP root | 123456 |
| ubnt | 12345 |
| access | ubnt |
| DUP admin | password |
| test | 1234 |
| oracle | test |
| postgres | qwerty |
| pi | raspberry |
Table 1. Top 10 brute-force usernames and passwords used against IoT devices
IoT malware – common traits
While IoT malware is becoming more sophisticated, the fact that it is being used mostly for DDoS attacks allows us to distinguish several common traits that are seen within the variety of existing malware families.
As far as malware distribution goes, attackers take a straightforward approach. While some malware variants need to be manually installed on the device, the most common method consists of a scan for random IP addresses with open Telnet or SSH ports, followed by a brute-force attempt to login with commonly used credentials.
Because of the variety of CPU architectures that embedded devices run on, IoT malware may try to randomly download bot executables for multiple architectures and run them one by one until successful. In other cases, malware may also include a module that performs a check for the existing devices’ platform and download just the correct bot binary.
A common tactic by attackers is using a wget or tftp command to download a shell script (.sh) that in turn downloads the bot binaries. In one case we came across a shell script where the malware author used drug street names to differentiate between the bot binaries for different architectures.
Figure 3. Shell script used to download the bot binaries for different architectures
Once the bot binary is executed, it will establish a connection to a hardcoded command and control (C&C) server and await commands from the remote bot master. The communication might be established through an IRC channel and the malware may also include functionality to encrypt the traffic to the remote C&C server.
Cross-platform malware
It is quite simple for the attackers to cross-compile their malware for a variety of architectures. While the most common targets are the x86, ARM, MIPS, and MIPSEL platforms, attackers continue to expand the number of potential targets and have also been creating variants for PowerPC, SuperH and SPARC architectures. By doing so, the list of the potentially vulnerable devices increases, with more web servers, routers, modems, NAS devices, CCTV systems, ICS systems, and other devices added to the list of potential targets
One interesting feature seen on a variety of IoT malware is the ability to kill other processes, specifically processes belonging to other known malware variants. In some older variants this feature might have been used just to eliminate the potential malware competitor from the infected device. We believe that the most common reason for it lies in the fact that the embedded devices come with very limited system resources and the malware tries to make sure that these are not shared with other CPU or memory-intensive processes.
To achieve the same goal but through a more sophisticated approach, the malware may also change iptable rules on the infected device so that only specific external access attempts are allowed. A change like this would effectively block access to the device for other malicious actors but could potentially also lock out the legitimate admins (blocked telnet port).
An overview of IoT malware families
Below are the most recognizable and prevalent malware families targeting embedded devices:
Linux.Darlloz (aka Zollard)
Linux.Darlloz is a worm discovered by Symantec that spreads to vulnerable systems by exploiting the PHP ‘php-cgi’ Information Disclosure Vulnerability (CVE-2012-1823), an old vulnerability patched in 2012. The Darlloz variants found in the wild were initially designed only for computers running on x86 chip architecture, but later versions of the malware also target devices using ARM, PPC, MIPS, and MIPSEL architectures. An interesting trait of the worm is that it scans for and deletes any files associated with another piece of IoT malware, Linux.Aidra. It will also attempt to block the communications port used by the latter. Once the targeted device is infected with Darlloz, a backdoor on a TCP port will open that allows remote command execution. The worm will also block users from connecting to the infected device by dropping Telnet traffic and terminating the telnetd process.
Linux.Aidra / Linux.Lightaidra
Linux.Aidra and its latest variant Linux.Lightaidra, is a worm that spreads through Telnet services on TCP port 23 and uses common username / password combinations in order to login into the device. The worm opens a back door on the compromised computer or device and awaits commands from the remote C&C server. Each infected device is added to a botnet that is being used to perform DDoS attacks. DDoS attacks from devices compromised by Aidra may be floods of Transmission Control Protocol (TCP) packets, User Datagram Protocol (UDP) packets, or domain name system (DNS) requests.
Linux.Xorddos (aka XOR.DDos)
Linux.Xorddos opens a back door on the compromised computer or device. The name of the threat comes from the fact that it uses heavy XOR encryption both in the malware code as well as in the C&C server communication. Xorddos comes in variants compiled both for x86 as well as ARM architectures. Aside from the main function to conduct DDoS attacks, additional functionalities of the Trojan include downloading and execution of files, services removal, and installation of additional modules. Xorddos might be installed alongside a rootkit component that hides network traffic or files. In order to perform any such tasks on the infected device, the Trojan might send IOCTL requests to the rootkit component.
Linux.Gafgyt (aka GayFgt, Bashlite)
Linux.Gafgyt is usually distributed through a successful exploitation of the Shellshock Vulnerability (CVE-2014-6271). Once installed, it becomes a part of a botnet and is used to launch DDoS attacks (either UDP or TCP floods). Shellshock affected devices may include web servers or Linux-based routers that have a web interface using CGI. Gafgyt also contains functionality to brute-force routers with common username/password combinations and can collect CPU information from the infected device.
Linux.Ballpit (aka LizardStresser)
Linux.Ballpit was created by the infamous APT group known as Lizard Squad. The worm has the ability to launch DDoS attacks from the compromised device using floods of TCP or UDP packets. Similar to many other IoT malware families, the worm is distributed by scanning public IP addresses for Telnet services. Once an appropriate open connection is found, Ballpit will attempt a variety of hard-coded common usernames and passwords in order to login. A successful logon attempt will be reported back to the C&C server and the bot client will await further instructions from the attacker.
Linux.Moose
In contrast to many IoT malware families described here, Linux.Moose does not have any DDoS capabilities and seems to be more a reconnaissance type of malware. The worm spreads to targeted Linux-based routers and embedded ARM- or MIPS-based devices by first scanning for nearby IP addresses and then by brute-forcing weak Telnet login credentials. The first stage after infection consist of eavesdropping on network traffic on the compromised device. Alongside eavesdropping the worm may also capture the traffic, collect information about the devices’ CPU, and report the collected data back to a remote C&C server. Additional functionality of Moose includes periodic checks of any running processes belonging to competing IoT botnet clients and killing these if located. Bases on the configuration file received from the C&C server the worm may also change the DNS server settings on the compromised host.
Linux.Dofloo (aka AES.DDoS, Mr. Black)
Linux.Dofloo is a Trojan horse for Linux-based systems on x86, ARM, or MIPS architectures. The threat is also known as AES.DDoS, which comes from the fact that the AES algorithm is used to encrypt the communication with the C&C server. The Trojan opens a backdoor on the compromised device and awaits commands from the remote attacker. Dofloo is used to carry out DDoS attacks, but it might also collect information about the CPU, memory and network traffic of the compromised device and send this data back to the attacker.
Linux.Pinscan / Linux.Pinscan.B (aka PNScan)
Linux.Pinscan is a Trojan horse developed for various CPU architectures including x86, ARM, MIPS, and MIPSEL. Pinscan may scan a network segment for devices with an open Port 22 and attempt a brute-force login with common usernames and passwords. It might also try to get access to the devices by exploiting vulnerabilities. It does not have any DDoS capabilities, but once it successfully obtains access to a targeted device, it may further download additional malware binaries such as Linux.Kaiten.
Linux.Kaiten / Linux.Kaiten.B (aka Tsunami)
Linux.Kaiten and its later variant Linux.Kaiten.B is a Trojan horse used to DDoS attacks. Depending on the variant it may modify the /etc/init.d/rc.local file in order to get run each time a user logs in, or the /etc/rc.d/rc.local file to ensure it is executed on boot-up. Once installed Kaiten will join a hardcoded IRC channel and listen for commands from the remote attacker. Besides launching DDoS attacks it may also kill processes, download and execute other arbitrary files, or spoof the IP address of the compromised device.
Linux.Routrem (aka Remainten, KTN-Remastered, KTN-RM)
Since Linux.Routrem contains many elements of the Linux.Kaiten code, it is also as KTN (Kaiten)-Remastered. Once executed, Routrem will identify the architecture used on the compromised router and deploy the correct module (ARM, MIPS, or x86). Similar to Kaiten, Routrem may download additional files, launch a variety of DDoS attacks or scan nearby IP addresses for open Telnet ports. It is designed to target and infect standalone router devices and, as with Kaiten, receives commands from the remote attacker through the IRC channel.
Linux.Wifatch (aka Ifwatch)
Linux.Wifatch is considered an Internet-of-Things vigilante among the IoT malware families. According to its author, it has been designed for educational purposes. Wifatch’s code is written in the Perl programming language and it targets several different architectures – ARM, MIPS, Sh4, PowerPC, and x86. It does not launch DDoS attacks, exploit vulnerabilities, or distribute malware payloads, but instead some of its hardcoded routines attempt to improve the security of the compromised device. For example, Wifatch may present warning messages to the administrators about the potential danger of open Telnet ports or leave recommendations to change passwords and update the device’s firmware. Wifatch also includes a module that will attempt to find and kill any processes belonging to other known families of IoT malware present on the same device.
Linux.LuaBot
Linux.Luabot is the first malware targeting the ARM architecture written in the LUA programming language. The known capabilities of Luabot include launching DDoS attacks.
Attackers flocking to soft targets
The current IoT threat landscape shows that it does not require much to exploit an embedded device. While we have come across several malware variants exploiting device vulnerabilities – such as Shellshock or the flaw in Ubiquiti routers – the majority of the threats simply take advantage of weak built-in defenses and default password configurations in embedded devices.
DDoS attacks remain the main purpose of IoT malware. With the rapid growth of IoT, increased processing power in devices may prompt a change of tactics in future, with attackers branching out into cryptocurrency mining, information stealing, and network reconnaissance.
Staying protected
- Research the capabilities and security features of an IoT device before purchase
- Perform an audit of IoT devices used on your network
- Change the default credentials on devices. Use strong and unique passwords for device accounts and Wi-Fi networks. Don’t use common or easily guessable passwords such as “123456” or “password”
- Use a strong encryption method when setting up Wi-Fi network access (WPA)
- Many devices come with a variety of services enabled by default. Disable features and services that are not required
- Disable Telnet login and use SSH where possible
- Modify the default privacy and security settings of IoT devices according to your requirements and security policy
- Disable or protect remote access to IoT devices when not needed
- Use wired connections instead of wireless where possible
- Regularly check the manufacturer’s website for firmware updates
- Ensure that a hardware outage does not result in an unsecure state of the device
Source:https://www.symantec.com/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
