Comment sécuriser une application mobile contre son utilisateur?

ThoriumBR

2020-06-08 18:18:01 UTC

view on stackexchange narkive permalink

Vous ne pouvez pas.

Dès que l'utilisateur dispose de l'appareil mobile et de votre application, rien ne l'empêche de décompiler votre application, de comprendre son fonctionnement & quelles données il envoie, et de la répliquer. Ils peuvent même tricher en utilisant un engin qui fait tourner le téléphone et faire croire à votre application que c'est un humain qui l'utilise.

Ils n'ont même pas besoin de décompiler votre application; il leur suffit de mettre un proxy pour intercepter les requêtes et comprendre le protocole.

D'après les commentaires:

Si vous contrôlez le matériel, vous pouvez sécuriser l'application:

Pas tout à fait. Les contrôles Apple du processeur à l'interface utilisateur de l'iPhone, et les jailbreaks sont une chose. Même s'ils en contrôlent tous les aspects, un jour, quelqu'un jailbreaker et rooter l'iPhone, et charger votre application dessus.

Transparence des certificats, épinglage de clés

Pas utile si le périphérique est rooté. La somme de contrôle, la signature numérique et la vérification de l'intégrité ne fonctionnent que si le système d'exploitation n'est pas compromis. Si l'utilisateur possède le système d'exploitation et l'appareil, il peut désactiver les vérifications du système d'exploitation, modifier le binaire de l'application et modifier les instructions vérifiant la signature ou la somme de contrôle.

Machine virtuelle, obfuscation du code

Ils rendent l'analyse du code beaucoup plus difficile, mais le code doit être exécuté par le processeur. Si un désassembleur ne peut pas aider, un débogueur le fera. L'utilisateur peut mettre des points d'arrêt sur des parties clés du code et atteindra avec le temps la fonction de vérification du certificat, ou la somme de contrôle, ou tout contrôle de validation en place, et peut modifier tout ce qu'il veut.

Il est donc inutile d'essayer?

Non. Vous devez peser les coûts et les avantages. Seulement, ne comptez pas sur les défenses pour être imbattables, car chaque défense peut être battue. Vous ne pouvez rendre les choses si difficiles que l'attaquant renonce à mettre beaucoup de ressources contre votre application et à bénéficier d'un petit avantage.

fondamentalement, vous avez raison.mais dans une approche pratique, vous pouvez faire plusieurs choses pour augmenter la difficulté de jouer avec l'application.

vous pouvez rendre de plus en plus difficile, mais vous ne pouvez protéger aucune application contre le piratage.Pokemon Go est un bon exemple: il utilisait les capteurs du téléphone, avait une entreprise avec beaucoup d'expérience et d'argent, et l'application a quand même été piratée.

J'ai commencé par dire que vous avez raison.Et tu es.Mais il est toujours utile de rendre les choses plus difficiles même si impossible n'est pas une option.

Correct!Mais dès que la récompense pour avoir cassé le système est plus grande que le coût, elle sera cassée.Parfois, il sera cassé "juste pour le plaisir", c'est pourquoi essayer de protéger un système côté client ne fonctionnera généralement pas.

Aussi tout à fait vrai.L'impact sur une entreprise est cependant assez variable avec le niveau de protection en place.De l'absence de protection à une difficulté incroyable, il y a un large éventail de pertes potentielles de revenus (et donc de motivation à mettre en œuvre la sécurité).

Vous ne pouvez pas intercepter le trafic d'une application si elle suit les principes de sécurité de base, comme la transparence des certificats, entre autres.

@CONvid19 S'il s'exécute sur du matériel que vous contrôlez, vous pouvez le faire, même s'il respecte les principes de sécurité.

@ThoriumBR: Eh bien, vous pouvez, si vous contrôlez le matériel.Prenez Apple Inc, qui peut contrôler ce que les gens exécutent sur IPhones via la signature de code.Cependant, cela nécessite du matériel dédié et beaucoup de planification - et peut toujours être interrompu.

