Les mots de passe logiciels peuvent-ils être contournés par rétro-ingénierie?
Disons que j'ai des privilèges d'administrateur dans mon système d'exploitation (Windows ou autre). Lorsque le logiciel [~ # ~] xyz [~ # ~] est installé et exécuté, cela signifie qu'il existe une communication entre le système d'exploitation et [~ # ~] xyz [~ # ~] et le système d'exploitation s'exécute et voit tout ce qui [~ # ~] xyz [~ # ~] le fait.
Voici ma perception des mots de passe (comme les mots de passe .Zip):
Est-il possible de modifier la logique logicielle pour exécuter la commande au lieu d'une autre commande? Si oui, alors rien ne peut être protégé contre les fissures?
En bref, oui, vous pouvez modifier l'exécutable, utiliser un débogueur, etc. pour modifier la logique du code en cours d'exécution.
Mais cela ne suffira peut-être pas.
Pour utiliser votre exemple de "mots de passe .Zip", les archives protégées par mot de passe utilisent le mot de passe pour dériver une clé de chiffrement. À moins que vous ne fournissiez un mot de passe correct, la clé générée sera erronée et même si vous la modifiez pour utiliser une mauvaise clé, elle ne réussira pas à déchiffrer le fichier Zip.
Un autre scénario pourrait impliquer un exécutable setuid qui s'exécute avec des privilèges plus élevés. Vous pouvez l'exécuter sous un débogueur, ou le copier sur votre compte d'utilisateur et apporter des modifications, mais tout cela permettra de l'exécuter avec les autorisations de votre utilisateur, éliminant ainsi les possibilités d'exploitation.
Eh bien, votre perception des mots de passe .Zip n'est pas exacte. L'approche, également utilisée par de nombreux autres programmes, consiste à toujours exécuter un algorithme de décryptage et obtenir un résultat, avant même que le programme n'atteigne la décision "bon ou mauvais mot de passe". L'astuce est que le déchiffrement produit des ordures sur n'importe quel mot de passe, sauf un bon qui "magiquement" (ou plutôt - mathématiquement) calcule les données appropriées. Le programme ne sait donc pas quel est le bon mot de passe.
Le moment "bon ou mauvais" que vous souhaitez pirater vérifie uniquement si le résultat est une ordure. Ce n'est pas très avantageux de passer outre.
Oui et Non.
Étant donné que personne n'a encore proposé d'exemple concret (non informatique), je vais essayer ici:
Imaginez essayer de monter à bord d'un vol. Vous avez besoin d'une carte d'embarquement, sinon les agents de sécurité ne vous laisseront pas passer. Si vous avez accès au système et que vous pouvez le modifier (par exemple, vous êtes le PDG), pouvez-vous contourner la sécurité? Oui! Vous pouvez:
- Supprimez les gars de la sécurité (supprimez tout le composant d'authentification)
- Demandez aux gars de laisser entrer tout le monde (retirer la case "si le passager a une carte d'embarquement valide")
- Demandez aux gars de donner accès si quelqu'un présente une carte d'embarquement spéciale (ajoutez une nouvelle règle de validation pour autoriser les fausses informations d'identification)
Maintenant, un autre scénario: un tas de coffres-forts sont stockés dans une banque. Pour ouvrir un coffre-fort, vous avez besoin d'une clé physique pour activer le verrou.
Pouvez-vous tirer l'astuce précédente? Oui, vous pouvez, mais cela n'aidera pas. Ce n'est pas comme si le gars de la sécurité qui se tenait là avait accès à tous les coffres - il n'avait la clé d'aucun des coffres. Vous pouvez battre l'enfer hors de lui, mais il ne possède pas seulement ce qui est nécessaire (la clé physique) pour ouvrir les serrures.
Vous pouvez essayer de choisir le verrou (forçage brutal), mais cela prendrait beaucoup de temps (le calcul des clés de chiffrement modernes dit que vous avez besoin de quelques milliards d'années pour le déverrouiller, même si tous les ordinateurs du monde le font pour vous). Vous êtes donc là - dans cette conception (chiffrement des données), la seule façon d'obtenir les données stockées est d'utiliser une clé, ce qui rend impossible le contournement.
Bien sûr, le logiciel peut faire tout ce que vous programmez.
Comme exemple trivial, si on me fournissait un programme Python qui vérifiait un mot de passe:
password = raw_input('Enter your password: ')
if password != 'oh-so-secret':
sys.exit(1)
do_secure_thing()
Je pourrais tout simplement le changer pour ne pas me soucier du mot de passe:
password = raw_input('Enter your password: ')
do_secure_thing()
(Dans ce cas, vous pouvez également voir quel est le mot de passe en texte brut codé en dur et le saisir.)
Avec les applications binaires, vous devez les décompiler avant de pouvoir modifier la source, mais il existe de nombreux décompilateurs pour les langages courants.
C'est pourquoi signature de code existe.
Maintenant, si ce n'est pas votre propre système, vos options peuvent être un peu plus limitées. Sur la plupart des systèmes de type Unix, les exécutables sont généralement stockés avec des autorisations en lecture et en exécution uniquement pour les utilisateurs non root; ainsi, si vous n'êtes pas root, vous ne pouvez pas modifier l'exécutable cible. Il existe d'autres méthodes moins directes à essayer, mais si elles échouent, vous envisagez de passer à un autre vecteur.
Par exemple, un enregistreur de frappe enregistrera les mots de passe entrés par l'utilisateur, vous permettant de les réutiliser vous-même plus tard.
Une autre méthode d'attaque qui ne nécessite pas de modifier la source d'un programme consiste à modifier le chemin de chargement de la bibliothèque dynamique de telle sorte que le programme utilise un appel de bibliothèque que vous avez écrit, plutôt que celui qu'il attend. S'ils utilisent une bibliothèque externe chargée dynamiquement pour la gestion des mots de passe et que cette bibliothèque a une fonction verify_password() qui renvoie un booléen, vous pouvez écrire votre propre verify_password() qui renvoie toujours true, et chargez-le à la place.
La vraie distinction qui change la réponse de "oui" à "non" est que le mot de passe n'est pas réellement un mot de passe, mais une clé de cryptage. Si les données sont cryptées, peu importe ce que font les programmes externes - les données sont toujours cryptées jusqu'à ce que l'algorithme de décryptage reçoive la clé appropriée.
Supposons que vous ayez une application qui stocke des données dans un fichier texte (ou une petite base de données), mais pour accéder au fichier depuis l'application vous devez entrer un mot de passe ou utiliser un processus spécial. Vous pouvez simplement ouvrir le fichier texte (ou db) à partir du répertoire de fichiers à l'aide du système d'exploitation (aucune ingénierie inverse requise). Cela se produisait souvent dans les anciens programmes (jeux, en particulier).
C'est pourquoi les applications qui espèrent être sécurisées prennent des mesures pour protéger les données du système d'exploitation lui-même. Comme chiffrer les données ou les obscurcir pour les rendre difficiles à utiliser.
Cela dépend de la façon dont le logiciel XYZ utilise le mot de passe afin de produire l'action souhaitable et du type de données avec lequel il fonctionne.
Si nous regardons l'algorithme abstrait du programme XYZ ce serait:
- Demandez à l'utilisateur d'entrer le mot de passe.
- Faites quelque chose avec le mot de passe entré par l'utilisateur.
- Produire une sortie souhaitable (ou effectuer une action souhaitable).
Donc, votre question peut être réduite à l'étape #:
Est-il possible de produire une sortie souhaitable (ou d'effectuer une action) sans utiliser le programme XYZ?
Il existe de nombreuses variantes possibles ici, mais le point principal est que le logiciel XYZ effectue des étapes particulières afin de produire le résultat.
Si l'on peut créer un programme ABC qui peut produire le même résultat dans un délai raisonnable sans nécessiter de mot de passe, le XYZ peut être contourné.
Cela indiquerait que toute la "protection" est implémentée dans le programme XYZ lui-même.
Si la création d'un tel programme ABC n'est pas possible, la protection s'appuie sur un algorithme qui nécessite le mot de passe quel que soit le programme qui essaie de l'utiliser).
Exemple 1: Un compte OS non privilégié ne peut pas définir de mot de passe pour un autre utilisateur, car il est appliqué par l'OS. Ainsi, le système d'exploitation dans ce cas est XYZ . Mais on peut démarrer l'ordinateur à partir d'un lecteur amorçable et écraser le fichier contenant les mots de passe, car le système d'exploitation d'origine ne fonctionne pas pour le moment, il ne peut donc pas appliquer la protection. Ainsi, nous avons pu produire le résultat souhaité sans utiliser le programme XYZ .
Exemple 2: Dans le deuxième exemple, le lecteur système du système d'exploitation est correctement chiffré avec un algorithme de chiffrement puissant. Si nous démarrons l'ordinateur avec un lecteur amorçable pour tenter de contourner le système d'exploitation d'origine, nous découvrirons que nous ne pouvons pas atteindre notre objectif, car nous ne pouvons pas accéder au fichier contenant les mots de passe. Il réside sur une partition qui doit d'abord être déchiffrée, mais nous ne connaissons pas le mot de passe. Une tentative de forcer brutalement le processus de décryptage n'apporterait pas le résultat souhaité de si tôt, donc dans ce cas, il n'était pas possible de contourner le programme XYZ ou tout autre autre programme avec des fonctionnalités similaires, car le les données sous-jacentes nécessitent le mot de passe.
Le mot de passe Zip n'est pas un exemple de ce que vous pensez. Mais beaucoup de choses sont , en particulier les versions "d'essai" qui sont limitées dans le temps ou dans l'ensemble de fonctionnalités.
Je me souviens d'une paire d'articles dans un magizine de programmation (peut-être Langage informatique ) expliquant comment faire cela et comment contrecarrer les tentatives de faire cela à votre code, respectivement.
Je connais des cas où il était littéralement aussi simple que de trouver la déclaration de comparaison et de changer la condition de saut - c'est-à-dire de changer un octet - pour contourner la vérification réelle.
C'est parfois le cas maintenant si l'auteur a simplement écrit la ligne de code dans le cadre du programme. Mais pour les clés d'activation et autres, une industrie entière a vu le jour et l'auteur peut inclure un kit qui obscurcit le test réel et rend difficile le fonctionnement du programme si des tentatives sont faites pour le contourner en utilisant des techniques courantes familières à un code de débogage de programmeur. .
Tout dépend de la façon dont le système fonctionne lors du décodage du mot de passe.
Vous imaginez un système de mot de passe de type "connexion" très basique qui pourrait être infiltré. Cependant, quelque chose comme les fichiers Zip et les sites Web utilisent diverses méthodes pour lutter contre les personnes qui éditent simplement le système pour le forcer à révéler le mot de passe.
Une façon est l'utilisation de MD5 avec `` sel '' pour renforcer la sécurité - cela fonctionne sur le fait que le mot de passe est transformé en un code méconnaissable qui ne peut pas être retourné - un exemple de base de ce qui se passe est le suivant
Le système demande un mot de passe - par ex. Le système PASSWORD ajoute du `` sel '' au mot de passe - par ex. 1234 (le mot de passe est maintenant PASSWORD1234) Le système utilise MD5 sur le mot de passe avec du sel - la plupart des gens savent que PASSWORD génère à lui seul le code MD5 319f4d26e3c536b5dd871bb2c52e3178 mais avec le sel "1234" ajouté au mot de passe, le MD5 devient maintenant 579f276ad2a77fd1698 qui est désormais 579f276ad2a77fd164 - un code totalement différent.
À ce stade, le système n'a toujours pas vérifié si ce mot de passe était valide, il transmet ensuite ce nouveau code à une autre section du programme qui décide si le code MD5 correspond ou non à ce qui est attendu s'il affiche le fichier ( le mot de passe initial a longtemps été supprimé de la mémoire).
Pour que quelqu'un s'infiltre dans ce type de mot de passe, il devra d'abord obtenir le mot de passe initial qui a été tapé, puis savoir plus tard si le programme a autorisé l'ouverture du fichier. Sur un logiciel sur un ordinateur, il peut être possible d'obtenir le mot de passe, puis de vérifier plus tard pour voir si le fichier a été ouvert et obtenir le mot de passe de cette manière, cependant si le mot de passe est envoyé en tant que sel MD5 + à un autre serveur ( par exemple via javascript et PHP), cela devient beaucoup plus délicat car un ordinateur a le mot de passe dans sa mémoire qu'il convertit et le serveur php a juste le mot de passe sel md5 + qui ne peut pas être reconverti.
En plus de cela, une autre méthode utilisée consiste à prendre le mot de passe et à le coder dans les données d'une certaine manière, c'est ainsi que les fichiers Zip fonctionnent, par exemple, j'ai un fichier avec le texte suivant ....
le renard brun rapide saute par-dessus le chien paresseux
Je lui donne un mot de passe d'une lettre! ok je sais que c'est un peu simple mais c'est un exemple simple - l'ordinateur pourrait convertir ça! en c'est ASCII équivalent et soustrayez le code ascii de chaque lettre pour l'encoder - le code ascii pour! est 33 et le code ascii pour t est 116 et 116 - 33 = 83 qui est le code ascii pour une lettre majuscule S donc quand les données sont cryptées la ligne ci-dessus finit par être stockée comme
SGD PTHBJ AQNVM ENW ITLOR NUDQ SGD K @ YX CNF
maintenant, si quelqu'un essaie de décrypter ce message, vous ne savez pas s'il a le bon mot de passe - s'il a entré le mot de passe de # au lieu de! ils recevraient le message suivant pour eux
vjg swkem dtqyp hqz lworu qxgt vjg nc | {fqi
ce qui n'a aucun sens - donc la plupart des systèmes vérifient en fait la validité d'un mot de passe, mais ils modifient le mot de passe initialement afin qu'il ne puisse pas être piraté par quelqu'un qui détourne simplement le résultat - la seule fois où cela tombe parfois, c'est quand quelqu'un crée leur propre site Web ou programme faux et oblige l'utilisateur à entrer initialement son mot de passe dans le faux programme ou site Web et bien sûr, de nombreux sites Web contournent même cela en utilisant des jetons d'authentification qui génèrent des mots de passe spéciaux qui ne sont valides que pendant environ 5 minutes à un (par exemple, la clé intelligente HSBC).
La question doit être clarifiée. Votre compréhension de la lecture d'un fichier zip protégé par mot de passe est incorrecte. Comme d'autres l'ont souligné, un fichier zip est crypté (les données sont brouillées) et le mot de passe est la clé pour décrypter.
Ce que vous décrivez (une redirection de l'exécution du code via la rétro-ingénierie du flux de code) fonctionnerait pour vaincre le "contrôle d'accès" appliqué par le programme.
Donc, à votre question initiale:
Est-il possible de modifier la logique logicielle pour exécuter la commande au lieu d'une autre commande? Si oui, alors rien ne peut être protégé contre les fissures?
Il est certainement possible de modifier la logique logicielle pour exécuter les commandes, en contournant le contrôle d'accès pour faire quelque chose que le programme pourrait faire autrement, via l'ingénierie inverse. Cependant, cela ne corrobore pas votre deuxième affirmation selon laquelle "rien ne peut être protégé contre les fissures". Le fichier zip chiffré est un bel exemple de cas où votre contrôle sur le code ne vous permet pas d'obtenir le contenu du fichier.
Dans ce cas, la clé n'est pas un portier vous empêchant d'exécuter un chemin de code, mais plutôt un composant requis pour obtenir les données en texte brut. Rien à voir avec le contrôle du déroulement du programme.