New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

Stephen Satchell list at satchell.net
Fri Mar 2 16:15:42 UTC 2018


On 03/01/2018 02:55 PM, Royce Williams wrote:
> pstream, until two days ago, the default was to listen on all interfaces.
> 
> https://github.com/memcached/memcached/wiki/ReleaseNotes156
> 
> The package maintainers were (thankfully) injecting additional sanity.

Yes, they did, in commit dbb7a8af.  Here is the commit comment:

>     disable UDP port by default
>     
>     As reported, UDP amplification attacks have started to use insecure
>     internet-exposed memcached instances. UDP used to be a lot more popular as a
>     transport for memcached many years ago, but I'm not aware of many recent
>     users.
>     
>     Ten years ago, the TCP connection overhead from many clients was relatively
>     high (dozens or hundreds per client server), but these days many clients are
>     batched, or user fewer processes, or simply anre't worried about it.
>     
>     While changing the default to listen on localhost only would also help, the
>     true culprit is UDP. There are many more use cases for using memcached over
>     the network than there are for using the UDP protocol.
> 
> --------------------------------- memcached.c ---------------------------------
> index 88a5f2e..7178666 100644

But then you look at the changes in that commit:  what makes this a 
less-than-ideal change is that they didn't modify the default 
configuration file to include "-U 0".

By defaulting their settings.udpport to zero in the C code, they 
stop-punch the astonishment factor.  By not changing the distribution 
sysconfig file, though, they open a pitfall for those people who use 
UDP.  The problem?  They could have put a warning in the default file so 
that people who add OPTIONS="U 11211" would be told to firewall that UDP 
port from the public internet at large.

(Then there is the case of people deploying memcached in the cloud, 
which would incur additional difficulties.  But that's another argument...)



More information about the NANOG mailing list