Démêler la vulnérabilité de VigorConnect : un parcours de découverte et de correction

Introduction

Cet article étudie une vulnérabilité de lecture arbitraire de fichiers (Arbitrary File Read) découverte dans VigorConnect, un serveur de gestion DrayTek VigorAP et VigorSwitch conçu pour automatiser des tâches comme les mises à jour de firmware et les sauvegardes de configuration. En analysant le code décompilé de l'application, en particulier la gestion des opérations sur les fichiers, nous montrons comment la vulnérabilité peut être exploitée pour accéder à des fichiers sensibles. Nous avons confirmé le problème et localisé le code responsable de cette faille.

Découverte initiale de la vulnérabilité

La vulnérabilité de lecture arbitraire de fichiers a été identifiée via plusieurs endpoints qui autorisaient des lectures de fichiers non autorisées. Ces endpoints révèlent une gestion non sécurisée des chemins de fichiers et des entrées utilisateur :

/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

Ces URL d'apparence anodine sont en réalité de puissants passe-partout, qui ouvrent l'accès à des fichiers système sensibles sur l'ensemble du serveur.

Pour cette partie, nous avons téléchargé le binaire de VigorConnect/v1.5.2 depuis leur lien officiel et l'avons installé sur une machine locale en suivant les étapes de ce guide d'installation.

L'installation de VigorConnect nécessite des privilèges sudo. Cet accès élevé permet au logiciel d'interagir avec des fichiers et des ressources au niveau du système. Nous avons ainsi pu confirmer la vulnérabilité de lecture arbitraire de fichiers en accédant à des fichiers sensibles comme /etc/passwd et windows/win.ini.

Analyse du code

Notre parcours pour découvrir la vraie nature de cette vulnérabilité nous a menés à travers un labyrinthe de code et d'hypothèses. Ce qui a commencé comme une hypothèse simple est devenu une exploration complexe, qui nous rappelle l'importance d'une analyse rigoureuse chaque fois que l'on étudie une vulnérabilité grave.

Analyse de la cause racine : vulnérabilité dans FileServerController

Tout d'abord, le binaire a été désassemblé avec binwalk :

binwalk -e <binary>

Le firmware VigorConnect utilisé pendant cette recherche est VigorConnectLinuxSetup_1.5.2. Nous avons confirmé CVE-2021-20123 dans cette version avant de poursuivre l'investigation.

Plusieurs binaires ont été trouvés dans le contenu extrait. L'attention s'est portée principalement sur le binaire VigorConnect.

À première vue, en examinant le code désassemblé du binaire VigorConnect, le coupable semblait évident : la méthode SaveToFile du framework web Beego. Cette méthode, chargée d'enregistrer les fichiers téléversés, semblait manquer d'une validation correcte des entrées :

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
}

L'absence de contrôles pour assainir le chemin tofile semblait être un cas d'école de vulnérabilité permettant des attaques de traversée de répertoires. C'était une théorie convaincante, que de nombreux chercheurs en sécurité auraient pu être tentés de suivre. Cependant, le chemin vers la vérité en cybersécurité est souvent plus sinueux qu'on ne le pense.

Poussés par le soupçon persistant qu'il y avait peut-être autre chose, nous avons décidé d'approfondir. Cette décision nous a conduits à employer des techniques de débogage plus traditionnelles, ce qui a préparé une révélation qui allait remettre en cause nos hypothèses initiales. Armés du puissant GNU Debugger (GDB), nous avons mené une investigation plus approfondie. Le processus était méthodique :

1. Lancement de GDB avec le binaire VigorConnect : gdb ./VigorConnect
2. Exécution du programme en mode débogage : r -d &

Après avoir déclenché la vulnérabilité de lecture arbitraire de fichiers, nous avons posé des points d'arrêt sur plusieurs fonctions jusqu'à ce que l'un d'eux soit déclenché : os.OpenFile

1. Nous avons posé un point d'arrêt sur la fonction os.OpenFile : br os.OpenFile et examiné les arguments de la fonction : info args

Le code désassemblé de os.OpenFile a été obtenu après avoir ouvert le binaire avec Ghidra et appliqué tous ses analyseurs :

Cette fonction semble être une opération d'ouverture de fichier de bas niveau. Elle pourrait potentiellement être exploitée si elle n'est pas correctement restreinte, ou si elle est appelée avec une entrée non assainie provenant d'une fonction de plus haut niveau.

