Fout in Linux-implementatie van standaard laat aanvaller verbinding manipuleren

Een lek in de Linux-implementatie van de rfc 5961-standaard laat een aanvaller verbindingen tussen twee partijen onderbreken en maakt het mogelijk om bijvoorbeeld malware te injecteren. Volgens de ontdekkers zijn grote internetsites kwetsbaar.

De kwetsbaarheid, die is ontdekt door onderzoekers van de universiteit van Californië, stelt tcp-verbindingen bloot aan een zogenaamde 'off path'-aanval, dat schrijft Ars Technica. Daarbij is het voor een aanvaller niet nodig om zich tussen twee communicerende partijen te bevinden, zoals bij een man-in-the-middle-aanval. Er is alleen vereist dat de aanvaller kan vaststellen dat er communicatie plaatsvindt.

Het lek met kenmerk cve-2016-5696 doet zich voor in de Linux-implementatie van de redelijk nieuwe rfc 5961-standaard, dat aanwezig is vanaf versie 3.6 van de kernel. Het probleem is opgelost in versie 4.7 van de kernel. Deze moet echter nog in de verschillende distributies opgenomen worden. Rfc 5961 heeft juist tot doel om verbindingen veiliger te maken en is op dit moment alleen geïmplementeerd in Linux, niet in Windows of OS X.

Om een aanval op basis van de kwetsbaarheid uit te voeren, is vereist dat de aanvaller kennis heeft van de ip-adressen en poorten waarlangs de communicatie tussen twee partijen plaatsvindt. Vervolgens kan hij de server bestoken met spoofed pakketten. Hierdoor stuurt de server challenge ack's totdat het maximum is bereikt, waarna de aanvaller zich tot het doelwit kan richten en spoofed pakketten kan versturen om de verbinding te verbreken of gegevens te injecteren op een onversleutelde verbinding. The Register meldt dat er een tussentijdse oplossing is door de regel net.ipv4.tcp_challenge_ack_limit = 999999999 aan /etc/sysctl.conf toe te voegen en sysctl -p uit te voeren als root.

Door van een dergelijke aanval gebruik te maken, toonden de onderzoekers aan dat zij kwaadaardige javascript in de website van USA Today konden injecteren. Ook is het mogelijk om ssh en tor-verbindingen te onderbreken. Injectie kan alleen plaatsvinden in onversleutelde verbindingen. "Het unieke aspect van de aanval is dat deze zonder veel vereisten uitgevoerd kan worden", zo legt onderzoeker Zhiyun Qian aan The Register uit. Een dos-aanval op het Tor-netwerk kan volgens de wetenschapper grote gevolgen hebben voor de beschikbaarheid van de dienst. Dit komt terug in hun onderzoek.

Reacties (50)

En voor de volledigheid:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696

Wil er nog iemand zijn mening geven over de patch om sysctl_tcp_challenge_ack_limit van 100 naar 1000 te wijzigen en er wat willekeurigheid aan toe te voegen i.p.v. publieke op kunnen vragen van de challenge ACK limiet te blokkeren?:
https://github.com/torval...c455b6822ab09e533c551f758

[Reactie gewijzigd door Anoniem: 801137 op 11 augustus 2016 17:54]

De beschrijving van de werking in dit artikel is grovelijk onnauwkeurig.
Een betere beschrijving vind je op https://lwn.net/Articles/696868/

Een korte transcript:
1) maak een normale connectie
2) zorg dat je op deze connectie tegen de challenge ACK limiet aanloopt
3) stuur dan zowel voor de normale connectie als voor de te proben connecties spoofed packets
Op dit manier kun je dan zien of er een connectie is tussen de 2 hosts of niet

Vervolgens:
1) maak een normale connectie
2) zorg dat je op deze connectie tegen de challenge ACK limiet aanloopt
3) stuur dan opnieuw voor je eigen connectie als voor de te proben connectie spoofed packets, maar zoek daarbij met verschillende sequence nummers, zodat je het TCP window kan bepalen. Dit kan je dan verkleinen tot je het echte sequence nummer hebt.

