Superficie d'attacco cloud

Nel cloud, il provider protegge l'infrastruttura, mentre il cliente protegge la configurazione, l'identità e i dati. La maggior parte delle violazioni avviene dal lato del cliente rispetto a questa responsabilità.

• Il provider si occupa delle patch degli hypervisor e della sicurezza fisica.
• Il cliente è responsabile delle policy IAM, delle autorizzazioni di archiviazione e delle regole di rete.
• Il rischio principale è la configurazione errata, non la compromissione del provider.

Il cloud non ha un tradizionale perimetro di rete. L'accesso è regolato da IAM: utenti, ruoli, policy e chiavi. Una chiave di accesso trapelata può essere dannosa quanto una password di Domain Admin rubata.

• Le policy IAM concedono azioni sulle risorse.
• I ruoli consentono a servizi e utenti di assumere credenziali temporanee.
• Le identità con autorizzazioni eccessive sono il principale vettore di escalation.

Le credenziali cloud trapelano continuamente. Le fonti comuni includono:

• Chiavi di accesso sottoposte a commit in repository Git pubblici.
• Chiavi hardcoded in app mobili, log CI o immagini dei container.
• Server-Side Request Forgery (SSRF) che raggiunge il servizio metadati.
• Condivisione eccessivamente ampia di chiavi a lunga durata invece di ruoli a breve durata.

Ogni istanza cloud espone un endpoint dei metadati che può fornire credenziali temporanee del ruolo. Un attacco SSRF o RCE su una VM che riesce a raggiungerlo consente spesso di ottenere il ruolo dell'istanza.

• AWS IMDS è disponibile all'indirizzo 169.254.169.254.
• IMDSv1 richiede solo una richiesta e può essere sfruttato facilmente tramite SSRF.
• IMDSv2 richiede un token di sessione (prima PUT, poi GET), rendendo inefficaci molti attacchi SSRF.

Lo storage a oggetti (S3, GCS, Azure Blob) è una fonte ricorrente di esposizione dei dati.

• I bucket con lettura pubblica espongono file sensibili.
• I bucket con scrittura pubblica consentono manomissioni o l'hosting di malware.
• Policy o ACL dei bucket eccessivamente permissive concedono l'accesso agli utenti autenticati.
• Gli URL pre-firmati con scadenza lontana espongono un accesso persistente.

I controlli di rete cloud (Security Groups, NSG, regole firewall) vengono facilmente configurati in modo troppo permissivo.

• Database o porte di amministrazione esposti a 0.0.0.0/0.
• Piani di gestione (API Kubernetes, RDP, SSH) raggiungibili da Internet.
• Servizi interni che considerano implicitamente attendibile la VPC e non richiedono autenticazione.

Il serverless sposta il rischio, ma non lo elimina. Funzioni, code e database gestiti hanno ciascuno un'identità di esecuzione.

• Il ruolo di esecuzione di una Lambda potrebbe avere permessi eccessivi.
• Le variabili d'ambiente contengono spesso segreti leggibili in caso di compromissione.
• Una configurazione errata della sorgente di eventi può consentire a input non attendibili di attivare funzioni privilegiate.

Distinga le due superfici d'attacco:

• Piano di controllo: l'API cloud (creare risorse, modificare IAM, leggere configurazioni). Una compromissione di questo piano riguarda l'intero account.
• Piano dati: i carichi di lavoro stessi (app, VM, container).

Ottenere un punto d'appoggio nel piano dati che fornisca credenziali del piano di controllo è il classico percorso di escalation nel cloud.

Le grandi organizzazioni dividono i carichi di lavoro tra numerosi account, subscription e progetti.

• I ruoli tra account con policy di attendibilità deboli consentono il pivot.
• Un confused deputy in un ruolo di integrazione di terze parti può essere sfruttato.
• I ruoli a livello di organizzazione (ad esempio OrganizationAccountAccessRole) hanno un valore elevato.

I difensori si affidano ai log nativi del cloud. Gli attaccanti cercano di accecarli.

• CloudTrail / Activity Log / Audit Logs registrano le chiamate al piano di controllo.
• Gli attaccanti possono disabilitare i trail o interrompere la distribuzione dei log.
• GuardDuty / Security Command Center / Defender segnalano le anomalie.

Disabilitare il logging è di per sé un evento altamente indicativo, che merita un avviso.

I penetration test nel cloud richiedono consapevolezza del provider e autorizzazione. Alcune azioni (come la negazione del servizio e determinate scansioni) violano i termini del provider. Confermi sempre la titolarità dell'account, concordi la portata dell'impatto e preferisca inizialmente l'enumerazione in sola lettura.

Utilizzi un account di test dedicato o risorse chiaramente contrassegnate e non tocchi mai risorse esterne all'ambito documentato.

Verifichi la propria comprensione della superficie d'attacco cloud.

Ha mappato la superficie d'attacco cloud.

• Nel cloud, il rischio deriva soprattutto dalle configurazioni errate lato cliente.
• L'identità è il perimetro di sicurezza; le chiavi e i ruoli esposti sono vettori fondamentali.
• Il servizio dei metadati collega le vulnerabilità del piano dati alle credenziali cloud.
• Le configurazioni errate di storage, rete e logging completano la superficie d'attacco.

Prossimo argomento: enumerare le risorse cloud per individuare questi problemi.