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:
- Uzticības politika — kādi pakalpojumi vai cilvēki var izmantot šo lomu?
- 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.
- Instanču metadatus varat pieprasīt vietnē
http://169.254.169.254/latest/meta-dataCita starpā šajā adresē varat atrast IAM lomu ar jebkuru no piekļuves atslēgām. Protams, tikai tad, ja atrodaties instancē.
- 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:
- 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.
- Nokļuvusi serverī, viņa varēja rīkoties tā, it kā būtu pati servera
- 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...
. Šā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 !
Stāsta morāle: pārbaudiet savu drošību; Regulāri veikt auditus; Drošības politikā ievērojiet vismazāko privilēģiju principu.
( Jūs varat apskatīt pilnu juridisko ziņojumu).
Avots: www.habr.com