Contacto
Links
Ubicacion
Calz. del Valle 255 Int A Col. del Valle, Del Valle, 66220 San Pedro Garza García, N.L.
La vulnerabilidad Log4j continúa presentando una gran amenaza para las organizaciones empresariales un año después de que Apache Software Foundation 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 use en [casi] el 64 % de las aplicaciones Java y solo el 50 % de ellas se haya actualizado a una versión completamente reparada significa que los atacantes seguirán apuntándolo», dice David Lindner, CISO de Contrast Security. «Al menos por ahora, los atacantes continúan teniendo un día de campo para 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 conocida como Log4Shell, existe en la función de interfaz de directorio y nombres de Java (JNDI) de Log4j para el almacenamiento y la recuperación de datos. Brinda a los atacantes remotos una forma trivialmente fácil de tomar el control de los sistemas vulnerables, un problema dado que Log4J se usa 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 red 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 software de criptominería y recolectores de credenciales en una red federal.
La advertencia fue similar a una de Fortinet en marzo sobre el actor de amenazas chino Deep Panda que usa 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 que distribuye 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, la cantidad real de compromisos informados públicamente que involucran a Log4 se ha mantenido comparativamente baja, 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ó que 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 error. 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 web, 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 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 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 de forma recursiva, 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 el 35% de las descargas de Log4 actualmente continúan siendo de versiones vulnerables del software. «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.
Sobre Nosotros
Somos una consultoría especializada en la seguridad de información, que por medio de una gama de consultores expertos en la materia, brindamos soluciones a los problemas tecnológicos que enfrentan las diferentes industrias.