Un año después de Log4Shell, la mayoría de las empresas todavía están expuestas a ataques



La vulnerabilidad Log4j continúa presentando una gran amenaza para las organizaciones empresariales un año después de que Apache Software package Basis la revelara en noviembre pasado. a pesar de que la cantidad de ataques divulgados públicamente dirigidos a la falla en sí misma ha sido menor de lo que muchos podrían haber esperado inicialmente.

Un alto porcentaje de los sistemas aún permanecen sin parches contra la falla, y las organizaciones enfrentan desafíos para encontrar y remediar el problema y luego evitar que la falla se vuelva a introducir en el entorno, dicen los investigadores de seguridad.

«El hecho de que Log4j se utilice en [nearly] El 64 % de las aplicaciones Java y solo el 50 % de ellas se han actualizado a una versión completamente reparada, lo que significa que los atacantes seguirán teniendo como objetivo», dice David Lindner, CISO de Distinction Safety. «Al menos por ahora, los atacantes continúan teniendo un día de campo en encontrar caminos para explotar a través de Log4j».

Múltiples ataques, pero menos de lo esperado

La falla de Log4j (CVE-2021-44228), comúnmente conocido como Log4Shell, existe en la función JNDI (Java Naming and Listing Interface) de Log4j para el almacenamiento y la recuperación de datos. Brinda a los atacantes remotos una forma trivialmente fácil de tomar el regulate de los sistemas vulnerables, un problema dado que Log4J se united states en prácticamente todos los entornos de aplicaciones Java. Los investigadores de seguridad la consideran una de las vulnerabilidades más importantes de los últimos años debido a su prevalencia y la relativa facilidad con la que los atacantes pueden explotarla.

Durante el año pasado, ha habido numerosos informes sobre actores de amenazas que apuntan a la falla como una forma de obtener acceso inicial a una crimson de destino. Muchos de estos ataques han involucrado grupos de amenazas persistentes avanzadas (APT) respaldados por estados nacionales de China, Corea del Norte, Irán y otros países. En noviembre, por ejemplo, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) advirtió sobre un grupo APT respaldado por el gobierno de Irán que explota la vulnerabilidad Log4j en un servidor VMware Horizon sin parches para implementar application de criptominería y recolectores de credenciales en una red federal.

La advertencia fue related a una de Fortinet en marzo sobre el actor de amenazas chino Deep Panda usando el vector idéntico para implementar una puerta trasera en los sistemas de destino y otra de Ahn Labs sobre el Grupo Lazarus de Corea del Norte distribuyendo su propia puerta trasera de la misma manera Otros, como Microsoft, también informaron haber observado a actores estatales como el grupo Phosphorous de Irán y el actor de amenazas Hafnium de China usando Log4 para lanzar proyectiles inversos en sistemas infectados.

A pesar de tales informes, y varios otros sobre grupos de delitos cibernéticos motivados financieramente que apuntan a Log4j, el número real de compromisos informados públicamente que involucran a Log4 se ha mantenido comparativamente bajo, especialmente cuando se compara con incidentes que involucran vulnerabilidades de Exchange Server como ProxyLogon y ProxyShell. Bob Huber, director de seguridad de Tenable, dice que la escala y el alcance de los ataques informados han sido sorprendentemente más bajos de lo esperado, considerando la simplicidad de la vulnerabilidad y la ruta del ataque. «Solo recientemente hemos visto alguna evidencia significativa de focalización, como lo señaló la actividad reciente del estado nación de CISA», dice Huber.

Amenaza no disminuida

Sin embargo, eso no significa que la amenaza de Log4j haya disminuido durante el último año, señalan los investigadores de seguridad.

