Penetration test cloud: la nostra metodologia per AWS, Azure e GCP

Affidateci un ruolo IAM in sola lettura che qualcuno ha sovradimensionato nei permessi e c’è una buona probabilità che lo portiamo fino al controllo totale dell’account prima che finisca il vostro stand-up. Il provider cloud non è guasto quando questo accade. Qualcuno ha collegato una policy con un’azione wildcard, lasciato un ruolo assumibile da mezza Internet e smesso di leggere CloudTrail da qualche parte nell’ultimo trimestre. L’intera metodologia di penetration test cloud descritta in questo articolo vive in quel divario, quello tra “la piattaforma è sicura” e “la nostra configurazione è sicura.”

Quel che segue è la sequenza che eseguiamo davvero nei lavori su AWS, Azure e GCP. Non è una checklist di conformità riformattata in prosa, ma l’ordine in cui testiamo, gli strumenti a cui ricorriamo e le configurazioni errate che continuano a rendere ingaggio dopo ingaggio.

Una premessa di inquadramento. Il testing in cloud è un problema di modello dei permessi prima che un problema di rete. On-premise si combattono firewall e segmentazione. Qui si combattono policy IAM, relazioni di trust ed endpoint di metadati. Affrontatelo come un classico test di rete esterno e passerete dritti oltre le cose che davvero portano alla compromissione degli account.

Punti chiave

• Una metodologia di penetration test cloud è identity-first: le policy IAM e le relazioni di trust sono la principale superficie di attacco, molto prima di qualsiasi cosa a livello di rete.
• Quattro riscontri dominano i nostri report: policy IAM troppo permissive, storage esposto pubblicamente (S3, Blob, GCS), SSRF che raggiunge il servizio di metadati dell’istanza ed escalation di privilegi tramite una policy o un ruolo mal configurati.
• Il perimetro e l’autorizzazione scritta contano qui più che in qualsiasi altro test. State lavorando dentro un confine di responsabilità condivisa, quindi vi servono sia le regole del provider sia il via libera del proprietario dell’account prima di toccare qualsiasi cosa.
• IMDSv2, policy a privilegio minimo, il blocco dell’accesso pubblico allo storage e un logging monitorato (CloudTrail, Azure Monitor, Cloud Logging) chiudono la maggior parte di ciò che troviamo.
• Gli scanner CSPM segnalano le configurazioni errate una alla volta. Non ne concatenano tre fino a una presa di controllo dell’account. Proprio quella concatenazione è l’intero senso di un test manuale.

Che cos’è un penetration test cloud e in cosa è diverso?

Un penetration test cloud è una simulazione di attacco autorizzata contro l’ambiente cloud che vi appartiene: gli account, le identità, i servizi e le configurazioni che risiedono dentro AWS, Azure o GCP. Il provider mette in sicurezza l’hardware, l’hypervisor e il livello fisico. Voi siete responsabili di tutto ciò che configurate al di sopra: IAM, permessi dello storage, gruppi di sicurezza di rete, gestione delle chiavi, logging. Questa suddivisione è il modello di responsabilità condivisa, e traccia il confine di ciò che ci è consentito testare.

La differenza pratica rispetto a un pentest tradizionale è che il perimetro è morbido e il piano dell’identità è enorme. Una singola chiave di accesso trapelata, un trust OIDC sciatto per una pipeline CI o una Lambda con un ruolo admin collegato possono contare molto più di qualsiasi porta aperta. Perciò la metodologia è costruita attorno a identità, trust e configurazione, non attorno alla scansione di un range CIDR.

Passo 1: perimetro, autorizzazione e regole d’ingaggio

Prima che venga eseguito un solo comando, fissiamo tre cose. Quali account e subscription rientrano nel perimetro. Di che tipo di test si tratta: esterno senza credenziali, oppure autenticato in modalità “assumed breach” a partire da un’identità a bassi privilegi. E cosa consente davvero il provider. AWS, Azure e GCP pubblicano ciascuno le condizioni d’uso accettabile per i test di sicurezza. La maggior parte dei servizi comuni non richiede più un’approvazione preventiva, ma i test di denial-of-service, il carico pesante e prolungato e alcuni servizi gestiti sono ancora soggetti a limiti. Noi restiamo al loro interno.

I test cloud più utili che eseguiamo sono autenticati. Chiediamo un’identità deliberatamente debole: un utente IAM in sola lettura, un account Entra ID di base, un service account GCP con ruoli minimi. Poi vediamo fin dove arriva. Questo modella la minaccia realistica, cioè un dipendente vittima di phishing, una chiave trapelata in un repository pubblico o un’integrazione di terze parti compromessa, non un attaccante senza volto che parte da zero. Il lavoro esterno non autenticato ha il suo posto per la mappatura della superficie di attacco. L’escalation interessante vive quasi sempre dopo quel primo punto d’appoggio.

Passo 2: enumerare l’identità, perché è lì la vera superficie di attacco

Con un punto d’appoggio in mano, il primo compito è rispondere a due domande: chi siamo e cosa possiamo diventare? Su AWS si comincia in modo semplice.

