Compte rendu conférence SSTIC 2019 : Analyse de firmwares de points d’accès, rétro-ingénierie et élévation de privilèges

Kevin Boulom Non classé

Le sujet de la conférence permettait de présenter les résultats concernant l’analyse et le reverse engineering de point d’accès WiFi. Durant ce talk, Victorien Molle nous présente les vulnérabilités découvertes avec ses collègues Romain Bellan et Florent Fourcot. Les cibles sont des points d’accès WiFi Ruckus et Aerohive. L’article complet, les slides et la présentation vidéo est disponible ici : https://www.sstic.org/2019/presentation/analyse_de_firmwares_de_points_dacces_retro_ingenierie_et_elevation_de_privileges/

Comme expliqué dans un de mes précédent post touchant à l’exploitation hardware, la plupart des points d’accès wifi sont mal sécurisé tant d’un point de vue matériel (hardware) que logiciel (software). Les étapes classiques de ce genre de recherche de vulnérabilités sont les suivantes :

  • Analyse du fonctionnement normal de l’appareil
  • Obtention ou dump du firmware
  • Extraction du système d’exploitation (RootFS)
  • Analyse du fonctionnement du routeur (binaires utilisés, dépendances entre binaires, ….)
  • Ciblage des binaires intéressants
  • Analyse statique des binaires (Reverse engineering)
  • Analyse dynamique des binaires (Débogage)
  • Découverte de vulnérabilités
  • Exploitation des vulnérabilités

Il apparaît que pour exploiter les différents points d’accès présentés, l’attaquant doit déjà être en mesure d’avoir accès au routeur et de pouvoir se connecter en administrateur via SSH.

La question pourrait se poser alors « puisque l’attaquant a déjà un accès administrateur, quel est l’intérêt de cette attaque ?« .

Quand un attaquant arrivera sur l’interface administrateur standard de l’appareil, celle-ci récupèrera les traces de toutes les actions effectuées par cet utilisateur. Ces actions peuvent être remontées au fabricant qui, je suppose, propose une solution de monitoring des équipements vendus.

Dans le cas de l’exploitation de ces vulnérabilités, l’attaquant outrepassera cette surveillance et pourra ainsi passer inaperçu. L’orateur a porté son attention sur les points d’accès Rukus durant sa présentation, nous en feront de même sur ce billet.

Les auteurs ont donc cherché dans le shell d’administration usuel des fonctions cachées. Ils sont tombés sur des commandes intéressantes, notamment la commande « !v54! ». Cette commande permet d’appeler le binaire « /bin/sh » sur le système d’exploitation et ainsi de sortir de la zone surveillée.

L’orateur a ainsi préféré l’analyse dynamique du code. Pour ce faire, ils ont téléchargé le firmware du point d’accès directement sur le site du constructeur. Ils ont ainsi pu le décompresser avec l’outil BinWalk pour en extraire le système de fichier RootFS.
Ainsi, ils ont pu charger les binaires qui les intéressaient sur du matériel similaire, mais dont ils avaient le contrôle (architecture avec processeur MIPS). Celui-ci intégre également un serveur de débogage « GDB Server », qui permet de tracer l’exécution de chaque instruction d’un binaire et de retransmettre l’information vers un Framwork de reverse engineering (l’outil IDA). Cette méthode permet de charger le binaire dans IDA et ainsi de suivre l’exécution pas à pas du binaire.

D’après les informations recueillies, la commande « !v54! » demande 1 paramètre en entrée. La mission de l’orateur sera maintenant de trouver quel paramètre doit être passé afin d’escape la zone surveillée.

Après étude du fonctionnement de cette commande, il apparaît que le workflow soit le suivant : 

Sesame étant une fonction permettant de générer une clé dérivée ainsi qu’un fichier avec N fois le numéro de série de l’appareil.

OMAC est une fonction cryptographique qui prendra en entrée la clé dérivée, le fichier généré, ainsi que le numéro de série de l’appareil. Il nous donnera en sortie une clé secrète.

Les 16 derniers octets de la clé secrète seront comparés avec les 16 derniers octets de la clé dérivée. Si ceux-ci correspondent, nous avons accès au shell root.

Comme dit précédemment, la commande « !v54! » demande 1 argument. Cet argument subit une dérivation et une transformation, qui donnera en sortie une clé dérivée de 24 octets.

Cette clé sera ensuite passée à une fonction permettant de générer un fichier secret. Ce secret est en réalité la copie de N fois le numéro de série du point d’accès. Le chiffre N est calculé en additionnant quelques octets de la clé dérivée accompagné d’une application d’un masque binaire.

En admettant « k » la clé dérivée.

N = (k[13] + k[14] + k[15]) & 0x3F

Ensuite, la clé dérivée, le fichier secret, ainsi que le numéro de série sont passés à la fonction cryptographique OMAC. En sortie, la fonction nous renvoie une clé secrète.

Enfin, les 16 derniers octets de la clé secrète seront ensuite comparés aux 16 derniers octets de la clé dérivée. S’il y a concordance, le point d’accès ouvre un shell root.

Nous pouvons donc constater la faiblesse qui est ici. En effet, l’appareil ne semble pas utiliser de chiffrement avec un secret fort. Il semble donc possible, en connaissant le numéro de série (qui est la seule constante), de générer une commande valide.

Ainsi, en inversant le processus de vérification, il leur a été possible de créer un générateur de clé (keygen) permettant d’obtenir un accès « super » administrateur sur n’importe quel équipement du même type.

Cette vulnérabilité pourrait permettre à un attaquant d’être persistant dans un système malgré les mises à jour du firmware et ainsi, de passer inaperçu. Il pourrait ainsi intercepter toutes les communications passant par ce point d’accès, notamment les mots de passe ou les fichiers sensibles.

Depuis, la société de Ruckus à patché cette vulnérabilité en utilisant un système de chiffrement asymétrique. La vérification se fait donc sur un paramètre qui a été préalablement chiffré avec leur clé privée, puis le point d’accès vérifie ce paramètre en déchiffrant avec la clé publique du constructeur. De ce fait, le matériel vérifie la légitimité de la personne qui tente d’accéder au matériel.

Cependant, cette sécurité pourrait éventuellement être également cassée. Dans le cas où un attaquant se positionne en interception des communications, il serait éventuellement possible de rejouer le paramètre chiffré. Dans ce cas, il faudrait étudier le paramètre déchiffré via la clé publique stockée dans le point d’accès pour constater (ou non) l’utilisation d’une valeur pseudo-aléatoire empêchant le rejeu de commande.