SSTIC 2023 - J2

Vulnérabilités dans le protocole RemotePlay

Steam est l’application de jeu la plus populaire sur PC, avec une très grosse surface d’attaque. Elle fait l’objet d’un BugBounty sur HackerOne. Le RemotePlay est un protocole non documenté sans rapports de vulns publics. Il permet dans son mode « together » un streaming et un contrôle à distance pour que deux personnes puissent jouer ensemble. L’hôte envoie un lien qui permet de se connecter à la session de jeu, ce qui offre une grosse surface d’attaque.

l’imple du remote-play est dans SteamUI.dll, et implémente des briques de streaming voix, image et contrôle. Les canaux de com sont multiplexés dans le protocole sous forme de channels, un par fonction tel que la voix, le son, les commandes du pad/clavier/souris, etc.

Les candidats au fuzzing sont la mécanique de contrôle des messages, le remote HID pour les claviers/souris/pad et les codec audio/vidéo.

L’orateur à d’abord construit un client et un serveur remoteplay en python, qui est vite devenu un fuzzer. Bien que simpliste, il est très efficace. Grâce à ça, il a pu trouver une douzaine de bugs. Seule les vulnérabilités patchées sont présentées, une format string, et une CSRF.

La format string est présente dans une url envoyée à tous les clients steam participant à un « remote play together » chargé de charger le profil de chaque joueur. Toutes les debug strings sont envoyé à l’ĥote via le channel « stats ».

La CSRF est une url contrôlée par l’attaquant qui génère une requête CURL qui lorsqu’elle part en vrac provoque un message d’erreur renvoyé dans le canal « stats ».

Leveraging android permissions

Android fait fonctionner ses applications dans des sandbox, et filtre l’accès à certaines fonctions via un système de permissions dynamiques. Certaines permissions comme l’accès à la caméra, le micro, etc… et sont classées par niveau de risque pour l’utilisateur. Les plus sensibles sont sous privilèges « système ». Certaines permissions comme les SMS sont groupées, et autorisent à la 1ere acceptation de l’utilisateur l’accès à tout un ensemble de privilèges. Ceci pour éviter que l’utilisateur soit spammé de popups de permissions.

L’orateur décrit ensuite une vulnérabilité ou lors d’une mise à jour d’une appli, le manifest peut être mis à jour, et les permissions se retrouverons mises à jour au reboot.

L’orateur à modélisé le système de permissions Android dans un solveur pour rechercher des élévations de privilèges. Cette modélisation est un peu longue et nécessite de bien faire attention à chaque cas particulier du fonctionnement d’Android. Une fois ce modèle construit, il suffit de décrire l’action recherchée, et le solveur va proposer des solutions. S’il trouve des solutions, alors une vulnérabilité est trouvée.

Analyse de sécurité de NetBackup

Netbackup est une application de sauvegarde le plus répandu dans les grandes entreprises. Ces systèmes de backup ont des privilèges élevés, et stocke des données sensibles voir essentielles pour l’entreprise.

Des vulnérabilités ont été découvertes dans NetBackup et présenté à Hexacon 2022. La prise en compte et la remédiation des vulnérabilités par l’éditeur Veritas s’est très bien passé, et c’est assez rare pour être souligné.

Le fonctionnement interne de NetBackup dépend de centaines de binaires propriétaires issu du rachat de nombreuses sociétés. Par exemple pour une simple sauvegarde planifiée, une douzaine de binaires rentre en jeux et communiquent entre eux. Ces derniers tournent tous en root, et sont codés avec des technologies très diverses. Chaque binaire attend des commandes sur le réseau, et dispose de son propre protocole.

pbx_exchange maintient une liste dynamique de services qui viennent s’enregistrer avec leur version. Les services s’enregistrent via un socket unix qui écoute en local. La liste des services permet d’identifier le rôle de la machine NetBackup. VNETD est un composant legacy de NetBackup qui offre une liste de commandes, dont des informations de version et de services installés. Du coup via le port 1556, via pbx_exchange et vmnetd, on peut cartographier l’ensemble des composants NetBackup sur un LAN.

