GitHub : un bogue a été révélé avec la fonction « réinitialisation du mot de passe »

Version imprimable

03/05/2018, 03h09
Blondelle Mélina

2 pièce(s) jointe(s)

GitHub : un bogue a été révélé avec la fonction « réinitialisation du mot de passe »

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 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.

Pièce jointe 375735

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.

Pièce jointe 375740

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 ?

:fleche: Qu'en pensez-vous ?

Voir aussi :

:fleche: GitHub : des chercheurs estiment que plus de la moitié des codes écrits en Java, Python, C/C++ et JavaScript, sont dupliqués
:fleche: GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée, et menée sans réseau de zombies
:fleche: GitHub utilisé par des acteurs malveillants pour héberger un mineur de moneros, distribué au travers d'une campagne publicitaire
03/05/2018, 10h44
earhater

Bug de débutant non ?
03/05/2018, 11h10
transgohan

Vu qu'on a aucunement le détail du bug difficile de juger.
03/05/2018, 11h33
SofEvans

Citation:

Envoyé par earhater

Bug de débutant non ?

Non, 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.
03/05/2018, 12h08
earhater

Citation:

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.

Sauf qu'en prod tu fais du log fichier non accessible et pas sur la page. C'est la constante php error_reporting (http://php.net/manual/fr/function.error-reporting.php) qui doit être settée au minimum. Tout framework qui se respecte une fois en mode prod n'affiche plus les erreurs de devs en prod et les logs en fichier avec une page 500 skinnable pour l'utilisateur. C'est une erreur de débutant
03/05/2018, 12h17
SofEvans

Citation:

Envoyé par earhater

Sauf qu'en prod tu fais du log fichier non accessible et pas sur la page. C'est la constante php error_reporting (http://php.net/manual/fr/function.error-reporting.php) qui doit être settée au minimum. Tout framework qui se respecte une fois en mode prod n'affiche plus les erreurs de devs en prod et les logs en fichier avec une page 500 skinnable pour l'utilisateur. C'est une erreur de débutant

Je 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 ?
03/05/2018, 16h16
hotcryx

Des librairies qui montrent des mots de passe :aie: 8O

"echo 'root:mon_super_mdp_root'", il faut être inconscient pour faire ce genre de chose!
03/05/2018, 16h45
SofEvans

Citation:

Envoyé par hotcryx

Des librairies qui montrent des mots de passe :aie: 8O

"echo 'root:mon_super_mdp_root'", il faut être inconscient pour faire ce genre de chose!

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) ?
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.
03/05/2018, 21h40
earhater

Citation:

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) ?

La connexion SSH implique un échange ssl entre les deux partis, donc le risque attaque main in the middle est quasi nul (mais pas inexistant, je pense notamment à une falsification des certificats en local, par exemple via un phishing et une élévation de privilèges préalable). La commande passwd n'expose pas directement le mot de passe utilisateur, ni même la longueur du mot de passe : quand on l'écrit dans le terminal on ne voit rien s'afficher à l'écran. la seule viable manière pour un attaquant de récupéré un mot de passe utilisateur via un terminal ssh est un keylogger, qui ne requière pour sa part aucune élévation de privilèges. Un bon antivirus à jour permet toutefois de s'en protéger en partie en cas de phishing.

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 client

Citation:

Mais pour l'exemple des commandes bash, tu fais comment ?

De la même manière, tous les frameworks qui se respectent proposent une entrée input sécurisée ($this->secret pour laravel, je te fais pas la démo pour tous les outils) qui utilisent le secure input dont le comportement et les limites sont exposés juste au dessus. En bash pur, l'argument -s à la commande read permet de demander un secure input dont, encore une fois, le comportement et limites sont exposées si dessus.

Tout cela relève de la sécurité de base

EDIT: à aucun moment l'input utilisateur n'est remonté par la commande bash history
07/05/2018, 11h26
SofEvans

Désolé de ne pas avoir répondu plus tôt.

Citation:

Envoyé par earhater

La connexion SSH implique un échange ssl entre les deux partis, donc le risque attaque main in the middle est quasi nul (mais pas inexistant, je pense notamment à une falsification des certificats en local, par exemple via un phishing et une élévation de privilèges préalable). La commande passwd n'expose pas directement le mot de passe utilisateur, ni même la longueur du mot de passe : quand on l'écrit dans le terminal on ne voit rien s'afficher à l'écran. la seule viable manière pour un attaquant de récupéré un mot de passe utilisateur via un terminal ssh est un keylogger, qui ne requière pour sa part aucune élévation de privilèges. Un bon antivirus à jour permet toutefois de s'en protéger en partie en cas de phishing.

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.

Citation:

Envoyé par earhater

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

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 ...

Citation:

Envoyé par earhater

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 client

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.

Citation:

Envoyé par earhater

De la même manière, tous les frameworks qui se respectent proposent une entrée input sécurisée ($this->secret pour laravel, je te fais pas la démo pour tous les outils) qui utilisent le secure input dont le comportement et les limites sont exposés juste au dessus. En bash pur, l'argument -s à la commande read permet de demander un secure input dont, encore une fois, le comportement et limites sont exposées si dessus.

Tout cela relève de la sécurité de base

EDIT: à aucun moment l'input utilisateur n'est remonté par la commande bash history

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.