19 m. liepos 2019 d. „Capital One“ gavo pranešimą, kurio baiminasi kiekviena šiuolaikinė įmonė: įvyko duomenų nutekėjimas. Tai paveikė daugiau nei 106 milijonus žmonių. 140 000 JAV socialinio draudimo numerių, vienas milijonas Kanados socialinio draudimo numerių. 80 000 banko sąskaitų. Nemalonu, ar nesutinkate?
Deja, įsilaužimas neįvyko liepos 19 d. Kaip paaiškėjo, Paige Thompson, dar žinomas kaip Nepastovus, padarė tai nuo 22 m. kovo 23 d. iki kovo 2019 d. Tai yra beveik prieš keturis mėnesius. Tiesą sakant, tik padedant išorės konsultantams „Capital One“ pavyko sužinoti, kad kažkas atsitiko.
Buvęs „Amazon“ darbuotojas buvo areštuotas, jam gresia 250 XNUMX USD bauda ir penkeri metai kalėjimo... tačiau vis dar liko daug negatyvo. Kodėl? Kadangi daugelis įmonių, nukentėjusių nuo įsilaužimų, bando nusimesti atsakomybę už savo infrastruktūros ir taikomųjų programų stiprinimą, augant kibernetiniams nusikaltimams.
Šiaip ar taip, šią istoriją galite lengvai paieškoti „Google“. Mes nesileisime į dramą, o kalbėsime apie tai techninis reikalo pusė.
Visų pirma, kas atsitiko?
„Capital One“ turėjo apie 700 S3 kibirų, kuriuos Paige Thompson nukopijavo ir išsiurbė.
Antra, ar tai dar vienas netinkamai sukonfigūruotos S3 segmento politikos atvejis?
Ne, ne šį kartą. Čia ji gavo prieigą prie serverio su netinkamai sukonfigūruota užkarda ir iš ten atliko visą operaciją.
Palauk, kaip tai įmanoma?
Na, pradėkime nuo prisijungimo prie serverio, nors mes neturime daug informacijos. Mums buvo tik pasakyta, kad tai įvyko per „netinkamai sukonfigūruotą ugniasienę“. Taigi, kažkas tokio paprasto, kaip neteisingi saugos grupės nustatymai arba žiniatinklio programos ugniasienės (Imperva) arba tinklo ugniasienės (iptables, ufw, shorewall ir kt.) konfigūracija. „Capital One“ tik pripažino savo kaltę ir pasakė, kad užvertė skylę.
Stone'as teigė, kad „Capital One“ iš pradžių nepastebėjo ugniasienės pažeidžiamumo, bet ėmėsi greitai, kai apie tai sužinojo. Tai tikrai padėjo tai, kad įsilaužėlis tariamai paliko raktinę identifikavimo informaciją viešoje erdvėje, sakė Stone.
Jei jums įdomu, kodėl mes nesigilinome į šią dalį, supraskite, kad dėl ribotos informacijos galime tik spėlioti. Tai neturi prasmės, nes įsilaužimas priklausė nuo „Capital One“ paliktos skylės. Ir jei jie nepasakys daugiau, mes tiesiog išvardysime visus galimus būdus, kaip „Capital One“ paliko savo serverį atidarytą, kartu su visais įmanomais būdais, kuriais kas nors galėtų pasinaudoti viena iš šių skirtingų parinkčių. Šie trūkumai ir metodai gali svyruoti nuo beprotiškai kvailų klaidų iki neįtikėtinai sudėtingų modelių. Atsižvelgiant į daugybę galimybių, tai taps ilga saga be jokios realios išvados. Todėl sutelkime dėmesį į tos dalies, kurioje turime faktus, analizę.
Taigi pirmas dalykas yra toks: žinokite, ką leidžia jūsų užkardos.
Nustatykite politiką arba tinkamą procesą, kad užtikrintumėte, jog atidaroma TIK tai, ką reikia atidaryti. Jei naudojate AWS išteklius, pvz., saugos grupes ar tinklo ACL, akivaizdu, kad tikrinamas kontrolinis sąrašas gali būti ilgas... bet kaip ir daugelis išteklių sukuriami automatiškai (pvz., CloudFormation), taip pat galima automatizuoti jų auditą. Nesvarbu, ar tai naminis scenarijus, nuskaitantis naujus objektus, ar nėra trūkumų, ar kažkas panašaus į saugos auditą CI/CD procese... yra daug paprastų variantų, kaip to išvengti.
„Juokingoji“ istorijos dalis ta, kad jei „Capital One“ būtų užkimšęs skylę iš pradžių... nieko nebūtų nutikę. Taigi, atvirai kalbant, visada šokiruoja, kaip kažkas iš tikrųjų gana paprasta tampa vienintele priežastimi įsilaužti į įmonę. Ypač tokio dydžio kaip „Capital One“.
Taigi, įsilaužėlis viduje – kas nutiko toliau?
Na, įsilaužus į EC2 egzempliorių... daug kas gali suklysti. Jūs praktiškai einate ant peilio ašmens, jei leidžiate kam nors taip toli. Bet kaip jis pateko į S3 kibirus? Norėdami tai suprasti, aptarkime IAM vaidmenis.
Taigi vienas iš būdų pasiekti AWS paslaugas yra būti vartotoju. Gerai, tai gana akivaizdu. Bet ką daryti, jei norite suteikti kitoms AWS paslaugoms, pvz., programų serveriams, prieigą prie savo S3 segmentų? Tam yra skirti IAM vaidmenys. Jie susideda iš dviejų komponentų:
- Pasitikėjimo politika – kokios tarnybos ar žmonės gali naudoti šį vaidmenį?
- Leidimų politika – ką leidžia šis vaidmuo?
Pvz., norite sukurti IAM vaidmenį, kuris leis EC2 egzemplioriams pasiekti S3 segmentą: Pirma, vaidmuo nustatytas taip, kad būtų pasitikėjimo politika, pagal kurią EC2 (visa paslauga) arba konkretūs egzemplioriai gali „perimti“ vaidmenį. Vaidmens priėmimas reiškia, kad jie gali naudoti vaidmens leidimus veiksmams atlikti. Antra, leidimų politika leidžia tarnybai/asmeniui/ištekliui, kuris „atėmė vaidmenį“, daryti bet ką S3, nesvarbu, ar tai pasiekti vieną konkretų segmentą... ar daugiau nei 700, kaip „Capital One“ atveju.
Kai esate EC2 egzemplioriuje su IAM vaidmeniu, kredencialus galite gauti keliais būdais:
- Galite prašyti egzempliorių metaduomenų adresu
http://169.254.169.254/latest/meta-dataBe kitų dalykų, šiuo adresu galite rasti IAM vaidmenį su bet kuriuo prieigos raktu. Žinoma, tik tuo atveju, jei esate pavyzdyje.
- Naudokite AWS CLI...
Jei AWS CLI yra įdiegtas, jis įkeliamas su kredencialais iš IAM vaidmenų, jei yra. Belieka dirbti PER egzempliorių. Žinoma, jei jų pasitikėjimo politika būtų atvira, Paige galėtų viską daryti tiesiogiai.
Taigi IAM vaidmenų esmė yra ta, kad jie leidžia kai kuriems ištekliams veikti JŪSŲ VADOVAN KITIMS IŠTEKLIAIS.
Dabar, kai suprantate IAM vaidmenis, galime kalbėti apie tai, ką padarė Paige Thompson:
- Ji gavo prieigą prie serverio (EC2 egzempliorius) per ugniasienės skylę
Nesvarbu, ar tai buvo saugos grupės / ACL, ar jų pačių žiniatinklio programų ugniasienės, spragą tikriausiai buvo gana lengva užkimšti, kaip teigiama oficialiuose įrašuose.
- Patekusi į serverį, ji galėjo elgtis „tarsi“ pati būtų serveris
- Kadangi IAM serverio vaidmuo leido S3 pasiekti daugiau nei 700 kibirų, jis galėjo juos pasiekti
Nuo tos akimirkos jai tereikėjo vykdyti komandą List Bucketsir tada komanda Sync iš AWS CLI...
. Užkirsti kelią tokiai žalai, todėl įmonės tiek daug investuoja į debesų infrastruktūros apsaugą, „DevOps“ ir saugos ekspertus. Ir kiek vertingas ir ekonomiškas perėjimas prie debesies? Tiek, kad net ir susidūrus su vis daugiau kibernetinio saugumo iššūkių !
Istorijos moralė: patikrinkite savo saugumą; Reguliariai atlikti auditą; Laikykitės mažiausiai privilegijų saugumo politikos srityje.
( Galite peržiūrėti visą teisinę ataskaitą).
Šaltinis: www.habr.com