La vulnerabilidad Log4Shell amenaza la seguridad de los gigantes tecnológicos

Cualquier compañía que en sus servidores o aplicaciones use Apache Log4j, una biblioteca de registro de Java, se está enfrentando a una de las vulnerabilidades más importantes de la última década. Se trata de Log4Shell (CVE-2021-44228), un fallo de seguridad crítico que da como resultado la ejecución remota de código con potencial para tomar el control del equipo. La vulnerabilidad fue descubierta por Chen Zhaojun de Alibaba Cloud Security Team y por su importancia y alcance se compara con Heartbleed y WannaCry.

Lo que hace de Log4Shell una vulnerabilidad extremadamente peligrosa es la facilidad con la que se puede usar. Según los expertos de seguridad, para aprovecharse de este fallo no hace falta una configuración especial e incluso un atacante inexperto puede ejecutar con éxito un asalto. Por otro lado, hay que tener en cuenta que Log4j es una biblioteca de código abierto que se usa en innumerables aplicaciones, incluyendo las que emplean los gigantes tecnológicos. Según W3Techs, el 31,5 % de todos los sitios web se ejecutan en Apache.

En consecuencia, la lista de empresas con una infraestructura vulnerable a Log4Shell es larga e incluye a Microsoft, Apple, Amazon, Twitter, Steam, Cloudflare, Baidu y Tesla entre muchas otras. La versión Java de Minecraft fue una de las primeras víctimas en sufrir un ataque con Log4Shell. Proveedores como Cisco, IBM, Oracle, VMware y Red Hat ya han emitido avisos de seguridad, y ahora trabajan junto a otras tecnológicas y compañías de ciberseguridad en implantar medidas para mitigar los efectos del fallo en servidores y aplicaciones.

Log4Shell afecta de la versión 2.0 a la 2.14.1 de Apache Log4j y se recomienda actualizar lo antes posible a la versión 2.15.0 que corrige la vulnerabilidad. Esta es la mejor solución. Sin embargo, la aplicación de parches suele ser compleja y necesita de un ciclo de lanzamiento y un ciclo de pruebas. Esto significa tiempo, el mismo que tienen los atacantes para usar el fallo. La compañía de seguridad Check Point ha detectado 400.000 ataques con Log4Shell y afirma que más del 45 % eran maliciosos. El resto fue realizado por investigadores legítimos.

Para ganar tiempo, la compañía de seguridad Cybereason ha liberado el script Logout4Shell que básicamente actúa como una vacuna, ya que corrige el fallo de seguridad aprovechando el servidor vulnerable.

Fuente: arstechnica
Ya lleva unos días, el que tenga curiosidad aquí lo explican más en detalle https://unit42.paloaltonetworks.com/apa ... 021-44228/

Se trata de una librería de logs, esta librería facilita el sacar logs de información/error en diferentes formatos para poder ser utilizados en otras aplicaciones (kibana o dashboards similares)
De los gigantes y de los no tan gigantes, yo creo que aquí más o menos el que trabaje con Java está temblando.
largeroliker escribió:De los gigantes y de los no tan gigantes, yo creo que aquí más o menos el que trabaje con Java está temblando.

Exacto, yo mismo la he utilizado en algún proyecto de los que me ha tocado trabajar.
@blackorwhite ¿nos explicas el chiste?, porque yo al menos la gracia no se la veo por ningún sitio. Y menos tratándose de una biblioteca de código abierto.
Virus, apagones eléctricos, la inteligencia colectiva humana por los suelos, y ahora empieza el miedo al apagón de internet. Si al final lo del plan Illuminati va a ser verdad y to.
Saludos a todos!

¿Alguno sabe si la vulnerabilidad afecta también a la variante para .Net Framework, Log4Net, en servidores IIS?
Pregunto desde el más absoluto desconocimiento.

Google se ha "salvado" de esta vulnerabilidad ? De ser así, por qué?
DavET está baneado por "Saltarse el ban con un clon"
Con lo bien que estaban los datos alojados en un cuartucho de mala muerte en carpetas dentro de archivadores ... [jaja] [qmparto]
@deividjg
Compae, prefiero reír que llorar... tal y como está el patio...
Hostia, pues como sea como las bakunas del cobi, van listos. Mejor que actualicen, y se dejen de parches.
largeroliker escribió:De los gigantes y de los no tan gigantes, yo creo que aquí más o menos el que trabaje con Java está temblando.


Desde luego no he trabajado en ni un solo proyecto en Java que no la use [mad]

@Benzo
No entiendo muy bien por que se habla de servidores que "corren" bajo Apache, ya que el fallo por lo que entiendo está en la librería de Java desarrollada por la Apache Software Foundation y por tanto sólo debería afectar a aquellas APLICACIONES que estén desarrollada en Java independientemente de donde corran estas, que dicho sea de paso, Apache se usa tradicionalmente para referirse al "Servidor HTTP Apache" que es un servidor web que está escrito en C y mediante el cual no se pueden correr aplicaciones Java y solo corre lenguajes de scripting y está restringido a clientes HTTP.

