Onderzoekers leggen kwetsbaarheid in firewalls bloot

Onderzoekers hebben nieuwe aanvalsmethodes gepubliceerd die een ernstige kwetsbaarheid blootlegt in het initial sequence numbers-protocol. Het gat zou in firewalls van een groot aantal mobiele aanbieders voorkomen.

Het toevoegen van initial sequence numbers (ISN) aan datapakketten is als een patch ingevoerd om eerdere hacks via spoofing op tcp-verbindingen tegen te gaan. ISN gebruikt daarvoor pseudowillekeurige volgnummers. Een groot aantal firewalls van bekende fabrikanten zoals Cisco, Juniper en Check Point implementeren ISN en verwerpen pakketten die incorrect zijn. Juist deze eigenschap maakt de weg vrij voor een aantal nieuwe aanvalsmethoden, zo stellen onderzoekers van de universiteit van Michigan in een rapport.

De onderzoekers stellen in 'Off-Path TCP Sequence Number Inference Attack' dat zij een tcp-verbinding konden kapen door gebruik te maken van software op een Android-smartphone en een mobiele provider die ISN ingeschakeld heeft op zijn firewalls. Zo was het onder andere mogelijk om http-verbindingen met diensten als Facebook, Twitter en Windows Live Messenger over te nemen door middel van een zogenaamde on-site tcp hijacking-aanval. Daarbij wordt de oorspronkelijke server in de communicatie buiten spel gezet en communiceert een slachtoffer ongemerkt met de aanvaller.

Een andere aanvalsmethode kan bijvoorbeeld cookies stelen van een gebruiker die is ingelogd op een website, zo schrijft Ars Technica. Ook zou het mogelijk zijn om met behulp van malware uit de veilig geachte sandboxomgeving van een browser te breken om zo data van andere applicaties buit te kunnen maken.

Uit een onderzoek naar de mogelijke kwetsbaarheid van 150 mobiele aanbieders blijkt dat 48 van hen ISN ingeschakeld hebben op hun firewalls. Via een Android-applicatie kan een smartphonebezitter ook zelf testen of zijn telco kwetsbaar is; een snelle test op de redactie van Tweakers.net laat zien dat de firewalls van KPN door de app als kwetsbaar worden gekwalificeerd, terwijl er geen definitief oordeel wordt geveld over de netwerkapparatuur van Vodafone. Het netwerk van T-Mobile is niet getest.

Ondanks dat het merendeel van de aanvalsmethoden alleen ingezet kan worden als applicaties of websites data zonder encryptie versturen, en het gebruik van ssl- en tls-protocollen dus enige bescherming zouden bieden, kunnen de technieken ook ingezet worden voor dos-aanvallen. Daarnaast is het de vraag of mobiele aanbieders ISN zullen uitschakelen op hun firewalls omdat zij veel dataverkeer kunnen besparen door verdachte ip-pakketjes al bij de toegangspoort te weigeren.

Reacties (37)

[no-sense]

Ik heb 't document even doorgelezen en ik heb een aantal opmerkingen:

- Dit is niet per se een probleem van mobiele aanbieders. Ook het "gewone" internet kan kwetsbaar zijn zolang er maar een stateful firewall tussen staat. Iedereen die thuis een router heeft met een firewall zouden misschien kwetsbaar kunnen zijn als de firewall out-of-sequence packets dropt.

- Een tussenliggende firewall hoeft out-of-sequence packets helemaal niet te droppen. De ontvanger zelf zal ze ook al weggooien. De grootste winst voor een ISP om intermediate sequence nummer checking te doen is het besparen van bandbreedte.

