Malware
The Reigning King, Challengers of IP Camera Botnets
Early last month we discussed a new Internet of Things (IoT) botnet called Persirai (detected by Trend Micro as ELF_PERSIRAI.A), which targets over 1000 Internet Protocol (IP) camera models.
Update as of June 21, 2017, 9:00 PM CDT to clarify a statement to emphasize that embedded JavaScript code was unable to be executed on the client side since IoT devices were too weak to execute JavaScript code locally. Also fixed ASUS Router Infosvr name.
Early last month we discussed a new Internet of Things (IoT) botnet called Persirai (detected by Trend Micro as ELF_PERSIRAI.A), which targets over 1000 Internet Protocol (IP) camera models. Currently, through Shodan and our own research, we see that 64% of tracked IP cameras with custom http servers are infected with Persirai. But, because these cameras are such common targets, there is some competition between malware.
We find that there are four different malware families which all focus on IP cameras. Each one has its own unique features, but since the pool of targets is finite they all compete for territory and build defenses to block rival malware.
Name | Attac-king since | First Seen | Self Defense | Propagation Methods | Special Features | Main Target TCP Port |
Persirai | 2017/04 | 2017 | Yes | SSDP Web | >Spread by SSDP vulnerability in LAN >Built-in Webcam exploits function | 81 |
DvrHelper | 2017/03 | 2016 | No | Telnet Web | > The same as Mirai function. > Layer7 DDoS (1) | 80 |
Mirai | 2017/02 | 2016 | No | Telnet Web Others (2) | >DDoS Type: GRE IP/GRE ETH/SYN/ACK/STOMP/DNS/UDP | 81 |
TheMoon | 2017/02 | 2014 | Yes | Telnet Web (Include Linksys) SOAP RCE Asus.infosvr.UDP | >P2P Communication (Multi C&C) >External Socks5 Module >Support Plug-In | 80 |
Note: (1) Layer 7 DDoS was copied from existing Python script
(2) Mirai variants spread through multiple methods
Figure 1. Overview of IP camera malware families
Persirai
In the aftermath of 2016 (the year of record breaking distributed denial-of-service (DDoS) attacks from compromised IoT), the authors of Persirai had the benefit of seeing what worked for older malware families and finding new strategies to infect their targets. Our post in early May already detailed the inner workings of Persirai, including the infection flow.
One interesting feature of Persirai is that when it compromises an IP camera, that camera will start attacking others by exploiting three known vulnerabilities:
- Vulnerabilities in a custom http server provider:
- 1. login.cgi – allows attackers to bypass authentication and get the admin password
- 2. set_ftp.cgi – when the attacker knows the admin password, he can use this for command injections and malware deployment
- CVE-2014-8361– this vulnerability allows remote attackers to execute arbitrary code via a crafted New Internal Client request.
Through these vulnerabilities, the attacker will be able to get users’ passwords, and can deploy command injections regardless of password strength.
Mirai
Before Persirai surfaced, news outlets and the cybersecurity industry were already talking about the DDoS capabilities of botnets thanks to the most infamous malware of the group: Mirai (identified by Trend Micro as ELF_MIRAI family). First seen in August 2016, Mirai made global headlines last year when it successful launched the largest DDoS attacks in history. The problem only worsened when the developers published Mirai’s source code in October 2016, letting anyone modify and create new variants. It is no surprise that the malware family is joining the fight and targeting IP cameras, even claiming some victims in Russia.
Recently, we’ve seen that Mirai is widening its distribution capabilities through a Windows Trojan that scans for more ports than previous versions. It checks if the following ports are open: 22 (SSH), 23 (Telnet), 135 (DCE/RPC), 445 (Active Directory), 1433 (MSSQL), 3306 (MySQL) and 3389 (RDP).
DvrHelper
A newer version of Mirai, DvrHelper (detected by Trend Micro as ELF_MIRAI.AU ) also learned from its predecessor. Since Mirai triggered such a response from companies and industries all over the world, DDoS prevention solutions have been surfacing. To match the increase in security, DvrHelper has eight more DDoS attack modules. It is also the first malware designed to bypass an anti-DDoS solution.
Specifically, DvrHelper has two methods that can bypass DDoS defense from one particular content delivery network that also provides DDoS prevention services.
The first method targets anti-bot techniques and takes advantage of the challenge-response policies of the provider:
Figure 2. This method bypasses the provider’s anti-bot
The process is as follows:
- Bot sends a request to target’s website and gets a challenge request in JavaScript.
- Embedded JavaScript code is extracted and sent to the command and control (C&C) server. The C&C server will execute JavaScript code and respond with a result (answer).
- The answer and other information are combined and a response request is sent to the DDoS protection provider to get a valid cookie and user-agent for the following DDoS attack.
This method has been on the Python library since 2014. However, the embedded JavaScript code was unable to be executed on the client side since IoT devices were too weak to execute JavaScript code locally. In this case, the developers designed the architecture and executed remotely.
The second method uses a shared “Google reCAPTCHA response” token:
Figure 3. How it attempts to bypass the provider’s Google reCAPTCHA
- Bot sends a request to the C&C URL and gets a valid (shared) Google reCAPTCHA response token.
- Bot sends a request with the token to the validator URL and gets a valid cookie, __cfduid (used by the provider to override any security restrictions based on the IP address the visitor is coming from) and cf_clearance (if this cookie is present in requests, further challenges are bypassed). With the information, the bot attempts to bypass DDoS protection.
Also, on comparing the latest version of DvrHelper’s C&C server we found that the early hardcoded C&C server (110[.]173[.]49[.]74) was replaced by the hostname jbeupq84v7[.]2y[.]net. VirusTotal only has a passive DNS record of this, and currently the A record for DNS is removed.
Figure 4. VirusTotal showing a passive DNS record for the domain
TheMoon
Finally, TheMoon (detected by Trend Micro as ELF_THEMOON.B) is the oldest malware targeting IoT devices. The family was first discovered by SANS ICS in 2014 and it continues to upgrade attack methods and target new vulnerabilities.
When we compared a newer version with an older variant, we noted that the C&C server port was changed. Also, in the later versions a specific binary focuses on a specific vulnerability, and there are new iptables rules.
Figure 5. New Iptables rules for TheMoon malware
As the above figure shows, when the infection is done, iptables rules will be imported to the infected device. Through these rules, a wall is built by TheMoon to prevent other malware from infecting the device. The rules are different from each binary.
> .nttpd,17-arm-le-t1 INPUT -p tcp --dport 23 -j DROP INPUT -s 46.148.18.0/24 -j ACCEPT INPUT -s 185.56.30.0/24 -j ACCEPT INPUT -s 217.79.182.0/24 -j ACCEPT INPUT -s 85.114.135.0/24 -j ACCEPT INPUT -s 95.213.143.0/24 -j ACCEPT INPUT -s 185.53.8.0/24 -j ACCEPT
> .nttpd,17-mips-be-t2 INPUT -p tcp -m multiport --dport 80,8080,7547 -j DROP INPUT -s 46.148.18.0/24 -j ACCEPT INPUT -s 185.56.30.0/24 -j ACCEPT INPUT -s 217.79.182.0/24 -j ACCEPT INPUT -s 85.114.135.0/24 -j ACCEPT INPUT -s 95.213.143.0/24 -j ACCEPT INPUT -s 185.53.8.0/24 -j ACCEPT
> .nttpd,18-arm-le-t1 INPUT -p tcp --dport 23 -j DROP INPUT -s 46.148.18.0/24 -j ACCEPT INPUT -s 185.56.30.0/24 -j ACCEPT INPUT -s 217.79.182.0/24 -j ACCEPT INPUT -s 85.114.135.0/24 -j ACCEPT INPUT -s 95.213.143.0/24 -j ACCEPT INPUT -s 185.53.8.0/24 -j ACCEPT
> .nttpd,19-mips-le-t1 INPUT -p udp --dport 9999 -j DROP INPUT -p tcp -m multiport --dport 80,8080 -j DROP INPUT -s 46.148.18.0/24 -j ACCEPT INPUT -s 185.56.30.0/24 -j ACCEPT INPUT -s 217.79.182.0/24 -j ACCEPT INPUT -s 85.114.135.0/24 -j ACCEPT INPUT -s 95.213.143.0/24 -j ACCEPT INPUT -s 185.53.8.0/24 -j ACCEPT
>.nttpd,port4444 INPUT -p tcp --dport 8080 -j DROP INPUT -p tcp --dport 443 -j DROP INPUT -p tcp --dport 80 -j DROP INPUT -p tcp --dport 23 -j DROP INPUT -p tcp --dport 22 -j DROP INPUT -s 46.148.18.0/24 -j ACCEPT INPUT -s 185.56.30.0/24 -j ACCEPT INPUT -s 217.79.182.0/24 -j ACCEPT INPUT -s 85.114.135.0/24 -j ACCEPT INPUT -s 95.213.143.0/24 -j ACCEPT INPUT -s 185.53.8.0/24 -j ACCEPT
>.nttpd,port4446 INPUT -p tcp --dport 8080 -j DROP INPUT -p tcp --dport 443 -j DROP I NPUT -p tcp --dport 80 -j DROP INPUT -p tcp --dport 23 -j DROP INPUT -p tcp --dport 22 -j DROP INPUT -s 46.148.18.0/24 -j ACCEPT INPUT -s 185.56.30.0/24 -j ACCEPT INPUT -s 217.79.182.0/24 -j ACCEPT INPUT -s 85.114.135.0/24 -j ACCEPT INPUT -s 95.213.143.0/24 -j ACCEPT INPUT -s 185.53.8.0/24 -j ACCEPT |
Figure 6. Target ports for TheMoon malware
Based on rules, we know its target ports include TCP/22 (SSH Remote Login Protocol), TCP/23 (Telnet), TCP/80 (HTTP), TCP/443 (HTTP over SSL/TLS), TCP/7547 (CPE WAN Management Protocol), TCP/8080 (alternative port for HTTP) and UDP/9999 (ASUS Router Infosvr). Each port is mapped to a specific device and vulnerability, with the main target being IP cameras.
When the infection is done, the installation script will be replaced with a string “ne kemi mbaruar!” which is “We’re done!” in Albanian.
The impact and distribution
Figure 7. Infection rate for IP cameras with custom http servers (US and Japan)
Based on Shodan and our own research, we see that a little more than half of tracked IP cameras in the United States were infected by one of the four malware families discussed above. In Japan the number is even higher—64.85% of cameras are infected.
Figure 8. Distribution of infection of the four families (data for US, Japan, Taiwan, Korea only)
Looking at the data of infected devices from the United States, Japan, Taiwan and Korea, we see that Persirai is the clear frontrunner. However, the landscape is constantly changing and many vulnerable IP cameras are still exposed to the internet. With the success of these four families, other developers might be releasing their own IP camera-targeting malware and the results could be completely different very soon.
Recommendations and solutions
Many of these attacks are caused by a simple issue: the use of default passwords in the device interface. As soon as possible, IP camera users should change their passwords and follow best practices for creating a strong password—use at least 15 characters, with both uppercase and lowercase letters, numbers, and special characters.
But as proven by Persirai, a strong password is just the first step—it does not guarantee device security. IP camera owners should also disable Universal Plug and Play on their routers to prevent devices within the network from opening ports to the external Internet without any warning.
This issue of IP camera security is not just a concern for users. Vendors should also shoulder some of the responsibility and make sure their devices are secure and always updated. In line with this, users should take steps and always update their devices with the latest firmware to minimize the chance of vulnerability exploits.
In addition to the best practices mentioned above, users can look into solutions such as Trend Micro™ Security and Trend Micro Internet Security, which offer effective protection for threat’s to IoT devices using security features that can detect malware at the endpoint level. Connected devices are protected by security solutions such as Trend Micro Home Network Security, which can check internet traffic between the router and all connected devices. In addition, enterprises can monitor all ports and network protocols to detect advanced threats and protect from targeted attacks via Trend Micro™ Deep Discovery™ Inspector.
For more information about the IP camera models that are affected by these malware families, please see this link. And a list of Indicators of Compromise (IoCs) comprised of related hashes (SHA256) and malicious domains can be found in this appendix.