Log4Shell: la vulnerabilità che ha ROTTO IL WEB

[@morrolinux]

🎓 Vuoi acquisire *solide conoscenze* nell'ambito del NETWORKING o diventare un LINUX SYSADMIN CERTIFICATO? Il modo migliore per cominciare è seguire un corso *ben strutturato e semplice da seguire* , per imparare al tuo ritmo e con i tuoi tempi, ma soprattutto tenuto da un docente sempre disponibile per *rispondere alle tue domande.* Tengo corsi per tutti i livelli, visita morrolinux.it/corsi per maggiori informazioni.

[@marcelloros1026]

già iscritto!!! Non vedo di seguirlo! Tutti i tuoi corsi mi stanno finalmente colmando lacune di era geologica!! Spero ne farai di nuovi, grazie infinite :)

[@marcoperiotto]

Ciao, puoi suggerirmi un testo universitario che si occupa di ingegneria informatica ? Grazie.

[@black-tooth-thin-rook]

facevo lo stesso con struts utilizzando urlclassloader facendogli caricare una classe che stava su un server mio pubblico... inoltre riuscivo a ridirezionare output direttamente nella finestra del browser usando il request dispatcher unica cosa tutto il codice iniettato nella url doveva essere url encoded ed ovviamente si potevano solo fare assegnamenti ed istanziare oggetti questa limitazione era imposta ovviamente dall'expression language assurdo che dopo anni che si parlava già di struts spring ed expression language injection log4j se ne esce con sta cosa ....

[@AndreaVenturi]

Ti sei laureato? Congratulazioni!

[@VitoMasciulli]

Una vulnerabilità "simile" a quella utilizzata in SQL injection. Interessante e allo stesso tempo inquietante. Chissà quante altre vulnerabilità di mancato controllo sintassi sono ancora latenti.

[@pierrezocco783]

Mi ha sminc****o in database che stavo creamdo

[@davidrop]

Che poi bastano 2 funzioni per proteggersi dall' sql injection ... una per il testo e una per i numeri

[@lumihasmilk]

Grazie Morro e Rev3rse, ho visto molte persone parlare a sproposito di Log4J pensando che fosse Log4J la cosa malevola e non Log4Shell. Per ora questo è l'unico video in Italia che specifica bene l'argomento. Ancora una volta: grazie

[@rev3rsesecurity]

Grazie!

[@nicolamurtas5467]

Concordo pienamente sull’analisi. Ringrazio quando mi hanno obbligato a ciclare tutti gli header di una chiamata che arrivava al server e prima di loggarli fare escape di tutto il contenuto in maniera preventiva. È per la cronaca quel server usava Log4j 😂

[@albertocanu]

Chiarissimo come al solito. Come non condividere al 100% quella "S". Questo è il problema di molte librerie che nascono per risolvere un problema e finiscono con il fare anche i cappuccini. Ho cominciato ad usare log4j più di 15 anni fa e anche se molto semplice era perfetta. Tra le altre cose, non so che ne pensiate, ma a me sembra che spesso i progetti che finiscono nella Apache Software Foundation tendono a soffrire di questo problema.

[@WolfrostWasTaken]

Ciò che dici è verissimo...

[@francescodemuro900]

Grazie. Spiegazione chiarissima. Complimenti a te ed al team di Reverse security. Buone feste a tutti voi.

[@nometutentegiapreso]

Premettendo che sul discorso single responsibility sono pienamente d'accordo e che la funzionalità non sarebbe proprio dovuta esistere, la cosa che più mi lascia allibito è che qualcuno abbia pensato che fosse una grande idea fare sì che la libreria reperisse delle classi Java serializzate da una fonte esterna senza un microgrammo di autenticazione dell'origine di queste classi. Per non parlare della sanificazione dell'input utente saltata a piè pari, oggi che per permettere una cosa simile (iniezione di codice tramite l'input utente) con gli ultimi framework per il web, tipo Angular, React, Vue, Django, etc., ti devi sforzare alla grande

