Our Exposed World – Old exposures, new attacks

2018-03-03T16:28:01
ID TRENDMICROBLOG:DDD9049BF6CA42FA00574DB614462811
Type trendmicroblog
Reporter Natasha Hellberg (Senior Threat Researcher)
Modified 2018-03-03T16:28:01

Description

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:

|

  • Read up on memcache attacks (both Arbor and 360 Netlab have excellent analysis of these attacks)
  • Ensure your networks have good traffic monitoring (both in and outbound!) using Trend network intrusion tools (like DDI and TippingPoint)
  • Ensure you have more than one upstream provider so you can fail over to other links should the primary become flooded
  • Ensure your network providers have implemented anti-spoofing (such as BCP38 & 84) to ensure spoofed packets such as those used in DDoS reflection attacks do not make it to your network in the first place!
    ---|---
    |

As part of looking into this attack vector, several members of the security community assisted. I would like to say thanks to these folks, along specifically with both Damien Menscher of Google for his assistance in understanding the protocol and interaction as attack traffic, and John Matherly of Shodan for assistance with assessing the global impact.

The post Our Exposed World – Old exposures, new attacks appeared first on .