Hvad er Account Harvesting?

Der er mange forskellige typer af databrud. Nogle involverer enorme mængder tid, planlægning og indsats fra angriberens side. Dette kan tage form af at lære, hvordan et system fungerer, før du laver en overbevisende phishing-besked og sender den til en medarbejder, der har tilstrækkelig adgang til at tillade angriberen at stjæle følsomme detaljer. Denne form for angreb kan resultere i en enorm mængde tabte data. Kildekode og virksomhedsdata er almindelige mål. Andre mål inkluderer brugerdata såsom brugernavne, adgangskoder, betalingsoplysninger og PII såsom cpr-numre og telefonnumre.

Nogle angreb er dog ikke i nærheden af ​​så komplicerede. De har ganske vist heller ikke så stor betydning for alle, der er ramt. Det betyder dog ikke, at de ikke er et problem. Et eksempel kaldes kontoindsamling eller kontooptælling.

Kontoopregning

Har du nogensinde prøvet at logge ind på et websted kun for at fortælle dig, at din adgangskode var forkert? Det er snarere en specifik fejlmeddelelse, er det ikke? Det er muligt, at hvis du så bevidst laver en tastefejl i dit brugernavn eller din e-mailadresse, vil hjemmesiden fortælle dig, at en "konto med den e-mail ikke eksisterer" eller noget i den retning. Kan du se forskellen mellem de to fejlmeddelelser? Websteder, der gør dette, er sårbare over for kontooptælling eller kontoindsamling. Kort sagt, ved at give to forskellige fejlmeddelelser for de to forskellige scenarier, er det muligt at afgøre, om et brugernavn eller en e-mailadresse har en gyldig konto hos tjenesten eller ej.

Der er mange forskellige måder, hvorpå denne slags problemer kan identificeres. Ovenstående scenarie med de to forskellige fejlmeddelelser er ret synligt. Det er også nemt at rette, du skal blot give en generisk fejlmeddelelse for begge tilfælde. Noget som "Det brugernavn eller den adgangskode, du indtastede, var forkert".

Andre måder, hvorpå konti kan høstes, omfatter formularer til nulstilling af adgangskode. Det er praktisk at kunne gendanne din konto, hvis du glemmer din adgangskode. Et dårligt sikret websted kan dog igen give to forskellige beskeder afhængigt af, om det brugernavn, du forsøgte at sende en nulstilling af adgangskode til, eksisterer. Forestil dig: "Konto eksisterer ikke" og "Nulstilling af adgangskode sendt, tjek din e-mail". Igen i dette scenarie er det muligt at afgøre, om der findes en konto ved at sammenligne svarene. Løsningen er også den samme. Angiv et generisk svar, noget som: "En e-mail til nulstilling af adgangskode er blevet sendt", selvom der ikke er nogen e-mail-konto at sende den til.

Subtilitet i kontohøstning

Begge de ovennævnte metoder er noget højlydte med hensyn til deres fodaftryk. Hvis en angriber forsøger at udføre et af angrebene i skala, vil det dukke op ganske let i stort set ethvert logningssystem. Metoden til nulstilling af adgangskode sender også eksplicit en e-mail til enhver konto, der rent faktisk eksisterer. At være højlydt er ikke den bedste idé, hvis du prøver at være lusket.

Nogle websteder tillader direkte brugerinteraktion eller synlighed. I dette tilfælde kan du blot ved at browse på webstedet samle skærmnavnene på hver konto, du støder på. Skærmnavnet kan ofte være brugernavnet. I mange andre tilfælde kan det give et stort hint om, hvilke brugernavne de skal gætte, da folk almindeligvis bruger variationer af deres navne i deres e-mail-adresser. Denne type kontoindsamling interagerer med tjenesten, men kan i det væsentlige ikke skelnes fra standardbrug, og er derfor meget mere subtil.

En god måde at være subtil på er aldrig at røre ved webstedet, der er under angreb overhovedet. Hvis en angriber forsøgte at få adgang til et virksomhedswebsted, der kun var for medarbejdere, kunne de muligvis gøre præcis det. I stedet for at tjekke selve webstedet for problemer med brugeropregning, kan de gå andre steder hen. Ved at trawle sider som Facebook, Twitter og især LinkedIn kan det være muligt at opbygge en ret god liste over medarbejdere i en virksomhed. Hvis angriberen derefter kan bestemme virksomhedens e-mail-format, såsom [email protected], så kan de faktisk høste et stort antal konti uden nogensinde at oprette forbindelse til det websted, de planlægger at angribe med dem.

Der kan ikke gøres meget imod nogen af ​​disse kontohøstteknikker. De er mindre pålidelige end de første metoder, men kan bruges til at informere mere aktive metoder til kontooptælling.

Djævelen er i detaljerne

En generisk fejlmeddelelse er generelt løsningen til at forhindre aktiv kontoopregning. Nogle gange er det dog de små detaljer, der giver spillet væk. Som standard leverer webservere statuskoder, når de besvarer anmodninger. 200 er statuskoden for "OK", hvilket betyder succes, og 501 er en "intern serverfejl". Et websted skal have en generisk meddelelse, der angiver, at en nulstilling af adgangskode blev sendt, selvom det faktisk ikke var, fordi der ikke var nogen konto med det angivne brugernavn eller e-mailadresse. I nogle tilfælde vil serveren stadig sende fejlkoden 501, selvom webstedet viser en vellykket meddelelse. For en angriber, der er opmærksom på detaljerne, er dette nok til at fortælle, at kontoen virkelig eksisterer eller ikke eksisterer.

