On February 27th Radware noticed an increase in activity on UDP port 11211. As other organizations began to disclose a trend in UDP amplified attacks over UDP port 11211, Radware’s ERT Research team and the Threat Research Center began preparing for the inevitable. With a Bandwidth Amplification Factor (BAF) ranging between 10,000x and 52,000x, we knew that due to this exposure and publication that attackers would be quick to adopt this method and could easily reach volumes well over 500Gbps.
Attack Against GitHub
The inevitable quickly became a reality 24 hours later when an attacker launched, at the time, the world’s largest DDoS attack against GitHub. This attack peaked at 1.35Tbps, 126.9 million packets per second and resulted in 10 minutes of service degradation for GitHub. Following this event there were numerous attacks over the next several days that would push the world’s record to 1.7Tbps. With these record-breaking attacks we can officially say that we have entered the era of Terabit Denial-of-Service attacks.
The first attack ever to break the 1Tbps mark was an attack against French hosting provider OVH in 2016. This attack was able to break the 1Tbps barrier by infecting hundreds of thousands of IoT devices with a piece of malware called Mirai. Mirai was successfully leveraged at the time with a number of attack vectors to generate enough volume to claim the world record and escalate DDoS attacks to a new level.
IoT Botnet Evolution
The Mirai botnet was the culmination of years of IoT botnet evolution. In 2012 an IRC-based mass router scanner and exploiter called Aidra was released that utilized two servers, one to host the binaries and the other, an IRC server, used to issue commands to devices infected via telnet. Shortly after Aidra, Bashlite, also known as Qbot, Lizkebab and Gafgyt, was discovered in 2014 with a new twist. This IoT botnet utilized the ShellShock vulnerability to infect IoT devices. But shortly after Bashlite, in 2016, a new IoT botnet was discovered and struck the security industry with three massive DDoS attacks that shook the traditional protection paradigms.
This botnet was the first version of Mirai, a powerful and sophisticated attack tool. Mirai gained infamy in 2016 when it was leveraged in the first DDoS attack to exceed 1Tbps of traffic volume. Mirai was responsible for the top three attacks that year, targeting Brian Krebs, OVH and DynDNS. Once the source code for Mirai became public it empowered script-kiddies from all over the world to customize the code and create new variations.
The original Mirai botnet featured ten predefined attack vectors including common attacks such as SYN and ACK floods that have proven effective in previous attacks. Mirai introduced new DDoS vectors like GRE IP and Ethernet floods. Mirai also featured intelligent evasion mechanisms to bypass known security controls and DDoS mitigation methods before reaching its target, providing a challenge for some organizations. Mirai did not leverage an exploit like ShellShock used by Bashlite. It leveraged a simple attack of targeting insecure devices with default credentials via telnet and SSH.
IoT botnets became an attractive toolkit for attackers for several reasons. The main reason why an IoT botnet is favored over a standard botnet is due to availability. Standard botnets are comprised of infected PCs that are not always on. With IoT devices, they are left operating 24/7 year round. This allows an attacker who is leveraging an IoT botnet to have 100% service availability from infected devices. There is also no regulations or standards for securing IoT devices, leaving millions of devices exposed with default credentials.
After hitting the 1Tbps mark, IoT devices became all the rage and the once-popular, amplified attack took a back seat to large-scale IoT botnets as attackers zeroed in on the most insecure areas in the cyber landscape – IoT devices.
After two years of Mirai, UDP amplification attacks came back into the mainstream with the release of the Memcached amplified attack vector. This vector makes use of legitimate third party Memcached servers to send spoofed attack traffic to a targeted victim. Memcached, like other UDP-based services (SSDP, DNS and NTP), are internet servers that do not have native authentication and are therefore easily hijacked to launch amplified attacks against their victims.
Memcached is a general-purpose, distributed memory caching system typically used to speed up dynamic web applications by caching data and objects in RAM. This reduced the backend database or API round trips but also created a problem with the way Memcached’s UDP protocol is implemented. Memcached can be compiled with optional SASL authentication support but was deployed with TCP/UDP port 11211 exposed to the Internet. As a result, attackers can abuse this service to launch large-scale amplified attacks.
All the attacker has to do is scan the internet for vulnerable Memcached servers to create an amplification list. In fact, today they don’t even need to do this. They can simply search a number of public sources like PasteBin to find a public amplification list. Once the attacker has a Memcached amplification list they are able to use a simple script to send spoofed requests to UDP port 11211 with the victim’s spoofed IP address. The Memcached servers will respond to the request by sending an amplified request, vastly larger than the original request, to the victim’s IP address. The result is pipe saturation and service degradation for the targeted organization.
Due to the volume that can be reached with a single amplification list, attackers do not need a massive IoT botnet to launch 1Tbps+ assaults as with Mirai. At the core of the Memcached problem is the number of exposed servers on the Internet. With just under 100,000 exposed Memcached servers, it creates a prime reflector for an amplified attack.
What Do We Need to Be Concerned About?
There are two main concerns in regards to the Memcached vulnerability. The first issue is centered around the number of exposed Memcached servers. With just under 40,000 vulnerable servers and only a few thousand required to launch large scale volumetric attacks, the cause for concern is great. Some organizations are likely still unaware that they have exposed Memcached servers exposed to the internet and it will take time to block or filter this service. Memcached servers will be vulnerable for some time, allowing attackers to generate volumetric attacks with few resources.
The second concern is the time it took attackers to begin exploiting this vulnerability. The spike in activity was known for several days prior to the patch and publication of the Memcached vulnerability. Within 24 hours of publication, attackers were able to build an amplification list of vulnerable Memcached servers and launch multiple record breaking DDoS attack, a title previously held by the Mirai botnet.
Memcached has reminded everyone in the industry that what’s old is new again. Once we get used to a threat and can properly mitigate it, attackers will quickly look for a new vector which will gain the desired results, and incorporate it into their attack toolkit. In fact, the DDoS-as-a-Service industry has incorporated the Memcache attack vector into their stresser service. These for-profit criminals are quick to utilize the newest vector for many reasons. The first reason a criminal would include this attack vector into their stesser is due to hype and public attention. The first one to incorporate it could expect to see a growth in subscribers because of it. They will also provide a bigger bang for their customers’ buck. Currently most stresser services cost around $20 a month and allow the user to launch one attack at a time for 1,200 seconds. To impound the problem, ransom groups will likely start sending out letters threatening a 1Tbps attack for Bitcoin, as was seen directly after the release of Mirai. Attackers prey off the fear of the public and with Memcached in the spotlight, its likely it’s only a matter of time before RDoS groups start using Memcached as a threat for their campaign.
To prevent this problem from expanding, I suggest that users with Memcached servers should disable UDP, update to the latest code version of Memcached, 1.5.6 or enable SAML authentication.
If faced with a RDoS attack do not pay the attacker, as often times they reuse the same payment address, making it difficult to determined who paid the ransom. RDoS groups in 2017 rarely follow through with their threats with the exception of an occasional sample attack after receiving the letter.