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

Mike Hammett nanog at ics-il.net
Wed Feb 28 20:57:42 UTC 2018


They ship it by default firewalled from the Internet. 




----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

----- Original Message -----

From: "Denys Fedoryshchenko" <denys at visp.net.lb> 
To: nanog at nanog.org 
Sent: Wednesday, February 28, 2018 6:42:37 AM 
Subject: Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks 

I want to add one software vendor, who is major contributor to ddos 
attacks. 
Mikrotik till now shipping their quite popular routers, with wide open 
DNS recursor, 
that don't have even mechanism for ACL in it. Significant part of DNS 
amplification attacks 
are such Mikrotik recursors. 
They don't care till now. 

On 2018-02-28 14:31, Job Snijders wrote: 
> Dear all, 
> 
> Before the group takes on the pitchforks and torches and travels down 
> to 
> the hosting providers' headquarters - let's take a step back and look 
> at 
> the root of this issue: the memcached software has failed both the 
> Internet community and its own memcached users. 
> 
> It is INSANE that memcached is/was[1] shipping with default settings 
> that make the daemon listen and respond on UDP on INADDR_ANY. Did 
> nobody 
> take notes during the protocol wars where we were fodder for all the 
> CHARGEN & NTP ordnance? 
> 
> The memcached software shipped with a crazy default that required no 
> authentication - allowing everyone to interact with the daemon. This is 
> an incredibly risky proposition for memcached users from a 
> confidentiality perspective; and on top of that the amplification 
> factor 
> is up to 15,000x. WHAT?! 
> 
> And this isn't even new information, open key/value stores have been a 
> security research topic for a number of years, these folks reported 
> that 
> in the 2015/2016 time frame they observed more than 100,000 open 
> memcached instances: https://aperture-labs.org/pdf/safeconf16.pdf 
> 
> Vendors need to ensure that a default installation of their software 
> does not pose an immediate liability to the user itself and those 
> around 
> them. No software is deployed in a vacuum. 
> 
> A great example of how to approach things is the behavior of the 
> PowerDNS DNS recursor: this recursor - out of the box - binds to only 
> 127.0.0.1, and blocks queries from RFC 1918 space. An operator has to 
> consciously perform multiple steps to make it into the danger zone. 
> This is how things should be. 
> 
> Kind regards, 
> 
> Job 
> 
> [1]: 
> https://github.com/memcached/memcached/commit/dbb7a8af90054bf4ef51f5814ef7ceb17d83d974 
> 
> ps. promiscuous defaults are bad, mmkay? 
> Ask your BGP vendor for RFC 8212 support today! :-) 




More information about the NANOG mailing list