Se ha estado hablando mucho en la red sobre la vulnerabilidad en Log4J que permite a un atacante desencadenar una ejecución de código arbitrario de forma remota si tiene la capacidad de enviar datos a una aplicación que utiliza la biblioteca log4j para registrar el evento.
Este ataque se puede realizar sin estar autenticado, por ejemplo, aprovechando una página de autenticación que registra los errores de autenticación.
Este fallo ha puesto a las empresas especializadas en ciberseguridad a trabajar en el suceso e indican que la cantidad de ataques que aprovechan esta falla está aumentando.
Los miembros de Apache Software Foundation han desarrollado un parche para poder corregir la vulnerabilidad y es la versión 2.15.0, además de que también se han dado a conocer posibles soluciones para reducir los riesgos.
¿Qué es Apache Log4j? ¿Qué tan grave es la falla?
Para quienes aún desconocen de lo grave que es el problema, puedo comentarles que el 9 de diciembre, se descubrió una vulnerabilidad en la biblioteca de registros log4j de Apache.
Esta biblioteca se utiliza ampliamente en proyectos de desarrollo de aplicaciones Java/J2EE, así como en los proveedores de soluciones de software estándar basadas en Java/J2EE.
Log4j incluye un mecanismo de búsqueda que podría usarse para realizar consultas a través de una sintaxis especial en una cadena de formato. Por ejemplo, se puede utilizar para solicitar varios parámetros como la versión del entorno Java a través de$ {java:version}etc.
Luego especificando la clave jndi en la cadena, el mecanismo de búsqueda utiliza la API JNDI. De forma predeterminada, todas las solicitudes se realizan con el prefijo java:comp/env/*; sin embargo, los autores implementaron la opción de usar un prefijo personalizado usando un símbolo de dos puntos en la clave.
Aquí es donde radica la vulnerabilidad: sijndi:ldap:// se utiliza como clave, la solicitud va al servidor LDAP especificado. También se pueden utilizar otros protocolos de comunicación, como LDAPS, DNS y RMI.
Por lo tanto, un servidor remoto controlado por un atacante podría devolver un objeto a un servidor vulnerable, lo que podría provocar la ejecución de código arbitrario en el sistema o la filtración de datos confidenciales.
Todo lo que un atacante tiene que hacer es enviar una cadena especial a través del mecanismo que escribe esta cadena en un archivo de registro y, por lo tanto, es administrada por la biblioteca Log4j.
Esto se puede hacer con solicitudes HTTP simples, por ejemplo, las enviadas a través de formularios web, campos de datos, etc., o con cualquier otro tipo de interacciones utilizando el registro del lado del servidor.
Tenable caracterizó la vulnerabilidad como «la vulnerabilidad más importante y crítica de la última década».
Ya se ha publicado la prueba de concepto. Esta vulnerabilidad ahora se explota activamente.
La gravedad de la vulnerabilidad es de un máximo de 10 en la escala CVSS.
Aquí está la lista de sistemas afectados:
- Apache Log4j versiones 2.0 a 2.14.1
- Apache Log4j versiones 1.x (versiones obsoletas) sujetas a configuración especial.
- Productos que utilizan una versión vulnerable de Apache Log4j: los CERT nacionales europeos mantienen una lista completa de productos y su estado de vulnerabilidad
CERT-FR recomienda realizar un análisis exhaustivo de los registros de la red. Las siguientes razones pueden usarse para identificar un intento de aprovechar esta vulnerabilidad cuando se usa en URL o ciertos encabezados HTTP como usuario-agente
Finalmente cabe mencionar que se recomienda encarecidamente utilizar la versión 2.15.0 de log4j lo antes posible.
Sin embargo, en caso de dificultades para migrar a esta versión, las siguientes soluciones se pueden aplicar temporalmente:
Para las aplicaciones que utilizan las versiones 2.7.0 y posteriores de la biblioteca log4j, es posible protegerse contra cualquier ataque modificando el formato de los eventos que se registrarán con la sintaxis% m {nolookups} para los datos que proporcionaría el usuario.
Esta modificación requiere modificar el archivo de configuración log4j para producir una nueva versión de la aplicación. Por lo tanto, esto requiere volver a realizar los pasos de validación técnica y funcional antes del despliegue de esta nueva versión.
Para las aplicaciones que utilizan las versiones 2.10.0 y posteriores de la biblioteca log4j, también es posible protegerse contra cualquier ataque cambiando el parámetro de configuración log4j2.formatMsgNoLo