Il 19 luglio 2019, Capital One ha ricevuto il messaggio che ogni azienda moderna teme: si è verificata una violazione dei dati. Ha colpito più di 106 milioni di persone. 140 numeri di previdenza sociale statunitensi, un milione di numeri di previdenza sociale canadesi. 000 conti bancari. Spiacevole, non sei d'accordo?
Sfortunatamente, l’hacking non è avvenuto il 19 luglio. A quanto pare, Paige Thompson, a.k.a. irregolare, lo ha commesso tra il 22 e il 23 marzo 2019. Questo è quasi quattro mesi fa. Infatti, è stato solo grazie all'aiuto di consulenti esterni che Capital One ha potuto scoprire che qualcosa era successo.
Un ex dipendente di Amazon è stato arrestato e rischia una multa di 250 dollari e cinque anni di prigione... ma resta ancora molta negatività. Perché? Perché molte aziende vittime di attacchi informatici stanno cercando di scrollarsi di dosso la responsabilità di rafforzare le proprie infrastrutture e applicazioni in un contesto di aumento della criminalità informatica.
Ad ogni modo, puoi facilmente cercare su Google questa storia. Non entreremo nel dramma, ma ne parleremo tecnico lato della questione.
Innanzitutto cosa è successo?
Capital One aveva circa 700 bucket S3 in esecuzione, che Paige Thompson ha copiato e sottratto.
In secondo luogo, si tratta di un altro caso di policy del bucket S3 configurata in modo errato?
No non questa volta. Qui è riuscita ad accedere ad un server con un firewall configurato in modo errato e da lì ha eseguito l'intera operazione.
Aspetta, come è possibile?
Bene, iniziamo accedendo al server, anche se non abbiamo molti dettagli. Ci è stato detto solo che ciò è avvenuto attraverso un “firewall mal configurato”. Quindi, qualcosa di semplice come impostazioni errate del gruppo di sicurezza o configurazione del firewall dell'applicazione web (Imperva) o del firewall di rete (iptables, ufw, Shorewall, ecc.). Capital One si è limitata ad ammettere la propria colpevolezza e ad affermare di aver chiuso il buco.
Stone ha affermato che Capital One inizialmente non si è accorta della vulnerabilità del firewall, ma ha agito rapidamente non appena ne è venuta a conoscenza. A ciò ha sicuramente contribuito il fatto che l'hacker avrebbe lasciato informazioni chiave identificative di pubblico dominio, ha affermato Stone.
Se ti stai chiedendo perché non approfondiamo questa parte, ti preghiamo di comprendere che a causa delle informazioni limitate possiamo solo speculare. Ciò non ha senso dato che l’hacking dipendeva da un buco lasciato da Capital One. E a meno che non ci dicano di più, elencheremo semplicemente tutti i possibili modi in cui Capital One ha lasciato aperto il proprio server in combinazione con tutti i possibili modi in cui qualcuno potrebbe utilizzare una di queste diverse opzioni. Questi difetti e tecniche possono variare da sviste estremamente stupide a schemi incredibilmente complessi. Data la gamma di possibilità, questa diventerà una lunga saga senza una vera conclusione. Pertanto, concentriamoci sull'analisi della parte in cui abbiamo i fatti.
Quindi il primo punto è: sapere cosa consentono i firewall.
Stabilire una politica o un processo adeguato per garantire che venga aperto SOLO ciò che deve essere aperto. Se utilizzi risorse AWS come gruppi di sicurezza o ACL di rete, ovviamente la lista di controllo da controllare può essere lunga... ma proprio come molte risorse vengono create automaticamente (ad esempio CloudFormation), è anche possibile automatizzare il loro controllo. Che si tratti di uno script fatto in casa che analizza i nuovi oggetti alla ricerca di difetti o di qualcosa come un controllo di sicurezza in un processo CI/CD... ci sono molte semplici opzioni per evitarlo.
La parte "divertente" della storia è che se Capital One avesse tappato il buco in primo luogo... non sarebbe successo nulla. E quindi, francamente, è sempre scioccante vedere come qualcosa funziona davvero abbastanza semplice diventa l'unico motivo per cui un'azienda viene hackerata. Soprattutto uno grande come Capital One.
Quindi, hacker all'interno, cosa è successo dopo?
Bene, dopo essere entrati in un'istanza EC2... molte cose possono andare storte. Stai praticamente camminando sul filo del rasoio se lasci che qualcuno arrivi così lontano. Ma come è finito nei bucket S3? Per capirlo, parliamo dei ruoli IAM.
Pertanto, un modo per accedere ai servizi AWS è essere un utente. Ok, questo è abbastanza ovvio. Ma cosa succede se desideri fornire ad altri servizi AWS, come i server delle applicazioni, l'accesso ai tuoi bucket S3? Ecco a cosa servono i ruoli IAM. Sono costituiti da due componenti:
- Politica di fiducia: quali servizi o persone possono utilizzare questo ruolo?
- Politica delle autorizzazioni: cosa consente questo ruolo?
Ad esempio, desideri creare un ruolo IAM che consentirà alle istanze EC2 di accedere a un bucket S3: in primo luogo, il ruolo è impostato per avere una policy di attendibilità secondo la quale EC2 (l'intero servizio) o istanze specifiche possono "assumere" il ruolo. Accettare un ruolo significa che possono utilizzare le autorizzazioni del ruolo per eseguire azioni. In secondo luogo, la policy di autorizzazione consente al servizio/persona/risorsa che ha “assunto il ruolo” di fare qualsiasi cosa su S3, sia che si tratti di accedere a un bucket specifico... o a oltre 700, come nel caso di Capital One.
Una volta che ti trovi in un'istanza EC2 con il ruolo IAM, puoi ottenere le credenziali in diversi modi:
- Puoi richiedere i metadati dell'istanza all'indirizzo
http://169.254.169.254/latest/meta-dataA questo indirizzo puoi trovare, tra l'altro, il ruolo IAM con una qualsiasi delle chiavi di accesso. Naturalmente, solo se sei in un'istanza.
- Utilizza l'AWS CLI...
Se l'AWS CLI è installata, viene caricata con le credenziali dei ruoli IAM, se presenti. Tutto ciò che resta è lavorare ATTRAVERSO l'istanza. Naturalmente, se la loro politica di fiducia fosse aperta, Paige potrebbe fare tutto direttamente.
Quindi l'essenza dei ruoli IAM è che consentono ad alcune risorse di agire PER TUO CONTO su ALTRE RISORSE.
Ora che hai compreso i ruoli dell'IAM, possiamo parlare di ciò che ha fatto Paige Thompson:
- Ha ottenuto l'accesso al server (istanza EC2) attraverso un buco nel firewall
Che si trattasse di gruppi di sicurezza/ACL o dei propri firewall per applicazioni web, probabilmente il buco era abbastanza facile da tappare, come indicato nei documenti ufficiali.
- Una volta sul server, poteva comportarsi “come se” fosse lei stessa il server
- Poiché il ruolo del server IAM consentiva a S3 l'accesso a questi oltre 700 bucket, è stato in grado di accedervi
Da quel momento in poi non le restava altro che eseguire il comando List Bucketse poi il comando Sync dall'AWS CLI...
. Prevenire tali danni è il motivo per cui le aziende investono così tanto nella protezione dell’infrastruttura cloud, in DevOps e negli esperti di sicurezza. E quanto è prezioso ed economico il passaggio al cloud? Tanto che anche di fronte a sempre più sfide alla sicurezza informatica !
Morale della favola: controlla la tua sicurezza; Condurre audit regolari; Rispettare il principio del privilegio minimo per le politiche di sicurezza.
( È possibile visualizzare la relazione legale completa).
Fonte: habr.com