Introducción
Hace poco más de un año que se hizo pública la infame vulnerabilidad log4j, que llevó a los equipos de seguridad a un frenesí de parches ante la inminencia de las vacaciones. La vulnerabilidad, denominada Log4Shell, es una vulnerabilidad crítica de ejecución remota de código (RCE) en la biblioteca de registro log4j de Apache. Permite a un actor de amenazas enviar una solicitud con una carga útil que, al ser registrada por una versión vulnerable de log4j, da lugar a la ejecución remota de código en el host. Además, la carga útil se ejecuta con permisos al nivel del usuario que ejecuta el servicio (otra razón más para evitar ejecutar servicios como `root`).
La vulnerabilidad recibió la puntuación CVSS más alta posible , 10, y se instó a los profesionales a parchear y actualizar inmediatamente los sistemas vulnerables. La ubicuidad de la biblioteca log4j -utilizada en diversas herramientas y productos- agravóla gravedad de la propia vulnerabilidad.
Mucho se ha escrito sobre esta vulnerabilidad desde su divulgación, incluyendo nuestra mirada inicial a la vulnerabilidad. Aquí presentamos nuestra investigación sobre cómo ha evolucionado la corrección de Log4Shell a lo largo del tiempo.
Medición de la respuesta de Internet a Log4Shell
En Censys, queríamos entender mejor cómo respondía Internet en su conjunto a esta vulnerabilidad. Para medir esto, identificamos un subconjunto de software visible en Censys cuyas versiones pudiéramos discernir y asignar a un estado de si es probablemente "vulnerable" o "no vulnerable" a Log4Shell. En concreto, examinamos hosts que ejecutaban software Metabase, Neo4j, Solr, Pagerduty y Unifi. El siguiente análisis no representa todos los dispositivos vulnerables a Log4Shell existentes, sino más bien lo que podemos ver a partir de nuestros escaneos pasivos de dispositivos orientados a Internet.
Las consecuencias inmediatas
Puede que reconozcas este gráfico si has visto nuestro Informe sobre el estado de Internet 2022 (y si no lo has hecho, puedes conseguir tu copia aquí). Como se comenta en el informe, la aplicación de parches tras la revelación fue rápida, y observamos un descenso del 34% en los dispositivos que ejecutan software que parece ser vulnerable a Log4Shell desde diciembre de 2021, cuando se reveló, hasta enero de 2022. Sin embargo, teníamos curiosidad por saber cuánto duraría esta sensación de urgencia.
Un año después
De diciembre de 2021 a diciembre de 2022, Censys observó un descenso del 78% en los hosts que parecen ejecutar software vulnerable a Log4Shell.
Aunque la tendencia general de disminución de las versiones vulnerables es prometedora, es preocupante que todavía haya más de 23.000 hosts visibles en Censys que parecen ser vulnerables. En diciembre de 2022, Wired señala que actores chinos e iraníes patrocinados por el Estado siguen explotando esta CVE. Es probable que los intentos de explotación tampoco se limiten a actores patrocinados por el Estado. A partir de este post, GreyNoise identifica 327 hosts que parecen estar escaneando activamente la vulnerabilidad log4j.
Vulnerabilidad por sistema autónomo y país
Al examinar los 10 principales sistemas autónomos en los que log4j parece seguir siendo vulnerable en diciembre de 2022, no es sorprendente ver dos AS propiedad de Amazon encabezando la lista, ya que son uno de los mayores propietarios de bienes inmuebles de Internet en términos de recuento de hosts y servicios. Otros proveedores de nube populares, como Digital Ocean, Microsoft, OVH, Google y Alibaba, también destacan en esta lista.
De forma similar a las observaciones de que Amazon tiene un gran número de servicios probablemente vulnerables a Log4Shell, no es sorprendente ver que EE.UU. encabeza la lista de países en los que observamos más servicios probablemente vulnerables. Sin embargo, si la distribución de los lugares en los que observamos versiones vulnerables de log4j reflejara la distribución de los lugares en los que observamos la mayor cantidad de servicios a nivel global, no esperaríamos ver a Brasil tan cerca de la cima de esta lista.
Conclusión
Aunque la comunidad de seguridad se unió hace un año para parchear y abordar la vulnerabilidad log4j, apodada "posiblemente la vulnerabilidad más grave de la historia", sigue siendo objeto de explotación y sigue siendo una herramienta valiosa en el conjunto de herramientas de un actor de amenazas. Un número no trivial de hosts sigue siendo vulnerable a la explotación. El mejor momento para parchear log4j fue hace un año, pero si está ejecutando una versión vulnerable, el segundo mejor momento es ahora.
Censys Los clientes de ASM tienen acceso a los riesgos del software tratado en este post.
