Open-Source Attack Tools Open Pandora’s Box
The act of leaking or flat-out releasing source code of advanced hacking tools isn’t new. It has happened numerous times, especially with high-profile and advanced malware families, such as Zeus, Citadel, Carberp and SpyEye, which have been responsible for losses measuring in the hundreds of millions of dollars. Once dangerous tools are released to the public, they can be downloaded—and modified and enhanced—by anyone.
As security reporter Brian Krebs wrote, “Miscreants who develop malicious software often dump their source code publicly when law enforcement investigators and security firms start sniffing around a little too close to home.”
That can fuel copycats—and “enhanced” copycats. Radware performed a quick test to see how easy or difficult it would be for an average hacker to take the now open-sourced Mirai source code and extend its capabilities with a new, advanced attack vector.
To do this, we considered implementing several advanced attacks that are NOT currently implemented in the original Mirai source code, such as:
1. SSL attacks
2. Layer-7 HTTP attacks with JavaScript support
3. HTTP 2.0 support
GitHub repositories and builds the attack bot binary
From there, we began our experiment. We were able to acquire the Mirai source code in a matter of minutes on GitHub. Compiling the bot binary and building it for the x86 platform took five minutes and did not require any programming skills. In less than an hour, we had managed to integrate another open-source attack tool called thc-ssl-dos, which can be used to launch SSL RENEGOTIATION attacks against Web servers. With some elementary coding skills, we slightly modified the code to stress servers that do not allow SSL renegotiation by rapidly establishing a new TCP connection on each SSL handshake.
[You might also like: Let’s discuss facts: An insight into Mirai’s source-code]
Benchmarking Our Code
We performed some basic benchmarking of our new attack vector capabilities against a target low-end server (Intel Xeon E3-1245V2, 16gb RAM) running Nginx 1.10 Web server (built with OpenSSL 1.0.2g). The client used to launch these attacks was sitting on a different remote server, with a latency of ~15 milliseconds roundtrip time.
our server starts to get “busy” handling the incoming SSL connections
In our test landscape, we have observed that a single instance of our new Mirai code is capable of generating 350 SSL connections per second, which takes 50% of our server CPU resources. Multiple instances easily bring the server to full CPU utilization—dramatically hurting system performance and availability.
For large enterprises with high-end backend servers, load balancers, proxies and the like, 350 SSL connections per second is negligible. However, if we extrapolate this value to 100,000 instances—or even 1,000,000 instances—the resulting numbers are large enough to take down, in theory, every major website.
Of course, we need to remember that an IoT device is running on very low power and with limited CPU/network capabilities. Even so, if we take a factor of x1,000, then an IoT botnet with 20,000 zombies will generate an attack that is 20 times higher than the one we have measured.
The Economics of Botnets
While much has been discussed around Mirai, IoT, “the rise of the machines” and other catchy buzz-phrases, we believe one of the most disruptive changes is the new economics model of IoT botnets.
Not so long ago, hackers were investing a great deal of money, time and effort to scan the Internet for vulnerable servers, build their army of zombie bots and then safeguard it against other hackers who might also want to claim ownership of them. All the while, hackers would keep continual watch for new infection targets that could join their zombie army.
Things have changed: Now we see millions of vulnerable devices sitting with default credentials. Bot masters— the authors and owners of the botnets—do not even bother to secure their bots after infection. After all, as Mirai demonstrates, it does not even persist infection to disk, so a simple device reboot brings it back to a clean and healthy state.
Nevertheless, this will not prevent re-infection. As we now know, it takes less than six minutes to scan the entire IPv4 space—and the time-to-infection of vulnerable devices is constantly dropping. It is now estimated to take less than an hour.
For a bot master, gaining control of powerful servers with 1Gbit cards or 10Gbit cards was considered to be the ultimate goal—the “Holy Grail.” Sometimes a hacker would pay hundreds of dollars every month for it. Often he or she would gain illegal access to it and work very diligently to hide it from others. And finding these servers— then gaining access and maintaining exclusive control—was and still is difficult and expensive.
Now with IoT botnets, we see a different picture. Instead of spending months of effort and hundreds of dollars to control a few powerful servers and several hundred infected PCs, bot masters can take control over millions of IoT devices with near zero cost.
What Now?
To date, the number of connected devices is estimated at 6 billion, while the estimated Internet user count is just 3.5 billion (though expected to grow to 13 billion by 2020).17 This shift points to a different economy—and requires changes in thought and action.
The botnet attacks of 2016 also underscore the need to move beyond IoT security as an afterthought. IoT platforms and devices need to be designed—from the ground up—to be secure. Right now it is far too simple to victimize IoT devices; all it takes is telnet and a limited list of factory default usernames and passwords to generate botnets of unimaginable proportions. And this is only the beginning.
Reducing the potential impact of IoT botnets should be a combined effort by all IoT stakeholders:
1. “Smart appliances” manufacturers need to be mindful of producing resilient products with robust
security components.
2. To protect enterprise customers, network carriers need the ability to detect and manage traffic that originates from such devices.
3. Enterprise customers should understand that when making a security investment to protect their
infrastructure and assets, they need to be able to protect not only against today’s threats, but also against those that will arise in the next three to five years.
The bottom line: The effort and money we’ve been expending to build defenses is no longer proportional to attackers’ investments. It is time to review the attack landscape, re-evaluate the architecture of defense mechanisms and consider how best to defend against higher-order-of-magnitude attacks.
