Skip to content
Prochain webinaire : Libérez la puissance de la recherche sur Censys avec Em Averton | 27 juin à 13h ET | S'inscrire maintenant
Blogs

CVE-2022-30525 : Vulnérabilité d'injection de commande du système d'exploitation Zyxel

Le 12 mai 2022, des détails ont été publiés sur une vulnérabilité qui cible plusieurs dispositifs VPN et pare-feu de Zyxel Networks. Répertoriée sous le nom de CVE-2022-30525 avec un score CVSS de 9.8 (critique), cette vulnérabilité permet à un attaquant d'exécuter des commandes arbitraires sur le dispositif sans authentification. Découverte par des chercheurs de Rapid7, cette vulnérabilité est facile à exploiter et a déjà été utilisée avec succès dans la nature.

Censys a été en mesure de relever les empreintes digitales et d'identifier les versions en cours d'exécution de ces appareils. Au moment de la rédaction du présent document, Censys a observé les éléments suivants 19 506 dispositifs de pare-feu/VPN Zyxeldont plus de 7 500 pourraient être vulnérables à cette attaque spécifique.

La bonne nouvelle est que beaucoup de ces appareils semblent avoir activé les mises à jour automatiques, puisque nous avons déjà observé des milliers d'hôtes avec la dernière version de microprogramme corrigée 5.30 installée ces derniers jours.

Série ATP

Résumé

Versions vulnérables v5.10 - v5.21 (corrigé dans la v5.30)
Censys Requête de recherche services.http.response.html_title: {“ATP100″,”ATP200″,”ATP500″,”ATP700”}
Nombre de résultats 5,899

USG FLEX 50(W)

Versions vulnérables v5.10 - v5.21 (corrigé dans la v5.30)
Censys Requête de recherche services.http.response.html_title: {“USG FLEX 50″,”USG FLEX 50w”}
Total des résultats 5,321

USG FLEX 100(W), 200, 500, 700

Versions vulnérables v5.00 - v5.21 (patché dans v5.30)
Censys Requête de recherche services.http.response.html_title: {“USG FLEX 100″,”USG FLEX 100w”,”USG FLEX 200″,”USG FLEX 500″,”USG FLEX 700″}
Total des résultats 8,287

Identification et empreinte digitale des appareils Zyxel

Pour déterminer la portée réelle de cette vulnérabilité, nous avons dû trouver une méthode pour identifier les versions spécifiques du logiciel en cours d'exécution. C'est parfois plus facile à dire qu'à faire, et ce fournisseur ne fait pas exception à la règle. Il n'y a pas d'information spécifique dans les données de notre analyse qui indique la version réelle du logiciel en cours d'exécution. Mais cela ne nous a pas découragés, car nous avons déjà réussi à versionner des logiciels non versionnables.

La première étape a consisté à examiner les artefacts et les données dont nous disposons actuellement pour voir si nous pouvions éventuellement utiliser quelque chose pour faire correspondre un appareil à une version spécifique. Il semblait que chaque appareil Zyxel que nous pouvions trouver dans nos données avait un ensemble commun de fichiers javascript que l'appareil importait :

L'un des fichiers javascript inclus qui a attiré notre attention s'appelle "/ext-js/app/common/zld_product_spec.js" et contient également un argument de requête nommé "v" suivi d'une chaîne de nombres. Il contenait également un argument de requête nommé "v" suivi d'une chaîne de nombres :

Comme nos données ne comprennent que les informations trouvées à la racine du service HTTP, nous avons dû récupérer manuellement ce fichier public spécifique. Le contenu de ce fichier contient plus de mille lignes de variables javascript, dont une variable nommée "ZLDCONFIG_CLOUD_HELP_VERSION".

~$ curl -sk https://$HOST/ext-js/app/common/zld_product_spec.js?v=220420024630 | grep ZLDCONFIG_CLOUD_HELP_VERSION

var ZLDCONFIG_CLOUD_HELP_VERSION=5.30 ;

~$

Il semble que cette variable soit utilisée dans le logiciel pour générer des liens vers la documentation spécifique à la version sur la page de support client de Zyxel. Mais si nos hypothèses sont correctes, nous pouvons utiliser cette variable pour potentiellement associer le lien "?v=220420024630" à une version réelle de l'appareil.

Nous devions générer une liste d'hôtes et les caractères numériques qui suivaient le fichier "zld_product_spec.js" en utilisant uniquement les données de notre ensemble de données. Pour ce faire, il est préférable d'utiliser l'interface BigQuery de Censys(disponible pour les clients professionnels) :

 

Le résultat ressemble à ce qui suit et peut être enregistré au format CSV :

Nous avons ensuite pris la liste complète et écrit un petit script personnalisé pour récupérer automatiquement le fichier "/ext-js/app/common/zld_product_spec.js" de l'hôte, analyser les résultats et créer un fichier journal contenant les nombres suivant l'argument "v" et la valeur de la variable "ZLDCONFIG_CLOUD_HELP_VERSION" trouvée dans le fichier javascript "zld_product_spec" proprement dit. En voici un exemple,

$ tail -n 5 hosts.log
220315001833, 5.20
220420064457, 5.30
220315032123, 5.20
220420002802, 5.30
220420001613, 5.30

Après une analyse approfondie de ces résultats, nous avons déterminé qu'il suffisait de regarder les quatre premiers chiffres de ce numéro "v" pour l'associer à une version spécifique du micrologiciel. Et comme nous ne devons identifier que les versions comprises entre 5.00 et 5.30, nos données nous permettent d'affirmer ce qui suit :

  • v5.00 a une valeur d'argument "v" comprise entre '2106' et '2108'
  • v5.10 a une valeur d'argument "v" comprise entre '2109' et '2111'
  • v5.20 a une valeur d'argument "v" comprise entre '2201' et '2203'
  • v5.30 (la dernière et la première version non vulnérable) a une valeur d'argument "v" qui commence toujours par "2204".

Avec ces informations en main, nous pouvons alors construire une image complète de l'internet et de la façon dont cette vulnérabilité l'affecte. Une fois de plus, la meilleure façon d'y parvenir est d'utiliser l'interface BigQuery de Censys :

Ce qui nous a donné un total de 71 résultats, qui ont tous été associés à une version spécifique du micrologiciel. Nous avons ensuite utilisé ces données pour générer les rapports de synthèse présentés au début de cet article.

 

Que peut-on faire ?

A propos de l'auteur

Mark Ellzey
Chercheur principal en sécurité Tous les postes de Mark Ellzey
Mark Ellzey est chercheur principal en sécurité à l'adresse Censys. Avant d'occuper son poste actuel, Mark a travaillé pendant plus de 22 ans en tant qu'ingénieur en sécurité des réseaux et développeur de logiciels pour plusieurs fournisseurs de services Internet et institutions financières.
Solutions de gestion de la surface d'attaque
En savoir plus