Eens je die combinatie hebt, kun je de connectie verbreken of packets injecteren.

Een andere kantopmerking is dat niet alle spoofed packets over het internet raken. Volgens onderzoek is ongeveer de helft van de addressen te spoofen.

Door dus de limiet op te trekken van 100/s naar 1000/s is het moeilijker om de timing goed te krijgen, door randomness toe te voegen weet de aanvaller niet of het ontbreken van een challenge ACK betekent dat hij iets gevonden heeft of als het gewoon een dropped packet is.

Het publiek op kunnen vragen van de sysctl is enkel voor local users, niet voor remote users - dit is een issue wat je remote moet uitvoeren.

Dank, die was ik vergeten!

http://askubuntu.com/ques...erable-from-cve-2016-5696
issue is bij beperkt aantal builds van toepassing, kunt je kernel up- of downgraden, op git vind je evt patches

Mwa, beperkt aantal builds, alle ondersteunde versies van Ubuntu (12.4.5, 14.4.x en 16.4.x)
https://people.canonical....curity/cve/pkg/linux.html

Ook is het mogelijk om ssh en tor-verbindingen te onderbreken. Injectie kan alleen plaatsvinden in onversleutelde verbindingen.

Is dit niet tegenstrijdig? SSH en TOR zijn toch versleutelde streams?

Het sleutelwoord is *onderbreken*. De stream wordt onderbroken door op het TCP-niveau (onder de TLS laag dus) een TCP FIN te injecten. Dat trapt de TCP-verbinding onder je SSH/HTTPS/TOR verbinding vandaan, en breekt dus ook die af.

De data die over een dergelijke beveiligde verbinding verstuurd wordt kan hiermee echter niet ontsleuteld of aangepast worden.

Het sleutelwoord is *onderbreken*. De stream wordt onderbroken door op het TCP-niveau (onder de TLS laag dus) een TCP FIN te injecten. Dat trapt de TCP-verbinding onder je SSH/HTTPS/TOR verbinding vandaan, en breekt dus ook die af.

De data die over een dergelijke beveiligde verbinding verstuurd wordt kan hiermee echter niet ontsleuteld of aangepast worden.

Overigens iets vergelijkbaars als de Great Firewall of China doet om verbindingen met "staatsgevaarlijke" hosts te verbreken. In dat geval is het een MITM aanval, maar daar wordt ook gebruik gemaakt van een vervalst TCP FIN-pakket wat te herkennen is aan een andere TTL dan de pakketten met verkeer over het internet.

Aan de gebruikerskant krijg je alleen maar te zien dat de verbinding daardoor onverwachts wordt verbroken, blokkades kun je ermee bereiken maar je kan nog altijd niet meekijken.

Maar in het geval van TOR kan het er wel toe leiden dat de aanvaller controle krijgt over welke TOR relays/exit nodes gebruikt worden aangezien TOR bij een disconnect een connectie naar een andere node zal opzetten.

Zo zou de NSA bvb een bestaande node kunnen zover krijgen om te connecteren op 1 van hun nodes, waarna ze MITM attacks kunnen proberen uitvoeren. In het ergste geval zouden ze zo zelfs het hele pad van TOR packets van een bepaalde target kunnen 'pellen' (om in de uien-wereld te blijven).

Ah, het is dus een denial of service ipv een redirect op de beveiligde verbindingen. Duidelijk

Het verbreken van verbindingen via deze methode lijkt me duidelijk, maar hoe kan dit nu precies worden gebruikt om gegevens te injecteren?

De aanval maakt het mogelijk om in een TCP verbinding de frame-nummers te raden en je eigen antwoord te spoofen.

