Following the record-breaking Distributed Denial of Service Attacks (DDoS) that targeted both Github and a yet unnamed US-based company, referred to as a service provider in various reports, a surge in Memcached DDoS research and proof of concept code was bound to come up. Recently two proof of concept attacks has been published online illustrating a surge in popularity of attempting such a reflective DDoS attack.
Both the record-breaking attacks have shone a light on Memcached DDoS attacks, more so than previous research warning of the possibility of such attacks, but what exactly is a Memcached DDoS attack? In such an attack, the attacker targets Memcached servers that are exposed online. Memcached servers allow applications that need to access a lot of data from an external database to cache some of the data in memory, which can be accessed much more quickly by the application than having to travel out to the database to fetch something important. Such servers have been used by companies to speed up page load time and deal with spikes in demand.
These servers have been used internally, disconnected from the public internet but accessible within a trusted network to improve internal application performance in the past which would mean they would not be an easy target for such an attack. However, recently it would appear that such servers have a default setting which exposed UDP (user datagram protocol) online.
Proof of Concept Code
The first proof of concept code was published by the infosec researcher behind the Spuz.me blog who called it Memcacrashed.py. The toll is a Python script that scans Shodan for IPs of vulnerable Memcached servers and allows a user to launch a DDoS attack against the desired target within seconds of running the tool. The second proof of concept was released on Pastebin on Monday with the author been unknown. The code is written in C. What makes this proof of concept unique is that it comes with a list of over 17,000 IPs belonging to vulnerable Memcached servers. The code will launch DDoS attacks against the listed servers and amplify the traffic towards the targeted servers resulting in a denial of service.
Memcached attacks gained a lot of attention in the infosec community from the end of February 2018 when Cloudflare, Akamai, and Arbor published reports detailing in detail a surge in popularity of attackers using such attacks. It was, in particular, Cloudflare’s report that drew a lot of attention as it illustrated how Memcached servers would amplify incoming UDP packets for up to 51,200 times, allowing an attacker with a small bandwidth to launch humongous-sized DDoS attacks. This massive amplification results from the UDP protocol not being implemented correctly that would allow the server to send information packets that are sometimes thousands of times bigger than the initial request rather than the expected packet to be of similar or smaller size. As the packet's origin IP address can be faked rather easily the attacker can trick the Memcached server into sending this oversized response packets to another IP address. This, in turn, results in the possibility of a DDoS attack being carried out. In the DDoS community, this type of DDoS attack is named reflective DDoS or reflection DDoS. The amount of times the response packet size is amplified is the DDoS attack's “amplification factor” and as Cloudflare proved Memcached attacks have the potential for a massive “amplification factor”.
In late 2017 the researchers at Okee Team published a report detailing their discovery of a Memcached DDoS attack vector. The report flew largely under the radar and received little notice from the community at large. In hindsight, it is perhaps a failing of the infosec community that this research was widely ignored for details covered within it were to become reality. On March 1, 2018, reports began surfacing that Github experienced a 1.3 Tbps (Terabits-per-second) DDoS attack utilizing the UDP flaw found in Memcached servers. In a press release issued to the public by Github, it was confirmed that on February 28, the website 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. In the release, the attack was directly attributed to what Cloudflare described in their report as a Memcached DDoS attack. The attack peaked at 1.35Tbps via 126.9 million packets per second placing the attack in the record books albeit briefly.
A mere four days after the Github DDoS attack researchers at Arbor Networks reported that an attack aimed at a yet unnamed “US Service Provider” clocked in at 1.7 Tbps and like the Github attack this one was also carried out via Memcached servers left exposed online. While these attacks have literally smashed the record set by previous attacks experts are predicting that 2 Tbps attacks are a possibility. Security firms like Arbor and Akamai are seeing such Memcached based DDoS attacks more frequently since last week with some in the industry believing the source of the attacks appear to be DDoS-for-hire services operating out of China. As of yet, no suspect has been named.
Admins Resisting Countermeasures
Initially, when news broke of these attacks it was estimated that approximately 134,000 Memcached servers were easily viewable online, this number has reduced to 93,000, this is still an incredibly large number for potential attackers to exploit. While it could be seen in a significant reduction in targetable servers, the UDP flaw can is to update the Memcached server. Admins are loathe to do this as it can reportedly take a substantial amount of time to do this. This is despite researchers pleading with Memcached server owners to disable their UDP port if they're not using it and place these servers on private networks and importantly behind firewalls. As it stands Corero Network Security has published details on a killswitch which can be used by those under attack. In summary, the “kill switch” sends a command back to the attackers' server to suppress the current DDoS exploitation. This invalidates the cache of a vulnerable server, including attackers' potentially malicious payload.