Hva er kontohøsting?

Det finnes mange forskjellige typer datainnbrudd. Noen involverer enorme mengder tid, planlegging og innsats fra angriperens side. Dette kan ta form av å lære hvordan et system fungerer før du lager en overbevisende phishing-melding og sender den til en ansatt som har nok tilgang til at angriperen kan stjele sensitive detaljer. Denne typen angrep kan resultere i en enorm mengde tapte data. Kildekode og bedriftsdata er vanlige mål. Andre mål inkluderer brukerdata som brukernavn, passord, betalingsdetaljer og PII som personnummer og telefonnumre.

Noen angrep er imidlertid ikke i nærheten av så kompliserte. Riktignok har de heller ikke så stor innvirkning på alle som rammes. Det betyr ikke at de ikke er et problem. Ett eksempel kalles kontohøsting, eller kontooppregning.

Kontooppregning

Har du noen gang prøvd å logge på et nettsted bare for å fortelle deg at passordet ditt var feil? Det er heller en spesifikk feilmelding, er det ikke? Det er mulig at hvis du med vilje gjør en skrivefeil i brukernavnet eller e-postadressen din, vil nettstedet fortelle deg at en "konto med den e-posten ikke eksisterer" eller noe i den retning. Ser du forskjellen mellom disse to feilmeldingene? Nettsteder som gjør dette er sårbare for kontooppregning eller kontoinnsamling. Enkelt sagt, ved å gi to forskjellige feilmeldinger for de to forskjellige scenariene, er det mulig å finne ut om et brukernavn eller en e-postadresse har en gyldig konto hos tjenesten eller ikke.

Det er mange forskjellige måter denne typen problemer kan identifiseres på. Scenariet ovenfor med de to forskjellige feilmeldingene er ganske synlig. Det er også enkelt å fikse, bare oppgi en generisk feilmelding for begge tilfeller. Noe sånt som "Brukernavnet eller passordet du skrev inn var feil".

Andre måter kontoer kan høstes på inkluderer skjemaer for tilbakestilling av passord. Det er nyttig å kunne gjenopprette kontoen din hvis du glemmer passordet. Et dårlig sikret nettsted kan imidlertid igjen gi to forskjellige meldinger avhengig av om brukernavnet du prøvde å sende en tilbakestilling av passord for eksisterer. Tenk deg: "Konto finnes ikke" og "Tilbakestilling av passord sendt, sjekk e-posten din". Igjen i dette scenariet er det mulig å finne ut om en konto eksisterer ved å sammenligne svarene. Løsningen er også den samme. Gi et generisk svar, noe sånt som: "En e-post for tilbakestilling av passord er sendt" selv om det ikke er noen e-postkonto å sende den til.

Subtilitet i kontohøsting

Begge metodene ovenfor er noe høylytte når det gjelder fotavtrykket. Hvis en angriper prøver å utføre et av angrepene i stor skala, vil det dukke opp ganske enkelt i stort sett alle loggsystemer. Metoden for tilbakestilling av passord sender også eksplisitt en e-post til enhver konto som faktisk eksisterer. Å være høy er ikke den beste ideen hvis du prøver å være lur.

Noen nettsteder tillater direkte brukerinteraksjon eller synlighet. I dette tilfellet, ganske enkelt ved å surfe på nettstedet, kan du samle skjermnavnene til hver konto du kjører over. Skjermnavnet kan ofte være brukernavnet. I mange andre tilfeller kan det gi et stort hint om hvilke brukernavn å gjette, da folk ofte bruker varianter av navnene sine i e-postadressene sine. Denne typen kontoinnsamling samhandler med tjenesten, men kan i hovedsak ikke skilles fra standardbruk, og er derfor mye mer subtil.

En fin måte å være subtil på er å aldri berøre nettstedet som er under angrep i det hele tatt. Hvis en angriper prøvde å få tilgang til et bedriftsnettsted som kun er for ansatte, kan de kanskje gjøre akkurat det. I stedet for å sjekke selve nettstedet for brukeroppregningsproblemer, kan de gå andre steder. Ved å tråle nettsteder som Facebook, Twitter og spesielt LinkedIn kan det være mulig å bygge opp en ganske god liste over ansatte i et selskap. Hvis angriperen deretter kan bestemme selskapets e-postformat, for eksempel [email protected], kan de faktisk høste et stort antall kontoer uten noen gang å koble seg til nettstedet de planlegger å angripe med dem.

Lite kan gjøres mot noen av disse kontohøstingsteknikkene. De er mindre pålitelige enn de første metodene, men kan brukes til å informere mer aktive metoder for kontooppregning.

Djevelen er i detaljene

En generisk feilmelding er vanligvis løsningen for å forhindre aktiv kontooppregning. Noen ganger er det imidlertid de små detaljene som gir spillet bort. Etter standarder gir webservere statuskoder når de svarer på forespørsler. 200 er statuskoden for "OK" som betyr suksess, og 501 er en "intern serverfeil". Et nettsted bør ha en generisk melding som indikerer at en tilbakestilling av passord ble sendt, selv om det faktisk ikke var fordi det ikke var noen konto med det oppgitte brukernavnet eller e-postadressen. I noen tilfeller vil serveren fortsatt sende feilkoden 501, selv om nettstedet viser en vellykket melding. For en angriper som legger merke til detaljene, er dette nok til å fortelle at kontoen virkelig eksisterer eller ikke eksisterer.

