U 19 di lugliu di u 2019, Capital One hà ricevutu u missaghju chì ogni cumpagnia muderna teme - una violazione di dati hè accaduta. Hà affettatu più di 106 milioni di persone. 140 000 numeri di securità suciale di i Stati Uniti, un milione di numeri di securità suciale canadiani. 80 cunti bancari. Dispiacevule, ùn site micca d'accordu ?
Sfurtunatamente, u pirate ùn hè micca accadutu u 19 di lugliu. Comu risulta, Paige Thompson, a.k.a. Erràticu, l'hà fattu trà u 22 di marzu è u 23 di marzu di u 2019. Hè quasi quattru mesi fà. In fatti, era solu cù l'aiutu di cunsultanti esterni chì Capital One hà sappiutu scopre chì qualcosa era accadutu.
Un anzianu impiegatu di Amazon hè statu arrestatu è face una multa di $ 250 è cinque anni di prigiò... ma ci hè sempre assai negatività. Perchè? Perchè parechje cumpagnie chì anu soffrenu di pirate, cercanu di scaccià a rispunsabilità di rinfurzà a so infrastruttura è l'applicazioni in mezzu à l'aumentu di a cibercriminalità.
In ogni casu, pudete facilmente google sta storia. Ùn andemu micca in dramma, ma parlemu tecnicu latu di a materia.
Prima di tuttu, chì hè accadutu?
Capital One avia circa 700 secchi S3 in esecuzione, chì Paige Thompson hà copiatu è sifonatu.
Siconda, hè questu un altru casu di pulitica di bucket S3 misconfigured?
Innò, micca sta volta. Quì hà acquistatu l'accessu à un servitore cù un firewall incorrectamente cunfiguratu è hà realizatu tutta l'operazione da quì.
Aspetta, cumu hè pussibule?
Ebbè, cuminciamu à accede à u servitore, ancu s'ellu ùn avemu micca assai dettagli. Ci hè statu solu dettu chì hè accadutu per un "firewall misconfigurated". Dunque, qualcosa di simplice cum'è paràmetri di gruppu di sicurezza incorrecte o cunfigurazione di u firewall di l'applicazione web (Imperva), o firewall di rete (iptables, ufw, shorewall, etc.). Capital One hà solu ammissu a so culpabilità è hà dettu chì avia chjusu u pirtusu.
Stone hà dettu chì Capital One ùn hà micca avvistu inizialmente a vulnerabilità di u firewall, ma hà agitu rapidamente una volta chì l'hà cunnisciutu. Questu hè statu certamente aiutatu da u fattu chì u pirate hà presuntamente lasciatu infurmazioni chjave d'identità in u duminiu publicu, Stone hà dettu.
Sè vi dumandate perchè ùn andemu più in questa parte, per piacè capisce chì per via di l'infurmazioni limitate pudemu solu speculate. Questu ùn hà micca sensu datu chì u pirate dipendia di un burato lasciatu da Capital One. È salvu chì ùn ci dicenu di più, elencheremu solu tutti i modi pussibuli chì Capital One hà lasciatu u so servitore apertu in cumminazione cù tutti i modi pussibuli chì qualchissia puderia utilizà una di queste diverse opzioni. Questi difetti è tecniche ponu varià da sguardi stupidi à i mudelli incredibilmente cumplessi. Data a gamma di pussibulità, questu diventerà una longa saga senza cunclusione vera. Dunque, focalizemu nantu à l'analisi di a parte induve avemu fatti.
Allora u primu postu hè: sapete ciò chì i vostri firewall permettenu.
Stabbilisce una pulitica o un prucessu propiu per assicurà chì SOLU ciò chì deve esse apertu hè apertu. Sè vo aduprate risorse AWS cum'è Gruppi di Sicurezza o ACL di Rete, ovviamente a lista di cuntrollu per audità pò esse longa ... ma cum'è parechje risorse sò create automaticamente (vale à dì CloudFormation), hè ancu pussibule di automatizà a so verificazione. Ch'ella sia una scrittura casalinga chì scansa novi oggetti per difetti, o qualcosa cum'è un auditu di sicurezza in un prucessu CI / CD ... ci sò parechje opzioni facili per evità questu.
A parte "divertente" di a storia hè chì si Capital One avia tappatu u pirtusu in u primu locu ... nunda ùn saria accadutu. È cusì, francamente, hè sempre scandalizatu per vede cumu qualcosa veramente abbastanza sèmplice diventa l'unicu mutivu per chì una cumpagnia hè piratata. In particulare unu grande cum'è Capital One.
Allora, pirate dentru - chì hè accadutu dopu?
Ebbè, dopu avè intruduciutu in una istanza EC2 ... assai pò sbaglià. Praticamente cammini nantu à u filu di un cuteddu s'è lascià qualcunu andà cusì luntanu. Ma cumu hè ghjuntu in i bucket S3? Per capiscenu questu, discutemu Roles IAM.
Dunque, una manera di accede à i servizii AWS hè di esse un User. Va bè, questu hè abbastanza evidenti. Ma chì si vulete dà altri servizii AWS, cum'è i vostri servitori d'applicazioni, accessu à i vostri bucket S3? Hè per quessa chì i roli IAM sò. Sò custituiti da dui cumpunenti:
- Politica di fiducia - chì servizii o persone ponu aduprà stu rolu?
- Politica di permessi - chì permette stu rolu?
Per esempiu, vulete creà un rolu IAM chì permetterà à l'istanze EC2 di accede à un bucket S3: Prima, u rolu hè stabilitu per avè una Politica di fiducia chì EC2 (u serviziu tutale) o istanze specifiche pò "piglià" u rolu. Accetta un rolu significa chì ponu utilizà i permessi di u rolu per fà azzione. Siconda, a Politica di Permissions permette à u serviziu / persona / risorsa chì "hà pigliatu u rolu" per fà qualcosa in S3, sia accede à un bucket specificu ... o più di 700, cum'è in u casu di Capital One.
Una volta site in una istanza EC2 cù u rolu IAM, pudete ottene credenziali in parechje manere:
- Pudete dumandà metadati di istanza à
http://169.254.169.254/latest/meta-dataFrà altre cose, pudete truvà u rolu IAM cù qualsiasi di e chjave d'accessu à questu indirizzu. Di sicuru, solu s'è vo site in un esempiu.
- Utilizà AWS CLI...
Se l'AWS CLI hè stallatu, hè caricatu cù credenziali da i roli IAM, se presente. Tuttu ciò chì resta hè di travaglià à traversu l'istanza. Di sicuru, se a so pulitica di fiducia era aperta, Paige puderia fà tuttu direttamente.
Allora l'essenza di i roli IAM hè chì permettenu alcune risorse per agisce IN VOTRE NOME nantu à ALTRI RESOURCES.
Avà chì avete capitu i roli di IAM, pudemu parlà di ciò chì Paige Thompson hà fattu:
- Hà guadagnatu l'accessu à u servitore (istanza EC2) attraversu un pirtusu in u firewall
Ch'ella si tratti di gruppi di sicurezza / ACL o di i so propiu firewall di l'applicazioni web, u pirtusu era prubabilmente abbastanza faciule da plug, cum'è dichjaratu in i registri ufficiali.
- Una volta nantu à u servitore, hà pussutu agisce "cum'è" ch'ella era u servitore stessu
- Siccomu u rolu di u servitore IAM hà permessu à S3 l'accessu à questi 700+ buckets, hà pussutu accede à elli
Da quellu mumentu, tuttu ciò ch'ella avia da fà era eseguisce u cumandamentu List Bucketse poi u cumandamentu Sync da AWS CLI...
. A prevenzione di tali danni hè per quessa chì e cumpagnie investenu tantu in a prutezzione di l'infrastruttura di nuvola, DevOps è esperti di sicurezza. E quantu preziosu è costu-efficace si move in u nuvulu? Tantu cusì chì ancu di fronte à sempre più sfide di cybersecurity !
Morale di a storia: verificate a vostra sicurità; Realizà auditi regularmente; Rispettate u principiu di u minimu privilegiu per e pulitiche di sicurità.
( Pudete vede u rapportu legale cumpletu).
Source: www.habr.com