Fout in TCP-protocol kan leiden tot DoS-aanvallen

Een zwak punt in het ontwerp van het TCP-protocol kan leiden tot een nieuwe soort DoS-aanvallen, aldus het Engelse National Infrastructure Security Co-ordination Centre (NISCC). Door een TCP-pakket van een valse afzender en een reset-commando te voorzien kunnen willekeurige gebruikers een verbinding tussen twee punten afbreken. Om dit tegen te gaan worden de pakketten in een TCP-datastroom genummerd met 32-bits getallen, zodat een operating systeem in principe makkelijk zou moeten kunnen zien wanneer een pakket buiten de echte stroom valt, en dus genegeerd moet worden. Voorheen werd daarom aangenomen dat deze onvolkomenheid in de praktijk niet tot problemen zou kunnen leiden.

Op CanSecWest 2004 presenteert Paul Watson echter zijn onderzoek "Slipping in the Window: TCP Reset Attacks", waarin hij het tegendeel bewijst. Omdat veel TCP-implementaties in verband met performance ontworpen zijn om een grote range van volgnummers te accepteren is de kans dat een kwaadwillend stuk software een geldig volgnummer raadt, en zijn pakketten dus door de ontvanger geaccepteerd worden, een stuk groter dan eerder werd aangenomen. In principe is iedere applicatie die afhankelijk is van openstaande TCP-verbinding kwetsbaar om op deze manier aangevallen te worden, hoewel het per toepassing verschilt hoeveel schade dat kan aanrichten.

Het NISCC vreest vooral voor aanvallen op routers die gebruikmaken van het Border Gateway Protocol (BGP). Routers gebruiken onderling langdurig openstaande TCP-verbindingen om elkaar via dit protocol op de hoogte te houden van de opbouw en status van het netwerk om zich heen. Als de BGP-sessies worden platgelegd met de beschreven reset-aanval kan de router vreemd gedrag gaan vertonen en mogelijk zelfs tijdelijk offline gaan. Verschillende bekende bedrijven (waaronder Cisco en Juniper) hebben al updates beschikbaar gesteld om hun producten hiertegen te beveiligen. Anderen zijn nog bezig met onderzoeken in hoeverre ze kwetsbaar zijn, en sommige fabrikanten hebben zelfs al trots laten weten dat ze er geen last van hebben.

Reacties (39)

[Confusion]

Voor dat iedereen moord en brand gaat schreeuwen: het valt mee en wordt door veel bronnen door mensen met onvoldoende verstand van zaken overdreven. Zie de /. draad van gisteren: http://slashdot.org/article.pl?sid=04/04/20/1738217&mode=thread&tid=12 6&tid=128&tid=172&tid=95 en lees vooral de commentaren: er zijn er een aantal die grondig inzicht bieden in het werkelijke probleem.

edit:
Ach, niveautje te hoog gereageerd: dit was als reactie op Scarecrow (die overigens terecht op 0 gemod is (dus misschien niet zichtbaar voor je) bedoeld.

N.B. Ik bedoel dus niet dit artikel, maar bronnen als de Telegraaf.

[C7RL]

Echt er word echt VET overdreven en terecht gesproken over een hype! Zelfs bij ons op het werk gingen een paar van die gasten over de rooie, riepen moord en brand BLAAT! Iedereen weet al jaren dat BGP ook alle nadelen heeft van TCP, of er zijn collega's geweest die hebben lopen slapen. Het plat leggen van een netwerk door het raden van het goede sequence nummer en ook nog het sturen van een RST pakket vanaf een endhost naar een router die BGP draait die ook nog eens geen ingress/eggress filtering (ACL's en anti-spoofing ) gebruikt, is bijzonder klein. Maar goed ook wij netwerk beheerders moeten aan het werk blijven en die security gasten vertrouwen zelfs hun eigen moeder niet eens zo achterdochtig zijn ze

[The Jester]

...en sommige fabrikanten hebben zelfs al trots laten weten dat ze er geen last van hebben.