Para ejecutar "aplicaciones Java" se requiere de un servidor de aplicaciones donde tenemos JBoss, WebLogic, Glassfish entre otros. También tenemos el conocido Apache Tomcat desarrollado también por la Apache Software Foundation (el catálogo de productos que desarrollan estos es infinito).

Que alguien me corrija si me equivoco.
No termino de entender el "parche/vacuna" ese, es lo mismo que se dijo el viernes de añadirle un {nolookups} al %m.
blackorwhite escribió:Imagen

Me resulta curioso cuando veo gente que se ríe de estas cosas, como si no nos afectase, incluido al risitas.

Tal vez el tipo de persona que se ríe pensando "que se jodan las multinacionales esas muahahhaa" piensa que esas empresas el dinero lo sacan del espacio sideral, y no de los clientes. Tal vez también piensa ese tipo de persona que cuando una empresa necesita incrementar beneficios porque sus gastos han subido por multas ese beneficio extra lo obtiene de los gamusinos, no de sus trabajadores con menos subida salarial o de los clientes que ven incrementados los precios.

Igual también este tipo de persona no se da cuenta que este fallo no solo afecta a esas grandes empresas mencionadas y sí afecta incluso al estudiante que está de prácticas.
Esperemos que todo quede en un susto porque vaya tela.
@tulkas666
"Inteligencia colectiva humana por los suelos".
Yo no lo habría explicado mejor, y creo que es el mayor mal que nos amenaza.
Ha estado movidito el fin de semana con esta vulnerabilidad.
Pero movidita va a empezar la semana en el trabajo, ya que esa librería está en cientos de herramientas. [looco]

Por si a alguien le interesa ver el nº de empresas afectadas o si han hecho comunicados de si sus productos están afectados os dejo este Github que van actualizando los enlaces directos.

https://gist.github.com/SwitHak/b66db3a ... 718970c592
Sigamos apostando por el intertet de las cosas, sigamos cada dia mas dependientes de que todo sea en linea, ya pronto llegara el momento de que todos pierdan la cabeza cuando algún listo se decida a hacer sus maromas!
JohnLeeHooker escribió:
blackorwhite escribió:Imagen

Me resulta curioso cuando veo gente que se ríe de estas cosas, como si no nos afectase, incluido al risitas.

Tal vez el tipo de persona que se ríe pensando "que se jodan las multinacionales esas muahahhaa" piensa que esas empresas el dinero lo sacan del espacio sideral, y no de los clientes. Tal vez también piensa ese tipo de persona que cuando una empresa necesita incrementar beneficios porque sus gastos han subido por multas ese beneficio extra lo obtiene de los gamusinos, no de sus trabajadores con menos subida salarial o de los clientes que ven incrementados los precios.

Igual también este tipo de persona no se da cuenta que este fallo no solo afecta a esas grandes empresas mencionadas y sí afecta incluso al estudiante que está de prácticas.


Se hicieron chistes de los muertos de las torres gemelas, y hasta de Miguel Ángel blanco y no te puedes reír de esto?

Reír te impide hacer algo al respecto? Que es lo que exactamente te molesta? Porque estoy seguro de que te ríes normalmente de cosas que a otros les parece "muy serias"
Es grave. El problema es que es bastante fácil de explotar según parece. De todos modos en grandes aplicaciones solo está disponible el acceso vía frontal web o API gw, así que con parchear eso si fuera necesario (que no lo será en muchos casos)... Esto lo digo por los preocupados por el impacto en las grandes empresas, ya que el grueso del software está aislado de internet.

Pero si hay interés por corregirlo se puede hacer de dos maneras muy fácil: ejecutar un script de ataque que lo corrige en todos los servidores vulnerables ( lo más rápido y ya circula el código por ahí) y/o reconstruir y desplegar las aplicaciones de nuevo con la versión corregida (2.15 creo). La segunda opción hay que hacerla si o si de cara al futuro así que...

En entornos de despliegue continuo ya estará corregido o se corregirá en cualquier momento. En otros más clásicos nos tocará cambiar dependencias (lo normal es que sea en uno os dos pom de componentes comunes) y re-desplegar.

Nos quitará algo de tiempo pero no será mucho.
recordar que... los esxi de vmware usan esa libreria para escribir los logs XD
largeroliker escribió:De los gigantes y de los no tan gigantes, yo creo que aquí más o menos el que trabaje con Java está temblando.

Se me ocurren muchos proyectos en muchas empresas grandes, pero la que mas se me viene a la cabeza, es la administracion publica, tira de muchos servicios en java.
AzagraMac escribió:
largeroliker escribió:De los gigantes y de los no tan gigantes, yo creo que aquí más o menos el que trabaje con Java está temblando.

Se me ocurren muchos proyectos en muchas empresas grandes, pero la que mas se me viene a la cabeza, es la administracion publica, tira de muchos servicios en java.

