ProHoster > Blogs > Administrācija > Tehniskā informācija par Capital One uzlauÅ”anu vietnē AWS

Tehniskā informācija par Capital One uzlauÅ”anu vietnē AWS

Tehniskā informācija par Capital One uzlauÅ”anu vietnē AWS

19. gada 2019. jÅ«lijā Capital One saņēma ziņojumu, no kura baidās katrs mÅ«sdienu uzņēmums ā€” noticis datu pārkāpums. Tas skāra vairāk nekā 106 miljonus cilvēku. 140 000 ASV sociālās apdroÅ”ināŔanas numuru, viens miljons Kanādas sociālās apdroÅ”ināŔanas numuru. 80 000 bankas kontu. NepatÄ«kami, vai jÅ«s nepiekrÄ«tat?

Diemžēl uzlauÅ”ana nenotika 19. jÅ«lijā. Kā izrādās, Peidža Tompsone, a.k.a. NepastāvÄ«gs, izdarÄ«ja to laikā no 22. gada 23. marta lÄ«dz 2019. martam. Tas ir gandrÄ«z pirms četriem mēneÅ”iem. Faktiski tikai ar ārējo konsultantu palÄ«dzÄ«bu Capital One varēja atklāt, ka kaut kas ir noticis.

BijuÅ”ais Amazon darbinieks tika arestēts, un viņam draud 250 XNUMX USD naudas sods un piecu gadu cietumsods... bet joprojām ir palicis daudz negatÄ«visma. Kāpēc? Tā kā daudzi uzņēmumi, kas cietuÅ”i no uzlauÅ”anas, cenÅ”as novilkt plecus no atbildÄ«bas par savas infrastruktÅ«ras un lietojumprogrammu stiprināŔanu, pieaugot kibernoziedzÄ«bai.

Jebkurā gadÄ«jumā jÅ«s varat viegli googlēt Å”o stāstu. Mēs neiedziļināsimies drāmā, bet runāsim par to tehnisks lietas puse.

Pirmkārt, kas notika?

Capital One darbojās aptuveni 700 S3 kausu, kurus Peidža Tompsone nokopēja un izsÅ«ka.

Otrkārt, vai Å”is ir vēl viens nepareizi konfigurētas S3 segmenta politikas gadÄ«jums?

Nē, Å”oreiz ne. Å eit viņa ieguva piekļuvi serverim ar nepareizi konfigurētu ugunsmÅ«ri un no turienes veica visu darbÄ«bu.

Pagaidiet, kā tas ir iespējams?

Nu, sāksim ar pieteikÅ”anos serverÄ«, lai gan mums nav daudz detaļu. Mums tikai teica, ka tas notika, izmantojot "nepareizi konfigurētu ugunsmÅ«ri". Tātad, kaut kas tik vienkārÅ”s kā nepareizi droŔības grupas iestatÄ«jumi vai tÄ«mekļa lietojumprogrammas ugunsmÅ«ra (Imperva) vai tÄ«kla ugunsmÅ«ra (iptables, ufw, shorewall utt.) konfigurācija. Capital One tikai atzina savu vainu un paziņoja, ka ir aizvērusi caurumu.

Stouns sacÄ«ja, ka Capital One sākotnēji nepamanÄ«ja ugunsmÅ«ra ievainojamÄ«bu, taču rÄ«kojās ātri, tiklÄ«dz par to uzzināja. To noteikti veicināja fakts, ka hakeris, iespējams, atstāja atslēgu identificējoÅ”o informāciju publiskajā telpā, sacÄ«ja Stouns.

Ja jums rodas jautājums, kāpēc mēs neiedziļināmies Å”ajā daļā, lÅ«dzu, saprotiet, ka ierobežotās informācijas dēļ mēs varam tikai spekulēt. Tam nav jēgas, ņemot vērā, ka uzlauÅ”ana bija atkarÄ«ga no Capital One atstātās bedres. Un, ja vien viņi mums nepateiks vairāk, mēs tikai uzskaitÄ«sim visus iespējamos veidus, kā Capital One atstāja savu serveri atvērtu, kā arÄ« visus iespējamos veidus, kā kāds varētu izmantot kādu no Ŕīm dažādajām iespējām. Å Ä«s nepilnÄ«bas un paņēmieni var bÅ«t no mežonÄ«gi muļķīgiem pārkāpumiem lÄ«dz neticami sarežģītiem modeļiem. Ņemot vērā daudzās iespējas, tā kļūs par garu sāgu bez Ä«stiem secinājumiem. Tāpēc koncentrēsimies uz tās daļas analÄ«zi, kurā mums ir fakti.

Tātad pirmais ir: ziniet, ko pieļauj jūsu ugunsmūri.

Izveidojiet politiku vai atbilstoÅ”u procesu, lai nodroÅ”inātu, ka tiek atvērts TIKAI tas, kas ir jāatver. Ja izmantojat AWS resursus, piemēram, droŔības grupas vai tÄ«kla ACL, acÄ«mredzot audita kontrolsaraksts var bÅ«t garÅ”... taču tāpat kā daudzi resursi tiek izveidoti automātiski (t.i., CloudFormation), ir iespējams arÄ« automatizēt to auditÄ“Å”anu. NeatkarÄ«gi no tā, vai tas ir paÅ”taisÄ«ts skripts, kas skenē jaunus objektus, lai atrastu trÅ«kumus, vai kaut kas lÄ«dzÄ«gs droŔības auditam CI/CD procesā... ir daudz vienkārÅ”u iespēju, kā no tā izvairÄ«ties.