@JosephSible-ReinstateMonica Même Apple ne peut pas tout contrôler tout le temps, et les jailbreaks sont là pour le prouver.Sony a fait du bon travail avec la PS3 et a mis environ 4 ans à la sécurité pour être vaincue, mais elle a également été vaincue.

@CONvid19 Rien n'empêche l'utilisateur de changer un `JNZ` en` JZ` sur le code, et de continuer lorsque le certificat ne correspond pas.Ou éditer le binaire et épingler son propre certificat.Ou `NOP` toute la fonction de vérification.La sécurité côté client échouera toujours avec suffisamment de temps et de motivation.

@ThoriumBR Je voulais dire «contrôler» comme «avoir la possession physique de».

@JosephSible-ReinstateMonica dans ce cas, c'est possible.Mais dans le cas d'OP, il ne serait pas très utile que l'utilisateur ne dispose pas de l'appareil qui enregistrera ses propres mouvements ...

@ThoriumBR Oui, c'est mon point.Je suis d'accord avec votre réponse.

Je suppose que la question est la suivante: quand il est piraté une fois, est-il largement ouvert à tout le monde via le partage d'informations, ou chaque utilisateur devrait-il le pirater lui-même?Dans ce dernier cas, j'imagine que cela en vaut toujours la peine, alors que dans le premier cas, ce n'est peut-être pas le cas?

@bob piraté une fois, piraté pour toujours jusqu'à ce que vous publiiez une nouvelle version qui bouche le trou, ou changez le protocole, ou toute autre contre-mesure.Il est difficile de garder des secrets maintenant.

@ThoriumBR alors oui, dans ce cas, il semble que cela ne vaut pas la peine d'essayer de prévenir.

MechMK1

2020-06-08 18:40:27 UTC

view on stackexchange narkive permalink

Bien que je sois généralement d'accord avec la réponse de ThoriumBR, il y a certaines choses que vous pouvez faire.

Par exemple, vous pouvez analyser le comportement de l'utilisateur pour des écarts, tels que:

Données manifestement relues

Par exemple, un utilisateur peut agir de la manière souhaitée, puis capturer le envoyé des données et relire les données ultérieurement. Cela peut être déterminé assez facilement, étant donné que les données du capteur bruyant se trouvent être exactement les mêmes, ce qui ne se produirait jamais dans un cas d'utilisation réel.
De toute évidence fausse Données

Par exemple, un utilisateur peut signaler de fausses données de capteur. Ces données ne seraient probablement pas suffisamment aléatoires. Par exemple, au lieu de signaler un emplacement de 48,7849165 ° N; 27,4159014 ° W , le point de données falsifié pourrait être 48,78 ° N; 27,42 ° W .
Modèles de type machine

Par exemple, un utilisateur pourrait écrire un programme qui envoie automatiquement du bruit et "correct -à la recherche de "données toujours à la même heure de la journée. Cela semble suspect, car fondamentalement aucun utilisateur ne serait aussi précis.

Bien sûr, vous ne pouvez pas voir ces exemples comme une liste exhaustive. Il n'y a là que des exemples du type de modèles que vous pouvez détecter. Entraîner votre système à détecter les anomalies est beaucoup plus difficile en pratique, et sera probablement plus difficile à mettre en œuvre que de simplement vivre avec le fait que certaines personnes tricheront.

Étant donné que la question a été modifiée après la publication de la réponse: vous pouvez effectuer une analyse plus approfondie de l'ensemble de données des gagnants pour voir si des irrégularités se produisent. De cette façon, vous n'auriez à effectuer une analyse que sur des ensembles de données qui comptent réellement pour vous en tant qu'entreprise.

Comme Falco l'a mentionné dans les commentaires, en ajoutant une clause de non-responsabilité telle que "Vos soumissions seront analysées pour éviter la triche "peut empêcher certaines personnes d'envoyer de fausses soumissions.

