19. července 2019 obdržela společnost Capital One zprávu, které se každá moderní společnost obává – došlo k úniku dat. Zasáhlo více než 106 milionů lidí. 140 000 amerických čísel sociálního zabezpečení, jeden milion kanadských čísel sociálního zabezpečení. 80 000 bankovních účtů. Nepříjemné, souhlasíte?
Bohužel k hacknutí nedošlo 19. července. Jak se ukazuje, Paige Thompson, a.k.a. Nesprávné, se ho dopustil v době od 22. března do 23. března 2019. To znamená téměř před čtyřmi měsíci. Ve skutečnosti to bylo pouze s pomocí externích konzultantů, kterým se Capital One podařilo zjistit, že se něco stalo.
Bývalý zaměstnanec Amazonu byl zatčen a hrozí mu pokuta 250 XNUMX dolarů a pět let vězení... ale stále zbývá spousta negativity. Proč? Protože mnoho společností, které trpěly hackery, se v době nárůstu kybernetické kriminality snaží zbavit odpovědnosti za posílení své infrastruktury a aplikací.
Každopádně tento příběh si můžete snadno vygooglit. Nebudeme se pouštět do dramatu, ale mluvit o tom technický stranu věci.
Za prvé, co se stalo?
V Capital One běželo asi 700 kbelíků S3, které Paige Thompson zkopírovala a vysála.
Za druhé, jedná se o další případ nesprávně nakonfigurované zásady bucketu S3?
Ne, tentokrát ne. Zde získala přístup na server s nesprávně nastaveným firewallem a odtud celou operaci provedla.
Počkejte, jak je to možné?
Začněme přihlášením na server, i když nemáme mnoho podrobností. Bylo nám pouze řečeno, že se to stalo přes „nesprávně nakonfigurovaný firewall“. Tedy něco tak jednoduchého, jako je nesprávné nastavení bezpečnostní skupiny nebo konfigurace firewallu webové aplikace (Imperva), případně síťového firewallu (iptables, ufw, shorewall atd.). Capital One pouze přiznal svou vinu a řekl, že uzavřel díru.
Stone řekl, že Capital One si zpočátku zranitelnosti firewallu nevšiml, ale jednal rychle, jakmile se o ní dozvěděl. Tomu jistě napomohla skutečnost, že hacker údajně nechal klíčové identifikační informace ve veřejné doméně, řekl Stone.
Pokud se ptáte, proč se touto částí nezabýváme hlouběji, pochopte prosím, že kvůli omezeným informacím můžeme pouze spekulovat. To nedává smysl vzhledem k tomu, že hack závisel na díře, kterou zanechal Capital One. A pokud nám neřeknou více, uvedeme pouze všechny možné způsoby, jak Capital One nechal svůj server otevřený v kombinaci se všemi možnými způsoby, jak by někdo mohl použít jednu z těchto různých možností. Tyto nedostatky a techniky se mohou pohybovat od divoce hloupých přehlédnutí až po neuvěřitelně složité vzory. Vzhledem k rozsahu možností se z toho stane dlouhá sága bez skutečného závěru. Zaměřme se proto na rozbor části, kde máme fakta.
Takže první krok zní: vědět, co vaše firewally umožňují.
Vytvořte politiku nebo správný proces, který zajistí, že bude otevřeno POUZE to, co je třeba otevřít. Pokud používáte zdroje AWS, jako jsou skupiny zabezpečení nebo síťové ACL, může být kontrolní seznam k auditu samozřejmě dlouhý... ale stejně jako mnoho zdrojů se vytváří automaticky (tj. CloudFormation), je také možné automatizovat jejich auditování. Ať už je to podomácku vyrobený skript, který skenuje nové objekty na chyby, nebo něco jako bezpečnostní audit v procesu CI/CD... existuje mnoho jednoduchých možností, jak se tomu vyhnout.
"Vtipná" část příběhu je, že kdyby Capital One zacpal díru na prvním místě... nic by se nestalo. A tak, upřímně řečeno, je vždy šokující vidět, jak něco skutečně je docela jednoduché se stává jediným důvodem pro hacknutí společnosti. Zvláště jeden tak velký jako Capital One.
Takže, hacker uvnitř - co se stalo potom?
No, po nabourání do instance EC2... se toho může hodně pokazit. Když někoho necháte zajít tak daleko, jdete prakticky po ostří nože. Ale jak se to dostalo do kýblů S3? Abychom to pochopili, pojďme diskutovat o rolích IAM.
Jedním ze způsobů přístupu ke službám AWS je tedy být uživatelem. Dobře, tohle je docela zřejmé. Ale co když chcete poskytnout přístup k vašim S3 bucketům dalším službám AWS, jako jsou vaše aplikační servery? K tomu slouží role IAM. Skládají se ze dvou složek:
- Zásady důvěry – jaké služby nebo lidé mohou tuto roli využívat?
- Zásady oprávnění – co tato role umožňuje?
Chcete například vytvořit roli IAM, která umožní instancím EC2 přístup k segmentu S3: Nejprve je role nastavena tak, aby měla zásadu důvěryhodnosti, že roli může „převzít“ EC2 (celá služba) nebo konkrétní instance. Přijetí role znamená, že mohou používat oprávnění role k provádění akcí. Za druhé, Zásady oprávnění umožňují službě/osobě/zdroji, který „převzal roli“, dělat cokoli na S3, ať už jde o přístup k jednomu konkrétnímu segmentu... nebo více než 700, jako v případě Capital One.
Jakmile jste v instanci EC2 s rolí IAM, můžete získat přihlašovací údaje několika způsoby:
- Metadata instance si můžete vyžádat na adrese
http://169.254.169.254/latest/meta-dataNa této adrese najdete mimo jiné roli IAM s kterýmkoli z přístupových klíčů. Samozřejmě, pouze pokud jste v instanci.
- Použijte AWS CLI...
Pokud je nainstalováno rozhraní AWS CLI, načte se do něj přihlašovací údaje z rolí IAM, pokud existují. Nezbývá než pracovat PŘES instanci. Samozřejmě, kdyby byla jejich politika důvěry otevřená, mohla by Paige dělat všechno přímo.
Podstatou rolí IAM je tedy to, že umožňují některým zdrojům jednat VAŠIM JMÉNEM na JINÉ ZDROJE.
Nyní, když rozumíte rolím IAM, můžeme mluvit o tom, co udělala Paige Thompson:
- Získala přístup k serveru (instanci EC2) dírou ve firewallu
Ať už to byly bezpečnostní skupiny/ACL nebo jejich vlastní firewally webových aplikací, díru bylo pravděpodobně docela snadné zacpat, jak je uvedeno v oficiálních záznamech.
- Jakmile byla na serveru, dokázala se chovat „jako by“ byla sama serverem
- Vzhledem k tomu, že role serveru IAM umožňovala S3 přístup k těmto 700+ bucketům, mohla k nim přistupovat
Od té chvíle stačilo jen spustit příkaz List Bucketsa pak příkaz Sync z AWS CLI...
. Předcházení takovým škodám je důvodem, proč společnosti tolik investují do ochrany cloudové infrastruktury, DevOps a bezpečnostních expertů. A jak hodnotný a nákladově efektivní je přesun do cloudu? Natolik, že i tváří v tvář stále větším výzvám v oblasti kybernetické bezpečnosti !
Morálka příběhu: zkontrolujte svou bezpečnost; Provádět pravidelné audity; Respektujte zásadu nejmenšího privilegia pro bezpečnostní zásady.
( Můžete si prohlédnout celou právní zprávu).
Zdroj: www.habr.com