Geschreven door: Patrick Maes

In samenwerking met onze pentester: Martin Knuijsting

De kwetsbaarheid van deze week is Node.js ReDoS(Regular expression Denial of Service).

Node.js is een open source server side runtime omgeving gebouwd op JavaScript V8 Engine van Google Chrome. Die gemaakt is voor het bouwen van snelle en uitbreidbare netwerktoepassingen. Het is een JavaScript runtime. Een lichte, snelle en moderne manier om code uit te voeren op uw computer. 

Node.js applicaties die gebruik maken van de populaire url-regex bibliotheek zijn potentieel kwetsbaar voor Regular expression Denial of Service (ReDoS) aanvallen. De kwetsbaarheid, in eerste instantie ontdekt en ingediend door software engineer Nick Baugh, beïnvloedt alle versies van url-regex en is nog niet gepatcht. Het url-regex pakket wordt ongeveer drie miljoen keer per maand gedownload. Toepassingen maken gebruik van regular expression bibliotheken om op basis van relevante patronen te zoeken en te ontleden. Een kwaadwillende kan deze functie benutten door een zorgvuldig gemaakte string te sturen die een extreme situatie veroorzaakt. Hierdoor wordt de url-regex bibliotheek vertraagt tot een crawl en zorgt ervoor dat de applicatieserver stopt. Dit is de zogenaamde ReDoS aanval.

Geen reactie beheerders url-regex

De beheerders van url-regex hebben nog niet gereageerd op vragen van een aantal veiligheidsonderzoekers. Een advies van Snyk’s Security Team, gepost op de GitHub 2 juni luidt:

We hebben deze kwetsbaarheid geverifieerd en hebben contact geprobeerd op te nemen om deze kwestie verder te bespreken met de beheerders. Tot op heden hebben we nog geen reactie gekregen. Omdat deze kwetsbaarheid al publiekelijk bekend is gemaakt, voelen we ons verantwoordelijk om over te gaan tot een officiële bekendmaking.

De kwetsbaarheid is ook nog niet gepatcht. De uitstaande kwetsbaarheid heeft sommige ontwikkelaars ertoe aangezet om url-regex te ruilen voor andere regular expression bibliotheken. Baugh stelde voor om node-re2 te gebruiken, een regex bibliotheek die geen last heeft van dezelfde kwetsbaarheid.

Niet meer beschikbaar

