Author: Guy Rosefelt – Dir, PM Threat Intelligence & Web Security
Recently, NSFOCUS has seen some interesting DDoS behavior. Since Q4 of last year, there has been a rise in SSL/VPN and SSH based DDoS attacks. Most people would not equate VPN or SSH as a viable mechanism for what is usually considered a volumetric art form, and they would be correct. But volumetric attacks are not the goal here; targeted VPN/SSH DDoS attacks reduce the ability to determine attribution.
How would this work? How could this be?? What am I having for lunch today??? The first two questions are relatively easy to answer; the third not so much. How would this work?
Threat actors are always looking for new ways to exploit things and not get caught. One of the good things about DDoS attacks is that not much effort is required to determine where the attacking botnet came from – one just has to look at the source IPs of the incoming DDoS packets. Since botnets can be easily identified, their active lifespan is rather short as their IP addresses are quickly blocked. Such a waste of time and resources to build a good functioning botnet only to have it blocked after only a few attacks.
But wait! What if there was a way to obfuscate the source IP addresses and prolong the short fleeting life of a well-crafted botnet? This is where the beauty of using VPN/SSH tunnels comes in. Most VPN tunnels apply network address translation (NAT) to the traffic passing through the tunnels. This is to minimize network routing issues. But a secondary benefit of NAT is that it masks the true source IP of the packets in the tunnel. So if one could compromise a VPN/SSH server and bent pipe (redirect) an attack through it, the source of the attack packets is hidden from the target.
Conversely, if I could take over the systems running the VPN/SSH clients, they would make a great botnet army whose attacks all look like they come from the VPN server the clients are connected to. In either case, many VPN servers do not keep the logs of VPN IP addresses assigned to clients for privacy and storage reasons, so trying to determine the true source IP of DDoS traffic becomes very difficult to determine.
But how can this be?? Many people have said to me, “but, Guy! What have you been smoking to fuel such ridiculous and fanciful notions. To those, I say, “nay! I have something that resembles proof! It may not be irrefutable, but it is a start!”
NSFOCUS monitors lots of DDOS traffic passing through our infrastructure and partner networks around the world. When we locate the sources of a DDoS attack, we try to scan those sources to determine what processes/software are running that might be the trigger for the attack. Recently, NSFOCUS has traced attacks back to devices running Dropbear.
Dropbear is a small open source SSH server and client app that runs on many POSIX platforms. I said “devices” and not “servers” for a reason – because of Dropbear’s small size and being free, it is used in a lot of embedded systems, like routers, IoT devices, etc. Below is a slide that shows recent DDoS activity coming from sources running Dropbear.
You might be yelling at your computer screen, “but, Guy! How can that be?? Why are you dumping on Dropbear in the woods??” Easy my friend, I have what I like to call “facts”, and not alternative ones. In the past year, there have been a number of vulnerabilities found against Dropbear. Almost all allow arbitrary code execution. Other known vulnerabilities can facilitate session hijacking or Man-in-the-Middle (MTM) attacks within a SSH tunnel. All in all, lots of opportunities for mischief by a diligent attacker.
Some of these vulnerabilities are still outstanding since the latest version of Dropbear was released in July 2016.What am I having for lunch today??? Still not sure but leaning towards a hot dog. What I am sure about is that there are over 11 million devices running Dropbear and all have the potential to facilitate and obfuscate a DDoS attack.
And there isn’t a whole lot that can be done to mitigate that. Some suggestions are
- Enable logging to track connections to and through Dropbear server and client.
- Make sure your endpoint protection/anti-virus are up to date. More importantly enable your client firewall to prevent external access to the Dropbear client.
- Disable any remote access to the embedded device running Dropbear
I am hoping to find hard evidence that Dropbear was involved in DDoS attacks. If so, I will present what I find here. Until then, to paraphrase another famous bear, “only you can prevent your devices from launching DDoS.”
