On Wednesday, the code distribution and version control service website GitHub survived a massive DDos attack.
In a report from Wired, the DDos attack happened at around 12:15 PM Eastern Time. GitHub reportedly got hit with 1.35 terabits per second (Tbps) of traffic all at once, the “most powerful distributed denial of service attack” ever recorded. The attack was staged using a popular DDos method that requires no botnet.
GitHub’s services went down for five minutes following the attack. The site then remained intermittently unavailable for the next four minutes.
Within ten minutes, GitHub automatically called for backup from its DDos mitigation services, Akamai Prolexic. The latter reportedly routed all of the traffic coming into and out of GitHub while filtering and weeding out malicious packets of traffic.
After eight minutes, the attackers relented, and the assault was dropped.
“We modeled our capacity based on fives times the biggest attack that the internet has ever seen,” Josh Shaul, vice president of Akamai Prelexic, told Wired.
“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.”
The DDos Attack Against GitHub
A distributed denial of service attack or DDos attack is a kind of online assault wherein hackers attempts to make online services unavailable by hitting them with immense traffic coming from different sources.
According to a report released by cybersecurity firm TrendMicro, anyone can buy a week-long DDos attack package on the Dark Web for as low as $150 USD. On the other hand, Arbor Network noted that over 2000 DDos attacks are being observed on a daily basis worldwide.
Usually, a distributed denial of service attack starts by building networks of infected computers, known as botnets, by spreading malicious software through emails, websites, or social media. These infected computers will then be controlled by the cybercriminals remotely, without the knowledge of their owners, to launch targeted attacks.
Read More: Russian Spies Hacked the Olympics and Tried to Blame North Korea for it
Apparently, some botnets used in DDos attacks could be “millions of machines” strong. However, that’s not the case with GitHub since the attack was staged without utilizing any botnet.
According to Akamai, the attackers exploited memcached servers to carry out the DDos attack against GitHub.
Memcached servers are database caching systems that are used to speed up networks and websites. They are not supposed to be exposed to the public online. However, anyone can query them, and they will likewise respond to anyone.
To date, Akamai said that there around 100,000 memcached servers that sit exposed online without any authentication protection. Businesses and other institutions own most of these systems. The lack of security enables any cybercriminal to access and exploit them by using a special command packet.
In a memcached DDos attack, hackers just merely spoof the IP address of their target then send small queries to a number of memcached servers that are designed to draw a much larger response. This would result in memcached systems returning data about 50 times larger than the request back to the target.
This so-called amplification attack is nothing new.
“Large DDoS attacks such as those made possible by abusing memcached are of concern to network operators,” Roland Dobbins, a principal engineer at Arbor Networks, was quoted as saying. “Their sheer volume can have a negative impact on the ability of networks to handle customer internet traffic.”
Right now, the DDos attack against GitHub is considered the largest ever recorded. The closest to its scale was the attack against internet infrastructure company Dyn in 2016, which peaked at 1.2 Tbps, causing major connectivity issues across the United States.
Akamai Prolexic and other cybersecurity firms have reportedly added filters that could immediately detect and block memcached traffic.
Comments (0)
Least Recent