Por un lado, un gran porcentaje de organizaciones siguen siendo tan vulnerables a la amenaza como lo eran hace un año. Un análisis de telemetría relacionado con el error que Tenable realizó recientemente mostró El 72% de las organizaciones eran vulnerables a Log4j, a partir del 1 de octubre. Tenable descubrió que el 28 % de las organizaciones en todo el mundo se han remediado por completo contra el mistake. Pero Tenable descubrió que las organizaciones que habían remediado sus sistemas a menudo se encontraban con Log4j una y otra vez a medida que agregaban nuevos activos a sus entornos.

En muchos casos (de hecho, el 29 %) los servidores, las aplicaciones net, los contenedores y otros activos se volvieron vulnerables a Log4j poco después de la reparación inicial.

«Suponiendo que las organizaciones integren la solución en el lado izquierdo de la ecuación, durante la canalización de creación del computer software, las tasas de reintroducción deberían disminuir», dice Huber. «Gran parte de la tasa de reintroducción y cambio depende en gran medida del ciclo de lanzamiento de computer software de una organización».

Además, a pesar de la conciencia casi omnipresente de la falla dentro de la comunidad de seguridad cibernética, las versiones vulnerables de Log4j siguen siendo muy difíciles de encontrar en muchas organizaciones debido a cómo las aplicaciones lo usan. Algunas aplicaciones pueden usar el componente de registro de código abierto como una dependencia directa en sus aplicaciones y, en otros casos, una aplicación puede usar Log4j como una dependencia transitiva, o una dependencia de otra dependencia, dice Brian Fox, CTO de Sonatype.

«Dado que las dependencias transitivas se introducen a partir de sus opciones de dependencia directa, es posible que sus desarrolladores no siempre las conozcan o las vean directamente», dice Fox.

En muchos casos, cuando la Fundación Apache reveló Log4Shell por primera vez, las empresas tuvieron que enviar miles de correos electrónicos internos, recopilar resultados en hojas de cálculo y escanear sistemas de archivos recursivamente, dice Fox. “Esto costó a las empresas tiempo y recursos valiosos para parchear el componente y prolongó la magnitud del efecto malicioso de la vulnerabilidad”, dice.

Los datos del repositorio Maven Central Java que mantiene Sonatype muestran que 35% de las descargas de Log4 actualmente siguen siendo de versiones vulnerables del program. «Muchas empresas todavía están tratando de construir su inventario de software antes de que puedan siquiera comenzar una respuesta y desconocen las implicaciones de las dependencias transitivas», dice Fox.

Debido a todos los problemas, la junta de revisión del Departamento de Seguridad Nacional de EE. UU. a principios de este año concluyó que Log4 es un riesgo de seguridad endémico con el que las organizaciones deberán lidiar durante años. Los miembros de la junta evaluaron que las instancias vulnerables de Log4j permanecerán en los sistemas durante muchos años y pondrán a las organizaciones en riesgo de sufrir ataques en el futuro previsible.

El único resultado positivo

Los investigadores de seguridad que rastrean el mistake dicen que las consecuencias positivas de Log4j son la mayor atención que ha atraído a prácticas como el análisis de composición de software program y la lista de materiales de software package (SBOM). Los desafíos que las organizaciones han enfrentado al determinar si son vulnerables o dónde podría existir la vulnerabilidad en su entorno han fomentado una mejor comprensión de la necesidad de visibilidad de todos los componentes en su base de código, especialmente aquellos de código abierto y fuentes de terceros.

«La investigación sobre el problema de Log4J ha reafirmado la necesidad de una mejor atestación de la cadena de suministro de application además de SBOM que se mantengan al día con la velocidad de DevOps», dice Matthew Rose, CISO de ReversingLabs. «Los equipos de seguridad y arquitectura de aplicaciones se dieron cuenta de que no basta con buscar riesgos en partes de la aplicación, como el código fuente, las API o los paquetes de código abierto. Ahora se dan cuenta de que una comprensión completa de la arquitectura de la aplicación es tan importante como encontrar SQLI o errores de secuencias de comandos entre sitios (XSS)», dice.



Enlace a la noticia unique