aws sts get-caller-identity
aws iam get-account-authorization-details   # if permitted
aws iam list-attached-user-policies --user-name svc-ci

Poi mappiamo il grafo delle identità. Pacu e ScoutSuite ci offrono un’ampia copertura di AWS, e PMapper trasforma un mucchio di policy JSON in una risposta netta su quale principal possa raggiungere admin. Su Azure ci appoggiamo ad AzureHound e al più ampio ecosistema BloodHound per rappresentare come grafo i ruoli di directory, l’annidamento dei gruppi e le assegnazioni PIM idonee. Su GCP percorriamo a mano la gerarchia delle risorse e leggiamo i role binding a livello di organizzazione, cartella, progetto e risorsa, perché un binding ereditato da un livello superiore è banalmente facile da lasciarsi sfuggire a occhio.

Ciò che cacciamo in questa fase: azioni wildcard come "Action": "*" o un iam:* esteso a un intero servizio, ruoli con trust policy sts:AssumeRole permissive e qualsiasi percorso che consenta a un’identità debole di concedersi altro. Una policy che consente iam:PassRole accanto a un permesso di creazione di compute non è una preoccupazione teorica. È una primitiva di escalation che funziona.

Passo 3: escalation di privilegi IAM

È qui che gli ingaggi cloud si vincono o si perdono. I percorsi di escalation su AWS che Rhino Security Labs ha documentato anni fa funzionano ancora su account in produzione, perché i team continuano a concedere i singoli permessi ingrediente senza accorgersi di cosa sommino. Alcuni che controlliamo ogni singola volta:

• iam:PassRole più creazione di compute. Se possiamo passare un ruolo admin a una nuova istanza EC2, una funzione Lambda o un job Glue, eseguiamo il nostro codice sotto quel ruolo e ne leggiamo le credenziali. Escalation immediata.
• iam:CreatePolicyVersion o AttachUserPolicy. Se il nostro utente può modificare o collegare policy, può collegare AdministratorAccess a sé stesso. Partita finita.
• Ruoli assumibili con trust troppo lasco. Un ruolo che si fida di "Principal": {"AWS": "*"}, o di una root di account troppo ampia, è una porta lasciata spalancata.

Gli equivalenti su Azure e GCP sono altrettanto produttivi. Su Azure cerchiamo ruoli personalizzati che portano Microsoft.Authorization/roleAssignments/write, service principal con permessi Graph eccessivi e runbook di Automation Account o managed identity che possiamo dirottare. Su GCP le primitive affidabili sono iam.serviceAccounts.getAccessToken (coniare un token per un service account più potente), iam.serviceAccountKeys.create e setIamPolicy a livello di progetto. Ognuna di esse trasforma un modesto punto d’appoggio nel controllo dell’intero progetto.

Passo 4: SSRF verso il servizio di metadati dell’istanza

La catena di maggior valore nel testing cloud è una vulnerabilità di server-side request forgery in un’applicazione in grado di raggiungere l’endpoint di metadati. Puntate quella SSRF verso l’indirizzo di metadati link-local e provate a leggere le credenziali temporanee del ruolo collegato.

http://169.254.169.254/latest/meta-data/iam/security-credentials/
# then, with the role name that comes back:
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

Su un host legacy con IMDSv1 che restituisce un AccessKeyId, un SecretAccessKey e un token di sessione, li esportiamo e li usiamo direttamente. È lo schema dietro una delle violazioni cloud più studiate di sempre, e il motivo per cui insistiamo tanto su IMDSv2. Gli endpoint equivalenti esistono altrove: Azure su 169.254.169.254/metadata/identity/oauth2/token con un header Metadata: true, e GCP su metadata.google.internal con Metadata-Flavor: Google. Poi mappiamo fin dove arriva quell’identità. Questa tecnica corrisponde con precisione a MITRE ATT&CK T1552.005, credenziali non protette dall’API di metadati dell’istanza cloud.

Passo 5: storage esposto e dati pubblici

Lo storage a oggetti leggibile pubblicamente resta uno dei riscontri gravi più frequenti che documentiamo. Enumeriamo i bucket S3, i container Azure Blob e i bucket GCS legati al target, leggiamo le loro ACL e bucket policy e testiamo l’accesso pubblico in elenco e lettura. Poi testiamo la scrittura pubblica, quella che tutti dimenticano. La scrittura pubblica su un bucket che serve gli asset di un sito o gli aggiornamenti software non è un problema di esposizione di dati. È un problema di supply chain.

Lo storage è solo metà della questione. Setacciamo anche i secret esposti: chiavi di accesso committate in repository pubblici, chiavi incorporate nei bundle delle app mobili, token che giacciono nel JavaScript di front-end e voci di Secrets Manager o Key Vault troppo leggibili. Una singola chiave valida e a lunga durata può cambiare la forma dell’intero ingaggio.

Passo 6: rete, servizi e movimento laterale