Når det kommer til brugernavne og adgangskoder, kan selv tid spille en faktor. En hjemmeside skal gemme din adgangskode, men for at undgå at lække den i tilfælde af, at den bliver kompromitteret, eller har en slyngel insider, er standardpraksis at hash adgangskoden. En kryptografisk hash er en envejs matematisk funktion, som hvis den samme input altid giver det samme output, men hvis selv et enkelt tegn i input ændres, ændres hele outputtet fuldstændigt. Ved at gemme outputtet af hashen, derefter hashe den adgangskode, du indsender, og sammenligne den gemte hash, er det muligt at verificere, at du har indsendt den korrekte adgangskode uden nogensinde at kende din adgangskode.

At sætte detaljerne sammen

Gode ​​hashing-algoritmer tager noget tid at fuldføre, typisk mindre end en tiendedel af et sekund. Dette er nok til at gøre det svært at brute force, men ikke så længe at være uhåndterlig, når du kun én til at kontrollere en enkelt værdi. det kan være fristende for en webstedsingeniør at skære et hjørne og ikke gider at hash kodeordet, hvis brugernavnet ikke eksisterer. Jeg mener, der er ingen reel mening, da der ikke er noget at sammenligne det med. Problemet er tiden.

Webanmodninger ser typisk et svar inden for et par tiere eller endda hundrede eller deromkring millisekunder. Hvis hash-processen med adgangskode tager 100 millisekunder at fuldføre, og udvikleren springer den over... kan det være mærkbart. I dette tilfælde vil en godkendelsesanmodning for en konto, der ikke eksisterer, få et svar på ca. 50 ms på grund af kommunikationsforsinkelse. En godkendelsesanmodning for en gyldig konto med en ugyldig adgangskode kan tage omkring 150 ms, dette inkluderer kommunikationsforsinkelsen såvel som de 100 ms, mens serveren hashes adgangskoden. Ved blot at kontrollere, hvor lang tid det tog for et svar at komme tilbage, kan angriberen med nogenlunde pålidelig nøjagtighed afgøre, om en konto eksisterer eller ej.

Detaljeorienterede opregningsmuligheder som disse to kan være lige så effektive som de mere oplagte metoder til at høste gyldige brugerkonti.

Effekter af kontohøst

Umiddelbart virker det måske ikke som et for stort problem at kunne identificere, om en konto eksisterer eller ikke findes på et websted. Det er ikke sådan, at angriberen var i stand til at få adgang til kontoen eller noget. Problemerne har en tendens til at være lidt bredere. Brugernavne plejer at være enten e-mailadresser eller pseudonymer eller baseret på rigtige navne. Et rigtigt navn kan nemt knyttes til en person. Både e-mailadresser og pseudonymer har også en tendens til at blive genbrugt af en enkelt person, så de kan bindes til en bestemt person.

Så forestil dig, hvis en angriber kan fastslå, at din e-mail-adresse har en konto på en skilsmisseadvokats hjemmeside. Hvad med på en hjemmeside om nichepolitiske tilhørsforhold eller specifikke helbredsforhold. Den slags kunne faktisk lække nogle følsomme oplysninger om dig. Information, som du måske ikke vil have derude.

Desuden genbruger mange mennesker stadig adgangskoder på tværs af flere websteder. Dette på trods af, at stort set alle er klar over sikkerhedsrådet om at bruge unikke adgangskoder til alt. Hvis din e-mailadresse er involveret i et stort databrud, er det muligt, at hashen af ​​din adgangskode kan være inkluderet i dette brud. Hvis en angriber er i stand til at bruge brute force til at gætte din adgangskode ud fra det databrud, kan de prøve at bruge det andre steder. På det tidspunkt ville en hacker kende din e-mail-adresse og en adgangskode, som du muligvis bruger. Hvis de kan opregne konti på et websted, som du har en konto på, kan de prøve den adgangskode. Hvis du har genbrugt adgangskoden på det pågældende websted, kan angriberen komme ind på din konto. Det er derfor, det anbefales at bruge unikke adgangskoder til alt.

Konklusion

Kontoindsamling, også kaldet kontooptælling, er et sikkerhedsproblem. En kontooptællingssårbarhed giver en hacker mulighed for at afgøre, om en konto eksisterer eller ej. Som en sårbarhed i offentliggørelse af oplysninger er dens direkte virkning ikke nødvendigvis alvorlig. Problemet er, at når det kombineres med anden information, kan situationen blive meget værre. Dette kan resultere i, at eksistensen af ​​følsomme eller private detaljer kan knyttes til en bestemt person. Det kan også bruges i kombination med tredjeparts databrud for at få adgang til konti.

Der er heller ingen legitim grund til at et websted lække disse oplysninger. Hvis en bruger laver en fejl i enten deres brugernavn eller adgangskode, skal de kun tjekke to ting for at se, hvor de lavede fejlen. Risikoen forårsaget af sårbarheder ved kontooptælling er meget større end den ekstremt lille fordel, de kan give en bruger, der har lavet en tastefejl i brugernavnet eller adgangskoden.