Cisco: omvangrijk tcp-lek bouwt voort op bekende kwetsbaarheden

Netwerkspecialist Cisco heeft na de publicatie van een lek in het tcp/ip-protocol een reactie op zijn website geplaatst waarin het bedrijf de impact van het lek analyseert en een voorlopige oplossing biedt.

Twee beveiligingsonderzoekers van Outpost24, Robert E. Lee en Jack Louis, kwamen de afgelopen weken in het nieuws vanwege hun claim een ernstig nieuw lek in het tcp/ip-protocol te hebben gevonden. Zij beweerden dat de kwetsbaarheid de mogelijkheid opent om netwerkverkeer ernstig te ontregelen door servers via dos-aanvallen offline te halen. Voor een dergelijke aanval, die op de handshake tussen twee partijen zou aangrijpen, zou slechts zeer weinig verkeer nodig zijn om met succes een server plat te leggen.

Cisco reageerde al enkele uren nadat Lee en Louis hun presentatie in Helsinki gaven. Tijdens die presentatie deden beide heren niet uit de doeken hoe de aanval precies in zijn werk gaat, naar eigen zeggen om derden niet de middelen te geven om netwerken te ontwrichten. In zijn reactie stelt Cisco echter dat de kwetsbaarheden waar de dos-aanval gebruik van maakt, al lange tijd bekend zijn. Het netwerkbedrijf onderzoekt nog welke gevolgen eventueel misbruik van de kwetsbaarheden op zijn apparatuur zou hebben.

Wel maakte het bedrijf alvast een advies bekend om de kans op misbruik van de kwetsbaarheid te beperken: laat alleen bekende, betrouwbare clients gebruikmaken van tcp/ip-services. Het spoofen, of vervalsen, van de afzender van de pakketjes is lastig, aangezien een aanvaller eerst een drieweg-handshake moet voltooien om de dos-aanval in te kunnen zetten. Behalve Cisco zullen ook andere fabrikanten van netwerkproducten en netwerksoftware, al dan niet in samenwerking met het Finse Cert, hun maatregelen nemen. De exacte details van de kwetsbaarheid zullen, naar verwachting, pas volgend jaar bekend worden gemaakt, zodat fabrikanten voldoende tijd hebben hun producten te beveiligen.

Reacties (33)

[Verwijderd]

Het gaat hier niet om een syn/fyn flood en ook niet om het uitschakellen van al het netwerk verkeer.
Het probleem voor zover beschreven is dat met een beperkt aantal packets 1 of meer services op de server crashen bijvoorbeel de http deamon of de ftp deamon of (en dit is best een leuke) een mail server die ge-root is zijn telnet\ssh\etc. services consequent laten crashen (kidnaping).

Bij een presentatie van het probleem lieten de mannen een web server crashen terwijl de rest lekker door bromde.

[CMG]

Als je kijkt naar uitleg die die maker van NMAP geeft, dan zou het werken door de resources helemaal op te gebruiken op een dusdanige manier dat de daemon de resources niet kan vrijgeven, wat vervolgens resulteerd in crashes of zelfs reboots. De resources die niet vrijgegeven kunnen worden zorgen er ook voor dat er geen poorten meer over zijn om te communiceren. De andere software mag dan wel niet crashen, met een beetje pech kan ook die software geen poorten meer openen om over te communiceren.

[brompot758]

De resources die niet vrijgegeven kunnen worden zorgen er ook voor dat er geen poorten meer over zijn om te communiceren

Een service communiceert altijd op een poort. Bijboorbeeld HTTP op poort 80. Alle inkomende verbindingen gebruiken bij jou dan poort 80, het is aan de aanvallers kant dat de poorten opraken na 65534 mogelijkheden. Daarboven moet de aanvaller meer IP adressen gaan gebruiken.

Wat op kan raken is zijn de sockets, file descriptors, geheugen e.d.

[jimbo123]

Quote uit het artikel:

Wel maakte het bedrijf alvast een advies bekend om de kans op misbruik van de kwetsbaarheid te beperken: laat alleen bekende, betrouwbare clients gebruikmaken van tcp/ip-services.

Dat lijkt mij niet handig wanneer je een webserver hebt draaien.
Je kunt toch niet gaan bepalen welke clients wel/niet je websites mogen bekijken?

[TD-er]

Dat lijkt mij niet handig wanneer je een webserver hebt draaien.
Je kunt toch niet gaan bepalen welke clients wel/niet je websites mogen bekijken?

