le istruzioni

Come proteggersi dalla minaccia Log4Shell

Aziende di tutto il mondo corrono per mitigare l’exploit Log4Shell che sfrutta la vulnerabilità nella libreria Log4J Apache. Ecco lo stato di quello che si può e si deve fare

17 Dic 2021
F
Dario Fadda

Research Infosec, fondatore Insicurezzadigitale.com

I criminali informatici stanno attivamente cercando e sfruttando l’exploit criticoLog4Shell/Log4J (CVE-2021-44228), mentre scriviamo e al tempo stesso fervono i lavori di aziende e vendor per mitigare il problema.

La mitigazione per Log4J

Anche i CERT di un gran numero di Paesi al mondo si sono interessati nella ricerca di metodi utili alla gestione di questo pericolo informatico. Il CSIRT nostrano (sotto il controllo dell’Agenzia per la Cybersicurezza Nazionale), ha pubblicato un’analisi metodologica il 12 dicembre 2021, con i suggerimenti finora noti sulle tecniche di mitigazione. Una serie di raccomandazioni sono arrivate sempre nella serata di ieri anche dal CERT svizzero.

WHITEPAPER
Cosa fare per migliorare l’analisi dei contenuti abbassando i costi operativi?
Datacenter
Software

Il bug Log4J minaccia mezza internet: ecco il fix urgente per le aziende

Quindi riportando le analisi degli esperti di sicurezza informatica (per gli amministratori di sistema), la ricerca di questa vulnerabilità, che ricordiamo interessa le infrastrutture lato server, i client (gli utilizzatori finali) infatti non hanno in alcun modo possibilità di intervenire proprio perché è legata alla libreria applicativa installata sul server che eroga un certo servizio sviluppato in Java (o con parti sviluppate in Java), si può effettuare con i seguenti comandi (come suggerito dal CSIRT italiano):

sudo egrep -i -r ‘${jndi:(ldap[s]?|rmi)://[^n]+’ /var/log

sudo find /var/log -name *.gz -print0 | xargs -0 zgrep -E -i ‘${jndi:(ldap[s]?|rmi)://[^n]+’

che effettuano appunto la ricerca di tentativi di compromissione direttamente sui log.

Come altro metodo utile alla ricerca della vulnerabilità, all’interno della propria infrastruttura, è consigliato l’utilizzo di strumenti disponibili online che effettuano la scansione da remoto: un esempio noto è Shodan. Con tools come questi è possibile filtrare per prodotto (con il quale si lavora nel server ricercato) usando le stringhe “product:minecraft”, “product:tomcat” e via dicendo ed effettuare la ricerca aggiungendo l’argomento “server” che punterà all’indirizzo pubblico del servizio che si sta erogando e sul quale si sta indagando.

Microsoft in azione su Log4J

Per i sistemi Windows invece, Microsoft ha dettagliato le proprie linee guida che interessano l’utilizzo di Microsoft 365 Defender, tramite la diffusione di una avanzata query di ricerca, atta appunto all’individuazione di tentativi di compromissione:

CloudAppEvents

| where Timestamp > datetime(“2021-12-09”)

| where UserAgent contains “jndi:”

or AccountDisplayName contains “jndi:”

or Application contains “jndi:”

or AdditionalFields contains “jndi:”

| project ActionType, ActivityType, Application, AccountDisplayName, IPAddress, UserAgent, AdditionalFields

Come fare per proteggersi da Log4j

Visti i metodi per la ricerca della vulnerabilità, vediamo ora cosa possiamo fare per proteggere la nostra infrastruttura (in questo caso critica) da un possibile sfruttamento malevolo.

Resta inteso che il miglior modo di intervenire è effettuare l’aggiornamento della libreria, da subito evidentemente fixata dal team ufficiale Apache nelle versioni 2.15.0 – 2.13.2 e 2.8.2.

Gli amministratori di sistema sanno bene però che non sempre è possibile effettuare un aggiornamento improvviso come questo, all’interno della propria applicazione. Per tutti i casi in cui questo non è possibile, o il software non è ancora pronto a riceverlo, si consiglia chiunque abbia a che fare con questa libreria di seguire le indicazione fornite dai più importanti CERT del mondo.

  1. Aggiungere il parametro all’avvio della jvm: -Dlog4j2.formatMsgNoLookups=true;
  2. Aggiungere il file di configurazione log4j2.component.properties nel classpath dell’applicazione, con il contenuto seguente: log4j2.formatMsgNoLookups=true;
  3. Impostare la variabile di ambiente di sistema LOG4J_FORMAT_MSG_NO_LOOKUPS=true;
  4. Utilizzare il seguente comando per rimuovere il file di classe JndiLookup nel pacchetto log4j-core: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class;
  5. Disabilitare JNDI manualmente, ad esempio con: add spring.jndi.ignore=true in spring.properties;
  6. Si consiglia di utilizzare la versione superiore di JDK 11.0.1, 8u191, 7u201, 6u211 e successive, che in una certa misura offre protezione contro lo sfruttamento RCE in generale.

A titolo di aiuto tecnico per affrontare questo problema, prima che diventi un incidente per l’infrastruttura critica, ci sentiamo di segnalare tre progetti recentissimi utili:

  • uno scanner per la ricerca della vulnerabilità: Log4j-scan;
  • un aiuto nell’individuazione della compromissione da parte dell’exploit: Log4shell-detector;
  • un “vaccino” per sistemi già compromessi, direttamente dalla società di sicurezza Cybereason;
  • elenco in costante aggiornamento degli applicativi potenzialmente affetti dalla vulnerabilità Log4j, relativamente completo e dettagliato.

Questi sei suggerimenti sono consigliati e utili a risolvere il problema in via del tutto temporanea. E’ sempre raccomandato aggiornare la versione di Log4j o lavorare sul progetto attualmente vulnerabile di modo da rendere fattibile l’aggiornamento.

CLICCA QUI per scaricare il White Paper: "Security As A Service"
INFOGRAFICA
[Infografica] I 6 migliori data analytics tools a confronto: CHI VINCE?
Big Data
Datacenter
@RIPRODUZIONE RISERVATA

Articolo 1 di 2