What is a Memcached Attack?
Memcached Attack Description:
Memcached is just one service or process (often called a daemon hence the “d”) that runs on a server. The server itself could primarily be a mail server, a web server, a DNS server, etc. Most of the time the vulnerable Memcached service is there by accident, installed as a default in case anyone wants to use the service. Attackers are exploiting Memcached reflection vulnerabilities to launch large denial-of-service attacks against target organizations.
The Memcached reflection vulnerability has been around for longer than 10 years, but the exploit was demonstrated and explained last year at a conference and its usage in the wild ramped up very recently. Memcached made mainstream news in February and March 2018 as part of the largest DDoS attacks ever reported. The attacks were made against the developer platform GitHub and an unnamed US Service Provider (who may not have been the intended victim but one of their customers may have been). The attacks were terabits in size from worldwide Memcached server requests being ‘amplified’, however, smaller but equally disruptive DDoS attacks were also launched using the Memcached vector. There are many copycat attackers and booter/stresser services that joined the fray since this attack.
This threat uses a reflective amplification method in which the attacker makes a spoofed request (with the source IP address of the intended victim) to a vulnerable Memcached server, which then replies to the victim with a much larger response. These attacks use UDP and will arrive at the victim from source port 11211 and destined for a single victim IP address and sometimes a specific port.
As mentioned above, GitHub was a target of one of the largest DDoS attacks ever, and they reported that the time it took to respond to this attack was around 10 minutes – meaning the attack succeeded in impacting Github services for that length of time. GitHub reported that the delay from detect, to manual decision processes to redirect traffic to scrubbing services plus the convergence delay for the mitigation to kick in comprised the outage delay.
“Detect then redirect” legacy DDoS systems can take tens of minutes to begin mitigation and are ineffective against new attacks for the first 15 minutes – potentially resulting in downtime and infrastructure equipment overload. Human intervention to swing traffic to scrubbing centers causes delays in “time to mitigate” and when added to approvals, and routing table updates it adds up to significant delays before attacks can be stopped.
How Memcached is Used for DDoS Attacks
An attacker looks for vulnerable devices on the internet to use as part of a DDoS attack. The first thing the attacker does is scan the internet for any device responding UDP on port 11211 and builds a list of IPs of those systems that respond on this port as potentially vulnerable systems to exploit. They need to respond on the UDP version of the Memcached service in order to be used as part of a Memcached DDoS attack.
Next, they choose a victim IP from either one that they already have planned to target or one they are being paid to target. They launch their attack by issuing commands to the servers preloaded with the 1Megabyte attack payload in this example but spoofing the source address of the victim, so the response and data goes back to the victim not the attacker and this continues, building up the attack. Corero estimates that you only need to send 4-5 requests to a memcached server per second to get it to unload its full attack potential.
To compound the problem – the attacker can amplify the attack further. They can also request get a a a a a in one command and the memcached server will reply with multiple copies of the same attack payload to the spoofed victim IP.
The Memcached Code
The code requests responses from vulnerable servers, exploiting those servers’ UDP port 11211 to the Internet.
How to Defend Against Memcached DDoS Attacks
Customers of Corero had zero-day protection with Corero’s SmartWall Appliance and Memcached reflection packets were blocked immediately upon arrival, prevented from entering the customer’s protected networks.
Countermeasure – invalidate memcached server cache, stopping attack from that server
These attacks can be very large and what we discovered is that as a countermeasure to the attack, you can send a simple memcached “flush_all” command back to the originating attacking server, defeating the current attack by invalidating its cache and making its malicious payloads useless, until it is reloaded by the attacker.
You can progress through the attacking sip list with a single “flush_all” command to each attacker. The countermeasure invalidate packet has been tested on live attack servers and appears to be 100% effective.
Corero Smartwall detects in seconds, generates evolving top sip list
- Countermeasure can begin immediately with no observed collateral damage
- Packet rate is minimal (reverse of amplification) 1/10,000
- Packet generation is trivial (where xxx.xxx.xxx.xxx is an attacking sip)
- – netcat example
- python -c “print ‘\0\x01\0\0\0\x01\0\0flush_all\r\n'” | nc -nvvu xxx.xxx.xxx.xxx 11211 > /tmp/null
- – /dev/udp example
- echo -ne ‘\0\x01\0\0\0\x01\0\0flush_all\r\n’ > /dev/udp/xxx.xxx.xxx.xxx/11211
The Corero SmartWall® TDS has various protections against Memcached type attacks. The Corero Security Operations Team (SOC) also has in-depth experience in dealing with Memcached attacks and can enable additional mitigation functions for customers not already taking advantage of the SecureWatch® Managed Service offering.
Additional & Related Information: