Þann 19. júlí 2019 fékk Capital One þau skilaboð sem hvert nútímafyrirtæki óttast - gagnabrot átti sér stað. Það hafði áhrif á meira en 106 milljónir manna. 140 bandarísk kennitölur, ein milljón kanadískar kennitölur. 000 bankareikninga. Óþægilegt, ertu ekki sammála?
Því miður átti hakkið ekki sér stað þann 19. júlí. Eins og það kemur í ljós, Paige Thompson, a.m.k. Óreglulegur, framdi það á milli 22. mars og 23. mars 2019. Það er fyrir tæpum fjórum mánuðum. Reyndar var það aðeins með aðstoð utanaðkomandi ráðgjafa sem Capital One gat uppgötvað að eitthvað hefði gerst.
Fyrrum starfsmaður Amazon var handtekinn og á yfir höfði sér 250 dollara sekt og fimm ára fangelsi... en það er enn mikil neikvæðni eftir. Hvers vegna? Vegna þess að mörg fyrirtæki sem hafa orðið fyrir tölvuárásum eru að reyna að hlaupa frá sér ábyrgðina á að styrkja innviði sína og forrit innan um aukningu á netglæpum.
Allavega, þú getur auðveldlega googlað þessa sögu. Við förum ekki í leiklist heldur tölum um tæknilegt hlið málsins.
Í fyrsta lagi, hvað gerðist?
Capital One var með um 700 S3 fötur í gangi, sem Paige Thompson afritaði og saumaði af.
Í öðru lagi, er þetta annað tilfelli af rangstilltri S3 fötustefnu?
Nei, ekki í þetta skiptið. Hér fékk hún aðgang að netþjóni með rangt stilltan eldvegg og framkvæmdi alla aðgerðina þaðan.
Bíddu, hvernig er það hægt?
Jæja, við skulum byrja á því að skrá okkur inn á netþjóninn, þó við höfum ekki margar upplýsingar. Okkur var aðeins sagt að það gerðist í gegnum „rangstilltan eldvegg. Svo, eitthvað eins einfalt og rangar öryggishópastillingar eða uppsetning á eldvegg vefforritsins (Imperva), eða neteldvegg (iptables, ufw, shorewall, osfrv.). Capital One viðurkenndi aðeins sekt sína og sagðist hafa lokað gatinu.
Stone sagði að Capital One hafi í upphafi ekki tekið eftir veikleika eldveggsins en brugðist hratt við þegar það varð meðvitað um það. Þetta var vissulega hjálpað af þeirri staðreynd að tölvuþrjóturinn sagðist hafa skilið eftir helstu auðkennandi upplýsingar á almenningi, sagði Stone.
Ef þú ert að velta því fyrir þér hvers vegna við erum ekki að fara dýpra í þennan hluta, vinsamlegast skildu að vegna takmarkaðra upplýsinga getum við aðeins getgátur. Þetta þýðir ekkert í ljósi þess að hakkið var háð holu sem Capital One skildi eftir. Og nema þeir segi okkur meira, munum við bara skrá allar mögulegar leiðir sem Capital One skildi eftir opinn netþjón ásamt öllum mögulegum leiðum sem einhver gæti notað einn af þessum mismunandi valkostum. Þessir gallar og tækni geta verið allt frá ótrúlega heimskulegum yfirsjónum yfir í ótrúlega flókið mynstur. Miðað við fjölda möguleika mun þetta verða löng saga án raunverulegrar niðurstöðu. Þess vegna skulum við einbeita okkur að því að greina þann hluta þar sem við höfum staðreyndir.
Þannig að fyrsta atriðið er: veistu hvað eldveggirnir þínir leyfa.
Komdu á stefnu eða réttu ferli til að tryggja að AÐEINS það sem þarf að opna sé opnað. Ef þú ert að nota AWS tilföng eins og öryggishópa eða netkerfi ACL, þá getur gátlistinn til að endurskoða augljóslega verið langur... en rétt eins og mörg tilföng eru búin til sjálfkrafa (þ.e. CloudFormation), þá er líka hægt að gera endurskoðun þeirra sjálfvirkan. Hvort sem það er heimatilbúið handrit sem skannar nýja hluti fyrir galla, eða eitthvað eins og öryggisúttekt í CI/CD ferli... þá eru margir auðveldir möguleikar til að forðast þetta.
Það "fyndinlega" í sögunni er að ef Capital One hefði stíflað gatið í fyrsta lagi... hefði ekkert gerst. Og svo, satt að segja, það er alltaf átakanlegt að sjá hvernig eitthvað raunverulega frekar einfalt verður eina ástæðan fyrir því að fyrirtæki er brotist inn. Sérstaklega einn eins stór og Capital One.
Svo, tölvuþrjótur inni - hvað gerðist næst?
Jæja, eftir að hafa brotist inn í EC2 dæmi... getur margt farið úrskeiðis. Þú ert nánast að ganga á hnífsegg ef þú lætur einhvern fara svona langt. En hvernig komst það í S3 fötu? Til að skilja þetta skulum við ræða IAM hlutverk.
Svo, ein leið til að fá aðgang að AWS þjónustu er að vera notandi. Allt í lagi, þetta er nokkuð augljóst. En hvað ef þú vilt veita annarri AWS þjónustu, eins og forritaþjónum þínum, aðgang að S3 fötunum þínum? Til þess eru hlutverk IAM. Þau samanstanda af tveimur hlutum:
- Trauststefna - hvaða þjónustur eða fólk getur notað þetta hlutverk?
- Heimildastefna - hvað leyfir þetta hlutverk?
Til dæmis, þú vilt búa til IAM hlutverk sem mun leyfa EC2 tilvikum að fá aðgang að S3 fötu: Í fyrsta lagi er hlutverkið stillt til að hafa trauststefnu sem EC2 (öll þjónustan) eða tiltekin tilvik geti „tekið yfir“ hlutverkið. Að samþykkja hlutverk þýðir að þeir geta notað heimildir hlutverksins til að framkvæma aðgerðir. Í öðru lagi leyfir leyfisstefnan þjónustunni/aðilanum/auðlindinni sem hefur „tekið hlutverkið“ að gera hvað sem er á S3, hvort sem það er að fá aðgang að einni tiltekinni fötu... eða yfir 700, eins og í tilfelli Capital One.
Þegar þú ert í EC2 tilviki með IAM hlutverkinu geturðu fengið skilríki á nokkra vegu:
- Þú getur beðið um lýsigögn tilviks á
http://169.254.169.254/latest/meta-dataMeðal annars er hægt að finna IAM hlutverkið með hvaða aðgangslykla sem er á þessu heimilisfangi. Auðvitað, aðeins ef þú ert í tilviki.
- Notaðu AWS CLI...
Ef AWS CLI er uppsett er það hlaðið með skilríkjum frá IAM hlutverkunum, ef það er til staðar. Það eina sem er eftir er að vinna í gegnum dæmið. Auðvitað, ef trauststefna þeirra væri opin, gæti Paige gert allt beint.
Þannig að kjarninn í IAM hlutverkum er að þau leyfa sumum auðlindum að bregðast við FYRIR ÞÍNA um AÐRAR Auðlindir.
Nú þegar þú skilur hlutverk IAM getum við talað um það sem Paige Thompson gerði:
- Hún fékk aðgang að þjóninum (EC2 dæmi) í gegnum gat á eldveggnum
Hvort sem það voru öryggishópar/ACL eða þeirra eigin eldveggir á vefforritum, þá var sennilega frekar auðvelt að stinga gatið, eins og fram kemur í opinberum skrám.
- Þegar hún var komin á netþjóninn gat hún hagað sér „eins og“ hún væri þjónninn sjálf
- Þar sem IAM miðlarahlutverkið leyfði S3 aðgang að þessum 700+ fötum, gat það fengið aðgang að þeim
Frá þeirri stundu var allt sem hún þurfti að gera að keyra skipunina List Bucketsog svo skipunin Sync frá AWS CLI...
. Að koma í veg fyrir slíkt tjón er ástæða þess að fyrirtæki fjárfesta svo mikið í verndun skýjainnviða, DevOps og öryggissérfræðingum. Og hversu dýrmætt og hagkvæmt er að flytja í skýið? Svo mikið að jafnvel í ljósi fleiri og fleiri áskorana um netöryggi !
Siðferði sögunnar: athugaðu öryggi þitt; Framkvæma reglulega úttektir; Virða meginregluna um minnstu forréttindi fyrir öryggisstefnu.
( Þú getur skoðað lagaskýrsluna í heild sinni).
Heimild: www.habr.com