Publié dans Internet

55

Un chercheur explique comment contourner l’authentification à deux facteurs grâce aux cookies de session

Un chercheur explique comment contourner l'authentification à deux facteurs grâce aux cookies de session

Pour se connecter à un site, nous utilisons généralement un identifiant et un mot de passe. L'identification à deux facteurs permet d'ajouter une couche de sécurité, par exemple en envoyant un code sur son smartphone.

Dans une vidéo, le chercheur en sécurité Kevin Mitnick contourne ce système grâce aux cookies de session, comme l'explique TechCrunch. Pour commencer, il faut envoyer sa victime sur un faux site spécialement conçu, via une campagne de phishing par exemple.

Le pirate peut alors récupérer l'identifiant, le mot de passe et surtout le cookie de session de l'utilisateur. Il s'en sert ensuite pour se connecter au site, sans avoir besoin de repasser par la double authentification. Précision importante : il ne s'agit pas d'une faille de la double authentification en elle-même.

Cette histoire rappelle une fois encore que le maillon faible est bien trop souvent l'utilisateur. En effet, dans le cas présent il faut être berné par un faux site et y entrer ses identifiants. On rappellera donc une fois encore l'importance de ne pas cliquer sur n'importe quel lien, que ce soit sur un site ou dans un email.

55

Tiens, en parlant de ça :

La Section 702 de la loi sur la surveillance du renseignement étranger (Foreign Intelligence Surveillance Act – FISA)

Aux USA, la surveillance des communications d’étrangers sans mandat (FISA) fait débat

Aller FISSA au Sénat

15:40 DroitSécu 2
logo apple en devanture de boutique

Apple autorise puis supprime un émulateur Game Boy sur iOS

Quel est ce phoque ?

14:09 Soft 15
Logo d'Android 14

Android 15 bêta : Wallet par défaut, sécurité des réseaux mobiles et Wi-Fi, bugs sur le NFC

Ce n’est PAS une révolution

11:15 Soft 6
Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

55

Fermer

Commentaires (55)


D’après la source, l’attaque est conçu façon “man-in-the-middle” : quand l’utilisateur rempli les champs, le site piégé tente de se connecter au vrai site et ainsi récupère le cookie de session permettant de se loguer indéfiniment (si on ne tiens pas compte de ce que peut faire l’utilisateur ou le site pour modifier le contenu du cookie de session de temps en temps par exemple).


Pareil je suis allé voir la source, je voyais pas comment on pouvais “voler un cookie de session” juste avec du fishing. l’utilisateur donne le code 2FA au pirate qui se récupère lui même “légitimement” son propre cookie de session


Je savais pas que Kevin Mitnick etait devenu chercheur en sécurité.



La technique est plutot simple et efficace, je me demande comment personne n’y a pensé avant.








Cashiderme a écrit :



Je savais pas que Kevin Mitnick etait devenu chercheur en sécurité.



La technique est plutot simple et efficace, je me demande comment personne n’y a pensé avant.







Au moins, il sait de quoi il parle… il était quand même, à la grande époque, le premier hacker à figurer sur la liste des dix fugitifs les plus recherchés du FBI.



C’était le mec qui avait été arrêté par le FBI si mes souvenirs sont bons, il a un bon passé de hacker et a passé pas mal de temps “traqué” par le FBI.



Je pensais qu’il s’était reconverti en consultant dans le social engineering suite à son livre “l’art de la supercherie” mais apparemment non, il est toujours actif mais légalement maintenant.








BTCKnight a écrit :



Au moins, il sait de quoi il parle… il était quand même, à la grande époque, le premier hacker à figurer sur la liste des dix fugitifs les plus recherchés du FBI.









thomgamer a écrit :



C’était le mec qui avait été arrêté par le FBI si mes souvenirs sont bons, il a un bon passé de hacker et a passé pas mal de temps “traqué” par le FBI.



Je pensais qu’il s’était reconverti en consultant dans le social engineering suite à son livre “l’art de la supercherie” mais apparemment non, il est toujours actif mais légalement maintenant.







Je connais oui, il a meme eu droit à un film. Ça fait juste bizarre de revoir ce vieux nom oublié depuis longtemps, et dans ces circonstances <img data-src=" />



En gros c’est du phishing pur, il reproduit l’authentification de A à Z sur sa copie, la copie du site n’étant juste qu’une façade “miroir” où l’utilisateur surfe en pensant être sur le site final.



A la lecture de la news, je pensais que le pirate récupérait le cookie avant la seconde authentification, donc je comprenais pas comment c’était possible. Par contre le cookie de session doit avoir une date d’expiration normalement.


Beaucoup de monde y a pensé avant… certains systèmes de SSO (Single Sign On) exploite ce genre de technique en fait…



Le 2FA n’a jamais été conçu pour empêcher un MITM, mais pour protéger lors d’une diffusion des identifiants.


Un site de phishing peut très bien demander un jeton d’authentification à deux facteurs comme le nom d’utilisateur et mot de passe. Je vois pas ce qu’il y a de nouveau dans cette vidéo.


les cookies sont renouvelé par le site web automatiquement généralement.. et puis même 3 mois c’est largement suffisant pour faire ce qu’on veux…



par contre par curiosité, t’as aussi une 10ene de cookie GScrollPos-XXX sur nextinpact ? :p


Je trouve sa démonstration étrange, il utilise un faux linkedin pour voler les login/pass/session qu’il a appellé llnkedin



Cela veut dire que l’internaute est sur le faux site, il rentre ses identifiants pour se les faire voler. OK. Mais comment le vrai linkedin sait que l’internaute essaye de se connecter pour lui envoyer le SMS ? Cela veut dire qu’en parallèle le faux site requête chez likedin une tentative de connexion ? je ne comprends pas.



je ne comprend pas non plus qu’après avoir mis le code SMS et valider sa connexion il dit dans sa vidéo qu’il se retrouve sur son compte linkedin alors qu’il est toujours sur llnkedin



Je ne comprends pas comme ça marche sa démonstration car cela veut qu’il a fait un script qui tente de se connecter également au vrai linkedin pour que linkedin envoi le SMS. C’est une attaque de type CSRF dans ce cas. Or linkedin est protégé de ce type d’attaque CSRF.



si quelqu’un peut m’expliquer, je ne comprends pas.


Ça s’appelle une attaque MITM (Man In The Middle pour l’homme du milieu).



&nbsp;Le site factice sert à récupérer les identifiants de l’utilisateur dans un premier temps (car ce dernier croit qu’il est sur le vrai site). Une fois récupérés, comme tu l’a deviné, le site factice se fait passer pour l’utilisateur grâce à ses identifiants et se connecte au vrai site.




Le vrai site envoie donc ensuite à l'utilisateur un code par SMS pour vérifier sa connexion. Pendant ce temps, le site factice va demander à l'utilisateur d'entrer ce code comme l'aurait fait le vrai site pour valider la double-authentification (il doit y avoir une seconde connexion faux site -&gt; vrai site donc).     



&nbsp;

Une fois ces deux étapes achevées, le site factice récupère le cookie de session correspondant à la session de l’utilisateur avec double authentification.

&nbsp;

Comme l’a expliqué un internaute précédent, ce n’est pas vraiment une faille de la double authentification car elle n’a pas été conçue pour ça !


C’est bien ça, le faux site a donc l’identifiant et mot de passe et tente de se connecter au vrai site pour récupérer un cookie de session.



edit : grillé&nbsp;<img data-src=" />


Pour mieux comprendre une attaque MITM, il faut visualiser un distributeur de billets, sur lequel un attaquant place un socle qui reproduit à l’exact les boutons du distributeur. Lorsque tu entres ton code, tu appuies sur les touches du faux socle qui va reproduire la pression sur les vraies touches du vrai socle.



L’argent est récupéré par l’interstice du faux socle qui donne sur l’interstice du vrai socle. Au final, en récupérant le faux socle on peut voir via les traces où tu as tapé et quel est ton code.



Le principe du MITM est que le processus est bon mais intercepté par un intermédiaire ce qui met en péril la confidentialité de tes données de connexion (et par extension, la viabilité de l’authentification)


Tu as un compte sur un site A.

Le pirate crée un site B qui est une copie du site A graphiquement.

Il t’envoie dessus (phishing ou autre).

Tu arrives sur la page d’authentification.

Tu indiques ton identifiant et ton mot de passe.

Le site B envoie ça au site A

Le site A demande le code du 2FA (soit soft token, soit SMS)

Le site B te demande le code 2FA

Tu reçois le SMS ou tu regardes ton soft token

Tu donnes au site B le code

Le site B donne le code au site A

Le site A envoie le cookie de session à B

Le site B enregistre le cookie de session et te l’envoie puis te redirige sur le site A officiel.



L’authentification s’est déroulée entièrement, au milieu quelqu’un a récupéré ton cookie.



&nbsp;








yope7 a écrit :



Ça s’appelle une attaque MITM (Man In The Middle pour l’homme du milieu).



 Le site factice sert à récupérer les identifiants de l’utilisateur dans un premier temps (car ce dernier croit qu’il est sur le vrai site). Une fois récupérés, comme tu l’a deviné, le site factice se fait passer pour l’utilisateur grâce à ses identifiants et se connecte au vrai site.




Le vrai site envoie donc ensuite à l'utilisateur un code par SMS pour vérifier sa connexion. Pendant ce temps, le site factice va demander à l'utilisateur d'entrer ce code comme l'aurait fait le vrai site pour valider la double-authentification (il doit y avoir une seconde connexion faux site -&gt; vrai site donc).     



 

Une fois ces deux étapes achevées, le site factice récupère le cookie de session correspondant à la session de l’utilisateur avec double authentification.

 

Comme l’a expliqué un internaute précédent, ce n’est pas vraiment une faille de la double authentification car elle n’a pas été conçue pour ça !









j-dub a écrit :



C’est bien ça, le faux site a donc l’identifiant et mot de passe et tente de se connecter au vrai site pour récupérer un cookie de session.



edit : grillé <img data-src=" />









Sniperovitch a écrit :



Tu as un compte sur un site A.

Le pirate crée un site B qui est une copie du site A graphiquement.

Il t’envoie dessus (phishing ou autre).

Tu arrives sur la page d’authentification.

Tu indiques ton identifiant et ton mot de passe.

Le site B envoie ça au site A

Le site A demande le code du 2FA (soit soft token, soit SMS)

Le site B te demande le code 2FA

Tu reçois le SMS ou tu regardes ton soft token

Tu donnes au site B le code

Le site B donne le code au site A

Le site A envoie le cookie de session à B

Le site B enregistre le cookie de session et te l’envoie puis te redirige sur le site A officiel.



L’authentification s’est déroulée entièrement, au milieu quelqu’un a récupéré ton cookie.







Je vous remercie, beaucoup. Vous m’avez éclairé.



Néanmoins, faire une connexion à distance comme ça s’appelle une attaque CSRF :https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) Ce dont linkedin s’est protégé.



Pour éviter ce type d’attaque, le formulaire sur le site génère un token CSRF pour vérifier que celui qui tente de se connecter est bien présent sur le site légitime. Vous ne pouvez pas non plus faire la même chose sur OVH par exemple. Expliquez moi du coup comment vous faites un bot qui va se logger sur linkedin



Ensuite, cela induit que l’attaqué soit délogué de linkedin pour lancer le SMS.