1. Remontée de la pile d'appels : bt 20

Notre analyse a révélé les points clés suivants :

1. Le chemin de fichier vulnérable auquel on accède est /usr/local/VigorConnect/FileRoot/tftp./../../../../../etc/passwd.

Il s'agit de la méthode Download de la structure BeegoOutput du framework web Beego. Elle est chargée de servir des fichiers à télécharger.

La sortie de GDB confirme que la fonction est appelée avec un chemin de fichier vulnérable : /FileRoot/tftp./../../../../../etc/passwd

Ce chemin utilise une traversée de répertoires (../) pour accéder au fichier /etc/passwd, qui se trouve en dehors du répertoire prévu.

La fonction décompilée ne montre aucune validation ni aucun assainissement clair du chemin. Elle utilise directement le chemin de fichier fourni pour appeler os.Stat puis, finalement, net/http.ServeFile.

1. Ce chemin est traité par la méthode Get de FileServerController.

Examinons maintenant en détail ce que fait cette méthode, à partir de son code désassemblé :

La méthode utilise la fonction GetString du framework Beego pour récupérer les paramètres de requête des requêtes HTTP entrantes, comme le nom du fichier ou le chemin à télécharger :

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

Ces paramètres de requête sont directement utilisés pour déterminer quel fichier servir. Point crucial, aucune validation ni aucun assainissement strict n'est appliqué à ces entrées, ce qui permet à des attaquants d'injecter des séquences de traversée de répertoires (par exemple ../../../../../) pour accéder à des fichiers situés en dehors du répertoire prévu.

La méthode traite ensuite différents types de requêtes, dont ConfigDownload et uploadfile, qui consistent toutes deux à servir des fichiers au client :

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

Pour les téléchargements de fichiers, la méthode construit un chemin de fichier à partir d'une entrée fournie par l'utilisateur, puis le transmet à la fonction BeegoOutput.Download. Comme aucune validation de l'entrée n'est effectuée, un attaquant peut manipuler ce chemin pour pointer vers des fichiers système sensibles.

Les implications de cette vulnérabilité vont bien au-delà de la simple curiosité technique. Entre les mains d'acteurs malveillants, cette faille pourrait mener à un accès non autorisé à des fichiers de configuration sensibles, à l'exposition d'identifiants d'utilisateurs, et potentiellement servir de tremplin vers des compromissions système plus graves. Par exemple :

• Identifiants de base de données : le fichier app.conf révèle que VigorConnect utilise une base de données SQLite (DbType = sqlite3). Un attaquant pourrait potentiellement accéder au fichier de base de données sqlite/VigorConnect.db, exposant toutes les données stockées.
• Certificats HTTPS : les chemins des fichiers HTTPSCertFile et HTTPSKeyFile sont spécifiés. Y accéder pourrait compromettre la sécurité SSL/TLS de l'ensemble du système.
• Identifiants CLI : les champs CliUser et CliPassword, s'ils sont renseignés, pourraient donner à un attaquant un accès direct en ligne de commande au système.
• Fichiers de journalisation : avec AcsLog défini sur file et AcsLogSrc activé, un attaquant pourrait accéder à des fichiers journaux contenant des données opérationnelles sensibles et potentiellement des activités d'utilisateurs.
• Configuration d'InfluxDB : la présence d'un dossier InfluxDB laisse penser que VigorConnect utilise InfluxDB, probablement pour stocker des séries temporelles. Le fichier influxdb.conf de ce dossier pourrait contenir des identifiants de base de données et des détails de connexion.

Ces exemples illustrent comment cette vulnérabilité pourrait être exploitée pour obtenir un accès profond au système VigorConnect, compromettant potentiellement non seulement le serveur de gestion mais aussi tous les équipements réseau connectés.

Conclusion

Notre analyse confirme non seulement une vulnérabilité critique de lecture arbitraire de fichiers dans VigorConnect, mais rappelle aussi avec force la vigilance constante qu'exige la cybersécurité. Cette faille souligne l'importance d'une revue de code rigoureuse, du principe du moindre privilège et de la défense en profondeur dans la conception des logiciels. À mesure que nous dépendons davantage de systèmes de gestion centralisés comme VigorConnect, la communauté de la sécurité doit rester vigilante, prête à découvrir et à traiter la prochaine menace cachée dans notre infrastructure numérique.