Y lo peor de eso es que esos proyectos los suelen llevar cárnicas y dudo de su proactividad XD
largeroliker escribió:
AzagraMac escribió:
largeroliker escribió:De los gigantes y de los no tan gigantes, yo creo que aquí más o menos el que trabaje con Java está temblando.

Se me ocurren muchos proyectos en muchas empresas grandes, pero la que mas se me viene a la cabeza, es la administracion publica, tira de muchos servicios en java.

Y lo peor de eso es que esos proyectos los suelen llevar cárnicas y dudo de su proactividad XD

[carcajad] [carcajad] llevo casi 20 años en IT y no se de ninguna empresa que no tenga dentro alguna carnica [+risas] y a veces no es ni culpa de ellas... si no de formas de llevar los proyectos los propios clientes, se de cierto banco que tiene unos procesos de actualizar PRO muy muy deficientes... pero muchos no tienen planificado procesos criticos en casos asi, recuerdo muy recientemente el problema de con Meltdown y Spectre, y en ambos casos se tardaron meses y se que a dia de hoy varios proyectos donde estaba no han solucionado el tema...

la seguridad es un gasto, no una inversion... poco pasa. Eso si, cunado falla, luego vienen los lloros. Muchos proyectos no tienen sistema de backup, o peor... tienen sistemas de backup, pero tienen exclusiones de datos criticos para el servicio, ejemplo los volumenes persistentes en contenedores docker...
tperalta escribió:Saludos a todos!

¿Alguno sabe si la vulnerabilidad afecta también a la variante para .Net Framework, Log4Net, en servidores IIS?


No afecta, al menos de momento porque esto se ramifica rápido
Por suerte, no es el único framework de logging en Java, ni por desgracia, será el último al que se le encuentren vulnerabilidades "0 day".

Habría que felicitar a los voluntarios(que no cobran por ello) de mantener el proyecto, porque la extensión y popularidad de Log4j es debida a que está bien construido además de ser fácil de implementar. Pero el ser humano es propenso a fallar y equivocarse, rectificar en 24 horas, sólo les honra.

Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...
agron escribió:Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...


La ignorancia es muy atrevida.
neofonta escribió:
agron escribió:Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...


La ignorancia es muy atrevida.


Totalmente de acuerdo, pero...
A veces, pensar que solo es ignorancia es lo fácil. También hay mucha maldad, o incluso envidia desde otros desarrolladores con productos de pago que hacen menos de la mitad del trabajo que la solución de código libre. Y eso nunca es bueno para el bolsillo, "ya tu sabes".
Encima el bug es simplemente por un comportamiento por defecto de la librería. Cambiándolo, ya se solventa el problema.
agron escribió:Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...

Con el software privativo tienes que tener fe absoluta y ciega de que lo que cuentan es lo que es y de que el parche ha sido aplicado correctamente, aunque esto último se puede verificar intentando lanzar el ataque a la supuestamente arreglada vulnerabilidad.
coyote escribió:
agron escribió:Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...

Con el software privativo tienes que tener fe absoluta y ciega de que lo que cuentan es lo que es y de que el parche ha sido aplicado correctamente, aunque esto último se puede verificar intentando lanzar el ataque a la supuestamente arreglada vulnerabilidad.


Claro, ¿y de que al arreglarla no hayan abierto otra, verdad? ;) para la que no tienes exploit, ni forma de saber que existe [looco]
agron escribió:
coyote escribió:
agron escribió:Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...

Con el software privativo tienes que tener fe absoluta y ciega de que lo que cuentan es lo que es y de que el parche ha sido aplicado correctamente, aunque esto último se puede verificar intentando lanzar el ataque a la supuestamente arreglada vulnerabilidad.


Claro, ¿y de que al arreglarla no hayan abierto otra, verdad? ;) para la que no tienes exploit, ni forma de saber que existe [looco]

De ahí fe absoluta y confianza ciega. [hallow]
agron escribió:
neofonta escribió:
agron escribió:Que hayan sufrido ataques desde las redes sociales, me causa un profundo estupor. No vi tanto cabreo sobre otros "0 day" de empresas con código privativo...


La ignorancia es muy atrevida.


Totalmente de acuerdo, pero...
A veces, pensar que solo es ignorancia es lo fácil. También hay mucha maldad, o incluso envidia desde otros desarrolladores con productos de pago que hacen menos de la mitad del trabajo que la solución de código libre. Y eso nunca es bueno para el bolsillo, "ya tu sabes".


Sí trabajan tanto los de software privativo, que te sacan chapuzas como Windows 11, en estado beta, a tenor de los problemas infantiles, como que se bloquee el explorer.

De hecho la realidad es que en este mundo ultra-capitalista donde primero se piensa en el dinero o en forrarnos, cada vez se sacan productos hardware y software peores creados/programados.

Saludos.
si usas la libreria en tu proyecto si puede ser problematico, pero si usas spring donde ya viene por defecto no es posible usar el exploit, aunque ya avisaron que sacarian

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
37 respuestas