Als deze aanval het raden van het frame-nummer makelijker maakt en dit an-sich leidt tot het kunnen spoofen van een antwoord als je weet dat de verbinding er is... Kun je dan niet stellen dat TCP antwoorden altijd al te spoofen waren en dat het hiermee alleen maar wel/niet significant makkelijker wordt?

Ik vind het persoonlijk ieder geval niet zo spannend. Als je geen TLS gebruikt ben je sowieso niet beveiligd bezig. En het kunnen verbreken van verbindingen mits je weet dat de client de verbinding heeft is nou ook niet bepaald schokkend, aangezien je praktisch een MITM uit moet voeren om dit te kunnen weten.

Inderdaad. Technisch gezien zijn TCP verbindingen altijd te spoofen. Echter moet je weten wie met wie communiceert EN het frame-nummer weten op het exacte moment dat je spooft. Er zijn echter miljarden mogelijke frame-nummers. De kans dat je, @random, de juiste poorten, IP's en het frame-nummer correct raadt is nagenoeg onmogelijk klein en je kunt ook niet weten hoe dichtbij je bent met je gok.

Echter kan het nu zonder MITM door random verbindingen te gokken tussen twee partijen. Daar de server (met bestaand IP en poort) bekend is heb je een stuk minder variabelen. Bovendien kun je met deze bug dus "warm/koud" spelen om er achter te komen of een bepaald IP een verbinding heeft en langzaam ook welke het actieve frame nummer dat dan moet zijn.

Er zijn echter miljarden mogelijke frame-nummers.

Kleine nuancering het zijn er maar ~4,2 miljard (32bit).

Om het volgnummer te raden moet je in het ontvangstvenster zitten.
Als je bijvoorbeeld een ontvangst venster hebt van 12600 dan heb je nog maar zo'n 340870 blokken die je moet doorzoeken.

En niet vergeten dat je dan ook nog een van de tienduizenden bronpoorten die gebruikt werden juist moet gokken. Als je al weet wat de bestemmingspoort (80/443), bron IP en bestemmings IP is.

"in the first round the attacker can test the port range from 32768 to 65535
(the most likely half) in a 1-second interval. If the actual
port number falls in the range, then the challenge ACK
observed by the attacker at the end of the interval wil be 99 (one goes to the victim). If the actual port number
does not
fall in this range, the observed number of challenge ACKs will be 100. "

[Reactie gewijzigd door Anoniem: 801137 op 11 augustus 2016 15:22]

Precies, je kunt dus "zeven":

Meest waarschijnlijke helft proberen; lukt dat, probeer je vervolgens de helft van deze range, anders van de andere range. enz.

Als het goed is ben je met maximaal 16 pogingen bij de juiste poort (en dus niet 65000)

totale aanval heeft dus wel zo'n 30-60 seconden nodig, omdat je hierna nog de sequence moet "zeven". Verbinding moet ook niet de window size aanpassen in de tussentijd en lang genoeg openblijven.

Dus moest windows dit op dezelfde manier implementeren moet je misschien een keer minder zeven want de ephemeral range is kleiner (49152-65535) ?

Om het volgnummer te raden moet je in het ontvangstvenster zitten.
Als je bijvoorbeeld een ontvangst venster hebt van 12600 dan heb je nog maar zo'n 340870 blokken die je moet doorzoeken.

Maar de window size hangt toch af van veranderende variabelen (linkwaliteit, buffertoestand van de hosts) en is dus niet constant. Zodoende moet je toch een conservatieve schatting maken ? Niet dat 12600 echt groot is.

"Zodoende moet je toch een conservatieve schatting maken ?"
Klopt, dat dan staat ook in de paper. Is de schatting te laag, dan verspil je tijd omdat het pas lukt na meer pogingen dan noodzakelijk is. Is de schatting te hoog, dan heb je kans dat de sprong van het ene volgnummer naar het andere volgnummer te groot is en je het ontvangstvenster overslaat.

Dat staat letterlijk (technisch) in het artikel uitgelegd.