[@WolfrostWasTaken]

Purtroppo Java è un linguaggio divorato da anni di boomerismo quindi scopriremo in futuro tantissime stronzate simili a questa in altre librerie. E' un triste destino, ma è ciò che ci attende

[@andreapazzo]

In realtà anche se usi framework frontend di ultima generazione, mai fare controlli solo lato pagina anche dei soli input utente. Se infatti comunichi con un backend tramite api, con un proxy (tipo burp) puoi intercettare e manipolare request e response..

[@giovannisardisco4541]

No, vabbé, ti sto amando per questa collab con Rev3rse 😍

[@giovannisardisco4541]

Io provo solo ad immaginare, per quanti anni gli "hacker cattivi" hanno ringraziato per tutto il pesce

[@DanieleO.]

Grazie per il video! Mi chiedo se fosse una feature che era lì da anni sotto il naso di tutti e qualcuno l'ha scoperta casualmente o se sia il risultato di una aggiornamento recente.

[@kaozlord76]

è inquietante, se però il server in questione fosse gestito da una politica di filtraggio di rete decente, firewall, sarebbe estremamente più difficile sfruttare questa vulnerabilità. Comunque bravi, avete spiegato in maniera semplice concetti complessi.

[@michelecasalino2569]

Complimenti Morro per la laurea e la spiegazione; sono sollevato di non aver dovuto fare i test per questa rogna (ho lavorato come tester per 6 anni e ho cambiato completamente mestiere l'anno scorso) e log4j era ovunque nei progetti in cui lavoravo.

[@daviderocchi4786]

Ciao, scusa la curiosità: che mestiere fai ora?

[@michelecasalino2569]

Faccio l’analista finanziario nel settore creditizio, tutta un’altra faccenda più in linea con i miei studi universitari ma l’informatica rimarrà sempre una delle mie passioni principali ma solo un hobby.

[@adcdsasa6526]

Bel video interessante.. Complimenti per la laurea... Buone feste anche a te

[@andreaturbati7404]

che poi la cosa "divertente" è che ad essere colpiti da questa vulnerabilità (estremamente grave) sono tutti quei servizi che, nel tempo, hanno aggiornato le librerie, visto che è una vulnerabilità di log4j dalla versione 2.0-alpha1 alla 2.16.0 (meno la 2.12.3) , cioè le versioni precedenti non hanno questa vulnerabilità (visto che, appunto, è stata una nuova feature introdotta, chissà come mai, dalla versione 2.x), quindi i servizi che ci sono in giro, magari non mantenuti e sviluppati molti anni fa, non hanno questo problema, mentre i servizi che sono stati aggiornati nel tempo, hanno introdotto una vulnerabilità che ha rischiato (e rischia ancora se uno non ha aggiornato le dipendenze in questi giorni) di dare il controllo totale o parziale del server a terze parti

[@lorenzofranzosa1780]

Più contenuti così Morro! Uno dei migliori canali di questo settore in Italia, bravissimo anche reverse security!

[@laboratorioassembler]

Ottima spiegazione :)

[@DomenicoUrso]

Credo che la questione sia così grave per le molteplici concause. Una applicazione BE che riesce a fare richieste (esterne) senza nessun limite? Siamo seri?

[@psykedady890]

altissima qualità del video wow grazie morro, grazie rev3rse!

[@stefanoromani1479]

Se vengono permesse certe schifezze non è un caso che l'injection sia ancora protagonista della top 10 OWASP.

[@robbroc]

I principi SOLID, sono come funghi, li trovi potenzialmente ovunque. Complimenti per la laurea e la collaborazione. (continuo a preferire lo sfondo di prima, lo scontornamento è ottimo, ma lo sfondo è molto artificiale )

[@kevinprevicini9909]

Finalmente youtube mi propone nella home video interessanti

[@ale.magaddino]

Grazie morro per avermi fatto conoscere il canale di reverse security 💪

[@massimo79mmm]