Comment pourriez-vous attraper des attaques de relecture sans enregistrer, sauvegarder et rechercher les données brutes?Cela semble assez peu pratique.

@jpaugh c'est exactement ce que nous faisons pour notre application - c'est juste beaucoup de données, ce n'est pas tout à fait impossible et une fois que vous obtenez un modèle sur l'apparence des données "réelles", vous pouvez repérer les "fausses" données basées sur le modèle et supprimer davantage de données.les données de sauvegarde.

@jpaugh C'est une tâche difficile et nécessitera beaucoup de données enregistrées.Je ne veux pas non plus prétendre que l'analyse des anomalies est la solution ultime, car elle nécessite une tonne de données et d'analyses, et sera probablement trop importante pour que la plupart des petites entreprises essaient de le faire.publiez une ou deux applications.

Vous pouvez voir les avantages et les risques de détecter et d'agir sur ces écarts dans le jeu, où la triche, ainsi que sa détection et sa prévention, n'est pas rare.Il existe des tableaux de scores élevés avec des scores clairement incroyablement élevés (par exemple, terminer un niveau en 0,0001 secondes) et il y a des cas où certains joueurs sont interdits pour simplement jouer au jeu normalement.

Je pense que vous sous-estimez les problèmes de la vie réelle avec différents matériels.Des données "trop exactes"?Vous ne savez pas ce que peut faire le micrologiciel de certains téléphones que vous n'avez jamais utilisés.Ce n'est même pas si stupide de débruiter des données de localisation inexactes, car pourquoi les applications devraient-elles compter sur la cinquième place après la virgule, alors que la lecture du capteur n'est précise qu'à deux endroits?

L'OP a un cas particulier, où il n'y a qu'un (ou quelques) gagnants et ils seront physiquement présents et pourraient être poursuivis pour tricherie.- Si vous enregistrez les données sur l'appareil et les téléchargez périodiquement sur le cloud, il vous suffit de vérifier l'exactitude des données, une fois qu'une personne prétend être gagnante et signe le formulaire "Je promets que je n'ai pas triché et si jeai-je dû à la société 1000 $ de dommages-intérêts "lors de la collecte de leur prix et après cela, vérifiez ses données.- La plupart des gens n'essaieront pas de tricher, s'il y a un risque réel d'être pris après coup.

@Falco Toutes ces informations ont été ajoutées après la rédaction de cette réponse

@MechMK1 Je pense que cette réponse pourrait être améliorée, en ajoutant un petit paragraphe à la fin.Puisque la solution que vous proposez semble idéale pour la situation des PO, puisque l'analyse ne doit pas être faite sur toutes les données, mais uniquement sur les ensembles de données des gagnants - et même simplement divulguer les informations «vos données seront analysées pour éviter la triche» devrait interdirela plupart des tricheurs

DennisFrett

2020-06-09 11:55:50 UTC

view on stackexchange narkive permalink

Bien que je sois d'accord avec les autres réponses, je trouve qu'il y a quelques éléments pragmatiques qui sont négligés ici.

Divulgation complète: je travaille pour une entreprise qui développe des logiciels d'obscurcissement / protection pour les applications mobiles.

Une protection complète et incassable n'est pas possible pour une application exécutée sur un appareil contrôlé par un attaquant. Cependant, il existe un logiciel qui vise à élever la barre et rend moins / pas utile pour une personne de mener une attaque.

En général, ces solutions couvrent deux aspects

Statique protection

Cela inclut généralement un tas de techniques d'obscurcissement visant à rendre la tâche difficile pour un attaquant qui veut analyser une application mobile en examinant les binaires à l'aide d'outils comme IDA Pro, Ghidra et Hopper.

Les techniques ici sont l'obscurcissement du flux de contrôle, l'obscurcissement sémantique (classe, méthode, ... noms), l'obscurcissement arithmétique, le chiffrement de chaînes, le chiffrement de classe, ...

