Hoe u account harvesting begrijpt

Omgaan met datalekken is een beetje als cybersecurity-mollengevecht. Sommige lekken zijn groot en vergen veel planning, het leren van de ins en outs van een systeem en het opstellen van behoorlijk overtuigende phishingberichten. Die kunnen leiden tot ernstige datalekken – denk aan broncode, gevoelige bedrijfsbestanden of gebruikersgegevens zoals wachtwoorden en burgerservicenummers. Maar niet elk datalek is zo ingewikkeld of schadelijk. Soms gaat het slechts om kleine beveiligingslekken, zoals account harvesting of account enumeratie. Dit klinkt misschien wat ingewikkeld, maar het is in feite de manier waarop hackers stiekem achterhalen welke gebruikersnamen of e-mailadressen bij echte accounts horen, zonder alarmbellen te laten rinkelen.

Hoe account-enumeratie werkt

Als je ooit hebt geprobeerd in te loggen op een site en hebt gemerkt dat er een andere melding verschijnt wanneer je wachtwoord onjuist is dan wanneer je e-mailadres of gebruikersnaam niet bestaat, dan is dat een klassiek teken van accountopsomming. Als de site “Onjuist wachtwoord” aangeeft terwijl de gebruikersnaam correct is, maar “Account bestaat niet” in andere gevallen, geeft dat hackers een duidelijk overzicht van geldige accounts. Waarom is dat slecht? Omdat ze zo zonder veel moeite echte gebruikersgegevens kunnen achterhalen. In sommige gevallen is dit overduidelijk: gewoon een andere foutmelding, en kunnen ze een vrij nauwkeurige lijst met actieve gebruikers samenstellen.

Dit oplossen is echter geen hogere wiskunde. Je hoeft alleen maar een algemene foutmelding te tonen zoals “De gebruikersnaam of het wachtwoord dat je hebt ingevoerd, is onjuist”, ongeacht of het account bestaat of niet. Klinkt eenvoudig, maar het is een makkelijke stap om dit soort informatielekken minder opvallend te maken.

Ga sluipend te werk met accountverzameling

Oké, maar dat is slechts de luidruchtige versie. Als een aanvaller stiekem probeert te blijven, kan hij dat op subtielere manieren doen. In plaats van alleen op foutmeldingen te vertrouwen, kan hij op de site rondkijken, gebruikersprofielen bekijken of zelfs openbare informatie van LinkedIn, Facebook of Twitter gebruiken. Door gebruikersnamen of e-mailpatronen te verzamelen, kan hij in principe een lijst met potentiële doelwitaccounts genereren zonder ooit de inlogformulieren rechtstreeks aan te vallen. Omdat dit geen foutmeldingen genereert, is het veel moeilijker om het in logs te vinden.

Iets anders wat hackers soms doen, is de naamgevingsconventies van e-mails van bedrijven identificeren, zoals [email protected]. Door e-mailformaten te raden, kunnen ze een heleboel geloofwaardige accounts verzamelen zonder ooit rechtstreeks het aanvalsoppervlak te raken. Een beetje vreemd, maar het maakt de aanval stiller – veel subtieler dan brute-force inlogpogingen of massale aanmeldingen.

Details die het spel verraden

Soms zijn het de kleine details die aangeven of er account harvesting plaatsvindt. Webservers bieden statuscodes aan, zoals 200 OKof 501 Internal Server Error, die, als ze niet zorgvuldig worden gebruikt, informatie kunnen lekken. Als uw wachtwoordherstelpagina bijvoorbeeld “E-mail voor wachtwoordherstel verzonden” toont, zelfs als de e-mail niet in de database staat, maar de server toch een 501-foutcode geeft, kan een aanvaller die het netwerkverkeer controleert, vaststellen of het account wel of niet bestaat. Windows en webhostingstacks moeten natuurlijk *irritant* nauwkeurig zijn met hun antwoorden.

En als het hashen van wachtwoorden niet goed wordt gedaan, is dat nog een manier waarop aanvallers kunnen achterhalen of het account bestaat op basis van de responstijd. Als je server 100 ms nodig heeft om een ​​wachtwoord te hashen voor een geldig account, maar direct reageert wanneer het account niet bestaat, kunnen ze de tijd meten en afleiden of het account echt of nep is. Ik weet niet zeker waarom het werkt, maar in sommige configuraties maakt het een merkbaar verschil. Timingaanvallen bestaan ​​dus.

Alle puzzelstukjes op hun plaats leggen

Wat is de belangrijkste les? Beveiliging draait om veel kleine details. Ervoor zorgen dat foutmeldingen altijd generiek zijn, HTTP-statuscodes correct worden verwerkt en er nooit tijdsverschillen in reacties worden onthuld, kan een groot verschil maken. Want hackers zijn natuurlijk dol op deze kleine gaatjes in het pantser: ze zijn gemakkelijk te misbruiken en kunnen leiden tot grotere inbreuken of gewoon een leuke, kleine verzameling informatie.

In de ene configuratie werkte het, in de andere…minder goed. Maar als je met gevoelige gegevens werkt, is het de moeite waard om je inlog- en wachtwoordherstelflows nogmaals te controleren op dit soort subtiele lekken. Soms kan het vasthouden aan consistente antwoorden je op termijn veel hoofdpijn besparen.

Waarom dit belangrijk is

Het lekken van informatie over het bestaan ​​van een account lijkt misschien onschuldig, maar het kan behoorlijk gevoelige informatie lekken. Stel je voor dat iemand erachter komt dat je e-mailadres geregistreerd staat op een site over gezondheidsproblemen of politieke opvattingen – dat is nogal gênant, toch? Bovendien worden deze hergebruikte gebruikersnamen en wachtwoorden gekoppeld aan echte mensen, waardoor toekomstige inbreuken gemakkelijker worden. Als iemand je e-mailadres en wachtwoord bemachtigt via een inbreuk elders, kan hij die combinatie ook op andere sites proberen – dus wachtwoorden hergebruiken? Niet zo handig.

Al deze kleine lekken en timingtrucs lijken op zichzelf misschien niet zo’n groot probleem, maar hackers zijn slim. Ze kunnen genoeg informatie verzamelen om wachtwoorden te raden, persoonlijke gegevens te identificeren of grotere aanvallen te plannen.

Afronding

Accountenumeratie is een sluwe kleine kwetsbaarheid die kwaadwillenden kan helpen achterhalen of je ergens een account hebt. Het is niet hetzelfde als het account zelf hacken, maar het is een tussenstap die later kan worden uitgebuit. Het goede nieuws? Het is meestal vrij eenvoudig te verhelpen: door foutmeldingen consistent te maken, op te letten op informatielekken in reacties en timingverschillen te minimaliseren. Want natuurlijk geldt: hoe minder ze weten, hoe beter.

Hopelijk bespaart dit iemand een hoop hoofdpijn: deze kleine details zijn belangrijker dan je zou denken.