io mi chiedo il motivo per il quale in un pacchetto per il log devi inserire certe stronzate. ennesima prova del fattoche KISS è l’unico modo sicuro per lavorare

[@IenapixelChannel]

Complimenti per la laurea e grazie per questo video, del problema è un po' che se ne legge anche sui social ma questo video è stato particolarmente esplicativo, come sempre.

[@AntonioMusarra]

C’è da considerare il fatto che solitamente i server sono configurati per non comunicare direttamente con l’esterno, se sono in grado di comunicare verso l’esterno c’è già un problema di sicurezza.

[@WolfrostWasTaken]

Un webserver per sua stessa natura comunica con l'esterno

[@AntonioMusarra]

@@WolfrostWasTaken deve rispondere alle richieste esterne sulla porta https (443) ma non gli deve essere consentito di instaurare connessioni verso servizi esterni; così facendo non sarebbe possibile per esempio instaurare connessioni verso LDAP o qualunque altro servizio. Questa è la base per un sistema sicuro.

[@androumeda9538]

Se è un'architettura a microservices i server comunicano eccome con l'esterno. Certo si poteva pensare di bloccargli le porte Ldap, se non sono note necessità di usare nessun server Ldap nella nuvola di servizi. La cosa assurda è che codice Java facente parte di una libreria di log si metta a deserializzare risposte di servizi potenzialmente non trusted e generi addirittura istanze di oggetti da mandare in esecuzione, questo è veramente assurdo...qui la colpa è dell'ecosistema Java, non tanto della configurazione di sicurezza della rete

[@AntonioMusarra]

@@androumeda9538 si un server o un servizio può instaurare una connessione verso altri servizi ma queste devono essere governate. Solitamente per default tutte le connessioni in uscita non sono consentite, sono aperte solo quelle necessarie. Per quanto riguarda l'ecosistema Java, quest'ultimo offre il cosiddetto Java Security Manager che in molti purtroppo non utilizzano, questo permette tra le altre di cose d'impedire l'esecuzione di codice "malevolo". Per esempio Elasticsearch è riuscito a mitigare questo problema proprio perché fa uso del Java Security Manager. In definitiva, quello che voglio dire e che le buone pratiche di sicurezza devono essere applicate su ogni fronte, questo senza dubbio aiuta a mitigare gli eventuali bug di questo genere.

[@WolfrostWasTaken]

@@androumeda9538 Sul fatto che Java sia un vero schifo sotto questo fronte siamo d'accordissimo, ma è comunque possibile creare un network interno anche tra più macchine usando una vpn, in modo tale da far comunicare microservizi sparsi su più macchine senza dover necessariamente "aprirsi" al mondo esterno. Questo non serve se fai girare tutti i microservizi sulla stessa macchina oppure li replichi tali e quali su tutte le macchine

[@NFVblog]

Rieccoci dopo anni, dopo Shellshock nel 2014 adesso c'è Log4Shell, questo bug di log4j comunque ha fatto centinaia di danni che al momento non sono ancora calcolabili, onestamente sia shellshock sia questo Log4Shell portano a problemi molto simili, consentono tutti e due alla fine permettevano di far eseguire comandi arbitrari ed entrambi erano semplici da eseguire, anche una persona senza grossi competenze informatiche potrebbe tranquillamente tentale questo attacco

[@alerighi]

In ogni caso, questa sarebbe al limite della classificazione di vulnerabilità. Il problema è qua una cattiva pratica di programmazione, ovvero quella di costruire i messaggi di log andando a concatenare delle stringhe (cosa inefficiente) al posto di utilizzare delle stringhe template supportate dalla libreria stessa. Non è molto diverso dalla SQL injection alla fine, dove se non usi i prepared statement ma costruisci le query come stringa rischi gli stessi problemi.

[@NFVblog]

@@alerighi In tutti e due i casi abbiamo dovuto sopperire ad una pessima pratica di programmazione, perché alle volte certe funzioni andrebbero delegate ad altri servizi perché altrimenti si crea un buco di sicurezza grande come una casa. Anche SQL injection è molto semplice da fare, è quello il problema

