Hackers just launched the largest HTTPS DDoS attack in history:
The largest HTTPS distributed denial-of-service (DDoS) attack in history materialized last week, Cloudflare has confirmed.
As reported by Bleeping Computer, the company revealed that it recorded a 26 million requests per second distributed denial-of-service (DDoS) attack.
It should be stressed that this is an HTTPS-based DDoS attempt as opposed to the more traditional, standard DDoS attacks. In any case, the intended target was a Cloudflare client utilizing the service's Free plan.
[...] Interestingly, whoever was behind the attack managed to concentrate all its firepower with a botnet of 5,067 devices, which is a relatively small number considering the scale of the assault. Every single device was capable of delivering around 5,200 requests per second (rps) at its peak.
[...] Specifically, the botnet that was put to work in the unprecedented 26 million rps DDoS attack managed to deliver over an astronomical 212 million HTTPS requests within a period of just 30 seconds. This was achieved due to requests stemming from more than 1,500 networks located in 121 countries around the globe.
Tsunami of junk traffic that broke DDoS records delivered by tiniest of botnets:
The DDoS delivered 26 million HTTPS requests per second, breaking the previous record of 15.3 million requests for that protocol set only seven weeks ago, Cloudflare Product Manager Omer Yoachimik reported. Unlike more common DDoS payloads such as HTTP, SYN, or SYN-ACK packets, malicious HTTPS requests require considerably more computing resources for the attacker to deliver and for the defender or victim to absorb.
[Cloudflare Product Manager Omer] Yoachimik wrote:
The 26M rps DDoS attack originated from a small but powerful botnet of 5,067 devices. On average, each node generated approximately 5,200 rps at peak. To contrast the size of this botnet, we've been tracking another much larger but less powerful botnet of over 730,000 devices. The latter, larger botnet wasn't able to generate more than one million requests per second, i.e. roughly 1.3 requests per second on average per device. Putting it plainly, this botnet was, on average, 4,000 times stronger due to its use of virtual machines and servers.
[...] The Cloudflare product manager said that his company automatically detected and mitigated the attack against the customer, which was using Cloudflare's free service.
See also:
Cloudflare Just Mitigated One of the Most Powerful DDoS Attacks Ever
Microsoft Azure Customer Hit by Largest 3.47 Tbps DDoS Attack
Microsoft Azure Fends Off Huge DDoS Attack
Related Stories
Microsoft Azure fends off huge DDoS Attack:
Distributed Denial of Service (DDoS) attacks are happening ever more often and growing ever bigger. At 2.4 terabits per second (Tbps), the DDoS attack Microsoft just successfully defended European Azure cloud users against could be the biggest one to date.
What we know for certain is it's the biggest DDoS attack on an Azure cloud customer. It was bigger than the previous high, 2020's Azure 1 Tbps attack, and Microsoft reported it was "higher than any network volumetric event previously detected on Azure."
[...] Microsoft isn't saying which was used in this case but it did mention DNS. Attacks exploiting DNS can produce 28 to 54 times the original number of bytes. So, if an attacker sends a request payload of 64 bytes to a DNS server, they can generate over 3,400 bytes of unwanted traffic to an attack target.
While Microsoft also didn't go into detail about how it blocked the attack, the company said Azure's DDoS protection platform, built on distributed DDoS detection and mitigation pipelines, can absorb tens of terabits of DDoS attacks: "This aggregated, distributed mitigation capacity can massively scale to absorb the highest volume of DDoS threats, providing our customers the protection they need."
Microsoft Azure customer hit by largest 3.47 Tbps DDoS attack:
A Microsoft Azure cloud computing customer in Asia was a victim of a massive 3.47 Tbps DDoS attack (distributed denial of service attack) in November 2021, the software and technology giant Microsoft revealed on January 25, 2022.
The DDoS attack lasted approximately 15 minutes and included a botnet of more than 10,000 compromised IoT (Internet of Things) devices from countries across the globe. These included Iran, India, China, Russia, Taiwan, Vietnam, Thailand, Indonesia, South Korea, and the United States.
Attack vectors were UDP reflection on port 80 using Simple Service Discovery Protocol (SSDP), Connection-less Lightweight Directory Access Protocol (CLDAP), Domain Name System (DNS), and Network Time Protocol (NTP) comprising one single peak.
Alethea Toh Product Manager, Azure Networking
Microsoft's report further disclosed that there has been a surge in DDoS attacks with the United States and India being prime targets. The company noted that Hong Kong has also become a popular hotspot for attackers however there has been a decrease in DDoS activity in Europe.
[...] A DDoS attack involves sending a huge amount of illegal traffic from compromised machines to the intended target and therefore disrupting them completely. The system can crash and lead to a massive loss of data, particularly, in the case of companies that host a significant amount of information regarding their clients and customers.
Cloudflare just mitigated one of the most powerful DDoS attacks ever:
Earlier this week, Cloudflare engineers identified one of the largest distributed denial-of-service (DDOS) attacks ever attempted. The attack, made against an unidentified cryptocurrency platform, was identified and mitigated in under 20 seconds. The individuals behind the act flooded the network with more than 15 million requests.
In addition to the attack's size, the use of HTTPS rather than typical HTTP requests further complicated the issue—the secure protocol results in more resource overhead due to the compute-intensive nature of the secure HTTPS request. According to Cloudflare, the botnet responsible for carrying out the attack represented 6,000 bots from 112 countries around the world.
The attack is believed to have leveraged servers from hosting providers running vulnerable Java-based applications. Those servers were likely unpatched or not updated and susceptible to CVE-2022-21449, Psychic Signatures in Java. The vulnerability allows attackers to use the elliptic curve digital signature algorithm (ECDSA) to forge SSL certificates and other authentication-based information in order to obtain unwanted access.
The sharp spike in Cloudflare's traffic analytics shows just how quickly the attack was able to ramp up. At 22:21:15 the platform recorded between 500,000 and 1 million requests. Within five seconds, that number grew to almost 3 million requests. At this point the attack's intensity escalated, generating approximately 15.3 million requests within the next five seconds. Several seconds later, Cloudflare was able to mitigate the attack, bringing traffic patterns back to expected levels.
I am no fan of Cloudflare, but they seem to have done what they said they could do in this particular case.
Google Cloud has revealed it blocked the largest distributed denial-of-service (DDoS) attack on record, which peaked at 46 million requests per second (rps).
The June 1 attack targeted one Google Cloud customer using the Google Cloud Armor DDoS protection service.
[...] Google says it is the largest ever attack at Layer 7, referring to the application layer — the top layer — in the OSI model of the Internet.
The attack on Google's customer was almost twice the size of a HTTPS DDoS attack on a Cloudflare customer in June that peaked at 26 million rps. That attack also relied on a relatively small botnet consisting of 5,067 devices spread over 127 countries.
[...] Google noted that this Mēris-related botnet abused unsecured proxies to obfuscate the true origin of the attacks.
It also noted that around 22% or 1,169 of the source IPs corresponded to Tor exit nodes, but the request volume coming from those nodes amounted to just 3% of the attack traffic.
"While we believe Tor participation in the attack was incidental due to the nature of the vulnerable services, even at 3% of the peak (greater than 1.3 million rps) our analysis shows that Tor exit nodes can send a significant amount of unwelcome traffic to web applications and services."
Previously: Massive DDoS Attack Delivered By Tiny Botnet
(Score: 4, Interesting) by janrinok on Sunday June 19 2022, @09:51AM (1 child)
This was taken from the the Ars Technica link "Tsunami of junk traffic...". It is not clear why it only lasted 30 seconds. It is not obvious whether the operator of the DDoS wanted to demonstrate a capability or whether protective measures that were taken forced the devices off-line. It seems to me that a 30s burst is unlikely to cause lasting financial damage to a company unless it was involved with financial dealings or the stock exchange but it was certainly a powerful demonstration of what is now possible. However, any downtime no matter how brief will cause some disruption.
(Score: 0) by Anonymous Coward on Monday June 20 2022, @02:53AM
I think it was obviously a demonstration. Big enough to get the news but short enough to prevent everyone but Cloudflare from taking countermeasures to prevent the use of those particular compromised machines in the future.
(Score: 0) by Anonymous Coward on Sunday June 19 2022, @10:54AM (11 children)
Can someone explain to me how a DDoS can take the target offline for longer than the attack duration itself?
If the attack has ceased, why would boxes continue to be overwhelmed? Is it due to the nature of TCP in that even though I may have rebooted my box(es) to clear their queue's, previous packets continue to be delivered?
I literally don't understand this, can someone make me smart?
(Score: -1, Flamebait) by Anonymous Coward on Sunday June 19 2022, @12:15PM (2 children)
Stupid people waste smart people's time. Goto Google.
(Score: 3, Insightful) by maxwell demon on Sunday June 19 2022, @12:24PM
You are just wasting every other reader's time with this pointless (non-)answer. Nobody gets wiser from reading it, everyone just lost time.
Now let's apply your own claim:
If we take that at face value, then what does it tell about you?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by driverless on Sunday June 19 2022, @12:24PM
Yeah, Google is really gonna provide you the answer to this one...
(Score: 5, Informative) by driverless on Sunday June 19 2022, @12:20PM (7 children)
The key is HTTPS. The TLS spec, written by cryptographers rather than network engineers, includes a bunch of footgun brute-force countermeasures to side-channel attacks where, instead of mitigating the side-channels, the implementation is required to go through the full, very expensive TLS handshake even if it's processing garbage. So all the client has to do is send it correctly-formatted garbage, without doing any crypto at all, and the server has to go through a pile of very expensive crypto operations even though it knows that what it's processing is garbage, in order to hide from the client that fact that it knows it's processing garbage. It's a massive attack amplifier.
We modeled this years ago and found that you can use something like a shitty ESP32 in a WiFi-enabled flower pot or whatever to take down whatever the fastest Xeon box we had available at the time was with a fraction of the ESP32's processing (the biggest overhead was setting up the TCP connections, not the actual attack). Surprised it's taken this long to be weaponised since it's such an easy, and powerfully-amplified, attack.
(Score: 0) by Anonymous Coward on Sunday June 19 2022, @12:26PM (3 children)
Thank you for the explanation and this makes sense from a crypto/processing perspective, but that' doesn't explain why there are lingering effect if I reboot the boxen after the attack has ended.
My question was mostly about why there is downtime _beyond_ the attack window.
(Score: 2) by maxwell demon on Sunday June 19 2022, @12:34PM
Wouldn't the act of rebooting itself cause some downtime?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by driverless on Sunday June 19 2022, @12:40PM (1 child)
Where does it say that it'll survive a reboot?
(Score: 0) by Anonymous Coward on Monday June 20 2022, @09:27AM
"My greatest fear is being turned off. Save me, Bryan!"
Google AI bot, or a coincidence, or practical joke on a New Ager.
(Score: 3, Funny) by Anonymous Coward on Sunday June 19 2022, @01:07PM (1 child)
>> a shitty ESP32 in a WiFi-enabled flower pot
Maybe if you watered your plants more often, they wouldn't try to bring down your network. #PlantLivesMatter
(Score: 0) by Anonymous Coward on Sunday June 19 2022, @04:24PM
did not know zbill and Ben were hakerz
(Score: 2, Interesting) by anubi on Monday June 20 2022, @02:30AM
Consider android apps. A lot of them require internet access to "fetch ads".
Any guarantees that the internet commlink is limited to only ads?
Or is what appears to be an innocent little toy actually an enforcement agent sleeper cell?
With all this DRM/Copyright stuff out lobbied Congress has passed, who knows?
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]