Om maar even duidelijk te zijn: Alleen bij onbeveiligde HTTP connecties is dit mogelijk, bij websites die gebruik maken van TLS(HTTPS) is dit niet mogelijk omdat connecties encrypted zijn, wel is het (als het goed is) nog steeds mogelijk om connecties te onderbreken.

[Reactie gewijzigd door MrFax op 11 augustus 2016 10:35]

wel is het (als het goed is) nog steeds mogelijk om connecties te onderbreken.

Klopt, maar een andere limitatie die niet genoemd wordt in het artikel is dat de aanval nog best even duurt. Het kan al snel enkele tientalle seconden duren. Meeste TCP/IP connecties zijn dan al verbroken.

Dat de demo USA Today gebruikt is dan ook geen toeval, want die site houdt de connectie bewust onbeperkt open, omdat het dynamisch nieuwe content kan doorsturen. Bijvoorbeeld als je scrolt op de voorpagina. Websites/connecties die kort duren zijn niet snel kwetsbaar omdat de aanval gelukkig te lang duurt.

KeepAlive.

Dit is een onontkomelijk gevolg van het vooraan lopen in veiligheid maatregelen. Als je RFCs niet eens implementeert (Microsoft, Apple) kan je ook geen fouten maken. Ik vind dat de titel doet blijken alsof niet-Linux implementaties deze fout niet bevatten. Er zijn geen niet-Linux implementaties die deze RFC (trachten) te implementeren.

Dat mag natuurlijk nooit een excuus zijn om een RFC maar foutief te implementeren.
Als je een toepassing toevoegt die de security laat toenemen maag het effect nooit omgekeerd Zijn.
Hoe dan ook een fikse blunder die je niet moet bagatelliseren door vergelijkingen te trekken met andere systemen.
Mogelijk denken die eerst na voordat ze iets op de markt zetten waardoor ze wat trager zijn maar wel hun verantwoording nemen.

[Reactie gewijzigd door SED op 11 augustus 2016 15:15]

Dat is juist het probleem een beetje met de titel: mensen denken dat het zit in de RFC of het vermangelen van wat de RFC moet doen, maar de RFC is correct geïmplementeerd.

De huidige implementatie heeft echter een negatieve bijwerking die je in staat stelt indirect wat te vertellen over een andere verbinding.

Ook is de implementatie van de RFC niet fout an sich. Het doet exact wat het moet doen. Het laat alleen onbedoeld een manier open om dingen te weten te komen van een andere verbinding, omdat als je een bestaande verbinding spoofed je een iets ander antwoord krijgt dan een niet bestaande verbinding.

Uit het Ars Technica artikel:
"It is a subtle problem," researcher Zhiyun Qian told Ars when asked if the vulnerability resided in the RFC specification itself or a specific implementation of it. "I want to say that the RFC is written in a way that if OSes implement it straightforwardly, it is going to be problematic. So I think we should probably split the responsibility between the RFC and implementation."

Er zijn geen niet-Linux implementaties die deze RFC (trachten) te implementeren.

Het is dan ook een goed gebruik in de security wereld om traag te zijn met nieuwe implementaties. Ook betreft security features.

Dus lekken fix je snel, maar nieuwe features ben je bewust traag mee.

Wat dat betreft is er al een hele tijd een trend waar te nemen bij tweakers.net dat het steeds meer om 'views' gaat in plaats van vooraanlopen met (technische) nieuwsfeiten.

Het valt me op dat het soms wel 2 dagen kost tussen dat een feit ergens gepubliceerd is, voordat het ook op tweakers verschijnt. Zelfs tussen de tech deel van nu.nl en tweakers zit een merkbare 'lag'.

Voorlopig tweakers maar volgen via rss en alleen maar kijken naar die artikelen die me echt de moeite waard lijken en 'uniek' zijn.

