Gevaren van een enumeratie-aanval

Kortgeleden, bij het testen van een blockchain-platform op kwetsbaarheden, ontdekten onze Kaspersky BlockChain Security-experts dat het proces voor het resetten van een wachtwoord kwetsbaar was voor een aanval via gebruikersnaam-enumeratie. Webdevelopers moeten zich bewust zijn van dit soort aanvallen en de gevaren ervan.

Wat is een enumeratie-aanval?

Webapplicaties met wachtwoord- en login-authenticatie omvatten normaal gesproken verschillende componenten die met de gebruikersdatabase communiceren: het inlogvenster (om voor de hand liggende redenen), het registratieformulier (om het dubbele gebruik van gebruikersnamen te voorkomen) en de wachtwoord-resetpagina (om te verzekeren dat het corresponderende account bestaat). Als webdevelopers deze features niet op veilige wijze implementeren, kunnen aanvallers ze gebruiken om erachter te komen of een bepaalde gebruikersnaam al in de database bestaat.

In het verleden was het gebruikelijk voor developers om al deze features zonder enige bescherming te implementeren, en aanvallers konden dan een lijst met gebruikersnamen en een programma gebruiken dat ze één voor één invoerde. Na verloop van tijd begonnen developers om potentiële hackers buiten de deur te houden met het toepassen van beschermende trucs, zoals captcha, beperkingen van het aantal inlogpogingen en het gebruik van sterretjes of wat anders om bepaalde ingevoerde gegevens te verbergen.

In moderne webapplicaties beschikt het inlogvenster normaal gesproken over dit soort bescherming. Maar bij registratieformulieren en wachtwoord-resetpagina’s ontbreekt het hier soms nog aan. Daar komt bij dat webdevelopers niet altijd rekening houden met het feit dat de aanwezigheid of afwezigheid van een gebruiker in de database bepaald kan worden door de timing van het antwoord van de server. Als de gebruikersnaam bijvoorbeeld in de database verschijnt, duurt het antwoord van de server 2 milliseconden. As dat niet zo is, duurt dat antwoord twee keer zo lang: 4 milliseconden. Voor een mens is dat verschil niet merkbaar, maar voor geautomatiseerde enumeratie-tools is dat eenvoudig te zien.

De gevaren van een gebruikersnaam-enumeratie-aanval.

Een enumeratie-aanval stelt en hacker in staat om erachter te komen of een naam al in de database voorkomt. Hierdoor kan de hacker niet onmiddellijk inloggen, maar het geeft hem wel al de helft van de benodigde informatie. Voor het instellen van een brute-force-aanval, in plaats van het zoeken naar overeenkomende inlognamen en wachtwoorden, hebben ze bijvoorbeeld alleen een overeenkomend wachtwoord nodig voor een geverifieerde gebruikersnaam, wat tijd en moeite bespaart.

Onthoud ook dat bijna elke service e-mailadressen als gebruikersnamen accepteert. Dat betekent dat de gemiddelde gebruiker één inlognaam voor vele websites heeft, en niet al die sites nemen de beveiliging even serieus; nieuws over lekken van combinaties van inlognamen en wachtwoorden is helaas erg gebruikelijk. Samengevoegde dataverzamelingen van deze lekken zijn beschikbaar op hackersfora. Mensen gebruiken ook vaak dezelfde wachtwoorden op verschillende websites, dus als eenmaal is geverifieerd dat een gebruikersnaam op uw websites bestaat, kan een aanvaller met zo’n dataverzameling eenvoudig nagaan of de wachtwoorden voor dezelfde gebruiker ook op andere sites bestaan, en die vervolgens uitproberen.

Bovendien maken spear-phishing operators vaak gebruik van enumeratie-aanvallen tijdens de verkenningsfase. Na te hebben vastgesteld dat hun doelwit een account voor uw service heeft, kunnen ze een e-mail sturen die van u lijkt te komen. Hierin vragen ze de gebruiker om hun wachtwoord te wijzigen en linken ze hiervoor naar een phishing-pagina die op uw website lijkt. Als de argeloze klant een nieuw wachtwoord invoert, moeten ze ook het oude wachtwoord bevestigen, en ze verstrekken ze de scammers dus alle benodigde informatie.

Hoe u zich tegen een enumeratie-aanval beschermt

Hebt u ooit gemerkt hoe moderne websites op de inzending van een formulier voor het resetten van een wachtwoord reageren? Ze zeggen niet “Er is een link om uw wachtwoord te resetten naar u verzonden” of “Het opgegeven e-mailadres komt  niet in onze database voor”, zoals websites dat eerder deden. In plaats daarvan schrijven ze: “Als dit e-mailadres in onze database bestaat, sturen we u een bericht met een link.” In andere woorden: websites bevestigen of ontkennen niet expliciet of de gebruikersnaam ook daadwerkelijk bestaat. Deze wijziging is speciaal doorgevoerd ter bescherming tegen enumeratie-aanvallen.

Om diezelfde reden is het niet langer nodig dat u in het inlogvenster in detail uitlegt dat de gebruiker een incorrect wachtwoord heeft ingevuld of dat de gebruikersnaam niet in het systeem voorkomt. U zegt simpelweg dat de combinatie van de inlognaam en het wachtwoord niet is gevonden. Het is niet ideaal vanuit een UX-oogpunt. Ik erger me bijvoorbeeld dood als ik ben vergeten welk e-mailadres ik voor mijn registratie heb gebruikt terwijl ik zeker ben van het ingevoerde wachtwoord, of juist andersom. Maar de website biedt me vervolgens geen informatie over welke van de twee fout is. Maar veiligheid gaat bijna altijd ten koste van comfort, en in het geval van authenticatiediensten is een kleine opoffering voor de veiligheid wel gerechtvaardigd.

Natuurlijk is het gebruik van een captcha of beperkingen op het aantal inlogpogingen ook een must. Behalve deze maatregelen raden we voor de veiligheid van uw webapplicatie ook aan om een audit van derden te ondergaan. Als u in de blockchain-technologie zit, kunnen onze collega’s van Kaspersky Blockchain Security helpen met de veiligheidsanalyse van uw webapplicatie.