Desde que se reveló la primera vulnerabilidad en la herramienta de registro Log4j de la Fundación Apache el 10 de diciembre, se han publicado tres actualizaciones a medida que se descubrieron vulnerabilidades adicionales. Esta rápida iteración de correcciones ha dejado a los desarrolladores de software y a las organizaciones de todo el mundo luchando por evaluar y mitigar su exposición con una guía que cambia casi a diario. Mientras tanto, hemos visto que los intentos de detectar o explotar la vulnerabilidad continúan sin parar.
A medida que transcurre la primera semana desde la exposición de la primera vulnerabilidad, SophosLabs ha continuado rastreando los intentos contra las redes de nuestros clientes para explotar Log4Shell. El tráfico que hemos observado incluye análisis benignos realizados por investigadores de seguridad y pentesters, así como actividad maliciosa, y no refleja directamente el estado de los intentos de los cibercriminales de explotar la vulnerabilidad. Pero a partir de partes de los datos, podemos saber lo suficiente sobre las solicitudes para tener una idea de la infraestructura involucrada en estos intentos y, en algunos casos, la intención detrás de ellos.
Lo cierto es que no hemos visto una reducción significativa en los intentos de exploits desde que alcanzaron su punto máximo el 15 de diciembre, y que estos sondeos y exploits provienen de una infraestructura distribuida globalmente. En algunos casos, una solicitud proviene de una dirección IP en una región geográfica, con URLs integradas para Log4j que se conectan a servidores en otros lugares, a veces varios servidores diferentes. Hemos visto millones de intentos entrantes de explotar Log4j en la telemetría del cliente.
¿Quién está detrás de esto?
Si bien no podemos distinguir la intención de cada solicitud, el segmento de nuestra telemetría que proporcionó detalles de tráfico proporciona una instantánea de la infraestructura involucrada en el abuso de Log4j. Al observar el origen de los intentos de paquetes abusivos hasta ahora, la gran mayoría proviene de direcciones IP en Rusia y China. Esto no incluye el tráfico que oculta su origen mediante el uso de redes privadas virtuales; una cantidad de tráfico estadísticamente significativa se enruta a través del punto de salida de NordVPN en Panamá, por ejemplo.
Del tráfico del que pudimos identificar una fuente, el 11% provino de una única dirección IP en Rusia: 195[.]54[.]160[.]149. Esta dirección IP se ha asociado con la botnet de minería de criptomonedas Kinsing.
Debido a la forma en que funcionan los exploits de Log4j, al solicitar “búsquedas” en servidores remotos a través de LDAP, DNS y otros protocolos compatibles con Java Name and Directory Interface (JNDI), las solicitudes de búsqueda se pueden dirigir a una ubicación diferente a la fuente del exploit. Por ejemplo, una solicitud enrutada a través del punto de salida de Panamá de NordVPN (94[.]140[.]9[.]194) utilizó una URL de solicitud que redirigió a una URL en Kenia (41[.]169[.]130[.]19:8443/api/login).
Casi dos tercios de estas solicitudes tenían URLs para infraestructuras en India. Y más del 40% tenía URL dirigidas a infraestructuras en los EEUU. Más del siete por ciento de las solicitudes de explotación se dirigieron al dominio de la herramienta Interactsh, el 18% de todo el tráfico a la infraestructura de EEUU. Los números en el cuadro a continuación suman más del 100% porque algunos intentos de explotación utilizaron múltiples URL con diferentes destinos.
Nota: Los porcentajes suman más del 100%, ya que se incluyen varias URL en algunos intentos de explotación.
Debido a que Interactsh ha sido utilizado tanto por investigadores como por ciberdelincuentes, es difícil separar lo benigno de lo malo, al igual que ocurre con gran parte del resto del tráfico que estamos detectando y bloqueando actualmente. Pero está claro que los intentos de explotación maliciosa siguen siendo la mayoría de este tráfico.
Mitigación y protección
Cuando se lanzó el primer parche para Log4j, el equipo de Apache ofreció una serie de soluciones para evitar la explotación. Pero todas estas correcciones resultaron ser discutibles a medida que se descubrieron rutas de vulnerabilidad adicionales. La única forma segura de protegerse contra la explotación, ya sea para obtener la ejecución remota de código o para causar la denegación de servicio, es actualizar el software para usar las versiones “seguras” actuales de Log4j (2.17.0 para Java 8, 2.12.3 para Java 7). Varias agencias gubernamentales de ciberseguridad mantienen una lista de productos comerciales vulnerables, incluida la Cybersecurity and Infrastructure Security Administration (CISA) de EEUU. Las organizaciones deben evaluar la vulnerabilidad de su software lo antes posible e implementar actualizaciones cuando sea posible.
Cuando las correcciones aún no están disponibles, las definiciones de filtrado de red protegerán contra un gran porcentaje del tráfico de exploits existente, pero no garantizan la protección contra amenazas emergentes y ataques altamente dirigidos.
Sophos continúa identificando nuevos métodos de ofuscación para explotar el tráfico y nuevas cargas útiles que se están implementando a través de exploits Log4j. Los siguientes son los identificadores de firma actuales publicados para los productos de protección contra intrusiones de Sophos (con los últimos en negrita), por producto, al 20 de diciembre:
| Producto | Identificaciones de firma publicadas |
|
XG
|
2306426, 2306427, 2306428, 58722, 58723, 58724, 58725, 58726, 58727, 58728, 58729, 58730, 58731, 58732, 58733, 58734, 58735, 58736, 58737, 58738, 58739, 58740, 58741, 58742, 58743, 58744, 58751, 58784, 58785, 58786, 58787, 58788, 58789, 58790, 58795, 58801, 58802, 58803, 58804, 58805, 58806, 58807, 58808, 58809, 58810, 58811, 58812, 58813 |
|
Endpoint IPS
|
2306426, 2306427, 2306428, 2306438, 2306439, 2306440, 2306441 |
|
SG
|
58722, 58723, 58724, 58725, 58726, 58727, 58728, 58729, 58730, 58731, 58732, 58733, 58734, 58735, 58736, 58737, 58738, 58739, 58740, 58741, 58742, 58743, 58744, 58751, 58784, 58785, 58786, 58787, 58788, 58789, 58790, 58795, 58801, 58802, 58803, 58804, 58805, 58806, 58807, 58808, 58809, 58810, 58811, 58812, 58813 |
Ten en cuenta que, en el caso de SG, las actualizaciones se encuentran en la próxima actualización de SG sigpack, que se publicará en breve.
La siguiente es una lista a partir del 20 de diciembre de todas las cargas útiles que Sophos ha detectado como parte de los intentos de explotación de Log4j (las nuevas cargas útiles están en negrita):
- Linux/Miner-ABU, Linux/Miner-ADH
- Linux/Swrort-G (“Mettle”)
- Troj/Ransom-GME (TellYouThePass ransomware)
- Troj/StealthL-A (Stealth Loader)
- App/StlthLdr-A (Stealth Loader installer, PUA)
- Mal/ExpJava-AL, Mal/ExpJava-AN, Mal/ExpJava-AO (Khonsari downloaders)
- Troj/JavaDl-AAN and Troj/Java-AIN (Khonsari downloaders)
- Troj/JavaDl-AAO (N0t4n3xplo1t.class)
- Troj/Mdrop-JMR, Troj/Mdrop-JMS, Troj/Mdrop-JMP
- Troj/Khonsari-A (new)
- Troj/JavaDl-AAN
- Troj/Java-AIN
- Troj/BatDl-GR
- Mal/JavaKC-B
- XMRig Miner (PUA)
- Troj/Bckdr-RYB
- Troj/PSDl-LR
- Mal/ShellDl-A
- Linux/DDoS-DT, Linux/DDoS-DS
- Linux/Miner-ADG, Linux/Miner-ZS, Linux/Miner-WU
- Linux/Rootkt-M
