19. julija 2019 je Capital One prejel sporočilo, ki se ga boji vsako sodobno podjetje – zgodila se je kršitev podatkov. Prizadelo je več kot 106 milijonov ljudi. 140 ameriških številk socialnega zavarovanja, milijon kanadskih številk socialnega zavarovanja. 000 bančnih računov. Neprijetno, se strinjate?
Na žalost do vdora 19. julija ni prišlo. Kot se je izkazalo, je Paige Thompson, a.k.a. Neredno, zagrešil med 22. in 23. marcem 2019. To je pred skoraj štirimi meseci. Pravzaprav je Capital One šele s pomočjo zunanjih svetovalcev lahko odkril, da se je nekaj zgodilo.
Nekdanji uslužbenec Amazona je bil aretiran in grozi mu globa v višini 250 $ in pet let zapora ... a še vedno je ostalo veliko negativnosti. Zakaj? Ker se mnoga podjetja, ki so bila prizadeta zaradi vdorov, poskušajo otresti odgovornosti za krepitev svoje infrastrukture in aplikacij ob porastu kibernetske kriminalitete.
Kakorkoli, to zgodbo lahko preprosto poguglate. Ne bomo se spuščali v dramo, ampak o tem tehnični plat zadeve.
Najprej, kaj se je zgodilo?
Capital One je imel v teku približno 700 veder S3, ki jih je Paige Thompson kopirala in izčrpala.
Drugič, ali je to še en primer napačno konfigurirane politike vedra S3?
Ne, tokrat ne. Tu je pridobila dostop do strežnika z nepravilno nastavljenim požarnim zidom in od tam izvedla celotno operacijo.
Počakaj, kako je to mogoče?
No, začnimo s prijavo v strežnik, čeprav nimamo veliko podrobnosti. Povedali so nam le, da se je to zgodilo prek »napačno konfiguriranega požarnega zidu«. Torej nekaj tako preprostega, kot so nepravilne nastavitve varnostne skupine ali konfiguracija požarnega zidu spletne aplikacije (Imperva) ali omrežnega požarnega zidu (iptables, ufw, shorewall itd.). Capital One je samo priznal svojo krivdo in dejal, da je zapolnil luknjo.
Stone je dejal, da Capital One sprva ni opazil ranljivosti požarnega zidu, vendar je hitro ukrepal, ko se je zavedel. K temu je zagotovo pripomoglo dejstvo, da je heker domnevno pustil ključne identifikacijske podatke v javni domeni, je dejal Stone.
Če se sprašujete, zakaj se ne poglobimo v ta del, razumejte, da lahko zaradi omejenih informacij le špekuliramo. To nima smisla glede na to, da je vdor odvisen od luknje, ki jo je pustil Capital One. In če nam ne povedo več, bomo le našteli vse možne načine, na katere je Capital One pustil svoj strežnik odprt, v kombinaciji z vsemi možnimi načini, na katere bi nekdo lahko uporabil eno od teh različnih možnosti. Te napake in tehnike lahko segajo od divje neumnih spregledov do neverjetno zapletenih vzorcev. Glede na paleto možnosti bo to postala dolga saga brez pravega zaključka. Zato se osredotočimo na analizo tistega dela, kjer imamo dejstva.
Prvi zaključek je torej: vedite, kaj vaši požarni zidovi omogočajo.
Vzpostavite pravilnik ali ustrezen postopek, da zagotovite, da se odpre SAMO tisto, kar je treba odpreti. Če uporabljate vire AWS, kot so varnostne skupine ali omrežni ACL-ji, je kontrolni seznam za revizijo očitno lahko dolg ... a tako kot se mnogi viri ustvarijo samodejno (tj. CloudFormation), je mogoče tudi avtomatizirati njihovo revizijo. Ne glede na to, ali gre za domači skript, ki skenira nove objekte za napake, ali nekaj podobnega varnostni reviziji v procesu CI/CD ... obstaja veliko preprostih možnosti, da se temu izognete.
"Smešen" del zgodbe je, da če bi Capital One sploh zamašil luknjo ... se ne bi zgodilo nič. In tako, odkrito povedano, vedno je šokantno videti, kako nekaj zares precej preprosto postane edini razlog za vdor v podjetje. Še posebej tako velik, kot je Capital One.
Torej, heker notri - kaj se je zgodilo potem?
No, po vdoru v primerek EC2... gre lahko marsikaj narobe. Praktično hodiš po ostrini noža, če pustiš nekoga, da gre tako daleč. Toda kako je prišel v vedra S3? Da bi to razumeli, se pogovorimo o vlogah IAM.
Eden od načinov za dostop do storitev AWS je torej biti uporabnik. V redu, ta je precej očiten. Kaj pa, če želite drugim storitvam AWS, kot so vaši aplikacijski strežniki, omogočiti dostop do vaših veder S3? Temu so namenjene vloge IAM. Sestavljeni so iz dveh komponent:
- Politika zaupanja – katere storitve ali osebe lahko uporabljajo to vlogo?
- Politika dovoljenj – kaj omogoča ta vloga?
Na primer, želite ustvariti vlogo IAM, ki bo primerkom EC2 omogočila dostop do vedra S3: Prvič, vloga je nastavljena tako, da ima pravilnik zaupanja, da lahko EC2 (celotna storitev) ali določeni primerki »prevzamejo« vlogo. Sprejem vloge pomeni, da lahko uporabijo dovoljenja vloge za izvajanje dejanj. Drugič, pravilnik o dovoljenjih dovoljuje storitvi/osebi/viru, ki je »prevzel vlogo«, da naredi kar koli na S3, pa naj gre za dostop do enega določenega vedra ... ali več kot 700, kot v primeru Capital One.
Ko ste v instanci EC2 z vlogo IAM, lahko pridobite poverilnice na več načinov:
- Metapodatke primerka lahko zahtevate na
http://169.254.169.254/latest/meta-dataMed drugim lahko na tem naslovu najdete vlogo IAM s katerim koli ključem za dostop. Seveda le, če ste v primeru.
- Uporabi AWS CLI ...
Če je AWS CLI nameščen, se naloži s poverilnicami iz vlog IAM, če so prisotne. Vse kar ostane je delo PREKO instance. Seveda, če bi bila njihova politika zaupanja odprta, bi Paige lahko vse naredila neposredno.
Bistvo vlog IAM je torej, da nekaterim virom omogočajo, da delujejo V VAŠEM IMENU na DRUGIH VIRIH.
Zdaj, ko razumete vloge IAM, lahko govorimo o tem, kaj je storila Paige Thompson:
- Dostop do strežnika (instanca EC2) je dobila skozi luknjo v požarnem zidu
Ne glede na to, ali je šlo za varnostne skupine/ACL-je ali lastne požarne zidove spletnih aplikacij, je bilo luknjo verjetno zelo enostavno zamašiti, kot je navedeno v uradnih zapisih.
- Ko je bila na strežniku, se je lahko obnašala, "kot da" je strežnik sama
- Ker je vloga strežnika IAM dovoljevala S3 dostop do teh 700+ veder, je lahko dostopal do njih
Od tistega trenutka dalje je morala samo izvesti ukaz List Bucketsin nato ukaz Sync iz AWS CLI...
. Preprečevanje takšne škode je razlog, zakaj podjetja toliko vlagajo v zaščito infrastrukture v oblaku, DevOps in varnostne strokovnjake. In kako dragocena in stroškovno učinkovita je selitev v oblak? Tako zelo, da tudi ob vedno več izzivih kibernetske varnosti !
Morala zgodbe: preverite svojo varnost; Izvajati redne revizije; Za varnostne politike upoštevajte načelo najmanjših privilegijev.
( Ogledate si lahko celotno pravno poročilo).
Vir: www.habr.com