Informe de errores- Diciembre de 2021

Philippe Laulheret · 19 de enero de 2022

Ciberseguridad con sentido del humor

¿Por qué estoy aquí?

Si está leyendo esto, ¡le doy la enhorabuena! ¡Ha conseguido llegar a 2022! Y lo que es incluso mejor, está a punto de leer el resumen mensual sobre seguridad de ATR, en el que comentamos nuestras vulnerabilidades favoritas de los últimos 30 días. Felicítese, tómese una buena taza de café o una infusión, una botella de Vichy Catalan, si quiere algo más refinado o una bebida energética, si prefiere algo más fuerte. Ahora que ya se siente cómodo y lleno de energía, ¡empecemos!

Cruce de rutas de Grafana: CVE-2021-43798

¿Qué es?

Según Wikipedia, Grafana es una aplicación web multiplataforma de código abierto para la visualización interactiva y el análisis. Se utiliza de forma generalizada en el sector y cuenta con clientes de pago como Bloomberg, eBay, PayPal, etc. A principios de diciembre, circuló la noticia de que una vulnerabilidad de tipo cruce de rutas permitía acceder a archivos locales por una desinfección inadecuada de "../../../" en la ruta de su complemento. Se trató además de uno de los plazos de divulgación más cortos conocidos hasta la fecha:

¿A quién afecta?

Vale, ¿quién podría culparle de no haber oído hablar de otra vulnerabilidad que no sea Log4Shell en los últimos 30 días? Sin embargo, si su empresa utiliza este software, más le valdría seguir de cerca la divulgación del mes pasado, no vaya a ser que sus archivos "/etc/passwd" circulen ahora por todos los rincones de Internet. Aparte de eso, hay dos cuestiones interesantes sobre las que puede reflexionar mientras remueve su ponche de huevo navideño (sin entrar en más detalles sobre este brebaje infecto). Teniendo en cuenta la facilidad de explotación de esta vulnerabilidad, el mero hecho de que el proveedor eligiera corregir el error a través de su GitHub público parece haber sido suficiente para atraer todas las miradas y, en menos de tres días tras la corrección, ya había pruebas de concepto funcionales públicas para esta vulnerabilidad. Si le pica la curiosidad y quiere saber cómo afrontan este riesgo las bases de código abierto más desarrolladas, sepa que proyectos como Chromium se basan en una infraestructura de rastreo de errores independiente, que limita el acceso a los informes de errores (en los que se detallan los riesgos de seguridad y los casos de prueba) y emplea mensajes de validación (commit) públicos con un lenguaje sencillo con el objetivo de evitar atraer la atención.

Otro dato interesante: la causa principal de este error es el uso indebido de una API de Go para desinfectar rutas de acceso, como se explica en este hilo de Twitter. Resulta que la función filepath.Clean con la que se limpian las entradas que procesa el código vulnerable solo elimina el exceso de "../../" si la ruta de acceso es absoluta. Se trata de otro caso más de una API que se comporta con normalidad, pero que tiene consecuencias peligrosas. ¿Tiene la absoluta certeza de que el código base de su empresa no presenta estos problemas? El impacto de vulnerabilidades sin parche en este caso sería la posibilidad de permitir el acceso o la filtración de datos extremadamente confidenciales o filtrarlos. *Aquí es cuando la reflexión se convierte en desesperación*.

¿Qué puedo hacer?

Obviamente, actualizar el software si lo está usando: También puede utilizar reglas Sigma para detectar intentos de ataque. Lo ideal es que su plataforma de análisis no estuviese expuesta a Internet como estas 87 000 instancias, de las cuales 16 000 siguen siendo vulnerables según Shodan. Como mínimo, asegúrese de que su instancia de Grafana está protegida por una solicitud .htaccess o una interfaz similar. Desde el punto de vista del desarrollo, deben realizarse pruebas de seguridad y de unidades para garantizar que los filtros que se están implementando funcionan correctamente. Y sobre todo, si va a procesar entradas de usuario no fiables, no eluda los filtros y aplique patrones de código exhaustivamente verificados en lugar de desactivar las advertencias de su herramienta de seguridad.