Les données du serveur principal Netbackup sont stockées dans une base sybase chiffrée, mais les clefs sont sur le filesystem, et une commande permet de modifier ce mot de passe. Les outils d’admins NetBackup sont détournables pour récupérer les fichiers, les restaurer ou les re-écraser.

Les orateurs ont codé un outil nbuscan.py et nbudump.py. Ces outils permettent de cartographier un système netbackup et de déchiffrer la base de donnée. La surface d’attaque étant énorme, il est fortement probable qu’il existe pas mal de RCE sur ces systèmes.

Mercator: Cartographie du système d’information

Les SI hospitaliers sont très complexes, et d’importance vitale. Le problème pour les RSSI c’est d’identifier ces composants et les inter-dépendances fonctionelles entre de nombreuses applications. Mercator est une application web qui permet de gérer la cartographie du SI tel que conseillé dans le guide de la cartographie de l’ANSSI. Les inventaires ont la faiblesse de ne pas représenter les inter-dépendances.

L’outil propose plusieurs niveaux de granularité, et plusieurs vues en fonction du métier (réseau, fonctionnel, etc…). Il intègre un niveau de maturité de la cartographie afin de savoir ou on en est dans la mise en oeuvre de la carto.

ChromeDump: All your scripts are belong to us

ChromeDump est un outil d’instrumentation du navigateur chrome via le ChromeDevtools Protocol (CDP) orienté analyse JavaScript. Il permet l’enregistrement de la session de navigation et la sauvegarde des codes JavaScripts chargés par le moteur V8. L’interception du JavaScript à l’entrée du moteur permet de capturer le code exécuté dynamiquement comme on peut le retrouver dans les obfuscateurs JavaScript. Il enregistre aussi la pile d’appel JS, et les urls consultés afin de pouvoir analyser hors-ligne les résultats de la navigation. L’outil est disponible sur GitHub.

Deep attack surfaces – shallow bugs

Tous les rapports de vulns exposent le process suivant: on regarde la cible, on trouve un bug, on l’exploite, et tadaaa. C’est classe, ça a l’air badass, mais ça ne montre pas le process réel et tous les échecs que rencontrent les chercheurs avant de trouver. Peut de chercheurs publient leurs échecs.

Solardiz a dit que c’est pas le bug qui compte mais la surface d’attaque. Il faut arrêter de s’attaquer aux vulns hardcore, il y a suffisament de logiciels d’entreprise complètement pourris qui n’ont jamais été regardé.

La plupart des vulnérabilités binaire sont des corruptions mémoire. Trouver un interger overflow, c’est pas mystérieux, c’est une question de méthodologie. Il n’est pas facile de trouver des bugs qui sont des vulnérabilités exploitables. Certains chercheurs se spécialisent sur une techno pour s’économiser dans la connaissance du contexte technique nécessaire à l’exploitation des vulns sous telle ou telle techno.

L’autre façon d’approcher ça, c’est de s’ennuyer rapidement, et de passer d’un système à l’autre, et de regarder plein de trucs différents ou l’on passe moins de temps à chercher des bugs, et plus à considérer quelle serait la bonne cible pour ce type de bugs.

Si le composant n’est pas populaire, il y a de grandes chances que personne n’ai regardé ça de près. En gros, moins ya de CVE, plus c’est pourri.

Exemple avec afd.sys, un driver vulnérable avec des bug « probablement exploitables » avec des pointeurs non validés issue d’entrées utilisateur. Maintenir des exploits fonctionnels, c’est comme être un core dev d’un produit mais sans les bénéfices, vu que vous avez pas la doc, l’environement de compilation etc…

L’oratrice à en suite appliqué son approche à SMB sous Windows. Elle a d’abord cartographié l’ensemble des services liés à SMB et comment ça fonctionnait, puis elle a sélectionné les fonctionnalités qui avait le plus de chances de contenir des bugs potentiellement exploitables. Après avoir regardé tous les bugs déjà sorti sur chacune de ces fonctionalités, l’oratrice à réduit ses investigations à la couche d’authentification de Windows sur SMB.

