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 -> 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é " />









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 " />

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.com LinkedIncdn.lynda.com media-exp2.licdn.com media-exp1.licdn.com video-uploads-prod.s3.amazonaws.com video-uploads-prod.s3-accelerate.amazonaws.com LinkedInimg-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.com LinkedInlichat.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.com LinkedIn/sc/ LinkedIn/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.com LinkedIn/voyager/service-worker-push.js LinkedInstatic-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 LinkedIn/sc/ LinkedIn/scds/https://qprod.www.linkedin.com/sc/ LinkedIn/sw.js LinkedIn/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.

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

empty a écrit :



Et bien si. C’est exactement ce qu’il a fait.  " />

 

 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.

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 " />" />

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.

Non c’est bien écrit, je suis d’accord avec toi sur beaucoup de points. Sauf le TOUT sur le TL;DR " /> 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.

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.