Mini Projet :

Sujet :

Analyse d'un Exploit Android basé sur une CVE :

Démonstration et Explication

Présenté par : Encadrés par :

Benabid Ilham M. Koulali Mohammed Amine

Fakiri Imane

Azahaf mohammed reda

Filière: SICS5
Année universitaire:2023/2024
Introduction

Analyse d'un Exploit Android basé sur une CVE :................................................1

Démonstration et Explication.................................................................................1

I. DÉFINITION DES MOTS TECHNIQUES :.......................................................3

A. CVE :.....................................................................................................................4
B. EXPLOIT :...............................................................................................................4
C. POC :......................................................................................................................4
D. SEANDROID :.........................................................................................................4
E. DEVICE AND SYSTEM :...........................................................................................6
II. DESCRIPTION DE LA VULNÉRABILITÉ OU DU SCÉNARIO :.................7
A. IDENTIFIER LA VULNÉRABILITÉ :............................................................................7
B. . DESCRIPTION TECHNIQUE :..................................................................................8
C. PORTÉE DU POC :...................................................................................................9
D. CONDITION PRÉALABLE :.....................................................................................10
E. ÉTAPES DE POC :.................................................................................................12
III. CONTRE-MESURES :........................................................................................14
A. CORRECTIFS DU NOYAU LINUX :.........................................................................14
B. MISES À JOUR ANDROID :....................................................................................14
C. MISES À JOUR DES FABRICANTS :........................................................................15
D. VERSIONS ANDROID :...........................................................................................15
CONCLUSION............................................................................................................16

References
 Introduction

Android est un système d'exploitation mobile développé par Google basé sur le noyau Linux.
Connu pour son développement open source, il permet à diverses entreprises, groupes et
particuliers de modifier leurs propres systèmes d'exploitation sur des appareils mobiles tels que les
tablettes Android gratuites de Hiit Media. Le système Android utilise également les autorisations
Linux et la propriété du système de fichiers. Root est le superutilisateur sur un système Linux qui
permet aux utilisateurs de supprimer les applications système inutiles, de configurer l'interface du
système Android et de fermer les processus en arrière-plan pour optimiser la consommation
d'énergie. Cependant, cette opération peut compromettre la sécurité de votre système. Google a
renforcé son contrôle sur l'enracinement des versions et travaille avec la National Security Agency
(NSA) pour développer SEAndroid, basé sur SELinux. Cependant, selon la version d'Android, il
existe encore des méthodes root possibles.

Cette étude approfondie se concentre sur une analyse approfondie des exploits Android et explore
les méthodes couramment utilisées pour obtenir les privilèges root sur les smartphones. Nous
examinons de plus près la nature de ces exploits, en examinant la prévalence des preuves de
concept (PoC) au sein de la communauté de la cybersécurité. Compte tenu de la cybercriminalité
émergente dans laquelle les appareils mobiles jouent un rôle central, l'objectif principal sera
d'analyser des exploits spécifiques avec les CVE associés, avec un accent particulier sur le root des
appareils Android. Le but de cette étude est de fournir un aperçu détaillé du domaine du rooting
des smartphones et d’enquêter sur les exploits et les PoC liés à cette pratique particulière sur les
appareils Android.

I. Définition des mots techniques :

 A. CVE :
Common Vulnerabilities and Exposures, est une nomenclature standardisée utilisée pour identifier et
référencer publiquement les vulnérabilités de sécurité informatique. L'objectif principal des CVE est
de fournir une référence commune pour discuter, partager des informations et coordonner la gestion
des vulnérabilités.

B. Exploit :
Un exploit est un programme, un code ou une technique spécifique utilisé pour tirer parti d'une
vulnérabilité, d'un bug ou d'une faiblesse dans un logiciel, un système d'exploitation, un réseau ou
une application. L'objectif d'un exploit est souvent d'obtenir un accès non autorisé à un système,
d'exécuter un code malveillant, ou de provoquer un comportement non prévu dans le but de
compromettre la sécurité

C. PoC :
Un Proof of Concept est un démonstrateur concret, souvent sous forme de code ou d'application, qui
vise à démontrer la faisabilité ou la validité d'une idée, d'un concept ou d'une technique

