La crisis de seguridad de Log4j se agudizó esta semana cuando los investigadores descubrieron que la primera solución para la vulnerabilidad crítica de Log4Shell no eliminaba por completo el comportamiento peligroso, los proveedores de software emitieron actualizaciones repetidas y el gobierno de EE. UU. ordenó a las agencias federales civiles que identificaran y remediaran los sistemas vulnerables con carácter de urgencia.
La vulnerabilidad original, CVE-2021-44228, permite a los atacantes, en muchas circunstancias, ejecutar código de forma remota mediante texto especialmente diseñado y procesado por Apache Log4j, un componente de registro integrado en todo el ecosistema de software Java. La Apache Software Foundation declaró el martes que Log4j 2.15.0, lanzado para solucionar la vulnerabilidad inicial, no protegía completamente contra ciertas configuraciones de ataque, lo que dio lugar a una segunda vulnerabilidad, CVE-2021-45046, y a la recomendación de actualizar a versiones más recientes.
Una emergencia se convierte en una carrera por solucionar problemas
El problema técnico es particularmente complejo porque Log4j suele estar ubicado varias capas por debajo de las aplicaciones que las organizaciones compran y utilizan. Una empresa puede no implementar la biblioteca a sabiendas mientras sigue utilizando productos comerciales, aplicaciones internas o servicios en la nube que la contienen. Esto hace que los inventarios de software y la comunicación con los proveedores sean tan importantes como el propio parche.
La alerta de seguridad de Oracle se revisó a medida que la empresa evaluaba sus productos y publicaba correcciones. El aviso de seguridad también ilustra la magnitud del trabajo: un proveedor de gran tamaño debe examinar extensas carteras de productos, determinar qué productos contienen versiones vulnerables y, posteriormente, proporcionar a los clientes soluciones específicas para cada producto.
Los distribuidores de Linux también han tenido que responder a la vulnerabilidad subsiguiente. El aviso CVE de Ubuntu, publicado el martes, documenta los paquetes y actualizaciones afectados para CVE-2021-45046. La rápida sucesión de divulgaciones implica que los administradores que aplicaron parches tempranamente no pueden dar por sentado que la primera actualización haya solucionado el problema.
CISA convierte la guía en una directiva federal
El viernes, la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) emitió una directiva de emergencia que exige a las agencias civiles federales que actúen. En su boletín del 17 de diciembre, la CISA ordenó a las agencias que identifiquen los productos afectados, apliquen las medidas de mitigación y los parches proporcionados por los proveedores y retiren del servicio el software vulnerable cuando no haya soluciones disponibles.
La directiva refleja la evidencia de que la explotación no es hipotética. Los atacantes comenzaron a buscar sistemas expuestos casi inmediatamente después de su divulgación pública, y las empresas de seguridad han reportado intentos que van desde la minería de criptomonedas hasta la instalación de software malicioso adicional. Un informe de CyberScoop sobre la directiva de emergencia describió la preocupación del gobierno de que la prevalencia de la vulnerabilidad y la facilidad de explotación creen una oportunidad inusualmente amplia para actores criminales y vinculados al Estado.
Cloudflare, que comenzó a bloquear los intentos de explotación la semana pasada, ha seguido publicando recomendaciones para mitigar los riesgos a medida que la situación evoluciona. Los proveedores de internet y las empresas de seguridad pueden bloquear patrones de explotación conocidos en los extremos de la red, pero estas defensas no sustituyen la eliminación del código vulnerable, ya que los atacantes pueden modificar las cargas útiles y acceder a los sistemas a través de rutas que las protecciones perimetrales no detectan.
La detección es importante incluso después de que los sistemas hayan sido parcheados
Las organizaciones se enfrentan a dos preguntas distintas: si siguen siendo vulnerables y si ya han sufrido una brecha de seguridad. La aplicación de parches solo responde a la primera. Dado que el escaneo y la explotación comenzaron con tanta rapidez, los responsables de la seguridad también deben examinar los registros, las conexiones salientes, los nuevos procesos, los archivos inesperados y la actividad de identidad en busca de indicios de que un atacante obtuvo acceso antes de la corrección.
La complejidad se ve agravada por la posibilidad de que un servidor comprometido sea solo el primer punto de acceso. Una vez que los atacantes ejecutan el código, pueden intentar robar credenciales, realizar movimientos laterales o emplear mecanismos de persistencia que resistan la actualización de Log4j. Esto significa que los equipos de respuesta a incidentes no pueden cerrar una investigación simplemente porque la biblioteca vulnerable se haya actualizado.
Un informe contemporáneo del Register describió la orden de la CISA como parte de un esfuerzo más amplio para forzar una rápida remediación en todas las redes federales, mientras que las organizaciones del sector privado se enfrentan al mismo problema de inventario sin un mandato central único.
La crisis pone al descubierto una debilidad estructural en el software
Log4j se ha convertido en un caso de estudio sobre el riesgo de dependencias. El software moderno se compone de capas de bibliotecas, marcos de trabajo y paquetes de código abierto, ya que la reutilización agiliza y mejora la fiabilidad del desarrollo. Sin embargo, las organizaciones suelen carecer de un registro completo y actualizado de estos componentes. Cuando falla una biblioteca fundamental, la ausencia de dicho inventario convierte la respuesta ante una vulnerabilidad en una mera búsqueda.
La lección ya va más allá de Log4j. Los equipos de seguridad necesitan listas de materiales de software, un seguimiento de dependencias más sólido, una divulgación más rápida de proveedores y la capacidad de localizar un componente en diferentes aplicaciones sin necesidad de investigación manual. Los desarrolladores necesitan procesos para actualizar bibliotecas profundamente integradas sin desestabilizar los sistemas de producción.
Por ahora, sin embargo, el problema sigue siendo inmediato. La revelación inicial de Log4Shell se ha convertido en una campaña de remediación continua, el primer parche ha sido reemplazado y las agencias federales operan bajo órdenes de emergencia. La característica principal del incidente ya no es simplemente la gravedad de una vulnerabilidad. Es la constatación de que una pequeña parte de la infraestructura de código abierto está integrada en tanto software que solucionarla requiere la coordinación de prácticamente toda la cadena de suministro tecnológico.
