La 19-an de julio 2019, Capital One ricevis la mesaĝon, ke ĉiu moderna kompanio timas—datumrompo okazis. Ĝi tuŝis pli ol 106 milionojn da homoj. 140 usonaj socialasekuraj numeroj, unu miliono kanadaj socialasekuraj numeroj. 000 bankkontoj. Malagrabla, ĉu vi ne konsentas?
Bedaŭrinde, la hako ne okazis la 19-an de julio. Kiel ĝi turnas, Paige Thompson, a.k. Erara, faris ĝin inter la 22-a de marto kaj la 23-a de marto 2019. Tio estas antaŭ preskaŭ kvar monatoj. Fakte, nur kun la helpo de eksteraj konsultistoj Capital One povis malkovri, ke io okazis.
Iama Amazon-dungito estis arestita kaj alfrontas monpunon de 250 XNUMX USD kaj kvin jarojn da malliberejo... sed ankoraŭ restas multe da negativeco. Kial? Ĉar multaj kompanioj, kiuj suferis de hakoj, provas forigi la respondecon plifortigi siajn infrastrukturojn kaj aplikojn meze de la pliiĝo de ciberkrimoj.
Ĉiuokaze, vi povas facile gugloĉi tiun ĉi rakonton. Ni ne eniros en dramon, sed priparolos teknika flanko de la afero.
Antaŭ ĉio, kio okazis?
Capital One havis proksimume 700 S3 sitelojn kurantajn, kiujn Paige Thompson kopiis kaj forflugis.
Due, ĉu ĉi tio estas alia kazo de misagordita S3-sitelo-politiko?
Ne, ĉi-foje ne. Ĉi tie ŝi akiris aliron al servilo kun malĝuste agordita fajroŝirmilo kaj efektivigis la tutan operacion de tie.
Atendu, kiel tio eblas?
Nu, ni komencu ensaluti en la servilon, kvankam ni ne havas multajn detalojn. Oni diris al ni nur, ke ĝi okazis per "misagordita fajroŝirmilo". Do, io tiel simpla kiel malĝustaj sekurecaj grupaj agordoj aŭ agordo de la ret-aplikaĵa fajroŝirmilo (Imperva), aŭ reta fajroŝirmilo (iptables, ufw, shorewall, ktp.). Capital One nur konfesis sian kulpon kaj diris, ke ĝi fermis la truon.
Ŝtono diris, ke Capital One komence ne rimarkis la vundeblecon de fajroŝirmilo sed agis rapide post kiam ĝi konsciis pri ĝi. Ĉi tio certe estis helpita de la fakto, ke la retpirato supozeble lasis ŝlosilajn identigajn informojn en la publika domeno, Stone diris.
Se vi scivolas, kial ni ne profundigas ĉi tiun parton, bonvolu kompreni, ke pro limigita informo ni povas nur konjekti. Ĉi tio ne havas sencon pro tio, ke la hako dependis de truo lasita de Capital One. Kaj krom se ili diros al ni pli, ni simple listigos ĉiujn eblajn manierojn, kiel Capital One lasis sian servilon malfermita kombine kun ĉiuj eblaj manieroj, kiel iu povus uzi unu el ĉi tiuj malsamaj opcioj. Ĉi tiuj difektoj kaj teknikoj povas varii de sovaĝe stultaj malatentoj ĝis nekredeble kompleksaj ŝablonoj. Konsiderante la gamon da eblecoj, ĉi tio fariĝos longa sagao sen reala konkludo. Tial ni koncentriĝu pri analizado de la parto, kie ni havas faktojn.
Do la unua preskribo estas: sciu, kion permesas viaj fajroŝirmiloj.
Establi politikon aŭ taŭgan procezon por certigi, ke NUR kio devas esti malfermita estas malfermita. Se vi uzas AWS-rimedojn kiel Sekurecaj Grupoj aŭ Retaj ACL-oj, evidente la kontrola listo povas esti longa... sed same kiel multaj rimedoj estas kreitaj aŭtomate (t.e. CloudFormation), ankaŭ eblas aŭtomatigi ilian revizion. Ĉu ĝi estas memfarita skripto, kiu skanas novajn objektojn por difektoj, aŭ io kiel sekureca revizio en CI/KD-procezo... ekzistas multaj facilaj elektoj por eviti ĉi tion.
La "amuza" parto de la rakonto estas ke se Capital One estus ŝtopinta la truon en la unua loko... nenio estus okazinta. Kaj do, sincere, ĉiam estas ŝoke vidi kiel io vere sufiĉe simpla fariĝas la sola kialo por ke kompanio estas hakita. Precipe unu tiel granda kiel Capital One.
Do, retpirato interne - kio okazis poste?
Nu, post enrompo en EC2-instanco... multe povas misfunkcii. Vi preskaŭ marŝas sur tranĉrando, se vi lasas iun iri tiom malproksimen. Sed kiel ĝi eniris S3-sitelojn? Por kompreni ĉi tion, ni diskutu IAM-Rolojn.
Do, unu maniero aliri AWS-servojn estas esti Uzanto. Bone, ĉi tiu estas sufiĉe evidenta. Sed kio se vi volas doni aliajn AWS-servojn, kiel viajn aplikaĵservilojn, aliron al viaj S3-siteloj? Por tio estas IAM-roloj. Ili konsistas el du komponantoj:
- Fidopolitiko - kiaj servoj aŭ homoj povas uzi ĉi tiun rolon?
- Permesaj Politiko - kion ĉi tiu rolo permesas?
Ekzemple, vi volas krei IAM-rolon, kiu permesos al EC2-instancoj aliri S3-sitelon: Unue, la rolo estas agordita por havi Fidopolitikon, kiun EC2 (la tuta servo) aŭ specifaj okazoj povas "transpreni" la rolon. Akcepti rolon signifas, ke ili povas uzi la permesojn de la rolo por plenumi agojn. Due, la Permesa Politiko permesas al la servo/persono/rimedo, kiu "prenis la rolon" fari ion ajn sur S3, ĉu ĝi aliru unu specifan sitelon... aŭ pli ol 700, kiel en la kazo de Capital One.
Post kiam vi estas en EC2-instanco kun la IAM-rolo, vi povas akiri akreditaĵojn en pluraj manieroj:
- Vi povas peti metadatumojn ĉe
http://169.254.169.254/latest/meta-dataInteralie, vi povas trovi la IAM-rolon kun iu ajn el la alirŝlosiloj ĉe ĉi tiu adreso. Kompreneble, nur se vi estas en kazo.
- Uzu AWS CLI...
Se la AWS CLI estas instalita, ĝi estas ŝarĝita kun akreditaĵoj de la IAM-roloj, se ĉeestas. Restas nur labori TRA la petskribo. Kompreneble, se ilia Fidopolitiko estis malfermita, Paige povus fari ĉion rekte.
Do la esenco de IAM-roloj estas, ke ili permesas iujn rimedojn agi EN VIA NOMO pri ALIAJ RIMEDOJ.
Nun kiam vi komprenas la rolojn de IAM, ni povas paroli pri tio, kion faris Paige Thompson:
- Ŝi akiris aliron al la servilo (EC2-instanco) tra truo en la fajroŝirmilo
Ĉu ĝi estis sekurecaj grupoj/ACL-oj aŭ siaj propraj ret-aplikaĵaj fajroŝirmiloj, la truo verŝajne estis sufiĉe facile ŝtopebla, kiel deklarite en la oficialaj registroj.
- Unufoje sur la servilo, ŝi povis agi "kvazaŭ" ŝi mem estus la servilo
- Ĉar la rolo de IAM-servilo permesis al S3-aliro al ĉi tiuj 700+ siteloj, ĝi povis aliri ilin.
Ekde tiu momento ŝi nur devis fari la komandon List Bucketskaj poste la ordono Sync de AWS CLI...
. Malhelpi tian damaĝon estas kial kompanioj tiom investas en nuba infrastruktura protekto, DevOps kaj sekurecaj fakuloj. Kaj kiom valora kaj kostefika estas moviĝado al la nubo? Tiom, ke eĉ antaŭ pli kaj pli da cibersekurecaj defioj !
Moralo de la rakonto: kontrolu vian sekurecon; Faru regulajn reviziojn; Respektu la principon de plej malgranda privilegio por sekurecaj politikoj.
( Vi povas vidi la plenan juran raporton).
fonto: www.habr.com