En plus sur la video on voit qu’à la fin de la procédure l’attaqué reste sur llnkedin, il n’est pas redirigé effectivement vers linkedin. Ce qui n’est pas étonnant, la protection CSRF mise en place par linkedin l’empêche.



Encore une fois, je ne comprends pas <img data-src=" />









boogieplayer a écrit :



pour vérifier que celui qui tente de se connecter est bien présent sur le site légitime.







Par quel moyen ?







boogieplayer a écrit :



En plus sur la video on voit qu’à la fin de la procédure l’attaqué reste sur llnkedin, il n’est pas redirigé effectivement vers linkedin.







Peut-etre juste une frame qui affiche le vrai site dans le faux ?



Ce n’est pas le pc de l’utilisateur qui appelle le site (là ça marcherait pas) mais le faux site qui en arrière plan contact le site, récupère le token envoi le formulaire avec le bon token etc.. aucun moyen de le détecter, à part bloquer l’ip depuis laquelle le site se connecte, car même si tu mets un captcha il peut le screener par exemple et le proposer à la victime qui le remplira aussi :)


seulement 4 cookies pour Nxi pour ma part (firefox)








Cashiderme a écrit :



Par quel moyen ?







Peut-etre juste une frame qui affiche le vrai site dans le faux ?







Il y’a pas mal de moyen de se protéger d’un connexion distante, est de forcer un token (qu’on appelle souvent CSRF token) voilà un exemple :https://support.detectify.com/customer/portal/articles/1969819-login-csrf



Il y’a d’autres méthodes plus compliquées à mettre en place qui joue sur le fingerprint par exemple.



Pour la frame ça c’est impossible, linkedin l’interdit, voilà son SCP :



default-src ‘none’;

base-uri ‘self’;

form-action ‘self’;

connect-src ‘self’ wss: static.licdn.com s.c.lnkd.licdn.com static-fstl.licdn.com static-src.linkedin.com dms.licdn.com static-exp1.licdn.com static-exp2.licdn.com s.c.exp1.licdn.com s.c.exp2.licdn.com static-lcdn.licdn.com s.c.lcdn.licdn.com media.licdn.com m.c.lnkd.licdn.com platform.linkedin.comhttps://www.linkedin.com cdn.lynda.com media-exp2.licdn.com media-exp1.licdn.com video-uploads-prod.s3.amazonaws.com video-uploads-prod.s3-accelerate.amazonaws.comhttps://media-src.linkedin.com/media/;

img-src data: blob: *;

font-src data: *;

frame-src ‘self’ *.doubleclick.net www.slideshare.net radar.cedexis.com platform.linkedin.com media-exp1.licdn.com media-exp2.licdn.com m.c.exp1.licdn.com m.c.exp2.licdn.com media-lcdn.licdn.com m.c.lcdn.licdn.com cdn.embedly.comhttps://www.linkedin.com lichat.azurewebsites.net www.youtube.com www.facebook.com player.vimeo.com embed.ted.com livestream.com embed.gettyimages.com w.soundcloud.com www.lynda.com media.licdn.com;

child-src ‘self’ *.doubleclick.net www.slideshare.net radar.cedexis.com;

style-src ‘unsafe-inline’ static.licdn.com s.c.lnkd.licdn.com static-fstl.licdn.com static-src.linkedin.com static-exp1.licdn.com static-exp2.licdn.com s.c.exp1.licdn.com s.c.exp2.licdn.com static-lcdn.licdn.com s.c.lcdn.licdn.comhttps://www.linkedin.com/sc/https://www.linkedin.com/scds/https://qprod.www.linkedin.com/sc/;

script-src ‘report-sample’ ‘sha256-6gLjSWp3GRKZCUFvRX5aGHtECD1wVRgJOJp7r0ZQjV0=’ ‘unsafe-inline’ static.licdn.com s.c.lnkd.licdn.com static-fstl.licdn.com static-src.linkedin.comhttps://www.linkedin.com/voyager/service-worker-push.jshttps://platform.linkedin.com/js/analytics.js static-exp1.licdn.com static-exp2.licdn.com s.c.exp1.licdn.com s.c.exp2.licdn.com static-lcdn.licdn.com s.c.lcdn.licdn.comhttps://www.linkedin.com/sc/https://www.linkedin.com/scds/https://qprod.www.linkedin.com/sc/https://www.linkedin.com/sw.jshttps://www.linkedin.com/voyager/abp-detection.js;

media-src blob: *;

manifest-src ‘self’;

frame-ancestors ‘self’;







titomate a écrit :



Ce n’est pas le pc de l’utilisateur qui appelle le site (là ça marcherait pas) mais le faux site qui en arrière plan contact le site, récupère le token envoi le formulaire avec le bon token etc.. aucun moyen de le détecter, à part bloquer l’ip depuis laquelle le site se connecte, car même si tu mets un captcha il peut le screener par exemple et le proposer à la victime qui le remplira aussi :)







Je sais bien que c’est pas le pc de l’utilisateur, mais le serveur de l’assaillant. ;)



Un capcha n’empêche pas une attaque CSRF :https://blog.detectify.com/2017/12/06/captcha-csrf/



Encore une fois, je ne vois comment linkedin peut être trompé par la méthode qu’il montre car pour déclencher l’envoi du SMS il faut faire croire à linkedin qu’on est bien sur le domaine linkedin.com en train de tenter de s’authentifier. Linkedin, et c’est justement le but de la protection des CSRF, se protège de ça. Une injection distante des login+pass dans le formulaire d’authentification n’est pas possible, de fait l’envoi du SMS ne peut pas se faire.



donc comment son attaque peut elle marcher ? J’ai plutôt l’impression que c’est un peu bidonné son truc, mais ce n’est que mon avis, je peux me tromper.