De titel is wel incorrect. Verbindingen zijn zonder dit protocol ook te manipuleren (tcp-packets injecteren kan van overal op het internet, ik kan zo een packet naar jouw ip adres sturen met een spoofed bron-ip), terwijl de titel doet suggereren dat er door de aanwezigheid van deze implementatie extra onveiligheden bij komen.
Voor zover ik het begrijp is dat niet zo, aangezien het bij afwezigheid van deze rfc ook al mogelijk is, en is het niet meer dan dat de implementatie niet doet wat het zou moeten doen.

Is het een fout in het genoemde protocol? Ja

Is het een fout in de linux implementatie? Ja

Staat er iets in de titel wat niet waar is? Nee

Gaat het over andere protocollen? Nee

terwijl de titel doet suggereren dat er door de aanwezigheid van deze implementatie extra onveiligheden bij komen

Het wordt er niet veiliger op, het protocol is bedoeld om het veiliger te maken. Maar doet dit niet. Het geeft nu een vals gevoel van veiligheid waardoor je misschien bepaalde andere beveiligingen gaat aanpassen of uitzetten omdat dit als vervanging werkt.

Ik zie het probleem niet.

Als de titel zou zijn: " fout in implementatie", is de eerste vraag die je krijgt: "welke implementatie?"

Dit is echt miggenziften en het niet leuk vinden dat er iets negatiefs gezegt word wat gewoon waar is.

Mogen we dan ook niet zeggen dat er een bug in Android zit omdat Windows ook bugs heeft?

[Reactie gewijzigd door ronaldmathies op 11 augustus 2016 11:15]

Is het een fout in het genoemde protocol? Ja
Is het een fout in de linux implementatie? Ja

Is het een fout in het protocol? Nee het protocol gaat over het tegengaan van flooding aanvallen en heeft niets direct te maken met de eigenlijke bug

Is het een fout in de linux implementatie? Deels de implementatie geeft onbedoeld een ander antwoord op geldige en niet geldige verbindingen. De implementatie doet WEL wat er verwacht wordt in de RFC en is zodoende niet fout

ah, dus stel dat ik bij mij op het werk een protocol schrijf, dat perfect doet wat het moet doen maar de rest van de poorten openzet, is dit geen fout in mijn implementatie en is het geen fout in het protocol?

[Reactie gewijzigd door Yoshi op 11 augustus 2016 11:33]

Heel andere situatie. Dit is namelijk niet wat er hier aan de hand is.

De hier genoemde RFC beschrijft een manier om SYN aanvallen op een server te beperken. Dit wordt gedaan door simpelweg minder verbindingen per seconde toe te staan en zodoende te voorkomen kan een aanvaller een onbeperkt aantal verbindingen kan opzetten en zodoende de server overbelasten. Dat is alles wat er in de RFC staat.

Het probleem is nu dat, door de gekozen implementatie in linux en de gekozen lage limiet (100), het mogelijk is de beveiliging op een specifieke manier expres af te laten gaan op een manier die je in staat stelt wat te vertellen over een bestaande verbinding (die je moet raden overigens).

Als de 100 veel groter was, was de aanval niet mogelijk. Als de window niet per seconde was, maar meer (10 seconden of zo) was de aanval niet mogelijk. Als de attempts per seconde random gegenereerd werd tussen 100-200, was de aanval niet mogelijk. Als de verdediging per client zou werken in plaats van de gehele server was de aanval niet mogelijk.

Een echte bug in zover dat de implementatie precies doet wat die moet doen, maar op een manier die misbruikt kan worden door de gekozen parameters

De RFC5961 zorgt er ook voor dat bij een SYN met een volgnummer dat in het geldige ontvangstvenster valt de verbinding niet automatisch gereset wordt, maar dat er altijd een 'challenge ACK' wordt gestuurd, waarna een RST teruggestuurd moet worden met het juiste volgnummer dat afgeleid moet worden van de 'challenge ACK'.

De titel is niet incorrect, maar op zijn minst suggestief.
Maar ja, dat is journalistiek.