Stāsta "smieklÄ«gā" daļa ir tāda, ka, ja Capital One vispirms bÅ«tu aizbāzis caurumu... nekas nebÅ«tu noticis. Un tā, atklāti sakot, vienmēr ir Å”okējoÅ”i redzēt, kā kaut kas Ä«sti notiek diezgan vienkārÅ”i kļūst par vienÄ«go iemeslu uzņēmuma uzlauÅ”anai. ÄŖpaÅ”i tik liela kā Capital One.

Tātad, hakeris iekŔā - kas notika tālāk?

Nu, pēc iebrukuma EC2 instancē... daudz kas var noiet greizi. Tu praktiski ej uz naža asmens, ja ļauj kādam aiziet tik tālu. Bet kā tas nokļuva S3 spaiņos? Lai to saprastu, apspriedīsim IAM lomas.

Tātad viens no veidiem, kā piekļūt AWS pakalpojumiem, ir bÅ«t lietotājam. Labi, Å”is ir diezgan acÄ«mredzams. Bet ko darÄ«t, ja vēlaties pieŔķirt citiem AWS pakalpojumiem, piemēram, lietojumprogrammu serveriem, piekļuvi saviem S3 segmentiem? Tam ir paredzētas IAM lomas. Tie sastāv no divām sastāvdaļām:

  1. UzticÄ«bas politika ā€” kādi pakalpojumi vai cilvēki var izmantot Å”o lomu?
  2. Atļauju politika ā€” ko Ŕī loma atļauj?

Piemēram, vēlaties izveidot IAM lomu, kas ļaus EC2 gadÄ«jumiem piekļūt S3 segmentam. Pirmkārt, lomai ir iestatÄ«ta uzticamÄ«bas politika, ar kuru EC2 (viss pakalpojums) vai konkrēti gadÄ«jumi var ā€œpārņemtā€ lomu. Lomas pieņemÅ”ana nozÄ«mē, ka viņi var izmantot lomas atļaujas darbÄ«bu veikÅ”anai. Otrkārt, atļauju politika ļauj pakalpojumam/personai/resursam, kas ir ā€œuzņēmis lomuā€, S3 darÄ«t jebko, neatkarÄ«gi no tā, vai tā ir piekļuve vienam noteiktam segmentam... vai vairāk nekā 700, kā tas ir Capital One gadÄ«jumā.

Kad esat EC2 instancē ar IAM lomu, varat iegūt akreditācijas datus vairākos veidos.

  1. Instanču metadatus varat pieprasīt vietnē http://169.254.169.254/latest/meta-data

    Cita starpā Å”ajā adresē varat atrast IAM lomu ar jebkuru no piekļuves atslēgām. Protams, tikai tad, ja atrodaties instancē.

  2. Izmantojiet AWS CLI...

    Ja AWS CLI ir instalēts, tas tiek ielādēts ar akreditācijas datiem no IAM lomām, ja tādas ir. Atliek tikai strādāt, izmantojot instanci. Protams, ja viņu uzticÄ«bas politika bÅ«tu atvērta, Peidža varētu darÄ«t visu tieÅ”i.

Tātad IAM lomu bÅ«tÄ«ba ir tāda, ka tās ļauj dažiem resursiem rÄ«koties JÅŖSU VĀRDĀ CITI RESURSI.

Tagad, kad jūs saprotat IAM lomas, mēs varam runāt par to, ko darīja Peidža Tompsone:

  1. Viņa ieguva piekļuvi serverim (EC2 instance) caur caurumu ugunsmūrī

    NeatkarÄ«gi no tā, vai tās bija droŔības grupas/ACL vai viņu paÅ”u tÄ«mekļa lietojumprogrammu ugunsmÅ«ri, caurumu droÅ”i vien bija diezgan viegli aizbāzt, kā norādÄ«ts oficiālajos ierakstos.

  2. Nokļuvusi serverī, viņa varēja rīkoties tā, it kā būtu pati servera
  3. Tā kā IAM servera loma ļāva S3 piekļūt Å”iem 700+ spaiņiem, tas varēja tiem piekļūt

No Ŕī brīža viņai atlika tikai izpildÄ«t komandu List Bucketsun tad komanda Sync no AWS CLI...

Capital One Bank lÄ“Å”, ka uzlauÅ”anas radÄ«tie zaudējumi ir no 100 lÄ«dz 150 MILJONIEM USD. Šādu bojājumu novērÅ”ana ir iemesls, kāpēc uzņēmumi tik daudz iegulda mākoņa infrastruktÅ«ras aizsardzÄ«bā, DevOps un droŔības ekspertos. Un cik vērtÄ«ga un rentabla ir pāreja uz mākoni? Tik daudz, ka pat saskaroties ar arvien vairāk kiberdroŔības izaicinājumiem Kopējais publisko mākoņu tirgus 42. gada pirmajā ceturksnÄ« pieauga par 2019%.!

Stāsta morāle: pārbaudiet savu droŔību; Regulāri veikt auditus; DroŔības politikā ievērojiet vismazāko privilēģiju principu.

(Šeit Jūs varat apskatīt pilnu juridisko ziņojumu).

Avots: www.habr.com

Pievieno komentāru