Capital One sai 19. heinäkuuta 2019 viestin, jonka jokainen moderni yritys pelkää – tapahtui tietomurto. Se vaikutti yli 106 miljoonaan ihmiseen. 140 000 Yhdysvaltain sosiaaliturvatunnusta, miljoona Kanadan sosiaaliturvatunnusta. 80 000 pankkitiliä. Epämiellyttävää, etkö ole samaa mieltä?
Valitettavasti hakkerointi ei tapahtunut heinäkuun 19. päivänä. Kuten käy ilmi, Paige Thompson, a.k.a. arvaamaton, teki sen 22.–23. maaliskuuta 2019. Tuo on melkein neljä kuukautta sitten. Itse asiassa vain ulkopuolisten konsulttien avulla Capital One sai selville, että jotain oli tapahtunut.
Entinen Amazonin työntekijä pidätettiin, ja häntä uhkaa 250 XNUMX dollarin sakko ja viisi vuotta vankeutta... mutta negatiivista on vielä paljon jäljellä. Miksi? Koska monet hakkeroista kärsineet yritykset yrittävät sivuuttaa vastuuta infrastruktuurinsa ja sovellustensa vahvistamisesta kyberrikollisuuden lisääntyessä.
Joka tapauksessa, voit helposti googlettaa tämän tarinan. Emme mene draamaan, vaan puhumme siitä tekninen asian puoli.
Ensinnäkin mitä tapahtui?
Capital Onella oli käynnissä noin 700 S3-ämpäriä, jotka Paige Thompson kopioi ja sifonoi pois.
Toiseksi, onko tämä toinen väärin määritetyn S3-säilökäytännön tapaus?
Ei, ei tällä kertaa. Täällä hän pääsi palvelimelle, jonka palomuuri oli määritetty väärin, ja suoritti koko toiminnon sieltä.
Odota, miten se on mahdollista?
No, aloitetaan kirjautumalla palvelimelle, vaikka meillä ei ole paljon yksityiskohtia. Meille kerrottiin vain, että se tapahtui "väärin määritetyn palomuurin" kautta. Joten jotain niinkin yksinkertaista kuin virheelliset suojausryhmäasetukset tai verkkosovelluksen palomuuri (Imperva) tai verkon palomuuri (iptables, ufw, shorewall jne.) määritykset. Capital One myönsi vain syyllisyytensä ja sanoi sulkeneensa reiän.
Stone sanoi, että Capital One ei aluksi huomannut palomuurin haavoittuvuutta, mutta toimi nopeasti saatuaan sen tietoon. Tätä auttoi varmasti se, että hakkerin väitetään jättäneen avaimet tunnistetiedot julkisuuteen, Stone sanoi.
Jos mietit, miksi emme mene syvemmälle tähän osaan, ymmärrä, että rajoitetun tiedon vuoksi voimme vain spekuloida. Tässä ei ole järkeä, koska hakkerointi riippui Capital Onen jättämästä reiästä. Ja elleivät he kerro meille enempää, luettelemme vain kaikki mahdolliset tavat, joilla Capital One jätti palvelimensa auki, sekä kaikki mahdolliset tavat, joilla joku voisi käyttää jotakin näistä eri vaihtoehdoista. Nämä puutteet ja tekniikat voivat vaihdella hurjan typeristä laiminlyönneistä uskomattoman monimutkaisiin kuvioihin. Mahdollisuuksien kirjo huomioon ottaen tästä tulee pitkä saaga ilman varsinaista johtopäätöstä. Keskitytään siis sen osan analysointiin, jossa meillä on tosiasiat.
Joten ensimmäinen huomio on: tiedä, mitä palomuurisi sallivat.
Luo käytäntö tai asianmukainen prosessi varmistaaksesi, että VAIN avattava avataan. Jos käytät AWS-resursseja, kuten suojausryhmiä tai verkon ACL-luetteloita, tarkastuksen tarkistuslista voi tietysti olla pitkä... mutta kuten monet resurssit luodaan automaattisesti (eli CloudFormation), on myös mahdollista automatisoida niiden valvonta. Olipa kyseessä kotitekoinen skripti, joka tarkistaa uusista objekteista vikoja, tai jotain, kuten tietoturvatarkastus CI/CD-prosessissa... tämän välttämiseksi on monia helppoja vaihtoehtoja.
Tarinan "hauska" osa on, että jos Capital One olisi tukkinut reiän alun perin... mitään ei olisi tapahtunut. Ja niin, suoraan sanottuna, on aina järkyttävää nähdä, miten jotain todella aika yksinkertaista tulee ainoa syy yrityksen hakkerointiin. Varsinkin yhtä iso kuin Capital One.
Joten hakkeri sisällä - mitä tapahtui seuraavaksi?
No, murtauduttuaan EC2-instanssiin... paljon voi mennä pieleen. Kävelet käytännössä veitsen terällä, jos annat jonkun mennä niin pitkälle. Mutta miten se pääsi S3-ämpäriin? Tämän ymmärtämiseksi keskustelemme IAM-rooleista.
Joten yksi tapa päästä AWS-palveluihin on olla käyttäjä. Okei, tämä on aika ilmeinen. Mutta entä jos haluat antaa muille AWS-palveluille, kuten sovelluspalvelimillesi pääsyn S3-sämpeihisi? Sitä varten IAM-roolit ovat. Ne koostuvat kahdesta osasta:
- Luottamuspolitiikka – mitkä palvelut tai ihmiset voivat käyttää tätä roolia?
- Käyttöoikeuskäytäntö – mitä tämä rooli sallii?
Haluat esimerkiksi luoda IAM-roolin, jonka avulla EC2-esiintymät voivat käyttää S3-säilöä: Ensinnäkin roolille on asetettu luottamuskäytäntö, jonka mukaan EC2 (koko palvelu) tai tietyt ilmentymät voivat "ottaa" roolin haltuunsa. Roolin hyväksyminen tarkoittaa, että he voivat käyttää roolin oikeuksia toimien suorittamiseen. Toiseksi, käyttöoikeuskäytäntö sallii palvelun/henkilön/resurssin, joka on "ottanut roolin", tehdä mitä tahansa S3:ssa, olipa kyseessä sitten yhden tietyn ryhmän käyttö... tai yli 700, kuten Capital Onen tapauksessa.
Kun olet EC2-esiintymässä IAM-roolilla, voit hankkia valtuustiedot useilla tavoilla:
- Voit pyytää esiintymän metatietoja osoitteessa
http://169.254.169.254/latest/meta-dataLöydät muun muassa IAM-roolin millä tahansa pääsyavaimella tästä osoitteesta. Tietenkin vain, jos olet tapauksessa.
- Käytä AWS CLI:tä...
Jos AWS CLI on asennettu, se ladataan IAM-rooleilla, jos sellaisia on. Jäljelle jää vain työskennellä instanssin KAUTTA. Tietysti, jos heidän luottamuspolitiikkansa olisi avoin, Paige voisi tehdä kaiken suoraan.
Joten IAM-roolien olemus on, että ne antavat joidenkin resurssien toimia SINUUN PUOLESTASI MUISTEN RESURSSIEN suhteen.
Nyt kun ymmärrät IAM:n roolit, voimme puhua siitä, mitä Paige Thompson teki:
- Hän pääsi palvelimeen (EC2-instanssi) palomuurin reiän kautta
Olipa kyseessä tietoturvaryhmät/ACL:t tai heidän omat verkkosovellusten palomuurit, aukko oli luultavasti melko helppo sulkea, kuten virallisissa tiedoissa todetaan.
- Palvelimelle päästyään hän pystyi toimimaan "ikään kuin" hän olisi itse palvelin
- Koska IAM-palvelimen rooli salli S3:n pääsyn näihin yli 700 ryhmään, se pystyi käyttämään niitä
Siitä hetkestä lähtien hänen täytyi vain suorittaa komento List Bucketsja sitten komento Sync AWS CLI:stä...
. Tällaisten vahinkojen estäminen on syy, miksi yritykset investoivat niin paljon pilviinfrastruktuurin suojaukseen, DevOpsiin ja tietoturvaasiantuntijoihin. Ja kuinka arvokasta ja kustannustehokasta on pilveen siirtyminen? Niin paljon, että jopa yhä useampien kyberturvallisuushaasteiden edessä !
Tarinan moraali: tarkista turvallisuutesi; Suorita säännöllisiä tarkastuksia; Noudata turvallisuuspolitiikan vähiten etuoikeuksien periaatetta.
( Voit tarkastella koko lakiraporttia).
Lähde: will.com