SSTIC 2022 : Jour 2, 2 Juin

SSTIC 2022 : Jour 2, 2 Juin

Après la première journée, voici trois conférences ayant attirées notre attention le second jour de cette édition 2022 du STTIC. Cette journée s’est finie lors d’un mémorable social event au couvent des Jacobins.

DroidGuard – Romain Thomas – @rh0main

Les applications mobiles sensibles (secteur bancaire, éditeur de jeux) cherchent à savoir si elles s’exécutent sur un téléphone compromis.

Google propose aux développeurs Android une API SafetyNet, simple d’utilisation et efficace si bien utilisée. Elle renvoie principalement deux booléens pour les développeurs: basicIntegrity et ctsProfileMatch.

Alors que les vérifications pour la valeur basicIntegrity sont légères, celles pour la valeur ctsProfileMatch sont plus poussées, avec des vérifications hardware. Elles répondent par exemple aux questions suivantes :

  • Est-ce que l’appareil passe les tests de compatibilité CTS de Google ?
  • Est-ce que le téléphone utilise une ROM custom ?
  • Est-ce que le bootloader est déverrouillé ?
  • Est-ce que le téléphone est certifié par Google ?

SafetyNet se repose sur un composant obscur nommé DroidGuard, sur lequel l’auteur s’est penché. DroidGuard est un petit paquet Android présent sur chaque téléphone. Ce composant est difficile à reverse puisqu’il est obfusqué, mis à jour toutes les deux semaines, qu’une grande partie du code est natif (JNI) et que de nombreuses protections sont employées (anti-hook, anti-debug, pas de cha卯nes de caractères auxquelles se raccrocher, etc.). DroidGuard est en fait une mini-VM qui exécute du bytecode reçu depuis les serveurs de Google. DroidGuard réalise en fait une collecte d’informations ciblées sur le téléphone pour générer un token DroidGuardResult. Ce token est envoyé aux serveurs Google. La décision finale sur l’intégrité du téléphone est donc laissée aux serveurs de Google.

La logique de l’APK est dans sa librairie libdroidguard.so. Elle est codée en C++ et utilise 256 registres typés. Les valeurs manipulées par les registres de la VM sont encodées: un chercheur voulant les afficher ne verrait pas les vraies valeurs manipulées. L’intégrité du bytecode est également vérifiée par la VM et de nombreuses autres protections y sont intégrées.

Gr芒ce à ses recherches, Romain Thomas est parvenu à obtenir une valeur de basicIntegrity à true 馃檪 !

Malheureusement, l’API SafetyNet va bientôt être remplacée par la Play Integrity API (Plus d’informations ici) courant 2024, apportant de nouveaux challenges !

An Apple a Day Keeps the Exploiter Away – Eloi Benoist-Vanderbeken (@elvanderb) et Fabien Perigaud (@0xf4b)

Cette présentation de Synacktiv d’Eloi Benoist-Vanderbeken (@elvanderb) et de Fabien Perigaud (@0xf4b) est la suite logique d’une présentation réalisée au SSTIC en 2019, WEN ETA JB? A 2 million dollars problem.

Les deux auteurs commentaient alors les difficultés qu’un chercheur pouvait rencontrer il y a 3 ans en s’attaquant à la plateforme iOS. Le constat émis par les équipes de Synacktiv était qu’Apple avait commencé à mettre en place de nombreuses mesures de sécurité pour empêcher les exploits d’aboutir ou ralentir les chercheurs: les connaissances attendues sont toujours plus grandes.

Depuis cette présentation, iOS a bien s没r évolué et apporte de nouveaux challenges. L’objectif de la présentation est de faire un nouveau panorama des mesures employées par Apple pour renforcer la sécurité de ses systèmes.

La technologie à nouveau sous les feux des projecteurs est PAC (plus de détails dans ce blog post de Google Project Zero en 2019 ici). Via des instructions ARM, il est possible de savoir si un attaquant a modifié un pointeur et ainsi empêcher les techniques de ROP.

Apple a misé sur cette technologie et contribue à la renforcer toujours plus. Ainsi, on retrouve dans les dernières versions d’iOS :

  • Toujours plus de pointeurs signés ;
  • Des pointeurs avec un contexte nul presque introuvables ;
  • Un bruteforce bien plus long, avec 24 bits de signature ;
  • Des clés PAC qui dépendent d’un TeamID, qui est un identifiant unique attaché à un développeur Apple. Ces clés sont donc dédiées à un processus : s’attaquer à un autre processus est maintenant complexe ;
  • Un kernel qui met fin à un processus dès qu’une exception PAC est levée.

