SSTIC 2020 - J2

• « Hey mais, il manque des prez dans ton liveblogging »
• « Waip, mais la bonne nouvelle c’est que je les ajouterais quand j’aurais l’temps »
• « mais c’est plus un liveblogging »
• ¯\_(ツ)_/¯

(Merci a kyzdra qui m’a remplacé à l’arach vous évitant de prendre des notes 😉 )

Android Emuroot: Outils de rooting d’un émulateur Android Google API PlayStore

L’analyse d’application Android se repose souvent sur l’utilisation d’émulateurs. Pour pouvoir installer ses outils d’analyse, il faut pouvoir souvent être root sur le terminal. L’émulateur « google play store » permettant d’installer des applications du playstore google ne fournit pas d’accès shell root. En prime, il faut rester discret pour éviter de se faire détecter par les outils « anti-root » qui protègerait éventuellement l’application.

L’outil Emuroot permet donc d’élever les privilèges du processus de son choix. Dans le noyau android, chaque processus est associé à une structure contenant ses credentials avec ses droits SELinux associés. En utilisant le debug GDB de Qemu, on va pouvoir modifier cette structure et élever les privilèges du processus cible. Pour faciliter la recherche du processus, on va lui mettre un nom aisément repérable.

C’est open-source et disponible sur github

Dexcalibur : Hook it yourself !

Dexcalibur est un outil de désobfucation et d’analyse dynamique de code Java basé sur Frida. Ainsi il permet de s’attaquer aux problématiques des exécution dynamiques de code Java.

Petite démo en direct des capacités de l’outil en terme de hook Java. Interface qui m’a l’air très user friendly !!!

Comment ça marche ? Dexcalibur va enrôler un device, faire une analyse statique du framework Android et de l’application. Une représentation de l’application (fichiers, classes) est effectuée via l’analyse de l’APK. Une base de donnée est construite avec des hooks et seront déployés automatiquement à la prochaine installation de l’application.

Les graphiques de la présentations sont plus parlants, concernant l’enchaînement des appels de fonctions.

How to design a baseband debugger

Cible : baseband d’un Samsung Galaxy S7.

Le baseband « Shannon » est un OS temps réel pour les problématiques de communication. La structure des tâches est la suivante :

• toutes la même structure
• boucles while attendant des messages
• communication entre les tâches par des messages

Les communications sont effectuées soit via mémoire partagée, soit par mailboxes (il y en a 20 sur le Galaxy S7). Le protocole SIPC5 est le protocole de comm entre le baseband et le kernel Linux. Le kernel se charge de dispatcher les informations à la partie userland.

Les orateurs décrivent la séquence de boot, et là c’est compliqué sans schéma… Mais en gros le code du baseband est copié à différents endroits durant cette séquence.

Une vulnérabilité est disponible pour injecter le debugger dans le device :

• un buffer overflow dans le driver sécurisé
• une ROP chain est donc initialisée à partir de là
• le noyau du TEE ne s’exclut pas lui même des zones à être autorisée à être mappé, il pourra donc être patché
• Avec ce patch on s’assure que le driver peut mapper n’importe quoi, que la vérification de la signature est désactivée, et que la mémoire ou est chargée le baseband est considérée comme sécurisée

Petite démonstration des capacités du debugger :

• Renommer une fonction
• Activer les logs
• Injection d’un modem spécifique, permettant de s’attacher à une base station particulière et de voir les échanges

Exploiting dummy codes in Elliptic Curve Cryptography implementations

(argh de la crypto) L’orateur nous rappelle le fonctionnement des courbes elliptiques et leurs propriétés mathématiques permettant de faire de la crypto avec (T.T). En courbes elliptiques, on peut faire des calculs en temps constant (merci à l’orateur pour la précision 😉 ) en utilisant des « fausses » additions, mais cette opération introduit une vulnérabilité aux injections de fautes.

En récupérant les résultats des additions issues des injections de fautes sur la fin de l’addition, on récupère des bouts d’informations de la clef. L’outil vérifie les signatures valides issues de l’injection de faute et fait de la cryptomagie (LLL me souffle l’orateur) pour reconstituer la clef. (L’outil est sur GitHub)