D. SEAndroid :
Le modèle de sécurité Android repose sur le concept de sandbox d’application. Chaque application
s'exécute dans son propre bac à sable. Dans les versions précédentes d'Android 4.3, le système créait
un UID indépendant pour chaque application lors de l'installation de l'application et contrôlait le
processus d'accès en fonction de l'UID pour accéder aux ressources. Ce modèle de sécurité s'appuie
sur le modèle de sécurité traditionnel Linux DAC (Discretionary Access Control) pour atteindre ses
objectifs. À partir d'Android 4.3, SELinux (Secure Enhanced Linux) est utilisé pour définir
davantage les limites du bac à sable de l'application. En tant que partie intégrante du modèle de
sécurité Android, Android utilise le contrôle d'accès obligatoire (MAC) SELinux pour gérer tous les
processus. Bien que les processus puissent disposer de privilèges de superutilisateur, SELinux peut
créer des politiques de sécurité automatiques (sepolicy) pour limiter les privilèges des processus et
améliorer la sécurité d'Android. À partir d'Android 4.4, Android a activé le mode SELinux
Enforcing, qui fonctionne selon la politique de sécurité par défaut (sepolicy) définie dans le code
source AOSP. Le mode strict bloque les violations de la politique de sécurité de SELinux. Tout accès
non autorisé est enregistré dans dmesg et logcat. Par conséquent, en examinant dmesg ou logcat,
vous pouvez recueillir des informations sur les violations des politiques SELinux et améliorer votre
logiciel et vos politiques SELinux. Les fabricants peuvent définir différentes politiques SEAndroid
sur leurs appareils en fonction de leurs besoins spécifiques.

Il existe trois contextes de sécurité importants à comprendre dans le processus racine SEAndroid.

a) daemonsu : également connu sous le nom de "changer d'utilisateur", "super utilisateur"

ou "utilisateur alternatif", le binaire su agit comme intermédiaire entre une application et le
système lorsque l'application demande un accès root. Ceci est essentiel à l’ensemble du processus
d’enracinement. Dans SEAndroid, cet intermédiaire est partagé entre le processus su et le démon
su (appelé daemonsu). Le binaire su transmet toutes les requêtes reçues des applications au
démonsu. daemonsu s'exécute comme un processus démon avec l'UID racine et le contexte de
sécurité d'initialisation. daemonsu est dérivé d'init et peut hériter du domaine d'init.

b) Init : le premier processus sous Android est init. Tous les autres processus
dérivent directement ou indirectement de init. La page d'aide de Google Android Source
indique : "N'exécutez pas de processus autres que init dans le domaine init."

c) Zygote : sur Android, tous les processus d'application et les processus

SystemServer passent par le processus Zygote. Zygote est en mode application depuis
Android 4.4.
 Figure 1 : La séquence d'images du processus de démarrage

E. Device and System :

Cet environnement virtuel simule un dispositif Google Pixel 2 spécifiquement, offrant une
reproduction fidèle de ses caractéristiques matérielles et logicielles. Les dispositifs Pixel 2 sont
reconnus pour leur performance, leur qualité d'affichage et leur intégration poussée avec le système
d'exploitation Android. Notre émulateur est configuré pour refléter précisément ces aspects,
permettant aux développeurs de tester et de déployer leurs applications dans des conditions similaires
à celles d'un véritable Google Pixel 2, tout en bénéficiant des avantages d'un environnement virtuel .
 Figure 2 : Google Pixel 2 (Api 27 )

II. Description de la Vulnérabilité ou du Scénario :

A. Identifier la vulnérabilité :
disclosure of CVE-2019-2215 by Project Zero c’est une vulnérabilité trouvée par les chercheurs de
Google . La Vulnérabilité "Use-After-Free" (UAF) désigne un type de vulnérabilité de corruption de
mémoire dans lequel un programme continue à utiliser un pointeur après que la mémoire à laquelle il
pointe a été libérée. Dans le contexte d'Android et du pilote Binder, qui est une partie fondamentale
du mécanisme de communication inter-processus (IPC) d'Android, une vulnérabilité Use-After-Free
pourrait potentiellement permettre à une application malveillante d'exploiter une corruption de
mémoire et d'exécuter un code arbitraire avec des privilèges élevés.
 Figure 3 : Informations sur CVE-2019-2215

