Merci à AndrewT qui a publié un lien sur le chat , ayant ce document de recherche comme référence dans l'une des réponses . Cette réponse est entièrement basée sur le présent document (mai 2015) et met en évidence les aspects communs compréhensibles par l'utilisateur (elle contient de nombreux documents liés à la sécurité pour les personnes intéressées)
Quels sont les avantages et les inconvénients en dehors de ce qui précède?
Si un appareil a les deux options - enracinement basé sur l'application et enracinement par des méthodes par les développeurs, laquelle dois-je choisir?
Réponse: Tout est question de vulnérabilité aux logiciels malveillants. L'utilisation d'exploits root est un ÉNORME risque de sécurité et qui surpasse tous les autres avantages
Qu'est-ce que la racine molle et la racine dure?
Racine douce: la racine est obtenue directement en exécutant un logiciel (c'est-à-dire des exploits root) - soit en l'installant directement sur l'appareil ou en nécessitant un adb
shell via une connexion PC
Racine dure: la racine est obtenue en flashant su binaire en externe via un package de mise à jour ou une ROM
Menace liée aux logiciels malveillants - en général
Même si elles sont légitimes, de nombreuses méthodes racine en un clic pratiques fonctionnent en exploitant les vulnérabilités du système Android. S'ils ne sont pas soigneusement contrôlés, de tels exploits peuvent être utilisés abusivement par l'auteur de logiciels malveillants pour obtenir un privilège root non autorisé.
Comme décrit dans le projet Android Malware Genome , 36,7% (sur 1260) des échantillons de logiciels malveillants avaient intégré au moins un exploit root.
Ces exploits bien conçus ne sont pas bien protégés, c'est extrêmement dangereux s'ils tombent entre de mauvaises mains.
Qui sont les principaux fournisseurs de root et comment cela fonctionne-t-il?
Quels sont les types d'expositions racine?
L'article couvre 78 exploits étudiés. En général, l'ordre d' impact (du plus élevé au plus faible ):
Exploits du noyau: En raison de sa position privilégiée, cibler le noyau Linux est naturel pour obtenir un contrôle total sur un appareil Android - exemple, TowelRoot
Exploits de bibliothèque: les exploits ciblant les bibliothèques utilisées par les processus système Android ou les bibliothèques externes utilisées pour prendre en charge différentes applications, par exemple l'exploit ZergRush, les libsysutils utilisés par le démon Volume Manager
Application et cadre d'application Exploits de racine de couche application: les exploits ciblant les applications ou les services système, incluent principalement les logiques vulnérables introduites par les setuid
utilitaires, les applications système ou les services. exemple est un setuid
utilitaire vulnérable qui n'est présent que sur les appareils XoomFE qui a une vulnérabilité d'injection de commande
Noyau ou pilotes spécifiques au fournisseur : les fournisseurs personnalisent le noyau (par exemple, la branche de noyau Linux personnalisée de Qualcomm) ou fournissent des pilotes de périphérique spécifiques au fournisseur pour divers périphériques (par exemple, caméra, son). Ce code s'exécute à l'intérieur de l'espace du noyau et le compromis peut également conduire à un contrôle total sur le périphérique.
En termes de nombre , les exploits sont comme dans la figure ci-dessous
Est-il difficile de mettre la main sur Exploit (source ou binaire)?
Très facile. Facilement disponible à partir de la recherche Google, ce qui en fait un jeu d'enfant pour les auteurs de logiciels malveillants de tirer parti de ces exploits. La recherche de 73 exploits a conduit à la disponibilité de 68 d'entre eux - 46 avec le code source et 22 avec les binaires
Comment fonctionnent ces exploits?
Exigences majeures pour que les exploits fonctionnent (classés du plus difficile au moins ) (la balise malware contient un grand nombre de ces instances)
Requiert des interactions avec les utilisateurs: (6 sur 78 étudiés)
- Demander à l'utilisateur de télécharger une application et d'interrompre manuellement l'installation
- Demander à l'utilisateur de démarrer la récupération au moins une fois.
- Demander à l'utilisateur de mettre manuellement l'appareil en mode «économie de batterie».
- Demander à l'utilisateur d'ouvrir une application spécifique au fournisseur et d'appuyer sur un bouton
Requiert adb
shell via une connexion PC: (17 sur 78 étudiés). Pour certains exploits, une adb
connexion shell est requise pour les raisons les plus courantes suivantes:
L'exploit peut modifier avec succès un paramètre dans local.prop
lequel active adb
uniquement root pour le shell.
L'exploit doit écrire dans un fichier appartenant à l'interpréteur de commandes de groupe et accessible en écriture de groupe (non accessible en écriture universelle)
L'exploit cible le processus du démon adb qui nécessite que le processus d'attaque s'exécute avec l'utilisateur shell. Par exemple, l' exploit Rage Against the Cage cible la vulnérabilité de la vérification manquante du démon adb sur la valeur de retour desetuid()
Redémarrage: (6 sur 78 étudiés) Généralement, de nombreux exploits root nécessitent au moins un redémarrage. Par exemple, une attaque de lien symbolique permettrait à un attaquant de supprimer un fichier appartenant au système avec une autorisation faible, pour configurer un lien au même emplacement vers un fichier protégé. Après un redémarrage, les scripts d'initialisation correspondants tenteraient de modifier l'autorisation du fichier d'origine en écriture universelle, ce qui en réalité modifie l'autorisation du fichier lié
Aucune ou autorisation: (44 sur 78 étudiés) Les exploits de cette catégorie n'ont pas d'exigences strictes, cependant, certains d'entre eux peuvent nécessiter certaines autorisations Android comme READ LOGS
pour que le propriétaire du processus soit placé dans un certain groupe d'utilisateurs.
Ces exploits peuvent-ils être détectés par Anti-Virus?
Étant donné que les exploits root sont très sensibles et peuvent être exploités par divers logiciels malveillants Android, il est prévu que les logiciels antivirus sur la plate-forme Android puissent identifier la plupart d'entre eux, y compris ceux mis en œuvre par les fournisseurs de root. Dans l'ensemble, le résultat montre que les produits de sécurité de pointe sur la plate-forme Android ne peuvent toujours pas lutter efficacement contre les exploits root
4 produits antivirus Android représentatifs ont été utilisés pour tester le plus grand fournisseur (nom non révélé) ayant 167 exploits. Étant donné que les exploits téléchargés à l'origine à partir de la base de données des fournisseurs ont compressé le code d'exploitation réel et utilisé un mécanisme de détection de falsification, l'étude a conçu 3 versions différentes pour chaque exploit:
Exploit d'origine récupéré directement sur les serveurs des fournisseurs, avec emballage et détection de sabotage activés.
Exploit décompressé, qui exposera toute la logique d'exploitation réelle aux produits antivirus.
Exploit reconditionné avec détection de sabotage désactivée.
Les binaires d'exploitation conçus par de grands fournisseurs de racine sont étonnamment «propres» car tous les principaux logiciels antivirus ont du mal à les détecter comme le montre le tableau ci-dessous
Conclusion
Facile. Éloignez-vous des méthodes de racine douce, sauf si vous êtes capable de faire face aux conséquences