Technické detaily hacku Capital One na AWS

Technické detaily hacku Capital One na AWS

Dňa 19. júla 2019 spoločnosť Capital One dostala správu, ktorej sa každá moderná spoločnosť obáva – došlo k porušeniu údajov. Postihol viac ako 106 miliónov ľudí. 140 000 amerických čísel sociálneho zabezpečenia, jeden milión kanadských čísel sociálneho zabezpečenia. 80 000 bankových účtov. Nepríjemné, nesúhlasíš?

Žiaľ, hacknutie nenastalo 19. júla. Ako sa ukázalo, Paige Thompson, a.k.a. Kolísavé, sa ho dopustil v dňoch 22 až 23. Teda takmer pred štyrmi mesiacmi. V skutočnosti sa Capital One podarilo zistiť, že sa niečo stalo, len s pomocou externých konzultantov.

Bývalý zamestnanec Amazonu bol zatknutý a hrozí mu pokuta 250 XNUMX dolárov a päť rokov väzenia... ale stále tu zostalo veľa negativity. prečo? Pretože mnohé spoločnosti, ktoré trpeli hackermi, sa snažia zbaviť zodpovednosti za posilnenie svojej infraštruktúry a aplikácií uprostred nárastu počítačovej kriminality.

Každopádne si tento príbeh ľahko vygooglite. Nebudeme zachádzať do drámy, ale hovoriť o tom technický strane veci.

Po prvé, čo sa stalo?

V Capital One bežalo asi 700 vedier S3, ktoré Paige Thompson skopírovala a odčerpala.

Po druhé, je to ďalší prípad nesprávne nakonfigurovanej politiky segmentu S3?

Nie, tentoraz nie. Tu získala prístup na server s nesprávne nakonfigurovaným firewallom a celú operáciu vykonala odtiaľ.

Počkať, ako je to možné?

No, začnime prihlásením sa na server, aj keď nemáme veľa podrobností. Bolo nám povedané len to, že sa to stalo cez „zle nakonfigurovaný firewall“. Teda niečo také jednoduché ako nesprávne nastavenie bezpečnostnej skupiny alebo konfigurácia firewallu webovej aplikácie (Imperva), prípadne sieťového firewallu (iptables, ufw, shorewall atď.). Capital One iba priznal svoju vinu a povedal, že zatvoril dieru.

Stone povedal, že Capital One si najskôr nevšimol zraniteľnosť brány firewall, ale rýchlo konal, keď sa o nej dozvedel. Určite tomu pomohla skutočnosť, že hacker údajne nechal kľúčové identifikačné informácie vo verejnej sfére, povedal Stone.

Ak sa pýtate, prečo sa tejto časti nevenujeme hlbšie, pochopte, že vzhľadom na obmedzené informácie môžeme len špekulovať. To nedáva zmysel vzhľadom na to, že hack závisel od diery, ktorú zanechal Capital One. A pokiaľ nám nepovedia viac, uvedieme len všetky možné spôsoby, ako Capital One nechal svoj server otvorený v kombinácii so všetkými možnými spôsobmi, ako by niekto mohol použiť jednu z týchto rôznych možností. Tieto chyby a techniky sa môžu pohybovať od divoko hlúpych prehliadnutí až po neuveriteľne zložité vzory. Vzhľadom na rozsah možností sa z toho stane dlhá sága bez skutočného záveru. Preto sa sústreďme na rozbor časti, kde máme fakty.

Takže prvý krok je: vedieť, čo umožňujú vaše brány firewall.

Vytvorte politiku alebo správny proces, ktorý zabezpečí, že sa otvorí LEN to, čo je potrebné otvoriť. Ak používate zdroje AWS, ako sú bezpečnostné skupiny alebo sieťové ACL, kontrolný zoznam na audit môže byť samozrejme dlhý... ale rovnako ako mnohé zdroje sa vytvárajú automaticky (t. j. CloudFormation), je tiež možné automatizovať ich audit. Či už je to podomácky vytvorený skript, ktorý skenuje nové objekty na chyby, alebo niečo ako bezpečnostný audit v procese CI/CD... existuje veľa jednoduchých možností, ako sa tomu vyhnúť.

