Comment puis-je prouver que ce site présente une énorme faiblesse de sécurité?
Avertissement: Je suis un programmeur informatique, pas un analyste de sécurité ou quoi que ce soit à voir avec la sécurité. Je n'ai aucune expérience dans le monde de la cryptographie, alors soyez indulgent avec moi.
Situation: On m'a confié la tâche d'intégrer le site d'un client avec un site d'hébergement de données. En travaillant sur cela, je suis tombé sur une requête qui vide toutes les données des utilisateurs. Pour effectuer cette requête, l'utilisateur doit "s'authentifier" pour obtenir une session et utiliser ce code de session pour effectuer cette requête, qui vérifie ensuite que l'utilisateur dispose des privilèges d'administrateur avant de terminer la requête et de répondre.
Mais quand même ... cela me semble horrible. Surtout que ce sont certaines des données qui sont renvoyées si la requête est exécutée avec succès:
"username": "[email protected]",
"firstname": "Test",
"lastname": "Name",
"userpassword": "$1$te000000$qMpAriadAHuRyDkK58YKS0"
Il y a plus de données renvoyées qui sont horribles à exposer, mais ce n'est pas ma principale préoccupation.
De toute évidence, personne n'a jamais été nommé "Nom du test" et "testemail.blerg" n'est pas un domaine enregistré, sans parler de "blerg" étant un domaine de premier niveau possible. Même s'il l'était, ce compte a été supprimé du site d'hébergement de données et ne peut pas se connecter. Le mot de passe qui a été utilisé est un cas de test faible et n'est utilisé par personne.
Est-il possible pour moi de recourir à la force brute/Rainbow-table (même si je n'ai pas d'expérience, je connais quelques mots flash: P) ou quelque chose pour en obtenir le mot de passe? Le peu (je pense) que je sais, c'est que la première partie du userpassword est le sel MD5, mais je ne sais rien d'autre.
Si quelqu'un peut expliquer à quel point c'est facile, je peux prouver à mon patron que ce site est complètement horrible et convaincre notre client de migrer de ce site d'hébergement de données.
Il y a plus que je sais sur le salage (c'est-à-dire comment il obtient le sel, quelle langue/fonction il utilise, etc.), mais j'aimerais voir avec quelle facilité une personne qui n'a pas accès à cette information peut le comprendre en dehors. Une autre chose avec laquelle j'irais voir mon patron, j'espère.
EDIT: Il semble y avoir une petite confusion liée au fait que je suis intentionnellement vague dans la description, en partie dans le but d'empêcher toute indication de quel CRM il s'agit, pour des raisons juridiques/etc. Je me rends également compte que je l'appelle ' l'hébergement de données "était potentiellement trompeur, donc ma mauvaise. J'espère que cela clarifie:
Le travail de notre équipe consiste à créer un site Web de base permettant à une entreprise de présenter ses produits. La seule interaction que j'ai avec le CRM est:
- Lorsqu'une personne remplit le formulaire Contactez-nous, nous
POSTau CRM unContactsobjet avec les informations de l'utilisateur. - Faites un
GETsur une liste deDealersqui vendent leurs produits à afficher.
J'ai commencé avec # 2, l'appel d'API GET, où j'ai découvert que je pouvais interroger la table Users. Je n'ai pas créé l'API, je n'en ai fait que des demandes.
L'appel GET nécessite un paramètre query= où la valeur est une instruction SELECT dans le langage de requête du système, qui est ensuite traduite en SQL (probablement pour empêcher les attaques SQLI, mais je ne sais pas comment elle interprète/se traduit en SQL, donc je suis pas toucher avec un poteau de 10 pieds). En changeant SELECT * FROM Dealers; à SELECT * FROM Users; dans la requête, j'ai pu voir les données de chaque utilisateur.
La façon dont le CRM gère les utilisateurs est avec un portail sur leur site. Un utilisateur est créé dans le portail, où il y a une case à cocher "Est administrateur". Cela peut être modifié à tout moment via le portail. C'est le processus pour faire des requêtes API:
Un utilisateur fait une demande au CRM, contenant le nom d'utilisateur, pour un jeton.
Le jeton est concaténé avec la clé d'accès "secrète" pour cet utilisateur, la chaîne résultante est hachée MD5 puis renvoyée pour demander un jeton de session.
Ce jeton de session est inclus avec chaque demande, en tant que paramètre de chaîne de requête, pour "vérifier" que la demande est "autorisée".
L'un des problèmes est que si un utilisateur "admin" fait une demande de la table Users, la réponse est une liste de chaque utilisateur avec les informations que j'ai répertoriées ci-dessus ainsi que le jeton d'accès "secret" de l'utilisateur (et d'autres informations). Donc, c'est encore pire que de simplement exposer un mot de passe, c'est accorder pratiquement l'accès à n'importe qui en usurpant l'identité de quelqu'un.
Le format de mot de passe dans l'attribut userpassword ressemble au format standard utilisé par divers services Unix, comme le service de mot de passe système par défaut qui stocke les mots de passe hachés dans /etc/shadow. Le format est essentiellement:
$ type $ salt $ hash
Dans votre exemple, le type est 1, qui désigne un hachage md5. Il existe d'autres types bien connus, tels que différentes tailles des fonctions de hachage de la famille sha.
Casser un hachage md5 est presque trivial aujourd'hui, même lorsqu'il est salé, car md5 est si rapide. Ce n'est pas une fonction de hachage qui peut être utilisée en toute sécurité pour hacher des mots de passe; hashcat et d'autres crackers de mot de passe peuvent littéralement hacher des millions voire des milliards de candidats de mot de passe par seconde.
Ce service de stockage de données n'est donc pas seulement horrible car il renvoie des hachages de mot de passe utilisateur, il est encore plus horrible car il utilise en fait des hachages md5 pour stocker des mots de passe.
Pour prouver à votre patron que ce n'est vraiment pas sécurisé, vous pouvez télécharger hashcat et quelques listes de mots de passe (vous pouvez facilement les trouver en ligne), puis exécuter hashcat sur un ordinateur avec un GPU très puissant sur tous les mots de passe que vous obtenez le service. Notez le nombre de mots de passe que le hashcat peut cracker (sans regarder les mots de passe eux-mêmes - ils peuvent révéler des informations privées sur les personnes qui les ont choisis, et vous ne voulez pas vraiment connaître leurs mots de passe), et informer les personnes dont les mots de passe ont été compromis qu'ils doivent choisir un nouveau mot de passe. Vous devrez probablement obtenir la permission de faire tout cela d'abord, car selon l'endroit où vous vivez et travaillez, cela pourrait en fait être considéré comme une attaque malveillante, voire illégale.
À part: Si vous étiez coincé à utiliser ce service même après avoir exprimé vos doutes, je suggère que la mise en place d'un cracker de mot de passe automatisé qui fonctionne sans intervention humaine et informe les gens (en leur envoyant un e-mail ) lorsqu'il parvient à déchiffrer son mot de passe serait un moyen de protéger vos utilisateurs contre ce type de mauvaise conception. Cela aiderait à éliminer les mots de passe faibles et à augmenter le temps nécessaire à un véritable attaquant pour déchiffrer les mots de passe.
Edit: Zach a souligné que le côté n'est pas une pratique courante et ne devrait pas être tenté par quelqu'un qui n'est pas en mesure d'évaluer les risques. Je suis complètement d'accord avec ça. À tout le moins, si vous avez fait quelque chose comme ça, vous devriez avoir la gestion d'accord.
Pourtant, NE PAS faire cela ne rend pas le système résultant plus sûr. C'est l'équivalent de vous mettre la tête dans le sable par crainte que si vous avez réellement fait quelque chose pour améliorer la sécurité des mots de passe, cela pourrait se retourner contre vous. Nous savons que les gens choisissent de mauvais mots de passe, et nous savons que md5 n'est pas un bon moyen de hacher des mots de passe. Si nous ne pouvons pas changer ces deux faits, et nous sommes en mesure d'éliminer les mots de passe faibles, alors nous devrions probablement le faire pour rendre nos utilisateurs plus sûrs.
Une raison importante pour laquelle cela n'est pas vu beaucoup, ni même considéré beaucoup, est que nous ne sommes généralement pas en mesure de le mettre en œuvre. Les bons systèmes n'utilisent pas de fonctions de hachage rapide pour hacher les mots de passe, et nous n'avons généralement pas accès à l'ensemble de la base de données de mots de passe hachés.
Ce hachage de mot de passe semble utiliser le format crypt() (qui, malgré son nom et ce que disent certaines documentations, y compris cette même page de manuel, n'a absolument rien à voir avec le cryptage; il est hachage). Quand ça commence par $1$, cela signifie qu'il s'agit d'une fonction de hachage de mot de passe basée sur MD5. Sa spécification exacte est "quoi que fasse la glibc". Un coup d'oeil au code source montre quelques passages éclairants:
201 /* The original implementation now does something weird: for every 1
202 bit in the key the first 0 is added to the buffer, for every 0
203 bit the first character of the key. This does not seem to be
204 what was intended but we have to follow this to be compatible. */
205 for (cnt = key_len; cnt > 0; cnt >>= 1)
206 md5_process_bytes ((cnt & 1) != 0
207 ? (const void *) alt_result : (const void *) key, 1,
208 &ctx, nss_ctx);
209
210 /* Create intermediate result. */
211 md5_finish_ctx (&ctx, nss_ctx, alt_result);
212
213 /* Now comes another weirdness. In fear of password crackers here
214 comes a quite long loop which just processes the output of the
215 previous round again. We cannot ignore this here. */
216 for (cnt = 0; cnt < 1000; ++cnt)
217 {
De cela, nous pouvons conclure que cette fonction de hachage n'est pas très bien documentée.
Quoi qu'il en soit , comme les fonctions de hachage de mot de passe vont, ce n'est pas très bon. Il utilise un salt, et c'est bien, car il devrait empêcher l'utilisation par les attaquants de tables précalculées (y compris les tables Rainbow). Il comprend également une boucle avec de nombreuses (1000) itérations, comme une tentative de ralentir le hachage de mot de passe, ce qui rend plus difficile pour les attaquants d'essayer de nombreux mots de passe potentiels jusqu'à ce qu'une correspondance soit trouvée (un processus appelé "force brute" ou "attaque par dictionnaire" ").
Malheureusement, ce n'est pas très bon non plus. MD5 est rapide et un millier de MD5 imbriqués, bien que 1000x plus lent, est toujours rapide. Un PC standard avec un GPU de base orienté jeu peut calculer des millions de tels hachages par seconde; un mot de passe utilisateur moyen ne durera pas longtemps; et par cela, je veux dire qu'un attaquant qui passe une minute de calcul par mot de passe haché en craquera toujours la moitié.
Mis à part le mot de passe haché, révéler simplement les adresses e-mail des utilisateurs est déjà une infraction assez condamnable - je veux dire juridiquement parlant. Par exemple, au Canada, il s'agit de "renseignements personnels" et tous les utilisateurs auraient le droit de vous poursuivre.
Arrêtez. N'allez pas plus loin. Ne faites plus de tests, de démonstrations, etc. jusqu'à ce que vous ayez été explicitement invité à le faire par écrit, et même alors commencez par suggérer qu'il y a beaucoup plus de personnes qualifiées que vous pour faire un audit/pentest/etc.
Je connais 2 personnes qui ont fait la même chose avec moins d'informations (pas de mot de passe, juste des détails auxquels elles n'avaient pas besoin d'accéder et n'auraient pas dû avoir accès) il y a quelques mois à peine et elles sont toujours en train de gérer crime frais.
Ce format ressemble à un hachage de mot de passe de style Unix standard. Les champs sont séparés par des signes dollar, d'abord l'algorithme, puis le sel, puis le hachage réel. En supposant que c'est un système Linux, le $ 1 $ indique l'algorithme de mot de passe md5 (qui est un peu plus complexe que le md5 pur). Les longueurs de champ sont également cohérentes avec l'algorithme de hachage de mot de passe MD5.
Il existe de nombreux outils pour attaquer les hachages de mot de passe Linux. La réussite de ces outils dépendra en grande partie de la force des mots de passe.
Je note également que votre sel contient beaucoup de zéros. Si vous avez un sel statique ou une gamme de sels relativement petite (par rapport au nombre d'utilisateurs), cela peut ouvrir des options pour les attaques précalculées.
Enfin, je voudrais noter que l'attaque de vrais mots de passe peut entraîner des problèmes juridiques.
Toutes ces informations sont disponibles pour un utilisateur admin sur un système Linux typique dans /etc/passwd (lisible par tous) et /etc/shadow (lisible par root). Il est difficile sous Linux standard d'empêcher un utilisateur root d'accéder à /etc/shadow. Comme la requête nécessite des privilèges d'administrateur, il ne semble pas qu'elle expose beaucoup étant donné qu'un compte d'administrateur a été compromis. Comme d'autres réponses l'ont mentionné, si le système utilise vraiment des hachages md5, c'est un problème, mais sans rapport avec la question.