Vulnerabilidad en Apache Log4j 2

Se ha hecho pública una vulnerabilidad que afecta a la librería de registro de Java “Apache Log4j 2”, herramienta desarrollada por Apache Foundation que ayuda a los desarrolladores de software a escribir mensajes de registro, cuyo propósito es dejar constancia de una determinada transacción en tiempo de ejecución, además, Log4j permite filtrar los mensajes en función de su importancia.

La vulnerabilidad, a la que se le ha asignado el CVE-2021-44228 y denominada Log4Shell o LogJam, fue reportada el pasado 9 de diciembre por el ingeniero de ciberseguridad “p0rz9”, quien publicó un repositorio en GitHub anunciando su descubrimiento, así como una publicación en la red social Twitter en la que dio a conocer de manera pública la vulnerabilidad.

Una explotación exitosa de esta vulnerabilidad, que aprovecha una validación de entrada incorrecta al procesar solicitudes LDAP, permite la ejecución remota de código (RCE), haciéndose cargo del servidor, por lo que se compromete por completo la confidencialidad e integridad de los datos, así como la disponibilidad del sistema.

Recursos afectados:

La vulnerabilidad reportada afecta a las siguientes versiones:

• Apache Log4 desde la versión 2.0 hasta la versión 2.14.1.

Esta vulnerabilidad cobra relativa importancia puesto que “Log4j 2” se usa ampliamente en muchas aplicaciones y está presente, como dependencia, en muchos servicios:

• Nationaal Cyber Security Centrum (NCSC-NL): Listado de productos afectados

Solución a la vulnerabilidad:

• Actualizar la versión de Log4j. Apache ha publicado la versión 2.16 https://github.com/apache/logging-log4j2/blob/cffe58f6a433ea1ab60ceb129d4c9b3377acda1d/RELEASE-NOTES.md
• Para las versiones anteriores a la 2.10, revisar los ficheros de configuración buscando “log4j2.formatMsgNoLookups “ y la variable de entorno “LOG4J_FORMAT_MSG_NO_LOOKUPS “. Ambos deben estar a True.

Recomendaciones:

• Revisar si se está usando log4j:
  • PowerShell:
    • https://github.com/crypt0jan/log4j-powershell-checker
    • gci ‘C:\’ -rec -force -include *.jar -ea 0 | foreach {select-string «JndiLookup.class» $_} | select -exp Path
  • Linux:
    • find / 2>/dev/null -regex «.*.jar» -type f | xargs -I{} grep JndiLookup.class «{}»
• Revisar aplicaciones de Java:
  • https://github.com/logpresso/CVE-2021-44228-Scanner
  • https://github.com/hillu/local-log4j-vuln-scanner
  • https://github.com/mergebase/log4j-detector
• JAR file hashes:
  • https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• Class file hashes (2.15.0 no es vulnerable, pero está incluida):
  • https://gist.github.com/olliencc/8be866ae94b6bee107e3755fd1e9bf0d
• JAR and Class hashes:
  • https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228
• Escaneo de vulnerabilidad en Go:
  • https://github.com/hillu/local-log4j-vuln-scanner
• Conjunto de reglas YARA para la detección de versiones de “log4j” vulnerables a CVE-2021-44228 en base a la búsqueda de firmas relacionadas con versiones de JndiManager anteriores a 2.15.0:
  • https://github.com/darkarnium/CVE-2021-44228
• Revisar si se ha tenido un aumento de conexiones DNS.
  • Los intentos durante el fin de semana se han focalizado en el uso de las pruebas de concepto que explotan la vulnerabilidad conectando con servidores de DNS. Un aumento fuera de lo habitual en las conexiones salientes a DNS puede ser indicativo de explotación exitosa.
• Revisar en logs los siguientes IOC:
  • https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217
• Logs:
  • En caso de sospechas revisar los logs de las aplicaciones para buscar “jndi” se pueden apoyar en los siguientes scripts:
    • https://github.com/Neo23x0/log4shell-detector/
  • Tareas programadas:
    • Revisar en Windows si se han creado tareas programadas, y en Linux en el Cron.