En los últimos dos días, ha sido despreciado por la "vulnerabilidad de ejecución remota de código Apache Log4j2" en el círculo de amigos, principalmente debido a la vulnerabilidad de inyección JNDI en Java en el componente: cuando el programa escribe los datos introducidos por el usuario en el registro, el atacante construye una solicitud especial para activar la vulnerabilidad de ejecución remota de código en Apache Log4j2, explotando así esta vulnerabilidad para ejecutar código arbitrario en el servidor objetivo.
Alcance de influencia
Apache Log4j 2.x <= 2.14.1
JNDI (Java Naming and Directory Interface) es una interfaz de nombres y directorios en Java proporcionada por Java. Al llamar a la API de JNDI, las aplicaciones pueden localizar recursos y otros objetos del programa. JNDI es una parte importante de Java EE, cabe señalar que no solo incluye DataSource (fuente de datos JDBC), sino que JNDI puede acceder a directorios y servicios existentes como: JDBC, LDAP, RMI, DNS, NIS, CORBA, extractos de la Enciclopedia Baidu. Hay muchos artículos en Internet sobre cómo corregir vulnerabilidades y capturas de pantalla de vulnerabilidades, pero poco sobre cómo probar el proyecto para detectar la vulnerabilidad.Java utiliza principalmente Log4j2 para probar el códigoComo sigue:
En términos sencillos, Log4j2 accederá a la siguiente dirección a través del protocolo RMI o LDAP y, según el contenido del protocolo, puede ejecutar código construido de forma maliciosa.
La existencia de la vulnerabilidad casi siempre se demuestra en Internet abriendo una calculadora de Windows, y el código es el siguiente:
Dado que Log4J2 utiliza protocolos RMI o LDAP para acceder al servidor del atacante, y tanto los protocolos RMI como LDAP son basados en TCP, podemos hacerlo directamenteUsando .NET para escuchar en un puerto TCP, si una llamada a log4j2 para imprimir registros accede al puerto de escucha .NET, demuestra que puede haber una vulnerabilidad y, si no, resulta seguro。
.NET genera programas de prueba muy pequeños6kb, el código es el siguiente:
Prueba a usar el componente log4j2.14.0La versión se imprime y la representación es la siguiente:
Prueba a actualizar el componente log4j a2.15.0Ejecutada de nuevo, el efecto es el siguiente:
Tras actualizar la versión, se descubre que al llamar al registro de impresión,El programa Java ya no accede al puerto externo。
Amigos interesados, podéis consultar el siguiente enlace para reproducir la vulnerabilidad y activar la calculadora.
El inicio de sesión del hipervínculo es visible.
El inicio de sesión del hipervínculo es visible.
Finalmente, adjunta el procedimiento de prueba:
测试程序.rar
(2.66 KB, Número de descargas: 1)
|