15.3 Million Request-Per-Second DDoS Attack

Cloudflare is reporting a large DDoS attack against an unnamed company “operating a crypto launchpad.”

While this isn’t the largest application-layer attack we’ve seen, it is the largest we’ve seen over HTTPS. HTTPS DDoS attacks are more expensive in terms of required computational resources because of the higher cost of establishing a secure TLS encrypted connection. Therefore it costs the attacker more to launch the attack, and for the victim to mitigate it. We’ve seen very large attacks in the past over (unencrypted) HTTP, but this attack stands out because of the resources it required at its scale.

The attack only lasted 15 seconds. No word on motive. Was this a test? Or was that 15-second delay critical for some other fraud?

News article.

Tags: cryptocurrency, cyberattack, denial of service

Posted on May 5, 2022 at 6:02 AM • 16 Comments

Comments

Andy • May 5, 2022 9:27 AM

I think it was CloudFlare’s QE/QA testing their automated protection and providing a basis for the blog entry. Being prepared is important. Showing data to back it up helps with marketing.

Ted • May 5, 2022 9:42 AM

It would be nice if we knew which crypto launchpad was targeted. I would be interested to know if the DDoS attack was attempting to exploit a vulnerability to steal cryptocurrency or if it was just a local brawl.

Since the attack wasn’t successful, I guess we won’t be seeing any dramatic headlines.

It’s disturbing that the attack came out of data centers, primarily from German, Colombian, and French network providers. But why use HTTPS? Is this a concern for any other activity going on in their data centers?

EvilKiru • May 5, 2022 10:27 AM

Why HTTPS? Could it be because even though it is more expensive for the attacker, it is also more expensive for the victim?

Winter • May 5, 2022 10:42 AM

@EvilKiru

Why HTTPS?

Maybe, the target could simply deflect all non-https requests?

Clive Robinson • May 5, 2022 11:20 AM

@ ALL,

The two most interesting things in the ARS technica news article by Dan Goodin is,

Firstly, the “shark fin” graph of traffic by time. They are generally created by “exponential growth” followed by exponential decay. This one is not, and conveys things of intetrst to those who “join the dots”[1].

Secondly, this little snipit, from two Cloudflare researchers, Omer Yoachimik and Julien Desgats,

“They said that the flood of traffic mainly came from data centers, as DDoSes move away from residential network ISPs to cloud computing ISPs.”

If you think about it, if your site does not use “cloud computing” –and even if it does– it should not receive connection requests from “cloud computing” sites, as they are “traffic sinks” not “traffic sources” by general design.

So as you get to know these address ranges it probably will do you no harm to “black hole” connection requests from them at your fire wall.

[1] Also note that the exponential rise is close to being a two linear line approximation.

AndyHat • May 5, 2022 1:46 PM

The flash loan attack on BeanStalk took 13 seconds: https://www.theverge.com/2022/4/18/23030754/beanstalk-cryptocurrency-hack-182-million-dao-voting

I can certainly imagine how a DDoS might provide useful cover for another similar attack.

SpaceLifeForm • May 5, 2022 4:52 PM

@ Ted, Clive, ALL

My gut feel is that this exercise was not about DDoS. The target was not relevant.

CloudFlare has not spelled out what TLS ciphers that the attackers presented during the initial TLS handshake. They have not clearly stated if the TLS handshake was actually completed or not. Was it like a SYN Flood where it is purely a non completed handshake issue?

I will bet the ciphers presented were limited. Probably only requesting AES 128.

I will bet that the TLS handshake was completed, but then no further traffic.

The purpose of the exercise may have to been to extract data from the edge servers.

If I am CloudFlare, I would start randomly rebooting edge servers.

How is that Random working for you today?

Ted • May 5, 2022 5:50 PM

@SpaceLifeForm, Clive, All

The purpose of the exercise may have to been to extract data from the edge servers.

So yeah. It’s hard not to try to speculate.

I was wondering if the botnet operators had the option to use HTTPS simply because they were running it off compromised servers, instead of IoT devices.

