5 juin 2020

Retours sur le SSTIC – 18e édition « OnLine » – Jour 2

SSTIC

Cette année, BSSI est virtuellement présent à la 18e édition. Le premier jour était déjà grandiose mais le deuxième était tout aussi bien avec, en plus des conférences, la présentation du challenge ainsi que les rumps.

Vous souhaitez plus d’informations ? C’est par ici :

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

Par Anaïs Gantet, Mouad Abouhali

La première présentation de cette deuxième journée au SSTIC online a permis à Anaïs et Mouad de présenter l’outil Android_Emurrot, permettant de rooter un émulateur Android afin d’obtenir un environnement de travail idéal.

Avant de rentrer dans le vif du sujet, une parenthèse est faite entre les deux types d’émulateurs :

  • Google API
  • Google API PlayStore

Comme son nom le laisse penser, Google API PlayStore (bien que moins connu et moins utilisé) propose un Google PlayStore (se rapproche d’un périphérique physique). Néanmoins, cette fonctionnalité en plus est rattrapée par l’impossibilité de passer root sur ce type d’émulateur.

Pour l’utilisation d’Android Emuroot, la partie importante est la spécification des options « -qemu –s » permettant d’activer le mode GDB du serveur QEMU de l’émulateur.

Une image contenant capture d’écran, assis, portable, noir

Description générée automatiquement

Mais ce n’est pas tout, comme le spécifie Anaïs, rien n’est magique et voilà comme cela fonctionne.

Android Emuroot va ainsi manipuler la mémoire du système d’exploitation Android (Linux) afin de chercher la structure task_struct associée au shell lancé, écraser la valeur de la structure creds et optionnellement désactiver SELinux.

L’étape de reverse est nécessaire pour supporter une nouvelle version d’Android. En effet, c’est cette dernière qui permettra d’obtenir les adresses mémoires des structures telles que creds ainsi que les adresses de configuration de SELinux.

Une image contenant capture d’écran

Description générée automatiquement

À l’heure actuelle, les versions supportées sont Android 7.0, 7.1, 8.0 ou encore 8.1.

Wombat: one more Bleichenbacher attack toolkit+

Par Aina Toky Rasoamanana, Olivier Levillain

Aina Toky Rasoamanana, Ingénieur en Cryptographie chez Télécom SudParis a commencé la présentation avec un rappel sur RSA et sur l’attaque de Bleichenbacher.

En effet, RSA est un algorithme vieux de 40 ans, qui est encore largement utilisé aujourd’hui. Le standard qui décrit son utilisation en pratique est PKCS#1. La version 1.5 de ce standard, qui commence à dater, est encore présente dans de nombreux standards (par exemple TLS, jusqu’à sa version 1.2).

Cependant, comme en témoignent des publications régulières ces dernières années, de nombreuses implémentations de PKCS#1 v1.5 sont vulnérables à une attaque décrite par Daniel Bleichenbacher en 1998.

Afin d’expliquer cette attaque, Aina Toky Rasoamanana a étudié le padding de type 2 (PKCS#1 v1.5), utilisé pour le chiffrement :

Le principe de l’attaque Bleichenbacher (CRYPTO 1998) :

Afin de pouvoir évaluer la présence d’oracles de Bleichenbacher dans les implémentations de divers protocoles, Olivier Levillain, Maître de conférences en sécurité des systèmes d’information chez Télécom SudParis a présenté un outil qu’il ont développé.

Il s’agit de Wombat (one more Bleichenbacher toolkit), un outil modulaire permettant d’identifier les implémentations vulnérables et en cas de besoin valider la faisabilité de l’attaque.

Wombat permet de tester des implémentations TLS et des challenges de type rootme. Olivier a mentionné que des travaux sont en cours autour de XML Encryption et OpenPGP.

Dans ce contexte, une démonstration a été présentée afin d’illustrer l’attaque sur un serveur vulnérable :

Pour plus d’information :

Les aléas d’un ransomware

Par Yoann Guillot (ANSSI)

Dans cette présentation, Yoann Guillot a partagé la méthodologie que l’ANSSI a suivie pour déchiffrer des fichiers suite à une attaque de type ransomware.

Ici, le malware liste tous les disques auxquels le poste accède et parcours les dossiers et sous-dossiers afin de lister les fichiers. Si les fichiers n’ont pas une extension qui est blacklistée alors ils sont chiffrés.

Le chiffrement se déroule en deux étapes :

  • La génération « aléatoire » d’une clé de 117 octets
  • Le chiffrement du fichier en utilisant la clé générée et l’algorithme RC4

La fonction de génération aléatoire de clé se base sur les ticks. Un tick est le nombre de millisecondes depuis le boot du poste, sa valeur est codée sur 32 bits.

Plusieurs cas de figure peuvent être rencontrés, mais les deux principaux sont :

  • Une ou plusieurs clés sont générées lors d’un unique tick
  • Les premiers octets de la clé sont générés sur un tick puis les octets suivants sur celui d’après

De façon générale, l’identification des fichiers déchiffrés est réalisée par un calcul d’entropie du header. Cette méthode n’étant pas adaptée aux petits fichiers, un algorithme différent est utilisé sur ceux-ci, considérant un fichier contenant uniquement de l’ASCII comme déchiffré. Pour les fichiers à forte entropie, une augmentation du seuil d’entropie est réalisée en se basant sur l’extension du fichier.

Le chiffrement des fichiers par le ransomware ne durant généralement que quelques heures, il suffit de trouver la valeur d’un tick utilisé puis d’élargir aux ticks environnants afin de réduire grandement l’aléa.

L’ANSSI a procédé à deux opérations de déchiffrement, la première a conduit au déchiffrement de 95,3% des 16849 fichiers chiffrés, la seconde au déchiffrement de 89,5% des 231513 fichiers chiffrés.

L’article complet est disponible sur : https://www.sstic.org/media/SSTIC2020/SSTIC-actes/aleas_ransomware/SSTIC2020-Article-aleas_ransomware-guillot.pdf

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *