La semaine dernière, nos confrères de Les Numériques ont été victimes d'une cyberattaque ayant entrainé la fuite de logins et de cookies de session. Ces derniers contiennent une empreinte du mot de passe associé au compte, il est donc conseillé d'en changer.
Le site Les Numériques a été victime d'un pirate qui a exploité une faille XSS sur certaines pages du site afin d'exécuter du code JavaScript. Mathias Lallement, directeur technique, explique en effet qu'un « attaquant l'a utilisée pour collecter login+cookie de session, sur certains commentaires d'articles du site, depuis le 25/10 à 17h41 [...] Nous avons été prévenus jeudi soir et avons pu trouver et corriger cette faille entre vendredi et lundi ».
Il ajoute que « la faille permettait d'être connecté à la place du membre, donc d'accéder à l'édition de son profil sur le site, de connaître l'adresse email associée au compte et de changer les informations liées au compte, comme le mot de passe ». Plus problématique, le cookie de session contient une empreinte (hash) du mot de passe du compte, mais qui n'est pas salé. Il est donc bien plus facile de retrouver le mot de passe original, notamment via des Rainbow tables par exemple.
Quoi qu'il en soit, la procédure est toujours la même en pareille situation : changer de mot de passe sur le site, mais aussi sur n'importe quel autre service où il aurait été utilisé. On ne rappellera en effet jamais assez que réutiliser le même mot de passe n'est pas une bonne idée. Nos confrères précisent enfin que « les attaquants n'ont pas eu accès à nos serveurs ni à la base de données du site », sans plus de précisions sur l'origine de l'attaque ou sur le nombre de comptes impactés. Bien évidemment, ils indiquent qu'une plainte va être déposée.
Commentaires (61)
Comme quoi, il faut toujours saler avant de hasher !
Pas cool de bosser le week-end sur ce genre de galère
" />
Bientôt le même problème pour NxI?
" />
C’est un cauchemar en cuisine mixé avec qui est le meilleur pâtissier.
Et la faille Php exploité sur 000webhost.com (=hostinger en France), personne n’en parle?
Mauvaise gestion des cookies par les devs.
Bonne pratique : un cookie n’est pas fait pour stoker des données mais uniquement un identifiant unique crypté (lisible uniquement par le serveur). De cet identifiant, on récupère ensuite les infos associées coté serveur.
De cette manière, un seul cookie est nécessaire (on y associe autant d’info qu’on veut coté serveur), celui-ci est le plus léger possible, et n’y a plus de risque de fuite d’infos (quand bien même quelqu’un arriverait à décrypter le cookie il ne récupèrerais qu’un identifiant inexploitable en tant que tel..)
Roh, les méchants pirates pourraient avoir accès à ma boite /trash 
" />
Tout à fait d’accord. C’est quoi cette histoire de stocker le hash du mot de passe dans le cookie ? Sérieusement ?
aucun intérêt/sens de chiffrer un cookie, oui pour le reste. il ne doit etre qu’un id permettant de retrouver les informations. Par contre l’attribut HttpOnly, déja ca evite de recupérer l’info via un XSS moisi et si possible le tout communiqué sur SSL bien (mais bon la pub limite visiblement cf les problematique NxI) avec l’attribut secure.
Si si, le crypter évite que le client viennent le bidouiller et/ou le modifier.
" /> Si c’est crypté tu peux toujours essayer de le modifier…
Si j’ai un id (en clair) du genre 123456 dans mon cookie et que je remplace par 123457 il y a de grandes chance que je me retrouve connecté avec un autre compte.
Un cookie de session en fait ?
J’aime pas crypter. Chiffrer c’est plus mieux.
" />
Je sors
Oui.
" />
le problème reste le meme, il ne s’agit pas de crypter, il suffit juste de générer des ID non linéaires et suffisament entropique c’est la qu’est la sécurité, en diminuant la proba que l’utilisateur trouve une chaine de caractère qui corresponde à un ID (si ton chiffré est ridiculement court tu ne résoud pas le problème par exemple) , ce que globalement php et consort savent faire plutot bien de nos jours.
Mais là tu compares un bête ID que tu incrémentes à chaque connexion à un ID aléatoire (le résultat de ton chiffrement). Pas sûr que tu gagnes en sécurité avec le chiffrement si ton ID fait autant de bits et est simplement généré aléatoirement.
Pour la faille 000webhost, voici ce que j’ai reçu :
What happened?
A hacker used an exploit in an old PHP version, that we were using on our website, in order to gain access to our
systems. Data that has been stolen includes usernames, passwords, email addresses, IP addresses and names.
Although the whole database has been compromised, we are mostly concerned about the leaked client information.
What did we do about it?
We have been aware of this issue since 27th of October and our team started to troubleshoot and resolve this issue
the same day, immediately after becoming aware of this issue.
In an effort to protect our users we have temporarily blocked access to systems affected by this security flaw. We
will re-enable access to the affected systems after an investigation and once all security issues have been
resolved. Affected systems include our website and our members area. Additionally we have temporarily blocked FTP
access, as FTP passwords have been stolen as well.
We reseted all users passwords in our systems and increased the level of encryption to prevent such issues in the
future.
We are still working around the clock to identify and eliminate all security flaws. We will get back to providing
the free service soon. We are also updating and patching our systems.
What do you need to do?
As all the passwords have been changed to random values, you now need to reset them when the service goes live
again.
DO NOT USE YOUR PREVIOUS PASSWORD.
PLEASE ALSO CHANGE YOUR PASSWORDS IF YOU USED THE SAME PASSWORD FOR OTHER SERVICES.
We also recommend that you use Two Factor Authentication (TFA) and a different password for every service whenever
possible. We can recommend the Authy authenticator app and the LastPass password manager.
We are sorry
At 000webhost we are committed to protect user information and our systems. We are sorry and sincerely apologize we
didn’t manage to live up to that.
At 000webhost our top priority remains the same - to provide free quality web hosting for everyone. The 000webhost
community is a big family, exploring and using the possibilities of the internet together.
Our leadership team will closely monitor this issue and will do everything possible to earn your trust every day.
Sincerely,
000webhost CEO,
Arnas Stuopelis
Merci d’éviter les HS :)
du coup si je fais la synthèse des échanges, il faudrait un cookie qui contienne l’ID plus un élément aléatoire chiffré par le serveur, qui le déchiffre a chaque fois, récupère l’id dans la chaine pour ensuite requêter les bonnes info?
je sais pas si en perf c’est plus économique que de taper directement sur le contexte associé a ton PHPSESSID par exemple… mais pourquoi pas, je m’y connais pas des masses en optimisation
Mais une question…
Comment un pirate peut récupérer le cookie d’un utilisateur X ?
Il l’a intercepté ? du coup c’est une MitM non ?
il l’a récupéré sur un serveur de lesnumeriques.com ?
il l’a récupéré en étant sur l’ordinateur de l’utilisateur X ?
Enfin c’est un peu la question que je me pose en lisant cette article…
c’est chiant car j’utilise un login et mdp que j’utilise pas mal ailleurs … mais sais pas trop ou
" />
Du coup sans aléat tu te retrouves avec un autre problème, ton cookie est toujours le meme pour une personne donnée, donc il suffit que bidule se connecte une fois depuis un poste partagé ou que je me balade sur son poste pendant sa pause café et me voila capable d’usurper sa session quand je veux.
les bonnes pratiques en la matière étant de renouveller le cookie à chaque changement d’état (après authent et après déco ) et que lors de la déco la session soit correctement purgée, si dès que l’utilisateur se réauthentifie on lui ressort le meme cookie ca pose problème.
en fait le XSS est une attaque qui vise l’utilisateur et pas le serveur en injectant du code qui est interpreté par ton navigateur.
bref, l’attaquant a peut être trouvé une faille dans les commentaires par exemple, et a donc posté un commentaire spécial avec du code javascript. S’il s’applique un peu, les artefact sont pas trop visible quand tu regardes la page, mais ton navigateur quand il recoit le contenu de la page, au moment d’afficher le fameux commentaire va afficher ce qu’il comprend etre du texte et interpreter le code qu’il reconnait.
Ce code est généralement “fait une requete vers tel serveur en affichant le login courant et la valeur du cookie de session”
donc ce n’est ni du MitM, ni une attaque du serveur, mais le piégeage de ton navigateur web
Via la faille XSS.
" />
Celle-ci permet à l’attaquant de glisser du code javascript malveillant qui sera exécuté sur un client (celui qui n’aura pas de chance).
Le script permet de venir lire les infos du cookie du client (autrement dit, c’est un vol de cookie), et ces infos sont ensuite renvoyée d’une manière ou d’un autre vers un autre serveur (celui de l’attaquant).
S’il n’y avait pas de faille XSS, l’attaquant ne devrais pas pouvoir ajouter du script javascript a une page.
C’est un peut comme si tu trouvais une faille dans NXI qui te permette de rajouter une photo dans les commentaire. Cette photo serait ensuite visible par les autres utilisateur (le vol peut commencer).
L’autre faille c’est d’être vu coller le hash du mot de passe dans le cookie.
Si la première faille est excusable, la seconde ne l’est pas..
Cookie de session ?
Donc ces cookies doivent être transmis en https uniquement. Le bon réflexe est donc de mettre l’attribut Secure sur ses cookies.
De plus, ils ont été volés par une faille XSS, donc il manquait l’attribut httpOnly qui doit être mis sur ce type de cookie.
On ajoutera qu’une politique Content-Security-Policy et l’utilisation de fonction comme htmlspecialchars() auraient évité cet incident.
PS: mince grillé ci-dessus pour les attributs
Mais avec la certification ISO 1664
(Désolé)
excuser un XSS? tu est trop bon avec eux
" />
C’est
pas parce que c’est hyper courant que c’est excusable, avec des
frameworks comme BeeF on fait des choses très sales depuis quelques années maintenant
Oui, j’excuse. C’est toujours moins gênant qu’une faille SQL.. ou des mots de passe stockés en clair.
" />
Si le reste du site n’est pas trop mal construit, une faille XSS n’est en principe pas trop virulente.
meuuuuh non ca dépend juste de ta catégorie: utilisateur de debian ou non.
" /> comme ca par exemple
Je viens de me rendre compte qu’ils n’ont pas de connexion sécurisée pour l’identification sur le forum… Sinon de mon coté c’est fait, mot de passe changé
" />
Je savais pas que l’aléatoire “pseudo-aléatoire” était un problème de distribution.
" /> 
" />
En tout cas le rand() PHP (quelque soit la distrib) est une calamité.
Ce qui me fait bien marrer, c’est la description de la fonction mt_rand () : Génère une meilleure valeur aléatoire
En parlant de sécurité de mdp, étant abonné chez orange (internet fixe) j’avais perdu mon mot de passe. Je demande donc un mdp et il me sort quoi ? mon ancien mot de passe, en clair…. Bizarre non ?
C’est quoi le salage exactement? explication Simple hein.
Mais ça, il n’y a rien à y faire en HTTP. La seul parade c’est d’être en HTTPS.
Ah d’accord, donc ça veut dire que les failles xss permette à une personne mal intentionné d’écrire sur le serveur qui contient le code javascript à la base et d’en altérer son contenu.
Ce genre de chose m’étonnera toujours. y’a pas un paramètre dans le serveur qui empêcherait qu’une écriture de ce genre soit possible ? (au niveau de la restriction rwx )
Enfin pour moi un serveur web dans l’idéal serait un point accessible du net (donc vulnérable) mais dont il serait impossible d’écrire dessus sauf lors d’un déploiement/MàJ.
Le HTTPS n’empêche pas le XSS.
Chopage des cookies via XSS, puis immédiatement, usurpation des sessions en cours. Cookie crypté ou non, communications en HTTPS ou non. Bon, normalement certains gestionnaires de sessions gueulent si on réutilise le même cookie depuis plusieurs IP pour éviter ça, mais ça fait aussi merdoyer ces sites sur les hotspots instables ou les connexions avec load balancing.
Disons qu’une attaque par dictionnaire arriverait à trouver mon mdp ^^.
c’est pas nécessairement stocké dessus, dans ce cas, le XSS est dit reflectif et ne s’applique qu’aux personne qui font la requête directement avec le code dedans (par exemple suite à un phishing ou on amène la victime a cliquer sur un lien spécifique).
Maintenant un serveur où tu n’as aucun moyen d’écrire ce sont certain sites web style an2000, de nos jour ya toujours une partie commentaires ou une partie compte utilisateur ou que sais-je qui fait qu’il est possible d’écrire (rien qu’a la place de mon pseudo je pourrais mettre du code, et sur un site vulnérable, toute personne chargeant une page affichant mon pseudo exécutera le code). les informations sont stockées en base de données mais ça reste une inscription de donnée sur le serveur… la seule protection c’est de filtrer correctement les informations que le serveur reçoit de la part des utilisateur pour s’assurer qu’il n’intègre ou en renvoie rien qui puisse tromper le navigateur de ses visiteurs.
Mettre dans le cookie un jeton temporaire de connexion, lié dans la bdd à un compte utilisateur dont on mémorise l’ip de dernière authentification, et vérifier la correspondance IP/JETON ca doit marcher non?
(je précise, le jeton est lié a un COMPTE unique, pas juste a une ip. L’ip est une info enregistrée dans le compte :)
Le pirate récupère le cookie, mais a moins d’avoir la meme ip que le visiteur il ne pourra rien faire.
C’est une suite de caractères ajoutée au mot de passe pour rendre le hachage plus difficile à inverser. Jette un oeil à la page Wikipedia sur le sujethttps://fr.wikipedia.org/wiki/Salage_(cryptographie)
Ce qu’on m’avait présenté comme bonne pratique, c’est un truc long, aléatoire (généré par un outil de qualité, qui lave plus aléatoire que les générateurs
" />), et vérification que l’id n’ait jamais été utilisé (pas même par une session passée). L’id doit changer à chaque session, bien entendu.
Ce qui est essentiel, c’est que l’id ne puisse pas être deviné, donc pas de n° qui se suivent ou de timestamp (pas même hashés), ni de construction à partir des infos du clients (son IP, MAC, id…).
Le point ‘jamais utilisé’ me semble légèrement overkill, et peut-être pas très facilement scalable. Après, tel que j’ai compris le sujet, si on a une section aléatoire suffisamment longue et une section non aléatoire qui assure l’unicité, c’est bien sécurisé : la longue partie aléatoire assure la non-devinabilité, l’autre partie assure l’unicité, peu importe si elle peut être devinée.
Attention toutefois à ce que cette partie qui assure l’unicité ne contienne pas d’info sensible, donc pas d’id ou de mdp. Un compteur incrémenté fait l’affaire.
Oui, mais avec un simple id chiffré, si un pirate arrive à récupérer la clé (par exemple en analysant ses cookies successifs), il peut ensuite très facilement prédire tous les identifiants futurs. C’est certes très difficile, mais si quelqu’un y arrive, c’est catastrophique. D’où l’intérêt de mélanger les deux, ce qui est à la fois techniquement facile, et très robuste.
D’ailleurs, php génère ses id de session à peu près comme ça (à la différence qu’ils ne garantissent pas de façon absolue l’unicité, c’est seulement très improbable d’avoir une collision). Je ne sais pas pourquoi ils n’ont pas garanti l’unicité avec un truc genre auto-increment, il doit y avoir une subtilité qui m’échappe.
L’écrasante majorité des chiffrements symétriques sont basés sur des clé générées aléatoirement, et périmées rapidement. Le risque qu’un pirate puisse retrouver la clé en analysant en détail une connexion existe, mais ça ne lui donne pas le moyen de déchiffrer toutes les communications futures.
Pour ton id de session c’est pareil : si tu chiffres avec une clé aléatoire, unique et à faible durée de vie, c’est probablement super-sécure. Par contre tu reportes la difficulté le la génération de l’id sur la génération de la clé. Si tu chiffres toujours avec la même clé, la difficulté pour remonter à la clé est toujours la même, mais si quelqu’un y arrive, c’est une porte d’entrée durable.
Sinon même sans considérer que c’est l’algo de chiffrement qui tombe, une clé de chiffrement peut s’obtenir par d’autres moyens (chantage…). Le nombre aléatoire à le bon goût de ne pas être divulguable à l’avance.
Pour un petit site perso, ça n’a pas une très grande importance, mais si tu gères des données vraiment sensibles, mieux vaut éviter.
Après, tu as peut-être raison de dire qu’il existe souvent des moyens plus simple d’entrer, mais c’est pas parce que la porte de derrière ferme mal qu’il faut laisser les fenêtres ouvertes!
Si je sais que f(x & sel) = qdmcjadica, f(x+1 & sel) = qo^finpqocve, f(x+2 & sel) = dqsùvknaevn ; potentiellement, ça me donne un angle d’attaque (d’ailleurs, le sel, s’il est constant, n’apporte absolument rien). On est d’accord que ça reste quelque chose de pas trivial.
Mais surtout, si j’y arrive, que ce soit par chance, par astuce ou en tapant suffisamment fort sur ton admin, je peux prédire tous tes futurs id de session, et usurper l’identité de qui je veux.
En fait ta méthode c’est un peu comme hasher les mots de passe avec un sel constant.
En soit, c’est pas mauvais, parce que ça reste très difficile d’inverser l’algo de hachage, mais le problème c’est que si quelqu’un se procure son mdp haché hors-ligne, il peut prendre tout son temps pour le casser et en déduire le sel. Avec cette info, il aura beaucoup plus de facilité à casser les autres mots de passe s’il arrive à se procurer leurs hashs.
La critique ne porte pas sur la facilité à casser un mécanisme donné, mais sur le fait que réussir à en casser un ouvre la porte à tous les autres. Pour reprendre ta métaphore de la porte blindée, c’est comme si forcer tranquillement une porte blindée dans mon garage me permet d’en déduire comment fabriquer la clé de toutes les portes blindées de la même marque à travers le monde. Elle peut être aussi solide qu’elle veut, ça en fait une porte blindée médiocre.
C’est pour ça qu’il est recommandé de façon générale d’utiliser des valeurs aléatoires pour tout ce qui doit être difficile à deviner, et n’a pas besoin d’être retenu par un humain. C’est pour les sels de mots de passe, les jetons CSRF, les id de session…
Arf, j’ai dit une connerie sur le hash.
Ce qu’il va avoir ton son temps pour faire, c’est construire sa rainbowtable, évidemment pas trouver le sel, qui n’a rien de secret.