Maar je kunt wel het aantal connecties per IP-adres beperken en connecties resetten als er een bepaald gedrag te zien is. (bijvoorbeeld bij veel connecties die gewoon open staan, waar nog geen data over is gegaan).
Nu is dat laatste niet op een heel erg praktische manier op te lossen, omdat dat "gedrag" natuurlijk makkelijker aan te passen is aan de kant van de aanvaller dan dat het te detecteren is aan de kant van het slachtoffer. Nieuwe definities laden zou natuurlijk een oplossing kunnen zijn, maar dan zijn we alweer bezig een nieuw zwak punt te introduceren.

[gertvdijk]

Het verhaal heeft nu al veel gelijkenis met het DNS lek van Dan Kaminsky.

[TD-er]

Het DNS-lek van Kaminsky was meer een man-in-the-middle attack.
In het kort:
- Vraag aan een caching-nameserver een adres op, wat niet meer in die cache staat.
- Die nameserver gaat proberen uit te zoeken welk adres het wel moet zijn, door de authoritive nameserver te vragen.
- Zorg dat je jouw antwoord naar de caching-nameserver stuurt, voordat de authoritve server kan antwoorden. Dit doe je door het poortnummer te "raden" waarop die server het antwoord verwacht.

Daardoor kun je de cache van die nameserver dus vervuilen met foute informatie en ook best wel voor een lange tijd, door een hoge TTL mee te geven.

Dit lek is meer een probleem dat 1 computer alle beschikbare connecties opvult, zodat een nieuwe connectie niet gebruikt/opgezet kan worden.

[CyberSnooP]

Dit bewijst maar weer hoe moeilijk het is om een protocol te ontwerpen. Al bestaat het al zo lang en is het door zoveel mensen bekeken, je kunt altijd nog zwakheden ontdekken.

[KroontjesPen]

Het ontwerpen is voor een bepaald doel gebeurd en heeft aan de verwachtingen voldaan incl. veiligheid. Als men dat ontwerp voor andere doelen gaat gebruiken alleen op het feit dat het goed werkt is dat niet juist.
Om een kind uit een keukenkastje te houden is een simpele beveiliging voldoende.
Je gaat dat dan ook niet voor de voordeur gebruiken.

[MneoreJ]

Nou moet daarbij gezegd worden dat IP en TCP in beginsel ook niet ontworpen waren met (D)DOS in het achterhoofd, en in zekere zin zitten dat soort kwetsbaarheden (met halfopen verbinding) al ingebakken in het protocol zelf. Het vangt "eerlijke" netwerkproblemen op, maar geen moedwillige sabotage (die dingen lijken vaak maar niet altijd op elkaar).

Was er toen al een complete commissie geweest die in de toekomst kon kijken en rekening hield met schalen naar miljoenen computers en volksstammen aanvallers dan was de situatie ongetwijfeld anders geweest...

[g4wx3]

Een goede site om je hierover te informeren is http://www.grc.com/

Dit is geen site om te leren hacken, maar wel om te begrijpen hoe hackers het doen

[DRaakje]

http://insecure.org/stf/tcp-dos-attack-explained.html

Dit klinkt als een goede verklaring hoe deze exploit waarschijnlijk in elkaar steekt.

[Verwijderd]

Ziet er allemaal uit als een storm in een glas water. En Tweakers gaat lekker mee met alle andere sites: nieuws rapporteren dat er nog helemaal niet is. Die knullen hebben gezegd 'oh jeej, we hebben nu iets ontdekt, maar we zeggen lekker nog niet hoe het in elkaar steekt'. Vervolgens allemaal paniek in de ICT-wereld, maar we moeten nog maar zien hoe erg het allemaal daadwerkelijk is.

[i-chat]

mensen met een beetje netwerk achtergrond zullen wel kunnen raden hoe het werkt,
en geloof me ddos kan knap lastig zijn, en veel vervelender gevolgen hebben dan alleen maar niet kunne chatten op jouw favo irc bruttel, of het uitvallen van je favoriete website.

om maar eens wat te noemen steeds meer internationaal betalings verkeer gaat tegenwordig gewoon over TCP/ip verbindingen en die wil je NIET plat hebben.

dat dergelijke gasten jouw niet aan je neus willen hangen hoe het precies werkt kan ik wel waarderen, ik zou het ook niet hebben gedaan.

[Mesjefskie]

om maar eens wat te noemen steeds meer internationaal betalings verkeer gaat tegenwordig gewoon over TCP/ip verbindingen en die wil je NIET plat hebben.

och, door de huidige 'crisis' is er toch al niet zo heel veel internationaal betalingsverkeer meer...

Maar on-topic: Volgens Cisco is het mogelijk het risico aanzijnlijk te verkleinen:

