Just days after it was revealed that a distributed denial-of-service
(DDoS) attack on GitHub had been measured at a record-breaking
peak of 1.35 terabits per second, another attack has raced past, and claimed the world record at a mind-blowing 1.7 Tbps.
To give these figures some context, the notorious DDoS attack on the DNS provider Dyn in October 2016, which saw was speculated to have a magnitude in the range of 1.2 Tbps.
The Dyn attack was orchestrated by the Mirai botnet, which hijacked millions of poorly-secured IoT devices to bombard Dyn with unwanted traffic.
The attacks against GitHub, and the most recently announced world-record-breaking attack on an unnamed customer of a US-based service provider, are reflection/amplification attacks exploiting the many publicly accessible servers running memcached, an open-source distributed caching utility.
Memcached (pronounced “Mem-cache-dee”) is not supposed to be installed on servers that are exposed to the internet – because it simply doesn’t have security features to protect itself from malicious attackers in the first place.
Online criminals can exploit memcached database servers to amplify attacks against a targeted online service. An attacker spoofing the UPD address of their intended victim can send just a small packet of data to a memcached server, tricking it into blasting as much as 50,000 times more data in response.
The result? A data tsunami.
As an Arbor Networks blog post describes, it is critically important for companies to protect themselves as in all likelihood the problem isn’t going away:
While the internet community is coming together to shut down access to the many open mecached servers out there, the sheer number of servers running memcached openly will make this a lasting vulnerability that attackers will exploit.
To make sure you aren’t part of the problem you need to ensure that perimeter firewalls are blocking UDP, or better yet that UDP is disabled entirely on memcached servers.
This is a Security Bloggers Network syndicated blog post authored by Graham Cluley. Read the original post at: HOTforSecurity