La banque se plaint d'Android rooté. Est-ce vraiment pire qu'un bureau Windows?
Lorsque j'utilise application Android de ma banque, l'application remarque que mon téléphone est enraciné et affiche un message avec un grand symbole "danger" rouge et un message disant "appareil vulnérable". Je comprends parfaitement qu'ils le font, car les institutions financières aiment toujours être prudentes. La banque peut alors dire "Nous vous avons prévenu!" si quelqu'un avec un appareil enraciné voit ses services bancaires en ligne compromis.
Maintenant, je me rends compte que mon téléphone est moins sécurisé qu'un appareil non rooté Android. Je crois que tout le monde le fera facilement d'accord avec cela. ( Combien moins dépendra évidemment de beaucoup de choses.)
Mais la pensée que j'ai est, est-ce vraiment différent d'utiliser Net Banking dans un navigateur fonctionnant sur un bureau Windows? Je veux dire, Windows est également "enraciné" dans le sens où vous avez la possibilité d'accorder des privilèges "administratifs" à n'importe quelle application que vous souhaitez?
Donc, dans le sens où ils se plaignent que mon téléphone a la capacité de donner des autorisations "root" aux applications, n'est-ce pas comme utiliser les services bancaires en ligne sur un système d'exploitation de bureau qui a également cette capacité?
Que faire si j'ai utilisé les services bancaires en ligne à partir d'une application de navigateur sur mon téléphone? Serait-ce plus sûr que l'application?
L'utilisation des services bancaires en ligne dans une application de navigateur sur mon téléphone serait-elle différente de celle d'un navigateur sur un ordinateur Windows? (Les deux sont des navigateurs fonctionnant sous un système d'exploitation "enraciné".)
Tout dépend du modèle de sécurité
Nous voyons une référence à la "vérification de l'appareil jailbreaké/enraciné" dans presque toutes les listes de contrôle de sécurité des applications mobiles (par exemple OWASP ). Lorsque nous le comparons aux ordinateurs de bureau ou aux navigateurs Web, nous devons garder à l'esprit qu'ils ont différents modèles de menace.
Par exemple, sur les ordinateurs de bureau lors de la conception d'une application, nous savons déjà qu'il existe d'autres applications dotées de privilèges d'administrateur.
Pour vous donner un exemple, le modèle de sécurité pour les systèmes d'exploitation comme Windows ou Linux n'empêche pas une application d'accéder aux répertoires ou à la mémoire d'une autre application.
Maintenant dans le contexte mobile, en prenant Android comme exemple, le système d'exploitation empêche les applications d'accéder aux répertoires les uns des autres et le privilège root contourne ce contrôle de sécurité. Ainsi, en rootant votre appareil, vous apportez une modification dans votre appareil qui peut ne pas être prévu par les développeurs d'applications et ses risques peuvent ne pas être pris en considération.
Revenons maintenant à Projet de sécurité mobile de l'OWASP (Dangers of Jailbreaking/Root) , les méthodes d'enracinement sont classées comme suit:
- Exploits d'Userland: l'accès jailbreaké n'est obtenu qu'au sein de la couche utilisateur. Par exemple, un utilisateur peut avoir un accès root, mais n'est pas en mesure de modifier le processus de démarrage. Ces exploits peuvent être corrigés avec une mise à jour du firmware;
- iBoot Exploit: accès jailbreaké au niveau utilisateur et processus de démarrage. Les exploits iBoot peuvent être corrigés avec une mise à jour du firmware;
- Bootrom Exploits: accès jailbreaké au niveau utilisateur et processus de démarrage. Les exploits Bootrom ne peuvent pas être corrigés avec une mise à jour du firmware. Mise à jour matérielle de bootrom requise pour corriger dans de tels cas;
Et les risques sont:
Général Mobile
- Certaines méthodes de jailbreaking laissent SSH activé avec un mot de passe par défaut bien connu (par exemple, Alpine) que les attaquants peuvent utiliser pour Command & Control;
- L'ensemble du système de fichiers d'un appareil jailbreaké est vulnérable à un utilisateur malveillant qui insère ou extrait des fichiers. Cette vulnérabilité est exploitée par de nombreux programmes malveillants, notamment Droid Kung Fu, Droid Dream et Ikee. Ces attaques peuvent également affecter les appareils Windows Phone déverrouillés, selon le niveau de déverrouillage atteint;
- Les informations d'identification des applications sensibles, telles que les applications bancaires ou d'entreprise, peuvent être volées à l'aide de l'enregistrement des clés, du reniflement ou d'autres logiciels malveillants, puis transmises via la connexion Internet.
iOS
- Les applications sur un appareil jailbreaké s'exécutent en tant que root en dehors du bac à sable iOS. Cela peut permettre aux applications d'accéder aux données sensibles contenues dans d'autres applications ou d'installer des logiciels malveillants annulant la fonctionnalité de sandbox;
- Les appareils débridés peuvent permettre à un utilisateur d'installer et d'exécuter des applications auto-signées. Étant donné que les applications ne passent pas par l'App Store, Apple ne les examine pas. Ces applications peuvent contenir du code vulnérable ou malveillant qui peut être utilisé pour exploiter un appareil.
Android
- Les utilisateurs d'Android qui modifient les autorisations sur leur appareil pour accorder un accès root aux applications augmentent l'exposition de la sécurité aux applications malveillantes et aux failles potentielles des applications;
- Tierce partie Android marchés d'applications ont été identifiés comme hébergeant des applications malveillantes avec des capacités d'administration à distance (RAT).
Risques non techniques
- Les mises à jour logicielles ne peuvent pas être appliquées immédiatement car cela supprimerait le jailbreak. Cela laisse l'appareil vulnérable aux vulnérabilités logicielles connues et non corrigées;
- Les utilisateurs peuvent être incités à télécharger des logiciels malveillants. Par exemple, les logiciels malveillants utilisent couramment les tactiques suivantes pour inciter les utilisateurs à télécharger des logiciels;
Les applications annoncent souvent qu'elles fournissent des fonctionnalités supplémentaires ou suppriment des publicités d'applications populaires mais contiennent également du code malveillant;
Certaines applications n'auront pas de code malveillant dans la version initiale de l'application, mais les "Mises à jour" ultérieures inséreront du code malveillant.
On peut compter d'innombrables risques pour chaque plate-forme, allant du Web, des applications mobiles, des applications de bureau, etc. et comparer ces plates-formes en termes de sécurité n'est pas anodin. Il peut être fortement tributaire de plates-formes spécifiques (Android vs iOS, Windows vs Linux) et également dépendre des comportements des utilisateurs (avoir un appareil mobile avec beaucoup d'applications indésirables vs avoir un appareil mobile uniquement avec des applications connues). Dans chaque contexte, nous essayons de prendre des mesures afin de réduire nos risques et une fois qu'une plate-forme devient trop précaire, nous pouvons cesser de fournir des services (par exemple, des opérations bancaires par téléphone via un téléphone fixe ou USSD).
Pour en revenir à votre question sur l'utilisation du navigateur Web de votre téléphone mobile par rapport à l'utilisation de l'application native des banques mobiles, les risques dépendent de la mise en œuvre de l'application bancaire mobile et du type de malware pouvant être présent sur votre téléphone mobile.
Les applications dans Android se voient attribuer différents UID/GID dans le Linux sous-jacent et sont ainsi isolées les unes des autres de cette manière. Comparez cela à une application de bureau standard où tous les programmes exécutés par l'utilisateur ont généralement le mêmes autorisations (en l'absence de configuration AppArmor ou SELinux pour Linux). Windows n'est-il pas similaire? Les navigateurs offrent certaines capacités de sandboxing mais uniquement à partir d'autres codes exécutés par navigateur et même cet environnement est criblé d'avenues intersites pour une exploitation potentielle.
L'enracinement permet à l'utilisateur d'autoriser une application arbitraire à disposer de privilèges élevés. Cela représente certainement une menace et dérange les banques car elles estiment que cela échappe à leur contrôle. Mais c'est sous le contrôle de l'utilisateur. Le point important est que la compétence et les actions de l'utilisateur sont toujours hors du contrôle de la banque. Vraisemblablement, quiconque raccroche son téléphone est susceptible d'avoir au moins une compréhension élevée des risques et une compréhension concomitante de l'atténuation. Donc, bien sûr, la banque ne sait pas avec qui d'autre l'utilisateur dort - avec des privilèges élevés - ni à quel point ils sont avertis. D'un autre côté, l'enracinement permet des contre-mesures qui peuvent renforcer la sécurité. Si l'utilisateur est négligent, l'enracinement peut le laisser très exposé.
Même sans privilège root, toute application peut présenter un affichage qui prétend être l'application bancaire et inciter l'utilisateur à fournir des informations d'authentification. La façon dont cela est accompli avec succès est certes difficile mais certainement possible pour de nombreuses victimes potentielles.
Je crois que le dogme qui rend un téléphone "peu sûr" - un terme mal défini - est trompeur et les banques devraient concentrer leur attention sur d'autres questions.
FWIW, j'utilise root, entre autres, pour configurer iptables, car il est intéressant de noter que stock Android ne me permet pas d'autoriser de manière sélective des applications pour l'accès à Internet. Et nous pouvons tous deviner quels intérêts sont servis par cette circonstance.
J'accepte les informations fournies par @Silverfox. Les institutions financières visent certainement à réduire le risque de fraude en basant leur politique de sécurité sur un modèle de menace propre à l'appareil ciblé.
De nombreux systèmes bancaires en ligne ont adopté l'authentification multifacteur (MFA) pour prouver l'identité de leur utilisateur. Cela signifie qu'un attaquant qui obtient votre combinaison nom d'utilisateur/mot de passe ne peut pas accéder à votre compte (il leur faudrait soit obtenir le code de vérification, soit usurper/compromettre un "PC de confiance" auparavant).
L'escalade de privilèges permet à l'adversaire de rompre l'isolement et d'accéder à toutes les données sensibles. Étant donné que le téléphone est désormais un élément essentiel du schéma d'authentification des utilisateurs, un appareil enraciné représente un risque beaucoup plus grand pour la société financière car s'il est compromis. Par exemple, le malware peut voler des informations d'identification de l'application bancaire, ou même obtenir le code de vérification SMS qui est envoyé dans le cadre du MFA, le supprimant immédiatement pour masquer les traces de l'utilisateur.
Cependant, une chose importante à considérer est que ces vérifications d'environnement d'exécution peuvent souvent être facilement contournées. Il existe différentes méthodes et API pour effectuer la vérification, mais par exemple, de nombreuses applications le feront à peu près: vérifiez si le binaire "su" existe, si tel est le cas, il est supposé que le périphérique dispose des privilèges root. En renommant trivialement "su", il est tout à fait possible de contourner ce type de vérification.
Pour de meilleurs résultats, de nombreuses applications modernes Android utiliseront quelque chose comme l'API Google SafetyNet pour effectuer une attestation à distance et vérifier l'état de conformité de l'appareil. En outre, il existe des solutions tierces sous l'égide de Les applications de gestion des appareils mobiles (MDM), qui sont généralement déployées par de grandes entreprises qui partagent les risques que leurs employés transportent des données sensibles, par exemple, voir leur application de messagerie professionnelle être compromise si un appareil enraciné est infecté.