A new onslaught of massive distributed denial of service (DDoS) attacks has been hitting websites and web services in the past few days. Github published a blog post last week about how it dealt with a DDoS attack that brought down the service for 10 minutes. Soon after, the same technique was used to attack a large service provider in the US at an even larger scale.
These attacks, dubbed “memcrashed”, are using a new attack vector – hijacked instances of the open-source memcached service – to amplify traffic hitting target web servers by a factor of over 50,000. Memcached is a widely used distributed memory object caching system that is used to speed up web applications. Given the large number of unprotected memcached instances out in the wild, we are likely going to see several more attacks of this nature in the weeks to come.
In this blog post, we show how Dome9 customers are able to find exposed and vulnerable memcached instances in their public cloud environments and prevent these instances from being used for an attack.
Let’s start with a quick overview of how the attack works. Here are the steps:
1. Attacker finds memcached-enabled servers exposed to the internet
2. Attacker spoofs the target’s IP address and send forged requests to the default UDP port (11211) on these servers
3. Exposed UDP server sends a response packet to the target/victim assuming that the request was genuine
4. Rinse and repeat 10s of 1000’s of times over, simultaneously
A key factor in the effectiveness of a DDoS attack is the amplification factor, i.e. how much bigger the response packet is than the request packet. In the case of the “memcrashed” attacks, the amplification factor is enormous – up to 51,000.
Attack Prevention
Preventing DDoS attacks in general is challenging because of the large number of compromised systems used in the attack. Companies can prevent systems from being compromised for a “memcrashed” attack by ensuring that servers with memcached are not exposed to the internet.
Using Dome9 to Protect Your Cloud Environment
In an AWS environment, you should protect your servers by making sure that the security groups that they belong to don’t have port 11211 open to a wide scope. The Dome9 Compliance Engine gives you a simple automated way to check if any of your instances have opened port UDP 11211 to a wide scope. You can run this rule at any point of time as well as get an automated alert to your email or some other way. This simple security policy rule written using the Governance Specification Language (GSL) covers this:
Instance should not have inboundRules contain [port <= 11211 and portTo >= 11211 and protocol in ('UDP','ALL') and scope='0.0.0.0/0']
You can inspect an exposed instance using our entity explorer:
You can also fix the security group misconfiguration from within the Dome9 platform in Full Protection mode:
In addition, if you use Amazon Elastic Load Balancer (ELB) in your environment, you can check if the ELB opens port 11211 to the public using this rule:
ELB should not have inboundRules contain [port <= 11211 and portTo >= 11211 and protocol in (UDP,'ALL') and scope=’0.0.0.0/0’]
These rules have been part of the ‘Best Practices for AWS’ bundle in the Dome9 Compliance Engine since before these incidents occurred , so our current customers are already protected.
Conclusion
Attacks of this nature typically start out being directed manually by sophisticated hackers, but soon become automated push-button scripts that anyone can download and run. Preventing these attacks by continuously ensuring compliance and maintaining proper security hygiene is the best long-term solution. Please reach out to us if you have any questions about this attack or cloud security in general.