Solo dopo l’identità ci interessa la rete. Esaminiamo security group e NSG in cerca di ingress aperti, il solito SSH e RDP esposti a 0.0.0.0/0, database appesi alla Internet pubblica, poi controlliamo endpoint RDS pubblici o di database gestiti e come si comporta la segmentazione tra VPC, subnet e peering. Da un’identità o un host compromessi, testiamo il movimento. Possiamo raggiungere servizi interni? Assumere ruoli verso altri account? Pivotare da una subscription di dev alla produzione tramite un’identità condivisa? I confini di trust tra più account e più subscription tendono a essere più morbidi di quanto suggerisca il diagramma dell’architettura.

Passo 7: qualcuno ci ha visti?

Ecco un riscontro che ci sta a cuore quanto qualsiasi exploit: l’ambiente se n’è accorto? Verifichiamo che CloudTrail sia attivo in tutte le regioni con la validazione dei file di log, che Azure Monitor e gli Activity Log stiano raccogliendo, e che i GCP Cloud Audit Log siano abilitati, centralizzati e generino alert sulle azioni che abbiamo appena eseguito. Un attaccante che crea una chiave di accesso, disabilita il logging ed esfiltra dati dovrebbe far scattare qualcosa. In parecchi ingaggi non scatta assolutamente nulla. Lo segnaliamo come una lacuna di detection, e non lo addolciamo, perché la prevenzione prima o poi fallisce e la detection è la rete di sicurezza.

Come si previene ciò che troviamo?

Il privilegio minimo è tutto il gioco. Restringete le policy IAM ad azioni e risorse specifiche, cancellate le wildcard e usate permission boundary e service control policy per porre un tetto a ciò che qualsiasi identità può raggiungere. Imponete IMDSv2 su ogni istanza, così una SSRF vagante non può coniare credenziali. Attivate il blocco dell’accesso pubblico a livello di account per S3, tenete Blob e GCS privati per impostazione predefinita e verificatelo invece di fidarvi del valore predefinito della console. Preferite credenziali federate a breve durata rispetto alle chiavi a lunga durata, e ruotate le chiavi che davvero non potete evitare. E rendete reale il logging: centralizzato, a prova di manomissione e collegato ad alert su cui un umano o un SIEM interverranno. Un log che nessuno legge è teatro.

Come aiuta CyberXplore

Il nostro servizio di penetration test cloud esegue esattamente questa metodologia contro i vostri ambienti AWS, Azure e GCP. Identity-first, manuale e concentrato sul concatenare le configurazioni errate fino all’impatto che raggiungerebbe un vero attaccante, non sullo stampare un elenco di alert CSPM. Ottenete riscontri ordinati per sfruttabilità, passi di riproduzione che potete consegnare al team di sviluppo e un nuovo test gratuito una volta che avete posto rimedio. Se volete un test perimetrato della vostra impronta cloud, richiedete un preventivo e adatteremo l’ingaggio ai vostri account e alle regole d’ingaggio del provider.

FAQ

AWS, Azure e GCP consentono il penetration test cloud?

Sì, entro certi limiti. Tutti e tre i provider consentono di testare le vostre risorse per la maggior parte dei servizi comuni senza approvazione preventiva, e ciascuno limita i test di denial-of-service e alcuni servizi gestiti. Lavoriamo entro la politica d’uso accettabile attualmente pubblicata dal provider per tutto ciò che rientra nel perimetro, e richiediamo un’autorizzazione scritta del proprietario dell’account prima di iniziare.

Qual è la differenza tra una scansione CSPM e un penetration test cloud?

Uno strumento di cloud security posture management segnala di continuo le configurazioni errate rispetto a un insieme di regole, il che è utile, ma riporta ogni problema in modo isolato. Un penetration test concatena quei problemi, così un ruolo in sola lettura più un permesso PassRole più una SSRF diventa una presa di controllo dell’account dimostrata. Usiamo gli scanner per la copertura e il testing manuale per l’impatto.

Vi servono credenziali o potete testare dall’esterno?

Entrambe le vie sono valide e rispondono a domande diverse. Un test esterno, non autenticato, misura la vostra superficie di attacco esposta. Un test autenticato in modalità “assumed breach”, a partire da un’identità a bassi privilegi, tende a far emergere i percorsi di escalation e movimento laterale che contano di più. Per il lavoro in cloud di solito raccomandiamo l’approccio autenticato.

Quanto dura un penetration test cloud?

Dipende dal numero di account, dall’ampiezza dei servizi e dal fatto che sia mono o multi-cloud. Un singolo account AWS ben perimetrato richiede meno tempo di un’organizzazione con più account e Azure e GCP nel mix. Il perimetro determina la tempistica, ed è per questo che dimensioniamo ogni test singolarmente invece di indicare una cifra forfettaria.

Quali sono i riscontri cloud più frequenti che segnalate?

Le policy IAM troppo permissive e i percorsi di escalation dei privilegi guidano con ampio margine, seguiti dallo storage esposto pubblicamente, dalla SSRF che raggiunge il servizio di metadati dell’istanza e da un logging inadeguato o non monitorato. Presi da soli vanno da gravità media ad alta. Concatenati, diventano regolarmente critici.