A veces, cuando una crisis de software no causa el tipo de devastación que todos esperan, es porque puede que no haya habido una crisis. Ese no es el caso con la vulnerabilidad Log4Shell encontrada en el software Apache Log4J ampliamente explotado a principios de diciembre de 2021. Aunque el mundo no ha visto la temida explotación masiva de la vulnerabilidad, el fallo Log4Shell, enterrado profundamente en muchas aplicaciones y productos, probablemente será un objetivo de explotación en los próximos años.
Sophos cree que la amenaza inmediata de que los atacantes explotaran masivamente Log4Shell se evitó porque la gravedad del error unió a las comunidades digital y de ciberseguridad y motivó a las personas a actuar. Esto se vio en 2000 con el error Y2K y parece haber marcado una diferencia significativa aquí.
Tan pronto como los detalles del error de Log4Shell quedaron claros, los servicios en la nube, los paquetes de software y las empresas más grandes e importantes del mundo tomaron medidas para alejarse del iceberg, con el apoyo de la inteligencia de amenazas compartida y la orientación práctica de la comunidad de ciberseguridad.
Al igual que otros en la industria de la ciberseguridad, Sophos ha seguido rastreando y monitoreando la amenaza. Vale la pena hacer un balance de cómo se han desarrollado las cosas desde el 9 de diciembre de 2021, lo que sabemos ahora y lo que prevemos para el futuro.
Escaneando los escáneres
La telemetría de Sophos en los escaneos de instancias expuestas de Log4J revela un patrón típico para una vulnerabilidad recientemente informada. En los primeros días, el volumen de escaneos fue moderado, lo que refleja el desarrollo temprano de exploits de prueba de concepto y el escaneo preliminar en línea para sistemas explotables.
En una semana, hubo un aumento significativo en las detecciones por escaneo, con números que alcanzaron su punto máximo entre el 20 y el 23 de diciembre de 2021.
Estos números sin duda incluían explotaciones exitosas pero aún no identificadas, criptomineros oportunistas, ciberdelincuentes apoyados por estados nacionales y otros que buscan encontrar y violar objetivos. Sin embargo, también vale la pena señalar que durante estos días a fines de diciembre, muchas empresas de seguridad aún estaban abiertas antes de las vacaciones y monitoreaban activamente la web.
En otras palabras, los números simplemente confirman que muchas personas, con buenas o malas intenciones, estaban tratando de medir el grado de vulnerabilidad de los demás ante la amenaza buscando el número de sistemas potencialmente expuestos.
Otro factor a considerar al evaluar los números de escaneo es que un fallo del tipo de Log4Shell se explota de manera diferente según la aplicación en la que se encuentra el código Log4J y cómo se ha integrado con esa aplicación. Esto da como resultado un gran volumen de escaneos redundantes que intentan diferentes formas de explotar diferentes aplicaciones.
Sin embargo, desde finales de diciembre hasta enero de 2022, la curva de intentos de ataque se estabilizó y disminuyó. Esto no significa que el nivel de amenaza también haya disminuido: en ese momento, un porcentaje cada vez mayor de detecciones probablemente eran ataques reales, y menos provenían de investigadores que monitoreaban el estado de parches más reciente.
Explotación Masiva Limitada
El número total de ataques exitosos hasta la fecha sigue siendo más bajo de lo esperado. La evidencia de esto se puede encontrar en primera línea. El Sophos Managed Threat Response Team (MTR) señala que, si bien el equipo detectó muchos escaneos e intentos de activar el exploit Log4Shell, a principios de enero de 2022 solo un puñado de clientes de MTR se enfrentaron a intentos de intrusión donde se determinó que Log4j era el punto de entrada inicial. La mayoría de estos eran criptomineros.
Otra posible razón para la explotación masiva limitada podría ser la necesidad de personalizar el ataque para cada aplicación que incluye el código Apache Log4J vulnerable.
En un extremo de la escala están las aplicaciones muy utilizadas que están expuestas a Internet y que deben actualizarse manualmente, una por una. Estas se están explotando a escala de forma automatizada. Un ejemplo de una aplicación de este tipo es VMware Horizon. La primera intrusión vista por Sophos MTR que aprovechó Log4Shell involucró a VMware Horizon.
En el otro extremo de la escala se encuentran muchas otras aplicaciones más oscuras que involucran a Apache Log4J que los atacantes tardarán en descubrir y explotar. Estos ataques se realizarán a un ritmo humano y no generarán picos gigantes de actividad, aunque seguirán presentando un riesgo significativo para las organizaciones que siguen siendo vulnerables.
La geografía de los intentos de ataque: antes y ahora
La telemetría de geolocalización de Sophos desde que se informó el error el 9 de diciembre de 2021 hasta finales de año y durante las dos primeras semanas de enero de 2022 muestra algunas variaciones interesantes en las fuentes de intentos de ataque y escaneos.
Si se observa el mapa de diciembre, cabe destacar que los principales países, entre los que se encuentran Estados Unidos, Rusia y China, así como los países de Europa Occidental y América Latina, suelen tener una gran población y una importante mano de obra cualificada en materia de ciberseguridad. Muchos de ellos también tienen una infraestructura digital bien establecida y son populares centros de hospedaje de Internet. Por ejemplo, la fuerte ponderación de Estados Unidos y Alemania en los datos de origen de la IP de geolocalización probablemente refleje los grandes centros de datos que se encuentran allí y que son operados por Amazon, Microsoft y Google, entre otros.
Este panorama cambia drásticamente a principios de 2022, ya que las detecciones de escaneo masivo dan paso a indicadores de sondeo y explotación más detallados.
La diferencia más notable entre los dos mapas es que el dominio inicial de Rusia y China parece haber disminuido en enero. Los datos de Sophos sugieren que esto refleja un aparente descenso en el número de intentos de ataque por parte de un pequeño número de criptomineros muy agresivos con base en estas regiones.
Es importante tener en cuenta que puede no haber una relación entre las IPs de origen que están escaneando o explotando la vulnerabilidad, y la ubicación real de los que están generando el tráfico. Una mejor visión podría ser el destino de las devoluciones de llamada.
La geografía de los destinos de las devoluciones de llamada
Al igual que los datos de la IP de origen, Sophos ha capturado los destinos de las devoluciones de llamada relacionadas con Log4Shell para finales de 2021 y principios de 2022. Hay menos variaciones a lo largo del tiempo, pero la imagen general es muy diferente a la de la ubicación de la IP de origen.
Los datos muestran los principales destinos en todo el mundo a los que llegan los dispositivos vulnerables (sin parches) para recuperar una carga útil de Java o para volcar información extraída de la máquina, como claves de seguridad de AWS u otras variables.
Mientras que Estados Unidos sigue siendo uno de los principales contendientes, esta visión lleva a la India a la posición número uno y destaca a Turquía, Brasil e incluso Australia. Es difícil especular por qué estas regiones son los principales destinos de las devoluciones de llamadas. Una de las razones podría ser que estos países tienen muchos participantes activos en programas de recompensas por fallos, con la esperanza de ganar dinero siendo los primeros en alertar a las organizaciones de que están expuestas.
La amenaza persiste
El hecho de que hayamos esquivado el iceberg no significa que estemos libres de riesgo.
Como otros han señalado, algunos de los escaneos de ataque iniciales pueden haber dado lugar a que los atacantes se aseguren el acceso a un objetivo vulnerable, pero no abusen realmente de ese acceso para entregar el malware, por ejemplo, por lo que la brecha exitosa sigue sin ser detectada.
En el pasado, Sophos ha observado que países como Irán y Corea del Norte se abalanzan sobre las vulnerabilidades de las VPN para acceder a las redes de los objetivos e instalar puertas traseras antes de que los objetivos hayan tenido la oportunidad de desplegar los parches, y luego esperan meses antes de utilizar ese acceso en un ataque.
En otro ejemplo, los atacantes se dirigieron a servidores Exchange vulnerables inmediatamente después de los primeros parches de ProxyLogon, dejando atrás shells web como puertas traseras para ataques posteriores. No bastaba con parchear el servidor Exchange, también había que eliminar las puertas traseras que instalaban.
Y aún hay más. Con el tiempo, es probable que las aplicaciones orientadas a Internet vulnerables a un exploit Log4Shell se identifiquen parcheadas o eliminadas. Sin embargo, es posible que nunca se conozcan o descubran los sistemas vulnerables internos desconocidos, que seguirán siendo un riesgo para la seguridad. La telemetría de Sophos muestra que el número de archivos Java vulnerables (JAR) en los endpoints protegidos por Sophos no ha cambiado. Estos podrían convertirse en una herramienta favorita para el movimiento lateral malicioso en el futuro.
Conclusión
Sophos cree que los intentos de explotación de la vulnerabilidad Log4Shell probablemente continuarán durante años y se convertirán en el objetivo favorito de los pentesters y de los actores de amenazas apoyados por estados nacionales. La urgencia de identificar dónde se utiliza en las aplicaciones y actualizar el software con el parche sigue siendo tan crítica como siempre.
Si aún no has visto nuestro webinar donde explicamos los detalles de esta vulnerabilidad puedes acceder aquí al contenido bajo demanda
Dejar un comentario