Een minder vrij interpreteerbare titel zou zijn:
"Fout in Linux-implementatie van beveiligingsprotocol neutraliseert beveiliging."

(Overigens heb ik geen probleem met de huidige opzet, ik spring enkel in op de semantische discussie.)

Is het niet een beetje apart dat een RFC die tcp security zou moeten verbeteren er juist voor zorgt dat je makkelijker aangevallen kan worden?

RFC != implementatie ervan...
Een RFC is een algemeen beschrijvend document dat geen code bevat. Dergelijk document kan dan op verschillende manieren worden geïnterpreteerd en geïmplementeerd.

Nou, ik had net RFC1321 open (MD5, gebruikt in HTTP authentication) en daar staat gewoon source code in hoor. Sowieso is er weinig ruimte voor interpretatie. Je hebt wel gelijk wat betreft mogelijke implementaties; het is zeker niet verplicht om code uit een RFC exact te gebruiken.

In RFC1321 op zich staat geen code, In bijlage A vind je evenwel een referentie implementatie dewelke men mag overnemen, maar die men niet verplicht moet overnemen.

Het is een "side-channel" aanval: het misbruik van de verdediging voor 1 ding misbruiken voor de aanval op iets anders. Deze aanpassing verdedigt tegen SYN en RST aanvallen op servers, maar indirect, omdat er shared resource wordt gebruikt voor alle verbindingen, kun je door de verdediging expres te activeren wat te weten komen over een andere verbinding.

Als er een random hoeveelheid ACK's toegestaan zouden worden per bucket of de verdediging per verbinding zou worden gemaakt zou het probleem niet ontstaan

Dat is een flinke waarde die in het artikel wordt aangeraden, de default volgens kernel.org is 100.

Zitten er aan zo'n hoge waarde geen nadelen/gevaren?

Ja / nee . Deze aanval is een side-channel aanval. Deze hoge waarde zet de SYN/RST verdediging die RFC 5961 moet bieden uit, zodat die niet misbruikt kan worden tegen andere verbindingen.

Dank voor de uitleg. Kwam de kwestie ook net tegen op The Register, daar wordt ook het een en ander uitgelegd.

Misschien is het ook nuttig om te vermelden waarvoor RFC 5961 bedoeld is:

TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.

Oftewel: precies het soort aanval dat nu beschreven word moeilijker maken. Jammer genoeg heeft Linux deze RFC zodanig geïmplementeerd (via een globaal maximum voor de Challenge ACKs) dat het mechanisme bedoeld om de bescherming te verhogen gebruikt kon worden om de aanval mogelijk te maken.

Verder schrijven de onderzoekers

In this paper, we discover a much more powerful offpath attack that can quickly 1) test whether any two arbitraryhosts on the Internet are communicating using one or more TCP connections (and discover the port numbers associated with such connections); 2) perform TCP sequence number inference which allows the attacker to subsequently, forcibly terminate the connection or inject a malicious payload into the connection.

Het is dus niet noodzakelijk om vooraf kennis te hebben van de gebruikte TCP poorten zoals het Tweakers-artikel suggereert.

Dat is niet helemaal juist, de RFC beschrijft een methode om SYN aanvallen moeilijker te maken en dat doen ze door het aantal toegestane nieuwe verbindingen te beperken. En dat aspect werkt ook zoals bedoeld. Dat doel is dus behaald.

Het probleem is ook niet per se dat het een global-maximum is op de server. Het is alleen een vast global-maximum. Als het aantal toegestane verbindingen per seconde subtiel zou veranderen per window wordt deze aanval ook onmogelijk.

Je moet nog steeds de poort raden om de aanval te kunnen doen, echter is er maar 1 variable (de poort van de client):

Therefore, the only unknown is
the source port the client uses. The maximum possible
port range is 2
16
= 65536, and the default range on Linux
is only from 32768 to 61000.