Nota: Este post fue actualizado el 15 de diciembre de 2021 y de nuevo el 20 de diciembre de 2021.
Esta semana, hablaremos de la vulnerabilidad de Log4j2 que tiene a muchas organizaciones luchando por parchear sus sistemas, pero primero, abordaremos algunas preocupaciones de nuestros clientes con respecto a la vulnerabilidad.
Linode's Response To Log4j2
- Hemos evaluado a fondo el alcance del riesgo de esta vulnerabilidad crítica de día cero y su impacto en toda nuestra infraestructura en las primeras horas después de su publicación el viernes 10 de diciembre.
- Observamos los intentos fallidos de explotación con la ayuda de nuestra arquitectura de control de seguridad en profundidad.
- No hemos observado ningún indicador de compromiso relacionado con esta vulnerabilidad en nuestro entorno y estamos monitorizando continuamente nuestra infraestructura en busca de IoCs conocidos sobre esta vulnerabilidad y otras.
Vulnerabilidad crítica de ejecución de código remoto en Log4j2 (CVE-2021-44228)
Log4j2 es el sucesor de la utilidad de registro Log4j, utilizada habitualmente en Apache . Este componente está escrito en Java y forma parte de los servicios de registro de Apache . Según Oracle, Java Naming and Directory Interface (JNDI) es una interfaz de programación de aplicaciones (API) que proporciona funcionalidad de nombres y directorios a las aplicaciones escritas en Java.
La semana pasada, Apache publicó en su página de vulnerabilidades de seguridad de Log4j que las versiones de log4j-core entre 2.0-beta9 y 2.14.1 contienen una grave vulnerabilidad. Esta vulnerabilidad permite a los atacantes que pueden controlar los mensajes de registro o los parámetros de los mensajes de registro ejecutar código arbitrario cargado desde servidores LDAP. En la práctica, esto es explotable por atacantes externos. Esta vulnerabilidad fue calificada con una puntuación CVSS de 10 sobre 10 ya que permite a un atacante ejecutar código arbitrario en cada sistema afectado. Este problema está mitigado por la actualización 2.15, que deshabilitó el comportamiento de búsqueda de JNDI basándose en dos problemas de Jira a principios de diciembre y a finales de noviembre. Apache también lanzó la versión 2.17 para solucionar otros problemas que se encontraron posteriormente sobre el componente.
Efectos de la vulnerabilidad
Log4j2 es un popular marco de registro de Java utilizado por varios proveedores en numerosos productos. Esta vulnerabilidad puede ser fácilmente explotada manipulando la cadena User-Agent de las cabeceras de las peticiones HTTP y enviando la petición a los sistemas vulnerables. Aunque el User-Agent no es la única cabecera que puede utilizarse en este tipo de ataque, una carga útil maliciosa hará que el componente vulnerable Log4j2 active una búsqueda JNDI en el servidor malicioso. Cuando la URI maliciosa incrustada en las cabeceras HTTP contiene la ruta a un archivo de clase Java malicioso, este archivo se inyecta en el proceso del servidor y permite al atacante acceder al sistema afectado. Actualmente se están observando múltiples cargas útiles y desviaciones en la naturaleza, lo que hace más difícil protegerse contra ella utilizando mecanismos de defensa comunes.
Un diagrama del ataque
El siguiente diagrama del Equipo de Respuesta a Emergencias Informáticas del Gobierno Suizo puede ayudar a entender cómo funciona el ataque y cómo mitigarlo.
"Ataque a Log4j JNDI" por SGCERT está licenciado bajo CC BY-SA 4.0.
Productos afectados
Muchos proveedores han publicado declaraciones para ayudar a mitigar esta vulnerabilidad, y estas declaraciones podrían ser un recurso útil para nuestros clientes afectados. Puede encontrar los enlaces abajo para leer más sobre los productos afectados por los vendedores. Esta no es una lista completa de todos los productos afectados. Para una lista completa de los proveedores afectados y sus productos, puede ver la lista curada por SwitHak en Github u otra lista compartida por TechSolvency.
- Apache
- Atlassian
- Elastic
- Cisco
- CloudFlare
- Debian
- GitHub
- Minecraft
- Oracle
- RedHat
- Cebolla de seguridad
Métodos oficiales de mitigación
En la página de seguridad de Log4j, Apache afirma que hay varios métodos para solucionar esta vulnerabilidad, pero hay que tener en cuenta que estos métodos pueden no funcionar igual en todos los productos vulnerables. Consulte la declaración de seguridad del proveedor sobre la vulnerabilidad para obtener más información.
- Los usuarios de Java 8 (o posterior) deberían actualizar a la versión 2.17.0 para solucionar esta vulnerabilidad junto con otras recientemente encontradas.
- Los usuarios que necesiten Java 7 deben actualizarse a la versión 2.12.2.
- Si estos dos pasos no son posibles, la mitigación es eliminar la clase JndiLookup del classpath (mostrada como log4j-core-*.jar) usando un comando similar al que se muestra a continuación:
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.classEstamos orgullosos de compartir el conocimiento con nuestra comunidad para ayudarles a mitigar las vulnerabilidades, ya sean tan críticas como ésta o menos impactantes. No dudes en dejar un comentario a continuación para compartir tus opiniones y sugerencias.
Comentarios