A record-breaking attack on GitHub
On February 28, Github was the target of a massive DDoS attack. This attack was unusual in several ways, and there are some interesting lessons we can learn from it.
First, this was a record-breaking attack. It reached a peak of 1.35 Tbps, handily eclipsing the previous record of 1.2 Tbps in 2016.
To mount an attack on this scale, the attacker accomplished a remarkable level of amplification: a factor of 51,000. In other words, for every byte the attacker sent out, 51 kbytes were sent to GitHub.
This DDoS was also remarkable because it used an amplification attack on UDP port 11211, using memcached servers accessible via the public Internet. According to DDoSMon, memcache had previously represented a mere 0.8% of protocols used for reflection attacks. Suddenly, this little-used protocol became responsible for the biggest to-date attack seen on the Internet.
Also, this might not even be the biggest attack that this exploit ultimately will produce. GitHub did not report the number of source IPs for its attack, but the day before the DDoS occurred, Cloudflare reported a massive jump in memcached attacks, originating from 5,729 unique IPs.
If this is representative of the resources used to attack GitHub, then it was only a small fraction of the resources available to the attacker. According to Shodan, there are currently over 100,000 memcached servers exposed to the public Internet.
Thankfully, the memcached developers reacted quickly to the Github attack. They have committed a patch which disables UDP by default. Of course, this will take quite some time before it becomes part of a release and then gets distributed to, and installed on, the 100,000+ servers currently running this service.
Meanwhile, the vulnerability remains. It’s a safe bet that right at this moment, many sys admins are busy putting their memcached servers behind firewalls. But it’s an equally safe bet that many more are oblivious to this problem, or are just downright negligent.
So what can we learn from this? Several things. First, GitHub has not described any apparent motive for this attack — they didn’t mention any ransom demands or other attempted monetization by the attacker.
It would seem that GitHub was targeted just because it’s a well-known company. Perhaps the attacker was testing his capabilities, or demonstrating them to potential customers of his illicit services.
In any case, merely having a prominent site today is enough to raise your risk of being attacked.
Second, the exploit was successful because of the large number of memcached servers exposed to the Internet, even when there was no need for them to be publicly accessible. Some industry observers attribute this to the growing popularity of DIY cloud products, many of which include server platforms that were intended to be used only by admins who know what they’re doing (and who would disable unnecessary services, close unused ports, and so on).
Whatever the reason is, it’s clear that a large number of insufficiently hardened servers are on the Internet. There’s no reason to expect this situation to improve any time soon.
Third, this incident highlights the creativity of the black hat community. New attack vectors are always being invented. And even obscure protocols can suddenly be responsible for record-breaking assaults.
Lastly, when Github was attacked, it implemented countermeasures and restored reliable service to its users in only nine minutes. (Many kudos to the engineering team members who recognized the problem, reacted quickly, and solved it, all in that time.) Yet the potential harm of even this short outage caused Github to apologize to its users.
The potential financial damage of a successful DDoS (even a short one) grows higher all the time. And so does the importance of remaining vigilant against attacks, both DDoS or otherwise.
