Vad är Account Harvesting?

Det finns många olika typer av dataintrång. Vissa involverar enorma mängder tid, planering och ansträngning från angriparens sida. Detta kan ta formen av att lära sig hur ett system fungerar innan man skapar ett övertygande nätfiskemeddelande och skickar det till en anställd som har tillräcklig tillgång för att tillåta angriparen att stjäla känsliga detaljer. Denna typ av attack kan resultera i en enorm mängd förlorad data. Källkod och företagsdata är vanliga mål. Andra mål inkluderar användardata som användarnamn, lösenord, betalningsuppgifter och PII som personnummer och telefonnummer.

Vissa attacker är dock inte i närheten av så komplicerade. De har visserligen inte heller så stor påverkan på alla som drabbas. Det betyder dock inte att de inte är ett problem. Ett exempel kallas kontoinsamling, eller kontouppräkning.

Kontouppräkning

Har du någonsin försökt logga in på en webbplats bara för att den ska berätta att ditt lösenord var fel? Det är snarare ett specifikt felmeddelande, eller hur? Det är möjligt att om du sedan avsiktligt gör ett stavfel i ditt användarnamn eller e-postadress så kommer webbplatsen att berätta att ett "konto med den e-postadressen inte existerar" eller något i den meningen. Ser du skillnaden mellan dessa två felmeddelanden? Webbplatser som gör detta är sårbara för kontouppräkning eller kontoinsamling. Enkelt uttryckt, genom att tillhandahålla två olika felmeddelanden för de två olika scenarierna, är det möjligt att avgöra om ett användarnamn eller e-postadress har ett giltigt konto hos tjänsten eller inte.

Det finns många olika sätt att identifiera den här typen av problem. Ovanstående scenario med de två olika felmeddelandena är ganska synligt. Det är också lätt att fixa, ange bara ett allmänt felmeddelande för båda fallen. Något som "Användarnamnet eller lösenordet du angav var felaktigt".

Andra sätt som konton kan skördas på inkluderar formulär för återställning av lösenord. Att kunna återställa ditt konto om du glömmer ditt lösenord är praktiskt. En dåligt säkrad webbplats kan dock återigen ge två olika meddelanden beroende på om användarnamnet du försökte skicka en lösenordsåterställning för existerar. Föreställ dig: "Kontot finns inte" och "Lösenordsåterställning har skickats, kolla din e-post". Återigen i det här scenariot är det möjligt att avgöra om ett konto existerar genom att jämföra svaren. Lösningen är densamma också. Ge ett allmänt svar, något i stil med: "Ett lösenordsåterställningsmeddelande har skickats" även om det inte finns något e-postkonto att skicka det till.

Subtilitet i kontoskörd

Båda ovanstående metoder är något högljudda när det gäller deras fotavtryck. Om en angripare försöker utföra någon av attackerna i stor skala, kommer det att dyka upp ganska enkelt i i princip alla loggsystem. Lösenordsåterställningsmetoden skickar också uttryckligen ett e-postmeddelande till alla konton som faktiskt existerar. Att vara högljudd är inte den bästa idén om du försöker vara lömsk.

Vissa webbplatser tillåter direkt användarinteraktion eller synlighet. I det här fallet, helt enkelt genom att surfa på webbplatsen, kan du samla skärmnamnen för varje konto du stöter på. Skärmnamnet kan ofta vara användarnamnet. I många andra fall kan det ge en stor ledtråd om vilka användarnamn man ska gissa eftersom folk ofta använder varianter av sina namn i sina e-postadresser. Denna typ av kontoinsamling interagerar med tjänsten men är i princip omöjlig att skilja från standardanvändning, och är därför mycket mer subtil.

Ett bra sätt att vara subtil är att aldrig röra webbplatsen under attack alls. Om en angripare försökte få åtkomst till en företagswebbplats som endast är avsedd för anställda, kanske de kan göra just det. Istället för att kolla på själva webbplatsen efter problem med användaruppräkningar kan de gå någon annanstans. Genom att tråla sajter som Facebook, Twitter och särskilt LinkedIn kan det vara möjligt att bygga upp en ganska bra lista över anställda i ett företag. Om angriparen sedan kan bestämma företagets e-postformat, såsom fö[email protected], kan de i själva verket skörda ett stort antal konton utan att någonsin ansluta till webbplatsen de planerar att attackera med dem.

