Google détaille comment les failles de sécurité USB (fixes) compromettent les données utilisateur Android

Dans notre monde numérique moderne, nous sommes souvent plus préoccupés par les piratages et les escroqueries à distance lorsqu'il s'agit de la sécurité des appareils - mais l'accès physique à un appareil peut fournir une opportunité majeure à un attaquant ciblé. C'est le cas d'un ensemble de vulnérabilités (heureusement corrigées) trouvées par l'équipe du projet zéro de Google, qui nécessitent l'accès au port USB d'un périphérique. Si vous êtes un adepte de la sécurité, vous vous en souvenez peut-être depuis le correctif de sécurité de septembre 2018, cité brièvement comme un problème qui pourrait " permettre à un attaquant local de contourner les exigences d'interaction utilisateur pour accéder à des autorisations supplémentaires ".

En d'autres termes, tout ce que l'attaquant a à faire est de brancher une clé USB dans votre téléphone et, voilà ils ont un accès à votre smartphone. Eh bien, ils étaient assez intelligents pour comprendre comment exploiter deux vulnérabilités Android clés liées au stockage tout en créant du matériel léger. Simple.

D'accord, ce n'est pas simple, mais il y a maintenant un essai complet, étape par étape, sur le Projet Zéro, donc c'est assez accessible pour l'instant. C'est pourquoi des correctifs de sécurité et des mises à jour de version sont si cruciaux (voici un apperçu flagrant des fabricants Android qui ne sont pas Google : Essential, et BlackBerry).

Et au cas où vous vous demandez pourquoi Google fait ce qu'il fait - la politique de divulgation des vulnérabilités de l'entreprise l'oblige à respecter un délai de 90 jours avant la divulgation publique (sauf si le bogue est activement exploité, auquel cas il est de 7 jours). Cela donne aux vendeurs le temps de publier un correctif, mais aussi d'exercer des pressions pour s'assurer que ce correctif est apporté.

Cela mis à part, permettez à ce chercheur non spécialiste de la sécurité de vous guider à travers une version extrêmement simplifiée du rapport du Projet Zéro :

Étape 1 : Identifier la cible et obtenir l'accès
Mettez la main sur n'importe quel logiciel d'exécution de téléphone Android qui est pré-Android Pie et le patch de sécurité Septembre 2018. De plus, il doit prendre en charge le mode hôte USB, qui est assez répandu. Google a utilisé le Pixel 2.

Étape 2 : Trouvez la manière d'y entrer
Le port USB est votre point d'appui. Lorsqu'une clé USB est insérée dans le téléphone, vous pouvez copier des fichiers entre le système du téléphone et la clé - et même si le téléphone est verrouillé, sur les versions Android avant Pie, l'appareil essaiera toujours de monter l'USB. Heureusement, avec Pie, Google a créé un correctif qui bloque le montage des clés USB lorsque l'appareil est verrouillé. Le reste des problèmes, détaillés au fur et à mesure, ont été corrigés avec les correctifs d'août et septembre 2018.

Etape 3 : Prise de contact
Branchez la clé USB. Vous communiquez maintenant avec le noyau très important (le cœur du système d'exploitation du téléphone), et vold, abréviation de volume daemon, qui gère le montage du stockage externe, et possède des privilèges équivalents à ceux du noyau. Il va enquêter sur les partitions des types de systèmes de fichiers sur la clé USB.

Étape 4 : Mettez le micro sur écoute
Maintenant, le téléphone va rechercher trois attributs clés de chaque partition - étiquette, identifiant unique et type de système de fichiers. Les anciens schémas de partition ne peuvent pas stocker les deux derniers, donc Android extrait cette information lui-même, invoquant un outil appelé blkid. Il est donc possible de se frayer un chemin à l'aide d'une étiquette artisanale, d'un identificateur unique choisi par vous (une chaîne de chiffres appelée UUID) et d'un ensemble fixe de types.

Il y a une faille dans la façon dont vold analyse l'UUID et le type, donc en jouant avec les données juste à droite, vous pouvez tromper le téléphone pour monter le lecteur flash dans la mauvaise partie du système de fichiers du téléphone.

Étape 5 : Il y a une difficulté
Mais attendez ! Ce n'est pas si facile, il y a des limites. D'une part, avec le type de système de fichiers que vous utilisez, l'étiquette est limitée à 11 octets, et l'écriture de la première partie de votre attaque -'UUID="' utilise six octets seulement. Cela ne laisse que cinq caractères à taper dans un répertoire de destination, et avec cette limite, vous ne serez pas en mesure d'entrer très profondément dans le système, donc vous ne pouvez pas faire beaucoup de dégâts.

Étape 6 : Solution de contournement
Il y a certains types de systèmes de fichiers qui ont des étiquettes plus longues, mais vous devrez le faire à travers un ensemble séparé de vérifications. Pour que cela fonctionne, vous devrez essentiellement fournir des réponses différentes à la même question, donc une clé USB ordinaire ne suffira pas. C'est là que vous sortez le vieux Raspberry Pi et faites un faux dispositif de stockage qui est capable de changer les réponses au besoin. Avec ce gadget, votre chemin est libre pour prendre des photos à partir d'un stockage externe.

Étape 7 : Poursuivre la recherche
Besoin de plus que des photos ? Faites croire au téléphone que vous installez une clé USB plus sûre (PrivateVolume, plutôt que PublicVolume). Pour ce faire, plantez votre propre clé privée dans ce qui semble être les données du téléphone, puis montez un deuxième appareil, que vous pouvez connecter à ce niveau supérieur de confiance système en utilisant la clé que vous avez faite vous-même. Vous pouvez maintenant monter votre propre système de fichiers sur les données utilisateur du téléphone, avec vos propres règles. Comme vous contrôlez ces permissions, vous pouvez laisser n'importe quel processus accéder aux fichiers de votre système.

Étape 8 : Nous allons en profondeur
Le processus du zygote est une bonne cible. Le zygote a accès à presque toutes les données utilisateur de l'appareil. Lorsqu'il démarre au démarrage du système, vous pouvez injecter votre propre bibliothèque malveillante de fichiers exécutables et de fichiers au format ELF (linkable format), ce qui vous permettra d'obtenir un niveau de contrôle encore plus élevé sur le téléphone. Une chose, cependant. Quand vous attaquez, le zygote est déjà en marche.

Etape 9 : Temps du crash
Trouvez un moyen de tuer l'appareil, pour pouvoir injecter le zygote pendant son démarrage. Google a choisi de déclencher un crash en profitant d'un contrôle de sécurité de l'utilisation de la bande passante qui s'affiche s'il ne peut pas écrire sur disque et que si il y a plus d'un certain volume de trafic réseau est entré depuis la dernière écriture réussie. (Il n'a pas dit si c'était aussi réparé).

Étape 10 : Le Monde est a vous  (ou le  téléphone)
Votre méchant zygote transformé peut contourner les contrôles de sécurité et infiltrer le mécanisme utilisé pour créer des dumps de processus de crash (crash_dump) afin de prendre le dessus sur le vold, vous donnant des privilèges équivalents au noyau.

Étape 11 : EN OUTRE
De là, il vous est possible de passer du vold au processus d'initialisation pour Linux à sécurité renforcée. Après cela, vous pouvez même accéder au noyau, ce qui vous permet de prendre complètement et totalement le contrôle du périphérique. Un travail bien fait.

Effrayant, fascinant et extrêmement compliqué, non ? La morale de l'histoire est la suivante : prenez les mises à jour de sécurité aussi vite que possible et ne branchez jamais votre téléphone sur des appareils ou des câbles non fiables. Nos identités numériques existent sur des systèmes incroyablement complexes et parfois fragiles - des rapports comme celui-ci nous le rappellent clairement.

Source : androidpolice 

Suivez ce blog : Newsletter, Mail

Suivez-moi sur : Twitter ; Google+ Discord (chat, news..