Den 19 juli 2019 fick Capital One meddelandet som alla moderna företag fruktar – ett dataintrång inträffade. Det påverkade mer än 106 miljoner människor. 140 000 amerikanska personnummer, en miljon kanadensiska personnummer. 80 000 bankkonton. Otrevligt, håller du inte med?
Tyvärr inträffade inte hacket den 19 juli. Det visar sig att Paige Thompson, a.k.a. Oregelbunden, begick det mellan 22 mars och 23 mars 2019. Det är för nästan fyra månader sedan. Det var faktiskt bara med hjälp av externa konsulter som Capital One kunde upptäcka att något hade hänt.
En före detta Amazon-anställd greps och riskerar böter på 250 XNUMX dollar och fem års fängelse... men det finns fortfarande mycket negativitet kvar. Varför? Eftersom många företag som har drabbats av hacks försöker dra från sig ansvaret för att stärka sin infrastruktur och applikationer mitt i den ökande cyberbrottsligheten.
Hur som helst kan du enkelt googla den här historien. Vi ska inte gå in på drama, utan 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 sugde av.
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 det möjligt?
Nåväl, låt oss börja med att logga in på servern, även om vi inte har många 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 webbapplikationens brandvä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 agerade snabbt när den blev medveten om den. Detta var verkligen hjälpt av det faktum att hackaren påstås lämnat nyckelidentifierande information i det offentliga området, sa Stone.
Om du undrar varför vi inte går djupare in på den här delen, vänligen förstå att vi på grund av begränsad information bara kan spekulera. Detta är ingen mening med tanke på att hacket berodde på ett hål efter 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 tekniker kan sträcka sig från galet dumma förbiseenden till otroligt komplexa mönster. Med tanke på mängden av möjligheter kommer detta att bli en lång saga utan någon egentlig slutsats. Låt oss därför fokusera på att analysera den del där vi har fakta.
Så den första takeaway ä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 behöver öppnas öppnas. Om du använder AWS-resurser som säkerhetsgrupper eller nätverks-ACL kan uppenbarligen checklistan för granskning vara lång... men precis som många resurser skapas automatiskt (d.v.s. CloudFormation), är det också möjligt att automatisera deras granskning. Oavsett om det är ett hemgjort skript som skannar nya objekt efter brister, eller något som en säkerhetsgranskning i en CI/CD-process... 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 i första hand... skulle ingenting 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 ett företag hackas. Speciellt en så stor som Capital One.
Så, hacker inuti - vad hände sedan?
Tja, efter att ha brutit sig in i en EC2-instans... kan mycket gå fel. Du går praktiskt taget på en knivsegg om du låter någon gå så långt. Men hur hamnade den i S3-hinkar? För att förstå detta, låt oss diskutera IAM-roller.
Så ett sätt att komma åt AWS-tjänster är att vara en användare. Okej, den här är ganska uppenbar. 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:
- Trust Policy – vilka tjänster eller personer kan använda denna roll?
- Behörighetspolicy – vad tillåter den här rollen?
Till exempel vill du skapa en IAM-roll som ger EC2-instanser tillgång till en S3-bucket: För det första är rollen inställd på att ha en Trust Policy 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 "tagit rollen" att göra vad som helst på S3, oavsett om det är åtkomst till en specifik hink... eller över 700, som i fallet med Capital One.
När du väl är i en EC2-instans med IAM-rollen kan du få inloggningsuppgifter på flera sätt:
- Du kan begära instansmetadata på
http://169.254.169.254/latest/meta-dataBland annat kan du hitta IAM-rollen med någon av åtkomstnycklarna på den här adressen. Naturligtvis bara om du är i en instans.
- Använd AWS CLI...
Om AWS CLI är installerad laddas den med referenser från IAM-rollerna, om sådana finns. Allt som återstår är att arbeta GENOM instansen. Naturligtvis, om deras Trust Policy var öppen, kunde Paige göra allt direkt.
Så essensen av IAM-roller är att de tillåter vissa resurser att agera PÅ DINA VÄNNER på ANDRA RESURSER.
Nu när du förstår IAM:s roller kan vi prata om vad Paige Thompson gjorde:
- 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 webbapplikationsbrandväggar var hålet förmodligen ganska lätt att täppa till, som det står i de officiella dokumenten.
- Väl på servern kunde hon agera "som om" hon var servern själv
- Eftersom IAM-serverrollen 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 Bucketsoch sedan kommandot Sync från AWS CLI...
. Att förhindra sådana skador är anledningen till att företag investerar så mycket i skydd av molninfrastruktur, DevOps och säkerhetsexperter. Och hur värdefullt och kostnadseffektivt är det att flytta till molnet? Så mycket att även inför fler och fler cybersäkerhetsutmaningar !
Moralen i historien: kontrollera din säkerhet; Genomföra regelbundna revisioner; Respektera principen om minsta privilegium för säkerhetspolicyer.
( Du kan se hela juridiska rapporten).
Källa: will.com