Les vidages sur incident (par exemple depuis Breakpad, Windows) doivent-ils être chiffrés et signés?
En tant que développeur de logiciels, mes vidages sur incident (par exemple à partir de Breakpad, Windows) doivent-ils être chiffrés et signés? J'offre la possibilité d'exporter des vidages sur incident afin de pouvoir identifier le problème lorsque l'utilisateur en signale un.
Mes préoccupations, en termes de protection de mon produit (l'attaquant est un utilisateur piratant le produit pour gagner quelque chose):
- Les vidages donnent trop d'informations aux pirates pour effectuer une rétro-ingénierie ou pirater le logiciel, par exemple pour activer des fonctionnalités ou des licences?
- Les mots de passe et les clés peuvent être stockés dans les vidages pour que les pirates puissent pirater le logiciel.
- Un utilisateur pourrait nous renvoyer un vidage malformé, ce qui provoque des ravages lorsque nous essayons de déchiffrer le vidage sur nos machines. Si notre application signe le vidage, nous pouvons au moins ouvrir le fichier en toute confiance.
Mise à jour: Pour le dernier point, une des réponses m'a rappelé qu'il n'y a aucun point à signer les données, car la clé doit être dans le produit lui-même, que le pirate peut ensuite utiliser à signer quand même. De plus, la crainte de vidages malveillants peut être contournée par l'utilisation de machines virtuelles temporaires.
La dernière préoccupation restante est de savoir comment les vidages, étant donné qu'ils contiennent des adresses et d'autres éléments, pourraient aider les pirates à contourner les restrictions telles que les fonctionnalités sous licence.
Les décharges donnent trop d'informations aux pirates pour effectuer une rétro-ingénierie ou pirater le logiciel, par exemple pour activer des fonctionnalités ou des licences?
Les vidages doivent, à un moment donné, exister sous forme non chiffrée. Un attaquant disposant d'un contrôle local total peut soit récupérer les clichés à cet instant, soit simplement les ignorer et consulter à volonté la mémoire de l'application en cours d'exécution.
Certains programmes, tels que Spotify, essaient de détecter s'ils s'exécutent dans un environnement de débogage et utilisent divers schémas d'obscurcissement pour ralentir l'ingénierie inverse. Cela peut contrecarrer les attaquants non expérimentés ou ralentir les attaquants expérimentés. Mais cela n'arrêtera probablement pas un attaquant. C'est essentiellement la raison pour laquelle des entreprises comme Microsoft optent pour la validation de licence en ligne.
Cependant, le chiffrement en transit est une tout autre affaire. La protection des actifs des clients qui peuvent être disponibles dans un vidage, ou même des licences installées sur un ordinateur client, en fait une bonne proposition - garantissant qu'aucun tiers ne peut accéder au vidage.
Il est également facile à mettre en œuvre; soumettre le vidage par exemple https. Bien que le gain de cela puisse être faible, selon le contenu des vidages, il est également très bon marché à mettre en œuvre et réduit les risques pour les vôtres et les données des clients. N'oubliez pas que votre client apprécie probablement ses données plus qu'il n'apprécie votre produit.
Un utilisateur pourrait nous renvoyer un vidage malformé, ce qui provoque des ravages lorsque nous essayons de déchiffrer le vidage sur nos machines. Si notre application signe le vidage, nous pouvons au moins ouvrir le fichier en toute confiance.
Pour signer les fichiers, l'application a pour accéder à une clé privée. La clé privée doit être présente en mémoire sur la machine effectuant la signature à un moment donné. Il doit être distribué avec chaque instance du logiciel.
Un attaquant peut accéder à la clé et signer son fichier de vidage malveillant.
Cela n'aidera pas à utiliser les décharges comme vecteur d'attaque.
[...] mes vidages sur incident [...] doivent-ils être chiffrés et signés?
Quelqu'un peut créer n'importe quel nombre de vidages sur incident avec divers outils comme le Gestionnaire des tâches, l'Explorateur de processus, ProcDump, WinDbg, Visual Studio, DebugDiag, WER, AdPlus (et potentiellement plus) et vous n'avez aucune chance de les intercepter. Un attaquant n'utiliserait pas votre vidage sur incident Breakpad chiffré mais créerait ses propres vidages sur incident réguliers à la place.
Cependant, vous devez vous assurer de respecter les règles de confidentialité et vous assurer que seul le personnel autorisé peut accéder aux vidages sur incident. Dans ce cas, le cryptage peut aider, mais tout autre contrôle d'accès est également correct.
Les décharges donnent trop d'informations aux pirates pour effectuer une rétro-ingénierie ou pirater le logiciel, par exemple pour activer des fonctionnalités ou des licences?
Une instance en direct de l'application donne encore plus d'informations. Pensez comme ceci: vous pouvez créer de nombreux vidages sur incident, vous avez donc plus d'informations à analyser.
Aussi: saviez-vous que vous pouvez influencer la taille du vidage sur incident? Selon les options MINIDUMP_TYPE , le vidage sur incident contient plus ou moins d'informations.
Un utilisateur pourrait nous renvoyer un vidage malformé, ce qui provoque des ravages lorsque nous essayons de déchiffrer le vidage sur nos machines.
Bien sûr, mais peu probable. Ce serait un bogue lié à la sécurité dans le débogueur autant que possible dans toute autre application. Le débogueur va simplement lire les informations du vidage sur incident, pas l'exécuter.
Comment l'attaquant vous envoie-t-il un vidage sur incident sans s'identifier?
Mon opinion personnelle est que cela dépendra du rapport coût/bénéfice pour vous.
Signe numérique des fichiers oui. Cela réduira le travail et vous permettra de recevoir des décharges de vos vrais clients. Pour le transport d'informations oui. Vous devez utiliser un canal crypté et si ce n'est pas possible, crypter les données. je crois qu'il est plus facile de le livrer en utilisant https par exemple au lieu d'essayer de mettre en œuvre une méthode de cryptage sur les données qui peuvent échouer.
Localement, cela dépendra du paysage.
Normalement, les vidages ne devraient pas être autorisés par défaut et ne devraient être activés que pour le dépannage de problèmes spécifiques sur les serveurs de production.
Lorsqu'il est activé, il est conseillé de configurer une partition spécifique pour les vidages et pour que cette partition soit autorisée à accéder aux utilisateurs privilégiés, et ne jamais laisser les données de vidage au repos sur le système, dès qu'elles sont générées, elles doivent être déplacées de l'environnement de production pour l'analyse.
Dans ces situations, c'est une chose contrôlée, et l'implémentation du chiffrement ici n'ajoutera aucun avantage réel.
Si vous avez un type d'automatisation qui génère des vidages et les fournit à votre organisation, alors je dirais que vous DEVEZ implémenter le chiffrement partout spécialement si le vidage peut avoir des données PII ... Les vidages au repos qui n'ont pas été supprimés ou écrasés sont une bonne chose source d'informations sur ce qui s'exécute sur le serveur.
Ce n'est pas une bonne pratique car les serveurs de production doivent avoir DUMPS désactivé et DEBUG également désactivé. Cela ne doit être activé que lorsque cela est nécessaire et avec certains administrateurs système, il le surveille en direct.
Le chiffrement entraînera des défis qui vous coûteront de l'argent.
Infra PKI: si vous possédez la clé privée, aucun de vos clients ne sera autorisé à accéder aux données localement, sauf si vous partagez la clé.
Si vous souhaitez permettre à vos clients d'avoir la clé privée pour accéder à leur vidage local, vous entrerez dans un problème de gestion des clés qui peut prendre du temps car vous devrez générer une clé privée par client.
La révocation d'une clé nécessitera une mise à jour de l'application chez tous vos clients ...
Clé synchrone: n'a pas beaucoup de sens car la clé devra exister quelque part dans le système pour permettre le chiffrement des données.
Le changement de clé sera également un défi et prendra du temps.