Dana 19. srpnja 2019. Capital One primio je poruku koje strahuje svaka moderna tvrtka – došlo je do povrede podataka. Pogodilo je više od 106 milijuna ljudi. 140 američkih brojeva socijalnog osiguranja, milijun kanadskih brojeva socijalnog osiguranja. 000 bankovnih računa. Neugodno, slažete li se?
Nažalost, hakiranje se nije dogodilo 19. srpnja. Kako se doznaje, Paige Thompson, a.k.a. Neredovito, počinio u periodu od 22. ožujka do 23. ožujka 2019. godine. To je prije skoro četiri mjeseca. Zapravo, Capital One je tek uz pomoć vanjskih konzultanata uspio otkriti da se nešto dogodilo.
Bivši zaposlenik Amazona je uhićen i suočava se s novčanom kaznom od 250 dolara i pet godina zatvora... ali ostalo je još puno negativnosti. Zašto? Zato što mnoge tvrtke koje su patile od hakiranja pokušavaju zbaciti odgovornost za jačanje svoje infrastrukture i aplikacija usred porasta kibernetičkog kriminala.
U svakom slučaju, ovu priču možete lako guglati. Nećemo ulaziti u dramu, nego o tome tehničke stranu stvari.
Prije svega, što se dogodilo?
Capital One je imao oko 700 S3 spremnika, koje je Paige Thompson kopirala i isisala.
Drugo, je li ovo još jedan slučaj pogrešno konfigurirane politike spremnika S3?
Ne, ne ovaj put. Ovdje je dobila pristup poslužitelju s neispravno konfiguriranim vatrozidom i odatle izvršila cijelu operaciju.
Čekaj, kako je to moguće?
Pa, počnimo s prijavom na poslužitelj, iako nemamo puno detalja. Rečeno nam je samo da se to dogodilo kroz "pogrešno konfiguriran vatrozid". Dakle, nešto tako jednostavno kao što su netočne postavke sigurnosne grupe ili konfiguracija vatrozida web aplikacije (Imperva), ili mrežnog vatrozida (iptables, ufw, shorewall, itd.). Capital One je samo priznao svoju krivnju i rekao da je zatvorio rupu.
Stone je rekao da Capital One u početku nije primijetio ranjivost vatrozida, ali je brzo djelovao kada je postao svjestan toga. Tome je svakako pomogla činjenica da je haker navodno ostavio ključne podatke za identifikaciju u javnoj domeni, rekao je Stone.
Ako se pitate zašto ne idemo dublje u ovaj dio, shvatite da zbog ograničenih informacija možemo samo nagađati. Ovo nema smisla s obzirom da je hakiranje ovisilo o rupi koju je ostavio Capital One. I osim ako nam ne kažu više, samo ćemo navesti sve moguće načine na koje je Capital One ostavio otvoren svoj server u kombinaciji sa svim mogućim načinima na koje bi netko mogao upotrijebiti jednu od ovih različitih opcija. Ovi nedostaci i tehnike mogu varirati od krajnje glupih propusta do nevjerojatno složenih obrazaca. S obzirom na niz mogućnosti, ovo će postati duga saga bez pravog zaključka. Stoga, usredotočimo se na analizu dijela u kojem imamo činjenice.
Dakle, prvi zaključak je: znajte što dopuštaju vaši vatrozidi.
Uspostavite politiku ili odgovarajući proces kako biste osigurali da se otvori SAMO ono što treba otvoriti. Ako koristite AWS resurse kao što su sigurnosne grupe ili mrežni ACL-ovi, očito je da kontrolni popis za reviziju može biti dugačak... ali kao što se mnogi resursi stvaraju automatski (tj. CloudFormation), također je moguće automatizirati njihovu reviziju. Bilo da se radi o domaćoj skripti koja skenira nove objekte u potrazi za nedostacima ili nečemu poput sigurnosne revizije u CI/CD procesu... postoje mnoge jednostavne opcije za izbjegavanje ovoga.
"Smiješni" dio priče je da da je Capital One uopće začepio rupu... ništa se ne bi dogodilo. I tako, iskreno, uvijek je šokantno vidjeti kako nešto stvarno prilično jednostavno postaje jedini razlog da tvrtka bude hakirana. Pogotovo tako velik kao što je Capital One.
Dakle, haker unutra - što se zatim dogodilo?
Pa, nakon provale u EC2 instancu... puno toga može poći po zlu. Praktički hodaš po oštrici noža ako dopustiš nekome da ode tako daleko. Ali kako je dospio u S3 kante? Da bismo ovo razumjeli, razgovarajmo o IAM ulogama.
Dakle, jedan od načina za pristup AWS uslugama je biti korisnik. U redu, ovo je prilično očito. Ali što ako želite dati drugim AWS uslugama, kao što su vaši aplikacijski poslužitelji, pristup vašim S3 spremnicima? Tome služe IAM uloge. Sastoje se od dvije komponente:
- Politika povjerenja - koje usluge ili ljudi mogu koristiti ovu ulogu?
- Pravila dopuštenja - što dopušta ova uloga?
Na primjer, želite stvoriti IAM ulogu koja će omogućiti EC2 instancama pristup S3 spremniku: Prvo, uloga je postavljena tako da ima Pravila povjerenja prema kojima EC2 (cijela usluga) ili određene instance mogu "preuzeti" ulogu. Prihvaćanje uloge znači da mogu koristiti dopuštenja uloge za izvođenje radnji. Drugo, Pravila dopuštenja dopuštaju usluzi/osobi/resursu koji je "preuzeo ulogu" da radi bilo što na S3, bilo da pristupa jednom određenom spremniku... ili preko 700, kao u slučaju Capital One.
Nakon što ste u EC2 instanci s IAM ulogom, vjerodajnice možete dobiti na nekoliko načina:
- Možete zatražiti metapodatke instance na
http://169.254.169.254/latest/meta-dataIzmeđu ostalog, na ovoj adresi možete pronaći IAM ulogu s bilo kojim od pristupnih ključeva. Naravno, samo ako ste u instanci.
- Koristite AWS CLI...
Ako je AWS CLI instaliran, učitava se vjerodajnicama iz IAM uloga, ako postoje. Ostaje samo raditi KROZ instancu. Naravno, ako je njihova politika povjerenja otvorena, Paige bi sve mogla učiniti izravno.
Dakle, bit IAM uloga je da dopuštaju nekim resursima da djeluju U VAŠE IME na DRUGIM RESURSIMA.
Sada kada razumijete uloge IAM-a, možemo govoriti o tome što je Paige Thompson učinila:
- Dobila je pristup poslužitelju (instanci EC2) kroz rupu u vatrozidu
Bilo da se radilo o sigurnosnim grupama/ACL-ovima ili vlastitim vatrozidima web-aplikacija, rupu je vjerojatno bilo prilično lako začepiti, kao što je navedeno u službenim zapisima.
- Jednom kada je bila na poslužitelju, mogla se ponašati "kao da" je ona sama poslužitelj
- Budući da je uloga IAM poslužitelja omogućila S3 pristup do ovih 700+ spremnika, mogao im je pristupiti
Od tog trenutka nadalje, sve što je trebala učiniti bilo je pokrenuti naredbu List Bucketsa zatim zapovijed Sync iz AWS CLI...
. Sprječavanje takve štete razlog je zašto tvrtke toliko ulažu u zaštitu infrastrukture oblaka, DevOps i sigurnosne stručnjake. I koliko je prelazak u oblak vrijedan i isplativ? Toliko da čak i pred sve većim izazovima kibernetičke sigurnosti !
Moral priče: provjerite svoju sigurnost; Provoditi redovite revizije; Poštujte načelo najmanje privilegije za sigurnosne politike.
( Možete pogledati cijelo pravno izvješće).
Izvor: www.habr.com