Nota: questo post è stato aggiornato il 15 dicembre 2021 e il 20 dicembre 2021.
Questa settimana parleremo della vulnerabilità di Log4j2, che ha spinto molte organizzazioni a cercare di applicare una patch ai loro sistemi, ma prima affronteremo alcune preoccupazioni dei nostri clienti in merito a questa vulnerabilità.
Risposta di Linode a Log4j2
- Abbiamo valutato a fondo la portata del rischio e l'impatto di questa vulnerabilità critica zero-day su tutta la nostra infrastruttura nelle prime ore dal rilascio pubblico, venerdì 10 dicembre.
- Abbiamo osservato i tentativi di exploit falliti con l'aiuto della nostra architettura di controllo della sicurezza approfondita.
- Non abbiamo osservato alcun indicatore di compromissione relativo a questa vulnerabilità nel nostro ambiente e stiamo monitorando continuamente la nostra infrastruttura per verificare la presenza di IoC noti relativi a questa vulnerabilità e ad altre.
Vulnerabilità critica di Log4j2 per l'esecuzione di codice remoto (CVE-2021-44228)
Log4j2 è il successore dell'utilità di logging Log4j di Apache , comunemente utilizzata. Questo componente è scritto in Java e fa parte di Apache Logging Services. Secondo Oracle, la Java Naming and Directory Interface (JNDI) è un'interfaccia di programmazione di applicazioni (API) che fornisce funzionalità di denominazione e directory alle applicazioni scritte in Java.
La scorsa settimana, Apache ha pubblicato nella pagina delle vulnerabilità di sicurezza di Log4j che le versioni di log4j-core comprese tra la 2.0-beta9 e la 2.14.1 contengono una grave vulnerabilità. Questa vulnerabilità consente agli aggressori che possono controllare i messaggi di log o i parametri dei messaggi di log di eseguire codice arbitrario caricato dai server LDAP. In pratica, ciò è sfruttabile da aggressori esterni. Questa vulnerabilità è stata classificata con un punteggio CVSS di 10 su 10, poiché consente a un utente malintenzionato di eseguire codice arbitrario su ogni sistema interessato. Questo problema è stato mitigato dall'aggiornamento 2.15, che ha disabilitato il comportamento di ricerca JNDI sulla base di due problemi Jira all'inizio di dicembre e alla fine di novembre. Apache ha inoltre rilasciato la versione 2.17 per risolvere altri problemi riscontrati in seguito sul componente.
Effetti della vulnerabilità
Log4j2 è un popolare framework di logging Java utilizzato da diversi fornitori per numerosi prodotti. Questa vulnerabilità può essere facilmente sfruttata manipolando la stringa User-Agent delle intestazioni delle richieste HTTP e inviando la richiesta ai sistemi vulnerabili. Sebbene l'User-Agent non sia l'unica intestazione che può essere utilizzata in questo tipo di attacco, un payload dannoso farà sì che il componente Log4j2 vulnerabile attivi una ricerca JNDI sul server dannoso. Quando l'URI dannoso incorporato nelle intestazioni HTTP contiene il percorso di un file di classe Java dannoso, questo file viene iniettato nel processo del server e consente all'aggressore di accedere al sistema interessato. Attualmente sono stati osservati diversi payload e bypass, il che rende più difficile proteggersi da questo problema utilizzando i comuni meccanismi di difesa.
Diagramma dell'attacco
Il seguente diagramma del Computer Emergency Response Team del governo svizzero può aiutare a capire come funziona l'attacco e come mitigarlo.
"Attacco a Log4j JNDI" di SGCERT è concesso in licenza sotto CC BY-SA 4.0.
Prodotti interessati
Molti fornitori hanno rilasciato dichiarazioni per aiutare a mitigare questa vulnerabilità e queste dichiarazioni potrebbero essere una risorsa utile per i nostri clienti interessati. Nei link sottostanti è possibile leggere ulteriori informazioni sui prodotti interessati dai fornitori. Questo non è un elenco completo di tutti i prodotti interessati. Per un elenco completo dei fornitori interessati e dei loro prodotti, è possibile consultare l'elenco curato da SwitHak su Github o un altro elenco condiviso da TechSolvency.
- Apache
- Atlassian
- Elastic
- Cisco
- CloudFlare
- Debian
- GitHub
- Minecraft
- Oracolo
- RedHat
- Cipolla della sicurezza
Metodi di mitigazione ufficiali
Nella pagina sulla sicurezza di Log4j, Apache afferma che esistono diversi metodi per risolvere questa vulnerabilità, ma va notato che questi metodi potrebbero non funzionare allo stesso modo in tutti i prodotti vulnerabili. Per ulteriori informazioni, consultare la dichiarazione di sicurezza del fornitore sulla vulnerabilità.
- Gli utenti di Java 8 (o successivi) dovrebbero aggiornare alla release 2.17.0 per risolvere questa vulnerabilità insieme ad altre vulnerabilità scoperte di recente.
- Gli utenti che necessitano di Java 7 devono aggiornare alla versione 2.12.2.
- Se questi due passaggi non sono possibili, l'attenuante è rimuovere la classe JndiLookup dal percorso di classe (indicata come log4j-core-*.jar) usando un comando simile a quello che segue:
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.classSiamo orgogliosi di condividere le conoscenze con la nostra comunità per aiutarli a mitigare le vulnerabilità, sia che siano critiche come questa o meno impattanti. Sentitevi liberi di lasciare un commento qui sotto per condividere i vostri pensieri e suggerimenti.
Commenti