une extention sur un navigateur dans une vm qui remplis les champs, qui recoit les infos en direct du serveur de la fausse page ? c’est pas très scalable mais ça marche bien et sans aller chercher dans les client webs simulé dans un serveur nodejs








boogieplayer a écrit :



Encore une fois, je ne vois comment linkedin peut être trompé par la méthode qu’il montre car pour déclencher l’envoi du SMS il faut faire croire à linkedin qu’on est bien sur le domaine linkedin.com en train de tenter de s’authentifier.





Le serveur de l’attaquant se connecte tout à fait normalement sur linkedin.com, il n’a rien à “faire croire”.

&nbsp;Il a tous les identifiants nécessaires, puisque la victime les lui donne.









boogieplayer a écrit :



&nbsp;Une injection distante des login+pass

dans le formulaire d’authentification n’est pas possible, de fait

l’envoi du SMS ne peut pas se faire.





Il n’y a aucune injection distante, c’est un MITM tout à fait classique.

La victime ne se connecte pas à linkedin, elle donne ses identifiants au pirate, et se trouve face à une page maquillée pour ressembler au vrai site.



J’espère que le tout nouveau protocole WebAuthn, dont on nous fait les louanges, vérifiera bien le nom de domaine avant d’échanger des clés publiques et des signatures pour nous authentifier.&nbsp; <img data-src=" />








empty a écrit :



Le serveur de l’attaquant se connecte tout à fait normalement sur linkedin.com, il n’a rien à “faire croire”.

 Il a tous les identifiants nécessaires, puisque la victime les lui donne.







Et comment le serveur de linkedin à l’information alors pour envoyer le SMS ?









empty a écrit :



Il n’y a aucune injection distante, c’est un MITM tout à fait classique.

La victime ne se connecte pas à linkedin, elle donne ses identifiants au pirate, et se trouve face à une page maquillée pour ressembler au vrai site.







Ah si, il y’a obligatoirement une connexion distante car l’assaillant à besoin que l’internaute reçoive le SMS

lorsqu’il est toujours sur le site pirate pour le piquer le cookie de session. Il faut donct que le pirate fasse rester l’internaute sur le site pirate le temps que le SMS arrive, qu’il rentre le code du SMS et là le connecter définitivement pour prendre le cookie. Et c’est là que je ne vois pas comment ça marche techniquement, car linkedin empêche ça justement la connexion distante.



Ce n’est pas du MIM c’est du CSRF









Firefly’ a écrit :



une extention sur un navigateur dans une vm qui remplis les champs, qui recoit les infos en direct du serveur de la fausse page ? c’est pas très scalable mais ça marche bien et sans aller chercher dans les client webs simulé dans un serveur nodejs







y’a même plus simple qu’une vm ou node.js, comme snoopy par exemple =&gt;https://github.com/duantianyu/Snoopy <img data-src=" />



Ce n’est pas cela qu’il montre sur sa video. Sur la video il n’en parle même pas. Ça ressemble à un tour de magie son truc, pas une attaque. Pour être compris, il faudrait qu’il explique vraiment ce qu’il fait.



Je ne dit pas que c’est pas possible, je dis qu’en l’état de sa démonstration ça ne me convainc guerre. Mais c’est moi sans doute qui ne comprend pas <img data-src=" />









boogieplayer a écrit :



Et comment le serveur de linkedin à l’information alors pour envoyer le SMS ?





Quelle information ?

Je viens de te le dire, la victime lui donne tout.

&nbsp;



boogieplayer a écrit :



Ah si, il y’a obligatoirement une connexion distante car l’assaillant à besoin que l’internaute reçoive le SMS

lorsqu’il est toujours sur le site pirate pour le piquer le cookie de session. Il faut donct que le pirate fasse rester l’internaute sur le site pirate le temps que le SMS arrive, qu’il rentre le code du SMS et là le connecter définitivement pour prendre le cookie. Et c’est là que je ne vois pas comment ça marche techniquement, car linkedin empêche ça justement la connexion distante.



Ce n’est pas du MIM c’est du CSRF





Non, pas de connection distante. Connection directe. Le serveur pirate se connecte NORMALEMENT sur linkedin, il agit comme s’il était un utilisateur classique.

Linkedin n’empêche personne de se connecter sur son site en envoyant login/pass puis code SMS. Et ben, le serveur pirate il fait ça. Il fait exactement ce que toi ou moi faisons pour se connecter.



Je crois que tu n’as pas compris le principe du MITM :

&nbsp;Le serveur pirate fait 2 choses distinctes au même moment :





  • présenter une fausse page à la victime pour aspirer ses identifiants (rôle: serveur web)

  • se connecter à linkedin.com en tant qu’utilisateur avec les identifiants (rôle: utilisateur)











empty a écrit :





  • présenter une fausse page à la victime pour aspirer ses identifiants (rôle: serveur web)

  • se connecter à linkedin.com en tant qu’utilisateur avec les identifiants (rôle: utilisateur)







    J’ai compris la philosophie de l’attaque hein, t’inquiètes pas. C’est pas le principe qui m’interrese, mais le concret. Je reste septique quant à la possibilité de faire vraiment ce qu’il dit, car je pense (pour ne pas dire je sais) que linkedin se défend -justement- d’un connexion depuis un serveur via un bot/script.



    Je mets moi même en place ces contre-mesures sur les serveurs que je déploie pour des boites lorsqu’on leur fait des SaaS avec des connexion web login/pass/ + 2F



    Mais bon, on va partir du principe que c’est possible avec linkendin. Dans ce cas l’attaque est facile à faire, et elle existe depuis longtemps.









boogieplayer a écrit :



Je reste septique quant à la possibilité de faire vraiment ce qu’il dit, car je pense (pour ne pas dire je sais) que linkedin se défend -justement- d’un connexion depuis un serveur via un bot/script.





