Je lisais le débordement de la pile pendant un certain temps, mais c'est ma première question postée.
J'ai ce programme de suivi écrit en C # qui collecte des informations sur l'utilisation de l'ordinateur local et les envoie à un serveur. Les données sont formatées XML, envoyées une fois par 10 minutes.
Mon problème: peu importe la façon dont je chiffre les données XML (que ce soit symétrique ou asymétrique), une personne pourrait toujours décompiler mon programme de suivi C #, comprendre les conventitions de clé / certificat / cryptage que j'utilise et écrivez un autre programme qui envoie de faux rapports. au serveur.
Le programme de suivi fonctionne sous l'hypothèse que l'utilisateur exécutant peut être intéressé par l'envoi de fausses rapports.
Questions: 1) Comment puis-je vous assurer (le plus possible possible) que les données sont envoyées du vrai tracker au lieu d'un clone / faner? 2) Comment puis-je vis-je suffisamment le code que la récupération des clés / certificats / conventions de cryptage devient l'enfer / à côté impossible?
Je veux dépenser peu ou de préférence pas d'argent sur la solution (SO 500 $ Obfuscators sont hors de question. Je suis un étudiant universitaire et je suis bon marché :)
Merci d'avance.
6 Réponses :
1.Auzer approche: En supposant que vous ne changez pas souvent votre exécutable. Faites un digsig de votre image de fichier exécutable de votre client et envoyez-la avec, qui authentifieriez votre client en tant que véritable client et non une version modifiée.
Mais cela ne peut pas empêcher les données envoyées par un client totalement différent, qui peut acquérir la digsig de votre image exécutable.
Diffie-Hellman ajoute très peu de valeur supplémentaire sans une tierce partie. Assez facile à mitm si tout ce dont vous avez besoin est sur la machine.
@erickson ouais. C'était stupide. Pour le scénario de l'OP, peu importe si son symétrique / asymétrique.
En théorie, une application ne peut tout simplement pas se protéger lorsqu'elle est exécutée dans un environnement non approuvé. Donc, la réponse à la première question est: «Vous ne pouvez jamais être sûr que les données sont envoyées par le vrai tracker."
En pratique, l'obfuscation contrecarrera des attaquants jusqu'à un point. Le point est déterminé par la qualité de l'obfuscation et la motivation de l'attaquant. Ainsi, la réponse à la deuxième question dépend de l'adresseur de l'attaquant, à quel point ils sont capables et quelles ressources ils pourraient s'appliquer à ce problème. Obfuscation qui est "enfer / presque impossible" pour un profane non motivé à démêler peut être trivial pour un expert ou une personne capable de louer un expert.
Voici une liste de certains obfuscateurs C #.
Découvrez le réflecteur .NET, l'un des meilleurs décompileurs que j'ai jamais vus (et c'est gratuit)
L'utilisateur client sera-t-il des droits d'administrateur sur la machine? Cela ressemble au type d'application qui serait installé par un administrateur, mais utilisé par les utilisateurs non administratifs. Si tel est le cas, vous pourriez peut-être stocker votre clé ou votre hachage protégé des utilisateurs normaux et exécuter l'application dans le contexte de l'utilisateur de l'administrateur. Je ne connais pas vraiment le magasin clé, mais je m'attendrais à ce que toutes les versions de Windows (au moins XP +) disposeraient de cette fonctionnalité disponible. Si ce n'est pas le magasin de clés, alors peut-être un fichier situé dans un répertoire crypté appartenant à l'utilisateur administrateur.
Si votre utilisateur cible a des droits d'administration locaux, je ne vois vraiment pas comment vous pouvez les arrêter.
"Exécutez l'application dans le contexte de l'administrateur". Ce serait un trou de sécurité potentiel.
Que diriez-vous de simplement dans le contexte d'un autre utilisateur non administrateur?
Cela semble assez désespéré. Votre tracker s'appuie probablement sur Windows pour fournir les métriques, telles que en appelant en fin de compte Getansername () / gettickcount () / CollectionformanceData () / etc. Donc, un mauvais gars doit juste piéger votre code (peu importe la manière dont il est obscurcissé, et sans déranger de décompiler) à n'importe quel article d'entrée de l'intérêt de Windows, remplacez les fausses données et laissez votre code continuer sur sa voie joyeuse.
La vie est trop courte pour battre la tête contre ces types de murs de briques.
Nous utilisons une solution matérielle pour fournir cette fonctionnalité requise.
Je travaille avec un produit appelé Ironkey, il s'agit d'un dispositif matériel capable de générer des signatures numériques. Lorsque nous émettons l'appareil, nous stockons la clé publique sur notre serveur. Lorsque notre candidature client soumet des données, nous générons une signature à l'aide de la clé privée, une fois que nous avons reçu les données, nous pouvons vérifier qu'il a été envoyé du client correct à l'aide de la clé publique.
Cela prouve que le rapport a été envoyé d'une boîte avec le dongle, mais cela ne garantit pas que les données n'étaient pas faillées par des logiciels modifiés fonctionnant sur la case.
Les données sont signées par l'appareil, le client envoie les données et la signature au serveur, le serveur vérifie la signature par rapport aux données et la signature à l'aide de la clé publique stockée. Si la vérification échoue, nous savons que les données ont été simulées, soit qu'ils utilisent la mauvaise clé privée. L'Ironkey n'est pas simplement un dongle, il fournit une signature et une vérification matérielles via PKCS11.
Il générant des données de manière programmatique toutes les 10 minutes. La signature des données ne garantit pas son programme n'a pas été compromise.
@Joe: Il doit y avoir une certaine confirmation humaine que les données qu'ils voient sont les données signées. Je conviens que les données peuvent être changées où il est stocké
comme Raph Koster a une fois mis le , écrit sur la bataille contre les pirates informatiques Dans les jeux en ligne client-serveur,
Ne faites jamais confiance au client. Ne jamais rien mettre sur le client. Le client est entre les mains de l'ennemi. Jamais jamais jamais oublié ça.
Malheureusement, pour toute une demande du monde réel qui exige que la puissance de traitement du client soit utilisée, quelque chose doit être mise sur le client, et donc parce que disponible pour un attaquant malveillant. La question qui doit être posée - comme pour toute mesure de sécurité - est combien de temps et d'argent êtes-vous prêt à dépenser de l'atténuation de ce risque?
Certaines personnes aiment souligner les personnes qui demandent des mécanismes de licence d'obscusation ou de licence côté client, "Oh, il ne sera pas fait de point, il sera fini par". Mais il faut rater le point: que l'objectif de ces mesures est de pousser cela "finalement" plus loin dans le futur, au point que pour un attaquant insuffisamment déterminé, ce sera "jamais".
Par exemple: Si votre application a envoyé ses données par courrier électronique en clair, qui vaincre environ zéro attaquants. L'envoyer en ROT13 Email vaincre peut-être 5% des attaquants. L'envoyer crypté à l'aide du nom d'utilisateur comme une clé vaincre plus. Obfusquant le code d'envoi avec un Obfuscator gratuit vaincre plus. Obgfusquer avec un obfuscateur de qualité commerciale vaincre plus. Obliger chaque client à avoir un dongle matériel vaincre «tous les attaquants les moins déterminés», comme les gens aiment dire - mais ce serait probablement un coût intolérable.
de "Je suis un étudiant universitaire" Je suppose que ce n'est pas le projet le plus sensible jamais. Utilisez un Obfuscator gratuit et CNRYPT les données envoyées à l'aide de certaines informations spécifiques à l'utilisateur comme clé. Ça va probablement faire.
Réponse courte: vous ne pouvez pas. Les éditeurs de logiciels mettent une durée et des efforts extraordinaires pour tenter quelque chose de similaire, et il est invariablement brisé dans les heures devenant disponibles.
Personnellement, je ne voudrais pas y dépenser d'argent, car même les solutions coûteuses sont facilement brisées si une personne est déterminée à donner de fausses données. Vous ne pouvez jamais «s'assurer» que les données sont valides, n'essayez que de dissuader les personnes de la tentative.