In regards to Fyodor's article:
There are some really valid points made; While his article does describe some of how sockstress works and why it is efficient, it does not describe our attacks.
Louis would like to stress that turning off server side SYN-Cookie protection will not help and will only make you open to syn flood attacks again (as stated in Fyodor's article).
Also, scenarios that lead to systems being resource starved to the point of requiring a reboot is very attack and target specific. It is not as universal as causing a specific service to become unavailable. We have made this clear in all public communications, but it is worth saying again.
Thursday, October 2, 2008
Subscribe to:
Post Comments (Atom)
9 comments:
Sounds like this partly uses an old scanning technique of separating the sender and the receiver.
In a best case scenario there are two hosts at play here from the attackers point of view. A sender and a receiver.
Step 1 (Sender): Construct a TCP packet with the source address defined as the receivers address. All the rest can be whatever server you are attacking etc. Make a hash of the IP/TCP header using sip,sport,dip,dport and that as your ISN.
Step 2 (Sender): Send the packet out.
Step 3 (Victim): Recv the packet, send a syn/ack back to the receiver.
Step 4 (Receiver): This service passively listens to the network for SYN/ACK traffic. When a packet is seen, it will take the sequence number, subtract it by 1, and see if it matches the hashing mechanism you created.
Step 5 (Receiver): If the hash matches, simply create the final ACK packet and send, this will complete the three way handshake.
Since the handshake has been completed, the socket is now under to kernel based timeout limitations. Thus you can go through these steps many times in a longer period of time.
Then again, that's just a guess.
I admit it, I didn't read the fyodor post. I apparently said the same thing.
I posted a basic overall interpretation on Linux Today http://www.linuxtoday.com/security/2008100600535NWNT .
I was wondering what someone has to do to get involved in this and save some time (ie, gain access to more details and software/source code). I don't think I have time, but this is very interesting, and it seems that before a clever (set of partial) solution(s) is found (which may take some time), kernel or other code might be improved to help mitigate some of the worse attacks [I have Linux contributions in mind.]
As a possible first whack at solving this problem (whose details I don't really know), perhaps a reserved bit in the IP header can be used to allocate an initial portion of the payload (maybe ahead of TCP or within TCP) as reserved for the IP protocol handlers from the servers/routers/etc to play the same game and store state data within the packet. Having not given much thought to this, I have no clue if this is an accurate approach, practical, possible, sensible, etc (or even if IP has unused bits in the header). Also, I don't even know the problem, just have a guess based on the audio interview.
Thanks.
@fdsa
The vulnerabilities Louis discovered are post handshake. How we complete the handshake may be considered interesting to some, but is unrelated to the actual vulnerabilities.
@jose_x
For right now, we're actively working with vendors on solutions. If you are a vendor of a TCP stack, you should contact CERT-FI.
Otherwise, please be patient. All of the details will be shared in due time.
I don't understand. The old tool netkill (http://www.securiteam.com/tools/5QR0B000AU.html) do the same or there is a difference?
@Denis
Netkill/Naptha represent 0window and socket flood attacks.
It is possible to cause some bad effects using those attacks, but those just represent 2 possible stresses. Sockstress has several other stresses, some of which cause different outcomes.
We'll have all the details out around easter of next year, possibly sooner depending on what's talked about at CCC this year.
Ok. Thank you. And what is CCC?
@Denis
CCC is Chaos Computer Club, Congress. It is one of the major conferences in Europe.
http://events.ccc.de/congress/2008/
One of the talks there is about TCP DoS:
http://events.ccc.de/congress/2008/Fahrplan/events/2909.en.html
We don't yet know what they independently discovered... but Fabs is the author of Portbunny, and works with FX. Both of those researchers know enough about TCP to rediscover at least some of the findings we've been talking about, and possibly something we've missed.
Will have to wait until their talk to know if we need to send out complete advisories sooner than Easter.
Post a Comment