De url-regex bibliotheek werd maandag 22 juni 2020 van het Wix website-bouwplatform verwijderd en vervangen door is-url-superb. Quote: “url-regex heeft een beveiligingslek. ‘is-url-superb’ Gebruikt een native url API om te controleren of tekst een geldige url is.” leest een beveiliging commitment dat op de GitHub repository van Wix is geplaatst. De beheerders van de postcss-values-parser bibliotheek hebben ook de url-regex verwijderd uit hun dependency tree, waarbij ze verklaren: “Er is een open kwetsbaarheid in url-regex (kevva/url-regex#70) en er is geen patch beschikbaar.”

PoC Node.js url-regex 

Hieronder ziet u de PoC

Details

Denial of Service (DoS) beschrijft een verzameling van aanvallen, allemaal gericht op het ontoegankelijk maken van een systeem voor de oorspronkelijke en legitieme gebruikers. Er zijn vele soorten DoS aanvallen, variërend van het proberen te verstoppen van de netwerkverbinding naar het systeem door het genereren van een grote hoeveelheid verkeer van vele machines, tot het verzenden van bewerkte verzoeken die een systeem laten crashen of die een onevenredige hoeveelheid tijd in beslag nemen om te verwerken. De Regular expression Denial of Service (ReDoS) is een soort Denial of Service aanval. Regular expressions zijn ongelooflijk krachtig, maar ze zijn niet erg intuïtief en kunnen het uiteindelijk makkelijk maken voor kwaadwillende om uw site offline te halen.

Laten we de volgende regular expression als voorbeeld nemen:

Deze regular expression bereikt het volgende: 

  • A De string moet beginnen met de letter ‘A’.
  • (B|C+)+ De string moet dan de letter A volgen met ofwel de letter ‘B’ ofwel een aantal keren dat de letter ‘C’ voorkomt (de + komt overeen met één of meerdere keren). De + aan het eind van deze sectie geeft aan dat we kunnen zoeken naar één of meerdere overeenkomsten van deze sectie.
  • D Tot slot zorgen we ervoor dat dit gedeelte van de string eindigt met een ‘D’.

De expression zou overeenstemmen met de input zoals ABBD, ABCCCCD, ABCBCCCD en ACCCCCD. In de meeste gevallen duurt het niet lang voordat een regex engine een match vindt:

Het hele proces van het testen van het tegen een 30 karakters lange string duurt ongeveer ~52ms. Maar wanneer een ongeldige string wordt gegeven, duurt het bijna twee seconden om de test te voltooien. Dat is tien keer langer dan het duurt om een geldige string te testen. Het dramatische verschil is te wijten aan de manier waarop regular expressions worden geëvalueerd.

De meeste regex engines zullen op dezelfde manier werken (met kleine verschillen). De engine zal overeenkomen met de eerste mogelijke manier om het huidige karakter te accepteren en door te gaan naar de volgende. Als het dan niet overeenkomt met het volgende karakter, zal het teruggaan en kijken of er een andere manier was om het vorige karakter te verteren. Als het te ver in de geheimzinnige spelonken(rabbit hole) gaat om er achter te komen dat de string uiteindelijk niet overeenkomt, kan het aantal backtracking stappen erg groot worden. Dit resulteert in wat bekend staat als catastrofaal backtracking. Laten we eens kijken hoe onze expressie tegen dit probleem aanloopt, door gebruik te maken van een kortere string: “ACCCX”. Hoewel het vrij eenvoudig lijkt, zijn er nog steeds vier verschillende manieren waarop de engine past bij die drie C’s:

1. CCC
2. C+CC
3. CC+C
4. C+C+C

De engine moet elk van die combinaties uitproberen om te zien of een van hen mogelijkerwijs overeenkomt met de uitdrukking. Combineer dat met de andere stappen die de engine moet nemen. Dit kunnen we met RegEx 101 debugger zien. De debugger toont aan dat de engine in totaal 38 stappen moet nemen voordat hij kan vaststellen dat de string niet overeenkomt. Van daaruit groeit het aantal stappen dat de engine moet gebruiken om een string te valideren door.

Tegen de tijd dat de string 14 C’s bevat, moet de engine meer dan 65.000 stappen nemen om te zien of de string geldig is. Deze extreme situaties kunnen ervoor zorgen dat ze zeer langzaam werken (exponentieel gerelateerd aan de grootte van de invoer, zoals hierboven is aangetoond). Hierdoor kan een kwaadwillende dit uitbuiten en kan de service overmatig veel CPU gaan verbruiken, wat kan resulteren in een Denial of Service.

Zorg dat u niet kwetsbaar bent

Met een kwetsbaarheid als deze kan uw organisatie grote financiële schade oplopen. Zorg dan ook voor een goed update beleid, waarbij frequent updates worden geïnstalleerd op kritische systemen. 

Om er zeker van te zijn dat uw netwerk zo min mogelijk kwetsbaarheden bevat, is het scannen van uw systemen noodzakelijk. Tijdens deze scan worden kwetsbaarheden blootgelegd en krijgt u handvatten hoe u uw netwerk beter te beveiligen tegen incidenten. Onze pentesters hebben de juiste kennis en kunde in huis om u hierbij van dienst te zijn. Zij zullen zorgvuldig uw netwerk scannen op kwetsbaarheden en u voorzien van een duidelijk advies waarmee u direct aan de slag kunt. 

Meer weten

Wil u meer informatie over onze pentesten of vulnerability scans? Kijk dan even op onze diensten pagina. Of bel direct met onze medewerkers via: 020 7881030, we zijn u graag van dienst.


Deel artikel via: