Log4Shell – Log4J CVE-2021-44228 (ITA)

Guarda su YouTube → 26:26 12 dicembre 2021

Cybersecurity

Descrizione

In questo video descrivo la CVE-2021-44228, una recente vulnerabilità scoperta in log4j, una libreria molto famosa utilizzata per gestire i file di log delle applicazioni java. ------------------------- TIMESTAMP 00:00 introduzione alla CVE-2021-44228 01:33 requisiti necessari per l'attacco 03:30 exploitation (in teoria) 10:43 exploitation (in pratica) 23:00 conclusione ------------------------- RIFERIMENTI - https://www.lunasec.io/docs/blog/log4j-zero-day/ - https://github.com/christophetd/log4shell-vulnerable-app - https://github.com/feihong-cs/JNDIExploit - https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ - https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/ - https://y4y.space/2021/12/10/log4j-analysis-more-jndi-injection/ - https://christine.website/blog/open-source-broken-2021-12-11 - https://blog.filippo.io/professional-maintainers/ ------------------------- CONTATTI - Technical blog: https://blog.leonardotamiano.xyz/ - Github: https://github.com/LeonardoE95?tab=repositories - Support my work: https://www.paypal.com/donate/?hosted_button_id=T49GUPRXALYTQ

Commenti 19

I commenti vengono da YouTube e sono aggiornati periodicamente.

@esadecimale Autore 14 dicembre 2021

UPDATE: A quanto pare è stata rilasciata un’ultima patch per log4j versione 2.16.0. Questa patch rimuove completamente il meccanismo di JNDI lookup() che ha causato la CVE-2021-44228. Questo cambiamento è descritto nel change log, disponibile qui https://lists.apache.org/thread/d6v4r6nosxysyq9rvnr779336yf0woz4 Come “hardening changes”, ovvero viene fatto proprio per aumentare il livello di sicurezza, e non è strettamente necessario per eliminare la particolare vulnerabilità che ha causato la Log4Shell, in quanto per quello basta la 2.15.x. UPDATE 2: in realtà sembra che la 2.15.0 sia proprio vulnerabile ad altri attacchi, quindi patchare è un must. https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/ In ultima analisi, la versione sicura è la 2.16.0. UPDATE 3: hanno trovato proprio una RCE anche per la versione 2.15.0 https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/ Quindi, nuovamente, fate upgrade alla 2.16.0
@gregandark8571 16 febbraio 2022 2

Signor Leonardo Tamiano lei è un genio del Kamasutra informatico !!!
@LucaCanali 13 dicembre 2021 1

😱 non posso distrarmi un attimo che mi pubblichi video a profusione 🤪 Bellissimo video 💪
@fabiospadaro4400 16 gennaio 2022 1

Bravo, molto chiaro
@ytbison 1 febbraio 2023

Grazie bellissimi tutorial
@Xaero3169 14 dicembre 2021 1

recuperato grazie.
@micky_3432 13 dicembre 2021 1

Bel video Leo!
1 risposta
1. @esadecimale Autore 14 dicembre 2021
  
  Grande bro :D
@hamzacod8178 15 dicembre 2021 1

Buongiorno, avrei una domanda. Ma un apache server con applicativi non java spring al suo interno, è vulnerabile?
1 risposta
1. @esadecimale Autore 15 dicembre 2021
  
  No, non dovrebbe, sia apache httpd (che se non sbaglio è scritto in C), e sia tomcat non dovrebbero essere vulnerabili a log4j. Il problema sono tutte le applicazioni scritte in Java. Comunque c’è una lista di software compromessi: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md Sicuramente ce ne sono varie, quindi bisogna stare attenti e continuare ad informarsi
@Angelo-is2im 14 marzo 2022

Mirai aggiornata con log4 hihi
@Xaero3169 14 dicembre 2021 1

Ottima guida, puoi codividere JNDIExploit, è stato rimosso...
1 risposta
1. @esadecimale Autore 14 dicembre 2021
  
  Guarda ti consiglio anche di guardare questo tool molto interessante https://github.com/mbechler/marshalsec/ può essere utilizzato per generare un server LDAP che fa fa il redirect ad una particolare path .class nel server web. Il tool è utilizzato in quest'altro video che ho trovato su Log4Shell https://youtu.be/FJsJR0Iu5J4?t=933
@hamzacod8178 14 dicembre 2021 1

Ciao bel video, vorrei chiederti una domanda a cui non trovo risposta su internet. Supponiamo che il mio server abbia ricevuto una request di tipo Get con la stringa malevola, come posso sapere dai log di java spring se il server ha fatto effettivamente un redirect?
2 risposte
1. @esadecimale Autore 14 dicembre 2021 1
  
  Per questo vengono utilizzati dei servizi di dns logging. Della serie: provi ad attaccare con un payload contenente un particolare dominio che hai registrato esclusivamente pe sta cosa con un nome strano tipo “dhkskans.com”, e poi vedi se e quando qualche server ha provato a risolvere quel dominio. Tipicamente viene utilizzato come servizio di dns il seguente sito: https://canarytokens.org/generate Io non lo utilizzo ma il sito ti dovrebbe permette di essere notificato quando qualcuno prova a risolvere il particolare nome di dominio immesso
2. @cheatisawesome1645 20 dicembre 2021
  
  Il log è parlante, se non è riuscito ad effettuare il redirect uscirà un bel "connection timeout"
@shadmanaripen3600 13 dicembre 2021 1

video utile, ma ci puoi mostrare come fare l'upgrade alla versione 2.15 in modo sicuro?
1 risposta
1. @esadecimale Autore 13 dicembre 2021
  
  Premetto che non sono un sistemista dunque prendi le mie parole con la giusta dose di scetticismo. Secondo me il problema di fare l’upgrade non è tanto aggiornare il software in sé (log4j in questo caso), quanto piuttosto tutti gli altri software che lo utilizzano a loro volta. I sistemi, e soprattutto quelli legacy, sono un intreccio di dipendenze che finché funzionano va tutto bene, ma quando poi cambi una versione di un pacchetto potresti rompere il funzionamento dell’intero sistema. Il vero problema di queste cose poi è che ogni sistema è unico ed ha le proprie dipendenze, dunque il patching sarà diverso in ogni sistema. In alcuni potrebbe essere tanto semplice quanto aggiornare log4j scaricando l’ultima versione resa disponibile su Maven, in altri però aggiornare log4j potrebbe non far funzionare altri componenti del sistema. Insomma, è un bel casino. Lascio qui comunque delle risorse: per quanto riguarda l’aggiornamento alla nuova versione, si possono utilizzare i package manager quali maven e gradle come spiegato nel seguente articolo https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot Per chiunque non riuscisse ad aggiornare il software invece è consigliato settare la proprietà ‘log4j2.formatMsgNoLookups‘ a True quando si lancia il processo Java, come java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar Se ho capito bene il setting di questa proprietà evita di chiamare il JNDI_lookup() quando si processano stringhe con quel payload malevolo (dollaro, jndi etc etc)
@levistray5708 27 dicembre 2021

Il video é solo a scopo informativo