- Deze vulnerability heeft niet 1 maar 2 actieve aanvallers nodig (in de simpelste vorm, andere scenarios hebben zelfs 3 verschillende samenwerkende attackers nodig), 1 aan beide kanten van de kwetsbare firewall. Ik behandel hier verder het simpelste scenario (reset-the-server hijacking)
De eerste aanvaller dient zich op of vlakbij het slachtoffersysteem te bevinden (in het document wordt uitgegaan van malware op 't systeem van het slachtoffer)
Het tweede systeem dient aan veel meer eisen te voldoen:
- Het dient in het pad van het slachtoffer naar de server te staan.
- Het moet communicatie tussen client en server kunnen afvangen.
- Attacker 1 (de malware) dient van attacker 2 op de hoogte te zijn (hij moet attacker 2 melden dat er een verbinding opgezet wordt)

Gebaseerd op enkele aannames en feiten die ik nu ga doen ga ik beweren dat dit weliswaar een daadwerkelijke zwakte is maar dat het in de praktijk wel mee zal gaan vallen.
aanname 1: als de aanvallers een grote kans op succes willen hebben dienen ze een punt in handen te krijgen wat dient als attacker 2 die veel attacker 1's kan bedienen. Dit wijst al op een grote router, die i.h.a. niet zo simpel te kraken zijn.
aanname 2: attacker 2 dient heel selectief te zijn in welke sites afgevangen moeten worden. Normaal verkeer tussen client en server wordt onmogelijk gemaakt en attacker 2 zal de bewuste website/dienst goed na moeten doen anders regent het klachten over onbereikbare diensten.
aanname 3: Het is voor internetcriminelen veel makkelijker om de malware al het werk te laten doen. Geen moeilijke attacker 2 nodig. De aanname is dat de successrate te laag zal zijn voor de gemiddelde attacker.
aanname 4: als de malwareverspreiding een groot succes is zal attacker 2 al snel effectief geDDOSs worden door de stortvloed van meldingen van duizenden attacker 1's.
feit 1: encryptie zal deze en alle andere genoemde schema's laten mislukken. Banksites e.d. zullen dus al geen target zijn.
feit 2: deze methode is niet onzichtbaar. Er zal vrij snel ergens een attacker 1 gevonden worden en daarmee is attacker 2 ook heel snel gevonden. De gecompromitteerde router schoonmaken of domweg uitzetten en rerouten zullen alle attacker 1's waardeloos maken, De trend onder malwareschrijvers is juist om dit soort single-points-of-failure onmogelijk te maken.

Ik voorzie dan ook dat deze methode an sich niet populair zal worden onder malwareschrijvers. Maar ga hier geen geld op zetten, veel malwareschrijvers zijn een stuk slimmer dan ik

[280562]

Helemaal met je eens.
Wat deze twee schrijvers voorstellenis allemaal of 1) heel generiek, of 2) waardeloos in praktische zin.

Ze stellen bv hoe je een TCP connectie kunt hijacken als je al malware op de target machine hebt draaien. Wtf ? Waarom zou je makkelijk doen als het ook moeilijk kan ? Als je al malware hebt draaien, dan ben je er al. Klaar.

Ook het raden van portnumbers wordt afgedaan als iets wat je makkelijk kunt doen. 1) Malware (alweer ?), 2) "Simply guesses", (tuurlijk!) 3) attacker initializes the connection himself (dan zit je er al tussen! Bovendien, veel success en connectie naar mijn browser te initieren).

Ze stellen voor hoe je achter het IPID kunt komen. (Het identifier veld in de IP header). Hun methode zou misschien werken, als ze de enige gebruiker van de firewall waren. Zodra er meer traffic door de firewall gaat wordt het een stuk lastiger, zou ik denken. Bovendien, volgens mij hoef je helemaal het IPID niet te weten om TCP-hijacking te doen ....

Ik vind het maar een flut-paper.
Ja, als er een firewall tussen twee computers zit, dan zou je die misschien kunnen gebruiken om info te ontfustelen die je kunt gebruiken voor TCP-hijacking. Maar dit paper stelt niet echt nieuwe methodes voor. En ik geloof ook niet dat ze een attack werkend hebben gekregen. Allemaal hypothethische aannames, als als als als.

[280562]

Man man man, wat is de kwaliteit van dit stukje bedroevend.
Als je niet begrijpt waar je over schrijft, schrijf dan gewoon het persbericht over.
Het is Dimitri gelukt om zelf mij flink in de war te brengen. Ik moest het 3x terug lezen om te zien waar het nu over ging.

het initial sequence numbers-protocol

Er is geen ISN protocol.
Het gaat gewoon om het TCP protocol. Wat deel uitmaakt van de "TCP/IP protocol suite".

Het toevoegen van initial sequence numbers (ISN) aan datapakketten

