World’s largest DDoS attack thwarted in minutes

What has been tagged the largest DDoS attack ever disclosed slammed into the servers of software development site GitHub at 17:21 UTC last Wednesday.
Large DDoS attacks have become occasional events in recent years but the statistics on this one were memorable, hitting a peak of 1350 gigabits per second with a follow-up reaching 400 gigabits per second.
The previous record attack was on DNS provider Dyn in 2016, whose estimated 1000 gigabits per second peak blast caused visible disruption to services such as Netflix, Twitter and, funnily enough, GitHub.
According to GitHub Engineering, last week’s disruption lasted nine minutes.

At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. … Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai.

Good news – DDoS mitigation defence worked as designed – but the interesting theme of the attack has turned out not to be its size at all, but what fuelled its extraordinary size.
The attack exploited amplification, a technique we’ve seen before in previous mega DDoS incidents, this time hitting a target called Memcached.
Memcached is a popular technology designed to speed access to sites running big web application databases by caching data in RAM for rapid access.

By default, it allows unauthenticated external connections on UDP port 11211, which means the attackers were able to generate large amounts of traffic simply by sending servers left in this weak state a simple “stats” command from a spoofed IP address.
Memcached stats responses turn out to be huge, said GitHub:

The amplification factor is up to 51,000, meaning that for each byte sent by the attacker, up to 51KB is sent toward the target.

This compares favourably with previous amplification attacks such as the 2013 DNS-themed assault on Spamhaus, which boosted responses 50 times to 300 gigabits per second peak.
A year later it was the NTP protocol’s turn to be abused in a 400 gigabits per second attack on French hosting company OVH that exploited an amplification rate of 500 times.
The mitigation companies seem to have suspected something unpleasant was brewing, which might explain why Akamai’s Prolexic division shut it down so rapidly.
Luckily, it’s not that hard to stop using perimeter firewalls to block UDP on the named port or disabling UDP on Memcached servers altogether.
And yet, as with previous amplification attacks, the underlying problem is once again poorly-secured infrastructure – estimates of the number of vulnerable Memcached servers range up to around 100,000, with almost all being in the US and China.
Akamai warned:

Akamai has seen a marked increase in scanning for open Memcached servers since the initial disclosure.

And:

Because of Memcached reflection capabilities, it is highly likely that this record attack will not be the biggest for long.

Someone will now have to persuade the owners of all those vulnerable Memcached servers to close the vulnerability or risk intervention by large ISPs.
Perhaps this time the attackers were testing out a new idea. It has even been suggested it was a ransom attack because there appeared to be an embedded demand for the Monero virtual currency.
The best hope is probably that the speed with which the attack was quelled will put the bad guys off a sequel.