En die vertrouw ik dus niet.
Juniper en Cisco zijn hebben samen vrijwel de gehele Ultra-High Bandwidth markt in handen en steken dan ook de meeste centjes in R&D. En dan zouden een paar van de kleinere spelers géén last hebben van fenomeen
Lijkt mij van niet, dus...

[Belgar]

Dit is wel mogelijk hoor. Juist omdat cisco en juniper de grote jongens zijn, zijn ze ietwat gevoeliger voor dit probleem. Theoretisch dan. Producten die alleen lagere snelheden kunnen bedienen maken meestal ook gebruik van kleinere windows. Juniper heeft overigens, afgezien van meer BGP updates, geen problemen met crashes door deze bug.

[0siris]

er staat dan ook duidelijk:

Verschillende bekende bedrijven (waaronder Cisco en Juniper) hebben al updates beschikbaar gesteld...

[franssie]

voor 90% moet je echter wel een zeer verspreidde aanval inrichten, bij elke router die je plat legt raak je namelijk ook alles achter die router kwijt. Een (1) foute achtie op een router van je ISP en je hebt jezelf te pakken en niet de rest van het internet ... je zal jezelf dus ook verblinden als je niet oppast

[Verwijderd]

Wie zegt dat een router plat gaat? Er gaat een connectie plat. En als je dat met genoeg connecties doet dan is de router connectieloos. De router gaat niet plat. .

[Verwijderd]

Zoals hierboven inderdaad al aangehaald: een storm in een glas water en dit is al jaren bekend!! Dit is eigelijk maar gewoon combinatie van IP spoofing, resetflag in tcpheader aanzetten, en probleem omtrent predictable sequencenumbers. En naar mijn weten zijn deze problemen dus al veel langer bekend .... beetje uitgemolken dus!

[El Snorro]

hm, het is toch DDOS (Distributed Denial Of Service)??
Of is dit de nieuwe afkorting...

[Verwijderd]

In principe kan dit gebruikt worden in een DDOS attack ja.
Één methode om een DDOS uit te voeren is om een hele berg SYN pakketjes te sturen. SYN vraagt de ontvanger om een nieuwe TCP verbinding op te stellen. Op het moment dat de SYN ontvangen wordt worden er resources geallocceerd voor die verbinding.
Als er dan niks meer gedaan wordt met die nieuwe verbinding worden die resources niet meer vrijegegeven voor een tijd x, waar x de timeout van een TCP verbinding is. Kun je nagaan dat je een server plat kunt leggen als je deze de hele tijd nieuwe verbindingen laat maken.

Deze methode is juist het tegenovergestelde. Je breekt bestaande verbindingen af. Je stuurt een RST en de verbinding wordt greset/verbroken. Behoorlijk vervelend voor applicaties die over een lange tijd één zelfde TCP verbinding gebruiken (bijv: FTP or telnet)

Op zich vind ik dit weer een storm in een glas water. Ergens moet je op een laagste niveau defineren hoe een sessie (lees: verbinding) er uit ziet. Je kunt wel weer alles gaan encrypten zoals recentelijk de trend lijkt te zijn, maar bij grote en snelle data transfers loop je dan HEEL snel tegen performance problemen aan. Dus de encryptie mag ook weer niet te sterk zijn. Daarbij stelt zelfs de huidige encryptie vaak niet veel voor. Ik heb gehoord dat de WLAN encryptie (128 bits) met een dagje rekenen en een gigabyte aan data te kraken is.

[Olaf van der Spek]

Dus de encryptie mag ook weer niet te sterk zijn. Daarbij stelt zelfs de huidige encryptie vaak niet veel voor. Ik heb gehoord dat de WLAN encryptie (128 bits) met een dagje rekenen en een gigabyte aan data te kraken is.

Dan moet je eens kijken naar 448-bit Blowfish, Twofish of AES. Dan ben je wel wat langer zoet en dit soort algoritmes kan erg snel zijn in hardware.

[genosis]

nee distributed houd in van meerdere aanvallers..

[El Snorro]

