Exploitation du mécanisme de sous-application de SteelSeries pour l'escalade des privilèges
Synthèse
Tomer Peled, chercheur en sécurité chez Akamai, a récemment découvert deux vulnérabilités dans l'application SteelSeries.
SteelSeries est une entreprise qui fabrique des périphériques informatiques et compte plus de 9 millions de clients dans le monde.
Les références CVE-2023-31461 et CVE-2023-31462 ont été attribuées à ces vulnérabilités. SteelSeries a agi rapidement pour corriger ces vulnérabilités en mai 2023.
Ces vulnérabilités permettent à un pirate d'exécuter du code avec des privilèges plus élevés que ceux obtenus initialement, notamment avec des privilèges ADMIN. Pour exploiter ces vulnérabilités, le pirate doit envoyer deux paquets locaux à un serveur IPC en écoute. Le serveur exécute alors la charge utile du pirate avec des privilèges élevés.
La cause profonde de ces vulnérabilités repose sur une gestion non sécurisée des autorisations dans l'auditeur IPC du service et sur un manque de protection contre le Path Traversal.
Le Groupe Security Intelligence (SIG) d'Akamai a pris la décision de divulguer en responsabilité les vulnérabilités aux équipes d'assistance et d'ingénierie de SteelSeries et les a soumises à MITRE pour les CVE attribués.
Le SIG a trouvé le service vulnérable dans plusieurs centres de données que nous surveillons et a informé les clients du risque et de la marche à suivre pour l'atténuer.
- Nous fournissons une version de démonstration présentant l'exploitation ainsi qu'une requête osquery pour détecter les machines ayant un service vulnérable.
Introduction
SteelSeries est une entreprise de matériel informatique spécialisée dans les périphériques d'ordinateurs, tels que les claviers, les souris, les casques d'écoute, etc. Pour personnaliser ces périphériques, SteelSeries propose à ses utilisateurs une application, SteelSeries GG, qui peut être téléchargée depuis son site Web.
Cette application, composée du module principal SteelSeries GG et de plusieurs sous-applications, est un mécanisme que SteelSeries utilise pour améliorer l'expérience de l'utilisateur.
Dans nos recherches, nous avons découvert deux façons d'enregistrer notre propre sous-application et de spécifier le code à exécuter à travers elle, ce qui peut permettre l'exécution de code avec des autorisations plus élevées. Dans ce billet de blog, nous fournissons les détails techniques des vulnérabilités ainsi qu'une version de démonstration présentant l'exploitation.
Détails techniques
SteelSeries GG est exécuté par défaut à un niveau d'intégrité moyen, et généralement dans l'environnement de l'administrateur. Par conséquent, il peut être exécuté dans un environnement de haute intégrité dans certaines circonstances. Ce détail, combiné au fait que SteelSeries GG est un processus d'écoute (Figure 1), en fait une cible de choix pour la recherche de vulnérabilités.
Figure 1 : Process Hacker et netstat montrent l'application SteelSeries GG en écoute
Le mécanisme de sous-application et l'API de communication interprocessus
Le mécanisme de sous-application est utilisé pour gérer les fonctions optionnelles de SteelSeries et améliorer l'expérience de l'utilisateur. À titre d'exemple, citons Sonar, « une suite avancée d'outils logiciels audio pour le jeu qui donne à chacun la possibilité de régler séparément le son du jeu, le chat d'équipe et le microphone », selon la définition de SteelSeries. Les sous-applications s'exécutent en arrière-plan et communiquent avec le module principal de l'application par l'intermédiaire d'une API de communication interprocessus (IPC).
L'API IPC de SteelSeries GG présente plusieurs types d'opérations qu'un utilisateur peut demander, y compris des changements de configuration, des actions administratives, des modifications de profil utilisateur, etc. Plus intéressant : l'API propose une interface permettant de gérer les sous-applications, de la création à la suppression, en passant par l'activation et la désactivation.
La fonctionnalité de routage de l'API (à savoir, comment traiter chaque requête API) est mise en œuvre à l'aide de la bibliothèque open source gorilla/mux . En nous appuyant sur ces éléments, nous pouvons plus facilement explorer la surface d'attaque. La fonction de routage elle-même est très volumineuse, mais il s'agit essentiellement d'un ensemble d'instructions SI pour chacune des options d'API disponibles (Figure 2).
Figure 2 : La mise en œuvre du routage HTTP dans SteelSeries GG
Ces appels API sont accessibles à toute personne qui établit une connexion avec le serveur d'écoute ("SteelSeriesGG.exe") et ne nécessitent aucune authentification.
J'ai choisi de me concentrer sur les gestionnaires d'événements des sous-applications, car ce sont eux qui ont le plus d'impact potentiel. Après avoir réorganisé le code désassemblé dans IDA, nous avons constaté que les gestionnaires de routage pour les sous-applications ont le prototype présenté à la Figure 3.
Figure 3 : Prototype de la fonction de gestionnaire dans le code gorilla/mux
Exploitation du mécanisme de sous-application
L'un des appels API que nous pouvons effectuer consiste à créer une nouvelle sous-application. Ce processus s'effectue en envoyant une requête POST au chemin /subApps avec une charge utile JSON qui contient plusieurs paramètres, dont quatre nous intéressent : "name" (nom), "executableName" (nom du fichier exécutable), "isEnabled" (est activé) et "shouldAutoStart" (doit démarrer automatiquement).
En utilisant ces champs, nous pouvons pratiquement créer une nouvelle sous-application en tant qu'utilisateur non privilégié, la faire pointer vers un exécutable dans un emplacement non privilégié et éventuellement la planifier à chaque démarrage de l'application.
SteelSeries GG construit le chemin complet du fichier exécutable de la sous-application comme suit :
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
Sachant que les champs « name » et « executableName » sont concaténés de cette manière, nous nous sommes dit que nous pouvions tenter une attaque Path Traversal. Comme indiqué, SteelSeries GG est vulnérable aux Path Traversals, et le fait de faire précéder le chemin par « ../../../../../ » a été accepté, comme le montre la Figure 4.
Figure 4 : Le Path Traversal est accepté lors de la création d'une nouvelle sous-application
Lorsqu'une sous-application est créée, les informations la concernant sont stockées dans la base de données de SteelSeries GG. Existe-t-il un autre moyen de contrôler les sous-applications par le biais de cette base de données ? En effet, la base de données est située dans un emplacement non sécurisé. Cela signifie que, même sans accès à l'API de sous-application, nous pouvons ajouter une sous-application directement à la base de données. Toutefois, les pirates devront trouver une vulnérabilité pour utiliser à mauvais escient ce défaut de conception, qui n'est pas exploitable en lui-même et ne pose donc pas de risque immédiat.
On pourrait penser que la création d'une sous-application dans un emplacement contrôlé signifie l'obtention de privilèges élevés (une fois exécuté un fichier binaire à partir de ce chemin), mais en essayant cela, nous avons découvert qu'il y a une autre contrainte : la validation de certificat. SteelSeries s'assure à juste titre que les fichiers exécutables des sous-applications sont signés et approuvés. Pour exécuter notre propre charge utile, nous devrons contourner le processus de vérification.
La fonction de vérification appelle la fonction WinVerifyTrust et appelle ensuite une chaîne de fonctions WinAPI pour comparer certains champs du certificat avec des chaînes codées en dur dans l'application.
Cette validation est un peu difficile à contourner, mais est possible de deux manières :
Détournement DLL
TOCTOU (time-of-check to time-of-use)
Le vecteur de détournement DLL
Avec la technique de détournement DLL, nous pouvons nous appuyer sur le fait que SteelSeries fait confiance à plusieurs fichiers binaires existants ; l'un d'entre eux est SteelSeriesEngine.exe, qui charge la bibliothèque SSEDEVICE.dll. Nous compilerons notre propre bibliothèque avec le même nom afin qu'elle soit chargée à la place de la DLL SSEDEVICE d'origine. Les fonctions exportées de notre propre DLL appelleront les fonctions de la DLL authentique.
Toutefois, la fonction appelée lors du chargement de notre DLL mettra en œuvre notre logique malveillante (Figure 5). La technique est expliquée plus en détail dans l' article de blog DLL Proxying d'itm4n.
Figure 5 : Détournement de DLL de SSEDEVICE
L'animation de la Figure 6 montre le processus qui va de l'envoi du paquet initial à l'exécution de la charge utile du pirate (dans notre cas, l'ouverture d'une instance cmd) avec des privilèges élevés.
Figure 6 : Le processus d'envoi du paquet initial jusqu'à l'exécution de la charge utile du pirate avec des privilèges élevés
Le vecteur TOCTOU
Dans ce cas, nous tirons parti du délai entre la vérification du certificat et l'exécution effective du fichier binaire (Figure 7). En d'autres termes, nous nous lançons dans une course de vitesse en remplaçant rapidement le fichier légitime par un fichier malveillant à l'aide de l'outil BaitAndSwitch de James Forshaw. Nous souhaitons le remplacer immédiatement après la vérification du certificat. De cette manière, la vérification est effectuée sur un fichier légitime, mais un fichier malveillant non vérifié est ensuite exécuté.
Par nature, ces concurrences critiques ne sont pas garanties de fonctionner. Pour optimiser nos chances de succès, nous pouvons essayer de gagner davantage de temps pour le remplacement afin d'élargir notre fenêtre d'opportunité.
Figure 7 : Illustration du vecteur TOCTOU
Rappelons que la vérification du certificat repose sur deux tests : un appel à WinVerifyTrust et une vérification entre plusieurs champs du certificat et des chaînes codées en dur dans l'application. Nous pouvons implanter un certificat avec ces valeurs exactes dans notre exécutable. Cette amélioration permet au pirate d'être dans une position idéale même si le changement se produit entre les deux tests, car notre fichier binaire malveillant répond à tous les critères du deuxième test.
L'animation de la Figure 8 montre le processus qui va de l'attente du début du processus de vérification avec BaitAndSwitch à l'exécution du fichier binaire du pirate (dans ce cas, cmd.exe).
Figure 8 : Le processus allant de l'attente du début du processus de vérification avec BaitAndSwitch à l'exécution du fichier binaire du pirate
Détection et prévention
Pour faciliter la détection d'éléments vulnérables dans le réseau, nous fournissons une requête osquery permettant de trouver des instances de SteelSeries GG et sa version actuellement installée :
SELECT name,version from programs where name LIKE '%SteelSeries%' |
Les clients d'Akamai Guardicore Segmentation peuvent utiliser cette requête avec Insight pour localiser les applications nécessitant un correctif.
SteelSeries met à jour son application à chaque nouveau correctif. Cela peut limiter les risques d'exposition de vos terminaux à ces vulnérabilités, mais nous vous conseillons de mettre à niveau SteelSeries vers une version supérieure à la version 39.
Conclusion
SteelSeries est une grande entreprise avec une base d'utilisateurs considérable de plus de 9 millions de clients dans le monde. Toute vulnérabilité de ses produits a un impact intrinsèque. Les conséquences sont aggravées selon la facilité d'exploitation de ces vulnérabilités et leur impact sur chaque machine, notamment en permettant potentiellement l'exécution de fichiers binaires avec des droits ADMIN.
La portée de cet impact n'est pas limitée à la machine appartenant à l'utilisateur ; toute l'entreprise peut également être touchée. L'ordinateur portable d'un employé qui se connecte à un terminal vulnérable ou exécute une application vulnérable peut ensuite être connecté au réseau de l'entreprise et « importer » des risques dans l'organisation. Il est donc important que les entreprises envisagent de mettre en place une règle BYOD (Bring Your Own Device) et de sensibiliser les employés aux dangers liés à l'utilisation de tels terminaux.
Nous avons analysé les réseaux des clients d'Akamai pour rechercher des instances de l'application vulnérable et avons informé les clients concernés.
Dans le cadre de nos efforts continus visant à protéger nos clients et la communauté, nous continuerons d'analyser les correctifs et autres systèmes afin de détecter toutes vulnérabilités. Pour vous tenir informé des recherches les plus récentes d'Akamai en matière de sécurité, suivez-nous sur Twitter.
Calendrier de divulgation
27/04/2023 — Requête CVE soumise à MITRE
01/05/2023 — E-mail envoyé au support client de SteelSeries
02/05/2023 — CVE attribués par MITRE
03/05/2023 – 04/06/2023 — Conversations avec l'équipe d'ingénierie de SteelSeries
31/05/2023 — Correctifs publiés
17/07/2023 — Brouillon de blog révisé par SteelSeries
18/07/2023 — Article de blog publié