Y a pas de bot ou script, juste un intermédiaire qui retransmet les requêtes et réponses qui transitent.

Comme le fait un simple routeur.



Tu dis que tu connais le principe du MITM, mais tu n’en as pas l’air.









empty a écrit :



Y a pas de bot ou script, juste un intermédiaire qui retransmet les requêtes et réponses qui transitent.

Comme le fait un simple routeur.



Tu dis que tu connais le principe du MITM, mais tu n’en as pas l’air.







Y’a forcément un script quelque part mon poulet. Des lignes des codes écrites par l’assaillant, un automatisme (bot) qui fait se connecter ou faire l’intermédiaire comme tu dis.



MITM c’est pas vraiment ce qu’il à fait.https://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu Ce qu’il fait c’est du fishing-&gt;usurpation-&gt;CSRF



Mais je ne demande qu’à être convaincu hein, j’aimerai voir le code qu’il a mis en place simplement.



Le code 2FA n’est pas autre chose que l’affichage d’un CAPTCHA sur un téléphone. Ce code étant lié à un jeton (pour que le site réel sache qu’il s’agit du bon code 2FA), il suffit que le site factice reproduire à l’identique les données et jeton du formulaire réel.



Je pense que nous sommes dans ce cas dans un MITM puisque la victime interagit avec un formulaire généré par le site réel mais présenté par le site factice.


&nbsp;







boogieplayer a écrit :



MITM c’est pas vraiment ce qu’il à fait.





Et bien si. C’est exactement ce qu’il a fait.&nbsp; <img data-src=" />

&nbsp;

&nbsp;Lâche ton CSRF 2 secondes, puisqu’on te dis que c’est pas ça. T’es borné et tu n’écoute pas, j’aimerais pas travailler avec toi.

&nbsp;

Va lire ces articles (un du créateur de l’outil, qui dit lui-même que c’est un MITM), qui expliquent plus en détail la mise en place de l’attaque par Mitnick :

https://breakdev.org/evilginx-advanced-phishing-with-two-factor-authentication-bypass/

&nbsp;https://www.extremetech.com/extreme/269121-this-tool-can-hack-your-accounts-even-with-two-factor-authentication









Demilitarized Zone a écrit :



Le code 2FA n’est pas autre chose que l’affichage d’un CAPTCHA sur un téléphone. Ce code étant lié à un jeton (pour que le site réel sache qu’il s’agit du bon code 2FA), il suffit que le site factice reproduire à l’identique les données et jeton du formulaire réel.







Oui certes. C’est la théorie, très bien, mais concrètement il fait comment pour contourner la protection mise en place par linkedin pour empêcher ça ? Mais encore une fois, je ne demande qu’à être convaincu. Je ne dis pas que c’est faux sont truc, je dis simplement que je n’ai pas vu le code et la méthodologie exacte dans la vidéo. Donc il raconte ce qu’il veut, on va le croire sur parole ?







Demilitarized Zone a écrit :



Je pense que nous sommes dans ce cas dans un MITM puisque la victime interagit avec un formulaire généré par le site réel mais présenté par le site factice.







Non justement, ce n’est pas possible, je l’ai expliqué plus haut il n’est pas possible de faire cela, le CSP de linkedin l’empêche (voir plus haut dans les commentaires). C’est pour ça que ce n’est pas vraiment une attaque MITM, mais plus du CSRF. Et c’est pour ça que la méthode qu’il montre ne devrait pas fonctionner. Donc je demande des explications précises et techniques.



Je ne demande qu’à croire moi, mais pour l’instant je ne vois aucune preuve. Juste une vidéo dont j’ai déjà soulevé les points étrange, comme par exemple lors que la procédure est terminé le hacker dit dans la video que l’internaute est ensuite redirigé (et connecté) sur linkedin, or ce n’est pas vrai l’internaute reste sur llnkedin. Il faudrait pouvoir répéter l’expérience.









empty a écrit :



Et bien si. C’est exactement ce qu’il a fait.  <img data-src=" />

 

 Lâche ton CSRF 2 secondes, puisqu’on te dis que c’est pas ça. T’es borné et tu n’écoute pas, j’aimerais pas travailler avec toi.

 

Va lire ces articles (un du créateur de l’outil, qui dit lui-même que c’est un MITM), qui expliquent plus en détail la mise en place de l’attaque par Mitnick :

https://breakdev.org/evilginx-advanced-phishing-with-two-factor-authentication-bypass/

 https://www.extremetech.com/extreme/269121-this-tool-can-hack-your-accounts-even-with-two-factor-authentication







C’est pas en te roulant par terre de rire que ça fait avancer la discussion. Je défend mon propos tranquillement avec autant d’envie que toi, j’ai le droit non ? Me permets tu d’exprimer mon opinion (qui peut être fausse) sans être galvaudé ? tu as ton opinion, tu me dis que c’est toi qui a raison, je te crois, mais permet moi au moins d’exprimer mon opinion et de débattre.



Par contre les liens sont interressants. Je vais aller voir.



Moi je ne demande qu’à croire, mais je me me fit qu’aux preuves et à la répétabilité scientifique d’un expérience, quelle qu’elle soit. Pas d’une simple vidéo où je devrai croire sur parole ce qu’il me dit.



C’est sans doute vrai, mais j’aimerai voir le code. Voir faire l’expérience moi même. Ou toi même, tu m’as l’air d’en avoir largement les compétences. Apparemment blouser linkedin est très aisé et c’est inquiétant.









boogieplayer a écrit :



Moi je ne demande qu’à croire, mais je me me fit qu’aux preuves et à la répétabilité scientifique d’un expérience, quelle qu’elle soit. Pas d’une simple vidéo où je devrai croire sur parole ce qu’il me dit.



