Dana 19. jula 2019., Capital One je dobio poruku od koje se plaši svaka moderna kompanija – došlo je do povrede podataka. Pogađalo je više od 106 miliona ljudi. 140 američkih brojeva socijalnog osiguranja, milion kanadskih brojeva socijalnog osiguranja. 000 bankovnih računa. Neprijatno, zar se ne slažete?
Nažalost, hakiranje se nije dogodilo 19. jula. Kako se ispostavilo, Paige Thompson, a.k.a. Nepravilno, izvršio u periodu od 22. marta do 23. marta 2019. godine. To je prije skoro četiri mjeseca. U stvari, Capital One je samo uz pomoć vanjskih konsultanata uspio otkriti da se nešto dogodilo.
Bivši zaposlenik Amazona je uhapšen i suočava se s novčanom kaznom od 250 dolara i pet godina zatvora... ali još uvijek je ostalo mnogo negativnosti. Zašto? Zato što mnoge kompanije koje su patile od hakova pokušavaju da se oslobode odgovornosti za jačanje svoje infrastrukture i aplikacija usred porasta sajber kriminala.
U svakom slučaju, ovu priču možete lako proguglati. Nećemo se upuštati u dramu, nego pričamo o tome tehnički stranu stvari.
Prije svega, šta se dogodilo?
Capital One je imao oko 700 kanti S3, koje je Pejdž Tompson kopirala i isisala.
Drugo, da li je ovo još jedan slučaj pogrešno konfigurisane S3 bucket politike?
Ne, ne ovaj put. Ovdje je dobila pristup serveru s pogrešno konfiguriranim firewall-om i odatle izvela cijelu operaciju.
Čekaj, kako je to moguće?
Pa, hajde da počnemo tako što ćemo se prijaviti na server, iako nemamo mnogo detalja. Rečeno nam je samo da se to dogodilo preko “pogrešno konfigurisanog zaštitnog zida”. Dakle, nešto tako jednostavno kao što su pogrešne postavke sigurnosne grupe ili konfiguracija firewall-a web aplikacije (Imperva), ili mrežnog firewall-a (iptables, ufw, shorewall, itd.). Capital One je samo priznao krivicu i rekao da je zatvorio rupu.
Stone je rekao da Capital One u početku nije primijetio ranjivost firewall-a, ali je brzo reagirao kada je postao svjestan toga. Tome je svakako pomogla i činjenica da je haker navodno ostavio ključne identifikacione informacije u javnom domenu, rekao je Stone.
Ako se pitate zašto ne ulazimo dublje u ovaj dio, imajte na umu da zbog ograničenih informacija možemo samo nagađati. Ovo nema smisla s obzirom da je hakiranje zavisilo od rupe koju je ostavio Capital One. I osim ako nam ne kažu više, mi ćemo samo navesti sve moguće načine na koje je Capital One ostavio svoj server otvoren u kombinaciji sa svim mogućim načinima na koje bi neko mogao koristiti jednu od ovih različitih opcija. Ove mane i tehnike mogu se kretati od ludo glupih previda do nevjerovatno složenih obrazaca. S obzirom na niz mogućnosti, ovo će postati duga saga bez pravog zaključka. Stoga, hajde da se fokusiramo na analizu dijela u kojem imamo činjenice.
Dakle, prvi zaključak je: znajte šta vaši zaštitni zidovi dozvoljavaju.
Uspostavite politiku ili odgovarajući proces kako biste osigurali da se otvori SAMO ono što treba otvoriti. Ako koristite AWS resurse poput sigurnosnih grupa ili mrežnih ACL-ova, očito kontrolna lista za reviziju može biti duga... ali baš kao što se mnogi resursi kreiraju automatski (tj. CloudFormation), moguće je i 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... postoji mnogo jednostavnih opcija da se ovo izbjegne.
"Smiješni" dio priče je da da je Capital One začepio rupu... ništa se ne bi dogodilo. I tako, iskreno, uvijek je šokantno vidjeti kako nešto zaista prilično jednostavno postaje jedini razlog da kompanija bude hakovana. Posebno veliki kao Capital One.
Dakle, haker unutra - šta se dalje dogodilo?
Pa, nakon provale u EC2 instancu... mnogo toga može poći naopako. Praktično hodate na oštrici noža ako nekoga pustite da ode tako daleko. Ali kako je dospio u S3 kante? Da bismo ovo razumjeli, razgovarajmo o IAM ulogama.
Dakle, jedan od načina pristupa AWS uslugama je da budete korisnik. Ok, ovo je prilično očigledno. Ali šta ako drugim AWS uslugama, kao što su serveri aplikacija, želite dati pristup vašim S3 buckets? Tome služe IAM uloge. Sastoje se od dvije komponente:
- Politika povjerenja - koje usluge ili ljudi mogu koristiti ovu ulogu?
- Politika dozvola - šta ova uloga dozvoljava?
Na primjer, želite da kreirate IAM ulogu koja će omogućiti EC2 instancama da pristupe S3 bucketu: Prvo, uloga je postavljena da ima Politiku povjerenja da EC2 (cijela usluga) ili određene instance mogu "preuzeti" ulogu. Prihvatanje uloge znači da mogu koristiti dozvole uloge za izvođenje radnji. Drugo, Politika dozvola dozvoljava servisu/osobi/resursu koji je „preuzeo ulogu“ da uradi bilo šta na S3, bilo da se radi o pristupu jednom specifičnom segmentu... ili preko 700, kao u slučaju Capital One.
Jednom kada ste u EC2 instanci sa IAM ulogom, vjerodajnice možete dobiti na nekoliko načina:
- Možete zatražiti metapodatke instance na adresi
http://169.254.169.254/latest/meta-dataIzmeđu ostalog, na ovoj adresi možete pronaći IAM ulogu sa 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. Sve što ostaje je raditi KROZ instancu. Naravno, da je njihova politika povjerenja otvorena, Pejdž bi sve mogla da radi direktno.
Dakle, suština IAM uloga je da one dozvoljavaju nekim resursima da djeluju U VAŠE IME na DRUGIM RESURSIMA.
Sada kada razumete uloge IAM-a, možemo razgovarati o tome šta je Pejdž Tompson uradila:
- Dobila je pristup serveru (EC2 instanca) kroz rupu u zaštitnom zidu
Bilo da se radi o sigurnosnim grupama/ACL-ovima ili njihovim vlastitim zaštitnim zidovima za web aplikacije, rupu je vjerovatno bilo prilično lako začepiti, kao što je navedeno u službenim zapisima.
- Jednom na serveru, mogla je da se ponaša "kao da" je i sama server
- Pošto je uloga IAM servera dozvolila S3 pristup ovim 700+ buckets, mogao je pristupiti njima
Od tog trenutka, sve što je morala da uradi je da izvrši komandu List Bucketsa zatim komandu Sync iz AWS CLI...
. Sprečavanje takve štete je razlog zašto kompanije toliko ulažu u zaštitu infrastrukture oblaka, DevOps i stručnjake za sigurnost. I koliko je vrijedno i isplativo prelazak u oblak? Toliko da čak i suočeni sa sve više i više izazova kibernetičke sigurnosti !
Moral priče: provjerite svoju sigurnost; Sprovoditi redovne revizije; Poštujte princip najmanje privilegija za sigurnosne politike.
( Možete pogledati kompletan pravni izvještaj).
izvor: www.habr.com