Introduction

Lors d’un précédent article nous nous intéressions à la sécurité des terminaux iOS, notamment face aux outils de jailbreak permettant de contourner le chiffrement de la NAND. Bien que le marché Suisse soit majoritairement tourné vers iOS pour le moment, la sécurité des terminaux Android n’est pas à négliger, d’autant plus que leur popularité est grandissante.

Contrairement au cas iOS, il est beaucoup plus difficile de généraliser sur la sécurité des terminaux Android du fait de la grande diversité de constructeurs sur le marché et des modifications ou spécificités que chacun d’eux peut introduire dans ses terminaux. De plus, contrairement à iOS dont les terminaux ont tendance à converger assez rapidement vers la dernière version disponible, un large éventail de versions Android peut être rencontré en parallèle, pour lesquelles les fonctionnalités qui nous intéressent peuvent ne pas être uniformes (un exemple de ceci est la disponibilité de la fonction de chiffrement). Ceci étant dit, nous détaillons dans cet article quelques cas que nous espérons suffisamment génériques pour être applicables à une majorité de terminaux.

Récupération des données

Dans le cas d’un terminal Android « lambda », un certain nombre de fonctionnalités ou de limitations peuvent avoir un impact direct sur la sécurité du terminal face à une tentative de récupération de données, par exemple en cas de perte ou de vol de l’appareil. Certaines des ces fonctionnalités sont liées à des aspects « hardware » et donc directement liées à des choix faits par le constructeur. Parmi celles-ci nous allons notamment considérer le verrouillage du bootloader (qui empêche le démarrage du terminal sur une image système modifiée) et la présence d’éventuelles interfaces de debug accessibles (JTAG, UART, …).

A l’inverse d’autres fonctionnalités sont directement proposées par le système d’exploitation (Android) et donc communes à tous les constructeurs, notamment ADB (Android Debug Bridge), le verrouillage du téléphone par un code ou un schéma ou encore le chiffrement des données (disponible depuis Android 3.0 pour les tablettes et depuis Android 4.0 pour les téléphones).

Cas #1 : out-of-the-box

Dans une grande majorité des cas, les terminaux Android sont vendus avec une configuration assez peu « intéressante » pour un attaquant, comprendre par là que la protection des données est assez bien garantie. En effet, le bootloader est généralement verrouillé par défaut et ADB n’est pas activé. Seul bémol (mais de taille) à cela, le chiffrement des données n’est pas activé par défaut sur les terminaux actuellement disponibles. Bien entendu, tout cela est inutile si l’utilisateur ne protège pas son terminal par un code d’accès (passcode). Toutefois ce cas étant trivial, nous n’allons pas le considérer et nous partons du principe que cette fonctionnalité est activée.

Un attaquant a alors trois options principales pour extraire des données d’un terminal:

• « Deviner » le passcode (ou tenter une smudge attack s’il s’agit d’un schéma de verrouillage)
• Extraire des données de la carte externe (micro-SD) si le terminal en dispose (ce qui n’est, par exemple, pas le cas des terminaux de type Nexus de Google). Les données contenues par la micro-SD peuvent toutefois ne pas être les plus intéressantes pour l’attaquant
• Utiliser un équipement permettant l’extraction des données de la NAND, par exemple via l’interface JTAG

Cette dernière option est généralement toujours envisageable, mais elle demande du matériel spécifique ainsi que le démontage plus ou moins profond du téléphone, suivant les modèles. Si ces deux conditions sont remplies, il devient alors toutefois possible d’extraire l’intégralité des données en faisant un « dump » complet de la mémoire flash.

Lors des tests menés dans notre laboratoire sur des terminaux équipés d’une NAND de 4Go, il aura fallu environ 4h pour réaliser une copie bit-à-bit au travers de l’interface JTAG.

Toutefois, une fois cette copie effectuée il aura suffi de quelques secondes (à l’aide d’un petit script Python) pour localiser les « hash » du passcode, le « salt » correspondant ainsi que pour récupérer le code par brute-force (PIN de 4 chiffres). Cette récupération est par ailleurs déjà bien documentée sur Internet.

