CVE-2020-0022

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

Résultats

Toutes les étapes mentionnées dans l'article d'Insinuator ont été réalisées, et bien plus. Ces étapes sont nombreuses à mettre dans un fichier README.md, donc 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'à ce que les chances d'échec diminuent significativement
4. Le code est optimisé en termes de temps de déconnexion et de vitesse de recherche mémoire jusqu'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 la manière suivante :

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 sous Android 9 (PQ3A.190801.002, Niveau de correctif de sécurité 2019-08-01) car c'est ce que j'avais sous la main
4. Il divulgue des adresses dans libandroid_runtime.so plutôt que dans libicuuc.so, car cela fonctionnait mieux sur ce téléphone/cible
5. Il dispose de deux chaînes JOP d'exemple implémentées, une qui appelle execv directement et une 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 gadgets (pour faciliter le portage de l'exploit vers d'autres cibles)

Démo/Captures d'écran

Voici une démonstration 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 peut être trouvée 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 peuvent être trouvés 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 hackers malveillants.

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 de décalages pour différentes cibles
• Tester les exploits sur plusieurs cibles pour viser une relative universalité
• 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 en un exploit black-hat qui peut être utilisé comme 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, lancez simplement :

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

Où 00:00:00:00:00:00 est l'adresse MAC de l'appareil cible/victime. En dehors de make clean, les autres cibles de construction ne sont utiles que si vous essayez de modifier, améliorer ou réimplémenter l'exploit, il n'est donc pas nécessaire de les mentionner en détail.

Débogage

• Le binaire gdbserver Android peut être trouvé 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 termux's gdb (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 attaquante s'il cesse 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 descripteur de socket HCI) afin d'éviter un délai d'attente sur la cible distante :

• Nous envoyons des paquets de nettoyage de tas (heap cleaner) afin de réduire les chances que la cible plante en raison d'un débordement non intentionnel qui modifie les vtables de l'objet base::MessageLoop utilisé via get_message_loop :

• Cela n'a pas été bien expliqué dans l'article d'Insinuator. Nous divulguons l'adresse d'un paquet en essayant de cibler les blocs 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écouvert en utilisant map_experiment Le map_experiment ne correspond pas à ce qui est divulgué dans le programme réel, j'ai donc 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 (première, execv uniquement) est expliquée dans JOP_PLAN.md