Après une première protection difficile à contourner, PAC, une autre se dresse devant les chercheurs: PPL ou Page Protection Layer. Même en ayant la possibilité de lire et écrire dans le kernel et contourner PAC, PPL empêche la modification de pages arbitraires. Or, les profiles et entitlements d’iOS sont protégés par PPL. D’anciennes techniques telles que le hook d’amfid (Apple Mobile File Intergrity Daemon), daemon qui vérifie l’intégrité des fichiers s’exécutant sur le système, ne fonctionnent à présent plus.

Apple a verrouillé des zones mémoires sensibles en lecture seule (RO) et les a protégées par PPL. Il n’est plus possible de modifier l’uid d’un processus pour devenir root.

Apple a également renforcé ses protections côté kernel, en ajoutant des vérifications dans ses allocations par zones. Une adresse doit à présent appartenir à la bonne zone et une zone ne peut pas être réutilisée après un passage du garbage collector. Tout ceci met à mal les vulnérabilités de type use-after-free dans le kernel.

Du côté de WebKit, Apple a cherché à réduire la surface d’attaque. La sandbox est à présent très restreinte: il ne reste que 4 services userland atteignables, et les syscalls sont filtrés. Que d’aventures !

Enfin, notons qu’Apple surveille de près les exploits publiés et corrige les portes d’entrée employées par ceux-ci. Il n’y a pour l’instant pas de jailbreak disponible pour iOS 15 et cette présentation n’a montré qu’une partie des méthodes employées par Apple pour empêcher la compromission d’un iPhone.

N’hésitez pas à en découvrir plus sur les actes du SSTIC disponibles ici, ou sur les articles de blog Synaktiv liés à IOS disponibles ici.

Practical timing and SEMA on embedded OpenSSL鈥檚 ECDSA

Adrian Thillard est expert en sécurité matérielle à Ledger. Au sein de cette conférence, il va présenter différents scénarios d’attaques par canaux auxiliaires sur l’implémentation de l’algorithme de signature ECDSA par la bibliothèque logicielle OpenSSL. Ces attaques ont été réalisées par Julien Eynard, Guena毛l Renault, Franck Rondepierre et Adrian Thillard.

Les canaux auxiliaires regroupent des attaques utilisant des mesures telles que le temps d’exécution ou la consommation électrique afin d’en extraire des informations (clé de signature par exemple).

Les auteurs de cette conférence se basent sur les travaux liés à l鈥檃ttaque 芦聽Minerva聽禄 qui cible l’algorithme de signature ECDSA. Cette attaque réalise une attaque par timing sur l’algorithme, c’est-à-dire que la mesure du temps d’exécution d’un nombre important d’opérations de signature permet d’obtenir des informations, telles que la clé ayant permis de réaliser la signature.

Afin de réaliser la signature, un nombre aléatoire k est choisi entre 1 en n-1 (n étant un paramètre dépendant de la courbe elliptique choisie). En effet, l’algorithme ECDSA réalise une 芦聽grosse boucle聽禄 sur chaque bit du nombre k. Ainsi, plus k est grand, plus le nombre de tours de boucle est important, donc plus le temps d’exécution augmente. En mesurant cette information, il est possible d’obtenir des informations sur le nombre de bits dans k.

Ensuite, l’algorithme LLL, non présenté durant cette conférence, et en réalisant un grand nombre de mesures, permet d’obtenir des informations sur la clé à partir du nombre de bits dans k.

Les auteurs de cette conférence se sont interrogés si l’implémentation d’OpenSSL se prémunissait contre ce type d’attaques. En effet, au sein du modèle de menace d’OpenSSL, une grande partie des attaques par canaux auxiliaires ont ainsi été écartées il y a quelques années. Seules les attaques par mesure de temps visibles depuis un appareil extérieur ont été conservées au sein du modèle de menace. Les attaques ne rentrant pas dans ce modèle de menace ne se verront ainsi pas l’attribution de CVE.

Les auteurs se sont ainsi interrogés si OpenSSL proposait une bonne sécurité sur les attaques par canaux auxiliaires. En analysant le code source d’OpenSSL, les auteurs ont identifié des contre-mesures implémentées. Par exemple, afin de mitiger l’attaque Minerva, OpenSSL tire un nombre aléatoire k’ beaucoup plus grand que le nombre aléatoire réel k. L’attaquant obtient alors des informations sur le nombre k’ qui ne lui permet pas d’obtenir des informations sur la clé.

