Ivanti Pulse Secure utiliza una versión de Linux obsoleta

Un análisis de ingeniería inversa del firmware de los dispositivos Ivanti Pulse Secure ha revelado la existencia de varios puntos débiles, lo que subraya una vez más el reto que supone proteger las cadenas de suministro de software.

Eclypsiusm, que adquirió la versión de firmware 9.1.18.2-24467.1 como parte del proceso, dijo que el sistema operativo base utilizado por la empresa de software con sede en Utah para el dispositivo es CentOS 6.4.

«Pulse Secure ejecuta una versión de Linux de hace 11 años que no recibe soporte desde noviembre de 2020», señaló la compañía de seguridad de firmware en un informe que se ha compartido.

Esta novedad se produce en un momento en que las amenazas aprovechan una serie de vulnerabilidades de seguridad descubiertas en Ivanti Connect Secure, Policy Secure y las puertas de enlace ZTA para distribuir una amplia gama de malware, como web shells, ladrones y puertas traseras.

Las vulnerabilidades que se han explotado activamente en los últimos meses son CVE-2023-46805, CVE-2024-21887 y CVE-2024-21893. La semana pasada, Ivanti también reveló otro fallo en el software (CVE-2024-22024) que podría permitir a los autores de amenazas acceder a recursos restringidos sin necesidad de autenticación.

En un aviso publicado ayer, la empresa de infraestructura Web Akamai dijo que ha observado «actividad de escaneo significativa» dirigida a CVE-2024-22024 a partir del 9 de febrero de 2024, tras la publicación de una prueba de concepto (PoC) por watchTowr.

Eclypsium dijo que aprovechó un exploit PoC para CVE-2024-21893 que fue publicado por Rapid7 a principios de este mes para obtener una shell inversa al dispositivo PSA3000, exportando posteriormente la imagen del dispositivo para el análisis de seguimiento utilizando el analizador de seguridad de firmware EMBA.

Esto no sólo descubrió una serie de paquetes obsoletos – corroborando los hallazgos previos del investigador de seguridad Will Dormann – sino también una serie de bibliotecas vulnerables que son susceptibles acumulativamente a 973 fallas, de las cuales 111 tienen exploits públicamente conocidos.

Número de solicitudes de escaneo al día dirigidas a CVE-2024-22024

Perl, por ejemplo, no se actualiza desde la versión 5.6.1, que se publicó hace 23 años, el 9 de abril de 2001. La versión del kernel de Linux es la 2.6.32, que llegó al final de su vida útil (EoL) en marzo de 2016.

«Estos paquetes de software antiguos son componentes en el producto Ivanti Connect Secure», dijo Eclypsium. «Este es un ejemplo perfecto de por qué es importante la visibilidad en las cadenas de suministro digitales y por qué los clientes empresariales exigen cada vez más SBOM a sus proveedores.»

Además, un examen más profundo del firmware desenterró 1.216 problemas en 76 scripts de shell, 5.218 vulnerabilidades en 5.392 archivos Python, además de 133 certificados obsoletos.

Los problemas no acaban aquí, ya que Eclypsium encontró un «agujero de seguridad» dentro del código de la Herramienta de Comprobación de Integridad (ICT) que Ivanti recomienda a sus clientes para buscar indicadores de compromiso (IoCs).

En concreto, se ha descubierto que el script excluye del análisis más de una docena de directorios como /data, /etc, /tmp y /var, lo que hipotéticamente permitiría a un atacante desplegar sus implantes persistentes en una de estas rutas y aún así pasar la comprobación de integridad. Sin embargo, la herramienta analiza la partición /home, que almacena todos los demonios y archivos de configuración específicos del producto.

En consecuencia, Eclypsium descubrió que si se despliega el framework de post-explotación Sliver en el directorio /data y se ejecuta ICT no se detectan problemas, lo que sugiere que la herramienta proporciona una «falsa sensación de seguridad».

Vale la pena señalar que también se ha observado a actores de amenazas manipulando las TIC integradas en dispositivos Ivanti Connect Secure comprometidos en un intento de eludir la detección.

En un supuesto ataque presentado por Eclypsium, una amenaza podría dejar caer sus herramientas de la siguiente fase y almacenar la información recopilada en la partición /data y, a continuación, abusar de otro fallo de día cero para acceder al dispositivo y filtrar los datos almacenados anteriormente, todo ello mientras la herramienta de integridad no detecta signos de actividad anómala.

«Debe existir un sistema de controles y equilibrios que permita a los clientes y a terceros validar la integridad y seguridad del producto», afirma la empresa. «Cuanto más abierto sea este proceso, mejor trabajo podremos hacer para validar la cadena de suministro digital, es decir, los componentes de hardware, firmware y software utilizados en sus productos».

«Cuando los vendedores no comparten información y/o manejan un sistema cerrado, la validación se hace difícil, al igual que la visibilidad. Los atacantes seguramente, como se ha evidenciado recientemente, se aprovecharán de esta situación y explotarán la falta de controles y visibilidad del sistema.»

Fuente original en inglés

Más referencias:

Filed under
Ciberataques
Previous Next
For this post, the comments have been closed.