[@micromymario23]

Ma l'output viene inviato ad una porta e ad un indirizzo così senza che il firewall controlli che sono richieste con destinazione diversa dal richiedente?

[@albertank]

Specializzazione is the way! Good work! ^_^

[@lupin281]

lo scopo della classe dell'LDAP che risponde alla query /Basic/Command/ls qual'è? Interfacciarsi con la shell del sistema sotto attacco (dopo che quest'ultimo l'ha involontariamente scaricata) ed eseguire il comando ls? Se è così tale classe è uguale per qualsiasi comando linux.... (sarebbe stato interessante anche il codice sorgente di tale classe)

[@dany2dany]

Congratulazioni per il conseguimento della lauerea. Ottimo video!

[@angelonunziolombardi]

grande, fai altri video cosi, sono interessato alla teoria delle falle di sicurezza

[@ptkdev]

Molto interessante, ma il 90% dei log in produzione che vengono fatti sono quasi sempre stringhe di errori, tipo un try / catch andato male. Non credo che in produzione ci siano log di questo tipo. A me hanno insegnato di loggare solo cose importanti sennò poi al minimo problema non trovi nulla, ma vista la qualità scarsa del software in linea generale non mi stupisco di nulla e che le vittime siano più di quello che dovrebbero essere. Aggiungo che molte volte prima di scrivere sul log il valore si è fatto un giro in vari parser di controllo o di validatori delle stringhe (tipo quando in un form metti la email, fai la validazione sia client che server e poi magari la scrivi su un log). Comunque sei sempre il mejo e auguri per la laurea!

[@nonpuoesserevero]

Sono già più tranquillo, non sono un programmatore Java e pertanto capisco fino ad un certo punto come si possano scaricare classi eseguibili così, mi piacerebbe approfondire ma per il momento non ho tempo, ma i log li creo sempre e solo da messaggi di try/catch o al massimo da stringhe fisse pre-impostate.

[@androumeda9538]

Il punto del problema è il principio SOLID che in questo caso è stato apertamente violato, fra l'altro da una libreria open source che fa parte dell'ecosistema Java, che da sempre guarda dall'alto in basso le altre parrocchie con la spocchia di quelli che la sanno più lunga. Se una cosa del genere succedeva in Serilog o Microsoft.Common.Logging apriti cielo, il titolo Microsoft in borsa cadeva sotto zero...

[@whit3wolf791]

daje, ci ho "solo" due settimane di lavoro a ripacchettizzare e rilasciare tutti i moduli ... e non ho ancora finito !

[@lupin281]

ciao, che software hai usato per gli appunti al minuto 1:14 ?

[@morrolinux]

Xournalpp

[@samueleabbate2230]

È un po come un xss reflected, basterebbe trasformarlo in stringa oppure fare semplicemente una pulizia del codice che arrivi prima che entri realmente nei log

[@kappino]

Non capisco perché il server esegue un comando che scrive nel log .. il log dovrebbe contenere informazioni e come tali non essere eseguibili

[@giorgionapoli85]

ahahahahahah!! grasse risate....eh io che pensavo di poterci capire qualcosa. Niente ragazzi, ci vediamo tra qualche anno. Torno a studiare!

[@giovanni.dandrea]

Hanno rilasciato 2 fix e anche una "Fix a caldo" sul parametro booleano da cambiare, ma niente. Perchè fare una libreria pura di logging quando posso metterci netcat e rompere le balls ai sysadmin? Bel video comunque.

[@androumeda9538]

si infatti non volevo crederci quando ho letto la descrizione dettagliata del problema. Che minchia c'entra la CLI con una libreria di log? Se uno ha bisogno di loggare l'albero genealogico di suo cugino estraendolo da un servizio Ldap, perchè una libreria di logging dovrebbe fornirgli l'aiutino? Non si puo' fare con una libreria dedicata che fa solo Ldap e poi passa il risultato serializzato opportunamente alla Log4J o Log4Net o qualsiasi altro package di logging della minchia buffa?

