Tekniska detaljer om Capital One-hacket på AWS

Den 19 juli 2019 fick Capital One meddelandet som alla moderna företag fruktar: ett dataintrång. Det påverkade mer än 106 miljoner människor. 140 000 amerikanska personnummer, en miljon kanadensiska personnummer. 80 000 bankkonton. Det är obehagligt, håller du inte med?

Tyvärr inträffade inte hacket den 19 juli. Som det visar sig, Paige Thompson, aka Oregelbunden, begick det mellan 22 mars och 23 mars 2019. Det vill säga för nästan fyra månader sedan. Det var faktiskt bara genom externa konsulter som Capital One kunde ta reda på att något hade hänt.

Tidigare Amazon-anställd arresterad, riskerar böter på 250 XNUMX $, fem års fängelse... men mycket negativitet kvarstår. Varför? Eftersom många företag som har drabbats av intrång försöker undvika ansvaret att hårdna upp sin infrastruktur och sina applikationer inför den ökande cyberbrottsligheten.

Den här historien kan du i alla fall enkelt googla. Vi går inte in på dramatik, men vi ska prata om teknisk sidan av saken.

Först och främst, vad hände?

Capital One hade cirka 700 S3-skopor igång som Paige Thompson kopierade och hävertade.

För det andra, är detta ytterligare ett fall av felkonfigurerad S3-bucket-policy?

Nej, inte den här gången. Här fick hon tillgång till en server med en felaktigt konfigurerad brandvägg och genomförde hela operationen därifrån.

Vänta, hur är detta möjligt?

Tja, låt oss börja med att gå in på servern, även om vi har få detaljer. Vi fick bara veta att det hände genom en "felkonfigurerad brandvägg." Alltså, något så enkelt som felaktiga säkerhetsgruppinställningar eller konfiguration av webbapplikationsbrandvägg (Imperva) eller nätverksbrandvägg (iptables, ufw, shorewall, etc.). Capital One erkände bara sin skuld och sa att den hade täppt till hålet.

Stone sa att Capital One först inte märkte brandväggssårbarheten men reagerade snabbt när den fick reda på det. Det hjälpte verkligen att hackaren påstås lämnat nyckelidentifierande information allmänt tillgänglig, sa Stone.

Om du undrar varför vi inte går in på den här delen på djupet, vänligen förstå att vi på grund av begränsad information bara kan spekulera. Detta är ingen mening med tanke på att hacket förlitade sig på ett fel som lämnats av Capital One. Och om de inte berättar mer, kommer vi bara att lista alla möjliga sätt som Capital One lämnade sin server öppen på i kombination med alla möjliga sätt som någon skulle kunna använda ett av dessa olika alternativ. Dessa brister och metoder kan sträcka sig från galet dumma förbiseenden till otroligt komplexa mönster. Med tanke på mängden av möjligheter skulle detta förvandlas till en lång saga utan någon egentlig slutsats. Så låt oss fokusera på att analysera den del där vi har fakta.

Så den första slutsatsen är: vet vad dina brandväggar tillåter.

Upprätta en policy eller korrekt process för att säkerställa att ENDAST det som ska vara öppet är öppet. Om du använder AWS-resurser som säkerhetsgrupper eller nätverks-ACL kan uppenbarligen checklistan för granskning vara lång... men eftersom många resurser skapas automatiskt (d.v.s. CloudFormation), är det också möjligt att automatisera deras granskning. Oavsett om det är ett hembryggt skript som skannar nya objekt efter hål, eller något som en säkerhetsgranskning i CI/CD-processen... det finns många enkla alternativ för att undvika detta.

Den "roliga" delen av historien är att om Capital One hade täppt till hålet från början... skulle inget av detta ha hänt. Och så, ärligt talat, det är alltid chockerande att se hur något verkligen ganska enkelt blir den enda anledningen till att hacka ett företag. Speciellt en så stor som Capital One.

Så, hackaren är inne - vad hände sedan?

Tja, när du väl bryter dig in i en EC2-instans... kan mycket gå fel. Du går praktiskt taget på en knivsegg om du låter någon komma så långt. Men hur kom den in i S3-hinkarna? För att förstå detta, låt oss diskutera IAM-roller.

Så ett av sätten att få tillgång till AWS-tjänster är att vara en användare. Okej, det är ganska uppenbart. Men vad händer om du vill ge andra AWS-tjänster, såsom dina applikationsservrar, tillgång till dina S3-hinkar? Det är vad IAM-roller är till för. De består av två komponenter:

1. Trust Policy - vilka tjänster eller personer kan använda denna roll?
2. Behörighetspolicy – ​​Vad tillåter den här rollen?

Till exempel vill du skapa en IAM-roll som tillåter EC2-instanser att komma åt en S3-bucket: först ställs en Trust Policy in på rollen som EC2 (hela tjänsten) eller specifika instanser kan "ta över" rollen. Att acceptera en roll innebär att de kan använda rollens behörigheter för att utföra åtgärder. För det andra tillåter Behörighetspolicyn tjänsten/personen/resursen som har "tar på sig rollen" att göra något på S3, oavsett om det är att komma åt en specifik hink... eller över 700, som i fallet med Capital One.

När du väl är på en EC2-instans med en IAM-roll kan du få inloggningsuppgifter på några sätt:

1. Du kan begära instansmetadata på http://169.254.169.254/latest/meta-data

   Bland annat kan du hitta en IAM-roll med någon av åtkomstnycklarna på den här adressen. Naturligtvis bara om du är i en instans.

2. Använd AWS CLI...

   Om AWS CLI är installerad, startar den med referenser från IAM-roller, om sådana finns. Allt som återstår är att arbeta GENOM instansen. Naturligtvis, om deras Trust Policy var öppen, kunde Paige ha gjort allt direkt.

Så essensen av IAM-roller är att de tillåter en resurs att agera PÅ DIN räkning på ANDRA RESURSER.

Nu när du förstår IAM-rollerna kan vi prata om vad Paige Thompson gjorde:

1. Hon fick tillgång till servern (EC2-instans) genom ett hål i brandväggen.

   Oavsett om det var säkerhetsgrupper/ACL:er eller deras egna brandväggar för webbapplikationer, var hålet troligen ganska lätt att täppa till, som det står i den officiella dokumentationen.

2. Väl på servern kunde hon agera "som om" hon var servern själv.
3. Eftersom serverns IAM-roll tillät S3 åtkomst till dessa 700+ hinkar, kunde den komma åt dem.

Från det ögonblicket var allt hon behövde göra att köra kommandot. List Buckets, och sedan kommandot Sync från AWS CLI...

Capital One Bank uppskattar skada från hack till $100-$150 MILJONER. Att förhindra denna typ av skada är anledningen till att företag investerar så mycket i skydd av molninfrastruktur, DevOps och säkerhetsexperter. Och hur värdefull och kostnadseffektiv är övergången till molnet? Så mycket att även inför ständigt ökande cybersäkerhetsutmaningar Den totala marknaden för offentliga moln växte med 42 % under första kvartalet 2019!

Moralen i historien: kontrollera din säkerhet; Genomföra revisioner regelbundet; Respektera principen om minsta privilegium för säkerhetspolicyer.

(Här (Du kan se hela juridiska rapporten).

Källa: will.com