Se ha identificado otra vulnerabilidad en la biblioteca Log4j 2 (CVE-2021-45105) que, a diferencia de los dos problemas anteriores, está catalogada como peligrosa, pero no crítica. El nuevo problema permite provocar una denegación de servicio y se manifiesta en forma de bucles y fallos al procesar determinadas líneas. La vulnerabilidad se solucionó en la versión Log4j 2.17 lanzada hace unas horas. El peligro de la vulnerabilidad se ve mitigado por el hecho de que el problema sólo aparece en sistemas con Java 8.
La vulnerabilidad afecta a los sistemas que utilizan consultas contextuales (búsqueda de contexto), como ${ctx:var}, para determinar el formato de salida del registro. Las versiones de Log4j desde 2.0-alpha1 a 2.16.0 carecían de protección contra la recursión incontrolada, lo que permitía a un atacante manipular el valor utilizado en la sustitución para provocar un bucle, lo que provocaba el agotamiento del espacio de la pila y un bloqueo. En particular, el problema se produjo al sustituir valores como "${${::-${::-$${::-j}}}}".
Además, se puede observar que los investigadores de Blumira han propuesto una opción para atacar aplicaciones Java vulnerables que no aceptan solicitudes de red externa; por ejemplo, de esta manera se pueden atacar los sistemas de los desarrolladores o usuarios de aplicaciones Java. La esencia del método es que si hay procesos Java vulnerables en el sistema del usuario que aceptan conexiones de red solo desde el host local, o procesan solicitudes RMI (Invocación de método remoto, puerto 1099), el ataque se puede llevar a cabo ejecutando código JavaScript. cuando los usuarios abren una página maliciosa en su navegador. Para establecer una conexión con el puerto de red de una aplicación Java durante un ataque de este tipo, se utiliza la API WebSocket, a la que, a diferencia de las solicitudes HTTP, no se aplican restricciones del mismo origen (WebSocket también se puede utilizar para escanear puertos de red en el local host para determinar los controladores de red disponibles).
También son de interés los resultados publicados por Google sobre la evaluación de la vulnerabilidad de las bibliotecas asociadas con las dependencias de Log4j. Según Google, el problema afecta al 8% de todos los paquetes del repositorio central de Maven. En particular, 35863 paquetes Java asociados con Log4j a través de dependencias directas e indirectas estuvieron expuestos a vulnerabilidades. Al mismo tiempo, Log4j se utiliza como dependencia directa de primer nivel solo en el 17% de los casos, y en el 83% de los paquetes afectados, la vinculación se realiza a través de paquetes intermedios que dependen de Log4j, es decir. adicciones del segundo nivel y superiores (21% - segundo nivel, 12% - tercero, 14% - cuarto, 26% - quinto, 6% - sexto). El ritmo de reparación de la vulnerabilidad todavía deja mucho que desear: una semana después de que se identificara la vulnerabilidad, de 35863 paquetes identificados, el problema se ha solucionado hasta ahora sólo en 4620, es decir, al 13%.
Mientras tanto, la Agencia de Protección de Infraestructura y Ciberseguridad de EE. UU. emitió una directiva de emergencia que exige a las agencias federales identificar los sistemas de información afectados por la vulnerabilidad Log4j e instalar actualizaciones que bloqueen el problema antes del 23 de diciembre. Antes del 28 de diciembre, las organizaciones deben presentar informes sobre su trabajo. Para simplificar la identificación de sistemas problemáticos, se ha preparado una lista de productos que se ha confirmado que presentan vulnerabilidades (la lista incluye más de 23 mil aplicaciones).
Fuente: opennet.ru