GitHub découvre un bogue qui expose certains mots de passe en texte clair
Le problème viendrait de la fonction de réinitialisation du mot de passe
Le 2018-05-03 03:09:17, par Blondelle Mélina, Chroniqueuse Actualités
Le site de codage social GitHub, était jusqu'à lors connu comme un site de dépôt sécurisé des codes des logiciels open source. Les programmeurs y vont le plus souvent pour héberger codes à l'appui leurs logiciels afin d'assurer l’inter-échange dans la communauté des développeurs. Cependant, un bogue récemment révélé, exposerait les mots de passe des comptes utilisateurs de la plateforme.
La vulnérabilité a été signalée par GitHub. Le bogue serait au niveau de la fonction de réinitialisation du mot de passe. Cette fonction, selon GitHub, permettrait aux mots de passe des utilisateurs de se retrouver dans les mains des personnes non habilitées. Le site rappelle néanmoins que ces mots de passe ne sont visibles que par une poignet réduite de personnes. Ils n'ont pas été rendus publics ou mis à la disposition d'autres utilisateurs, ajoute la plateforme.
GitHub souligne qu'ils n'ont pas été victime d'une attaque. Plutôt que la vulnérabilité aurait été découverte lors d'un audit régulier du site et n'affecterait que les utilisateurs qui ont récemment réinitialisé leurs mots de passe. GitHub rappelle qu'ils stockent les mots de passe des utilisateurs avec des algorithmes de hachages cryptographiques sécurisés (bcrypt). « Nous utilisons des méthodes cryptographiques modernes pour garantir que les mots de passe sont stockés en toute sécurité dans nos bases de données », déclarent-ils.
Le site référentiel de code, avec plus de 27 millions d'utilisateurs en date de l'année dernière, aurait informé ses utilisateurs de ce bogue via un e-mail. Le site recommande donc fortement de mettre à jour votre mot de passe si vous avez reçu l'e-mail. Voici ci-dessous un extrait du contenu de l'e-mail de Github à ses utilisateurs.
GitHub dit avoir corriger le bogue. Pour retrouver l'accès au compte, il faudra réinitialiser le mot de passe, ajoute Github. Les attaques évoluent souvent et nous continuons d'étudier et de surveiller de nouveaux vecteurs d'attaques, déclare-t-il.
Source : GitHub Blog, The Daily Dot
Et vous ?
Qu'en pensez-vous ?
Voir aussi :
GitHub : des chercheurs estiment que plus de la moitié des codes écrits en Java, Python, C/C++ et JavaScript, sont dupliqués
GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée, et menée sans réseau de zombies
GitHub utilisé par des acteurs malveillants pour héberger un mineur de moneros, distribué au travers d'une campagne publicitaire
La vulnérabilité a été signalée par GitHub. Le bogue serait au niveau de la fonction de réinitialisation du mot de passe. Cette fonction, selon GitHub, permettrait aux mots de passe des utilisateurs de se retrouver dans les mains des personnes non habilitées. Le site rappelle néanmoins que ces mots de passe ne sont visibles que par une poignet réduite de personnes. Ils n'ont pas été rendus publics ou mis à la disposition d'autres utilisateurs, ajoute la plateforme.
GitHub souligne qu'ils n'ont pas été victime d'une attaque. Plutôt que la vulnérabilité aurait été découverte lors d'un audit régulier du site et n'affecterait que les utilisateurs qui ont récemment réinitialisé leurs mots de passe. GitHub rappelle qu'ils stockent les mots de passe des utilisateurs avec des algorithmes de hachages cryptographiques sécurisés (bcrypt). « Nous utilisons des méthodes cryptographiques modernes pour garantir que les mots de passe sont stockés en toute sécurité dans nos bases de données », déclarent-ils.
Le site référentiel de code, avec plus de 27 millions d'utilisateurs en date de l'année dernière, aurait informé ses utilisateurs de ce bogue via un e-mail. Le site recommande donc fortement de mettre à jour votre mot de passe si vous avez reçu l'e-mail. Voici ci-dessous un extrait du contenu de l'e-mail de Github à ses utilisateurs.
GitHub dit avoir corriger le bogue. Pour retrouver l'accès au compte, il faudra réinitialiser le mot de passe, ajoute Github. Les attaques évoluent souvent et nous continuons d'étudier et de surveiller de nouveaux vecteurs d'attaques, déclare-t-il.
Source : GitHub Blog, The Daily Dot
Et vous ?
Voir aussi :
-
SofEvansMembre émériteNon, pas spécialement.
Un exemple typique est pdo connect en php : Si la connexion échoue, une exception est levée.
En général, quand on a une exception en php, on cherche a avoir le max d'info (car justement cela n'aurait pas dû arriver du tout).
On "dump" donc l'exception complète dans le log.
Cependant, l'exception de connect pdo contient le mot de passe en clair de l'utilisateur.
À aucun moment le dev n'as voulu que le mdp aparaisse dans les log (il ne l'as pas tapé explicitement), ce qui sera pourtant le cas.
Idem, par exemple pour du loging de commande bash via ssh2 : En cas d'echec de la commande bash, on aime généralement bien savoir quelle commande a échoué et on log donc la commande complète.
Cependant, que se passe-t-il si la commande est "echo 'root:mon_super_mdp_root' | /usr/sbin/chpasswd" ?
On a logué un mdp ...
Donc non, ce n'est pas spécialement une erreur de débutant, ça peut être relativement vicieux.le 03/05/2018 à 11:33 -
SofEvansMembre émériteJe pense qu'on est bien d'accord sur le fait que l'utilisateur final ne doit pas avoir accès au logs, ni aux erreurs, ni aux exceptions (ni à rien du tout hormis un joli message générique style "Nous rencontrons des problèmes blablabla"
.
Cependant, ce n'est pas ce type d'erreur qui s'est produit : l'erreur remonté par github est que les mdp des utilisateurs apparaissaient en clair dans le système de logging interne à github (clairement précisé dans leurs com').
Et à ce niveau, des mdp en clair dans les logs interne ne sont pas forcement une erreur de débutant, cela pouvant être vicieux.
Bon ok, l'exemple de pdo connect est un peu faible, car c'est écrit en rouge dans la doc, et que toutes connexions pdo doit se faire dans un try catch.
Mais pour l'exemple des commandes bash, tu fais comment ?le 03/05/2018 à 12:17 -
SofEvansMembre émériteComment changes-tu, à travers une connexion ssh, le mot de passe d'un utilisateurs (root ou pas d'ailleurs) sur un système Debian sachant que cela doit être automatique (pas d'intervention humaine) ?
Je suis curieux. Cette problématique m'avais été posé par un prof il y a assez longtemps pour me montrer que de toute façon, a un certains point (et selon les contraintes), le mot de passe doit transiter "en clair" (il y a quand même le ssh qui est là, mais bon, cela ne change pas le fait que la commande apparaît dans l'historique et peut apparaître dans des logs, justement).
A cette époque, je n'avais pu penser qu'à cette commande avec soit un clean history après, soit (mieux) une désactivation de l'history sur le moment.
Mais si tu as mieux que cet acte inconscient, je suis preneur.le 03/05/2018 à 16:45 -
transgohanExpert éminentVu qu'on a aucunement le détail du bug difficile de juger.le 03/05/2018 à 11:10
-
earhaterMembre éprouvéBug de débutant non ?le 03/05/2018 à 10:44
-
SofEvansMembre émériteDésolé de ne pas avoir répondu plus tôt.
Sur ce point, nous sommes d'accord. D'ailleurs, il n'y a pas trop à débattre car tu énonces pour la quasi totalité des faits (oui, ssh implique un échange de certificat ssl, passwd ne montre pas son input, etc etc). Il n'y a que le keylogger géré via anti-virus sur lequel je ne me prononcerais pas.
Ok, c'est mieux que ma méthode car en cas de log, le mdp n’apparaît (et cela répond donc à ma question). Mais hormis le fait que tu caches le mdp dans un fichier, cela ne change pas le fait que tu doives à un moment ou un autre envoyer le "mdp" en clair.
Dans ton exemple, le "mdp" en clair, c'est l'acquisition de la clef de déchiffrage sur serveur distant. Car au final, même si ton vrai mdp est chiffré, il n'empêche que tu dois acquérir la clef de déchiffrement qui elle, sera en clair ...
L'étape "action responsable technique" est en trop si la volumétrie est énorme. C'est pour cela que la chaîne de maj du mdp devait être entièrement automatique.
La, tu part un peu en hors sujet par rapport à mon exemple initial :
Imagine que tu as une class "myssh2" avec la methode "execute($command)". la méthode execute se charge donc d'exécuter la commande "$command".
En cas d'erreur, on est bien content en général d'avoir la commande fautive (et le résultat de la commande par exemple), tout simplement parce que "Une commande envoyé en ssh ne s'est pas exécuté correctement", c'est mignon mais pas très utile, alors que "Echec de le commande 'ls /path/dossier/inexistant'" est plus parlant.
Il n'y a pas moyen de savoir que "$command" est quelque chose qu'il faut cacher (d'où ton hors sujet avec l'input sécurisé où là on sait clairement que l'on va rentrer des infos sensibles). D'où pourquoi je te dis que ce type d'erreur (mdp en clair dans les log) peut être vicieux.
Et je te parle de pdo et ssh2 uniquement parce que j'y ai déjà été confronté, mais clairement il doit y avoir d'autre exemple plus pertinents.le 07/05/2018 à 11:26 -
earhaterMembre éprouvéComment changes-tu, à travers une connexion ssh, le mot de passe d'un utilisateurs (root ou pas d'ailleurs) sur un système Debian sachant que cela doit être automatique (pas d'intervention humaine) ?
L'update automatique dans un script d'un mot de passe utilisateur ne doit pas être faite de cette manière. Si jamais on devait le faire je pense que je sauvegarderai le fichier de mot de passe en local, avec un système de hashage symétrique avec une clef sauvegardé à distance, avec une authentification par clef publique et privée. Mais je taperai très fort sur les doigts des gens qui me demanderaient de développer cet outil incensé. Le script prend le fichier sauvegardé sur le local : demande la clef de déchiffrage sur un serveur distant (à usage unique) qu'il récupère via un échange de clef publique / privée pour décoder l'entrée fichier, mettre à jour le mot de passe utilisateur et supprimer le fichier de mot de passe local
A chaque utilisation du script, le responsable technique s'occupe de générer une nouvelle clef de chiffrage / déchiffrage qu'il stocke sur ce serveur distant et renvoie les mot de passes chiffrés au clientMais pour l'exemple des commandes bash, tu fais comment ?
Tout cela relève de la sécurité de base
EDIT: à aucun moment l'input utilisateur n'est remonté par la commande bash historyle 03/05/2018 à 21:40 -
earhaterMembre éprouvéEn général, quand on a une exception en php, on cherche a avoir le max d'info (car justement cela n'aurait pas dû arriver du tout).
On "dump" donc l'exception complète dans le log.
Cependant, l'exception de connect pdo contient le mot de passe en clair de l'utilisateur.
le 03/05/2018 à 12:08 -
hotcryxMembre extrêmement actifDes librairies qui montrent des mots de passe
"echo 'root:mon_super_mdp_root'", il faut être inconscient pour faire ce genre de chose!le 03/05/2018 à 16:16