L’orateur nous explique ensuite les bases théoriques qui font que ça fonctionne. Il existe des contre-mesures programmatiques à mettre dans l’implémentation pour se prémunir contre ces vulnérabilités, ou alors il vaut mieux utiliser des libs adaptés à l’IoT et capable de se protéger contre les attaques en faute.

Testing for Weak Key Management in Bluetooth Low Energy Implementations

En BLE on utilise de la cryptographie pour se protéger contre des attaquants passifs qui écoutent les messages entre les équipements, et les attaquants actifs qui viennent rejouer des échanges, etc… Le standard BLE repose sur tout plein de clefs crypto pour assurer les propriétés de sécurité des échanges entre les devices. Le standard a évolué avec des versions successives.

Dans le Bluetooth, on fait d’abord un appairage, et la sécurité de la clef est essentielle en BLE car le protocole repose sur de la cryptographie symétrique. Du coup, si la clef est trouvée par un attaquant, c’est perdu.

Une fois l’appairage fait, les devices vont pouvoir établir un lien de communication appellé bonding avec des clefs crypto négociées pour l’échange. Il y a eu beaucoup de travaux et de vulnérabilités découvertes sur le Legacy pairing et le LE Secure Pairing.

ECDH c’est un échange de clef diffie-hellman sur courbe elliptique. Il est possible d’effectuer une attaque par échanges ECDH répétés permettant d’extraire la clef privée du serveur, il est donc recommandé de la changer régulièrement, et de vérifier la clef publique dans l’échange. Du coup en fonction des devices, si ce dernier ne vérifie pas la clef publique ou garde trop longtemps la clef privée, on peut mener une attaque et récupérer la clef privée. (cf actes)

Les orateurs ont mis au point un protocole de test pour vérifier qu’un device est vulnérable ou non. Comme BLE utilise une hiérarchie de clefs, si l’équipement fait du Legacy Pairing on peut énumérer toutes les clefs possibles sans avoir assisté à l’appairage. (bye bye la confidentialité… mieux vaut éviter de taper un mot de passe sur un clavier BLE).

Le respect de la spécification BLE est essentiel pour que le device soit sûr. Même en boite noire il est possible de tester un équipement et de s’assurer de sa sécurité face à ces attaques.

Les aleas d’un ransomware

Un attaquant employant un ransomware va tenter de chiffrer un maximum de fichiers de valeurs, dont des fichiers métier employés par des applications esssentielles au fonctionnement de l’entreprise. Pour chiffrer, le ransomware utilise un algo cryptographique assez solide, RC4 dans le cadre de l’exemple. Cependant la clef privée qui est générée par le ransomware doit utiliser une source d’aléa, qui parfois s’avère pas si aléatoire que ça.

A partir de la source de pseudo-aléa et de l’algorithme de génération de la clefs, on peut tenter de re-générer la clef pour déchiffrer le fichier. Pour s’assurer qu’il s’agisse de la bonne clef, il faut s’assurer que le fichier s’est bien déchiffré. On peut se baser sur les magic des fichiers, mais ça demande une grosse exhaustivité, l’autre approche c’est de mesurer l’entropie du fichier déchiffré.

Pour optimiser le bruteforce, on va restreindre l’espace de recherche du Tick servant à générer la clef, le nombre de fichiers à tester, et le nombre de clefs à tester. Le bruteforceur est codé en C avec OpenMP pour exploiter tous les threads du CPU. Ce binaire est piloté par un script qui « optimise » l’exploration de l’espace de recherche.

Dans la plupart des ransomware cependant, il n’y a pas de vulnérabilités cryptographique, et la seule protection reste les backup gardés hors-ligne.

Fuzz and Profit with WHVP

Cette présentation s’attarde sur le fuzzing Kernel Windows avec l’API WHVP (Windows Hypervisor Platform) :

• simpleator qui permet de sandboxer un binaire en userland
• applepie qui permet d’utiliser Hyper-V dans bocs comme accélérateur

L’auteur a voulu découvrir cette API et à donc réalisé son propre fuzzer :

