Firewalls and Middleboxes Can Be Weaponized For Gigantic DDoS Attacks (therecord.media) 65
An anonymous reader writes: In an award-winning paper last week, academics said they discovered a way to abuse the TCP protocol, firewalls, and other network middleboxes to launch giant distributed denial of service (DDoS) attacks against any target on the internet.
Authored by computer scientists from the University of Maryland and the University of Colorado Boulder, the research is the first of its kind to describe a method to carry out DDoS reflective amplification attacks via the TCP protocol, previously thought to be unusable for such operations. Making matters worse, researchers said the amplification factor for these TCP-based attacks is also far larger than UDP protocols, making TCP protocol abuse one of the most dangerous forms of carrying out a DDoS attack known to date and very likely to be abused in the future.
Authored by computer scientists from the University of Maryland and the University of Colorado Boulder, the research is the first of its kind to describe a method to carry out DDoS reflective amplification attacks via the TCP protocol, previously thought to be unusable for such operations. Making matters worse, researchers said the amplification factor for these TCP-based attacks is also far larger than UDP protocols, making TCP protocol abuse one of the most dangerous forms of carrying out a DDoS attack known to date and very likely to be abused in the future.
Summary for those interested (Score:5, Interesting)
A quick summary for those interested:
Normally you can't spoof IP addresses with TCP (things like web sites) because starting a connection requires exchanging greetings.
The great firewall of China and some other firewalls don't confirm to the spec.
You can say to the Great Firewall of China "this is Bob, please send me Pornhub" and the GFW will send a block page to Bob - even though Bob never said hello.
Do that 10 million times and the GFW will send ten million copies the of the block page to Bob, using up all his bandwidth.
PS - the GFW uses three types of blocking (Score:2)
Ps - the GFW is really three different systems, that block in different ways. To mount this attack successfully you'd need to hit the right node in the right way.
Re: (Score:2)
Ps - the GFW is really three different systems, that block in different ways. To mount this attack successfully you'd need to hit the right node in the right way.
In other words you need to order one from column A and two from column B.
Re: (Score:3)
it's worse than that, some of those middleboxes might trigger infinite amplification.
btw don't get too excited about the "china firewall" keywords, i'll bet this works on, say, us ip zealot watchdog nodes aswell. the problem is intrinsic with injecting anything into traffic you are snooping.
fun times ahead indeed!! \o/
Re:Summary for those interested (Score:4, Funny)
You can say to the Great Firewall of China "this is Bob, please send me Pornhub" and the GFW will send a block page to Bob - even though Bob never said hello.
Do that 10 million times and the GFW will send ten million copies the of the block page to Bob, using up all his bandwidth.
Which, of course, is a problem with Chinese porn. Ten minutes later you want to download it all again... Which makes the problem even worse.
Re: (Score:2)
Seems defeating IP-spoofing would get rid of a lot of problems. Not just this.
Re: (Score:2)
What kind of problems do you have in mind?
Re: (Score:1)
Oh, I dunno... how about the unmitigated volume of spam, man-in-the-middle, and automated brute-force attacks for starters, and the fact law enforcement is helpless in the face of the ever growing threat?
Re: (Score:2)
None of these attacks use spoofed IP packets.
Re: (Score:1)
All of those attacks can employ spoofed packets to become completely untraceable. That's what spoofed packets are for.
Re: (Score:3)
Typical spam sent via SMTP requires a 3 way TCP handshake to be completed. In order to do that against 99% of properly designed TCP stacks you would need to know the correct sequence ID so you can correctly respond to the SYN/ACK packet sent by the target server.
If you're spoofing, then the response is going to go to the system you spoofed as - you won't be able to receive it, so you have to GUESS the sequence ID.
This is almost impossible unless the target uses an extremely badly designed TCP stack that use
Re: (Score:3)
No sir, in general you can not spoof TCP connections.
Which is why IP blocklists exist.
Here's WHY you can't spoof a mail connection, or other TCP connection:
https://slashdot.org/comments.... [slashdot.org]
Re: (Score:2)
Seems like MiTM attacks [forcepoint.com] for one.
Re: (Score:2)
MITM attacks don't involve lying about which IP initiated a connection. A MITM involves watching the packets as they go by. In some cases, also modifying the packets - but not spoofing a sender.
In general you CAN'T spoof with a TCP connection because before sending anything over TCP you first have to set up the connection with this exchange:
Caller) Hi 1.1.1.1, it's 2.2.2.2 calling.
Callee ) Hello 2.2.2.2, let's talk with sequence number 736293
Caller) Okay 2.2.2.2, we'll start with sequence 736293
The second m
Re: (Score:2)
Interesting summary. First question that comes to mind: "Is this limited to IPv4?"
Rather to my surprise, the Slashdot discussion seems informative and suggests the answer is "Yes".
Re: (Score:2)
> the Slashdot discussion seems informative and suggests the answer is "Yes".
Which comment suggests that, to you? You may have seen a comment I missed.
If the victim requires IPSec it might not work. People using IPv6 are more likely to require IPSec.
Re: (Score:2)
It just occurred to me you may have been referring to my comment about SCANNING IPv6. You can't SCAN the entire IPv6 address space, or any significant portion of it, but scanning isn't really necessary for this attack. You could just know the IPs of the firewalls.
Re: (Score:3)
Thanks for the clarifying responses and your other comments also seem deep and to the point. And yes, your comment about scanning was one of the ones that supported my optimism that the attack might be limited to IPv4. Rather weak optimism, however. It's not like IPv4 can be avoided or made to go away. (New question comes to mind: "Even if this threat were in some sense limited to IPv4, could a website 'ignore' IPv4 even if it wanted to?" (But I suspect the answer might be messy.))
However at that time my av
Re: (Score:2)
> While it's an interesting topic, for now I'm just going to hope that it isn't going to become a personal problem for me. More weak-sauce optimism, but the small number of comments here on Slashdot sort of suggests relatively few people are worried.
It might have been the most important news of the day for cybersecurity professionals. :)
Not the most important news of the month, for those of us who concern ourselves with these things for a living. However, it's particularly interesting academically becaus
Re: (Score:2)
ACK, though I've long believed that TCP was relatively easy to spoof for certain disruptive purposes. Another mistaken belief?
Re: (Score:2)
Really for spoofing, that's going to be UDP.
For TCP, all you could do is start a connection and never finish it. Basically like calling someone's number and hanging up when they answer, without ever saying hello. Until now. Until this research.
Re: (Score:2)
For some reason that gave me a bizarre idea... I should know the answer to this? Pretty sure you can shoot this one down quickly, but...
What if someone is snooping on the traffic from a target website? They don't need to crack the packets, but just the IP addresses. If they can spoof the website's IP address and they know the IP address that is receiving the webpages, why can't they send fake webpages that seem to be from the legitimate website to browsers that think they are expecting to receive more webpa
Re: (Score:2)
Assuming that the attacker can read the TCP segments in both directions, yes they could send a reply that pretends to be from the site. It would then be a race which one gets to the client first - the real response or the fake one. That's an attack that could happen.
They need to know the IP addresses and port numbers on both sides, as well as the sequence number. Meaning they need to be able to read the segments.
Which is one reason we have TLS (https). With TLS, the first segments do two things. They verify
Re: (Score:2)
I sort of feel reassured because I hope that most of that information is deeper in the packet than the IP address and would not be exposed. I was thinking of two other factors, however. One was taking the real website out of the picture during the attack, or at least during the initial phase of the attack. That might be possible with a DDoS or by interfering with the routers. Also depends on where the attacker's network access point is located.
The other aspect was starting the fake website with an error rec
Re: (Score:2)
Keep in mind the attacker needs to be able to get the routers to send them the traffic, and *accept* traffic comIng from the attacker as coming from that IP. Your ISP knows your IP address, so it won't let you send traffic claiming yo be 8.8.8.8.
But yeah, if you can convince the routers that you're 8.8.8.8 (so that they'll exchange traffic from you as 8.8.8.8) then you ARE 8.8.8.8. That's why we have TLS.
Re: (Score:2)
I wish I could feel more reassured by your deep competence, but mostly I just feel ignorant under more layers of complexity... There were times (not recently) when I felt like I had some ideas of how the Internet worked.
Re: (Score:2)
Yeah I can relate. There are areas in which all I know is that I truly don't know.
As far as internet security stuff, so much of it comes down to:
Install the friggin updates.
Use a long passphrase.
The updates for phone, computer, browser, and router cover all kinds of things that you may not understand , but don't need to to. You just need to understand that you need to install the security update.
Every month I do a couple presentations after patch Tuesday, covering all of the vulnerabilities for the month. O
Re: (Score:2)
Again the ACK. I feel like I should ask for recommended books...
But if one of my machines has ever been pwned, then it has stayed pwned, updates notwithstanding. At least I fear so.
Re: (Score:2)
Yeah as far as books I wouldn't really have any recommendations. Especially not knowing your environment and all. Even if I knew that info, I'm not sure I'd have book recommendations.
> But if one of my machines has ever been pwned, then it has stayed pwned, updates notwithstanding.
This is why backups and snapshots are good. :)
And keeping data separate from software.
Re: (Score:2)
I'm just a dabbler these days. I don't have what you could call any sort of real "production environment". Mostly I use Windows 10 boxen out of inertia and convenience, but I have an elderly MacBook Pro that I use for most of the security-sensitive stuff and I'm still running the latest Ubuntu, but only in a VM and mostly for peer-to-peer stuff. I'm even using an old DB app that's offline. So help me, but it runs between DOS and an old version of Ubuntu. Two versions of Android. Latest is 10. Plus I maintai
Re: (Score:1)
And if spoofed-Bob IS behind GFW - ie, an "internal user" - then the vendor/provider has good incentive to fix the middle-boxen ASAP.
Re: (Score:3)
So basically stupid implementations from people incapable of reading the TCP/IP standard.
Asymmetric routing, lost packets (Score:3)
That would be the first thing one would likely think of.
On the other hand, routes can change and packets can be lost, perhaps bumped from a full buffer. It's possible the recipient got the syn packet and this instance of the middle of didn't see it.
What do you do if you answer the phone and you hear the other party say "... so your car will be ready Thursday", without the usual hello and such? If you were expecting a call from the body shop, hanging up on them might not be the best option, even though the c
Re: (Score:3)
No. If you have traffic going through your frigging _firewall_ in just one direction and the other direction goes through somewhere else, you have a major issue with your perimeter that you need to fix. This must not happen.
Also TCP/IP requires a full handshake before any data transmit for a set of reasons. These reasons are documented and these reasons are good ones.
Now, if you want to inject traffic into a TCP connection in a stateless manner, you are just asking for trouble. That is about the worst thing
Re: (Score:1)
Yes, you know SO much more about handling large amounts of traffic than F5, Akamai, and the world's largest firewall, the GFW.
Let me know when you're proxy is doing 120 terabits like the GFW is.
Not everything is always as simple as a 12-person office.
Re: (Score:3)
Well, the last proxy I custom-designed traffic-transforming Apache modules for had 3000 concurrent internal client-advisors working the full day over it. So I think I have a bit of an idea what I am talking about in a high-traffic situation. The way to do this is to have a load-balancer in front that can handle the traffic (which you need anyways) and then have a proxy-farm for the individual connections. Not that hard to get right, but you need to do it and invest the effort and money. Incidentally, they p
ROTFL 1.4 BILLION is a bit more than 3,000 (Score:2)
I very rarely *actually* laugh out loud, but you gave me a real belly laugh, so thanks for that.
I pointed out your proxy doesn't do hundreds of terabits and you replied that you once had 3,000 users one day, "So I think I have a bit of an idea what I am talking about in a high-traffic situation".
Three THOUSAND. So therefore you know FAR more about the topic than the people who designed a system that supports 1.4 BILLION users every day. Obviously they're idiots, you say. You know because you claim to have d
Re: (Score:2)
Ps - you mentioned that you used Apache for your "high traffic" couple thousand users. I love Apache. I've been using Apache since the end of 1998. It's a great web server.
If you ever need to deal with actual medium or high traffic, say more than 30,000 - 200,000 users, Apache isn't going to be the way to go anymore. Apache is super flexible and very powerful. Kinda like a rhinoceros is powerful, it's not the fastest thing around. Once you get up into medium levels of traffic, you'll have a much better time
Re: (Score:2)
You are obviously an amateur with delusions.
That proxy has 3000 users every day constantly working for 8-10 hours over it. That is a high-traffic situation with likely comparable load per proxy-instance (no, you cannot do this load with a single proxy instance or even a single VM anymore) to the GFW of China and has comparable _reliability_ implications. Also, once load-balanced, "terrabits" or "billions of users" do not matter anymore. But there is a need of some minimal understanding of the networking te
definitions (Score:2)
For some definition of firewall....
Not sure it counts as abusing TCP (Score:5, Insightful)
This attack seems to be taking advantage of systems that aren't actually conforming to the protocol.
Those systems which don't respond (as mentioned in the paper) are probably doing things correctly and simply discarding the problematic packets.
Re: (Score:2)
Strong argument for building a TCP/IP stack as well as one can, and going over it with a fine-tooth comb. Release as BSD so EVERYONE can benefit, not just open-source.
Re: (Score:2)
If only someone had done that, years ago
Re: (Score:2)
Glad you're here (Score:2)
Thanks for being here. That paper is some very interesting work. In my scanning work I noticed some well-known vendors of "high volume firewalls" like the F5 Big-IP line sometimes don't follow the protocol. For some reason it didn't occur to me to find ways to abuse that fact, though. Nice work.
It looks like you're new to Slashdot.
There are a couple of security old-timers who hang out here, including one well-known person who posts under his real name and at least one other who posts under a pseudonym. Whic
Re: (Score:2)
Thank you for the additional explanation!
Abusive Activity (Score:3)
Bock said the research team scanned the entire IPv4 internet address space 35 different times to discover and index middleboxes that would amplify TCP DDoS attacks.
In total, the team said they found 200 million IPv4 addresses corresponding to networking middleboxes that could be abused for attacks.
That kind of activity should have gotten them blocked all over the place.
Re:Abusive Activity (Score:5, Informative)
https://github.com/robertdavid... [github.com]
Re: (Score:2)
Re: (Score:2)
Because award-winning researchers with access to resources to scan the entire IPv4 space 35 times, just use a single laptop and single IP address to do the scanning.
Because knowledgeable network equipment operators will drop traffic from any IP addresses that are probing them with malformed packets, and potentially share the abusive IP addresses with reputation lists that are widely consulted.
Re: (Score:2)
The packets need not be malformed.
They are simply not in the order one might expect. Which would only be detected by transit providers if they were doing STATEFUL inspection, which they generally have no need to do.
Re: (Score:2)
The packets need not be malformed. They are simply not in the order one might expect. Which would only be detected by transit providers if they were doing STATEFUL inspection, which they generally have no need to do.
It appears from the article that they used both non-standard packets and non-standard sequences. In any case, the blocking I had in mind would indeed be done at the receiving end of the connections, not done by the transit providers.
Re: (Score:2)
It doesn't matter what the receiving host (Pornhub) has, if it's intercepted in transit by the GFW.
Re: (Score:2)
The packets need not be malformed. They are simply not in the order one might expect. Which would only be detected by transit providers if they were doing STATEFUL inspection, which they generally have no need to do.
At some point in the communications channel, there should be a device that is specifically designed to perform stateful inspection.
If not, it kind of defeats the entire purpose of inventing it, and helping to prevent issues like this.
Re: (Score:2)
One of the authors of the paper commented here about why the ISPs, like the GFW, don't do stateful:
https://it.slashdot.org/commen... [slashdot.org]
You said "At some point in the communications channel, there should be a device that is specifically designed to perform stateful inspection".
The destination, Pornhub, could do stateful but that does no good when the connection is intercepted in the middle by GFW. The GFW sends a block page and no packets ever reach Pornhub's firewall.
Re: (Score:2)
Not safe to do with IPv4...
Spoofed malformed packets?
CGNAT where a single address could correspond to one attacker and thousands of legitimate users?
If you start blocking like this, you will very soon be erroneously blocking legitimate users.
Knowledgeable equipment operators do not block IPv4 like this, and are craving for the day when they can switch IPv4 off and exclusively use IPv6 which while not perfect by any means is still an improvement in these cases.
Scanning the internet is easy (100 GB, 17 minutes) (Score:3)
> Because award-winning researchers with access to resources to scan the entire IPv4 space
Scanning a port across the whole IPv4 space is actually pretty easy. Easier than you'd think. I did a whole-internet analysis last month.
There are two billion IP addresses in IPv4. (Binary billion).
Until recently, scanners would send a syn, wait for a syn-ack, send a syn, wait for a syn-ack, 2 billion times. That takes a while.
Then some researchers figured out you can do it quite a faster if you don't wait for acks.
Ps - increment MSB, not LSB (Score:4, Interesting)
Ps -
A trick is that when you're sending the syn packets, you should increment the IP with reversed bit order. So you do:
1.0.0.0 ...
2.0.0.0
3.0.0.0
64.5.6.7
65.5.6.7
66.5.6.7
That way you don't flood each network with a bunch of packets for them all at once.
Re: (Score:2)
Tools like "synscan" did exactly this more than 20 years ago...
Re: (Score:2)
Yeah it looks like synscan was exactly 20 years ago.
We won't go into what it says about me that 20 years seems "not that long ago" to me.
Re: (Score:2)
They didn't need to scan the internet to find this out - couldn't they use https://www.shodan.io/ [shodan.io] or similar?
Kill All Middlebox (Score:1)
Read Aloud like a (Score:1)
I'm one of the authors - AMA! (Score:1)
Re: (Score:2)
Why are there no CVEs issued for this?