It is possible to mitigate the risk of these vulnerabilities by allowing only trusted sources to access TCP-based services. This mitigation is particularly important for critical infrastructure devices. PSIRT recommends the implementation of infrastructure access control lists (IACLs) and control plane policing (CoPP) to protect core network functionality

Ik mag er hopelijk wel van uitgaan dat organisaties die betalingsverkeer verzorgen alle mogelijke maatregelen hebben genomen om hun netwerk te beveiligen...

[marquis]

och, door de huidige 'crisis' is er toch al niet zo heel veel internationaal betalingsverkeer meer...

Als die internationale verkeer stillicht, stopt ook de beschaving. Alles zal als dominostenen omvallen.

Maar, is dit probleem niet opgelost als je met certificaten per server gaat werken? Als er ergens een server geen certificaat heeft, dan geen toegang. Op desktop nivo met certificaat zou het, volgens mij, net zo goed werken.

offtopic: het valt me op dat bij Tweakers.net toch een hele hoop specialisme zit. Ik zie hier hele interesante verhalen.

[Reactie gewijzigd door marquis op 23 juli 2024 07:16]

[Bloodshot]

Eh, nee. Certificaten worden pas gebruikt als de TCP/IP-sessie al staat.
Dit probleem los je dan ook niet op door de hogere lagen te beveiligen met certificaten.

Dit probleem "los je op" door alleen met vertrouwde IP-adressen sessies op te zetten/sessies op te laten zetten. (Dit is natuurlijk dus geen oplossing voor bijvoorbeeld Internet-zaken)

[CMG]

Yup, Fyodor is ook wel iemand die enige ervaring heeft op dit gebied. Maar toch, het was niet onder het grote publiek bekend en best een mooie/elegante manier van DoS attacks.

[The-Source]

Ik hoop dat ze daarmee niet Sync flooden bedoelen want daar klinkt het heel erg naar gezien de omschrijving. (pakketje is ter grootte van ping packetje maar vraagt rekenkracht van cpu om te beantwoorden)
En een aantal jaar geleden toen ik dat interessant vond bleek dat al te bestaan en je mag toch hopen dat dit het niet is

[Gerco]

Nee, het is geen SYN-flood, maar wel iets wat er kwa resultaat op lijkt.

Het gaat erom dat de server bepaalde resources alloceert (geheugen, timers) om een verbinding te servicen. Deze resources worden door de aanvallers bezet gehouden door de verbinding op een slinkse manier open te houden zonder daadwerkelijk data te hoeven versturen.

Als je dit met genoeg verbindingen tegelijk doet tegen 1 server dan zal deze alle beschikbare resources in gebruik hebben en dus geen nieuwe TCP verbindingen meer kunnen accepteren, effectief DoS dus.

[Pixeltje]

Hmm, ik had eerlijk gezegd meer paniek verwacht. Er werd een week geleden al gesproken over 'grootse onthulling' etcetera. Gevaarlijk zal het wel zijn, maar gezien de milde reacties overal denk ik niet dat er een reëel gevaar dreigt.

De vergelijking van KroontjesPen gaat goed op denk ik, Het protocol heeft zijn nut bewezen op veel verschillende vlakken, en de fouten die nu gevonden worden vloeien voort uit het inzetten van dit protocol voor doeleinden die het ontwerp niet meegerekend heeft.

[nutty]

Hm doet me denken aan de UT servers waar ook een stackfout in zit,deze exploit lijkt van hetzelfde principe gebruik te maken,De server raakt confused door het in de war brengen van de stackvolgorde,hoe ze het doen geen idee maar dat komt het dichtst in de buurt.

[Rob Coops]

Ehm, nou ja en nee...

Deze aanval is heel iets anders dan een virus, een virus of malware, kan bijvoorbeeld je data verwijderen, beschadigen of doorsturen naar een ander, dan wel ongewenste data op je computer zetten of door je computer uit laten sturen (spam bijvoorbeeld).

Deze aanval doet niets meer dan de server plat leggen en dus je netwerk verkeer blokkeren, of de computer zelf ook onderuit gaat hangt denk ik meer af van de drivers en het besturings systeem dan van iets anders.
Het lek is in princiepe niets meer dan een boodschap naar server sturen die door de TCP/IP stack (het deeltje van je netwerk driver dat de boodschappen ontvangt en verstuurt) niet begrepen wordt en de stack zo in de war weet te krijgen dat deze in zijn geheel faalt. En dus geen verkeer meer, wat natuurlijk erg vervelend is voor bijvoorbeeld een web sever...

