Wat is accountoogst?

Er zijn veel verschillende soorten datalekken. Sommige kosten enorme hoeveelheden tijd, planning en inspanning van de kant van de aanvaller. Dit kan de vorm aannemen van leren hoe een systeem werkt voordat een overtuigend phishingbericht wordt opgesteld en naar een medewerker wordt gestuurd die voldoende toegang heeft om de aanvaller in staat te stellen gevoelige details te stelen. Dit soort aanvallen kan resulteren in een enorme hoeveelheid verloren gegevens. Broncode en bedrijfsgegevens zijn gemeenschappelijke doelen. Andere doelen zijn gebruikersgegevens zoals gebruikersnamen, wachtwoorden, betalingsgegevens en PII zoals burgerservicenummers en telefoonnummers.

Sommige aanvallen zijn echter lang niet zo ingewikkeld. Toegegeven, ze hebben ook niet zo'n grote impact op alle getroffenen. Dat betekent echter niet dat ze geen probleem zijn. Een voorbeeld hiervan is account-harvesting of account-opsomming.

Rekening opsomming

Heeft u ooit geprobeerd u aan te melden bij een website om u te vertellen dat uw wachtwoord verkeerd was? Dat is nogal een specifieke foutmelding, nietwaar? Het is mogelijk dat als u dan met opzet een typefout maakt in uw gebruikersnaam of e-mailadres, de website u vertelt dat een "account met dat e-mailadres niet bestaat" of iets dergelijks. Zie je het verschil tussen die twee foutmeldingen? Websites die dit doen, zijn kwetsbaar voor accountopsomming of accountoogst. Simpel gezegd, door twee verschillende foutmeldingen te geven voor de twee verschillende scenario's, is het mogelijk om te bepalen of een gebruikersnaam of e-mailadres een geldig account bij de service heeft of niet.

Er zijn veel verschillende manieren waarop dit soort problemen kunnen worden geïdentificeerd. Het bovenstaande scenario van de twee verschillende foutmeldingen is redelijk zichtbaar. Het is ook eenvoudig op te lossen, geef gewoon een algemene foutmelding voor beide gevallen. Iets als "De gebruikersnaam of het wachtwoord dat je hebt ingevoerd was onjuist".

Andere manieren waarop accounts kunnen worden verzameld, zijn formulieren voor het opnieuw instellen van wachtwoorden. Het is handig om uw account te kunnen herstellen als u uw wachtwoord bent vergeten. Een slecht beveiligde website kan echter opnieuw twee verschillende berichten weergeven, afhankelijk van of de gebruikersnaam waarvoor u een wachtwoordreset probeerde te verzenden, bestaat. Stel je voor: "Account bestaat niet" en "Wachtwoord reset verzonden, controleer je e-mail". Ook in dit scenario is het mogelijk om te bepalen of een account bestaat door de reacties te vergelijken. De oplossing is ook hetzelfde. Geef een generiek antwoord, bijvoorbeeld: "Er is een e-mail voor het opnieuw instellen van het wachtwoord verzonden", zelfs als er geen e-mailaccount is om deze naar toe te sturen.

Subtiliteit bij het oogsten van rekeningen

Beide bovenstaande methoden zijn enigszins luid in termen van hun voetafdruk. Als een aanvaller een van beide aanvallen op grote schaal probeert uit te voeren, zal deze vrij gemakkelijk verschijnen in vrijwel elk logboeksysteem. De methode voor het opnieuw instellen van het wachtwoord stuurt ook expliciet een e-mail naar elk account dat daadwerkelijk bestaat. Luidruchtig zijn is niet het beste idee als je stiekem probeert te zijn.