Toute l’authentfication passe par le SSPI: Security Support Provider Interface. Chaque mécanisme d’authentification existe sous forme de DLL et doit respecter cette interface. Il ya pas mal de mécanismes d’authentification supporter sous ce format dont les fameux Kerberos et NTLM. Un seul de ces mécanismes n’a pas fait l’objet de vulnérabilités, c’est NEGOEXTS.

NegoExts.dll est chargé dans LSA au démarrage. L’oratrice à analysé le protocole réseau permettant de négocier une authentification via NEGOEXTS. Avec l’aide des symboles, on y identifie 279 fonctions. Dans toutes ces fonctions, l’oratrice à trié celles qui contenait du parsing des messages réseau NEGOEXTS. Après avoir identifié la bonne fonciton, l’oratrice y à découvert un memcpy qui prennait les valeurs du paquet pour un calcul de tailles. En contrôlant l’exploitabilité de ce memcpy, l’oratrice à découvert un double-fetch qui potentiellement service de LPE, mais difficilement exploitable en remote SAUF si on peut lui adjoindre un second bug. En regardant de près, il n’y a pas de vérification sur la taille minimale du paquet. Du coup en utilisant la taille lors du check des limites mémoire de copie qui est différent de celui du parsing du packet on peut faire du heap grooming et préparer le tas pour rendre exploitable le double-fetch.

Client Side desinc attack on werkzeug to perform XSS

Une CSD c’est lorsqu’on à un reverse-proxy entre le navigateur et le serveur applicatif, et que les connexions restent ouvertent. Cela permet par exemple de faire fuiter des headers HTTP. L’orateur voulait donc voir comment transformer une CSD en une XSS sur le framework Werkzeug.

Détournement de pile protocolaire ESP32

Romain Cayre & Damien Cauquil. L’ESP32 est un chip embarqué wifi/ble et très répandu dans l’IoT. Il est soit basé sur du Tensilica XTensa ou du Risk-V. Les orateurs se sont demandé s’ils pouvait sniffer ou injecter du BLE avec un ESP32, ou détourner la couche physique, voir interragir avec d’autres proto. Bref comment transformer un ESP32 en plateforme d’attaque à pas cher.

En regardant les peripherals, pas moyen de trouver le contrôleur BLE. Par reverse-engineering ils ont retrouver la puce BLE, un SOC Dialog DA14681. Dans la doc il y a 2 pages mémoire de Rom qu’ils ont dumpé. Elle contiennent du code de la stack BLE. Le système utilise un tableau de pointeurs en RAM. Du coup en jouant avec certaines de ces fonctions, l’orateur à mis au point un outil d’injection de paquets BLE.

Pour aller plus loin, les orateurs se sont attaqué à la couche physique au travers de la puce. Pour cela les orateurs jouent sur les fonctionnalités de la puce, et la modulation de patterns particuliers pour faire des attaques inter-protocoles. (cf talk wazabee SSTIC).

En contrôlant le modulateur et en détournant le mécanisme de synchronisation de l’access address. Pour récupérer les paquets, les orateurs désactivent la vérification des paquets en programmant un pattern laxiste. Pour contrôler les échanges, les orateurs font du packet into packet.

En jouant avec les fonctions bas niveau de la puce, les orateurs ont trouvé un moyen d’émettre des ondes arbitraires, transformant l’ESP32 en SDR BLE du pauvre. Ils peuvent ainsi le faire baver et brouiller signaux. A quand la SDR a base d’ESP32 ?

Your Mind is Mine: how to automatically steal DL models from Android apps.

Les poids de réseaux de neurones constituent les résultats des apprentissages sur grosses cartes graphiques et autre gros clusters. Une fois ce modèle créé, on peut l’envoyer dans un appareil plus léger. Cela réduit la latence, de connectivité, les coûts, et résoud les problèmes de confidentialités des donnés traités par ces modèles. La création d’un modèle entrainé, ça coute très cher, et nécessite beaucoup d’investissement.

Mais comme ces poids sont projettés dans le modèle, on peut procéder à sa rétro-conception. Les orateurs ont créé un outil de détection et de recherche de modèle ML dans une application Android.

