[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Testing on a recently-load VM of CentOS 7.3:

[root at localhost odd]# netstat -tan | grep 11211
[root at localhost odd]# netstat -uan | grep 11211
[root at localhost odd]# yum install memcached
[root at localhost odd]# systemctl start memcached.service
[root at localhost odd]# netstat -tan | grep 11211
tcp        0      0 *   LISTEN
tcp6       0      0 :::11211                :::*        LISTEN
[root at localhost odd]# netstat -uan | grep 11211
udp        0      0 * 

udp6       0      0 :::11211                :::* 

Since CentOS is supposed to be a near bit-by-bit copy of Red Hat 
Enterprise, this shows that when one loads memcached without modifying 
the configuration, plus expose 11211/udp to the world, one is now part 
of the problem.

It also suggests that other near-clones of RHEL may also exhibit the 

So I pulled the memcached repository from GitHub, and looked through the 
commits. NOTHING about updates to prevent DDoS.

So I started looking around for the config file in the maintainer GIT 
project.  Here is what I found:

> # These defaults will be used by every memcached instance, unless overridden
> # by values in /etc/sysconfig/memcached.<port>
> USER="nobody"
> MAXCONN="1024"
> # The PORT variable will only be used by memcached.service, not by
> # memcached at xxxxx services, which will use the xxxxx
> PORT="11211"

Here is what CentOS has:

> PORT="11211"
> USER="memcached"
> MAXCONN="1024"

What's missing from both of these system configuration files?


 From the memcached man page:

> -U <num>
>    Listen on UDP port <num>, the default is port 11211, 0 is off.

So this answers the question about how anyone loading memcached fresh 
from a distribution can be a major player in the DDoS game.

Now, in a lame defense of Red Hat, when one turns on the firewalld 
daemon, that daemon implements a mostly-closed access policy. 
"memcached" is not listed in the named services.  Furthermore, looking 
at the output of 'iptables -vnL' I saw no way that a 11211/udp packet 
would make its way through the firewall.

The policy of "defense in depth" would argue that setting the default to 
disable 11211/udp is still the right thing(r) to do.