19ko uztailaren 2019an, Capital Onek enpresa moderno guztiek beldurra duten mezua jaso zuen: datu-urraketa bat gertatu zen. 106 milioi pertsona baino gehiagori eragin zien. 140 AEBetako gizarte segurantzako zenbaki, milioi bat Kanadako gizarte segurantzako zenbaki. 000 banku-kontu. Desatsegina, ez al zaude ados?
Zoritxarrez, hackea ez zen uztailaren 19an gertatu. Horren ondorioz, Paige Thompson, a.k.a. Erratikoa, 22ko martxoaren 23tik 2019ra bitartean konpromisoa hartu zuen. Hori da duela ia lau hilabete. Izan ere, kanpoko aholkularien laguntzarekin bakarrik jakin ahal izan zuen Capital Onek zerbait gertatu zela.
Amazoneko langile ohi bat atxilotu zuten eta 250 dolar isuna eta bost urteko kartzela zigorra jaso behar ditu... baina oraindik ezezko asko geratzen da. Zergatik? Hackeak pairatu dituzten enpresa asko beren azpiegiturak eta aplikazioak indartzeko ardura kentzen saiatzen ari direlako ziberdelituaren gorakadaren artean.
Dena den, istorio hau erraz Googlen bila dezakezu. Ez gara draman sartuko, baizik eta hitz egingo dugu teknikoa kontuaren alde.
Lehenik eta behin, zer gertatu zen?
Capital One-k 700 S3 ontzi inguru zituen martxan, eta Paige Thompson-ek kopiatu eta desegin zuen.
Bigarrenik, gaizki konfiguratutako S3 kubo politikaren beste kasu bat al da?
Ez, oraingoan ez. Hemen gaizki konfiguratutako suebakia zuen zerbitzari batera atzitu zuen eta hortik egin zuen eragiketa osoa.
Itxaron, nola da posible hori?
Tira, has gaitezen zerbitzarian saioa hasten, nahiz eta xehetasun asko ez ditugun. "Gaizki konfiguratutako suebaki baten bidez" gertatu zela soilik esan ziguten. Beraz, segurtasun taldeen ezarpen okerrak edo web aplikazioen suebakiaren konfigurazioa (Imperva) edo sareko suebakia (iptables, ufw, shorewall, etab.) bezain sinplea. Capital Onek bere errua onartu zuen eta zuloa itxi zuela esan zuen.
Stonek esan zuen Capital Onek ez zuela hasiera batean suebakiaren ahultasuna nabaritu, baina azkar jokatu zuen horretaz jabetu zenean. Horrek, zalantzarik gabe, hackerrak domeinu publikoan identifikatzeko gako informazioa utzi izanak lagundu zuen, Stonek esan zuen.
Galdetzen bazara zergatik ez dugun zati honetan sakontzen, mesedez, ulertu informazio mugatua dela eta espekulatu baino ezin dugula egin. Horrek ez du zentzurik hack-a Capital Onek utzitako zulo baten mende zegoela kontuan hartuta. Eta gehiago esaten ez digutenean, Capital Onek zerbitzaria irekita utzi duen modu posible guztiak zerrendatuko ditugu, norbaitek aukera ezberdin hauetako bat erabiltzeko modu posible guztiekin batera. Akats eta teknika hauek gainbegiratze ergeletatik hasi eta eredu izugarri konplexuetaraino izan daitezke. Aukera sorta ikusita, benetako ondoriorik gabeko saga luze bat bihurtuko da hau. Hori dela eta, zentratu gaitezen gertakariak ditugun zatia aztertzen.
Beraz, lehen esana: jakitea zure suebakiek zer onartzen duten.
Ireki behar dena BAKARRIK irekitzen dela ziurtatzeko politika edo prozesu egoki bat ezarri. Segurtasun Taldeak edo Sareko ACLak bezalako AWS baliabideak erabiltzen ari bazara, jakina da ikuskatzeko zerrenda luzea izan daitekeela... baina baliabide asko automatikoki sortzen diren bezala (hau da, CloudFormation), haien auditoretzak automatizatzea ere posible da. Etxeko script bat den, objektu berriak akatsen bila aztertzen dituena, edo CI/CD prozesu batean segurtasun-ikuskaritza bezalako zerbait... aukera erraz asko daude hori saihesteko.
Istorioaren zati "dibertigarria" da Capital Onek zuloa lehenik eta behin tapatu izan balu... ez zela ezer gertatuko. Eta beraz, egia esanda, beti da harrigarria nola zerbait benetan ikustea nahiko sinplea enpresa bat hackeatzeko arrazoi bakarra bihurtzen da. Batez ere Capital One bezain handia.
Beraz, hacker barruan - zer gertatu da gero?
Beno, EC2 instantzia batean sartu ondoren... asko oker egin daiteke. Ia aizto baten ertzean ibiltzen zara norbait horren urrun joaten uzten badiozu. Baina nola sartu zen S3 kuboetan? Hau ulertzeko, eztabaida ditzagun IAM Rolak.
Beraz, AWS zerbitzuetara sartzeko modu bat Erabiltzailea izatea da. Ados, hau nahiko argia da. Baina zer gertatzen da beste AWS zerbitzu batzuei, hala nola zure aplikazio zerbitzariei, zure S3 kuboetarako sarbidea eman nahi badiozu? Horretarako dira IAM rolak. Bi osagaiz osatuta daude:
- Konfiantza-politika - zer zerbitzu edo pertsonek erabil dezakete rol hau?
- Baimen-gidalerroak - Zer onartzen du rol honek?
Adibidez, IAM rol bat sortu nahi duzu, EC2 instantziei S3 ontzi batera sartzeko aukera emango diena: Lehenik eta behin, rolak EC2 (zerbitzu osoa) edo instantzia zehatzek rola "hartu" dezaketen konfiantza-politika bat izan dezan ezartzen da. Rol bat onartzeak esan nahi du rolaren baimenak erabil ditzaketela ekintzak egiteko. Bigarrenik, Baimenen Politikak "rola hartu" duen zerbitzu/pertsona/baliabideari aukera ematen dio S3-n edozein gauza egiteko, dela ontzi zehatz batean sartu... edo 700etik gora, Capital One-ren kasuan bezala.
IAM rola duen EC2 instantzia batean zaudenean, hainbat modutara lor ditzakezu kredentzialak:
- Instantziaren metadatuak hemen eska ditzakezu
http://169.254.169.254/latest/meta-dataBesteak beste, helbide honetan sarbide-gakoren batekin IAM rola aurki dezakezu. Jakina, instantzia batean bazaude bakarrik.
- Erabili AWS CLI...
AWS CLI instalatuta badago, IAM roletako kredentzialekin kargatuko da, baldin badago. Instantziaren BIDEZ lan egitea besterik ez da geratzen. Noski, beren konfiantza-politika irekita balego, Paigek dena egin zezakeen zuzenean.
Beraz, IAM rolen funtsa baliabide batzuk ZURE IZENEAN BESTE BALIABIDEETAN jarduteko aukera ematen dutela da.
IAMren rolak ulertzen dituzunean, Paige Thompson-ek egin zuenari buruz hitz egin dezakegu:
- Suebakiko zulo baten bidez zerbitzarirako sarbidea lortu zuen (EC2 instantzia).
Segurtasun-taldeak/ACLak edo beren web aplikazioen suebakiak izan, zuloa nahiko erraza izango zen ziurrenik, erregistro ofizialetan esaten den moduan.
- Behin zerbitzarian sartuta, zerbitzaria bera izango balitz bezala jokatu ahal izan zuen
- IAM zerbitzariaren rolak S3ri 700 ontzi baino gehiago atzitzeko aukera ematen zionez, haietara atzitu ahal izan zuen
Une horretatik aurrera, agindua exekutatu besterik ez zuen egin behar List Bucketseta gero komandoa Sync AWS CLI-tik...
. Horrelako kalteak saihestea, horregatik, enpresek hainbeste inbertitzen dute hodeiko azpiegituren babesean, DevOps eta segurtasun adituetan. Eta nola baliotsua eta kostu-eraginkorra da hodeira pasatzea? Hainbeste, zibersegurtasun gero eta erronka gehiagoren aurrean ere !
Istorioaren morala: egiaztatu zure segurtasuna; Aldizkako auditoriak egitea; Segurtasun politiketarako pribilegio txikienaren printzipioa errespetatu.
( Txosten juridiko osoa ikus dezakezu).
Iturria: www.habr.com