[@giovanni.dandrea]

@@androumeda9538 Evidentemente la pigrizia li ha portati ad implementare cose su altre cose senza rivedere la struttura dei componenti. Spesso nelle grandi società "Ha sempre funzionato" fa da padrone.

[@salvatorecampolo2032]

siete simpatici, soprattutto Andrea (e non solo per lo Spok-saluto), ma: 1. la frase "qui viene il bello" (della vulnerabilità, ndr) era più appropriata in "qui viene il brutto"; 2. sulle macchine non-embedded il problema è risolto solo parzialmente, sebbene Apache abbia rilasciato in rapida successione tre fix (v2.15.0, v.2.16.0 e v2.17.0), dei quali, i primi due nuovamente buggati; 3. sulla maggior parte dei device embedded (nel numero di alcuni miliardi, tra dispositivi normali e IoT) il problema appare irrisolvibile; 4. così come è corretto esplicitare, quando necessario (con gusto/sarcasmo), le cause/colpe ai sistemi closed-source, diciamo le cose come stanno: questa vulnerabilità deriva direttamente dai dettami (fortemente anarchici e superficiali) di una parte del mondo open-source. Saluti :-)

[@rev3rsesecurity]

deformazione professionale :)

[@androumeda9538]

condivido tutto. E' una vulnerabilità così banale da capire anche per profani di sicurezza (come il sottoscritto) che non volevo crederci. Di solito per capire come funziona uno di questi giochini da hacker bisogna come minimo essere degli azzuri di assembler e compilatori vari con codice arbitrario eseguito da qualche oscuro chip della scheda grafica, e qui bastano due minuti scarsi di spiegazione banale per arrivare al punto. Grazie piccolo antico Java, e un grazie ancora più sentito alla tua spocchia ;-)

[@anocco]

Auguri di buone feste e per la tua laurea 🎓! Sarebbe bello un video se ti va su SOLID. Saluti

[@KastriotLleshi_homepage]

Congratulazioni per la Laurea, hai raggiunto un'altro bel traguardo! Per il video non dico niente, più chiaro di così

[@loreck7943]

Ottimo video e spiegazione impeccabile,,, Congratulazioni per la laurea! Ps: Potresti farci una recensione di Parrot Home Edition? So che le disro Debian based le trovi noiose, ma sarei curioso di sapere cosa ne pensi e come la valuti…

[@domenicocostantino503]

ei ciao sei bravissimo ti volevo chiedere se e possibile installare su un asus. chromebit una distro piu completa di chrome os , come si fa?

[@danielecarollo2598]

Video chiarissimo. Grazie Morro!

[@rockessence]

Che sia così che l'8 dicembre 2021 hanno cambiato le musiche natalizie dell'impianto audio stradale del comune di Vieste con degli inconfondibili gemiti di piacere?

[@emilie1977]

Ottimo e iscritta anche all'altro canale. Buone Feste e complimenti per la laurea! ps. in cosa ti sei laureato?

[@giovannisardisco4541]

Credo Filologia germanica

[@Zkhere]

@@giovannisardisco4541 sicuramente

[@emilie1977]

@@Zkhere lauree ce ne sono molte in ambito informatico, e poi mi piacerebbe parlasse anche della sua tesi

[@emilie1977]

@@giovannisardisco4541 ahahaha, grazie della risata

[@Jonathan1981it]

Video stupendo... grandiosi.

[@Savatore83]

concordo, log4j dovrebbe fare il log, se voglio la funzionalità jndi dovrei poter integrare la libreria

[@snowbeat936]

Mi chiedo ma sono ancora in tanti ad usare java per gli applicativi web?

[@andreadelbene730]

Mi viene male pensando a tutta la roba che con Docker e compagnia cantante usiamo "così com'è"...chissà quante insidie si nascondono anche li 😞

[@myfunkybeat]

Bravo Morro, e grazie!