B. . Description Technique :
Sous-système Binder :
● Binder est le mécanisme de communication inter-processus (IPC) d'Android,
permettant aux processus de communiquer entre eux.
Explication de la Vulnérabilité :
● La vulnérabilité réside dans une mauvaise gestion de la mémoire dans le code du
sous-système Binder.
Déclenchement de la Vulnérabilité :
● L'exploitation de la vulnérabilité peut impliquer la manipulation de certaines
opérations IPC spécifiques via Binder.
Elévation de Privilèges :
● L'exploitation réussie de la CVE-2019-2215 peut permettre à un attaquant d'élever ses
privilèges sur un dispositif Android, lui accordant un niveau d'accès plus élevé
qu'autorisé.
Conséquences Possibles :
● Les conséquences peuvent inclure l'exécution de code arbitraire avec des privilèges
élevés, ou d'autres actions malveillantes pouvant compromettre la sécurité du
dispositif.
Conditions Préalables :
● L'exploitation de la vulnérabilité peut dépendre de conditions spécifiques, telles que
des configurations matérielles ou logicielles particulières.

C. Portée du Poc :
 Le PoC de base nous a laissé une primitive de lecture/écriture du noyau complet, essentiellement un
jeu terminé pour la sécurité des systèmes, mais a laissé l'accès à la racine comme un exercice pour le
lecteur. Cela soulève la question suivante : que signifie réellement « root » pour un système
Android moderne ?
Pour répondre à cette question, nous devons d’abord comprendre comment Android applique ses
politiques de sécurité.

Android protège contre les applications malveillantes grâce à une approche d'application à plusieurs
niveaux. Voici les principaux acteurs :

a) Contrôle d'accès discrétionnaire (DAC) - Autorisations UNIX

(ID utilisateur/groupe, autorisations d'objet R/W/X

b) Contrôle d'accès obligatoire (MAC) – Application de type via

SELinux/SEAndroid (en fait, une liste blanche de qui peut parler à qui
et comment)

c) Capacités Linux (CAP) - Divise l'utilisateur root tout-puissant

en tranches d'autorisation (CAP_XYZ)

d) SECCOMP - Permet de filtrer/bloquer les appels système,

limitant ainsi efficacement la surface d'attaque du noyau

e) Middleware Android - Autorisations typiques des applications

Android telles que définies dans android_manifest.xml, telles que
android.permission.INTERNET (généralement appliquées par
system_server)

* Pour obtenir un shell racine ( root privileges ) complet, nous devons contourner chaque couche
d’application (à l’exception du middleware Android en tant que classeur de cibles d’exploit, qui ne
nécessite aucune vérification du middleware pour y accéder).

Sur un système Android moderne, il s'agit d'une entreprise importante sans vulnérabilité du noyau. Mais
avec un exploit du noyau accessible par application, nous avons la possibilité de contourner ou de
désactiver tous ces éléments avec une relative facilité. Pour chaque tâche sur un système, le noyau
Linux garde une trace de son état dans la structure task_struct. Cet état inclut des détails pertinents
pour la sécurité tels que tous les ID utilisateur, son contexte SELinux, ses capacités, si SECCOMP est
activé, et bien d'autres. Si nous parvenons à cibler une task_struct spécifique avec notre primitive
R/W, nous pouvons modifier ces valeurs sensibles pour la sécurité à notre guise. Par exemple, si nous
ciblons notre propre tâche (le processus actuel), nous pouvons alors réaliser efficacement une élévation
de privilèges (EoP)
 Figure 4 : Hiérarchie de sécurité Android et approche en couches pour se protéger contre les
applications malveillantes

D. Condition Préalable :

* Cela fonctionne sur les Pixel 1 et 2, mais pas sur les Pixel 3 et 3a.
* Bug a été corrigé dans le noyau Linux >= 4.14 sans CVE.
* CONFIG_DEBUG_LIST casse la primitive.
* CONFIG_ARM64_UAO entrave l'exploitation.
* La vulnérabilité est exploitable dans les processus de rendu de Chrome sous le domaine SELinux
'isolated_app' d'Android, ce qui nous amène à soupçonner Binder d'être le composant vulnérable.
* L'exploit nécessite peu ou pas de personnalisation par appareil.
* Une liste des appareils concernés et non concernés et leurs versions, et plus encore.
→ Une liste non exhaustive est disponible dans la description de ce numéro.Parmi lesquelles:
1) Pixel 2 with Android 9 and Android 10 aperçus
(https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-wahoo-4.4-q-
preview-6/)
2) Huawei P20
3) Xiaomi Redmi 5A
4) Xiaomi Redmi Note 5
5) Xiaomi A1
6) Oppo A3
7) Moto Z3
8) Oreo LG phones (exécution du même kernel )
9) Samsung S7, S8, S9