Sorry dan

[Tyrian]

DoS = Denial of Service attack, niet gedistribueerd dus. (point-to-point attack)

[Robby]

Je kan de kans dat je systemen zo worden ge-dos'ed makkelijk verkleinen : zorg gewoon dat je op je BGP sessie authenticatie via MD5 enabled.

Zelfs protocollen die een al relatief veilig zijn doordat ze meestal korte connecties opzetten zoals HTTP kunnen worden beveiligd door de servers simpelweg via HTTPS te draaien.

[Verwijderd]

Je hebt de advisory niet goed gelezen. . IPSEC is veilig vanwege encryptie. Het verschil tussen HTTPS encryptie en IPSEC encryptie is de layer waarin de encryptie plaats vindt. In IPSEC vind die voor de transport layer plaats (namelijk in de network layer), in HTTPS na de transport layer plaats (namelijk in de applicatie layer). IPSEC is dus al geencrypteerd op het moment van exploit, en dus is het onmogelijk om op dit niveau van de verbinding paketten toe te voegen voor de DoS-style attack. Bij HTTPS is deze layer nog ongeencrypteerd en kun je dus paketten toevoegen en daarmee de connectie resetten, ongeacht of er na dat niveau nog encryptie plaats vindt.

[LinuxMan]

Zelfs protocollen die een al relatief veilig zijn doordat ze meestal korte connecties opzetten zoals HTTP kunnen worden beveiligd door de servers simpelweg via HTTPS te draaien.

jezus wat een onzin, http en https gaan beiden over tcp, dus er is nul komma nul verschil...

het enige dat verschil maakt is de voorspelbaarheid van je tcp sequence number en je accepted window size. Dus http op openBSD is vele malen beter dan https op NT om es een extreme te noemen.

[coller]

is dit op zowel ipv4 als ipv6?

[stunn0r]

het heeft niks met ip te maken het gaat over tcp dus het lijkt me dat je ook met ipv6 dit probleem zou hebben

[maartena]

Is het niet zo dat ook TCP is aangepast bij IPv6?

[Kwaak]

Laat je BGP router alleen sessies acepteren van zijn peers... en dan valt het probleem best wel mee... of mis ik nu ergens iets??

[Erkens]

je mist idd iets, immers het gaat hier om het feit dat een willekeurig iemand een verbinding kan verbreken, zoals bijvoorbeeld deze BGP verbindingen.
Om dit te doen moet je zoals het artikel vermelde je afzender faken, dus doen alsof je een router bent die al met hem verbonden is, en je stuurt het verbinding reset commando mee.
Maar om dit te "beveiligen" had men volgnummertjes bedacht, als je dus een geldig nummertje verzint wat zich in de (relatief grote) range zit die geaccepteerd wordt, denk de router dat het van de bekende partij komt, en weg is je verbinding.
Oplossing is dus om die range dusdanig klein te houden, alleen dan krijg je wellicht weer performance problemen.

[Goldwing1973]

kan de router vreemd gedrag gaan vertonen en mogelijk zelfs tijdelijk offline gaan

M.A.W.

Als je genoeg van die routers tegelijk plat krijgt... Internet offline..

brrrr... eng idee

En dan vraag ik me nog af, het internet zoals we dat nu kennen is in fases steeds groter geworden.
Stel DAT het iemand lukt om 90% plat te krijgen, de apparatuur is er echt niet op berekend / ontworpen om tegelijk weer aan te gaan....

[Rex]

[sarcasm]Ja, zeker een eng idee....[/sarscasm]

Maar het geldt niet voor het internet die we vandaag de dag hebben.... Weet je hoeveel miljarden routers er zijn? Internet plat is dus wel heel overdreven...

[Verwijderd]

" Weet je hoeveel miljarden routers er zijn? "

Nou, geen miljarden in ieder geval. We zijn maar met 5 milljard mensen op de wereld.
Ik denk eerder enkele honderdduizenden, waarvan enkele tienduizenden voor echte zware backbones worden gebruikt.