Implication de sécurité si Android peut être installée sur l'émulateur
Je travaille à assurer la sécurité des produits de mon entreprise. Nous avons une version mobile du produit. Cette question concerne la Android
Contexte - Notre produit est un produit basé sur SaaS et l'application est destinée à être utilisée par différents vendeurs de l'organisation de locataires. Nous avons mis en œuvre différentes couches de contrôle pour assurer un environnement sécurisé (ou plus comme sûr) pour notre application -
- Nous vérifions la détection des racines - (vérification du niveau du système d'exploitation)
- Épinglage SSL implémenté - (Vérification du niveau de la couche de transport)
- Stockage de secrets dans Android porte-clés
- Stockage local minimal des données. Crypter les données locales (qui doivent être stockées)
et la liste continue. En bref, de l'appareil à la couche de communication en passant par la couche serveur, nous sommes en train de couvrir tous les coins.
Le problème est que nous avons eu un problème signalé par l'un des chercheurs en sécurité qui dit que notre application peut être téléchargée à partir du Android Play Store donc elle peut fonctionner sur un émulateur et sur un émulateur, il est possible de contourner la détection racine. Cela ajoute donc une énorme menace et devrait être corrigé immédiatement.
J'ai recherché, mais je ne trouve aucune implication de sécurité qui pourrait être possible si l'application peut être installée sur l'émulateur. J'ai également vérifié si je devais y remédier, quelle pourrait être la solution possible. Il y a des vérifications comme regarder si l'environnement en cours d'exécution est un SDK, vérifier si des fonctionnalités comme la caméra ou les capteurs fonctionnent, mais toutes ces vérifications peuvent également être contournées dans l'émulateur.
C'est un peu critique pour moi car si j'accepte ce problème, notre client le verra dans le rapport et insistera pour qu'il soit corrigé. Je suis vide pour l'implication que je devrais expliquer à la direction et aux développeurs (si j'accepte) et corriger (cela pourrait être nécessaire plus tard)
Mise à jour -
- Je tiens à préciser une chose que nous ne préconisons jamais la détection de racine ou tout autre contrôle de sécurité côté client comme un point positif de notre application, car nous pensons que toute la protection côté client peut être contournée à un moment ou à un autre
- Nous continuons d'essayer de construire une architecture plus sécurisée au niveau du serveur. Mais puisque le côté client fait également partie de l'écosystème, nous ne pouvons donc pas le laisser sans surveillance.
- Nous essayons même d'implémenter des contrôles au niveau de la couche de communication (autres que TLS) pour nous assurer qu'en appuyant simplement sur vous ne pouvez pas tout
Toute l'idée est que si nous ne pouvons pas contrôler certaines choses, nous pouvons au moins rendre la tâche difficile aux parties malveillantes. Notre objectif principal est de sécuriser les données et les contrôles de nos utilisateurs sont en place et en cours.
Mise à jour également de Pentester - Après discussion avec lui, il a dit qu'il ne comprenait pas les exigences de sécurité de l'application. Selon lui, toutes les applications devraient avoir une détection de racine. Nous lui avons expliqué que ces choses étaient secondaires pour nous, mais si des données spécifiques au client se trouvent à la vue ou peuvent être compromises en raison d'une mauvaise configuration dans l'application ou de toute vulnérabilité dans l'application (comme les secrets codés en dur), alors c'est primaire.
Sur la base des informations fournies, vous avez pu clarifier cette distinction et aider à résoudre le problème. Auparavant, c'était tout le bruit à cause de ce problème. Merci à tous
On ne sait pas quel type d'exigences de sécurité vous avez en premier lieu et donc on ne sait pas si vos mesures de sécurité sont suffisantes ou non.
Une protection complète contre un utilisateur malveillant utilisant votre application n'est pas possible tant que vous n'êtes pas en mesure de contrôler complètement le périphérique de l'utilisateur. Ce risque comprend l'exécution de l'application sur des émulateurs, mais également son exécution sur un périphérique enraciné ou autrement altéré - et tout cela ne sera pas détecté par la méthode de détection de racine que vous utilisez.
Au lieu de cela, vous devez concevoir votre application de sorte qu'un utilisateur malveillant ne puisse pas vous faire de mal ou à d'autres utilisateurs mais seulement à lui-même. Cela signifie par exemple avoir des secrets spécifiques à l'utilisateur dans l'application et ne pas utiliser de secrets globaux. Cela signifie également que vous ne devez pas faire confiance à quoi que ce soit signalé par l'application, mais plutôt vérifier si cela a du sens (c'est-à-dire ne pas faire confiance aux scores élevés auto-déclarés dans les jeux ou similaires).
Pour qui la sécurité vous préoccupe-t-elle ici, et qu'essayez-vous de protéger? Essayez-vous de protéger les utilisateurs contre le fait que d'autres personnes accèdent à leurs données, ou essayez-vous de protéger l'entreprise contre les ingénieurs inverses qui tentent de voir comment l'application fonctionne parce que votre API n'est pas sécurisée?
Si vous essayez uniquement de protéger la sécurité des utilisateurs, il n'y a aucun problème à ce que l'application s'exécute dans un VM sauf si vous pensez que les utilisateurs exécuteront l'application dans un _ mal sécurisé [VM et se faire voler leurs données, ce qui est très improbable et c'est leur problème, pas le vôtre.
Si vous essayez d'empêcher les gens de faire de l'ingénierie inverse de l'application, vous livrez une bataille difficile car les vérificateurs de racine sont facilement contournés. C'est aussi presque toujours un effort inutile car l'application ne devrait rien avoir d'utile pour un attaquant si elle a été conçue en toute sécurité.
En outre, gardez à l'esprit que, parfois, les personnes effectuant des tests de sécurité inventent parfois des non-problèmes s'ils ne trouvent aucun problème réel, car un rapport vierge rend difficile la justification de l'argent dépensé. Si possible, défiez-les sur cette déclaration et demandez-leur de donner un exemple concret de la façon dont il s'agit réellement d'un problème.
La réponse classique et correcte à votre client est NOTANISSUE .
Aucun logiciel côté client * * ne doit jamais être considéré comme étant sécurisé, au sens où votre question le demande. Ils ne peuvent pas l'être. Le logiciel côté client - qu'il s'agisse du Web ou d'une application - est totalement sous le contrôle des clients, tout comme son environnement, tout comme la capacité totale de réécrire/modifier le logiciel ou de l'exécuter dans un environnement indétectablement non sécurisé ou modifié. Ce n'est pas un bug. C'est inhérent au modèle * *.
Le but de vos différents contrôles est de réduire les risques et de relever la barre, comme si souvent en toute sécurité. C'est pas fait pour sécuriser le client ou assurer la sécurité côté client, et votre client a tort d'assumer cet objectif.
- * * Avec peut-être la seule exclusion des logiciels côté client où l'ensemble du logiciel côté client et son environnement sont conçus et contrôlés dans le but de créer un environnement hautement inviolable et vérifiable, tel que Trusted Exécution, ou le micrologiciel de certains YubiKeys (qui ne peuvent pas être téléchargés ou modifiés facilement une fois flashés), ou lorsque le client est un système distant avec sa propre sécurité en place, comme des serveurs de basculement bien sécurisés se synchronisant entre eux via SSH.
Même dans ce cas, le module spécifique peut être considéré comme sécurisé (pour un certain modèle de menace) mais cela ne signifie toujours pas que quoi que ce soit d'autre, comme une application locale vérifiant la réponse du dongle, est en aucune façon sécurisé.
Je suis en train de réorganiser les lignes ici, mais je pense que je vois d'où vient le chercheur.
Votre application n'a aucune activité de stockage (ou d'utilisation) de secrets qui pourraient révéler les données d'autres clients.
concevez votre backend pour que les secrets donnés au frontend ne donnent qu'un accès compartimenté aux services backend. puis, si un utilisateur roote son appareil, il ne peut pirater que son propre compte.
Je ressens le besoin de défendre ici le pauvre testeur de stylo décrié.
Dans quel but ce testeur a-t-il été embauché et dans quelle mesure?
Si le développeur de l'application a fourni un livre blanc ou une stratégie de sécurité, etc. qui prétend que la détection des racines fait partie de leur stratégie de sécurité, il est tout à fait approprié de souligner que la détection des racines est une fiction pour les apks accessibles au public. Ce n'est généralement pas le problème du testeur de déterminer si l'architecture globale est réellement vulnérable du côté client et ne doit être exécutée que sur des appareils contrôlés, ou la direction souhaitait simplement la plus grande liste possible de "fonctionnalités de sécurité". Il ou elle signale simplement qu'il a échoué par rapport aux affirmations fournies (que la détection des racines améliore la sécurité.)
Le "correctif" arrête de prétendre que les vérifications d'environnement côté client font tout pour la sécurité afin que vous puissiez avoir une plus grande liste de "fonctionnalités de sécurité".
Le libellé qui implique que cette personne a déclaré "être sur Playstore est une vulnérabilité" n'est pas le leur. (avoir eu des choses que j'ai dites mal reformulées d'une manière qui fait que ça ne va pas assez souvent dans ma propre carrière ...!)
Je ne considérerais aucune des applications côté client ou Web comme autonome suffisamment sûre, c'est-à-dire sans sécuriser la solution côté serveur indépendamment sur le système d'exploitation.
Toutes les couches de sécurité, validations et vérifications implémentées à l'intérieur de l'application côté client doivent être au moins répétées avec des validations correspondantes ou plus fortes dans les composants côté serveur de votre application.
De plus, l'utilisation de l'émulateur pour exécuter l'application signifie que les propres vulnérabilités de l'émulateur peuvent nuire à la sécurité de l'utilisateur, par exemple, certaines vulnérabilités permettaient aux attaquants d'exécuter du code à distance, de divulguer des informations, de voler des sauvegardes et des données, ainsi que d'accéder aux inter- fonctions de communication de processus *.
Il y a peu de différence entre une JVM fonctionnant sur un périphérique matériel ou un émulateur. Bien sûr, on pourrait voir si la chaîne de construction du système d'exploitation a "générique" (que seul l'émulateur a), puis quitter l'application, lorsqu'il s'agit d'une version de version - mais cela n'apporte aucune amélioration de la sécurité globale (car le bytecode peut facilement être décompilé - et seule la signature de code empêche les modifications des fonctionnalités dans une certaine mesure). De plus, les versions de version ne sont pas configurées comme debuggable.
Le fait est que, lorsqu'il ne peut pas s'exécuter sur un périphérique enraciné, il ne s'exécutera pas sur un émulateur (enraciné).
Une détection fiable des racines est impossible, en raison des trous de test logiques évidents du stylo.
Si l'utilisateur a accès à l'apk, l'utilisateur peut également simplement analyser l'apk, puis appeler directement les API de votre serveur assez facilement et contourner complètement l'application ou portez l'application sur un autre système. Vous devez repenser votre approche globale de la sécurité si cela fait partie de la stratégie de protection de vos systèmes pour détecter si elle est exécutée sur un appareil enraciné - puisque vous ne peut même pas savoir de manière fiable ce qui est exécuté.
L'utilisateur peut s'il veut décompiler votre application et simplement retirer toutes les parties de détection de l'application en premier lieu. Le processus serait exactement le même que le logiciel de "craquage".
Ce que vous pouvez faire avec la détection de racine est de simplement faire savoir à un utilisateur que vous pensez que son téléphone est enraciné, par mesure de sécurité pour l'utilisateur - peut-être que le téléphone est enraciné sans que l'utilisateur le sache? mais même dans ce cas, vous ne pouvez pas vous y fier. vous ne pouvez pas savoir si c'est du matériel réel ou non que vous utilisez. Vous ne pouvez pas savoir s'il fonctionne sur un système comme Knox où vous pouvez payer Samsung pour obtenir essentiellement des pouvoirs root dans le système (grâce aux fonctionnalités d'entreprise - et oui, il peut essentiellement vous accorder des pouvoirs presque root pour jouer avec d'autres applications et d'autres composants d'applications - le téléphone apparaîtra alors comme sécurisé knox et sans racine).
La détection des racines et autres se retrouvent généralement dans une application pour dissuader le piratage, mais c'est à 100% la mauvaise approche pour lutter contre le problème. Désolé, mais ce dont vous avez besoin, c'est d'un changement de pensée culturelle dans l'organisation en ce qui concerne la sécurité: vous ne pouvez pas faire confiance à un logiciel qui s'exécute ailleurs pour être ce que vous pensez qu'il est si pentestant car cela est inutile.
edit: Si vous avez besoin d'un moyen de l'expliquer à vos supérieurs, vous pouvez essayer ceci: "Si nous pouvions le faire, alors ce morceau de code vaudrait plus que ce que la société entière va jamais valoir" - et cette citation serait s'appliquent toujours à votre entreprise même si vous avez travaillé pour Google.
L'avertissement du chercheur en sécurité est correct, mais vous devez placer cet avertissement dans le contexte de votre application pour savoir s'il est pertinent.
Vous avez répertorié la "détection de racine" comme une caractéristique de sécurité importante de votre application.
Étant moi-même un expert en sécurité, je voudrais souligner que la détection des racines peut être facilement contournée. Non seulement sur les machines virtuelles: mais également sur les appareils physiques. De nombreux frameworks qui prétendent faire la détection de racine ne détectent pas de nombreux périphériques enracinés et détectent certains normaux comme enracinés. Même si c'était le cas, le côté client de n'importe quelle application peut être facilement rétroconçu. Un attaquant motivé pourra accéder à votre interface principale en contournant complètement l'application côté client. Cela signifie que toutes les vérifications côté client peuvent être contournées et tout calcul gâché. Aucun contrôle ou calcul côté client ne peut être approuvé.
Il est possible de créer un client de confiance, mais cela nécessite du matériel, un système d'exploitation et des logiciels propriétaires. Les consoles de jeu et les réseaux câblés le font, mais souffrent toujours beaucoup du piratage, qui devrait constituer un bon exemple de la difficulté de protéger un appareil. Cette stratégie est théoriquement possible, mais échoue dans la pratique car elle est trop chère, vole et empêche les investissements sur la fonctionnalité du produit qui devient faible et obsolète face à sa concurrence.
Dans quelle mesure doit-il être sécurisé?
Une application sécurisée/sûre n'existe pas. La sécurité consiste à comprendre les risques, la probabilité et l'ampleur des pertes qu'elle peut causer et à identifier les éventualités et les stratégies d'atténuation pour maintenir une marge bénéficiaire saine. Les questions que vous devriez vous poser sont:
- que se passe-t-il lorsque la "détection racine" échoue?
- contre quels types d'attaques la "détection des racines" est-elle censée protéger?
- quelle est la probabilité que cela se produise?
- quels types de pertes une "détection de racine" peut-elle échouer?
- existe-t-il d'autres protections contre cela?
- est-il possible de détecter rapidement ce type de violations?
- est-il possible de déclencher des imprévus qui réduisent ou éliminent les pertes?
- l'entreprise sera-t-elle toujours rentable avec ces pertes?
Toute logique importante doit être côté serveur
Vous semblez gêné par la possibilité qu'un attaquant puisse installer votre application dans un environnement virtuel. Je soupçonne que la plupart des contrôles de sécurité et des calculs importants sont du côté client. Si c'est le cas, vous devez vraiment repenser votre application pour déplacer tous les contrôles côté serveur:
Les API d'interface principale exposées aux réseaux d'utilisateurs doivent exiger l'authentification de l'utilisateur.
Les API de l'interface principale doivent limiter ce que l'utilisateur peut voir et faire. Les limites d'accès doivent être imposées par le côté serveur, jamais par le côté client. À l'exception, bien sûr, des services qui n'incluent pas d'informations et de commandes sensibles;
Les API de l'interface principale doivent tenir compte de la possibilité d'attaques par force brute. Un attaquant peut télécharger d'énormes portions de votre base de données et deviner les mots de passe et les codes de confirmation faibles en les essayant tous.
Les API internes - celles utilisées par le back-end et non exposées aux réseaux d'utilisateurs - composent une couche de service interne qui doit utiliser des utilisateurs de service ou des certificats clients pour l'authentification. Les informations de l'utilisateur réel doivent être propagées à ces services à des fins de journalisation.
Je sais que c'est très décevant. Avec ces restrictions, les API de l'interface back-end doivent être très spécifiques aux workflows de l'application et donc moins réutilisables. Malheureusement, seules les API internes peuvent être réutilisables. Cela signifie également que les développeurs principaux devront comprendre très bien l'expérience utilisateur, les flux de travail conçus et travailler en étroite collaboration avec les équipes frontales, ce que la plupart des développeurs n'aiment pas ou sont prêts à faire.
Même avec toute la logique importante du serveur, il est nécessaire de concevoir les workflows pour tenir compte des autres risques
Si l'application suit les directives mentionnées ci-dessus, peu importe si l'application côté client est falsifiée sur l'appareil d'un attaquant. Il ne sera pas en mesure de faire autre chose que ce que les informations d'identification dont il dispose lui permettraient de le faire via l'application officielle côté client.
Mais si une véritable machine utilisateur est enracinée, les logiciels malveillants pourront:
- contourner la détection de périphérique enraciné;
- capturer les informations d'identification de l'utilisateur;
- rediriger l'utilisateur vers une fausse page;
- rediriger l'utilisateur vers une fausse application;
- contrôler à distance l'appareil;
Ces attaques ne sont pas très courantes. Celles-ci sont difficiles car obligent généralement l'utilisateur à effectuer des procédures compliquées. Mais si le produit est cher ou si les informations sont trop sensibles, ces attaques doivent être prises au sérieux.
Si votre préoccupation est due au fait que vos "vendeurs" traitent des produits coûteux dont les pertes sont importantes et difficilement récupérables, vous devez considérer des barrières secondaires telles que:
- validation du superviseur sur des opérations plus importantes;
- valider l'adresse de livraison avec plusieurs bases de données externes;
- améliorer le suivi des livraisons;
- imposer des contraintes de temps sur les livraisons en fonction du risque.
Si cela ne suffit toujours pas, vous pouvez choisir de fournir un appareil appartenant à l'entreprise qui est verrouillé pour empêcher l'installation d'applications externes et que l'USB n'est verrouillé que pour charger. Je connais tout le temps quelques personnes qui se promènent avec trois téléphones d'entreprise de différentes sociétés: c'est toujours une chose.
Développer de bons journaux et les surveiller
La surveillance est également une bonne stratégie pour éviter de nombreuses pertes. Le retour en arrière des pertes sur les journaux permet de mieux comprendre comment elles se produisent et ce qui a échoué, de proposer des modifications aux produits ou au moins de surveiller ces situations pour obtenir des alertes précoces de situations similaires à l'avenir.
Si les journaux sont suffisamment détaillés, il existe des techniques de biométrie comportementale qui sont faciles à mettre en œuvre et peuvent détecter de nombreux types d'intrusions et certains types d'erreurs opérationnelles suffisamment tôt pour éviter les pertes.
Vous avez une version bureau?
Lorsque vous avez dit "Nous avons une version mobile du produit", cela ressemblait à une autre. Avez-vous une version de bureau? Les systèmes d'exploitation de bureau sont enracinés par défaut et il n'y a pas d'isolement d'application. Si vous pouvez vivre avec une version de bureau, vous n'avez probablement même pas besoin de la détection de racine en premier lieu.
C'est une bonne chose d'améliorer continuellement la sécurité, et vous devriez le faire, mais vous pouvez vous attendre à ce que la version mobile soit plus sûre que celle de bureau, sauf si vous faites une horrible erreur dans le nouveau développement.