Den 19. juli 2019 modtog Capital One den besked, som enhver moderne virksomhed frygter - et databrud opstod. Det berørte mere end 106 millioner mennesker. 140 amerikanske cpr-numre, en million canadiske cpr-numre. 000 bankkonti. Ubehageligt, er du ikke enig?
Desværre fandt hacket ikke sted den 19. juli. Det viser sig, at Paige Thompson, a.k.a. Erratic, begået det mellem 22. marts og 23. marts 2019. Det er næsten fire måneder siden. Faktisk var det kun ved hjælp af eksterne konsulenter, at Capital One kunne opdage, at der var sket noget.
En tidligere Amazon-medarbejder blev arresteret og risikerer en bøde på 250 dollars og fem års fængsel... men der er stadig meget negativitet tilbage. Hvorfor? Fordi mange virksomheder, der har lidt af hacks, forsøger at fralægge sig ansvaret for at styrke deres infrastruktur og applikationer midt i stigningen i cyberkriminalitet.
Du kan i hvert fald nemt google denne historie. Vi vil ikke gå ind i drama, men tale om teknisk side af sagen.
Først og fremmest, hvad skete der?
Capital One havde omkring 700 S3-spande kørende, som Paige Thompson kopierede og sugede af.
For det andet, er dette endnu et tilfælde af forkert konfigureret S3-bucket-politik?
Nej, ikke denne gang. Her fik hun adgang til en server med en forkert konfigureret firewall og udførte hele operationen derfra.
Vent, hvordan er det muligt?
Nå, lad os starte med at logge ind på serveren, selvom vi ikke har mange detaljer. Vi fik kun at vide, at det skete gennem en "fejlkonfigureret firewall." Altså noget så simpelt som forkerte sikkerhedsgruppeindstillinger eller konfiguration af webapplikationens firewall (Imperva) eller netværksfirewall (iptables, ufw, shorewall osv.). Capital One indrømmede kun sin skyld og sagde, at den havde lukket hullet.
Stone sagde, at Capital One i første omgang ikke bemærkede firewall-sårbarheden, men handlede hurtigt, når den blev opmærksom på det. Dette blev bestemt hjulpet af det faktum, at hackeren angiveligt efterlod vigtige identificerende oplysninger i det offentlige domæne, sagde Stone.
Hvis du undrer dig over, hvorfor vi ikke går dybere ind i denne del, bedes du forstå, at vi på grund af begrænset information kun kan spekulere. Dette giver ingen mening, da hacket afhang af et hul efterladt af Capital One. Og medmindre de fortæller os mere, vil vi bare liste alle de mulige måder, hvorpå Capital One forlod deres server åben i kombination med alle de mulige måder, nogen kunne bruge en af disse forskellige muligheder. Disse fejl og teknikker kan variere fra vildt dumme forglemmelser til utroligt komplekse mønstre. I betragtning af de mange muligheder, vil dette blive en lang saga uden nogen egentlig konklusion. Lad os derfor fokusere på at analysere den del, hvor vi har fakta.
Så den første takeaway er: ved, hvad dine firewalls tillader.
Etabler en politik eller en ordentlig proces for at sikre, at KUN det, der skal åbnes, åbnes. Hvis du bruger AWS-ressourcer som sikkerhedsgrupper eller netværks-ACL'er, kan tjeklisten til revision naturligvis være lang... men ligesom mange ressourcer oprettes automatisk (dvs. CloudFormation), er det også muligt at automatisere deres revision. Uanset om det er et hjemmelavet script, der scanner nye objekter for fejl, eller noget som en sikkerhedsrevision i en CI/CD-proces... der er mange nemme muligheder for at undgå dette.
Den "sjove" del af historien er, at hvis Capital One havde lukket hullet i første omgang... ville der ikke være sket noget. Og så ærligt talt er det altid chokerende at se, hvordan noget virkeligt ret simpelt bliver den eneste grund til, at en virksomhed bliver hacket. Især en så stor som Capital One.
Så, hacker indeni - hvad skete der derefter?
Nå, efter at have brudt ind i en EC2-instans... kan meget gå galt. Du går nærmest på en knivsæg, hvis du lader nogen gå så langt. Men hvordan kom det ind i S3 spande? For at forstå dette, lad os diskutere IAM-roller.
Så en måde at få adgang til AWS-tjenester på er at være bruger. Okay, denne er ret indlysende. Men hvad nu hvis du vil give andre AWS-tjenester, såsom dine applikationsservere, adgang til dine S3-bøtter? Det er, hvad IAM-roller er til for. De består af to komponenter:
- Tillidspolitik - hvilke tjenester eller personer kan bruge denne rolle?
- Tilladelsespolitik – hvad tillader denne rolle?
For eksempel vil du oprette en IAM-rolle, der giver EC2-instanser adgang til en S3-bucket: For det første er rollen indstillet til at have en Trust Policy, som EC2 (hele tjenesten) eller specifikke instanser kan "overtage" rollen. At acceptere en rolle betyder, at de kan bruge rollens tilladelser til at udføre handlinger. For det andet tillader tilladelsespolitikken tjenesten/personen/ressourcen, der har "taget rollen", at gøre hvad som helst på S3, uanset om det er at få adgang til en bestemt bucket... eller over 700, som i tilfældet med Capital One.
Når du først er i en EC2-instans med IAM-rollen, kan du få legitimationsoplysninger på flere måder:
- Du kan anmode om instansmetadata på
http://169.254.169.254/latest/meta-dataDu kan blandt andet finde IAM-rollen med en hvilken som helst af adgangsnøglerne på denne adresse. Selvfølgelig kun hvis du er i en instans.
- Brug AWS CLI...
Hvis AWS CLI er installeret, indlæses det med legitimationsoplysninger fra IAM-rollerne, hvis de er til stede. Det eneste, der er tilbage, er at arbejde GENNEMGÅ instansen. Selvfølgelig, hvis deres tillidspolitik var åben, kunne Paige gøre alt direkte.
Så essensen af IAM-roller er, at de tillader nogle ressourcer at handle PÅ DINE VEGNE på ANDRE RESSOURCER.
Nu hvor du forstår IAM's roller, kan vi tale om, hvad Paige Thompson gjorde:
- Hun fik adgang til serveren (EC2-instans) gennem et hul i firewallen
Uanset om det var sikkerhedsgrupper/ACL'er eller deres egne webapplikations-firewalls, var hullet nok ret nemt at plugge, som det står i de officielle optegnelser.
- Når hun først var på serveren, var hun i stand til at opføre sig "som om" hun selv var serveren
- Da IAM-serverrollen tillod S3 adgang til disse 700+ buckets, var den i stand til at få adgang til dem
Fra det øjeblik af var alt, hvad hun skulle gøre, at køre kommandoen List Bucketsog derefter kommandoen Sync fra AWS CLI...
. Forebyggelse af sådanne skader er grunden til, at virksomheder investerer så meget i beskyttelse af skyinfrastruktur, DevOps og sikkerhedseksperter. Og hvor værdifuldt og omkostningseffektivt er det at flytte til skyen? Så meget, at selv i lyset af flere og flere cybersikkerhedsudfordringer !
Moralen i historien: Tjek din sikkerhed; Udføre regelmæssige revisioner; Respekter princippet om mindste privilegium for sikkerhedspolitikker.
( Du kan se den fulde juridiske rapport).
Kilde: www.habr.com