19. juulil 2019 sai Capital One teade, mida iga kaasaegne ettevõte kardab – toimus andmerikkumine. See mõjutas rohkem kui 106 miljonit inimest. 140 000 USA sotsiaalkindlustuse numbrit, üks miljon Kanada sotsiaalkindlustuse numbrit. 80 000 pangakontot. Ebameeldiv, kas te pole nõus?
Kahjuks 19. juulil häkkimist ei toimunud. Nagu selgub, on Paige Thompson, a.k.a. Ebakorrapärane, pani selle toime 22. märtsist 23. märtsini 2019. See on peaaegu neli kuud tagasi. Tegelikult sai Capital One alles väliste konsultantide abiga avastada, et midagi on juhtunud.
Endine Amazoni töötaja arreteeriti ja teda ähvardab 250 XNUMX dollari suurune trahv ja viis aastat vangistust... kuid negatiivsust on veel palju alles. Miks? Kuna paljud häkkide all kannatanud ettevõtted üritavad küberkuritegevuse kasvu ajal oma infrastruktuuri ja rakenduste tugevdamise eest vastutust maha võtta.
Igatahes saab selle loo lihtsalt googeldada. Me ei lasku draama, vaid räägime sellest tehniline asja pool.
Esiteks, mis juhtus?
Capital One’il oli töös umbes 700 S3 ämbrit, mille Paige Thompson kopeeris ja välja tõmbas.
Teiseks, kas see on järjekordne valesti konfigureeritud S3 ämbripoliitika juhtum?
Ei, seekord mitte. Siin sai ta juurdepääsu valesti konfigureeritud tulemüüriga serverile ja viis sealt läbi kogu toimingu.
Oota, kuidas see võimalik on?
Noh, alustame serverisse sisselogimisega, kuigi meil pole palju üksikasju. Meile öeldi ainult, et see juhtus "valesti konfigureeritud tulemüüri kaudu". Niisiis, midagi nii lihtsat nagu valed turvagrupi sätted või veebirakenduse tulemüüri (Imperva) või võrgu tulemüüri (iptables, ufw, shorewall jne) konfiguratsioon. Capital One tunnistas vaid oma süüd ja ütles, et on augu sulgenud.
Stone ütles, et Capital One ei märganud algselt tulemüüri haavatavust, kuid tegutses kiiresti, kui sellest teada sai. Sellele aitas kindlasti kaasa asjaolu, et häkker jättis väidetavalt avalikku omandisse identifitseeriva võtmeteabe, ütles Stone.
Kui te ei tea, miks me sellesse osasse sügavamalt ei lähe, siis mõistke, et piiratud teabe tõttu saame vaid oletada. Sellel pole mõtet, arvestades, et häkkimine sõltus Capital One'i jäetud august. Ja kui nad meile rohkem ei räägi, loetleme lihtsalt kõik võimalikud viisid, kuidas Capital One oma serveri avatuks jättis, ja kõik võimalikud viisid, kuidas keegi saaks mõnda neist erinevatest valikutest kasutada. Need vead ja tehnikad võivad ulatuda metsikult rumalatest möödalaskmistest kuni uskumatult keeruliste mustriteni. Arvestades võimalusi, saab sellest pikk saaga, millel pole tegelikke järeldusi. Seetõttu keskendume selle osa analüüsimisele, kus meil on faktid.
Nii et esimene kokkuvõte on: teadke, mida teie tulemüürid võimaldavad.
Kehtestage poliitika või õige protsess tagamaks, et avatakse AINULT see, mis tuleb avada. Kui kasutate AWS-i ressursse, nagu turberühmad või võrgu ACL-id, võib auditeerimise kontroll-loend olla pikk... aga nagu paljud ressursid luuakse automaatselt (nt CloudFormation), on võimalik ka nende auditeerimist automatiseerida. Olgu selleks omatehtud skript, mis skannib uutel objektidel vigu või midagi sellist, nagu turvaaudit CI/CD protsessis... selle vältimiseks on palju lihtsaid võimalusi.
Loo "naljakas" osa on see, et kui Capital One oleks augu alguses kinni toppinud... poleks midagi juhtunud. Ja ausalt öeldes on alati šokeeriv näha, kuidas midagi tegelikult on päris lihtne muutub ettevõtte häkkimise ainsaks põhjuseks. Eriti sama suur kui Capital One.
Niisiis, häkker sees – mis edasi sai?
Noh, pärast EC2 eksemplari sissemurdmist... võib palju valesti minna. Sa kõnnid praktiliselt noateral, kui lased kellelgi nii kaugele minna. Aga kuidas see S3 ämbritesse sattus? Selle mõistmiseks arutame IAM-i rolle.
Seega on üks viis AWS-i teenustele juurdepääsuks olla kasutaja. Olgu, see on üsna ilmne. Aga mis siis, kui soovite anda teistele AWS-i teenustele, näiteks oma rakendusserveritele, juurdepääsu oma S3 ämbritele? Selleks on IAM-i rollid. Need koosnevad kahest komponendist:
- Usalduspoliitika – millised teenused või inimesed saavad seda rolli kasutada?
- Lubade poliitika – mida see roll võimaldab?
Näiteks soovite luua IAM-i rolli, mis võimaldab EC2 eksemplaridel pääseda juurde S3 ämbrile: esiteks on rollil seatud usalduspoliitika, mille kohaselt EC2 (kogu teenus) või konkreetsed eksemplarid saavad rolli üle võtta. Rolli vastuvõtmine tähendab, et nad saavad toimingute tegemiseks kasutada rolli õigusi. Teiseks lubab lubade poliitika teenusel/isikul/ressursil, kes on rolli võtnud, S3-s kõike teha, olgu selleks siis juurdepääs ühele konkreetsele ämbrile... või üle 700, nagu Capital One’i puhul.
Kui olete IAM-i rolliga EC2 eksemplaris, saate mandaate hankida mitmel viisil.
- Saate taotleda eksemplari metaandmeid aadressil
http://169.254.169.254/latest/meta-dataMuuhulgas leiate sellelt aadressilt mis tahes juurdepääsuvõtmega IAM-i rolli. Muidugi ainult siis, kui olete juhtumis.
- Kasutage AWS-i CLI-d...
Kui AWS-i CLI on installitud, laaditakse see IAM-i rollide mandaatidega, kui need on olemas. Jääb üle vaid töötada eksemplari LÄBI. Muidugi, kui nende usalduspoliitika oleks avatud, saaks Paige teha kõike otse.
Seega on IAM-i rollide põhiolemus selles, et need võimaldavad mõnel ressurssil TEIE NIMEL TEISTE RESSURSSIGA tegutseda.
Nüüd, kui mõistate IAM-i rolle, võime rääkida sellest, mida Paige Thompson tegi:
- Ta sai juurdepääsu serverile (EC2 eksemplar) läbi tulemüüri augu
Olgu selleks turvarühmad/ACL-id või nende enda veebirakenduste tulemüürid, oli auk ilmselt üsna lihtne kinni keerata, nagu ametlikes dokumentides kirjas.
- Serveris olles suutis ta käituda nii, nagu oleks ta ise server
- Kuna IAM-i serveri roll võimaldas S3-l juurdepääsu neile 700+ ämbrile, pääses see neile juurde
Sellest hetkest peale ei jäänud tal muud üle kui käsk täita List Bucketsja siis käsk Sync AWS CLI-st...
. Sellise kahju ärahoidmine on põhjus, miks ettevõtted investeerivad nii palju pilve infrastruktuuri kaitsesse, DevOpsi ja turvaekspertidesse. Ja kui väärtuslik ja tasuv on pilve kolimine? Nii palju, et isegi üha uute küberturvalisuse väljakutsete ees !
Loo moraal: kontrollige oma ohutust; Viia läbi regulaarseid auditeid; Austage turvapoliitika vähimate privileegide põhimõtet.
( Saate vaadata täielikku juriidilist aruannet).
Allikas: www.habr.com