On Tue, 14 Dec 2021 20:03:48 +0100 380° wrote: > Giacomo Tesio <[email protected]> writes: > > > A questo primo problema fondamentale, si è aggiunta una particolare > > tipologia di integrazione dei log che scarica ed esegue una libreria > > java [6] all'interno della JVM in esecuzione. > > > [6] > > https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLooku > (ho riportato qui il link per comodità di commento) > > Io ho letto e riletto quattro volte quel paragrafo e - complice la mia > ignoranza - non capisco dove c'è scritto che la variabile recuperata > via JNDI viene usata per scaricare un payload (una classe Java?) che > poi viene eseguito dal processo che lo scarica.
No, Giovanni, non c'è scritto: il mio link voleva fornire un riferimento solo alla "feature" in questione, non all'exploit. Le mie parole erano una semplificazione (evidentemente eccessiva) di quanto spiegato meglio da Bechler qui: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ > Log4J will perform a JNDI lookup() while expanding placeholders in > logging messages (or indirectly as parameters for formatted messages). > > In a default installation there are two “interesting” protocols > supported by JNDI: RMI and LDAP. In both cases a lookup() call is > actually meant to return a Java object. This usually means serialized > Java objects, however there is also a JNDI Reference mechanism for > indirect construction through a factory. This object and factory > bytecode can potentially be loaded from a remote URL codebase (read: a > webserver with .class files). Una factory [1] è un metodo (tipicamente statico) che restituisce un'istanza di un oggetto. Per restituirla deve essere eseguito, tipicamente dalla macchina virtuale che poi userà l'istanza. E per creare l'istanza può fare tutto ciò che l'ambiente di esecuzione permette. Quindi in questo caso può scaricare altro codice etc... Scusa l'approssimazione confusa. > > Infatti NESSUNO di coloro che ha usato log4j nell'ultimo decennio ha > > > > - letto la documentazione di questa feature > > - letto il sorgente > > - acceso il cervello > > > > O meglio, qualcuno l'ha fatto: quelli che hanno iniziato a > > exploitarlo. > > A dire il vero, nel 2015 [1] [2] questa classe di bachi - intendo dire > vulnerabilità dovute alla deserializzazione - era stata evidenziata da > due professionisti Le due cose non sono mutualmente esclusive: il fatto che problema delle implementazioni della JNDI fosse noto, non implica che qualcuno abbia letto la documentazione di log4j, notato che che venivano usate nell'espansione dei pattern prima di scrivere i log e fatto due più due. O meglio, ripeto: diversi l'hanno fatto, ma non sappiamo chi o da quanto tempo sfruttassero questa vulnerabilità senza farsi notare. Naturalmente, avere tutte le uova in un solo paniere (i grandi cloud provider) avrà reso molto più facile la vita degli attaccanti (che hanno sicuramente avuto almeno diversi MESI per operare). Ora tutti faranno finta che non sia successo niente: aziende, Garanti della Privacy e Governi... Ma dopo un "incidente" come questo non devi solo reinstallare TUTTI i datacenter, ma ricontrollare anche tutti i log dei backup, gli archivi del software etc... I pivelli che compromettono un datacenter installano miner bitcoin. I professionisti cercano di raggiungere backup ed archivi dei clienti in modo da installarvi subito backdoor difficilmente individuabili e che verranno ripristinate anche in caso di ricostruzione complessiva del software del datacenter a partire dai sorgenti (cosa che tanto nessuno farà davvero). Di fronte a tutto ciò, favole come il "risk management" in InfoSec servono solo a garantire la sicurezza economica di chi le racconta. Ma in fondo è così che funziona il mercato, giusto? Costose favole hi-tech per soddisfare la domanda di rassicurazione. Giacomo [1] https://en.wikipedia.org/wiki/Factory_method_pattern _______________________________________________ nexa mailing list [email protected] https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