Lite kan göras mot någon av dessa kontoskördningstekniker. De är mindre tillförlitliga än de första metoderna men kan användas för att informera mer aktiva metoder för kontouppräkning.

Djävulen är i detaljerna

Ett allmänt felmeddelande är vanligtvis lösningen för att förhindra aktiv kontouppräkning. Ibland är det dock de små detaljerna som ger bort spelet. Enligt standarder tillhandahåller webbservrar statuskoder när de svarar på förfrågningar. 200 är statuskoden för "OK" som betyder framgång och 501 är ett "internt serverfel". En webbplats bör ha ett allmänt meddelande som indikerar att en lösenordsåterställning har skickats, även om det faktiskt inte var för att det inte fanns något konto med det angivna användarnamnet eller e-postadressen. I vissa fall kommer servern fortfarande att skicka felkoden 501, även om webbplatsen visar ett lyckat meddelande. För en angripare som uppmärksammar detaljerna är detta tillräckligt för att tala om att kontot verkligen finns eller inte existerar.

När det kommer till användarnamn och lösenord kan till och med tid spela en faktor. En webbplats måste lagra ditt lösenord, men för att undvika att det läcker i händelse av att de äventyras, eller har en falsk insider, är standardpraxis att hasha lösenordet. En kryptografisk hash är en envägs matematisk funktion som om samma inmatning ges alltid ger samma utdata, men om även ett enda tecken i inmatningen ändras så ändras hela utdatan helt. Genom att lagra utdata från hashen, sedan hasha lösenordet du skickar in och jämföra den lagrade hashen är det möjligt att verifiera att du har skickat in rätt lösenord utan att någonsin veta ditt lösenord.

Att sätta ihop detaljerna

Bra hashalgoritmer tar lite tid att slutföra, vanligtvis mindre än en tiondels sekund. Detta är tillräckligt för att göra det svårt att brute force men inte så länge för att vara svårhanterlig när du bara en att kontrollera ett enda värde. det kan vara frestande för en webbplatsingenjör att skära ett hörn och inte bry sig om att hasha lösenordet om användarnamnet inte finns. Jag menar, det finns ingen egentlig mening eftersom det inte finns något att jämföra med. Problemet är tiden.

Webbförfrågningar ser vanligtvis ett svar inom några tiotals eller till och med hundra eller så millisekunder. Om hashprocessen för lösenord tar 100 millisekunder att slutföra och utvecklaren hoppar över den... kan det märkas. I det här fallet skulle en autentiseringsbegäran för ett konto som inte existerar få ett svar på ungefär 50 ms på grund av kommunikationslasen. En autentiseringsbegäran för ett giltigt konto med ett ogiltigt lösenord kan ta ungefär 150 ms, detta inkluderar kommunikationslatens såväl som 100 ms medan servern hashar lösenordet. Genom att helt enkelt kontrollera hur lång tid det tog för ett svar att komma tillbaka kan angriparen avgöra med ganska tillförlitlig noggrannhet om ett konto finns eller inte.

Detaljorienterade uppräkningsmöjligheter som dessa två kan vara lika effektiva som de mer uppenbara metoderna för att samla in giltiga användarkonton.

Effekter av kontoinsamling

På det första kan det inte verka som ett alltför stort problem att kunna identifiera om ett konto finns eller inte finns på en webbplats. Det är inte som att angriparen kunde få tillgång till kontot eller något. Problemen tenderar att vara lite bredare i omfattning. Användarnamn tenderar att vara antingen e-postadresser eller pseudonymer eller baserade på riktiga namn. Ett riktigt namn kan lätt knytas till en individ. Både e-postadresser och pseudonymer tenderar också att återanvändas av en enda individ vilket gör att de kan knytas till en specifik person.

Så tänk dig om en angripare kan fastställa att din e-postadress har ett konto på en webbplats för skilsmässaadvokater. Vad sägs om på en webbplats om nischade politiska tillhörigheter, eller specifika hälsotillstånd. Sådant kan faktiskt läcka känslig information om dig. Information som du kanske inte vill ha där ute.