• 1er problème : Le CPU virtuel démarre en mode 16 bits, les instructions sont données pour passer en mode 64 bits
• 2ème problème : La partition manipule des Guest Physical Address. Via une API on arrive par translation à récupérer la GVA correspondant à la GPA demandée initialement (voir présentation).
• 3ème problème : On veut exécuter une fonction spécifique (et non exécuter tout le noyau). Il faut donc définir l’adresse de retour qui est dans la pile, et définir les autres adresses grâce au débogueur à la création du snapshot. Et il suffit de définir des points d’arrêts logiciels au moment ou on mappe la mémoire dans la partition.
• 4ème problème, la couverture de code : on active le trapflag pour passer en mode single step (mais trop lent en direct). Mais ce qui nous intéresse ce sont les nouvelles instructions exécutées. La solution est de mapper les pages de code avec des interruptions.

Petite démo en live du fuzzer obtenu, mais j’avoue que je n’ai pas vu grand chose sur mon petit écran.

afl-taenia-mt : fuzzing en mémoire pour des cibles multi-threadées et en boite noire

Une présentation sur le fuzzing sous Linux, cette fois-ci. Un bon fuzzer est rapide, malin et honnête. Le problème de afl, c’est que le code n’est plus maintenu. afl++ est donc une version améliorée de afl. afl++ utilise des sondes dans qemu pour réaliser son fuzzing. Pour répondre aux limitations d’afl une nouvelle approche est effectuée : le fuzzing en mémoire et sans redémarrage.

C’est là qu’intervient afl-taenia-mt :

• libtaenia : suivi de bibliothèques
• suivi de processus, et script pour redémarrer l’environnement complet
• suivi de thread (mais des problématiques avec le multi thread, et la couverture de code est problématique). Les sondes ont donc été redéveloppées.

Les principes sont survolés il va falloir se référer aux slides pour aller plus loin. Le code est présent sur GitHub.

Présentation des résultats du challenge

Conception du challenge :

1. Utilisation de Matrix/Riot comme plateforme, pour essayer d’organiser un peu plus le challenge SSTIC.
2. Epreuve Crackme, pour bruteforcer un programme en Rust
3. Epreuve sous IE5/Windows 98. Une clé de chiffrement est obenue Hash Echo
4. Utilisation d’une PSOne pour déverrouiller un KeePass.
5. Challenge Ethereum avec du reverse sur un binaire et une résolution mathématique (assez chaud et donc pas mal d’aide dans le code)

L’organisation du challenge a été parfaite vu que 3 mois avant tout était prêt. La génération de l’archive finale a été lancé 2 jours avant le début de l’épreuve.

Solution de Pierre Bienaimé (il y aura certainement des raccourcis dans ce liveblogging, le PDF de la solution).

• Utilisation de Volatility pour explorer le contenu de la RAM en reproduisant la machine cible. On arrive à donc récupérer le script d’une sauvegarde qui normalement doit être supprimé mais la commande n’est pas effectuée. Et donc il est possible de récupérer et de déchiffrer ce fameux fichier.
• Restauration d’une instance d’un serveur Matrix/Riot. On change tous les mots de passe de toutes les personnes connues de l’instance Matrix/Riot. On accède donc aux conversations privées de chaque personne et on passe au niveau supérieur.
• Le profiling est la première étape pour essayer de bruteforcer le programme Rust. Le programme a donc été patché pour aller plus vite pour la vérification des mots de passe.
• Compromission via une page internet, il faut donc récupérer le code vbscript. Il faut passer par la désobfuscation de code. Et via un recodage en python, on remarque que le chiffrement utilisé c’est du RC4. L’exfiltration des données à été effectuée de manière chiffrée via COCONUT98. A partir le là il y a des maths et c’est plutôt chaud pour déchiffrer COCONUT98.
• Le fichier KeePass attend une entrée sur port série pour le déverrouiller. Le fichier ISO est un jeu PS. La PS est connectée sur le port série, l’utilisateur doit saisir des boutons sur sa manette et la PS envoie le secret pour déverrouiller le KeePass. Via l’émulateur Ghidra, il est facile de générer tous les mots de passe possibles, et via un patch sur KeePass de les essayer tous, pour passer au niveau suivant.
• Utilisation d’un outil en ligne pour décompiler le contrat Ethereum. Le but c’est de se débarrasser de la blockchain et de récupérer les transactions. Avec la clé récupérée on accède à un nouveau salon ou les personnes ne parlent qu’avec des émojis. A partir de là on peut récupérer l’adresse mail, sur laquelle il faut envoyer un message.

Une solution vraiment claire et bien expliquée, bravo !!!