Why the World is Under the Spell of IoT_Reaper
It’s difficult to have missed the headlines on the new IoT botnet threat that is forming and the storm that might come with it. Why is the world under the spell of this new threat? What makes it different from Mirai? Why could it potentially become the most threatening botnet ever seen?
A history lesson
To better understand and appreciate why IoT_Reaper is taking the world by storm, we should revisit the recent history of Mirai. A little over a year ago, Krebs and OVH faced devastating DDoS attacks of unseen sizes. Almost one week after the attacks, in a world that was still trying to understand exactly what happened, a bad actor going by the name of Anna-Senpai published the source code of a botnet named ‘Mirai’ on Hackforums.com, claiming responsibility for the attacks.
Mirai became the first open-source botnet and most widely used weapon in the history of DDoS. Less than a month later, the internet infrastructure giant Dyn became a target of a Mirai botnet, resulting in large chunks of the internet becoming unreachable. Some of the internet’s largest cloud and service providers including Twitter, Spotify, Amazon, CNN and more were affected during the attacks. The Dyn attacks and their associated impact on many of the largest and most popular services on the internet marked a milestone in DDoS history. At that moment, most of us realized that the world would never be the same again and that Mirai and its victim, IoT, would severely impact the threat landscape for DDoS.
The water torture attack suffered by Dyn was not a new attack vector. First spotted in January 2014, water torture defeats the hierarchical caching of the internet DNS infrastructure. By generating random hostnames for a specific domain, the attacking device resolves the name through its recursive DNS. Because of the random nature of the hostname, the recursive DNS will always have a cache missing and has to forward the request to the authoritative DNS server for the domain. Now multiply this by hundreds of thousands of attackers, using tens of thousands of recursive DNS servers and the resulting load on the authoritative DNS. Take into account that authoritative DNS is sized with distributed caching in mind, knowing that locality of requests will be handled by the caches of the recursive DNS servers used by clients on the same internet segments. No authoritative DNS system, not matter how large it might be, is sized to be able to handle the load of hundreds of thousands of clients without the support of the distributed cache.
After the attack on Dyn it was clear that the DDoS threat landscape was moving from large volume, low complexity, amplification-based attacks on one side of the threat spectrum and complex application level attacks at low volumes to a new combined threat of high volume, highly complex, application-level attacks. The water torture was one of the first in what we expect to be a long list of high volume application-level attacks we will face in the near future. Given the sizes of IoT botnets, it is fairly easy to imagine a simple-to-code application-level request can result in devastating volumetric attacks that are hard to detect and difficult to mitigate. Even if IoT devices are resource-constrained, they run common and well known operating systems based on Linux which ship with a rich library of functions enabling them to easily code DNS attacks (gethostbyname) or HTTP/FTP/IMAP/LDAP/POP/SMTP/… application level attacks (libcurl) including each of their SSL/TLS permutation (openssl).
[You might also like: Chatting With IoT Bots]
Following the public release of the full Mirai botnet code, hundreds of Mirai botnets got herded by wannabe and professional hackers, all enjoying the unsophisticated nature yet very lethal and efficient harvesting of unsecured, vulnerable IoT devices such as DVRs, IP cameras and NVRs. The low investment and easy access to a weapon of DDoS had its impact on the economy of this attack: for less than the average price of a latte, anyone can now launch a multi-gigabit DDoS attack lasting more than a couple of minutes.
It’s only a couple of months later that Mirai showed its true potential when wielded by a skilled attacker. On November 27th, Deutsche Telekom (DT) saw 900,000 of its consumers’ internet connections impacted as an unseen variant of Mirai was attempting to infect their modems. A hacker, apprehended earlier this year and going by the alias of “BestBuy,” modified the Mirai exploit code with the TR-069 NewNTPServer1 Remote Command Execution vulnerability. A simple HTTP POST-based attack, which was mostly unknown until then, impacted any ISP using the TR-069 CPE WAN Management Protocol (CWMP) to centrally manage its fleet of modems. Shortly after DT, TalkTalk and Post UK were affected by the same attacks. Luckily for the rest of the world, the modem infection attempts failed. I’m sure DT doesn’t think of themselves as being lucky, but they managed to remediate and mitigate the vulnerabilities in their modems within a couple of days and the world was back to normal. But imagine for one moment that the attack had succeeded: we would have faced a 900,000 device botnet – almost 10 times the size of the largest botnets we have faced the last year.
IoTroop or IoT_reaper?
In the last week, two independent security reports emerged covering what is thought to be the same botnet. On Oct 19th CheckPoint reported on a new botnet they discovered, dubbed ‘IoTroop.’ The first signs of the botnet were picked up by their Intrusion Prevention Systems, which were showing an increasing number of attempts by hackers to exploit a combination of vulnerabilities typically found in IoT devices.
On Oct 20th, Chinese security firm Netlab 360 published an extensive report on a new malicious sample they caught one month earlier which was targeting IoT devices. The bot borrowed code from the Mirai botnet but does not share the same brute force Telnet exploit vector. Instead it exploits nine known IoT vulnerabilities. They named their discovery ‘IoT_reaper.’
[You might also like: Everything You Need to Know About Brickerbot, Hajime, and IoT Botnets]
IoT_reaper is not open sourced, but it might as well be! Based on the fixed domain names and IPs provided in the Netlab 360 report, anyone has access to the latest malware binaries. From the exploit vectors discovered by Netlab, it is almost conclusive that CheckPoint and Netlab are referring to one and the same IoT botnet. Over the last week, reports on IoT_reaper aka IoTroop have emerged around the globe, sounding the alarm on a new IoT botnet storm in the making. Quoting the CheckPoint report on what could very well be the largest storm in IoT botnet history: “So far we estimate over a million organizations have already been affected worldwide, including the U.S., Australia and everywhere in between, and the number is only increasing.”
At this time IoT_Reaper (Reaper) is propagating but has not been observed launching attacks. The current versionof the malware (1.07) does not contain attack code and restricts itself to scanning and exploiting new potential victims.
This calls for some intimate time with Reaper – so I downloaded the latest sample and started examining the little bugger, to see if he really has what it takes to become the next largest IoT botnet.
It’s Mirai… noooo it’s Reaper!
Running the sample through virustotal.com, the link with Mirai is more than obvious. Out of the 20 engines that detected the malicious file, the vast majority reports it as being Mirai.
Besides closely resembling architecture of IoT_Reaper, the bot itself does not expose a lot of Mirai characteristics. It might be based on the Mirai source, but it has undergone a serious transformation in terms of exploits, command and control, and omits all of the Mirai attack vectors. But it ships with an integrated Lua execution environment, which might prove more flexible and agile in terms of adding new attack vectors compared to hardcoding them.
Reaper uses the same distributed scanning and central loading architecture which made Mirai so effective in terms of harvesting bots. However, instead of doing aggressive, asynchronous SYN scans for open Telnet ports, Reaper performs a more elaborate, conservative TCP SYN scan on a series of different ports, one IP at a time. The SYN scan is always performed in the same sequence and the source IP and source port of the scan is the same for the lifetime of the bot. The sequence of destination port scans for each victim is:
20480, 20736, 36895, 37151, 22528, 16671, 14340, 20992, 4135, 64288, 45090, 21248, 21504, 31775, 39455, 47115, 42254
After the first wave of TCP SYN scans on the victim, a second wave of TCP SYN scans starts consisting of potential IoT web service ports:
80, 81, 82, 83, 84, 88, 1080, 3000, 3749, 8001, 8060, 8080, 8081, 8090, 8443, 8880, 10000
During the second wave the source port of the TCP SYN packet varies, while the source IP remains the IP of the infected device scanning for new victims.
Based on the results of the last SYN port scan, the bot starts a series of nine HTTP-based exploits for each open port on the victim.
[You might also like: The Expansion of IoT since Mirai.]
9 known IoT vulnerabilities
As of version 1.06 and 1.07, Reaper contains exploits based on nine published IoT vulnerabilities.
1: Exploiting an unauthenticated Remote Command Execution (REC) to dump the contents of /var/passwd based on DLink DIR-600 and DIR-300 vulnerabilities published Feb 4, 2013.
2: Exploiting of CVE-2017-8225, a Pre-Authentication Info Leak containing clear text credentials within the custom GoAhead HTTP server included in several IP cameras. A vulnerability disclosed and published by Pierre Kim on March 8, 2017. The exploit as coded in Reaper dumps the system.ini of the IP cameras and is able to retrieve the admin credentials in doing so.
3: Exploiting the Netgear ReadyNAS Surveillance unauthenticated Remote Command Execution vulnerability as reported by SecuriTeam Blogs on Sept 27, 2017. Remark that Netgear has released a patch to address the vulnerability.
Looking closer at the exploit as executed by Reaper in the picture above, remark how the command to be executed is ‘echo nuuo 123456’. While the first two exploits were gathering information, the latter one is verifying the success of the potential remote code execution. If the RCE is successful, the findings of the successful exploit are communicated back to the central reporting server for further processing and infection by the loader service.
4: Exploiting of Vacron NVR through Remote Command Execution as published by SecuriTeam Blogs on Oct 8, 2017. The unauthenticated RCE is used to dump /etc/passwd contents of the victim.
As per the report by Securiteam, Vacron did not answer repeated attempts to disclose the vulnerability, and at the time of writing there is no known solution or workaround to prevent Vacron devices from being exploited.
[You might also like: BrickerBot only attacks compromised devices]
5: Exploiting an unauthenticated RCE to list user accounts and their clear text passwords on D-Link 850L wireless routers. This vulnerability was published as part of multiple vulnerabilities on Aug 8, 2017.
DLink has released patches to address these vulnerabilities through firmware 1.14B07 BETA.
6: Exploiting a Linksys E1500/E2500 vulnerability caused by missing input validation, resulting in an injected shell command being executed. Vulnerability published Feb 5, 2013.
The URL-decoded POST payload ‘ping_ip=; AAA***BBB||| ;&ping_size=&ping_times=5&traceroute_ip=’ most probably tests the validity of the exploit. The vulnerability details that one must be authenticated for the exploit to work, so the validity of this exploit is not certain at this point.
7: Exploiting of Netgear DGN DSL modems and routers using an unauthenticated Remote Command Execution dated back as far as May 31, 2013.
The exploit passes ‘echo dgn 123456’ as ‘cmd’ argument in the GET request and upon execution of the command validates the devices as vulnerable.
8: Exploiting of AVTech IP cameras, DVRs and NVRs through an unauthenticated information leak and authentication bypass which gives access to all account information of the device. Vulnerability published on Oct 11, 2016.
AVTech was contacted multiple times but without any response, this vulnerability is probably not fixed as of yet.
9: Exploiting DVRs running a custom web server with the distinctive HTTP Server header ‘JAWS/1.0’. Pentest Partners published an unauthenticated remote command execution which Reaper tests by attempting to execute ‘echo jaws 123456; cat /proc/cpuinfo’. Upon validation, the exploit is passed on to the central report server for further exploiting and infection of the victim.
Command and Control
During start-up the bot performs two DNS requests to resolve ‘weruuoqweiur.com’ and ‘e.hl852.com.’ The first domain resolves to 110.110.110.110 and it is not clear at this time what its use is. The second hostname resolves to IP address 27.102.101.121 and is the control server.
[You might also like: BusyBox Botnet Mirai – the warning we’ve all been waiting for?]
Every 10 seconds the bot reports back to the control server through HTTP, providing mac address, type, and version of bot malware.
Chinese Roots?
Digging for the domain name weruuoqweiur.com, the name was registered Oct 10th, 2017 through registrar HiChina Zhicheng Technology Ltd. by a registrant from Jangzhou, Zhejiang in China.
When accessing the command and control server it greets with Chinese messages.
Detecting Reaper – device IOCs
The executing malware consists of five active processes which are obfuscated by random names and for which the parent of the group hangs of off ‘init’ (pid 1).
While the malware runs on the victim’s device, its first operation is removing the /var/log entry. Missing /var/log or missing history under /var/log after reboot are an indication of compromise by Reaper.
The malware also listens on port 23 (Telnet) for all interfaces, and all processes listen on port 48099 on localhost.
Detecting Reaper – Network Inbound
Look for a sequence of TCP SYN scans originating from the same source IP and source port to destination ports:
20480, 20736, 36895, 37151, 22528, 16671, 14340, 20992, 4135, 64288, 45090, 21248, 21504, 31775, 39455, 47115, 42254
Detecting Reaper – HTTP Exploits
Reaper uses only HTTP-based exploits and by consequence these are easily detectable by IPS or DPI.
Check for protocol HTTP on ports 80, 81, 82, 83, 84, 88, 1080, 3000, 3749, 8001, 8060, 8080, 8081, 8090, 8443, 8880, 10000 and payloads as described in the exploits – see below:
So, is it an evolved Mirai?
If Reaper is based on Mirai’s source, which is very probable, it has received some very impacting changes but keeps the efficient distributed scan, central loader architecture which is characterizing for the Mirai botnet.
Compared to Mirai, the SYN scanning in Reaper is much more elaborate but less aggressive.
[You might also like: The offspring of two comic book giants bring us the Bot Squad! Super freaky!]
Reaper does not use Telnet brute force with default credentials but uses HTTP-based exploits of known vulnerabilities in IoT devices including Dlink, Netgear, Vacron, Linksys, AVTech, etc.Reaper does not include the TR069 NewNTPServer1 Remote Command Execution exploit used by the Mirai variant during the attacks on DT, TalkTalk and Post UK last November.
Command and Control uses unencrypted HTTP which checks in with the C2 server every 10 seconds; Mirai for its part uses a clear text, always-on TCP connection between the client and C2 server.
Is Reaper sophisticated?
The most sophisticated IoT botnet known to date is Hajime, discovered two days before the Dyn attacks and clocking in on about 300,000 devices at its peak in April of 2017. Still today, over 30% of our IoT honeypot activity is attributed to Hajime.
Compared to the unsophisticated, unencrypted HTTP protocol used by Reaper, Hajime uses multiple trackerless BitTorrent channels with daily changing infohashes, while encrypting all C2 traffic across the BitTorrent channels using public/private key RC4.
Hajime does not contain such an elaborate number of IoT exploits to infect IoT devices, but does leverage the default passwords dictionary of Mirai for Telnet bruting while it adds the Arris password of the day and TR069 NewNTPServer RCE exploits.
How serious is this threat? Is a storm imminent? Can we stop it?
The control servers, the architecture and the methods of operation of the Reaper botnet have been uncovered and are known. It is not as sophisticated compared to Hajime and it uses a fixed domain and IP addresses for its C2 servers, which should make blacklisting or blackholing effective to stop any attacks it might attempt.
I’m not sure why the servers are still active at this moment, but they have been identified and are known.
Reaper uses very specific methods to find new victims and infect those victims. IPS signatures can easily be crafted to block the further discovery and spreading of new victim devices. The exploits are not very sophisticated, they are all HTTP-based and can be blocked with simple signatures at gateway level. The bot is mainly using security vulnerabilities that were uncovered in the last four years by security researchers, while limiting itself to use exploits to gather information. Only once exploits are validated will a central loader server leverage these to install the malware. Blacklisting and blackholing of the loader server is certainly a potential solution to stop the infection and spreading of the botnet.
The communication from infected devices to their central server is done in clear text HTTP with a fixed pattern. The clients check in every 10 seconds with the server and most probably this channel will be used to deliver commands and attack scripts if or when the malware gets armed and activated by its authors. The server domains, IP addresses and the HTTP requests are easily identified and blocked at gateway level.
The threat does exist from the hundreds of thousands of devices that are not protected in any way by a firewall or gateway. There is unfortunately not much that can be done to protect those devices and prevent them from joining the army of Reaper-bots. That said, blackholing the servers at ISP level will render those devices useless zombies until rebooted and cleaned from any infection.
[You might also like: IoT Threats: Whose problem is it?]
We can also trust in our allies, good and bad, such as Hajime and BrickerBot to try to keep the upper hand in the war on IoT devices. I do not agree with the ways of the Janit0r or BrickerBot, but if devices are left unsecured, uncontrolled and unprotected by any form of firewall or gateway, I prefer them disabled rather than becoming a weapon that could destabilize online businesses or the cloud economy.
Concluding remarks
There is nothing new in the threat that is forming that we did not face at the end of 2016 and over the course of 2017. The IoT botnets have impacted the economy of the DDoS attacks and brought them within reach of anyone, technically and price-wise. DDoS campaigns by disgruntled users or customers, competitors, ransom DDoS campaigns, hacktivist campaigns…they have become a part of the consistent threat we all have to live with. A more pressing issue caused by IoT botnets is the complexity of the attacks, which caused a shift in the threat landscape forcing us to find new, better and faster ways to detect and protect customers.
The biggest threat everyone should be scared about is that of the possibility for fragmented IoT botnets to get overrun by one strong and efficient botnet which can win the battle for IoT devices on every occasion, and will create a super-botnet of unequal and unseen size. Iot_Reaper has been thought of as a potential candidate, but all indicators lead one to believe that this will not be the case. At least not if it does not evolve and the authors of Reaper shift gears to provide more sophisticated malware and command & control infrastructure. I’m certainly not ruling out that there is a real and imminent threat – the one who creates a malware that spreads faster and more efficiently across IoT devices will hold the world of the internet in its power and will be able to cause a lot of damage and downtime. Combining multiple exploits of known and unknown vulnerabilities will certainly pay off, and this is the strategy IoT_Reaper chose to adopt, albeit not fully implemented and ready for primetime before it was uncovered.
We need to stay vigilant and detect threats in their early development stage, like was the case with IoT_Reaper. Kudos to Netlab 360 and CheckPoint for pointing all of our cyber noses in the right direction. Together, as a community, we can fend off the threats that might emerge from it.
We have been living with Hajime for a year now. This botnet is assumingly 300,000 devices large and could be used for devastating attacks, but for now it has been helping IoT by protecting them from further abuse. Sometimes unconventional solutions are needed to solve unconventional problems for which we cannot provide immediate conventional solutions.
To read the alert from our ERT Team, click here: Reaper Botnet
