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.
Indice degli argomenti
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.
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
Il bug Log4J e l’exploit Log4Shell
Nei due giorni appena trascorsi l’exploit Log4Shell e la vulnerabilità Log4j sono diventati temi caldi su social e non solo. Le società di sicurezza informatica di tutto il mondo hanno iniziato a studiare i dettagli di questa scoperta e diffondere metodologie di mitigazione del rischio al quale espone. Nell’analisi che abbiamo pubblicato nel weekend abbiamo riportato in maniera generale quali sono le alternative di mitigazione dell’esposizione, oltre all’aggiornamento.
La vulnerabilità nella libreria Log4J consente agli aggressori di eseguire codice in remoto su un server vulnerabile semplicemente cercando o modificando l’user agent del browser in una stringa personalizzata.
Una volta scoperta la vulnerabilità, gli aggressori sfruttano il problema per eseguire script di shell forzando l’installazione del cryptominer. Lo script bash sul server vulnerabile scarica e installa il malware Kinsing per estrarre criptovaluta (attività di cryptomining).
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.
- Aggiungere il parametro all’avvio della jvm: -Dlog4j2.formatMsgNoLookups=true;
- Aggiungere il file di configurazione log4j2.component.properties nel classpath dell’applicazione, con il contenuto seguente: log4j2.formatMsgNoLookups=true;
- Impostare la variabile di ambiente di sistema LOG4J_FORMAT_MSG_NO_LOOKUPS=true;
- 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;
- Disabilitare JNDI manualmente, ad esempio con: add spring.jndi.ignore=true in spring.properties;
- 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.
