Slash Boxes

SoylentNews is people

posted by hubie on Sunday June 19, @08:41AM   Printer-friendly [Skip to comment(s)]
from the big-things-in-little-packages dept.

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

Original Submission #1Original Submission #2

Related Stories

Microsoft Azure Fends Off Huge DDoS Attack 10 comments

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."

Original Submission

Microsoft Azure Customer Hit by Largest 3.47 Tbps DDoS Attack 22 comments

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.

Original Submission

Cloudflare Just Mitigated One of the Most Powerful DDoS Attacks Ever 8 comments

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.

Original Submission

Display Options Threshold/Breakthrough Reply to Article Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by janrinok on Sunday June 19, @09:51AM (1 child)

    by janrinok (52) Subscriber Badge on Sunday June 19, @09:51AM (#1254364) Journal

    The burst lasted less than 30 seconds and generated more than 212 million HTTPS requests from more than 1,500 networks in 121 countries, with Indonesia, the United States, Brazil, and Russia topping the list.

    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.

    We are always looking for new staff in different areas - please volunteer if you have some spare time and wish to help
    • (Score: 0) by Anonymous Coward on Monday June 20, @02:53AM

      by Anonymous Coward on Monday June 20, @02:53AM (#1254505)

      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, @10:54AM (11 children)

    by Anonymous Coward on Sunday June 19, @10:54AM (#1254369)

    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, @12:15PM (2 children)

      by Anonymous Coward on Sunday June 19, @12:15PM (#1254375)

      Stupid people waste smart people's time. Goto Google.

      • (Score: 3, Insightful) by maxwell demon on Sunday June 19, @12:24PM

        by maxwell demon (1608) on Sunday June 19, @12:24PM (#1254378) Journal

        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:

        Stupid people waste smart people's time.

        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, @12:24PM

        by driverless (4770) on Sunday June 19, @12:24PM (#1254379)

        Yeah, Google is really gonna provide you the answer to this one...

    • (Score: 5, Informative) by driverless on Sunday June 19, @12:20PM (7 children)

      by driverless (4770) on Sunday June 19, @12:20PM (#1254377)

      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, @12:26PM (3 children)

        by Anonymous Coward on Sunday June 19, @12:26PM (#1254381)

        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, @12:34PM

          by maxwell demon (1608) on Sunday June 19, @12:34PM (#1254383) Journal

          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, @12:40PM (1 child)

          by driverless (4770) on Sunday June 19, @12:40PM (#1254384)

          Where does it say that it'll survive a reboot?

          • (Score: 0) by Anonymous Coward on Monday June 20, @09:27AM

            by Anonymous Coward on Monday June 20, @09:27AM (#1254555)

            "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, @01:07PM (1 child)

        by Anonymous Coward on Sunday June 19, @01:07PM (#1254390)

        >> 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, @04:24PM

          by Anonymous Coward on Sunday June 19, @04:24PM (#1254415)

          did not know zbill and Ben were hakerz

      • (Score: 2, Interesting) by anubi on Monday June 20, @02:30AM

        by anubi (2828) on Monday June 20, @02:30AM (#1254504) Journal

        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]