Les auteurs se sont ensuite intéressés sur opérations réalisées par OpenSSL autre que la boucle sur le nombre k. En particulier, une fonction réalisant une multiplication modulaire a été identifiée comme pouvant être exploitée par une attaque par canaux auxiliaires. En effet, au début de cette fonction, une comparaison vérifie que le nombre de mots sur lequel est codé le nombre n est égal au nombre de mots sur lequel est codé le nombre aléatoire k. Le nombre de mots correspond aux nombres d’octets non vides, par exemple, le nombre 00000000_AB321623_A8299773_37281902 a un nombre de mots égal à 3.

Ainsi, selon la taille du nombre aléatoire, une partie de code optimisé en assembleur ou non est exécutée. Les auteurs se sont ainsi interrogés sur la manière d’exploiter cette fonction. Une idée a été de choisir un nombre d’entrées n commençant par 00000001. Ainsi, en tirant des nombres aléatoires k, il y aura une chance sur deux environ d’obtenir un nombre k commençant par 00000001 ou 00000000, donc d’obtenir un nombre de mots différents pour k et n. Ainsi, les nombres k commençant par 00000001 prendront le chemin d’exécution le plus rapide, tandis que les nombres k commençant par 00000000 prendront le chemin d’exécution long. EN mesurant le temps d’exécution de cette fonction, il est possible de déterminer des informations sur les nombres k et ainsi retrouver des informations sur la clé.

Les courbes suivantes ont été déterminées comme pouvant présenter un défaut permettant d’exploiter cette attaque:

  • secp521r1
  • sect131r1
  • sect131r2
  • sect163k1
  • sect163r1
  • sect233k1
  • sect233r1
  • sect409k1
  • c2pnb208w1
  • c2pnb272w1
  • c2pnb304w1
  • c2tnb431r1
  • wap-wsg-id-ecid-wtls1
  • wap-wsg-idm-ecie-wtls3
  • wap-wsg-idm-ecie-wtls5
  • wap-wsg-idm-ecie-wtls10
  • wap-wsg-idm-ecie-wtls11

Les auteurs concluent cette analyse en indiquant qu’il existe donc des scénarios attaques théoriques.

Les auteurs ont ainsi tenté de réaliser cette attaque en pratique. Pour cela, ils ont utilisé un Raspberry Pi 4 sur lequel était exécuté OpenSSl 1.1.1k, en prenant un nombre n de 257 bits.

Les résultats de ces mesures on permis de mettre en évidence une mesure du temps beaucoup plus faible pour les cas o霉 le nombre de mots de k est égal au nombre de mots de n. Cependant, la mesure est réalisée uniquement sur la fonction identifiée. Une seconde mesure a été réalisée sur la fonction parente dans le graphe d’appel afin de vérifier si cette différence de mesure était également présente. Cette différence ne se retrouve pas au sein de la fonction parente. En effet, la différence de cycles au sein de la première fonction étudiée était de l鈥檕rdre de 80 cycles, tandis que le nombre de cycles au sein de la fonction parente est de l’ordre de 40 000 cycles, rendant négligeables les 80 cycles mesurés précédemment.

Les auteurs ont ensuite réalisé une attaque en effectuant des mesures électromagnétiques (en dehors du modèle de menace d’OpenSSL). Une différence a été identifiée au sein des mesures, en raison de chemins différents au sein du code. Cette différence permet de mesurer la longueur du nombre aléatoire k, et ainsi de remonter à la clé n.

Les auteurs proposent des changements afin de se prémunir contre ces attaques. Par exemple, en forçant les nombres à être codés sur le maximum de bits (changement appliqué sur le fork BoringSSL).

En conclusion, les auteurs estiment que les attaques par timing peuvent être réalisées dans certains contextes (si l’attaquant peut clairement identifier les débuts et fins de la fonction identifiée). Cependant, il est difficile de réaliser la mesure de différence de cycle dans le cas général, étant donné que cette différence de cycle est confondue avec le bruit présent dans le reste du code. D’autre part, les auteurs indiquent que même si un problème de timing ont été identifiés en local, mais que ceux-ci ne sont pas visibles en remontant dans l’arbre des fonctions, il est toujours possible pour un attaquant ayant davantage de capacités, de trouver un moyen d’exploiter ce problème (sonde de mesure des émanations électromagnétiques ou de consommations par exemple). Les auteurs insistent également sur le fait d’analyser les modèles de menaces des bibliothèques pouvant être utilisés au sein de systèmes embarqués afin de s’assurer que celui-ci couvre l’ensemble des menaces identifiées.


Simon