„Vtipná“ časť príbehu je, že keby Capital One zapchal dieru na prvom mieste... nič by sa nestalo. A tak, úprimne povedané, je vždy šokujúce vidieť, ako niečo naozaj je celkom jednoduché sa stáva jediným dôvodom pre napadnutie spoločnosti. Najmä taký veľký ako Capital One.

Takže, hacker vnútri - čo sa stalo potom?

No, po preniknutí do inštancie EC2... sa môže veľa pokaziť. Prakticky kráčate po ostrí noža, ak niekoho necháte zájsť tak ďaleko. Ale ako sa to dostalo do vedier S3? Aby sme to pochopili, poďme diskutovať o úlohách IAM.

Takže jedným zo spôsobov prístupu k službám AWS je byť používateľom. Dobre, toto je celkom zrejmé. Ale čo ak chcete poskytnúť prístup k vašim S3 bucketom aj iným službám AWS, ako sú vaše aplikačné servery? Na to sú roly IAM. Pozostávajú z dvoch komponentov:

  1. Zásady dôvery – aké služby alebo ľudia môžu túto rolu využívať?
  2. Pravidlá povolení – čo táto rola umožňuje?

Napríklad chcete vytvoriť rolu IAM, ktorá umožní inštanciám EC2 prístup k segmentu S3: Po prvé, rola je nastavená tak, aby mala politiku dôvery, že rolu môže „prevziať“ EC2 (celá služba) alebo konkrétne inštancie. Prijatie roly znamená, že môžu používať povolenia roly na vykonávanie akcií. Po druhé, Zásady povolení umožňujú službe/osobe/zdroju, ktorý „prevzal úlohu“, robiť čokoľvek na S3, či už ide o prístup k jednému konkrétnemu segmentu... alebo viac ako 700, ako v prípade Capital One.

Keď ste v inštancii EC2 s rolou IAM, môžete získať poverenia niekoľkými spôsobmi:

  1. Metadáta inštancie si môžete vyžiadať na adrese http://169.254.169.254/latest/meta-data

    Na tejto adrese okrem iného nájdete rolu IAM s ktorýmkoľvek z prístupových kľúčov. Samozrejme, iba ak ste v inštancii.

  2. Použiť AWS CLI...

    Ak je nainštalované rozhranie AWS CLI, načítajú sa do neho poverenia z rolí IAM, ak sú k dispozícii. Ostáva už len pracovať CEZ inštanciu. Samozrejme, ak by ich Zásady dôvery boli otvorené, Paige by mohla robiť všetko priamo.

Takže podstatou rolí IAM je to, že umožňujú niektorým zdrojom konať vo VAŠOM MENE na INÉ ZDROJE.

Teraz, keď ste pochopili úlohy IAM, môžeme hovoriť o tom, čo urobila Paige Thompson:

  1. Získala prístup k serveru (inštancia EC2) cez dieru vo firewalle

    Či už to boli bezpečnostné skupiny/ACL alebo ich vlastné brány firewall webových aplikácií, dieru bolo pravdepodobne celkom ľahké zapchať, ako sa uvádza v oficiálnych záznamoch.

  2. Keď bola na serveri, mohla sa správať „ako keby“ bola sama serverom
  3. Keďže rola servera IAM umožňovala S3 prístup k týmto 700+ vedrám, mohla k nim pristupovať

Od tej chvíle jej stačilo len spustiť príkaz List Bucketsa potom príkaz Sync z AWS CLI...

Capital One Bank odhaduje škody spôsobené hackom na 100 až 150 miliónov dolárov. Predchádzanie takýmto škodám je dôvodom, prečo spoločnosti toľko investujú do ochrany cloudovej infraštruktúry, DevOps a bezpečnostných expertov. A aký hodnotný a nákladovo efektívny je prechod do cloudu? Až tak, že aj napriek stále väčším výzvam v oblasti kybernetickej bezpečnosti Celkový trh s verejným cloudom vzrástol v prvom štvrťroku 42 o 2019 %.!

Morálka príbehu: skontrolujte svoju bezpečnosť; vykonávať pravidelné audity; Rešpektujte zásadu najmenšieho privilégia pre bezpečnostné politiky.

(Tu Môžete si pozrieť celú právnu správu).

Zdroj: hab.com

Pridať komentár