Cherché et trouvé : Faille de sécurité dans un routeur Zyxel

Martin Wrona

14/4/2025

Traduction: traduction automatique

Dans le cadre de la préparation du lancement de notre offre Internet, l'équipe de sécurité de Digitec Galaxus a examiné de plus près le routeur Zyxel que nous avons livré. Lors de l'analyse du routeur, nous avons découvert une vulnérabilité inconnue jusqu'à présent (CVE-2024-12010). sur laquelle j'écris ce rapport.

En tant qu'équipe de sécurité, nous nous efforçons toujours de passer au crible les dernières technologies et les dernières soldes de notre entreprise. Lorsque nous avons pris connaissance de notre offre Internet, notre chef d'équipe, Thomas Houiellebecq, a immédiatement compris que nous devions accorder une attention particulière à cette mise en œuvre afin d'identifier rapidement les éventuels risques de sécurité. C'est important pour nous, car cela nous permet d'influencer directement la sécurité de nos clients.

Il n'a pas fallu longtemps pour que l'équipe responsable du projet nous remette l'un des routeurs Zyxel prévus et que nous commencions notre analyse. Comme Zyxel nous fournit un firmware personnalisé, nous voulions examiner spécifiquement la partie qui nous était destinée et ensuite, de manière plus superficielle, la partie de base utilisée par tous les clients Zyxel.

Interface d'administration

Notre première étape dans le processus d'audit consiste à nous faire une idée de la manière dont le routeur est construit et des fonctionnalités qui sont offertes. Pour ce faire, nous lançons Burp Suite, un outil populaire pour enregistrer et manipuler le trafic web. Nous collectons ainsi tous les itinéraires pour les vérifier ensuite un par un.

À notre grande surprise, toutes les charges utiles POST et les réponses sont cryptées, ce qui rend incroyablement fastidieuse la tâche d'en avoir une vue d'ensemble. Au début, j'ai pensé que cela rendrait le processus de rétro-ingénierie plus complexe, mais nous y reviendrons plus tard. À ce stade, nous avons décidé d'adopter une approche différente.

Analyse du micrologiciel

Heureusement, nous avons le firmware non crypté qui fonctionne sur l'appareil et nous pouvons le démonter. Comme nous n'avons pas l'habitude d'analyser des projets IoT / Closed Source, Thomas a demandé à un collègue de ONEKEY de réaliser un PoC sur leur plateforme.

ONEKEY est une plateforme de sécurité pour les appareils IoT, spécialisée dans l'analyse automatisée des micrologiciels IoT. Un élément central de la plate-forme est l'analyse binaire du micrologiciel, qui décompresse le micrologiciel, classifie, identifie et éventuellement décompile tous les assemblages, puis vérifie le code pour détecter les failles de sécurité potentielles. Les processus automatisés de la plateforme permettent d'identifier rapidement les risques de sécurité potentiels.

Après l'analyse du firmware par la plateforme, nous avions une liste de points que nous voulions examiner de plus près.

À première vue, nous avons quelques vulnérabilités potentielles qui méritent d'être examinées de plus près. Cependant, une analyse plus approfondie révèle que la plupart de ces vulnérabilités ne sont pas directement accessibles ou qu'aucune entrée utilisateur n'est traitée pour permettre l'exploitation de la vulnérabilité. Cela signifie que la menace réelle de ces vulnérabilités est moins importante qu'il n'y paraît à première vue.

La découverte la plus passionnante sur laquelle je m'attarde ici a été identifiée par la plateforme comme une "injection de commande".

Pour analyser et vérifier plus précisément les détections, j'ai chargé la bibliothèque correspondante du firmware dans Ghidra, un outil de rétro-ingénierie open source de la NSA. Dans la vue du code décompilé, nous voyons une fonction qui assemble une commande mailsend avec des données provenant d'un JSON et qui l'exécute ensuite. La découverte semble prometteuse, car les données telles que l'adresse e-mail de l'expéditeur et du destinataire devraient très probablement être des entrées utilisateur.