Dessutom återanvänder många fortfarande lösenord på flera webbplatser. Detta trots att i stort sett alla är medvetna om säkerhetsråden att använda unika lösenord för allt. Om din e-postadress är inblandad i ett stort dataintrång, är det möjligt att hashen av ditt lösenord kan inkluderas i det intrånget. Om en angripare kan använda brute force för att gissa ditt lösenord från det dataintrånget, kan de försöka använda det någon annanstans. Vid den tidpunkten skulle en angripare känna till din e-postadress och ett lösenord som du kan använda. Om de kan räkna upp konton på en webbplats som du har ett konto på kan de försöka med det lösenordet. Om du har återanvänt det lösenordet på den webbplatsen kan angriparen komma in på ditt konto. Det är därför det rekommenderas att använda unika lösenord för allt.

Slutsats

Kontoinsamling, även kallad kontouppräkning, är en säkerhetsfråga. En sårbarhet för kontouppräkning gör att en angripare kan avgöra om ett konto finns eller inte. Som en sårbarhet för informationsröjande är dess direkta effekt inte nödvändigtvis allvarlig. Problemet är att i kombination med annan information kan situationen bli mycket värre. Detta kan resultera i att förekomsten av känsliga eller privata uppgifter kan knytas till en specifik person. Det kan också användas i kombination med dataintrång från tredje part för att få tillgång till konton.

Det finns heller ingen legitim anledning för en webbplats att läcka denna information. Om en användare gör ett misstag i antingen sitt användarnamn eller lösenord, behöver de bara kontrollera två saker för att se var de gjorde felet. Risken som orsakas av sårbarheter i kontouppräkning är mycket större än den extremt ringa fördel de kan ge en användare som gjort ett stavfel i användarnamnet eller lösenordet.


Hur man klona en hårddisk

Hur man klona en hårddisk

I den moderna digitala tidsåldern, där data är en värdefull tillgång, kan kloning av en hårddisk på Windows vara en avgörande process för många. Denna omfattande guide

Hur fixar jag drivrutinen WUDFRd kunde inte laddas på Windows 10?

Hur fixar jag drivrutinen WUDFRd kunde inte laddas på Windows 10?

Står du inför felmeddelandet när du startar din dator som säger att drivrutinen WUDFRd inte kunde laddas på din dator?

Så här åtgärdar du NVIDIA GeForce Experience Error Code 0x0003

Så här åtgärdar du NVIDIA GeForce Experience Error Code 0x0003

Upplever du NVIDIA GeForce-felkod 0x0003 på ditt skrivbord? Om ja, läs bloggen för att hitta hur du åtgärdar det här felet snabbt och enkelt.

Vad är SMPS?

Vad är SMPS?

Lär dig vad som är SMPS och innebörden av olika effektivitetsklasser innan du väljer en SMPS för din dator.

Varför slås inte min Chromebook på

Varför slås inte min Chromebook på

Få svar på frågan Varför slås inte min Chromebook på? I den här användbara guiden för Chromebook-användare.

Hur man rapporterar nätfiskebedrägerier till Google

Hur man rapporterar nätfiskebedrägerier till Google

Lär dig hur du rapporterar en bedragare till Google för att hindra dem från att lura andra med den här guiden.

Roomba stannar, sticker och vänder sig om – fixa

Roomba stannar, sticker och vänder sig om – fixa

Åtgärda ett problem där din Roomba robotdammsugare stannar, fastnar och fortsätter att vända sig om.

Hur man ändrar grafikinställningar på Steam Deck

Hur man ändrar grafikinställningar på Steam Deck

Steam Deck erbjuder en robust och mångsidig spelupplevelse precis vid dina fingertoppar. Dock för att optimera ditt spelande och säkerställa bästa möjliga

Vad är isoleringsbaserad säkerhet?

Vad är isoleringsbaserad säkerhet?

Vi skulle fördjupa oss i ett ämne som blir allt viktigare i världen av cybersäkerhet: isoleringsbaserad säkerhet. Detta förhållningssätt till

Hur man använder Auto Clicker för Chromebook

Hur man använder Auto Clicker för Chromebook

Idag skulle jag fördjupa dig i ett verktyg som kan automatisera repetitiva klickuppgifter på din Chromebook: Auto Clicker. Detta verktyg kan spara tid och