Pour se faire, les orateurs identifient le framework de ml utilisé, du genre TensorFlow/TensorFlow Light, ou des frameworks propriétaires avec des structures & mots clefs particuliers.

Une fois tout ça analysé, on se rend compte que les modèles sont de plus en plus ré-utilisés, soit parce qu’ils s’agit de solutions open-sources, soit parce qu’ils sont issue de fournisseurs de modèles. On retrouve ces modèles dans les applis photos, mais aussi dans des applis financières ou bancaires pour reconnaitre des cartes d’identités ou d’autres trucs sensibles.

Certaines applis chargent le modèle dynamiquement, et le déchiffrent à la volée. Du coup pour récupérer le modèle parfois, il faut hooker l’appli pour récupérer le modèle en clair. Pour ça les orateurs ont utilisé FRIDA.RE. L’outil d’extraction est disponible sur GitHub.

Attaques possibles: l’inversion de modèle qui permet de récupérer les données ayant servi à entrainer le modèle.

Etude critique d’une méthode de ML appliqué à l’analyse par canaux auxiliaires.

Les attaques par canaux auxiliaires vont s’attaquer aux fuites d’info physique produites par les implémentations crypto. Souvent les attaques par canaux auxiliaires sont vu comme un problème d’étiquettage de traces d’exécution. Dans la vraie vie, on a parfois des traces qui sont mal étiquettés. L’IFSCA est un framework de deep learning chargé de bien ranger les traces mal classifiés.

Les statistiques de résultats de l’article semblait trop bonnes pour être vrai. Du coup les orateurs ont reproduit les expérimentations, puis ont découvert qu’il y avait de l’overfitting du à la trop grande taille du modèle de réseau de neurones. Ils ont donc remplacé leur modèle par un perceptron à 1 neurone. Le jeu de donnée était trop simple, et donc biaisé.

Challenge SSTIC 2023

Cette année c’est Ledger qui à fait le challenge. L’objectif c’était de permettre aux participants d’interragir avec des technologies originales. Certaines étapes était accessibles en parallèle, mais nécessaires pour résoudre l’avant-dernière étape. Les concepteurs ont estimé le nombre de participants avec le chargement de l’image du lobster dog. Au final seul 25 personnes ont terminé le challenge.

Quelques fails: un solver Z3 a défoncé le labyrinthe. L’étape 3 résolue mais pas validable. l’étape 2c a été résolue de façon innatendue suite à une vuln dans la crypto.

Solution du challenge SSTIC

L’étape 0 se fait à partir d’une url, quand on modifie l’url on récupère un formulaire d’upload, avec dans les en-têtes HTTP on a la version exacte d’imagemagick. Cette dernière est vulnérable à un information disclosure/LFI lors d’un redimentionnement d’un PNG. Le step 2a c’est de la crypto sur la signature de Schnorr. Le step 2b c’est un script python qui fait des opération d’électronique numérque sur des portes logiques. C’est l’implem python d’un porte-monnaire électronique. on met tout dans Z3, et paf ça casse le challenge. Si on reverse la fonction ça dessine un labyrinthe, et la clefs est issue de la résolution du labyrinthe.

Le chall 2c comprend un binaire à exploiter avec une libc spécifique sur du arm64. Le service accepte des commandes d’ajout, de vule, de chiffrement & déchiffrement et de signature. La gestion des exceptions est faite avec des setjmp et longjmp. Avec la gestion des exceptions, ya moyen de faire sauter les limitations de l’application en levant les exceptions. On incrémente ainsi un compteur qui va overflow et permettre de corrompre les valeurs des registres er reprendre le controle du flot d’execution. Une fois la RCE exploitée, on se retrouve avec un shell dans un système avec un service qui tourne avec un 2eme utilisateur. Il y a une format string dans le 2ème service, mais si on le voit pas comme l’orateur, c’est plus dur. les fonctions encrypt et decrypt ont un bug de logique, et le type de l’entrée n’est pas vérifié, ce qui permet de sonder l’espace mémoire.

Le challenge 2d est une analyse side-channel. Le reste sur le site du SSTIC.