Dans les coulisses
Des données à l'action : Le développement de produits en pleine mutation (partie 1)
par Ronny Wullschleger
Cherché et trouvé : Faille de sécurité dans un routeur Zyxel
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.
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.
Après l'analyse du firmware par la plateforme, nous avions une liste de points que nous voulions examiner de plus près.
La découverte la plus passionnante sur laquelle je m'attarde ici a été identifiée par la plateforme comme une "injection de commande".
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.
- Le client génère une clé AES aléatoire
- Le client obtient une clé publique via le point de terminaison
/getRSAPublickKey - Le client envoie la clé AES générée pendant la connexion, cryptée avec la clé publique du routeur
- 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
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.chSécurité
Suivez les thèmes et restez informé dans les domaines qui vous intéressent.
Tech
Suivez les thèmes et restez informé dans les domaines qui vous intéressent.
Dans les coulisses
Actualités sur les fonctionnalités de la boutique, informations sur le marketing ou la logistique et bien plus encore.
Tout afficher
