Më 19 korrik 2019, Capital One mori mesazhin se çdo kompani moderne ka frikë - ndodhi një shkelje e të dhënave. Preku më shumë se 106 milionë njerëz. 140 numra të sigurimeve shoqërore në SHBA, një milion numra kanadezë të sigurimeve shoqërore. 000 llogari bankare. E pakëndshme, nuk jeni dakord?
Fatkeqësisht, hakimi nuk ndodhi më 19 korrik. Siç rezulton, Paige Thompson, a.k.a. I çrregullt, e ka kryer nga data 22 mars deri më 23 mars 2019. Kjo eshte gati katër muaj më parë. Në fakt, vetëm me ndihmën e konsulentëve të jashtëm, Capital One mundi të zbulonte se diçka kishte ndodhur.
Një ish-punonjës i Amazon u arrestua dhe përballet me një gjobë prej 250 dollarësh dhe pesë vjet burg... por ka ende shumë negativitet. Pse? Sepse shumë kompani që kanë vuajtur nga hakimet po përpiqen të heqin dorë nga përgjegjësia për forcimin e infrastrukturës dhe aplikacioneve të tyre në mes të rritjes së krimit kibernetik.
Gjithsesi, mund ta kërkoni lehtësisht në google këtë histori. Nuk do të hyjmë në dramë, por do të flasim teknike anën e çështjes.
Para së gjithash, çfarë ndodhi?
Capital One kishte rreth 700 kova S3 në punë, të cilat Paige Thompson i kopjoi dhe i hoqi.
Së dyti, a është ky një rast tjetër i politikës së konfigurimit të gabuar të kovës S3?
Jo, jo këtë herë. Këtu ajo fitoi akses në një server me një mur zjarri të konfiguruar gabimisht dhe kreu të gjithë operacionin prej andej.
Prit, si është e mundur?
Epo, le të fillojmë duke hyrë në server, megjithëse nuk kemi shumë detaje. Na u tha vetëm se ndodhi përmes një "firewall të keqkonfiguruar". Pra, diçka aq e thjeshtë sa cilësimet e gabuara të grupit të sigurisë ose konfigurimi i murit të zjarrit të aplikacionit në internet (Imperva), ose muri i zjarrit i rrjetit (iptables, ufw, shorewall, etj.). Capital One pranoi vetëm fajin dhe tha se e kishte mbyllur vrimën.
Stone tha se Capital One nuk e vuri re fillimisht cenueshmërinë e murit të zjarrit, por veproi shpejt pasi u bë i vetëdijshëm për të. Kjo sigurisht u ndihmua nga fakti që hakeri dyshohet se la informacione kyçe identifikuese në domenin publik, tha Stone.
Nëse po pyesni veten pse nuk po hyjmë më thellë në këtë pjesë, ju lutemi kuptoni se për shkak të informacionit të kufizuar mund vetëm të spekulojmë. Kjo nuk ka kuptim duke pasur parasysh se hakimi varej nga një vrimë e lënë nga Capital One. Dhe nëse nuk na thonë më shumë, ne thjesht do të rendisim të gjitha mënyrat se si Capital One e la të hapur serverin e tyre në kombinim me të gjitha mënyrat e mundshme se si dikush mund të përdorë një nga këto opsione të ndryshme. Këto të meta dhe teknika mund të variojnë nga gabime të pamenduara deri në modele tepër komplekse. Duke pasur parasysh gamën e mundësive, kjo do të bëhet një sagë e gjatë pa përfundim të vërtetë. Prandaj le të fokusohemi në analizimin e pjesës ku kemi fakte.
Pra, hapi i parë është: dijeni se çfarë ju lejojnë muret e zjarrit.
Krijoni një politikë ose një proces të duhur për të siguruar që VETËM ajo që duhet të hapet është e hapur. Nëse jeni duke përdorur burime AWS si Grupet e Sigurisë ose ACL-të e Rrjetit, padyshim që lista e kontrollit për auditim mund të jetë e gjatë... por ashtu si shumë burime krijohen automatikisht (p.sh. CloudFormation), është gjithashtu e mundur të automatizohet auditimi i tyre. Pavarësisht nëse është një skrip i bërë vetë që skanon objekte të reja për të meta, ose diçka si një auditim sigurie në një proces CI/CD... ka shumë opsione të thjeshta për ta shmangur këtë.
Pjesa "qesharake" e historisë është se nëse Capital One do ta kishte mbyllur vrimën që në fillim... asgjë nuk do të kishte ndodhur. Dhe kështu, sinqerisht, është gjithmonë tronditëse të shohësh se si diçka me të vërtetë mjaft e thjeshtë bëhet e vetmja arsye që një kompani të hakerohet. Sidomos një i madh sa Capital One.
Pra, haker brenda - çfarë ndodhi më pas?
Epo, pas hyrjes në një shembull EC2... shumë mund të shkojnë keq. Praktikisht po ecni në teh të thikës nëse e lini dikë të shkojë kaq larg. Por si u fut në kova S3? Për ta kuptuar këtë, le të diskutojmë Rolet e IAM.
Pra, një mënyrë për të hyrë në shërbimet AWS është të jesh Përdorues. Mirë, kjo është shumë e qartë. Por, çka nëse doni t'u jepni shërbime të tjera AWS, siç janë serverët tuaj të aplikacionit, qasje në kovat tuaja S3? Për këtë janë rolet e IAM. Ato përbëhen nga dy komponentë:
- Politika e Mirëbesimit - cilat shërbime ose njerëz mund ta përdorin këtë rol?
- Politika e lejeve - çfarë lejon ky rol?
Për shembull, ju dëshironi të krijoni një rol IAM që do të lejojë që instancat EC2 të aksesojnë një kovë S3: Së pari, roli është caktuar të ketë një Politikë Mirëbesimi që EC2 (i gjithë shërbimi) ose instanca specifike mund të "marrë përsipër" rolin. Pranimi i një roli do të thotë se ata mund të përdorin lejet e rolit për të kryer veprime. Së dyti, Politika e Lejeve lejon që shërbimi/personi/burimi që ka "marrë rolin" të bëjë çdo gjë në S3, qoftë aksesi në një kovë specifike... ose mbi 700, si në rastin e Capital One.
Pasi të jeni në një shembull EC2 me rolin IAM, mund të merrni kredencialet në disa mënyra:
- Mund të kërkoni meta të dhëna të shembullit në
http://169.254.169.254/latest/meta-dataNdër të tjera, rolin IAM mund ta gjeni me cilindo nga çelësat e aksesit në këtë adresë. Sigurisht, vetëm nëse jeni në një rast.
- Përdor AWS CLI...
Nëse AWS CLI është i instaluar, ai ngarkohet me kredencialet nga rolet IAM, nëse është i pranishëm. Gjithçka që mbetet është të punohet PËRMES instancës. Sigurisht, nëse Politika e tyre e Mirëbesimit ishte e hapur, Paige mund të bënte gjithçka drejtpërdrejt.
Pra, thelbi i roleve të IAM-it është se ato lejojnë disa burime që të veprojnë NË EMËR TUAJ në BURIME TË TJERA.
Tani që i kuptoni rolet e IAM, ne mund të flasim për atë që bëri Paige Thompson:
- Ajo fitoi akses në server (shembulli EC2) përmes një vrime në murin e zjarrit
Qoftë nëse ishin grupe sigurie/ACL ose mure zjarri të aplikacioneve të tyre në internet, vrima ishte ndoshta mjaft e lehtë për t'u futur, siç thuhet në të dhënat zyrtare.
- Pasi ishte në server, ajo ishte në gjendje të vepronte "sikur" të ishte vetë serveri
- Meqenëse roli i serverit IAM lejoi S3 qasjen në këto 700+ kova, ai ishte në gjendje t'i qasej ato
Që nga ai moment, asaj i duhej vetëm të drejtonte komandën List Bucketsdhe pastaj komanda Sync nga AWS CLI...
. Parandalimi i një dëmi të tillë është arsyeja pse kompanitë investojnë kaq shumë në mbrojtjen e infrastrukturës cloud, DevOps dhe ekspertët e sigurisë. Dhe sa e vlefshme dhe me kosto efektive është lëvizja në re? Aq shumë që edhe përballë gjithnjë e më shumë sfidave të sigurisë kibernetike !
Morali i tregimit: kontrolloni sigurinë tuaj; Kryerja e auditimeve të rregullta; Respektoni parimin e privilegjit më të vogël për politikat e sigurisë.
( Ju mund të shikoni raportin e plotë ligjor).
Burimi: www.habr.com