Når det kommer til brukernavn og passord kan selv tid spille en faktor. Et nettsted må lagre passordet ditt, men for å unngå å lekke det i tilfelle de blir kompromittert, eller har en useriøs innsidemann, er standard praksis å hash passordet. En kryptografisk hash er en enveis matematisk funksjon som, hvis gitt samme input, alltid gir samme utgang, men hvis selv et enkelt tegn i input endres, endres hele utgangen fullstendig. Ved å lagre utdataene fra hashen, deretter hashe passordet du sender inn og sammenligne den lagrede hashen, er det mulig å bekrefte at du har sendt inn riktig passord uten å vite passordet ditt.

Å sette sammen detaljene

Gode ​​hashing-algoritmer tar litt tid å fullføre, vanligvis mindre enn en tidel av et sekund. Dette er nok til å gjøre det vanskelig å brute force, men ikke så lenge til å være uhåndterlig når du bare én til å sjekke en enkelt verdi. det kan være fristende for en nettstedsingeniør å kutte et hjørne og ikke bry seg med å hash passordet hvis brukernavnet ikke eksisterer. Jeg mener, det er ikke noe poeng siden det ikke er noe å sammenligne det med. Problemet er tid.

Nettforespørsler ser vanligvis et svar i løpet av noen få titalls eller til og med hundre eller så millisekunder. Hvis passordhashing-prosessen tar 100 millisekunder å fullføre og utvikleren hopper over den... kan det merkes. I dette tilfellet vil en autentiseringsforespørsel for en konto som ikke eksisterer få et svar på omtrent 50 ms på grunn av kommunikasjonsforsinkelse. En autentiseringsforespørsel for en gyldig konto med et ugyldig passord kan ta omtrent 150 ms, dette inkluderer kommunikasjonsforsinkelsen så vel som 100 ms mens serveren hasheser passordet. Ved ganske enkelt å sjekke hvor lang tid det tok før et svar kom tilbake, kan angriperen fastslå med ganske pålitelig nøyaktighet om en konto eksisterer eller ikke.

Detaljorienterte oppregningsmuligheter som disse to kan være like effektive som de mer åpenbare metodene for å høste gyldige brukerkontoer.

Effekter av kontohøsting

Umiddelbart kan det ikke virke som et for stort problem å kunne identifisere om en konto eksisterer eller ikke eksisterer på et nettsted. Det er ikke slik at angriperen var i stand til å få tilgang til kontoen eller noe. Problemene har en tendens til å være litt bredere i omfang. Brukernavn pleier å være enten e-postadresser eller pseudonymer eller basert på ekte navn. Et ekte navn kan lett knyttes til en person. Både e-postadresser og pseudonymer har også en tendens til å bli gjenbrukt av en enkelt person, slik at de kan knyttes til en bestemt person.

Så, tenk om en angriper kan fastslå at e-postadressen din har en konto på et nettsted for skilsmisseadvokater. Hva med på en nettside om nisjepolitiske tilknytninger, eller spesifikke helsetilstander. Den slags kan faktisk lekke sensitiv informasjon om deg. Informasjon som du kanskje ikke vil ha der ute.

Videre gjenbruker mange fortsatt passord på tvers av flere nettsteder. Dette til tross for at stort sett alle er klar over sikkerhetsrådene om å bruke unike passord til alt. Hvis e-postadressen din er involvert i et stort datainnbrudd, er det mulig at hashen til passordet ditt kan være inkludert i bruddet. Hvis en angriper er i stand til å bruke brute force for å gjette passordet ditt fra det databruddet, kan de prøve å bruke det andre steder. På det tidspunktet ville en angriper vite e-postadressen din og et passord du kan bruke. Hvis de kan telle opp kontoer på et nettsted du har en konto på, kan de prøve det passordet. Hvis du har gjenbrukt passordet på det nettstedet, kan angriperen komme inn på kontoen din. Dette er grunnen til at det anbefales å bruke unike passord for alt.

Konklusjon

Kontoinnsamling, også referert til som kontooppregning, er et sikkerhetsproblem. Et sikkerhetsproblem med kontooppregning lar en angriper finne ut om en konto eksisterer eller ikke. Som en sårbarhet for informasjonsavsløring er dens direkte virkning ikke nødvendigvis alvorlig. Problemet er at kombinert med annen informasjon kan situasjonen bli mye verre. Dette kan føre til at eksistensen av sensitive eller private detaljer kan knyttes til en bestemt person. Den kan også brukes i kombinasjon med tredjeparts datainnbrudd for å få tilgang til kontoer.

Det er heller ingen legitim grunn for et nettsted til å lekke denne informasjonen. Hvis en bruker gjør en feil i enten brukernavnet eller passordet, trenger de bare å sjekke to ting for å se hvor de har gjort feilen. Risikoen forårsaket av sårbarheter ved kontooppregning er mye større enn den ekstremt små fordelen de kan gi en bruker som har skrevet feil i brukernavnet eller passordet.