Your thoughts were a bit more technical, and I wish there were more in-depth articles discussing those features, and how DDoS attacks could be impacted by HTTPS.

SpaceLifeForm • May 5, 2022 7:21 PM

@ Ted

I was wondering if the botnet operators had the option to use HTTPS simply because they were running it off compromised servers, instead of IoT devices.

It is not likely that a compromised server is restricted to https outbound.

If the entire point was a DDoS, then it would be easier to just use http, SYN Flood, or UDP.

The entire point of the exercise was to create the TLS handshakes and leak from the edge.

Have you guessed yet what may be being leaked?

The attack was probably China based.

tim • May 5, 2022 7:30 PM

@ SpaceLifeForm

They have not clearly stated if the TLS handshake was actually completed or not.

Yes they did. Read the article again.

I will bet the ciphers presented were limited. Probably only requesting AES 128

Not relevant to the attack.

I will bet that the TLS handshake was completed, but then no further traffic.

Read the article again.

The purpose of the exercise may have to been to extract data from the edge servers.

Edge servers have no data. And one doesn’t need to launch a DDOS attack to fingerprint the configurations and understand responses of an edge node.

If I am CloudFlare, I would start randomly rebooting edge servers.

Modern perimeters don’t have “servers”. They have workloads. Millions that scale up and down based on traffic requirements. There is nothing to “reboot”.

SpaceLifeForm • May 6, 2022 12:48 AM

@ tim

I am not seeing what you are saying, and have read multiple times everything I can find on this DDoS incident. A Link and a quote would help.

Note: this site pulls in Javascript from a CloudFlare edge server.

/dev/null • May 6, 2022 2:19 AM

@ Clive

I guess it depends on what you mean by “cloud computing” servers. Lots of services like VPN, businesses, mail, messaging, search engines, game servers, etc will go through an outer server in a data center (aka on a “cloud” provider). In other words, lots of outgoing requests. You can’t simply blackhole AWS from making incoming connections for instance.

Or am I not understanding?

Clive Robinson • May 6, 2022 12:59 PM

@ /dev/null, ALL,

You can’t simply blackhole AWS from making incoming connections for instance.

Why ever not? AWS are quite rightly almost the top of quite a number of “blackhole’m lists”.

I can tell you for free no Amazon service is alowed in any area I control.

Somebody elses moronic choices of VPN provider etc should not cause you to be insecure, “by their demand”.

It’s an appaling sign of the times that you would even think that.

Do you realy want to “Sleepwalk into the guilded trap from which the only exit is death?”.

lurker • May 6, 2022 3:05 PM

@Clive Robinson

Somebody elses moronic choices of VPN provider etc should not cause you to be insecure, “by their demand”.

@/dev/null: site managers have chosen that business model, and therefor have chosen that their site is broken for Clive and me and all others who value client security over server convenience. The unwashed majority don’t see the internet as broken because they don’t care.

/dev/null • May 6, 2022 4:05 PM

@ Clive, lurker

I think I sort of understand what you mean but that’s kind of like saying you’re never going to leave your house because your risk of injury and death goes up substantially. There is no perfect protection, all you can do is mitigate to an acceptable level for actually participating in life. Of course everyone makes their own choices for what’s acceptable.

I think there may be a fundamental difference in what we mean by “cloud” servers which is why I mentioned it before. I want to learn more. To you, what makes a server an unacceptable security risk? “Cloud computing” is kind of nebulous. Do you mean any server not under direct physical control? If so, then what about physically controlled malicious servers? Obviously servers have to talk to each other at some point unless you’re living in a vacuum. It’s not clear to me how it’s possible to accept or deny one or the other in a broad stroke. What is the difference?

I really like hearing from the extremes. It gives me ideas to help me be better, thanks!

SpaceLifeForm • May 6, 2022 5:33 PM

@ lurker, Clive, /dev/null

The last place that one should setup a VPS to roll their own VPN is AWS.

Your keymat will be exposed.

The absolute last choice.

Schneier on Security

15.3 Million Request-Per-Second DDoS Attack

Comments

Leave a comment Cancel reply