CVE-2020-0022

Un grand merci à Insinuator pour leur excellent article de blog et code!

Résultats

Toutes les étapes mentionnées dans l'article d'Insinuator ont été réalisées, et même plus. Ce sont beaucoup d'étapes à mettre dans un fichier README.md, alors n'hésitez pas à consulter l'article d'Insinuator mentionné ci-dessus.

L'exploit est entièrement complet jusqu'au point où :

1. L'adresse d'une zone mémoire suffisamment grande contrôlée par l'attaquant est divulguée
2. Le compteur de programme est modifié pour pointer vers une adresse personnalisée
3. Des tentatives sont effectuées automatiquement jusqu'au point où les chances d'échec diminuent considérablement
4. Le code est optimisé en termes de temps de déconnexion et de vitesse de recherche mémoire, au point où une optimisation supplémentaire compromet la stabilité de l'exploit

Différences et améliorations

Cet exploit diffère de l'implémentation d'Insinuator de les manières suivantes :

1. Il est écrit en C plutôt qu'en Python (parce que j'adore le C)
2. Il est écrit de manière modulaire, où chaque module est responsable d'une tâche spécifique
3. Il a été testé sur un Pixel 3 XL fonctionnant sous Android 9 (PQ3A.190801.002, niveau de patch de sécurité 2019-08-01) parce que c'est ce que j'avais sous la main
4. Il divulgue les adresses dans libandroid_runtime.so plutôt que dans libicuuc.so, car cela fonctionnait mieux sur ce téléphone/cible
5. Il comporte deux chaînes JOP d'exemple implémentées, l'une qui appelle execv directement et l'autre qui appelle fork puis execv
6. Il est accompagné d'un script Ghidra personnalisé qui traite le fichier libandroid_runtime.so et extrait les décalages des fonctions et des gadgets (pour faciliter le portage de l'exploit vers d'autres cibles)

Démo/Captures d'écran

Ceci est une démo vidéo montrant l'exploit modifiant le PC pour pointer vers une adresse personnalisée :

La première itération de la chaîne est celle que l'on peut voir dans jop_experiment. Cette chaîne appelle execv directement sans appeler fork. Elle se trouve dans le commit ca28fdf. Voici ce qui se produit en utilisant cette chaîne :

La deuxième itération de la chaîne est celle qui appelle fork puis execv. Les détails complets de cette chaîne se trouvent ici. Voici ce qui se produit en utilisant cette chaîne :

Heureusement, le Pixel 3 XL dispose de protections qui empêchent le processus Bluetooth d'appeler fork et/ou execv. En termes de partage de connaissances ou de démonstration, mon travail ici est terminé. Si j'écris et partage quelque chose de plus avancé, cela pourrait être trop utile pour les black-hats.

Conclusion de l'exploit

Je considère cet exploit comme complet. Les améliorations futures pourraient être :

• Écrire une chaîne JOP pour appeler dlsym puis mprotect afin d'exécuter un shellcode personnalisé
• Collecter et sauvegarder une base de données d'offsets pour différentes cibles
• Tester les exploits sur plusieurs cibles pour viser une universalité relative
• Enchaîner l'exploit avec un exploit au niveau du système d'exploitation pour obtenir les privilèges root (comme mon précédent exploit CVE-2019-2215)
• Et plus encore...

Toutes ces choses transforment ce projet d'un projet amusant de partage de connaissances à un exploit black-hat qui peut être transformé en arme, donc c'est là que mon voyage s'arrête, pour l'instant... Si vous avez des questions, n'hésitez pas à me contacter.

Utilisation

Pour exécuter l'exploit, il suffit de lancer :

make build run ARGS="00:00:00:00:00:00" 

Où 00:00:00:00:00:00 est l'adresse MAC du dispositif cible/victime. Mis à part make clean, le reste des cibles de build ne sont utiles que si vous essayez de modifier, améliorer ou réimplémenter l'exploit, donc il n'est pas nécessaire de les mentionner en détail.

Débogage

• Le binaire gdbserver d'Android se trouve dans le dossier NDK
• Utilisez ceci pour déboguer la cible (non recommandé) :

# On target
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# On host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• Directement sur le téléphone via gdb de termux (recommandé) :

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

# On target
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# OR
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

Vous pouvez redémarrer le service Bluetooth sur la machine de l'attaquant au cas où il cesserait de fonctionner :

sudo systemctl restart bluetooth.service

Notes

Cette section explique certains des phénomènes observés lors du développement de cet exploit :

• SSP est désactivé (lors de la création d'un fd de socket HCI) afin d'éviter un timeout sur la cible distante :

• Nous pulvérisons des paquets heap cleaner afin de réduire les chances que la cible plante en raison d'un débordement involontaire qui modifie les vtables de l'objet base::MessageLoop utilisé via get_message_loop :

• Ce n'était pas bien expliqué dans le billet d'Insinuator. Nous divulguons l'adresse d'un paquet en essayant de cibler les chunks malloc de 32 octets, qui incluent un élément de liste chaînée pour chaque élément de la unordered_map partial_packets. Cela a été déterminé en utilisant map_experiment Le map_experiment ne correspond pas à ce qui est divulgué dans le programme réel, donc j'ai simplement suivi le modèle d'Insinuator et utilisé un autre modèle (que j'ai également trouvé par expérimentation).

• Le crash et l'écrasement du PC font planter l'objet signal chrome avec succès

• La chaîne JOP a été simulée en utilisant jop_experiment. La chaîne JOP complète (la première, execv uniquement) est expliquée dans JOP_PLAN.md