Une fois le passcode récupéré il suffit alors de remonter pour en prendre le contrôle total et obtenir l’accès à ses données. Si ceci s’avère impossible, il est évidemment également possible d’extraire les autres données intéressantes directement à partir du dump de la flash. Il faut toutefois, pour cela, s’affranchir du fait que le dump est très bas niveau et ne fournit pas directement un système de fichiers pouvant être monté. Néanmoins, comme pour le cas du passcode, en sachant ce que l’on recherche quelques expressions régulières peuvent faire des miracles.

Cas #2 : Android Debug Bridge

Cette fonctionnalité se découpe sous la forme d’un client installé avec le SDK et d’une partie serveur lancée sur le terminal Android. Très utilisé dans le cadre du développement d’applications, il offre des options intéressantes pour un attaquant, telles que l’installation et le lancement d’applications.

Dans le cas où cette fonctionnalité est activée sur un terminal, un attaquant peut aisément accéder aux données de l’utilisateur, installer des applications et les lancer et ce sans avoir besoin du passcode.

Il est donc très important, pour la sécurité d’un terminal Android, de s’assurer que ADB n’est pas activé par mégarde.

Cas #3 : bootloader déverrouillé

Le bootloader est responsable du démarrage de l’appareil et de l’amorce du système d’exploitation. C’est donc lui qui démarre Android et qui fournit également la possibilités de démarrer le terminal sur une image de « recovery » permettant ainsi, par exemple, de flasher un nouveau système. Dans son mode de fonctionnement par défaut (verrouillé), ce bootloader ne permet le démarrage d’une image système que si cette dernière est signée par le constructeur. Toutefois, la plupart des constructeurs permettent maintenant de déverrouiller le bootloader afin de démarrer (ou de flasher) une image système non-signée (par exemple un système Android « rooté »).

Ainsi, si le bootloader du terminal à attaquer n’est pas verrouillé il est possible de démarrer le terminal sur une image « recovery » modifiée, contenant – par exemple – des outils de forensique offensif dans le but d’extraire des informations. Le système de recovery ayant généralement un accès complet à la flash (des particularités peuvent exister pour certains constructeurs, notamment pour ce qui est des droits d’écriture) il est alors possible, depuis là, d’accéder à l’intégralité des données utilisateur.

Une contre-mesure à cela est fournie par le chiffrement des données, toutefois, il sera alors possible (si le terminal a été dérobé alors qu’il était démarré mais verrouillé) de tenter des attaques de type cold-boot visant à récupérer la clé de chiffrement.

A ce stade le lecteur est en droit de se demander pourquoi il ne suffit pas – alors – pour l’attaquant de déverrouiller le bootloader du terminal pour en extraire les données. La raison est simple : l’opération de déverrouillage du bootloader entraîne, chez tous les constructeurs qui le permettent, la remise à zéro du terminal et ainsi l’effacement des données. Il ne s’agit pas là d’une contrainte technique mais bel et bien d’une fonctionnalité de sécurité visant justement à empêcher la compromission des données.

Conclusion

Comme nous avons tenté de le présenter dans cet article, la combinaisons des différentes fonctionnalités de sécurité peut rendre plus ou moins complexe la récupération des données sur un terminal Android. Les configurations d’usine sont généralement prévues pour être sûres toutefois, la grande liberté laissée à l’utilisateur dans la modification de son terminal Android (par opposition aux terminaux iOS) permet également à ce dernier d’effectuer des modifications entraînant un risque pour la sécurité de ses données.

De plus, il est à relever que même dans le cas où le terminal dispose d’un bootloader verrouillé et que ADB n’est pas démarré, il reste possible pour un attaquant ayant quelques connaissances en électronique (et surtout l’équipement approprié), de procéder à une copie bit-à-bit de la NAND et ainsi accéder aux données stockées sur le terminal, pour autant qu’elles ne soient pas chiffrées.

Pour conclure nous relèverons donc que, bien que ceci ne soit – malheureusement – pas fait par défaut sur les terminaux Android, l’activation du chiffrement des données apparaît comme une composante de base indispensable à une bonne protection des données de l’utilisateur.

Julien Bachmann
Sergio Alves Domingues