Our Exposed World – Old exposures, new attacks

Credit to Author: Natasha Hellberg (Senior Threat Researcher)| Date: Sat, 03 Mar 2018 16:28:01 +0000

Natasha Hellberg, Senior Threat Researcher FTR

With assistance from William Gamazo Sanchez, DSLabs

Within the last few days a new player has been introduced into the distribute denial of service (DDoS) amplification attack world and with it brings the potential for much larger DDoS attacks than what we have seen in the past. While most of us think DNS, UpNP/SDP and NTP when we think of protocols that are used in DDoS, memcache has emerged as just as potent of a protocol by which to commit these kinds of attacks. Memcache is a protocol meant to allow for the quick storage and retrieval of data from a server, without all the messy overhead of a database on the back end. Unfortunately, it also has recently been discovered that it makes a great source of amplification and reflection for DDoS.

Within the last few days, Cloudflare and Github have become the first victims of this new DDoS amplification method. In the case of Github, their network telemetry from Akamai indicates at least one wave of the attack hit over 1.35Tbps inbound at their servers:

Figure 1: From https://githubengineering.com/DDoS-incident-report/

Now keep in mind that some of this traffic isn’t attack traffic per se, but additional overhead from networking (handshaking attempts, etc.), in the end it still holds a significant punch. Just to put this in perspective, according to the Akamai SIRT, this attack was twice the size of what was seen for the Mirai attacks in Sept 2016.

Using memcached is actually pretty easy. You send it a key, it sends you back the data associated with that key. And an added benefit is being able to put as many queries into a single request as you’d like.

Figure 2:Creating a memcache attack

In the current attacks, the attackers are making GETS requests against the memcache service to grab whatever data they can on existing keys (steps 3 & 4 in figure 2); however, in many cases the memcache servers are not secured and also allow SET commands (aka putting data INTO the memcache server).  The bad actors can use this to set a key to the maximum data blob allowed, and then make their GETS query to that specific key (steps 1-4 in Figure 2) to maximize the size of their reflection attack against the victim.

While memcache can be installed both in TCP (natively) and UDP, these attacks will be primarily found on UDP Port 11211 as the UDP protocol allows for much easier spoofing of the source address, making it more attractive for reflection type DDoS attacks.

Of the 120,458 (at the time of writing of this blog) memcache servers globally, there are just under 10k servers running memcache on UDP according to Shodan. It is more interesting to note that almost one third of these are being seen in active attacks already.

Now, a key factor in the amplification value of memcache has to do with the data blob returned. Generally speaking, the max byte size for these is relatively small, but in some hosting provider space it can be seen that their memcache configuration allows for much larger data blobs (in some cases over 100G), thus increasing their value in a DDoS amplification attack.

This being said, there are a number of caveats and limitations to the size these attacks might grow to. First and foremost, they are inhibited by the links attached to memcached server being used to reflect the attack. A 1Gbps link is only ever going to send 1Gbps no matter how big of a data blob is created by the attack. Ditto for the network card. And finally, the protocol only allows for two eight byte network sequence numbers (the data blob has to be broken into pieces to be sent across the internet – the sequence numbering allows the other end to know how to put it all back together again (like humpty dumpty!). But with only two bytes that means the maximum number of packets the protocol can return is 65,536 and even I can do the math to say the max size of a single packet is 1428, so that the total volume can only ever be 93.58 megabytes, transmitted across the link speed of the server being reflected off of. Or in other words, as a much wiser colleague pointed out – the request / GETS part can be super large, but it then becomes capped because of the limitations of the packet sequencing. This also begs the question, how does memcached handle data blobs that require sequencing higher than its standard allows for, since handling of these packets does not appear to be specified in the protocol.  Its these questions that I would love more information on.

So, in the end, is the sky falling? Will the internet bottom out? No.  Notwithstanding we are still in the early days of understanding the technical potential of this new attack vector, even with NDP, SSDP, and DNS amplification attacks we did not see a constant barrage of large scale DDoS attacks, and it is unlikely to be the case with memcached either. However, will we see a growth in the size of DDoS attacks when they happen? In all likelihood, yes. As such, just like with other denial of service attacks, here’s what you should do:

http://feeds.trendmicro.com/TrendMicroSimplySecurity