GitHub was hit by the most powerful DDoS attack in history

Last week saw the largest distributed denial-of-service (DDoS) attack in history.

GitHub was hit by a record-breaking attack which peaked at some 1.35 terabits per second (outstripping the notorious DDoS attack on Dyn, which knocked the likes of Twitter, Spotify, Reddit, and umm.. yeah, GitHub, offline back in October 2016.)

A short while later a second attack wave against GitHub peaked at a mildly more bearable 400 Gbps.

This latest attack on GitHub exploited a newly-disclosed reflection/amplification vulnerability on servers running Memcached, an open-source distributed caching utility, in order to generate large amounts of unwanted traffic – swamping the attacker’s target.

As The Register describes, Memcached is not supposed to be installed on internet-facing systems in the first place.

Memcached’s own documentation is quite upfront about the fact that it is not designed to be exposed to the wilds of the internet:

“By default memcached listens on TCP and UDP ports, both 11211. -l allows you to bind to specific interfaces or IP addresses. Memcached does not spend much, if any, effort in ensuring its defensibility from random internet connections. So you must not expose memcached directly to the internet, or otherwise any untrusted users. Using SASL authentication here helps, but should not be totally trusted.”

Fortunately, it shouldn’t be too hard for businesses to ensure that UDP is disabled on servers running Memcached, or that perimeter firewalls are blocking UDP.

What impresses me, however, is not the size of this particular DDoS attack but rather that GitHub appears to have been able to get itself back on its feet after a mere nine minutes:

On Wednesday, February 28, 2018 GitHub.com was unavailable from 17:21 to 17:26 UTC and intermittently unavailable from 17:26 to 17:30 UTC due to a distributed denial-of-service (DDoS) attack. We understand how much you rely on GitHub and we know the availability of our service is of critical importance to our users. To note, at no point was the confidentiality or integrity of your data at risk.

There’s a good blog post by Barry Raveendran Greene, principal architect at Akamai, where he describes in technical terms what businesses can do to prevent themselves from contributing to the problem.

If we fail to behave as responsible members of the internet community, we risk causing problems for our online neighbours.

Update: Well that world record didn’t last long.

Found this article interesting? Follow Graham Cluley on Twitter, Mastodon, or Threads to read more of the exclusive content we post.

Graham Cluley •   @gcluley

Graham Cluley is an award-winning keynote speaker who has given presentations around the world about cybersecurity, hackers, and online privacy. A veteran of the computer security industry since the early 1990s, he wrote the first ever version of Dr Solomon's Anti-Virus Toolkit for Windows, makes regular media appearances, and is the co-host of the popular "Smashing Security" podcast. Follow him on Twitter, Mastodon, Threads, Bluesky, or drop him an email.