C’est sans doute vrai, mais j’aimerai voir le code. Voir faire l’expérience moi même. Ou toi même, tu m’as l’air d’en avoir largement les compétences. Apparemment blouser linkedin est très aisé et c’est inquiétant.





Quand on connait les principes évoqué, on sait que c’est faisable.

Je me moque légèrement parce que tu restes buté sur ton idée et on voit bien que tu ne comprends pas ce qu’est un mitm, malgré que tu t’en défendes, et malgré les explication détaillées de moi et d’autres.

&nbsp;Il ne “blouse” pas linkedin mais l’utilisateur, qui donne ses données à un pirate. Ca fonctionne sur n’importe quel site, même correctement sécurisé. Il démontre juste que l’U2F n’est pas plus sécurisant qu’un mot de passe vis-à-vis d’une attaque par phishing, puisque l’U2F se réduit à un cookie de session qui se copie et se réutilise.









empty a écrit :



Quand on connait les principes évoqué, on sait que c’est faisable.

Je me moque légèrement parce que tu restes buté sur ton idée et on voit bien que tu ne comprends pas ce qu’est un mitm, malgré que tu t’en défendes, et malgré les explication détaillées de moi et d’autres.

 Il ne “blouse” pas linkedin mais l’utilisateur, qui donne ses données à un pirate. Ca fonctionne sur n’importe quel site, même correctement sécurisé. Il démontre juste que l’U2F n’est pas plus sécurisant qu’un mot de passe vis-à-vis d’une attaque par phishing, puisque l’U2F se réduit à un cookie de session qui se copie et se réutilise.







C’est pas parce que on n’est pas d’accord que ça veut dire que je ne sais pas de quoi je parle et que de fait tu sais. Moi mon postulat de départ c’est qu’on sait tous les deux de quoi on parle, mais qu’on est pas d’accord.



Quant on connait les principes évoqué j’ai un doute sur la faisabilité sur linkedin, j’emets un doute, car la méthode utilisée, justement, linkedin s’en défend. Je ne dis pas que ce n’est pas faisable, ça l’est depuis très longtemps, relis le thread : je dis que j’ai un doute de le faire sur linkedin



D’ailleurs, dans le lien que tu as fourni me donne raison :https://breakdev.org/evilginx-advanced-phishing-with-two-factor-authentication-b… le hacker le dit dans ses FAQ et conclusion, que ça ne marche pas partout et que des “gros” sites savent se défendre. Il donne l’exemple tout bête de la gestion de l’injection hors domaine ou tout simplement de la reconnaissance du fait que ce son script se comporte comme un proxy. Il donne l’exemple de google qui se défend tout à fait bien de ce type d’attaque.



Bref, je reste sur mon analyse depuis le début : j’ai un doute sur la possibilité de faire cette attaque sur linkedin (pas ailleurs hein) et je ne demande qu’à être convaincu par une preuve autre qu’une simple video sur youtube. Si tu le crois sur parole et sans autre preuve, c’est ton droit. Ça se trouve tu as raison, il a réussi.



Moi pour ma part, je ne suis pas aussi catégorique que vous. Mais je ne demande qu’à être convaincu.



D’ailleurs, si tu arrives à reproduire son attaque -et je suis prêt à faire le cobaye et participer à l’expérience- et la réussir avec sa méthode et sur Linkedin. Je te promet que je prends ma bagnole, je viens chez toi et je te paye un bon resto ! je suis sûr qu’on aurait plein de truc à échanger tous les deux <img data-src=" /><img data-src=" />









boogieplayer a écrit :



Non justement, ce n’est pas possible, je l’ai expliqué plus haut il n’est pas possible de faire cela, le CSP de linkedin l’empêche.





En quoi le CSP empêche-t-il un site factice d’interroger un site réel afin d’en récupérer un formulaire, puis d’afficher ce formulaire à la victime afin d’en récupérer identifiant, mot de passe et 2FA, puis de soumettre ces informations au site réel afin d’en obtenir un cookie ?



Le site factice procède côté serveur à une authentification normale et complète auprès d’un site réel, au nom de la victime en se servant des informations que lui aura communiqué cette dernière. C’est comme si un premier utilisateur cherchait à s’authentifier sur un site réel avec les informations que lui aura soufflé un deuxième utilisateur assis à côté de lui.









Demilitarized Zone a écrit :



En quoi le CSP empêche-t-il un site factice d’interroger un site réel afin d’en récupérer un formulaire, puis d’afficher ce formulaire à la victime afin d’en récupérer identifiant, mot de passe et 2FA, puis de soumettre ces informations au site réel afin d’en obtenir un cookie ?



Le site factice procède côté serveur à une authentification normale et complète auprès d’un site réel, au nom de la victime en se servant des informations que lui aura communiqué cette dernière. C’est comme si un premier utilisateur cherchait à s’authentifier sur un site réel avec les informations que lui aura soufflé un deuxième utilisateur assis à côté de lui.







Oui tu as 100% raison. Ça c’est la théorie, et ça marche très bien d’ailleurs sur le terrain. Après il y’a des moyens de contre mesure contre ça, et mon humble opinion qui n’engage quoi moi après lecture de la video et du blog de l’assaillant, c’est que je pense que linkedin sait se défendre contre ce type d’attaque. Comme sait le faire google ou facebook.



Je peux me tromper, c’est ce que je dis depuis le début. Je ne remet pas en cause la méthode, on sait bien que ça marche. C’est pas un débat, le débat c’est que se soit faisable, de cette façon, sur linkedin qui me parrait louche. C’est pourquoi je souhaite en savoir plus, et surtout de voir quelqu’un d’autre le faire, avant de lever complètement mon doute. Pour l’heure on a qu’une video sur YT



Je ne dis rien d’autre depuis le début. Mais sans doute me suis je mal exprimé.