Het TCP protocol gebruikt een sequence-number. Als sinds dag 1 (ergens in de jaren tachtig). Als je een nieuwe verbinding opzet, dan werd dat sequencenumber gewoon op 1 gezet. Daarna verhoogt het gewoon met ieder pakketje dat je stuurt. (Het SQN is eigenlijk gewoon het aantal bytes dat je verstuurd hebt).
Het bleek (20 jaar geleden) dat je vrij gemakkelijk fake pakketjes kon sturen naar een andere computer die een bestaande verbinding had. Door er voor te zorgen dat de attacker het sequence-number niet makkelijk kon raden, kon je dat voorkomen. Je doet dat door het sequencenumber in het eerste pakketje geheel random te maken. Dat noem je "randomizing of the initial sequence number in TCP".

Een groot aantal firewalls van bekende fabrikanten zoals Cisco, Juniper en Check Point implementeren ISN

Niemand implementeert ISN. ISN is geen protocol. ISN is geen aparte techniek. ISN is een deel van het alledaagse TCP protocol.

Hopelijk is dat wat duidelijkere taal.

En btw, het is mijzelf nog steeds niet helemaal duidelijk wat de schrijvers van dit paper nu precies nieuw doen ....

[Reactie gewijzigd door 280562 op 23 juli 2024 22:26]

[knoffy]

t-mobile
firewall middlebox = not detected

[Reactie gewijzigd door knoffy op 23 juli 2024 22:26]

[Zilla]

Bij HI (NL KPN) krijg ik not detected. Kan dit te maken hebben met de firewall van mijn toestel. Het lijkt er dus op dat HI wel zijn zaken goed geregeld heeft.

[Macfreakje]

Ik heb ook HI (NL KPN) en bij mij krijg ik ook not detected. Lijkt me geen toeval dan en staat de firewall uit voor HI abonnees.

[Mel33]

Hm het check programma Firewall middlebox detection, zegt bij mij 'not sure'
Ook Vodafone hier.3G

2de test wel vulnerable, hmm ??

firewall update binnen gekregen, maar helpt ook niet.

edit:
Ook steeds bij de 2de test wel kwetsbaar op WIFI en 3G.
de eerte test is aldoor 'not shure' of 'not detected'
ook als ik de app kill in taakbeheer is het bij de eerste keer 'not shure'
Maargoed me provider is kwetsbaar, ook me thuis-provider en mijn 3.75G/ Wifi-router.
Alles lek blub blub ik zink

Ga twijfelen aan het appje.......

[Reactie gewijzigd door Mel33 op 23 juli 2024 22:26]

[wootah]

Bij mij zegt ie continu vurnable voor Vodafone...

Op WiFi zegt hij dat ook trouwens... Ik gebruik gewoon een vrij normale iptables firewall:
- in principe alles blokkeren wan->lan behalve uitzonderingen
- lan->wan alles doorlaten

In de paper kon ik niet direct terugvinden hoe dit te voorkomen is met iptables... iemand een idee?

Maargoed, even mijn android firewall aanzetten en je maakt gehakt van dit test programma

[Mel33]

Welke Firewall gebruik jij dan?

[wootah]

netfilter, meer bekend als iptables, gewoon linux.

Voor android heb ik dit: https://play.google.com/s...m.lbe.security.lite&hl=nl

[Kosty]

Dus een MitM-aanval via een mobiel netwerk kan ook gemakkelijk? Geweldig gevoel moet je dan hebben als je even op het internet wilt op een dichtbevolkte plaats (een makkelijk doelwit).

BASE (KPN, in België) geeft trouwens bij mij "Not detected".

[Fire69]

Proximus geeft "Detected, network and device vulnerable"

[itarix]

Vodafone heeft volgens dit programma wel een kwetsbaarheid

[Rudie_V]

Hier wordt vodafone wel als kwetsbaar gedetecteerd:

Carrier: Vodafone NL

Network type: mobile.GPRS
Firewall Middelbox: Detected, your network and device are vulnerable.

Network type: mobile.HSPA
Firewall Middelbox: Detected, your network and device are vulnerable.

[zvbhvb]

Dan vergroten ze de entropy pool toch.

[Jack Flushell]

Vodafone (wifi uit):

Firewall middlebox: Detected, your network and device are vulnerable

[Anoniem: 195390]

zou het zo kunnen zijn dat de kwetsbaarheid regio gebonden is?
dat instelling niet in alle wijkcentrales gelijk zijn [ als dit over wijkcentrales loopt ]

of speelt line sharing hier ook nog een rol in ?