[@alessandrocarlin2213]

Lavorando come sviluppatore posso capire che abbiano voluto semplificare la vita ad altri sviluppatori e per mantenere la retrocompatibilita probabilmente abbiano tenuto attiva quella feature. Spesso i progetti sono fatti di fretta e non vi è molto tempo per guardare e spulciare tutte le features di tutte le librerie che si includono nel progetto.

[@wmacosx]

Non mi capacito di come sia stato possibile ignorare questa cosa fino ad ora. Sono uno sviluppatore medio, molti degli exploit "complessi" faccio fatica a capirli senza perderci troppo tempo, ma questo è quasi ridicolo, se avessi lavorato nel mondo java e avessi saputo dell'esistenza di JNDI penso che ci sarei arrivato anche io. Also congratulazioni per la laurea!

[@EgidioSuriano]

Morro, per la serie "chi si fa i cassi suoi campa cent'anni". Video molto esplicativo, complimenti!!!

[@dillon1977]

Di base manca una cosa fondamentale: Test Driven Development...

[@DenisSoiMi]

Ciao Morro e complimenti, sia per la laurea che per il canale. Butto i miei 2 chicchi di riso nella discussione. Faccio notare che il problema dell'aggiornamento é molto piú insidioso di quanto puó sembrare poiché la libreria viene usata in uno sproposito di altre librerie java, che vanno dalla manipolazione dei pdf, al reporting, al networking, etc... Anche tutte queste librerie devono essere aggiornate, prima dai mantainer (sempre che siano attivi) e successivamente da chi gestisce l'applicativo. Altra considerazione é quella della estrema pigrizia e a volte dell'ignoranza di alcuni programmatori, che usano la prima libreria che trovano, anche per i compiti piú banali. Nello specifico mi chiedo se sia sensato usare una libreria esterna per gestire dei banali log ?

[@wmacosx]

d'accordo con tutto tranne che con "mi chiedo se sia sensato usare una libreria esterna per gestire dei banali log", se l'unica cosa che ti serve è scrivere del testo in un file al fine di guardarci all'occorrenza "a occhio" ok... ma se hai bisogno di log formattati in un certo modo, uniformi tra più sistemi, che vengono raccolti e analizzati in automatico ecc ecc ecc, usare una libreria esterna, soprattutto se molto famosa e diffusa mi sembra una scelta sensata

[@DenisSoiMi]

@@wmacosx Io risolvo con pochi e semplici metodi statici che poi copio incollo da un progetto all'altro. Se non ci sono esigenze particolari...

[@iacopociao5232]

@@DenisSoiMi così ogni volta che devi apportare una fix devi replicarla in tutti i progetti in cui hai copia-incollato quel codice... a patto che siano allineati sulle fix precedenti e che quel codice di quel determinato progetto non abbia subito variazioni tali da rendere più macchinosa (se non impossibile) l'applicazione della modifica, perché magari era più comoda una formattazione rispetto a quella iniziale o chissà che altro... Le librerie esistono proprio per ovviare a questo tipo di problemi e a molti altri, non perché la gente si sveglia la mattina e non sa che cosa fare... I framework e le librerie non sono pallottole d'argento come non lo è reinventare la ruota o, peggio ancora, inventarla di nuovo e copiarla a macchia d'olio apportando modifiche specifiche per il progetto di destinazione. Ci vuole buon senso, come in tutte le cose della vita.

[@DenisSoiMi]

@@iacopociao5232 Quello é il modo in cui ho risolto io il problema dei log. Altri potrebbero fare con una propria libreria. Il concetto che volevo esprimere é che ci sono cose molto banali per le quali scrivere poche righe di codice ha solo vantaggi.

[@A5A5A5A5h]

Secondo me sottovaluti l'operazione di log. Fare logging non significa solo scrivere in stdout o in un file. Loggare un programma significa gestire una critical section/mutex, gestire richieste asincrone, gestire la rotazione dei log, gestire il timestamp su piu' piattaforme e tante altre cose che adesso non mi vengono in mente. D'accordo che Log4J ha esagerato con le funzionalita', ma non utilizzare affatto una libreria(dunque loggare tutto a mano) e' un'impresa assurda.

