Antecedentes de vulnerabilidad 0x01
El 9 de diciembre, se detectó que la vulnerabilidad de ejecución remota de código Apache Log4j2 se reveló en Internet. Debido a la función de análisis recursivo de algunas funciones de Apache Log4j2, un atacante no autenticado puede ejecutar la ejecución de código arbitrario en el servidor de destino enviando un mensaje especial código de paquete de solicitud de datos construido. El PoC de la vulnerabilidad se ha hecho público en Internet y la configuración predeterminada puede ser explotada. Esta vulnerabilidad afecta a una amplia gama. Se recomienda que los usuarios pertinentes tomen medidas para investigarla y protegerla lo antes posible.
0x02 nivel de riesgo
grave
0x03 afecta la versión
Versiones afectadas:
Apache Log4j 2.x < 2.15.0-rc2
0x04 Ámbito de influencia de la cadena de suministro:
Aplicaciones y componentes afectados conocidos:
| 1 2 3 4 |
|
Puede consultar más componentes en el siguiente enlace:
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages?p=1
Versión no afectada:
Apache log4j-2.15.0-rc1 ha sido reemplazado Bypass, todavía una versión insegura.
apache log4j-2.15.0-rc2
Versión segura de JDK (si se utilizan los componentes anteriores, el siguiente JDK también es seguro):
Se recomienda utilizar JDK: 11.0.1, 8u191, 7u201, 6u211 y versiones superiores
0x04 Sugerencia de reparación
1. Estrategia temporal:
1. Agregue los parámetros de inicio de jvm: -Dlog4j2.formatMsgNoLookups=true
2. Agregue el archivo de configuración log4j2.component.properties en la classpath de la aplicación, el contenido del archivo es: log4j2.formatMsgNoLookups=true
3. Se recomienda que JDK use versiones superiores de 11.0.1, 8u191, 7u201, 6u211 y superiores
2. Estrategia formal:
1. Actualice a Log4j 2.15.0 r2 (se ha omitido r1)
esquema de detección 0x05
1. Los usuarios pertinentes pueden juzgar si se utiliza un componente con una vulnerabilidad de acuerdo con si existe una estructura de ruta relacionada de org/apache/logging/log4j después de descomprimir el jar de Java. Si hay un paquete de Java relacionado, es probable que la vulnerabilidad existir.
2. Si el programa está empaquetado con Maven, verifique si los campos relevantes que se muestran en la figura a continuación existen en el archivo pom.xml del proyecto.Si el número de versión es inferior a 2.15.0, esta vulnerabilidad existe.
3. Si el programa está empaquetado con gradle, puede ver el archivo de configuración de compilación build.gradle.Si hay campos relacionados con org.apache.logging.log4j en la sección de dependencias, y el número de versión es inferior a 2.15.0, esto existe vulnerabilidad.
esquema de detección de capa de tráfico 0x06
1. Los atacantes generalmente usan el método dnslog para escanear y detectar antes de explotar. El método de explotación común puede ser a través de "javax.naming.CommunicationException" y "javax.naming.NamingException: problema al generar objetos usando la fábrica de objetos" en el registro de errores de el sistema de la aplicación ", "Error al buscar el recurso JNDI" palabras clave para la solución de problemas.
2. Puede haber "${jndi:}" en el paquete de datos enviado por el atacante. Se recomienda utilizar un dispositivo de flujo completo o WAF para la recuperación, solución de problemas y bloqueo.
Proceso de eliminación sugerido:
1. Los firewalls de límite WAF e IDC en la nube agregan políticas de bloqueo y filtrado.
2. Conéctese al nombre de dominio del proveedor de protección en la nube para permitir que la protección en la nube intercepte la explotación de esta vulnerabilidad.
3. La conciencia situacional y el tráfico completo se agregan a las reglas de detección para verificar la lista de activos afectados externamente y dar prioridad a la reparación de negocios externos.
4. Las organizaciones moleculares internas y los fabricantes de productos comerciales, envían anuncios de advertencia de vulnerabilidad internamente, presionan a cada sucursal para que lleve a cabo una investigación preliminar y una actualización de la defensa por sí misma.
5. Esta vulnerabilidad es una vulnerabilidad de la capa de aplicación, que debe ser resuelta por I + D y actualizaciones de componentes. Comuníquese con el administrador de la base de código para escribir scripts para todas las bases de código conocidas para detectar la lista de elementos afectados y repararlos después de extraerlos, o use HIDS para extraer los activos afectados La lista de verificación se envía al equipo del proyecto a través de la gestión de vulnerabilidades para reparar y fortalecer.