Sommige websites staan ​​directe gebruikersinteractie of zichtbaarheid toe. In dit geval kunt u door simpelweg op de website te bladeren de schermnamen verzamelen van elk account dat u tegenkomt. De schermnaam kan vaak de gebruikersnaam zijn. In veel andere gevallen kan het een grote hint geven over welke gebruikersnamen moeten worden geraden, aangezien mensen vaak varianten van hun naam in hun e-mailadressen gebruiken. Dit type account-harvesting heeft interactie met de service, maar is in wezen niet te onderscheiden van standaardgebruik en is dus veel subtieler.

Een geweldige manier om subtiel te zijn, is door de website die wordt aangevallen nooit aan te raken. Als een aanvaller toegang probeert te krijgen tot een bedrijfswebsite die alleen toegankelijk is voor werknemers, is dat mogelijk ook mogelijk. In plaats van de site zelf te controleren op problemen met het opsommen van gebruikers, kunnen ze ergens anders heen gaan. Door sites als Facebook, Twitter en vooral LinkedIn te doorzoeken, kan het mogelijk zijn om een ​​behoorlijk goede lijst met werknemers van een bedrijf op te bouwen. Als de aanvaller vervolgens het e-mailformaat van het bedrijf kan bepalen, zoals [email protected], dan kunnen ze in feite een groot aantal accounts binnenhalen zonder ooit verbinding te maken met de website die ze met hen willen aanvallen.

Er kan weinig worden gedaan tegen een van deze technieken voor het verzamelen van accounts. Ze zijn minder betrouwbaar dan de eerste methoden, maar kunnen worden gebruikt om actievere methoden voor accountopsomming te informeren.

De duivel is in de details

Een generiek foutbericht is over het algemeen de oplossing om actieve accountopsomming te voorkomen. Soms zijn het echter de kleine details die de game verraden. Standaard geven webservers statuscodes bij het beantwoorden van verzoeken. 200 is de statuscode voor "OK", wat succes betekent, en 501 is een "interne serverfout". Een website zou een generiek bericht moeten hebben dat aangeeft dat er een wachtwoordreset is verzonden, zelfs als dit niet het geval was omdat er geen account was met de opgegeven gebruikersnaam of het opgegeven e-mailadres. In sommige gevallen verzendt de server echter nog steeds de 501-foutcode, zelfs als de website een succesvol bericht weergeeft. Voor een aanvaller die op de details let, is dit voldoende om te weten of het account echt bestaat of niet bestaat.

Als het om gebruikersnamen en wachtwoorden gaat, kan zelfs tijd een rol spelen. Een website moet uw wachtwoord opslaan, maar om te voorkomen dat het uitlekt in het geval dat ze worden gecompromitteerd of een malafide insider hebben, is de standaardpraktijk om het wachtwoord te hashen. Een cryptografische hash is een wiskundige functie in één richting die, als dezelfde invoer wordt gegeven, altijd dezelfde uitvoer geeft, maar als zelfs maar een enkel teken in de invoer verandert, verandert de hele uitvoer volledig. Door de uitvoer van de hash op te slaan, vervolgens het wachtwoord dat u opgeeft te hashen en de opgeslagen hash te vergelijken, is het mogelijk om te verifiëren dat u het juiste wachtwoord heeft opgegeven zonder ooit uw wachtwoord te kennen.

De details bij elkaar optellen

Goede hash-algoritmen hebben enige tijd nodig om te voltooien, doorgaans minder dan een tiende van een seconde. Dit is genoeg om brute kracht moeilijk te maken, maar niet zo lang om onhandelbaar te zijn als je er maar één bent om een ​​enkele waarde te controleren. het kan voor een website-engineer verleidelijk zijn om een ​​hoek om te gaan en niet de moeite te nemen om het wachtwoord te hashen als de gebruikersnaam niet bestaat. Ik bedoel, het heeft geen zin, want er is niets om het mee te vergelijken. Het probleem is tijd.