[@shaice]

Complimenti per la laurea!!!! A quando il dottorato? :-)

[@LucaCanali]

un po come va systemd e una parte del motivo per cui è nata devuan ✊

[@tommysteven89]

ok era già interessante, ma appena ho visto la maglia con la DeLorean con l'albero di natale il follow è stato automatico

[@gaetanov62]

Ciao Moreno, vorrei sapere se l'iscrizione a uno dei tuoi corsi sarebbe possibile pagarla con PayPal, grazie.

[@morrolinux]

Ciao, sì nessun problema puoi usare PayPal 🙂

[@morenomeschieri5761]

Grazie mille per il video. Molto chiaro.

[@exedes185]

ho installato l ultima patch per uno dei miei server ieri sera ... disastro

[@marcodepe]

Domanda banale. La risoluzione jndi è di default su tutte le versioni? Grazie

[@silversurfer2017]

domanda fondamentale, invece. infatti la vulnerabilità in questione affligge solo le versioni dalla 2.0-beta9 alla 2.15.0.

[@marcodepe]

@@silversurfer2017 grazie 1000. Dove è scritto tanto per chiudere il cerchio? Come diavolo han fatto a vederla solo ora? Sembra una vulnerabilità evidente...

[@Wrynard]

Non voglio essere quel tipo di persona che vuole attenzione o roba del genere, ma forse sarebbe interessante fare un paragone tra Mageia e OpenMandriva, tutt'e due queste distro sono derivate dalla distro Mandriva (o Mandrake), conosciuta fino al 2011, l'anno della fine dello sviluppamento. Mageia è la distro dalla maggior parte dei dev di Mandriva, mentre la community e il resto degli altri dev sono su OpenMandriva. Almeno spero.

[@SonoAX]

Lo sapete che questa vulnerabilità ha colpito tantissimi giochi come minecraft solo che in quel campo lo chiamano RCE e non Log4shell ed moltissimi player/server soffrono ancora di questo perché in alcuni casi dei player mettevano questo comando nella chat potevano anche installare virus nella macchina di tutti gli altri giocatori. Meno male che tutto questo è stato risolto!

[@nexdrums]

Abbiano installato la 2.17 ovunque! 🤟🏻

[@sbeng77]

Al minuto 5:28 che interfaccia è?

[@rev3rsesecurity]

vscode e la shell è zsh con ohmyzsh 👍🏻

[@giuseppetrapani4579]

Morro quale distro usi principalmente?

[@RiccardoMartinelli_Rick]

Video interessantissimo! Complimenti

[@RiccardoCosenza]

Qualcuno prima di adesso aveva scritto del rischio di questa funzionalità di log4j ?

[@morrolinux]

Si, dei ricercatori nell'ambito della sicurezza, nel 2016 avevano segnalato la possibiltà di problemi... Sono stati ignorati evidentemente

[@spinanico]

Decisamente d'accordo sulle singole responsabilità.

[@cocciasecca]

Congrats per la laurea!!

[@vale461mitoMedia]

Quindi si può dire che LOG4J rompe completamente il principio di SRP, praticamente il primo principio SOLID

[@finmat95]

"Ogni componente software non dovrebbe risolvere più di un problema" è un concetto si affianca al principio del minimo privilegio?

[@ant7827]

Più al concetto del KISS.

[@lylluzzos]

Più funzionalità introduci all'interno del tuo software, maggiore sarà la superficie d'attacco... Vero systemd?

[@iegos]

Che falla clamorosa! Quindi se uno smanettone potrebbe decidere di usare un server web per far partire una chiamata verso un qualsiasi altro server anche di dominio diverso? Sarebbe come dire che faccio una post su un web server, mi attacco al suo lpdap e mi faccio mandare indietro le password di admin? Il tutto senza che log4shell faccia una autenticazione preliminare sul server a cui inoltra la richiesta? A questo punto mi scrivo io una classe che fa il log degli accessi e non uso le librerie gratuite.