Maar op de een of andere manier heb ik het gevoel dat de aanval wat ik van de omschrijving hoor redelijk lastig is uit te voeren, daar naast denk ik zo dat Cisco, Juniper en andere heel erg snel met een fix zullen komen. Al vraag ik me wel af of Cisco's beweering dat dit al heel lang bekend is echt waar is, waarom zouden ze da nu pas onderzoeken hoe hun apperatuur gaat reageeren op zo'n aanval...

[TD-er]

Wat ik begrepen heb van dit lek is dat de aanvaller een connectie open zet en erna niets meer met die connectie doet, dus ook niet de verbinding afbreken.
Als je dat een aantal keer gaat herhalen, tot het maximum aantal connecties bereikt is (voor die service), dan is de server feitelijk onbereikbaar.
Doordat je zo weinig traffic hiervoor nodig hebt, kun je dat zelfs al met een dial-up verbinding bereiken.

Je kunt natuurlijk op de server per service het max. aantal connecties per IP beperken. Hier zit echter het probleem dat je nog steeds vatbaar bent voor een distributed attack en mogelijk zou je ook fake pakketjes kunnen sturen met een vervalste afzender. (al weet ik niet hoe je dan een verbinding dmv een handshake op kunt zetten)

[brompot758]

Je kunt dit aanpakken door rate limiting toe te passen. Specifiek kun je connection rate limiting gebruiken.

IPtables heeft hier een al goede implementatie van. Je kunt bijvoorbeeld 1 minuut lang elke seconde een connectie toestaan en daarna 3 per minuut, met een timeout van 5 minuten. Aangezien de SYN received timeout standaard op 60s staat kan een aanvaller nog maar 3 aanval packets uit hebben staan waar je last van hebt (na de eerste minuut), daar kan je OS wel tegen. Tijdens de normale operatie merk je er dan niets van, tijdens een aanval blijft je server overeind. Als je druk aangevallen wordt dan is het altijd lastig om de dienst die aangevallen wordt te bereiken.

Ook de aanval die in de podcast omschreven wordt door middel van het wel doorlopen van de '3way handshake' van tcp kun je door middel van rate limiting aanpakken. Tijdens de aanval is je service even slecht bereikbaar (maar dat is bij elke aanval) en zodra de aanval ophoudt doet je server het weer.

Je hoeft iets dergelijk alleen maar in je firewall aan te zetten. Met een linksys routertje met Tomato of DD-WRT ben je dus al onder de pannen......

Samenvattend is het best een serieus probleem, maar met bestaande middelen in elk geval in Linux in 5 minuten op te lossen.

[ejay79]

Leuk dat je dat kan met Linux, fanboy, maar wat doe je met proxy's?
Daarbij gaat dit niet werken.

Ik denk namelijk dat een thuisgebruiker (zoals jij en ik) niet interessant is om te gaan irriteren.

[Superstoned]

dat is 1 manier, ja. Het gaat hier om een groep problemen, jij noemt 1 manier om misbruik te maken van de specificatie. Een andere zou zijn om met elke handshake ramgeheugen te reserveren op de target, totdat deze door een out-of-memory onderuit gaat.

Het probleem met deze fout is dat het, in tegenstelling tot wat een aantal andere mensen hier roept, feitelijk WEL een fout in het protocol is. Tenminste inzoverre, dat als je het protocol echt goed implementeerd je systeem kwetsbaar is voor deze fout...

[Verwijderd]

Virusscanners en malware-cleaners zitten een paar stappen hoger in het OSI-model dan de tcp/ip stack.

Ze zijn dus zeker niet overbodig, alleen de hier beschreven kwetsbaarheid zit een paar niveaus lager.

Anders gezegd: elke laag is kwetsbaar, en er is niet 1 oplossing die tegelijk alle lagen beveiligt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:16]

[PierreG]

Voor degene die niet precies weten wat het OSI model is:
http://nl.wikipedia.org/wiki/OSI-model

Het beschrijft de manier waarop data via een netwerk wordt verbonden. Het TCP/IP protocol is slecht 1 van die lagen.

[Verwijderd]

bijna juist.
TCP/IP is een protocol stack en dus eigenlijk een model op zich.
In het OSI model zit TCP bv. op transport laag, IP op netwerk laag.
Ik denk dat je OSI model en TCP/IP model door mekaar slaat.

[Verwijderd]

Dat heb ik dus volkomen verkeerd begrepen, bedankt voor de eigenlijk duidelijke uitleg.

[Verwijderd]

Zover ik begrijp uit de eerdere artiekelen is het probleem niet zo zeer de TCP/IP stack, maar de implementatie hiervan in de besturing systemen. Met het protocol zelf lijkt dus weinig mis mee te zijn.