La referencia

Como se pregunta Garth Nix en su novela Sabriel: "¿Escoge el caminante al camino, o el camino al caminante?". Sea como fuere, lo que está claro es que el camino descrito no lo recorrerá, ni atravesará un ciberdelincuente para los clientes de Network Security Platform (NSP). Estos suertudos están totalmente protegidos frente a los ataques de cruce de rutas, bien mediante una regla genérica o mejor aún, con reglas personalizadas contra ataques concretos.

CVE-2021-44228: Log4Shell

¿Qué es?

¿Quién iba a saber que el análisis (y a veces incluso la ejecución) de entradas que no son de confianza era una mala idea? Bueno, pues resulta que es justo lo que hace el código de registro log4j de Apache, y si la cadena registrada contiene los caracteres mágicos $(jdni:...), puede incluso obtener y ejecutar código Java no fiable. Las iteraciones de este ataque también han revelado la posibilidad de filtrar secretos locales, almacenados en variables de entorno (como claves de AWS). Además, dado lo recurrente que resulta su procesamiento, también ofrece muchas maneras de evitar una detección basada en la comparación de patrones.

¿A quién afecta?

Prácticamente a todo el mundo. ¿Escribe código Java y registra eventos? Sí, ha llegado el momento de reaccionar. ¿Utiliza aplicaciones o servlets basados en Java? Entonces es más que probable que haya registros de entradas de usuarios que no son de confianza. ¿Se utilizan en su empresa appliances o servicios basados en Java? Brinde por el personal del SOC y de TI, que sin duda no van a descansar mucho durante sus "vacaciones" navideñas. Lo ha entendido bien, este problema afecta a todo el sector y, con toda probabilidad, sus consecuencias se dejarán notar durante años. Para colmo, el error es muy fácil de explotar. Encargados de pruebas de penetración, analistas del SOC, hackers en ciernes o ciberdelincuentes a sueldo de algún Estado, prácticamente todo el mundo ha comenzado a explorar este vector de ataque. Hemos observado ataques masivos de larga duración con una amplia gama de cargas útiles, de criptomineros a cargas útiles de tipo rm -rf /*, incluso un intento fallido de propagación del gusano Mirai. Y lo peor aún no ha llegado.

¿Qué puedo hacer?

A riesgo de parodiar a Erica en la serie Stranger Things ("You can’t spell America without Erica"), no hay Apache sin pa(r)che. Más o menos. ¡No espere ni un segundo para actualizar! Aplique microparches. Supervise el tráfico. Un consejo: si su aplicación exclusivamente interna empieza a enviar solicitudes LDAP a un servidor remoto en un país sin relación alguna con su actividad, tal vez haya gato encerrado…

Si disfruta con el caos y/o le cuesta convencer al equipo de TI de la importancia de este error, ¡consiga que le dejen hacerles una demostración de los riesgos que presenta! A continuación, atribuya a las cadenas que pueda controlar (user-agent, twitter name, wifi SSID, etc.) este valor mágico $(jdni:ldap...) y diríjalas a un puerto IP sobre el que tenga control (o a un servicio externo como Canarytoken, si confía en ellos). Si detecta respuestas con esa dirección, puede informar a su equipo de TI de la necesidad de actualizar su pila tecnológica con los propietarios de las direcciones entrantes. Llegados a este punto es cuando resulta fundamental solicitar permiso. Efectivamente, si empieza a colocar la cadena mágica por todas partes para ver qué pasa (como habrá visto en varias plataformas de redes sociales), es probable que en un momento dado, "alguien" intentará ponerse en contacto con usted para saber "más" sobre su extraño agente de usuario. Obviamente, antes de iniciar una maniobra así, no olvide que lo último que le gustaría recibir por Navidad es una denuncia por fraude informático.

La referencia

Los clientes de Trellix están protegidos de varias formas (para obtener más información, lea este artículo de la base de datos de conocimientos). Por ejemplo:

• Las reglas de experto de la solución ENS (Endpoint Security) pueden identificar patrones peligrosos en la memoria, como se describe en este artículo de blog.
• Endpoint Security (ENS), VirusScan Enterprise (VSE) y Web Gateway (WG) pueden ofrecer una detección genérica con el nombre Exploit-CVE-2021-44228.C a través de la "detección de software potencialmente no deseado". Esta detección también se complementa con una lista de hashes de muestras relacionadas con campañas activas que explotan esta vulnerabilidad.
• Network Security Platform (NSP) también puede detectar el ataque mediante una firma definida por el usuario (incluida en el anterior artículo de la base de datos de conocimientos).
• Las soluciones Endpoint Detection and Response (EDR) y Active Response (AR) también pueden utilizarse para buscar sistemas vulnerables con consultas de búsqueda en tiempo real (RTS, Real-Time Search).
• La solución SIEM ha recibido una actualización (Exploit Content Pack versión 4.1.0) que alertará de posibles intentos de explotación. Insights también facilita información útil mediante la campaña de amenazas "Log4Shell - Una vulnerabilidad de Log4j Vulnerability - CVE-2021-44228". Consulte la Vista preliminar de MVISION Insights.

CVE-2021-43527 – Big Sig

¿Qué es?

Big Sig suena al apodo que le puso a Freud su madre. Este error no es menos cautivador. A principios de diciembre, Google Project Zero publicó en su blog un artículo sobre una vulnerabilidad que detectaron en los servicios NSS (Network Security Services) de Mozilla con una calificación de CVSS de 9,8, según la página de la base de datos de vulnerabilidades National Vulnerability Database (NVD) del NIST. Hay un desbordamiento del montón en el procesamiento de ciertas firmas DSA y RSA-PSS codificadas en DER. En otras palabras, NSS es una colección de bibliotecas criptográficas que permiten a los desarrolladores utilizar implementaciones más seguras y probadas de estándares y primitivos criptográficos (para el cifrado de comunicaciones, la verificación de la autenticidad de los datos, etc.). La función en la que se encontró el error es responsable de la verificación de las firmas que demuestran la autenticidad de los datos mediante varios modelos criptográficos públicos. Este tipo de función se suele utilizar para confirmar que los autores reales de correos electrónicos o documentos son realmente quienes los firman. Uno de los aspectos más interesantes de este error es que es relativamente sencillo, pero también que ha existido durante mucho tiempo. Según el blog de Project Zero, este error se podía explotar desde 2012. La ruta de acceso del código vulnerable se coló por las grietas, es decir donde se superponen los distintos fuzzers que utiliza Mozilla.

¿A quién afecta?

Si le gusta que se verifiquen sus firmas y para ello confía en la biblioteca de NSS, debería echar un vistazo al boletín y actualizar a la última versión del software (NSS versión 3.73/3.681 ESR o posterior). Parece que no ha afectado a Firefox, pero sí a otros programas que analizan firmas (Thunderbird, LibreOffice, Evolution y Evince, entre otros).

¿Qué puedo hacer?

Como siempre, debe comprobar que todo el software que utilice y sea susceptible de ser vulnerable esté actualizado con la última versión. El parche se publicó el 1 de diciembre, luego empiece por comprobar que el software potencialmente vulnerable se haya actualizado posteriormente. También convendría identificar el software que recurre a esta biblioteca; aunque no existe una fórmula mágica, las referencias a archivos como nss3.dll en Windows o libnss3.so en Linux son un buen punto de partida. Además de eso, lo mejor es consultar las notas de la versión y la lista de posibles bibliotecas de terceros empleadas en las aplicaciones que utilice. Si utiliza la biblioteca vulnerable en su propio producto, actualice el código o incluya el parche.

La referencia

¿Ha consultado nuestros boletines? Constituyen una excelente fuente de información sobre las vulnerabilidades críticas que tal vez haya pasado por alto. En ellos puede encontrar información sobre aplicaciones que implementarán correcciones para la vulnerabilidad CVE-2021-43527.