19. juli 2019 mottok Capital One meldingen som ethvert moderne selskap frykter – et datainnbrudd skjedde. Det berørte mer enn 106 millioner mennesker. 140 000 amerikanske personnummer, én million kanadiske personnummer. 80 000 bankkontoer. Ubehagelig, er du ikke enig?
Dessverre skjedde ikke hacket 19. juli. Det viser seg at Paige Thompson, a.k.a. uberegnelig, begått det mellom 22. mars og 23. mars 2019. Det er for nesten fire måneder siden. Faktisk var det kun ved hjelp av eksterne konsulenter at Capital One kunne oppdage at noe hadde skjedd.
En tidligere Amazon-ansatt ble arrestert og risikerer en bot på 250 XNUMX dollar og fem års fengsel... men det er fortsatt mye negativitet igjen. Hvorfor? Fordi mange selskaper som har lidd av hacks prøver å trekke fra seg ansvaret for å styrke infrastrukturen og applikasjonene sine midt i økningen i nettkriminalitet.
Uansett, du kan enkelt google denne historien. Vi skal ikke gå inn i drama, men snakke om teknisk siden av saken.
Først av alt, hva skjedde?
Capital One hadde rundt 700 S3-bøtter i gang, som Paige Thompson kopierte og sugde av.
For det andre, er dette enda et tilfelle av feilkonfigurert S3-bøttepolicy?
Nei ikke denne gangen. Her fikk hun tilgang til en server med feilkonfigurert brannmur og utførte hele operasjonen derfra.
Vent, hvordan er det mulig?
Vel, la oss starte med å logge på serveren, selv om vi ikke har mange detaljer. Vi ble bare fortalt at det skjedde gjennom en "feilkonfigurert brannmur." Så, noe så enkelt som feil sikkerhetsgruppeinnstillinger eller konfigurasjon av nettapplikasjonens brannmur (Imperva), eller nettverksbrannmur (iptables, ufw, shorewall, etc.). Capital One innrømmet bare sin skyld og sa at den hadde tettet hullet.
Stone sa at Capital One i utgangspunktet ikke la merke til brannmursårbarheten, men handlet raskt når den ble klar over det. Dette ble absolutt hjulpet av det faktum at hackeren angivelig etterlot nøkkelidentifikasjonsinformasjon i det offentlige domene, sa Stone.
Hvis du lurer på hvorfor vi ikke går dypere inn i denne delen, vennligst forstå at på grunn av begrenset informasjon kan vi bare spekulere. Dette gir ingen mening gitt at hacket var avhengig av et hull etterlatt av Capital One. Og med mindre de forteller oss mer, vil vi bare liste opp alle mulige måter Capital One forlot serveren sin åpen i kombinasjon med alle mulige måter noen kan bruke en av disse forskjellige alternativene på. Disse feilene og teknikkene kan variere fra vilt dumme forglemmelser til utrolig komplekse mønstre. Gitt utvalget av muligheter, vil dette bli en lang saga uten noen reell konklusjon. La oss derfor fokusere på å analysere den delen hvor vi har fakta.
Så den første takeawayen er: vet hva brannmurene dine tillater.
Etabler en policy eller riktig prosess for å sikre at KUN det som må åpnes åpnes. Hvis du bruker AWS-ressurser som Security Groups eller Network ACLs, kan selvsagt sjekklisten for å revidere være lang... men akkurat som mange ressurser opprettes automatisk (dvs. CloudFormation), er det også mulig å automatisere revisjonen deres. Enten det er et hjemmelaget skript som skanner nye objekter for feil, eller noe sånt som en sikkerhetsrevisjon i en CI/CD-prosess... det er mange enkle alternativer for å unngå dette.
Den "morsomme" delen av historien er at hvis Capital One hadde tettet hullet i utgangspunktet... ville ingenting ha skjedd. Og så, ærlig talt, er det alltid sjokkerende å se hvordan noe egentlig er ganske enkelt blir den eneste grunnen til at et selskap blir hacket. Spesielt en så stor som Capital One.
Så, hacker på innsiden - hva skjedde videre?
Vel, etter å ha brutt seg inn i en EC2-instans... kan mye gå galt. Du går praktisk talt på en knivsegg hvis du lar noen gå så langt. Men hvordan kom den inn i S3-bøtter? For å forstå dette, la oss diskutere IAM-roller.
Så en måte å få tilgang til AWS-tjenester på er å være bruker. Ok, denne er ganske åpenbar. Men hva om du vil gi andre AWS-tjenester, for eksempel applikasjonsserverne, tilgang til S3-bøttene dine? Det er det IAM-roller er til for. De består av to komponenter:
- Trust Policy – hvilke tjenester eller personer kan bruke denne rollen?
- Tillatelsespolicy – hva tillater denne rollen?
For eksempel vil du opprette en IAM-rolle som vil tillate EC2-instanser å få tilgang til en S3-bøtte: Først er rollen satt til å ha en Trust Policy som EC2 (hele tjenesten) eller spesifikke instanser kan "ta over" rollen. Å godta en rolle betyr at de kan bruke rollens tillatelser til å utføre handlinger. For det andre tillater tillatelsespolicyen tjenesten/personen/ressursen som har "tatt rollen" å gjøre hva som helst på S3, enten det er tilgang til én spesifikk bøtte... eller over 700, som i tilfellet med Capital One.
Når du er i en EC2-instans med IAM-rollen, kan du få legitimasjon på flere måter:
- Du kan be om instansmetadata på
http://169.254.169.254/latest/meta-dataDu kan blant annet finne IAM-rollen med hvilken som helst av tilgangsnøklene på denne adressen. Selvfølgelig bare hvis du er i en instans.
- Bruk AWS CLI...
Hvis AWS CLI er installert, er den lastet med legitimasjon fra IAM-rollene, hvis de er til stede. Alt som gjenstår er å jobbe GJENNOM instansen. Selvfølgelig, hvis tillitspolitikken deres var åpen, kunne Paige gjøre alt direkte.
Så essensen av IAM-roller er at de lar noen ressurser handle PÅ DINE VEGNE på ANDRE RESSURSER.
Nå som du forstår rollene til IAM, kan vi snakke om hva Paige Thompson gjorde:
- Hun fikk tilgang til serveren (EC2-forekomst) gjennom et hull i brannmuren
Enten det var sikkerhetsgrupper/ACL-er eller deres egne nettapplikasjonsbrannmurer, var nok hullet ganske enkelt å plugge, som det står i de offisielle journalene.
- Når hun først var på serveren, var hun i stand til å oppføre seg "som om" hun var serveren selv
- Siden IAM-serverrollen tillot S3 tilgang til disse 700+ bøttene, kunne den få tilgang til dem
Fra det øyeblikket av var alt hun måtte gjøre å kjøre kommandoen List Bucketsog deretter kommandoen Sync fra AWS CLI...
. Å forhindre slik skade er grunnen til at selskaper investerer så mye i beskyttelse av skyinfrastruktur, DevOps og sikkerhetseksperter. Og hvor verdifullt og kostnadseffektivt er det å flytte til skyen? Så mye at selv i møte med flere og flere cybersikkerhetsutfordringer !
Moralen i historien: sjekk sikkerheten din; Gjennomføre regelmessige revisjoner; Respekter prinsippet om minste privilegium for sikkerhetspolitikk.
( Du kan se hele den juridiske rapporten).
Kilde: www.habr.com