Pour le CSP je parlais du fait d’embed, iframe le formulaire.









boogieplayer a écrit :



Pour le CSP je parlais du fait d’embed, iframe le formulaire.





Justement je pense que le formulaire n’est pas du tout celui de LinkedIn, mais une reproduction (réalisée à partir de celui-ci).









boogieplayer a écrit :



C’est pas un débat, le débat c’est que se soit faisable, de cette façon, sur linkedin qui me parrait louche.





Vu qu’il est possible de s’authentifier sur LinkedIn à partir de l’application Android ou iOS, c’est-à-dire une interface autre que le site LinkedIn.com, tu peux très bien réaliser la même opération à partir d’un script sur un serveur quelconque.









boogieplayer a écrit :



je souhaite en savoir plus, et surtout de voir quelqu’un d’autre le faire, avant de lever complètement mon doute. Pour l’heure on a qu’une video sur YT





Evilginx MITM attack :

https://github.com/kgretzky/evilginx

https://www.youtube.com/results?search_query=evilginx



&nbsp;







boogieplayer a écrit :



Je ne dis rien d’autre depuis le début.



&nbsp;&nbsp;&nbsp;



 Depuis le début, tu prétends que ce n'est pas du MITM.


C’est encore un avantage des gestionnaires de mots de passe : lastpass par exemple alertera si on entre le mot de passe LinkedIn sur un site “llinkedin”. Je suppose que les amateurs de 2fa ont un gestionnaire ;-)



Mais ça ne me semble pas extraordinaire comme méthode, d’ailleurs, depuis des années je me posais des questions au moment d’entrer un code 2fa sur une application Android. Autant sur mon pc, j’ai plusieurs garanties d’être sur le site officiel, autant sur les applications, on ne sait jamais trop où on se trouve. Et ça me semblait beaucoup plus facile de faire une fausse application par exemple. C’est moins vrai maintenant car les intégrations des comptes sont mieux gérées dans les dernières versions d’android et on ne doit plus s’authentifier tout le temps.


Je n’ai pas lu toute la conversation, mais tu répète plusieurs fois que ça te semble difficilement possible sur LinkedIn.



J’aimerais savoir ce qui te fait penser ça, et qu’elle(s) mesure(s) pourrait empêcher de faire ça.



Comme répété plusieurs fois par d’autres personnes, cette technique est connue (je m’en amusait pendant mes études) depuis des années, il n’y a rien de nouveau dedans et il est impossible (a ma connaissance) de s’en protéger.








boogieplayer a écrit :



Oui certes. C’est la théorie, très bien, mais concrètement il fait comment pour contourner la protection mise en place par linkedin pour empêcher ça ?&nbsp;



Le CSRF, ça ne marche que pour se protéger d’un site qui se lie à des morceaux du tien de mémoire.



Si maintenant, le faux site émule complètement un utilisateur - le CSRF ne sert à rien.

Pense par exemple à un exemple très concret: les outils comme ceux de Nokia à l’époque pour accélérer le web: c’était un serveur qui exécutait le navigateur, tu ne recevais que l’image.&nbsp;Un peu comme si tu voyais une image via TeamViewer et que le navigateur est sur l’ordi d’un autre: où se trouve le cookie de session dans ce cas?

&nbsp;

Le MIM n’a qu’à faire pareil: recevoir tes infos, les ressaisir dans un navigateur et te renvoyer la page. Par contre, il faut la renvoyer dans un format “web”, pas image.



Ca permet de faire un phishing générique et très fidèle…









TheMyst a écrit :



Je n’ai pas lu toute la conversation, mais tu répète plusieurs fois que ça te semble difficilement possible sur LinkedIn.



J’aimerais savoir ce qui te fait penser ça, et qu’elle(s) mesure(s) pourrait empêcher de faire ça.



Comme répété plusieurs fois par d’autres personnes, cette technique est connue (je m’en amusait pendant mes études) depuis des années, il n’y a rien de nouveau dedans et il est impossible (a ma connaissance) de s’en protéger.







Je l’ai dis plus haut, la technique vise a utiliser une technique qui fait passer le serveur de l’assaillant comme un proxy et que les sites de cette importance comme FB, google, twitter ont des contre mesure qui permet de reconnaître ou suspecter un proxy, des techniques qui voit que le login mot de passe passé l’est depuis un navigateur complètement inconnu jusque là, que le fingerprint est inconnu également, pour les plus connues.



Comme cette technique d’attaque est connue depuis longtemps, des mesures techniques peuvent être mise en place. Pas fiable à 100% mais dans le doute on laisse pas passer.



Pour des groupes internationaux pour qui je vais des SaaS, cette attaque est donc connue, et en plus de la 2F ont mets en place des techniques liés au fingerprint. Lorsqu’on détecte un navigateur, une machine, un fingerprint inconnu, la connexion n’est pas validée et l’utilisateur est alerté par mil ou SMS d’une connexion depuis un endroit, une machine, un navigateur, inconnus ou une IP suspectes. Un troisième éléments d’authentification est demandé.



Ce ne sont que des suppositions. Je doute -simplement- que linkedin n’est pas mis en place ce type de contre mesure. Mais encore une fois je ne demande qu’à croire ce qu’on me dit.







brice.wernet a écrit :



Le CSRF, ça ne marche que pour se protéger d’un site qui se lie à des morceaux du tien de mémoire.



Si maintenant, le faux site émule complètement un utilisateur - le CSRF ne sert à rien.

Pense par exemple à un exemple très concret: les outils comme ceux de Nokia à l’époque pour accélérer le web: c’était un serveur qui exécutait le navigateur, tu ne recevais que l’image. Un peu comme si tu voyais une image via TeamViewer et que le navigateur est sur l’ordi d’un autre: où se trouve le cookie de session dans ce cas?

 

