The Biggest DDoS attack on Github using Memcached Servers - Survived

Brief News:- On Wednesday, at about 12:15 pm ET, 1.35 terabits per second of traffic hit the developer platform GitHub all at once. However, the attack cannot take the server down. GitHub managed to tackle the attack and it lasted for less than 10 minutes.

Seems great, right! 1.35 terabits of traffic using botnets. What do you think about how many botnets might have been required? And it would be surprising to tell you that this is a new method which doesn't use Botnet. Rather, it uses only a single server - Memcached Server. It was the most powerful distributed denial of service attack recorded to date—and it used an increasingly popular DDoS method, no botnet required.

Before going into deep about what happened, let us understand how this attack can be done. This is something you will find in all my articles because I believe that having the knowledge of what happened doesn't help. One should also have the knowledge of how it happened. And that's the reason why I always specify the method of attack. Let us start by learning what is memcached server and how are they exploited to perform this kind of attack.

What is a Memcached Server?

Memcached Servers are used to cache small chunks of data in the memory of a server. Think of the time required to retrieve data from the database by making queries to it and then converting that data into a readable format. What if a server finds out that a piece of information stored in database is accessed frequently! The server can access that data once and then store it into the cache i.e. memory. Now, only a memory read needs to be performed to access the data.

Memcached is a distributed caching system used for this purpose. It stores the data in dictionary form using key-value pairs. And hence, speedily access to data can be done. Hence, it works to speed up servers and websites.

How can a Memcached Server be exploited to DDoS?

Memcached servers generally return a large amount of data in response to a small request. Also, it works over UDP on port 11211. These are the two things which are taken as an advantage to exploit the server.

Crooks send small byte-sized requests to Memcached servers on port 11211. Because the UDP protocol wasn't implemented correctly, instead of responding with a similar or smaller packet, Memcached servers respond with packets that are sometimes thousands of times bigger than the initial request. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn't then you have no control over it. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address. Hence, the return address field in the request packet is spoofed to the target's (victim's) address.

In the DDoS community, this type of DDoS attack is named reflective DDoS or reflection DDoS. The amount of times the response packet size is amplified is the DDoS attack's "amplification factor". By a research, it is found that the amplification factor of a memcached server can reach a massive 51,200.

Now you know how the attack is performed, let's take a look a the news...

What Happened?

GitHub briefly struggled with intermittent outages as a digital system assessed the situation. Within 10 minutes it had automatically called for help from its DDoS mitigation service, Akamai Prolexic. Prolexic took over as an intermediary, routing all the traffic coming into and out of GitHub, and sent the data through its scrubbing centers to weed out and block malicious packets. After eight minutes, attackers relented and the assault dropped off.

“We modeled our capacity based on fives times the biggest attack that the internet has ever seen,” Josh Shaul, vice president of web security at Akamai said hours after the GitHub attack ended. “So I would have been certain that we could handle 1.3 Tbps, but at the same time we never had a terabit and a half come in all at once. It’s one thing to have the confidence. It’s another thing to see it actually play out how you’d hope."

GitHub continued routing its traffic through Prolexic for a few hours to ensure that the situation was resolved. Akamai's Shaul says he suspects that attackers targeted GitHub simply because it is a high-profile service that would be impressive to take down. The attackers also may have been hoping to extract a ransom. "The duration of this attack was fairly short," he says. "I think it didn’t have any impact so they just said that’s not worth our time anymore."

As a result, everyone thought that memcached process should not be available for public. It should be kept private for the servers. The infrastructure community has also started attempting to address the underlying problem, by asking the owners of exposed memcached servers to take them off the internet, keeping them safely behind firewalls on internal networks. Groups like Prolexic that defend against active DDoS attacks have already added or are scrambling to add filters that immediately start blocking memcached traffic if they detect a suspicious amount of it. And if internet backbone companies can ascertain the attack command used in a memcached DDoS, they can get ahead of malicious traffic by blocking any memcached packets of that length.

This was everything you need to know about the news... Thanks.