My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Why we Don't Deserve the Internet: Memcached Reflected DDoS Attacks.

Published: 2018-02-27. Last Updated: 2018-02-27 18:39:29 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Let me start off by saying: If you have a memcached server in your environment that is exposed to the internet, then you should stop scanning for them, and spend your time writing a resume instead. Either because you do not want to work in an utterly incompetent organization like that, or if you are responsible for the exposed server, then well.. write a resume for a simpler job. (I was going to suggest a job here. But I can't come up with a job a sysadmin would be qualified for in a case like this)

Ok. Enough victim bashing (but in this case, you deserve it). The problem: Apparently people are exposing memcached to the internet. For many other services, I would qualify that statement: "without access control". But for memcached there is no access control. This is by design. You are not supposed to expose memcached to the internet, and it says so right in the configuration file:

# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1

So what will happen if you do expose your memcached server? Imagine that: All your data will be "messed up" (that is a technical term people who do expose memcached servers may understand)

But not only that. memcached offers a simple "stats" command, that will return statistics about the memcached server. Since memcached typically talks via UDP (but TCP works too), you can send the "stats" command from a spoofed IP address. The payload will be 15 bytes. The reply on the other hand will be at least around 1500 bytes, but can be several 100 kBytes in size. 

So you got yourself a classic reflective amplified DDoS attack. Luckily, it isn't too hard to block. You should see traffic *from* port 11211 if you are hit by this attack. Blocking all traffic from port 11211 should be possible as all modern operating systems tend to use a source port higher than that for client connections. But given the traffic volumes people are seeing, you will likely need help "upstream" or from an anti-DDoS company.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Keywords:
3 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Didn't adjit puanane pie kill title II protection of the internet for Verizon and their FiOS? So what excuse do the major carriers have now for not preventing these amplification attacks?
You probably won't approve this out of the moderator queue, but as righteous as you sound I would kind of expect someone with a Ph.D to have a better grasp of how the amplification attack is working in practice. Only a complete rookie would issue the stats command as part of their amplification attack. The real attack vector is to "set" a 1 MB key value pair with the key being a one character string and the value being random gibberish. Then to actually launch the attack you spam "gets" requests and fill the "gets" request with as many one character values as you can store in a 1500 byte packet. And obviously you spoof the source IP to your designated target but that goes without saying.
I had not yet observed that trick in my honeypot at the time I wrote the article, but this makes a lot of sense and explains the large amplification factors reported. Thanks for the correction.

Diary Archives