Exploitation

Nous avons donc une action vulnérable pour laquelle nous devons déterminer si elle est accessible avec des entrées utilisateur et comment elle peut être appelée. Après une courte recherche, j'ai trouvé ce que je cherchais dans les paramètres du journal. Ceux-ci permettent d'envoyer des syslogs à intervalles réguliers à une adresse e-mail spécifique.

Pour exploiter cette fonctionnalité, notre charge utile doit exécuter une commande à l'intérieur de la commande proprement dite. Plus d'informations sur l'injection de commandes sur HackTricks

Cependant, le panneau d'administration ne nous a pas permis de saisir les caractères spéciaux dont nous avions besoin pour notre attaque. Et s'il s'agissait simplement d'une validation côté client?

Pour pouvoir manipuler les requêtes vers le backend, nous avons d'abord dû contourner le cryptage côté client. Pour ce faire, j'ai défini un point d'arrêt dans la fonction de cryptage AES Javascript correspondante dans le débogueur Chrome et j'ai ensuite pu ajuster la valeur avant le cryptage via la console. Ensuite, le flux du programme a continué et la requête manipulée a été transmise au serveur.

Le résultat de la requête manipulée se présentait comme suit. Comme nous le voyons, la validation des caractères spéciaux n'était qu'un contrôle côté client que nous avons réussi à contourner.

La configuration des paramètres de messagerie était prête et nous devions déclencher la fonction pour que notre payload soit exécuté. Pour cela, nous avons utilisé la fonction de log "E-mail Log Now".

Après avoir vérifié la fonctionnalité de l'injection de commande, j'ai construit en Python une simple preuve de concept qui automatise le processus complet.

Pendant cette mise en œuvre, j'ai dû reconstruire le chiffrement côté client et j'ai reproduit la procédure suivante.

1. Le client génère une clé AES aléatoire
2. Le client obtient une clé publique via le point de terminaison /getRSAPublickKey
3. Le client envoie la clé AES générée pendant la connexion, cryptée avec la clé publique du routeur
4. Le client crypte ou décrypte toutes les requêtes / réponses suivantes avec la clé AES

Ce processus ressemble à une implémentation simplifiée de TLS. Les appareils peuvent être livrés sans certificat ou, comme dans notre cas, avec un certificat auto-signé, ce qui laisse supposer que cette méthode est conçue comme une mesure de protection supplémentaire contre les attaques de type man-in-the-middle.

PoC Exploit

Nous avons envoyé le script à Zyxel et leur équipe de sécurité a pu reproduire le problème dans leur firmware standard.

Timeline:

Nov 25, 2024 Report
Nov 29, 2024 Review / Repro
Déc 10, 2024 CVE assigned
Déc 12, 2024 Fix Released
Mar 11, 2025 Public Advisory

Périphériques concernés :

42 appareils, du CPE DSL/Ethernet, Fiber ONT au Wi-Fi extender.
Voir l'avis de Zyxel

Conclusion

L'équipe de sécurité de Zyxel a traité les vulnérabilités signalées avec une priorité élevée et les a transmises au groupe de produits concerné. La collaboration a été professionnelle et, grâce à la preuve de concept que j'ai fournie, un correctif a pu être rapidement développé et distribué aux clients. La plateforme ONEKEY nous a permis d'obtenir rapidement une vue d'ensemble du firmware concerné, ce qui a considérablement accéléré l'ensemble du processus.

Saviez-vous que nous avons un Vulnerability Disclosure Program chez Digitec Galaxus ? Les pirates éthiques peuvent également rechercher des failles de sécurité chez nous, à condition de respecter les règles. Vous trouverez plus d'informations à ce sujet sur notre page Sécurité.

Martin Wrona

Senior Security Software Engineer

Martin.Wrona@digitecgalaxus.ch

Ces articles pourraient aussi vous intéresser