Webverzoeken krijgen meestal binnen enkele tientallen of zelfs honderd milliseconden een reactie. Als het wachtwoord-hashing-proces 100 milliseconden in beslag neemt en de ontwikkelaar het overslaat... kan dat merkbaar zijn. In dit geval zou een authenticatieverzoek voor een account dat niet bestaat binnen ongeveer 50 ms een reactie krijgen vanwege communicatielatentie. Een authenticatieverzoek voor een geldig account met een ongeldig wachtwoord kan ongeveer 150 ms duren, dit is inclusief de communicatielatentie en de 100 ms terwijl de server het wachtwoord hasht. Door simpelweg te controleren hoe lang het duurde voordat een reactie terugkwam, kan de aanvaller met redelijk betrouwbare nauwkeurigheid bepalen of een account bestaat of niet.

Op detail gerichte opsommingsmogelijkheden zoals deze twee kunnen net zo effectief zijn als de meer voor de hand liggende methoden om geldige gebruikersaccounts te verzamelen.

Effecten van het oogsten van rekeningen

Op het eerste gezicht lijkt het misschien niet zo'n groot probleem om te kunnen identificeren of een account al dan niet bestaat op een site. Het is niet zo dat de aanvaller toegang heeft gekregen tot het account of zoiets. De problemen zijn meestal wat breder van opzet. Gebruikersnamen zijn meestal e-mailadressen of pseudoniemen of gebaseerd op echte namen. Een echte naam kan gemakkelijk aan een persoon worden gekoppeld. Zowel e-mailadressen als pseudoniemen worden ook vaak hergebruikt door een enkele persoon, waardoor ze aan een specifieke persoon kunnen worden gekoppeld.

Dus stel je voor dat een aanvaller kan vaststellen dat je e-mailadres een account heeft op een website van een echtscheidingsadvocaat. Hoe zit het op een website over niche politieke voorkeuren, of specifieke gezondheidsproblemen. Dat soort dingen kan zelfs gevoelige informatie over u lekken. Informatie die u daar misschien niet wilt hebben.

Bovendien hergebruiken veel mensen nog steeds wachtwoorden op meerdere websites. Dit ondanks dat vrijwel iedereen op de hoogte is van het beveiligingsadvies om voor alles unieke wachtwoorden te gebruiken. Als uw e-mailadres betrokken is bij een groot datalek, is het mogelijk dat de hash van uw wachtwoord in dat lek zit. Als een aanvaller brute kracht kan gebruiken om uw wachtwoord uit dat datalek te raden, kunnen ze proberen het ergens anders te gebruiken. Op dat moment zou een aanvaller uw e-mailadres kennen en een wachtwoord dat u zou kunnen gebruiken. Als ze accounts kunnen opsommen op een site waarop u wel een account hebt, kunnen ze dat wachtwoord proberen. Als je dat wachtwoord op die site opnieuw hebt gebruikt, kan de aanvaller toegang krijgen tot je account. Daarom wordt aanbevolen om voor alles unieke wachtwoorden te gebruiken.

Conclusie

Accountoogst, ook wel accountopsomming genoemd, is een beveiligingsprobleem. Door een kwetsbaarheid voor accountopsomming kan een aanvaller bepalen of een account al dan niet bestaat. Als kwetsbaarheid voor het vrijgeven van informatie is het directe effect niet noodzakelijkerwijs ernstig. Het probleem is dat in combinatie met andere informatie de situatie nog veel erger kan worden. Dit kan ertoe leiden dat het bestaan ​​van gevoelige of privégegevens aan een bepaalde persoon kan worden gekoppeld. Het kan ook worden gebruikt in combinatie met datalekken van derden om toegang te krijgen tot accounts.

Er is ook geen legitieme reden voor een website om deze informatie te lekken. Als een gebruiker een fout maakt in zijn gebruikersnaam of wachtwoord, hoeven ze maar twee dingen te controleren om te zien waar ze de fout hebben gemaakt. Het risico dat wordt veroorzaakt door kwetsbaarheden in accountopsomming is veel groter dan het extreem kleine voordeel dat ze kunnen bieden aan een gebruiker die een typefout heeft gemaakt in de gebruikersnaam of het wachtwoord.