Exploitation du micrologiciel Android - Micrologiciel non signé dans le SoC CVE-2020-10831 de Samsung

TL; DR  

Nous expliquerons comment nous avons exploité le micrologiciel Android à l'aide d'une API de noyau non documentée qui a été trouvée par rétro-ingénierie de l'application "Hidden Factory Settings" de Samsung.
Cette API permet de flasher le micrologiciel non signé du micrologiciel de l'écran tactile de Samsung.
Le CVE affecte toutes les séries Samsung S7-S10 utilisant le chipset exynos.

Inspiration  

Après avoir lu le projet zéro excellent article à propos de l'exploitation du micrologiciel WiFi pour obtenir RCE, j'ai décidé que je devrais essayer de faire moi-même une exploration du micrologiciel. 

Présentation générale du SoC  

De nos jours, les téléphones ont bien plus qu'un seul processeur qui exécute le système d'exploitation Android, ce qui en fait des systèmes extrêmement complexes. 

La plupart des téléphones Android ont 10 à 30 "ordinateurs" différents à l'intérieur, chacun avec son propre processeur, sa propre mémoire et son propre stockage. 

Toutes ces unités communiquent via différents protocoles de communication matériels tels que IPC, I2C, etc. 

Les principales unités de traitement des téléphones Android sont :

AP / Processeur d'application – Il s'agit du processeur principal que vous connaissez des spécifications du téléphone qui communique et gère toutes les autres unités de traitement et exécute le système d'exploitation Android. 

BP / Processeur de bande de base / Radio / Modem – Le BP est responsable de la conversion de toutes les données cellulaires reçues des ondes radio en informations utilisables par logiciel en mettant en œuvre la pile LTE. 

GPU - L'unité de traitement graphique est responsable de la gestion de toutes les tâches liées aux graphiques

Il y a plus d'unités de traitement comme le wifi, Crypto, Camera, Audio etc… 

Tous ces composants réunis appelés "System on Chip" - SoC

Trouver une cible vulnérable 

L'exploitation du firmware Android est difficile car nous avons très peu de connaissances préalables sur l'architecture du firmware et sur la manière dont le système d'exploitation communique avec lui. 

Par conséquent, l'utilisation d'une piste d'information du fabricant peut faciliter considérablement la recherche. 

Après avoir cherché sur Google les pistes mentionnées, de nombreux forums ont mentionné le problème d'écran tactile de Samsung et comment le résoudre. 
La méthode était relativement simple :

"Allez d'abord dans les paramètres cachés en écrivant * # 2663 # dans l'application du téléphone, puis cliquez sur mettre à jour le FW".

Trouver comment communiquer avec le micrologiciel

Comme mentionné précédemment, utiliser les connaissances du fabricant serait beaucoup plus facile que de tout comprendre par nous-mêmes. 

En exécutant strace sur l'application Android, qui est responsable de la mise à jour du firmware, vous pouvez facilement voir qu'après avoir cliqué sur le bouton de mise à jour, l'application écrit dans le chemin suivant

"/sys/classe/sec/tsp/cmd"

Ce chemin fait partie du mécanisme sysfs du noyau. 

sysfs est un pseudo système de fichiers fourni par le noyau Linux qui exporte des informations sur les pilotes de périphériques associés. 

Ici, nous pouvons voir comment communiquer avec le noyau à partir du fichier cmd :

L'écriture du nom de la fonction, par exemple « fw_update », puis le paramètre « 1 », entraînera une mise à jour du micrologiciel de l'écran tactile tel qu'utilisé dans l'application officielle des paramètres d'usine. 
Mais pour bien comprendre la fonctionnalité des mécanismes de mise à jour du firmware, nous devons download le noyau et regardez le code du pilote de périphérique. 
Après avoir examiné le code source du noyau qui gère la commande ci-dessus, le commentaire suivant a dévoilé des fonctionnalités très intéressantes. 

Apparemment, lors de l'écriture:

"echo -n "firmware_update:0" > /sys/class/sec/tsp/cmd"

Le paramètre 0 informe le noyau à partir duquel mettre à jour le firmware.

Comme le montre le commentaire de code du noyau, le fait de passer 2 obligera le noyau à mettre à jour le micrologiciel à partir d'UMS (carte SD). 
Un examen plus approfondi de la source du noyau affichera le chemin requis :

Processus d'exploitation 

Afin de vérifier si nous pouvons flasher un firmware non signé / mal formé, tout ce que nous avons à faire est d'essayer de voir ce qui se passe.

(En général, il est préférable de ne modifier que les chaînes lisibles par l'homme, comme un message de journal, pour ne pas interrompre le processus d'exécution du programme, malheureusement j'ai choisi la méthode la plus stupide)

La commande

Le résultat imprimé dans le journal du noyau (kmsg)

À cette partie de la recherche, je n'étais pas sûr à 100% que cela fonctionnait, mais après avoir essayé de cliquer sur mon appareil personnel et vu des tonnes d'erreurs d'E / S dans le kmsg (au lieu de simplement cliquer), j'ai compris que je viens de flasher le micrologiciel d'écran tactile mal formé avec succès , vuala ! 

Note intéressante sur le fuzzing 

Lorsque j'ai trouvé l'API du fichier cmd, ma première pensée a été "fuzzez-le et trouvez des débordements !"

Mais le journal indique clairement que l'entrée est trop longue et abandonnée pour éviter les débordements. 

Ce correctif est dû à vulnérabilité trouvé par le même chercheur de l'article du projet zéro qui m'a inspiré pour faire la recherche.