Desentrañando la vulnerabilidad de VigorConnect: un viaje de descubrimiento y corrección

Introducción

Este artículo investiga una vulnerabilidad de lectura arbitraria de archivos (Arbitrary File Read) encontrada en VigorConnect, un servidor de gestión de DrayTek VigorAP y VigorSwitch diseñado para automatizar tareas como las actualizaciones de firmware y las copias de seguridad de la configuración. Mediante el análisis del código descompilado de la aplicación, en particular del tratamiento de las operaciones con archivos, demostramos cómo puede explotarse la vulnerabilidad para acceder a archivos sensibles. Hemos confirmado el problema e identificado el código responsable de este fallo.

Descubrimiento inicial de la vulnerabilidad

La vulnerabilidad de lectura arbitraria de archivos se identificó a través de varios endpoints que permitían operaciones de lectura de archivos no autorizadas. Estos endpoints indican un tratamiento inseguro de las rutas de archivo y de las entradas del usuario:

/ACSServer/DownloadFileServlet?table_action=Save&show_file_name=../../../../../../windows/win.ini&type=uploadfile&path=anything
/ACSServer/DownloadFileServlet?table_action=Save&show_file_name=../../../../../../etc/passwd&type=uploadfile&path=anything

Estas URL aparentemente inocuas son en realidad potentes llaves maestras que desbloquean el acceso a archivos sensibles del sistema en todo el servidor.

Para esta parte, descargamos el binario de VigorConnect/v1.5.2 desde su enlace oficial y lo instalamos en un equipo local siguiendo los pasos de esta guía de instalación.

La instalación de VigorConnect requiere privilegios de sudo. Este acceso elevado permite que el software interactúe con archivos y recursos a nivel de sistema. Como resultado, pudimos confirmar la vulnerabilidad de lectura arbitraria de archivos accediendo a archivos sensibles como /etc/passwd y windows/win.ini.

Análisis del código

Nuestro viaje para descubrir la verdadera naturaleza de esta vulnerabilidad nos llevó por un laberinto de código y suposiciones. Lo que empezó como una hipótesis sencilla se convirtió en una exploración compleja, que nos recordó la importancia de un análisis exhaustivo siempre que se investiga una vulnerabilidad grave.

Análisis de la causa raíz: vulnerabilidad en FileServerController

En primer lugar, se aplicó ingeniería inversa al binario con binwalk:

binwalk -e <binary>

El firmware de VigorConnect utilizado durante esta investigación es VigorConnectLinuxSetup_1.5.2. Confirmamos CVE-2021-20123 en esta versión antes de continuar con la investigación.

Dentro del contenido extraído se encontraron varios binarios. El foco principal se puso en el binario VigorConnect.

A primera vista, al examinar el código desensamblado del binario VigorConnect, el culpable parecía evidente: el método SaveToFile del framework web Beego. Este método, responsable de guardar los archivos subidos, parecía carecer de una validación de entradas adecuada:

func (c *Controller) SaveToFile(fromfile, tofile string) error {
    file, _, err := c.Ctx.Request.FormFile(fromfile)
    if err != nil {
        return err
    }
    defer file.Close()
    f, err := os.OpenFile(tofile, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0666)
    if err != nil {
        return err
    }
    defer f.Close()
    io.Copy(f, file)
    return nil
}

La ausencia de comprobaciones para sanear la ruta tofile parecía un caso de manual de vulnerabilidad que permite ataques de directory traversal. Era una teoría convincente, de la que muchos investigadores de seguridad podrían haberse sentido tentados a tirar. Sin embargo, el camino hacia la verdad en ciberseguridad suele ser más sinuoso de lo que anticipamos.

Movidos por la persistente sospecha de que la historia podía tener más trasfondo, decidimos profundizar. Esta decisión nos llevó a emplear técnicas de depuración más tradicionales, preparando el terreno para una revelación que pondría en entredicho nuestras suposiciones iniciales. Con la potente GNU Debugger (GDB) en mano, emprendimos una investigación más exhaustiva. El proceso fue metódico:

1. Iniciamos GDB con el binario VigorConnect: gdb ./VigorConnect
2. Ejecutamos el programa en modo de depuración: r -d &

Tras desencadenar la vulnerabilidad de lectura arbitraria de archivos, empezamos a colocar breakpoints en múltiples funciones hasta que se activó uno: os.OpenFile

1. Establecimos un breakpoint en la función os.OpenFile: br os.OpenFile y examinamos los argumentos de la función: info args

El código desensamblado de os.OpenFile se obtuvo tras abrir el binario con Ghidra y aplicar todos sus analizadores:

Esta función parece ser una operación de apertura de archivos de bajo nivel. Podría explotarse si no está restringida adecuadamente o si una función de nivel superior la invoca con entradas sin sanear.

1. Rastreamos la pila de llamadas: bt 20

Nuestro análisis reveló los siguientes puntos clave:

1. La ruta de archivo vulnerable a la que se accede es /usr/local/VigorConnect/FileRoot/tftp./../../../../../etc/passwd.

Este es el método Download de la estructura BeegoOutput del framework web Beego. Se encarga de servir archivos para su descarga.

La salida de GDB confirma que la función se invoca con una ruta de archivo vulnerable: /FileRoot/tftp./../../../../../etc/passwd

Esta ruta utiliza directory traversal (../) para acceder al archivo /etc/passwd, que está fuera del directorio previsto.

La función descompilada no muestra ninguna validación ni saneamiento claros de la ruta. Utiliza directamente la ruta de archivo proporcionada para llamar a os.Stat y, finalmente, a net/http.ServeFile.

1. Esta ruta es procesada por el método Get de FileServerController.

Veamos ahora en detalle qué hace este método a partir de su código desensamblado:

El método utiliza la función GetString del framework Beego para recuperar los parámetros de consulta de las solicitudes HTTP entrantes, como el nombre de archivo o la ruta que se va a descargar:

github.com/astaxie/beego.(*Controller).GetString
((github.com/astaxie/beego.Controller *)self_00,key,
*([]string *)((long)register0x00000020 + -0x208),~r2_01);

Estos parámetros de consulta se utilizan directamente para determinar qué archivo servir. Es decisivo que no haya una validación ni un saneamiento estrictos de estas entradas, lo que permite a los atacantes inyectar secuencias de directory traversal (por ejemplo, ../../../../../) para acceder a archivos fuera del directorio previsto.

A continuación, el método procesa distintos tipos de solicitudes, entre ellas ConfigDownload y uploadfile, que implican servir archivos al cliente:

if (*plVar2 != 0x696664616f6c7075) {
  return;
}
if (*(short *)(plVar2 + 1) != 0x656c) {
  return;
}

En el caso de las descargas de archivos, el método construye una ruta de archivo a partir de entradas proporcionadas por el usuario, que luego se pasa a la función BeegoOutput.Download. Como no hay validación de entradas, un atacante puede manipular esta ruta para que apunte a archivos sensibles del sistema.

Las implicaciones de esta vulnerabilidad van mucho más allá de la mera curiosidad técnica. En manos de actores maliciosos, este fallo podría conducir al acceso no autorizado a archivos de configuración sensibles, a la exposición de credenciales de usuario y, potencialmente, servir de plataforma de lanzamiento para compromisos más graves del sistema. Por ejemplo:

• Credenciales de la base de datos: el archivo app.conf revela que VigorConnect utiliza una base de datos SQLite (DbType = sqlite3). Un atacante podría acceder potencialmente al archivo de la base de datos en sqlite/VigorConnect.db, y exponer todos los datos almacenados.
• Certificados HTTPS: se especifican las rutas de archivo de HTTPSCertFile y HTTPSKeyFile. Acceder a ellos podría comprometer la seguridad SSL/TLS de todo el sistema.
• Credenciales de CLI: los campos CliUser y CliPassword, si están rellenados, podrían dar a un atacante acceso directo por línea de comandos al sistema.
• Archivos de registro: con AcsLog establecido en file y AcsLogSrc habilitado, un atacante podría acceder a archivos de registro que contienen datos operativos sensibles y, potencialmente, actividad de los usuarios.
• Configuración de InfluxDB: la presencia de una carpeta InfluxDB sugiere que VigorConnect utiliza InfluxDB, probablemente para almacenar datos de series temporales. El archivo influxdb.conf de esta carpeta podría contener credenciales de la base de datos y detalles de conexión.

Estos ejemplos ilustran cómo podría explotarse esta vulnerabilidad para obtener un acceso profundo al sistema VigorConnect, comprometiendo potencialmente no solo el servidor de gestión, sino todos los dispositivos de red conectados.

Conclusión

Nuestro análisis no solo confirma una vulnerabilidad crítica de lectura arbitraria de archivos en VigorConnect, sino que también sirve como un crudo recordatorio de la vigilancia constante que exige la ciberseguridad. Este fallo subraya la importancia de una revisión rigurosa del código, del principio de mínimo privilegio y de la necesidad de una defensa en profundidad en el diseño de software. A medida que dependemos cada vez más de sistemas de gestión centralizados como VigorConnect, la comunidad de seguridad debe mantenerse siempre vigilante, lista para descubrir y abordar la próxima amenaza oculta al acecho en nuestra infraestructura digital.