Le MIM n’a qu’à faire pareil: recevoir tes infos, les ressaisir dans un navigateur et te renvoyer la page. Par contre, il faut la renvoyer dans un format “web”, pas image.



Ca permet de faire un phishing générique et très fidèle…







Comme je le dis depuis le début, ce n’est pas l’attaque qui me fait poser question on sait que ça marche, mais la cible. C’est tout. Mais j’ai du mal à me faire comprendre, je dois sans doute mal m’exprimer.



On peut émuler complètement un vrai navigateur et une machine. Linkedin pense donc que l utilisateur se connecte d un nouvel endroit nouveau poste et demande donc par sécurité le code 2FA.

Même tes sites de super clients peuvent se faire avoir. Tu parles d’un 3eme élément demandé, mais il suffit de l intégrer dans le faux site.

Et pour info on peut se connecter via proxy à google et FB








Skywa a écrit :



On peut émuler complètement un vrai navigateur et une machine. Linkedin pense donc que l utilisateur se connecte d un nouvel endroit nouveau poste et demande donc par sécurité le code 2FA.

Même tes sites de super clients peuvent se faire avoir. Tu parles d’un 3eme élément demandé, mais il suffit de l intégrer dans le faux site.

Et pour info on peut se connecter via proxy à google et FB





Voilà le point important : présenter à l’utilisateur toute la phase d’authentification et la réaliser à partir du site factice. Dans ce scénario, LinkedIn ne fera pas la distinction entre un proxy pirate et un utilisateur en déplacement dans un autre pays se servant d’un ordinateur qu’il n’a jamais utilisé auparavant (les empreintes ou signatures ne serviront à rien).









Cashiderme a écrit :



Je connais oui, il a meme eu droit à un film. Ça fait juste bizarre de revoir ce vieux nom oublié depuis longtemps, et dans ces circonstances <img data-src=" />





+1 !!!



Je suis désolé, mais quand je me connecte depuis un ordinateur distant (bureau, famille, autres) avec un “Random user-agent”, je n’ai pas plus de problème que ça.

Je ne suis pas obliger d’allez cliquer sur un mail, et je recois éventuellement un message disant “Quelqu’un s’est connecté depuis un ordinateur situé à XXXX”, je n’ai jamais été obligé d’avoir un 3FA pour m’identifier.



Au niveau du fingerprinting, il est assez limité, sauf si tu force l’activation des applets (Flash ? Java ? Peut-être il y a 5ans) ou du Javascript (J’ai toujours JS d’activé, mais vu que c’est récurrent de conseiller de le désactiver, est-il vraiment possible de forcer l’utilisateur à l’activer ?)



Le reste du fingerprinting ne peut se faire que sur des données d’entête HTTP, chose facilement copiable et falsifiable par le “hacker”.



Dans tous les cas, le fingerprint que pourrait récupérer le site, pourrait être récupérer par le site miroir du hacker, est donc renvoyé à l’autre site.



Le seul élément difficilement modifiable est l’adresse IP. Et sauf si le “hacker” a mis son serveur en ukraine, il devrait pouvoir passer à travers ce test facilement, surtout avec un peu de moyen (tu es en France, je fait mes requêtes depuis la France, tu es aux USA, depuis les USA etc.)



Je crois que Google vérifie les déplacement trop rapides, mais ce genre de tests à ses limites. Chez mon ancien FAI, je basculais entre Marseille et Corse en fonction des IPs. Et au niveau des téléphones portables qui sont majoritairement localisés à Paris, ça se passe comment ?



Bref, oui le fingerprinting permet de s’assurer qu’une personne est “possiblement” toujours la même, mais aucun moyen d’en être sur, et interdire l’accès c’est s’attirer les foudres de ses “clients” dans le cas de faux-positifs à répétition.



Cela ne m’étonnerait pas si un adage du genre existait : “Il vaut mieux laisser les hackers voler les comptes, plutôt que d’empêcher le client de se connecter”.



Désolé pour se pavé, mal écrit.



TL;DR : Se faire passer pour quelqu’un d’autre est possible, on peut tout gruger en HTTP, sauf peut-être l’IP.


Non c’est bien écrit, je suis d’accord avec toi sur beaucoup de points. Sauf le TOUT sur le TL;DR <img data-src=" /> Que je remplacerai par un beaucoup ou pas mal. Dans la vie concrete le 100% ou le 0% c’est rare, d’où mon avis sur les défenses de linkedin. Mais je crois qu’on a tous donné notre avis, chacun étant responsable de ses propos.


Pour faire avancer le débat, quelles seraient donc les informations sur LinkedIn qui ne peuvent pas être reproduites par un intermédiaire (site factice) ?








Demilitarized Zone a écrit :



Pour faire avancer le débat, quelles seraient donc les informations sur LinkedIn qui ne peuvent pas être reproduites par un intermédiaire (site factice) ?







Je ne dirais pas cela comme ça, mais plutôt le fait que l’on peut mettre en place des moyen pour détecter cette tentative. Comme expliqué à juste titre ici par tous on peut empecher de le faire, par contre on peut s’en rendre compte et à ce moment là mettre en stand-by la connection effective.



encore un “chercheur en sécurité” qui enfonce les portes ouvertes….


Le problème c’est d’être assez sécurisé sans pour autant rentre l’accès au site difficile.

Je pense que beaucoup d’entreprise, surtout grand public, préfère ignorer la sécurité pour des questions de facilité. LinkedIn, Facebook, Google, Microsoft, etc.



Mais peux-t-on vraiment leur en vouloir ? A qui la faute ?



Par contre, aucune excuse en entreprise, avec une formation suffisante, n’importe quel salarié peut se plier aux règles de sécurités.


Bon bah, en lisant les coms, en fait c’est pas forcément si simple pour tout le monde on dirait