Cela en fait très difficile de «jeter un œil» à l'intérieur d'un binaire et de comprendre ce qui se passe, mais n'offre pas beaucoup de protection lorsqu'un attaquant regarde l'application alors qu'elle s'exécute sur l'appareil lui-même.

Protection dynamique

Ces techniques de protection visent à protéger une application contre toute analyse ou modification lorsqu'elle s'exécute sur l'appareil. Les outils populaires ici sont les débogueurs (lldb, gdb, ...) et les frameworks d'accrochage (Frida, Cydia Substrate, ...).

Les techniques ici essaieront de bloquer / détecter l'utilisation de ces outils, de détecter les environnements d'exécution falsifiés (appareil jailbreaké / rooté, émulateurs), les modifications apportées à l'application et bien plus encore.

Conclusion

Bien qu'il soit de la plus haute importance de s'assurer que votre application a été créée en utilisant des pratiques de sécurité bien définies (les logiciels d'obscurcissement / protection ne vous aideront pas ici!), il existe des outils qui peuvent fonctionner comme un ensemble de shells autour de votre application qui, ensemble, rendent beaucoup plus difficile et, espérons-le, inutile, de casser votre application.

Vous pouvez également créer une machine virtuelle dans l'application, pour y effectuer des opérations critiques, ce qui offre une certaine protection contre les attaques statiques et dynamiques.

Je trouve triste que la sécurité par l'obscurité soit une chose si importante ... Non pas qu'elle ne soit pas utile.J'aimerais juste qu'il y ait une solution plus ... * robuste * pour empêcher l'utilisateur de faire quoi que ce soit avec votre code. Je suppose que j'aurais dû être un ingénieur civil plutôt qu'un logiciel.Les passants ne sont pas trop susceptibles de déchirer un pont juste pour éviter d'avoir à payer le péage :-(

@Mathieu VIALES, il y a des changements en cours d'implémentation sur ce front également.Vous pouvez jeter un œil à Intel SGX, ARM TrustZone, qui sont des implémentations matérielles.Je connais également des idées académiques basées sur l'hyperviseur qui tentent de fournir une sécurité significative sur les appareils infectés par des logiciels malveillants.Pas une solution complète bien sûr contre un appareil contrôlé par un attaquant, mais cela donne des garanties supplémentaires.

@DennisFrett Cela semble assez intéressant!Je vais m'assurer de rechercher SGX et zone de confiance.Cela semble assez prometteur. en ce qui concerne les périphériques contrôleurs attaquants, je suppose qu'il n'y aura jamais de solution réelle tant que le code sous quelque forme que ce soit est toujours présent sur les périphériques de l'attaquant:

Nitpick, mais: Comment passer de "l'appareil de l'utilisateur final" à "contrôlé par l'attaquant"?L'audit d'un logiciel et le dépannage / sandboxing sont des pratiques légitimes, bien que souvent fastidieuses.Dans mon livre, interférer avec des applications indépendantes sur la machine de l'utilisateur ferait de vous l'attaquant.

Je ne suis pas d'accord avec le sentiment que tout ce travail pour peu de profit est une mauvaise chose.Il est idiot de devoir installer un logiciel de source fermée au niveau du noyau pour vous assurer de ne pas tricher dans un jeu vidéo.Je préfère avoir affaire à des tricheurs plutôt qu'à des logiciels malveillants.

@MathieuVIALES le pont n'est pas non plus la propriété des passants, le téléphone l'est.Donc, ce sont surtout leurs affaires qu'ils tempèrent - et bien qu'il y ait des arguments en faveur de contrats déterminant comment un logiciel peut être utilisé (par exemple, ne pas pirater une autre machine sans le consentement de ce propriétaire, etc.), de nombreux modèles commerciaux / entreprises essaient beaucoup trop fort.pour contrôler la façon dont leur logiciel est utilisé sur les appareils d'autres personnes.Ce serait ridicule si quelqu'un essayait de s'assurer que vous ne pouvez pas utiliser un tournevis à fente pour les vis philipps.

@MathieuVIALES Y a-t-il une zone grise entre les deux?Bien sûr, mais l'allégorie du pont vient d'un point de vue extrême, c'est peut-être votre code mais c'est leur appareil et ils ont licencié votre code par-dessus, donc dans mon livre, ils possèdent comme trois quarts de dire quoi faire avec la combinaison detous les deux.

8vtwo

2020-06-09 01:35:40 UTC

view on stackexchange narkive permalink

C'est quelque peu possible.

Envoyez simplement les données enregistrées à un serveur distant qui vérifie le modèle. Assurez-vous qu'il y a un délai entre l'observation d'un modèle correct et la récompense. Il sera très difficile de déterminer exactement quel modèle correspond.

Si vous combinez cela avec des heuristiques qui détectent les activités répétées et bannissent les contrevenants, il y a de fortes chances que vous puissiez maintenir ce type de modèle.

Cela suppose que l'utilisateur ne peut rien savoir sur le modèle, par exemplequelle activité est censée la provoquer, et peu de chances de s'en approcher.Lorsque vous travaillez avec des données de capteur réelles, il est probable qu'une légère modification aléatoire des données enregistrées ait de bonnes chances de tomber dans les paramètres acceptables de votre modèle.

Ils peuvent savoir ce qu'est * une partie * du modèle, mais pas la totalité.Par exemple, si le modèle lance simplement le téléphone dans les airs: en envoyant tout le flux de données à distance, vous pouvez également vérifier les données avant et après l'événement connu.Tels que la «liquidation» et la «prise».Ensuite, vous pouvez vérifier que toutes ces choses correspondent correctement et sont uniques à chaque fois.

Cela ne m'empêche pas, par exemple, d'enregistrer dix lancers, d'attendre aussi longtemps la réponse, de déformer légèrement l'ensemble de données, de le découper entre les lancers puis de le renvoyer dans un ordre aléatoire.Après tout, les lectures de l'accéléromètre ne sont pas un bruit blanc aléatoire.Quelle que soit la configuration que vous attendez, elle dépend de la physique de l'activité que vous souhaitez détecter et de la précision des mesures.Et vous ne pouvez pas non plus facilement mettre les utilisateurs sur une liste noire, car vous obtiendrez des lectures non correspondantes tout le temps.

Je pense que vous sous-estimez la difficulté de déformer * précisément * l'ensemble de données et de rejouer un ensemble de données entièrement nouveau qui correspond correctement au comportement d'un utilisateur normal.L'utilisation de la correspondance de modèles côté serveur vous donne une énorme quantité de données que vous pouvez analyser.Tout ce qui se passe de l'ouverture de l'application au modèle cible peut être examiné.Les algorithmes d'apprentissage automatique sont très efficaces pour faire la distinction entre les modèles uniques réels et ceux qui présentent tout type d'anomalies.Les points auxquels vous "coupez" les lancers sembleraient suspects si la transition n'était pas douce.

@RutherRendommeleigh à l'appui de cette réponse, consultez les techniques qu'Uber utilise pour empêcher l'usurpation GPS ici https://eng.uber.com/advanced-technologies-detecting-preventing-fraud-uber/ C'est une solution couramment adoptée dans l'industrie.Ce n'est pas infaillible, évidemment.

@goncalopp Je dirais que les types et la quantité de données collectées par Uber, ainsi que les ressources qu'ils peuvent utiliser pour résoudre le problème, sont probablement hors de portée du scénario d'OP.S'ils * ont * besoin de données de localisation constantes et que l'application est suffisamment complexe pour produire des modèles d'utilisation distincts, c'est juste.D'un autre côté, vous perdez des utilisateurs qui ne consentent pas à la surveillance 24/7.

goncalopp

2020-06-10 11:57:24 UTC

view on stackexchange narkive permalink

Plus fréquemment ces dernières années, la solution sécurisée suggérée à ce problème est appelée attestation à distance.

En bref, cela signifie exécuter les parties critiques de sécurité de votre application dans une zone distincte du processeur qui garantit son intégrité (via le dépôt de clé sur le matériel) et permet à un serveur distant de le confirmer.

À ma connaissance, il n'y a pas un moyen pratique et infaillible de le faire pour une application mobile développée indépendamment à partir de 2020. Mais des API existent déjà pour vérifier que le système n'a pas été falsifié et que de plus en plus de téléphones incluent des TPM / TEEs, je pense qu'il est raisonnable de s'attendre à ce qu'il soit généralement disponible dans un proche avenir. Il est actuellement utilisé dans Google Pay, par exemple.

Mises en garde importantes:

Cela empêche votre application de s'exécuter sur des téléphones contrôlés (" possédé "?) par l'utilisateur final (c'est-à-dire: téléphones rootés / jailbreakés). Cela peut être considéré comme une forme de DRM et est controversé (voir la controverse relative au démarrage sécurisé sur les PC)
Vous devrez étendre votre TCB pour inclure les fabricants de processeurs et le fournisseur du système d'exploitation.

Les gens ont une grande variété d'opinions concernant ces mises en garde, les deux extrêmes étant "hors de propos en pratique" pour " rendre la technologie pire qu'inutile ".

Ceci est copié de ma propre réponse ici

Peu importe où le logiciel s'exécute, il obtient toujours des données quelque part.Configurez un faux capteur de mouvement / compteur de pas et votre programme traitera et soumettra de fausses données en toute sécurité.

Eric Johnson

2020-06-10 22:25:47 UTC

view on stackexchange narkive permalink

D'autres ont répondu concernant les protections logicielles, mais une attaque peut se produire même au niveau matériel.

Par exemple, si un téléphone a un accéléromètre IC qui se trouve sur le PCBA, la plupart de ces capteurs transmettraient sur un bus SPI ou I2C standard avec les données brutes et aucune sorte de cryptage. Il est possible qu'un attaquant supprime le capteur existant et envoie de fausses données sur le bus de données. Il serait impossible pour le logiciel du téléphone de détecter toute modification du mode de fonctionnement normal car aucune modification n'a été apportée au logiciel. Ainsi, il serait impossible d'empêcher un attaquant motivé.

Maintenant, certaines atténuations pourraient exister, comme détecter si l'appareil a été entré ou utiliser un capteur qui crypterait la communication / authentifierait le CI comme authentique, mais étant donné que un téléphone portable est un produit de base (au moins pour Android), il serait possible de trouver un téléphone qui ne le fait pas.

Daniël van den Berg

2020-06-11 11:44:12 UTC

view on stackexchange narkive permalink

En plus de toutes les autres réponses mentionnées, un moyen "simple" de se protéger contre le piratage consiste simplement à ne pas avoir la logique à l'intérieur de votre application.

Dans l'application, vous ne voulez faire que deux choses.

Lire les données
Afficher les données

Au moment où vous essayez de traiter des données sur l'appareil, vous êtes condamné et l'application sera piratée. Au lieu de cela, envoyez toutes les données brutes à un serveur (évidemment, cela comporte ses propres risques de sécurité, mais ceux-ci sont plus faciles à atténuer). Sur ce serveur, vous pouvez effectuer tout le traitement des données en toute sécurité, car c'est sous votre contrôle.

Un autre avantage de cette approche est qu'elle facilite la détection des utilisateurs malveillants. Vous mentionnez que cette application doit être utilisée pour un concours. Sur votre serveur, vous pouvez, à la fin de la compétition, comparer simplement les données de mouvement aux données d'autres utilisateurs. Si tous les utilisateurs affichent un modèle avec, disons 8 heures de sommeil, et qu'un utilisateur montre un modèle qui les obligerait à être éveillés 24 heures sur 24, 7 jours sur 7, vous savez que c'est truqué. Mais sur cet aspect, MechMK1 a déjà donné une excellente réponse, juste que maintenant vous pouvez aussi combiner plusieurs utilisateurs.