[@user-yj3pg9ee8v]

Bravo ottimo video

[@edoardo7570]

Grazie!

[@mattealex]

Buone feste

[@migianaventura]

Buen vidio ! Gracias

[@alessandrochiri6315]

È bastato disabilitare la lookup e cancellare il file log4j-core

[@Covid-st5ts]

E Morrino si è laureato... Auguri

[@MarcoFranceschini1971]

Io parlerei di "crackerare" dato che gli hacker hanno un'etica di base.

[@xgab0320]

Mi sono dovuto alzare dal letto all'una di notte e stare fino a quasi le quattro per colpa di questo exploit, da spararsi

[@A5A5A5A5h]

Al tuo posto chiudevo il firewall e ci pensavo il giorno dopo :D

[@euxheniodragoj2806]

Porta 1337

[@rev3rsesecurity]

una certezza! :)

[@fremsoft]

Che meraviglia! 🥳 Per fortuna che Java nacque principalmente per garantire la sicurezza

[@wallalo]

fischia e per fortuna che l'open source dovrebbe garantire sw migliore, uaz uaz uaz

[@emilioscaccaglia6134]

bravo!

[@Fabio286]

Per una volta non mi sentirò criticato in determinati ambienti per non adottare Java nello sviluppo software 😂

[@simonecelia5950]

nonostante quanto accaduto rimane l'ambiente più sicuro

[@Fabio286]

@@simonecelia5950 io sono del parere che l'ambiente più sicuro è quello che lo sviluppatore conosce meglio, a prescindere dal linguaggio.

[@androumeda9538]

@@simonecelia5950 guarda...se dici che è il più sicuro perchè tutte le banche lo usano per i loro portaloni, vabbè...diciamo che è solo più legacy e c'è più probabilità che le falle siano state scoperte. Ma cosa abbia Java di intrinseco che garantisca maggiore sicurezza, devo ancora capirlo. E non ditemi che è perchè c'è la Jvm, dai...

[@DiegoRegina]

Scusa… ti sei laureato e lo dici così?! Congratulazioni Morro!

[@Yep6803]

Stima per l'hacker ha MacOS(non lo dico a caso), non serve Linux ma competenza! Molti usano Kali pensando di fare i fighi...raga, si hackera anche da Windows.

[@noisiamo42]

Smoker di one piece ha un frutto potentissimo, ma si espone troppo xD

[@norelife999kjghgjhfg]

pollice in su per la tua laurea...immagino in farmacologia? scherzo ovviamente, basta che non ci abbandoni per il vibrante mondo del lavoro in cui il rispetto e cura per l'impiegato sono la priorità.... continuo a confondere realtà e vecchi episodi di "ai confini della realtà", vabbè comunque auguri!

[@thenewmidiera]

Una naming injection

[@flow3631]

io uso un plugin per bloccare questa vulnerabilità sul mio server minecraft :)

[@alexxxx334]

Io cosi ho clonato la carta dirindirnda'.

[@goodfella8131]

Ad maiora!

[@FreddyOneKenobi]

Ha rotto il web e le nostre pelotas 🤣

[@davidrop]

Ma roba da matti... ecco perchè odio le cose fatte da qualcun altro... con quello che ci vuole ad appendere una riga ad un file di testo. Non ho mai usato nessun tool, ho eliminato anche jquery che è 100 volte più lento del javascript puro. Gia si combatte contro se stessi figurati se mi devo mettere a combattere contro 10 tools... la cosa più divertente sono le vulnerabilità di cose tipo wordpress ... una volta scoperta la vulnerabilità basta usare google per sapere chi attaccare. Per non parlare del fatto che continuando ad usare programmi fatti da altri non miglioriamo perché le cose complicate ce le facciamo fare da altri e non ci sbattiamo la testa da soli