10/01/2008

Major update 2 TCP/IP Attack flaw : the info between the echo-storm

They have been holding it secret they say for three years and are now - in advance of a presentation in October - publicizing some information but not the technical details they say. Well you don't need many technical details. I don't know the real reasons for their going public, but if it has been so long, have they at any moment talked to the CERTS and Security people to work at a solution as was done with DNS lately ? They had been talking about it for some weeks.

First it is a super vulnerability because you could have an effective DDOS against any machine with less than 10 packets a second and it would effectively WORK. Imagine that you send with a small utility 10 packets a second an you can bring down whatever system. I don't know but that would interest even the dummiest of script kiddies. Now you have got all the attention you needed.

Second they did it with this tool - enfin during the tests with this tool they saw that some services just went down and started to investigate. So I have the tool, the effect and what I should look for. Even better they have even limited what I should look for by naming their tool sockstress

and even a better description was published here : "

Many TCP servers use a technique known as a SYN cookie in order to prevent attackers using spoofed IP addresses from launching SYN flood denial-of-service attacks against them. The cookie is essentially a chosen TCP initial sequence number that is calculated using some specific hashed metadata that reflects the details of the specific TCP connection. Once the client returns a correct packet to the server, the server knows that the client isn't using a forged IP address. Sockstress computes and stores so-called client-side SYN cookies and enables Lee and Louis to specify a destination port and IP address. The method allows them to complete the TCP handshake without having to store any values, which takes time and resources. "We can then say that we want to establish X number of TCP connections on that address and that we want to use this attack type, and it does it," Lee said.Lee and Louis have been able to execute a number of different attacks, which consumer various resources on the server, including memory, kernel timers and counters, and applications"

Thirdly there is no solution, patch, workaround and IPV6 is also no solution at all they say. Or something totally unworable like this : ""The best advice I have right now is don't allow anonymous connections. Make whitelist so only certain IP addresses can come in," Lee said, acknowledging the impracticality of that for a Web server or mail server or virtually any other TCP-enabled device. "There's no real workaround right now."

Except for this interview (forward 5 minutes for english) there are no Proof of concepts available. Yes, found one, Here

"Robert E. Lee and Jack C. Louis enters the speakerbox and raises the bar a bit on what tech-level the talks are being done at. Robert and Jack are telling us that there is a new way of DDOSing hosts, which dosen't require hardly any bandwidth. There is unfortunately no security against this type of attack yet, so they won't tell us specifics. Some of the things I am picking up is that you have to spoof this type of attack, because otherwise you will be taken down by your own attack. Now they are demoing the attack on a windows box. Not a very powerful demo, but interesting.
Actually, the demo was cool. With 200 packets per second, they DDOSed an apache on a wintendo in seconds. They estimate 7KBPS is all they need to DDOS just about any webserver.In addition, they just killed a whole windows box with this attack. They said that they have successfully destroyed a whole box with this kind of attack. It wouldn't boot afterwards. This with low bandwidth. An interesting comment they just made is that they almost sold this."

and here

"The next demo was even better. The started playing music on the very same laptop and then started Sockstress. After about two minutes the music wouldn’t play the way it was supposed to. It was slowed down, the CPU was at 100% etc. They then stopped sockstress but the machine never came back. It kept misbehaving even though the attack was over. What was really interesting was that both these attacks only sent 4 packages each second to the server machine. That’s nothing and could be done on a 56k modem"

Updates will follow, I release already this version 1 while working on it and adding information that is coming in and finding its way on the web

The journalist himself declares that he has seen enough technical information to be convinced (he was also behind the reporting about the DNS bug) and that a CERT and a big ITplayer are working on it

"Weet het punt is dit: Jullie willen de harde technische details zien. Dat snap ik helemaal. Die irritatie had ik ook bij Dan Kaminsky met zijn DNS-bug. Ik ben niet over 1 nacht ijs gegaan. Ik wist dit al twee weken, maar wilde eerst nadenken of ik dit wilde doen.  Later heb ik meer en meer bewijs gekregen en goed doorgevraagd waarom ze dit wilde. Ik ben doorgegaan. Heb her en der gecheckt (en ook de relevante RFC's nog eens goed doorgelezen). Gisteren heb ik het gepodcaste interview gedaan, maar daarvoor heb ik drie keer telefonisch contact gehad (kortere interviews) om feiten helder te krijgen. Uiteindelijk wilden we gisteren publiceren, maar ik was nog niet tevreden en wilde ook zeker weten dat er een CERT mee bezig was. Dat was het geval. Toen was het te laat om door te gaan tot vanochtend. Uiteindelijk zijn we dus om vier uur online gegaan. Van de dingen die ik wel weet, maar beloofd hebt niet te publiceren ben ik er van overtuigd dat dit een serieus, echt probleem is. Anders had ik het niet opgetekend. Natuurlijk schiet ik het wel vol in als het verhaal eenmaal doorgaat. Dat mag helder zijn. Dat de tekst wat eenvoudiger overkomt is, omdat je de feiten wel wilt geven maar het ook nog begrijpbaar moet houden. Veel mensen onder de lezers zijn diep technisch onderbouwd. Helaas stel je die teleur, maar de waarschuwing hoorde echt in het artikel. Voor jullie informatie: dat heeft zijn doel niet gemist. Inmiddels blijkt een grote speler vandaag nog personeel op de zaak te hebben gezet. Dat waren ze eerder ehh .... 'vergeten' zullen we maar zeggen."

In essence, one of 5 already developed and several still to develop attacks it boils down to this (would time-out and drops help ?) 

- You open a TCP connection using a normal 3-way handshake (so, spoofed packets won't work anyway
- Then you use certain packets to keep the connection open with a minimum amount of traffic? - This way you try to open and keep open as much TCP connections possible without doing anything and thus prevent others from using said service?

Technical contacts for firms and CERT

Outpost24 BV
Weteringschans 106 II
1017 XS Amsterdam
Telefoon: 020-4209560
Fax: 020-3303844

15:19 | Permalink | Comments (0) | Email this | |  del.icio.us | | Digg! Digg |  Facebook

Post a comment