Le bug est une vulnérabilité d’élévation de privilèges locale qui permet de compromettre
complètement un appareil vulnérable. Si l'exploit est diffusé via le Web, il suffit de l'associer à un
exploit de rendu, car cette vulnérabilité est accessible via le Sandboxing

Nous avons joint une preuve de concept (poc) d'exploit local pour démontrer comment ce bogue
peut être utilisé pour obtenir une lecture/écriture arbitraire du noyau lorsqu'il est exécuté localement.
Il suffit d’exécuter du code d’application non fiable pour exploiter CVE-2019-2215. Nous avons
également joint une capture d'écran du POC exécuté sur un Pixel 2, exécutant Android 8 (orio )avec
le niveau de correctif de sécurité de septembre 2019
(google/walleye/walleye:10/QP1A.190711.020/5800535:user/release-keys ).
 Figure 5 : Exploitable Properties Information of the Emulator

E. Étapes de PoC :
on a choisie un émulateur Pixel 2 Android 8 Arm64

on a téléchargé L’exploit du CVE du site :

https://github.com/kangtastic/cve-2019-2215#usage

● on a copié fichier de cve-2019-2215 de l’ordinateur au émulateur

● on a changer permission de fichier de cve pour l’executée

● on a trouvé que kernel n’est pas de version 4.4.177.. donc on a décidé d’installer une image
Rom custom : (https://developers.google.com/android/ota)

● on a vérifier qu’on a obtenue version de kernel voulus 4.4.117

● on a accédé au fichier cve et on l’a exécuté et par conséquent on a obtenus privilège d’un root
.
III. Contre-mesures :

CVE-2019-2215 a été corrigée par des correctifs de sécurité. Les correctifs sont généralement inclus
dans les mises à jour du noyau Linux et du système d'exploitation Android.

Les correctifs spécifiques dépendent du fabricant du dispositif et du fournisseur de la version du

système d'exploitation Android. Les principaux contributeurs à la correction de cette vulnérabilité
incluent Google, qui fournit des correctifs de sécurité pour les dispositifs Pixel et les mises à jour
Android, ainsi que d'autres fabricants de dispositifs Android qui intègrent ces correctifs dans leurs
propres mises à jour.

➔ Voici quelques informations générales sur la gestion des correctifs de sécurité pour la CVE-
2019-2215 :

A. Correctifs du Noyau Linux :

● Les correctifs spécifiques au noyau Linux ont été intégrés pour remédier à la
vulnérabilité dans le sous-système Binder.

B. Mises à Jour Android :

● Google a inclus les correctifs dans les mises à jour du système d'exploitation Android.
Les dispositifs Pixel bénéficient généralement des mises à jour de sécurité
directement fournies par Google.

C. Mises à Jour des Fabricants :

● Les fabricants de dispositifs Android autres que Google intègrent les correctifs de
sécurité dans leurs propres mises à jour. Ces mises à jour sont généralement
distribuées aux utilisateurs par le biais de mises à jour du système d'exploitation ou de
correctifs spécifiques.
 D. Versions Android :
● La vulnérabilité a été corrigée dans les versions ultérieures du système d'exploitation
Android. Les utilisateurs sont encouragés à mettre à jour leur dispositif vers la
dernière version d'Android disponible.

Conclusion

CVE-2019-2215 est une vulnérabilité d'utilisation après libération qui affecte le sous-système Binder
du noyau Linux utilisé par certains appareils Android. Cette vulnérabilité permet à un attaquant
d'élever les privilèges sur un appareil Android vulnérable.

La preuve de concept (PoC) associée à CVE-2019-2215 vise à démontrer comment cette

vulnérabilité peut être exploitée. Le PoC décrit les étapes spécifiques pour déclencher la vulnérabilité
et indique qu'elle pourrait permettre à un utilisateur malveillant d'exécuter du code arbitraire avec des
privilèges élevés. Le PoC comprend également des conditions préalables, les conséquences possibles
de l’exploitation, des contre-mesures et des recommandations.
Il est important de communiquer de manière proactive avec les développeurs et de divulguer de
manière responsable les vulnérabilités afin que les correctifs de sécurité puissent être ajustés avant
leur publication. Nous vous recommandons fortement d'installer les mises à jour logicielles
disponibles sur votre appareil Android pour vous protéger contre cette vulnérabilité connue.

References