Eplox / TCP-Starvation

TCP-Starvation

Update: From comments throughout different communities, I've seen links to different articles describing the same issue as I do here.
I understand this vulnerability that has existed for quite some time already (10y+), and by no means trying to take credit for them.
Perhaps I used wrong search terms when looking for related articles, or just that they was located at page 42 on google. Either way, I still hope you enjoy the read and perhaps learn something useful.

I've also seen a lot of people mistake this for a SYN flood attack. This attack relies on a full connection, not half open. So SYN cookies won't help you.

Since this is a already know vulnerability with existing attacks/pocs, I've decided to upload a trimmed down version of the kittenzlauncher.py (ddos/waf evasion, proxy jumping, c2 mode - is removed).

Original:

Some time ago, I found a design flaw/vulnerability which affects most TCP services and allows for a new variant of denial of service.
This attack can multiply the efficiency of a traditional DoS by a large amount, depending on what the target and purpose may be.

The idea behind this attack is to close a TCP session on the attacker's side, while leaving it open for the
victim. Looping this will quickly fill up the victim’s session limit, effectively denying other users to
access the service.

This is possible by abusing RFC793, which lacks an exception if reset is not sent.

RFC793 page 36
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.

What does this affect?

Most services running on TCP

Product handling TCP sessions such as:

Firewalls with session based policies

Routers and firewalls with NAT tables

Load balancers

and probably a lot more

Proof of Concept

Connect to a device with root privileges and drop all outgoing RST and FIN packets towards the victim server.

By adding a "Connection: keep-alive" to http/https request, increases the session hold time to at least the keep-alive time specified by the server.

The last packet from 173.194.222.100 is sent roughly 120 seconds after the attack occurred.
In most cases, the attack lasts equal to the time between first and last packet received, plus the time between last and second last packet.
This is because the server may not send out a "I'm done with you" packet at the end of it's FIN_WAIT1 state., something that can be confirmed by monitoring netstat during the attack on the victim side.
So for google.com, I would expect the total attack duration per request would be: (127-10)+(127-97) = 147 rounded up to 150 seconds.

Estimated TCP session timeout on a few popular sites

And if you weaponize it?

Disclosure

This vulnerability has been a real nightmare to disclose responsible. It could take several months before getting a reply with "TCP vulnerabilities are not within our scope.", or just no answers at all.
After multiple of disclosing attempts, I finally got in contact with EFF https://www.eff.org/security which pointed me in the right direction of CERT Coordination Center (CERT/CC) https://www.cert.org/, where the case was quickly handled with:

We're looking at updating the advisory to specify TCP RST packets too, but the problem in general appears to be a publicly known one. It's also unclear how the RFC could be updated to prevent this sort of attack in TCP.

Q/A

Q: How do I defend myself?A: Defending yourself means you have to tweak the timeout and retransmission settings, this could affect users with poor connections in a negative way.

Q: Will you release kittenzlauncher from that youtube video?A: Not planning to do so. Giving script kiddies a newb friendly attack tool with a ton of evasion and attack functionality would probably piss off more people than make others happy.