Une faille dans Windows permet une fuite des identifiants vers un serveur SMB

Une faille dans Windows permet une fuite des identifiants vers un serveur SMB

Petit haussement d'épaules à Redmond

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

14/04/2015 5 minutes
39

Une faille dans Windows permet une fuite des identifiants vers un serveur SMB

La société de sécurité Cylance a présenté hier des informations au sujet de Windows qui affecte l’ensemble des versions du système. Pour les chercheurs, la brèche est exploitable de manière presque automatisée. Pour Microsoft cependant, même si le bien-fondé de la découverte n’est pas remis en cause, il faut quand même que certaines conditions soient remplies.

Rediriger de simples requêtes vers un serveur vérolé

La faille en question est nommée « Redirect to SMB », pour Server Message Block, en général connu pour son implémentation libre Samba. Toutes les versions de Windows sont touchées, y compris Windows 10 (actuellement en développement), ainsi que les moutures pour tablettes et serveurs. Une fois exploitée, la brèche peut attirer Windows sur un serveur spécialement conçu, afin qu’il s’y connecte et livre des informations sensibles, notamment des identifiants et mots de passe.

En fait, cette faille n’est pas la première à reposer sur ce principe. Un cas similaire avait été trouvé en 1997, avec les mêmes rouages et les mêmes conséquences. Cependant, la méthode a évolué. Là où il fallait un lien sur un site ou dans un email pour mener l’utilisateur vers l’exploitation de la faille, cette dernière peut se produire sans n'avoir à recourir à la moindre action. Ce qui ne veut pas dire pour autant que la faille soit si simple à exploiter.

Microsoft a d'ailleurs indiqué à Reuters que « plusieurs facteurs sont nécessaires pour qu’une attaque de type « homme du milieu » puisse arriver ». La firme ajoute que les guides de bonne conduite en sécurité ont été mis à jour en 2009 pour « s’occuper des menaces de cette nature ». « Il y a également des fonctionnalités dans Windows, à l’instar de l’Extended Protection for Authentication, qui renforcent les défenses existantes pour gérer les identifiants de connexion réseau » ajoute l’éditeur de Redmond.

Une vieille vulnérabilité, plus simple à exploiter aujourd'hui

Ce qui n’empêche pas la faille d’avoir été ajoutée hier à la base de données CERT du Software Engineering Institute de l’université Carnegie Mellon. La fiche reprend en synthèse ce que qui était expliqué hier en détails par Cylance : les requêtes HTTP des applications Windows peuvent être transférées vers le protocole « file:// » sur un serveur spécialement conçu, auquel cas Windows tente automatiquement une authentification via SMB, si les critères sont réunis.

Cette faille a été découverte assez simplement par Cylance. Les recherches portaient initialement vers la manière dont on pouvait tromper une application faisant appel à des ressources extérieures, un cas extrêmement fréquent. Il s‘agissait dans les tests de tromper une application de messagerie et sa fonctionnalité de prévisualisation d’image. Cette dernière, au lieu de pointer vers le web classique, était située sur un serveur spécialement conçu. Devant un lien visant une image, l’application a cherché à afficher une miniature, et a entrainé une connexion de Windows au serveur, avec authentification.

cylance faille smb Windows

Selon Cylance, ce qui était possible précédemment l’est d’autant plus aujourd’hui que l’entreprise a identifié quatre API (Application Programming Interface) communes sous Windows qui peuvent être utilisées pour rediriger des requêtes HTTP/HTTPS vers SMB. La surface d’attaque est donc plus grande. Mais le danger vient également de la manière dont les logiciels et applications réalisent leurs requêtes HTTP. Adobe Reader, Apple Software Update, Internet Explorer, Media Player, Excel 2010, plusieurs antivirus, TeamViewer, Github pour Windows ou encore l’installeur Java font partie des fautifs.

Changements réguliers de mots de passe : la seule parade efficace

Mais quel est le risque finalement si les informations récupérées sont chiffrées, puisque c’est bien le cas ? Il tient justement au chiffrement utilisé, dont Cylance accuse l’âge, et pour cause : il date de 1998. Selon l’entreprise, il suffirait d’environ 3 000 dollars de matériel (essentiellement des GPU) pour casser n’importe quel mot de passe de huit caractères (majuscules et minuscules), le tout en moins d’une demi-journée. La solution proposée est donc la même finalement que celle donnée en 1997, et à laquelle Microsoft n’avait pas donné suite : désactiver l’authentification automatique vers les serveurs SMB qui ne sont pas de confiance.

Notez tout de même que ni Cylance, ni Microsoft ne sont actuellement au courant d’attaques qui utiliseraient ce vecteur. Sur la fiche du CERT, plusieurs méthodes sont fournies pour atténuer les risques d’attaques. Les développeurs et éditeurs tiers devraient ainsi éviter le protocole NTLM (NT Lan Manager) pour l’authentification de leurs logiciels. Mais rien ne remplacera la force du mot de passe protégeant le compte utilisateur : « Puisque les identifiants sont fournis à l’attaquant sous forme chiffrée, un mot de passe plus fort peut requérir plus de temps pour briser le chiffrement. Changer régulièrement les mots de passe éloigne les attaques par force brute ».

Microsoft de son côté, n'a pas précisé si un correctif était cette fois prévu. Rien n'en est moins sûr puisque la firme semble indiquer que quelques règles de base peuvent suffir à éloigner les risques.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Rediriger de simples requêtes vers un serveur vérolé

Une vieille vulnérabilité, plus simple à exploiter aujourd'hui

Changements réguliers de mots de passe : la seule parade efficace

Fermer

Commentaires (39)


Ouais donc en gros, il faut:

1/ qu’un abruti ait autorisé le CIFS entre LAN et WAN sur le firewall

2/ qu’un abruti ait laissé quelqu’un installer un serveur SMB non legit dans le LAN.

En fait c’est une faille pebkac.



edit: variante du 1/ qu’un abruti ait laissé quelqu’un installer un serveur http non legit dans le LAN.


Ah bah c’est couillon, il y a quelques mois ça m’aurait bien servi de connaitre ce genre de failles pour ma migration de comptes locaux Windows, j’ai jamais trouvé comment migrer les comptes ET les mots de passe. “Si tu sais, partage ” qu’y disaient. <img data-src=" />



Ou que le firmeware d’un des objets connectés de la maison n’ait pas de mise à jour et soit infecté suite à une faille non corrigée..


L’interface chaise clavier n’a rien a voir avec le réseau mal configuré, faut arrêter avec cette interface…



Et puis un serveur http sur le lan d’un reseau d’entreprise, ca n’a rien d’extraordinaire, encore heureux que le réseau l’autorise, c’est legitime. Et puis concrètement, tu fais comment pour l’interdire (vraie question) ?


Pour une migration AD 2003, j’avais utilisé ADMT.

Marchait bien. Je ne sais pas si le produit est maintenu par MS.



Edit : Oui c’est maintenu (Technet ADMT)


Plutôt que d’interdire les serveurs SMB et http illicites, autant interdire directement les failles, vers, et virus. Ce serait plus radical, tant qu’à faire.

&nbsp;


« Changer vos mdp régulièrement » n’a plus lieu d’être sous windows !

Finalement, quand tu tournes sous windows, ce n’est pas nécessaire de se protéger par un mdp, puisqu’inutile !

<img data-src=" />








46 75 63 6b 20 6f 66 66 a écrit :



Ou que le firmeware d’un des objets connectés de la maison n’ait pas de mise à jour et soit infecté suite à une faille non corrigée..





Dans le cas d’une attaque sur particulier, il faudrait donc 2 équipements vérolés, ce qui réduit pas mal le champ d’application.







flagos_ a écrit :



L’interface chaise clavier n’a rien a voir avec le réseau mal configuré, faut arrêter avec cette interface…





Parce que le firewall se configure tout seul peut être ? Faudrait réfléchir 2s avant de sortir des conneries.

A moins que ton firewall ait une config usine, ce qui dans certains cas ne pourrait pas être plus mal <img data-src=" />







flagos_ a écrit :



Et puis un serveur http sur le lan d’un reseau d’entreprise, ca n’a rien d’extraordinaire, encore heureux que le réseau l’autorise, c’est legitime. Et puis concrètement, tu fais comment pour l’interdire (vraie question) ?





Apprends à lire avant d’écrire. Et apprends aussi à comprendre ce dont on parle.

T’a même une belle image de démonstration, je vois pas ce qu’on peut faire de plus explicite.

Je t’ai parlé de serveur http non legit, donc un serveur http placé là par quelqu’un ayant de mauvaises intentions.

Comment l’interdire ? Sécuriser l’accès à tes locaux, ton infra, ton système et ton réseau, etc…

Le B.A.BA de la sécurité informatique que bon nombre de DSI n’ont pas le moindre début d’embryon en tête.







alexandredenis a écrit :



Plutôt que d’interdire les serveurs SMB et http illicites, autant interdire directement les failles, vers, et virus. Ce serait plus radical, tant qu’à faire.





C’est le défilé des neuneus qui savent pas lire aujourd’hui ou bien ?



Certes mais ADMT sert pour migrer des utilisateurs AD, et non des utilisateurs locaux. ;-)


J’ai pas tout compris.



En gros, en cliquant sur un lien, l’utilisateur se connecte à un serveur http, au départ “sur internet” mais en réalité situé sur le LAN.



Et Windows envoie alors tout gentil qu’il est, des identifiants SMB pour essayer d’ouvrir une session sur le serveur SMB. Mais comme c’est chiffré, c’est pas à la portée de tout le monde.



Donc en gros, un message demandant à l’utilisateur s’il veut se connecter à un SMB suffit à éviter l’envoi de données chiffrées involontaire?


C’est presque ça <img data-src=" />



Tu te connectes à un serveur http ( malveillant dont la page contient, par exemple, une image soit disant hébergée sur un serveur de fichier (smb) malveillant se trouvant sur ton réseau local.

Ce dernier va demander à ta machine de s’authentifier pour délivrer l’accès à la dite image et paf, ça fait des chocapics: le serveur smb a tes identifiants/mdp windows.



Le message de confirmation ne servira à rien, 99% des gens cliquant sur “oui” sans chercher à comprendre.

Le serveur http peut être sur lan ou wan, peut importe.

Le serveur smp peut être sur lan ou sur wan à la condition que le firewall soit une passoire.



Et au passage ça me permet de me rendre compte que j’ai mal exprimé le truc au début du thread mais j’ai la flemme de reformuler <img data-src=" />


Oups, mal lu. Je pars me flageller…


Ah j’ai presque tout compris <img data-src=" />



Donc c’est assez gênant comme faille, mais l’exploitation pratique me paraît compliquée.



Tiens, suis curieux de savoir combien coûte le brute force sur du cloud comme AWS…


Si j’ai bien compris et après avoir lu la news, il n’y a strictement rien de nouveau dans cette attaque, qui existe depuis longtemps et qui est souvent utilisée en pentest. Encore du buzz sur de l’ancien, dont le seul but est qu’une boite de secu fasse parler d’elle.

&nbsp;




Selon Cylance, ce qui était possible précédemment l’est d’autant plus aujourd’hui que l’entreprise a identifié quatre API (Application Programming Interface) communes sous Windows qui peuvent être utilisées pour rediriger des requêtes HTTP/HTTPS vers SMB. La surface d’attaque est donc plus grande. Mais le danger vient également de la manière dont les logiciels et applications réalisent leurs requêtes HTTP. Adobe Reader, Apple Software Update, Internet Explorer, Media Player, Excel 2010, plusieurs antivirus, TeamViewer, Github pour Windows ou encore l’installeur Java font partie des fautifs.





Le fautif c’est plutôt Microsoft je trouve. En quoi s’appuyer sur des appels API proposés par le système est une faute ?








CryoGen a écrit :



Le fautif c’est plutôt Microsoft je trouve. En quoi s’appuyer sur des appels API proposés par le système est une faute ?





Exact, et la faille potentielle était déjà connue depuis longtemps.



Je me demande comment un navigateur peut encore laisser passer ça aujourd’hui sans même couiner.



&nbsp;








MasterDav a écrit :



Apprends à lire avant d’écrire. Et apprends aussi à comprendre ce dont on parle.

T’a même une belle image de démonstration, je vois pas ce qu’on peut faire de plus explicite.

Je t’ai parlé de serveur http non legit, donc un serveur http placé là par quelqu’un ayant de mauvaises intentions.

Comment l’interdire ? Sécuriser l’accès à tes locaux, ton infra, ton système et ton réseau, etc…

Le B.A.BA de la sécurité informatique que bon nombre de DSI n’ont pas le moindre début d’embryon en tête.





Mmm, ca commence a devenir intéressant. Tu fais comment pour sécuriser l’accès de ton réseau sur un site de 5000 employés ?&nbsp;





  • tu passes en revue chacun des employés pour savoir lequel est un gros mechant payé par la concurrence ?

  • tu les soumet à un detecteur de verité ?

  • tu sors le “coco-gadegto-trouve-moi-le-méchant” ?



    Désolé mais non, l’attaque peut très bien venir de l’intérieur et elle est particulièrement critique: il suffit d’envoyer avec un lolcat par mail, la victime le recoit, ne se rend compte de rien, et paf, tout est aspiré.









neves a écrit :



Si j’ai bien compris et après avoir lu la news, il n’y a strictement rien de nouveau dans cette attaque, qui existe depuis longtemps et qui est souvent utilisée en pentest. Encore du buzz sur de l’ancien, dont le seul but est qu’une boite de secu fasse parler d’elle.

&nbsp;





Apparement, la découverte c’est qu’il y a plus de vecteurs d’attaques possibles, notamment:



Adobe Reader, Apple Software Update, Internet Explorer, Media Player, Excel 2010, plusieurs antivirus, TeamViewer, Github pour Windows ou encore l’installeur Javaqui sont des produits assez utilisés en entreprise.









flagos_ a écrit :



Mmm, ca commence a devenir intéressant. Tu fais comment pour sécuriser l’accès de ton réseau sur un site de 5000 employés ?





Des solutions diverses et variées existent, de nombreuses SSII sont spécialisées dans la sécurité des grands comptes.

Et ce n’est pas en 2 ou 3 posts sur NXI qu’on va en faire le tour, d’ailleurs ce n’est pas ma spécialité.







flagos_ a écrit :



Désolé mais non, l’attaque peut très bien venir de l’intérieur et elle est particulièrement critique: il suffit d’envoyer avec un lolcat par mail, la victime le recoit, ne se rend compte de rien, et paf, tout est aspiré.





Ça c’est de l’incompétence de DSI: il y a toujours moyen de se prémunir de ce genre d’attaque.



Je ne vois nulle part mention du LAN.


Check l’ip du serveur smb dans l’image.

De façon plus large, on met rarement un serveur smb sur du wan, ni opti ni secure. Mais c’est faisable.



De toute façon comme je disais plus haut ce premier post est mal formulé.

J’aurais du dire, il faut:




  • qu’un abruti ait laissé quelqu’un installer un serveur smb malveillant sur le lan

    ou

  • qu’un abruti ait (mal) configuré le firewall pour que l’on puisse accéder à un serveur smb malveillant sur le wan depuis le lan


Bonjour,



Tu veux mon login et mon mot de passe Microsoft ?

Tu vas en faire quoi ? J’ai activé la double authentification partout



Si tu n’as pas le code reçu par SMS ou depuis l’application sur mon smartphone, tu passes pas !!!



Copie d’écran ici&nbsp;

&nbsp;

&nbsp;http://img11.hostingpics.net/pics/52458639DA.jpg


C’est leur serveur d’exemple.

Leur papier parle bien du WAN.

Et le serveur smb en question est l’attaquant, pas la cible.


Peu importe, on en revient à ce que je disais juste avant:




  • si le smb d’attaque est sur le lan, c’est un gros problème d’incompétence des responsables informatique qui laissent n’importe qui installer n’importe quoi dans leur infra

  • si le smb d’attaque est sur le wan, c’est un gros problème d’incompétence des admins réseau qui laissent passer du CIFS/SMB à travers le firewall vers le wan.

    Faut pas chercher midi à 14h.








MasterDav a écrit :



C’est le défilé des neuneus qui savent pas lire aujourd’hui ou bien ?





Il vous en prie. Bon, comme tu as l’air aussi un peu comme tu dis, développons.

L’attaque part de l’intérieur : employé malveillant ayant accès au LAN, malware chopé par phishing, etc. À partir de là, l’escalade est possible via cette attaque pour récupérer les mots de passe.

Tu nous dis : facile, suffit d’interdire les serveurs SMB et http illicites. Moi je veux voir comment.

Solution 1 : tu peux mettre un post-it du DSI et espérer que les logiciels et employés malveillants vont respecter la note de service.

Solution 2 : tu peux aussi avoir une solution technique sûre à 100% qui va les bloquer pour de vrai, empêcher l’IP spoofing, empêcher les MAC spoofing, garantir que 100% de ton parc est clean sans malware, le tout sans gêner l’utilisation y compris en BYOD. Bref, être sûr à 100% que tu n’auras aucune attaque de l’intérieur qui cherchera l’escalade. Bien. Voilà un objectif ambitieux, mais tu dis que c’est “facile”.

Dans les deux cas, tu es riche : si tu as la solution 1, lance-toi comme humoriste ; si tu as la solution 2, fonde ta start-up illico.&nbsp;

&nbsp;









alexandredenis a écrit :



mais tu dis que c’est “facile”.





CTRL+F “facile”: 2 occurrences, ton dernier post. (avec ce post ça fera 4)







alexandredenis a écrit :



si tu as la solution 2, fonde ta start-up illico.





Tu donnes toi même brièvement la solution, appliquée par les SI et SSII compétents, rien de révolutionnaire.



Soit dit en passant, tu avais tourné ton précédent post de telle façon que j’ai compris “il faudrait interdire (sous entendu légalement) les virus, trojans etc…”, ce qui n’a pas beaucoup de sens dans cette discussion.

Ne t’étonnes donc pas de ma réponse.









MasterDav a écrit :



Soit dit en passant, tu avais tourné ton précédent post de telle façon que j’ai compris “il faudrait interdire (sous entendu légalement) les virus, trojans etc…”, ce qui n’a pas beaucoup de sens dans cette discussion.

Ne t’étonnes donc pas de ma réponse.





Raisonnement par l’absurde. “Il suffit d’interdire [un truc impossible à interdire en pratique] pour ne pas être exposé à l’attaque” -&gt; il suffit d’interdire l’attaque, c’est plus simple.

On pourrait aussi interdire le chômage, tiens. Pourquoi on n’y a pas pensé plus tôt.

&nbsp;



Certes, mais dans notre cas on peut tout à fait interdire les connexions CIFS/SMB entre LAN et WAN, tout comme on peut interdire l’accès au LAN à toute machine ou tout service “inconnu” (dans le sens, non whitelisté par exemple).



Enfin j’invente rien dans tout ça, ce ne sont que des “bonnes pratiques” de services informatiques sérieux.








MasterDav a écrit :



Certes, mais dans notre cas on peut tout à fait interdire les connexions CIFS/SMB entre LAN et WAN, tout comme on peut interdire l’accès au LAN à toute machine ou tout service “inconnu” (dans le sens, non whitelisté par exemple).



Enfin j’invente rien dans tout ça, ce ne sont que des “bonnes pratiques” de services informatiques sérieux.





Bien, et maintenant, on fait quoi avec ceux qui sont pas sérieux ou qui sont pas sensibilisés ou qui font avec les moyens du bord (embauche de non spécialistes parce que ça coûte cher et puis de toute façon on sait pas juger si le candidat est valable ou pas, etc.) ?



On prépare de suite un bûcher ?

Bien fait pour leur gueule ?



C’est bien beau d’enfoncer la porte ouverte, mais ça apporte quoi présentement ? &nbsp;&nbsp;



Bien fait pour leur gueule.

Des personnes compétentes dans leur domaine et qui recherchent du taf, c’est pas ce qu’il manque.

Que les guignols dégagent.



Ah pardon, j’oubliais qu’entretenir des branleurs incompétents et surpayés c’est une spécialité franco-française, surtout dans la fonction publique et affiliés.








flagos_ a écrit :



Apparement, la découverte c’est qu’il y a plus de vecteurs d’attaques possibles, notamment:



Adobe Reader, Apple Software Update, Internet Explorer, Media Player, Excel 2010, plusieurs antivirus, TeamViewer, Github pour Windows ou encore l’installeur Javaqui sont des produits assez utilisés en entreprise.





J’avais bien lu cette partie aussi, et là encore, rien de nouveau :(









MasterDav a écrit :



Bien fait pour leur gueule.

Des personnes compétentes dans leur domaine et qui recherchent du taf, c’est pas ce qu’il manque.

Que les guignols dégagent.



Ah pardon, j’oubliais qu’entretenir des branleurs incompétents et surpayés c’est une spécialité franco-française, surtout dans la fonction publique et affiliés.





Tu réponds à côté. Je ne parle pas des guignols qui se proclament expert, je parle des gens/boîtes qui en auraient besoin et qui sont à 100 lieues d’imaginer en avoir besoin et donc à 500 lieues d’être capable d’évaluer le clampin qui se présente comme pro en la matière.



Ça c’est le boulot du technico commercial de démarcher les futurs clients, d’évaluer correctement leurs besoins afin que la boite y apporte une réponse adaptée.

Quant à prendre au sérieux une SSII après, c’est plus une histoire de réputation là où elle aura fait ses preuves (ou non).

Ceci dit on sait très bien que les clients potentiels ne se tournent généralement vers les prestataires informatiques qu’une fois qu’ils ont eu un sinistre et tirent sur la corde tant qu’ils le peuvent en croisant les doigts pour que ça tienne.


Avis aux pirates. Sur mon PC actuel, mon nom d’utilisateur est “User”, et mon mot de passe… bah, j’en sais rien vu que c’est en login automatique au démarrage de l’ordi.



Voila. Bon courage.


Bref, tu te crois invulnérable parce que tu as un whitelisting sur les adresses MAC. Le spoofing, l’attaque de l”intérieur via un phishing, voire même l’attaque de l’intérieur directement, tout ça n’existe pas.

Punaise, tu en tiens une couche. J’espère que tu ne cherches pas du taf, comme tu dis, parce qu’un sysadmin qui se prétend d’emblée invulnérable, il ne tiens pas 15s en entretient d’embauche&nbsp;<img data-src=" />

&nbsp;


T’as dû être bercé trop près du mur pour être aussi tordu pour comprendre de travers ce que les gens écrivent ou leur attribuer des propos qu’ils n’ont jamais écris.

Cela expliquerait aussi pourquoi dans ton esprit malsain bonnes pratiques et réduction des risques = sentiment d’invulnérabilité.

T’es un sacré champion, change pas, des comme toi on en a bien besoin pour se foutre de leur gueule.








MasterDav a écrit :



T’as dû être bercé trop près du mur pour être aussi tordu pour comprendre de travers ce que les gens écrivent ou leur attribuer des propos qu’ils n’ont jamais écris.

Cela expliquerait aussi pourquoi dans ton esprit malsain bonnes pratiques et réduction des risques = sentiment d’invulnérabilité.

T’es un sacré champion, change pas, des comme toi on en a bien besoin pour se foutre de leur gueule.







On est beaucoup à avoir été bercé près du mur alors :p









MasterDav a écrit :



T’as dû être bercé trop près du mur pour être aussi tordu pour comprendre de travers ce que les gens écrivent ou leur attribuer des propos qu’ils n’ont jamais écris.

Cela expliquerait aussi pourquoi dans ton esprit malsain bonnes pratiques et réduction des risques = sentiment d’invulnérabilité.

T’es un sacré champion, change pas, des comme toi on en a bien besoin pour se foutre de leur gueule.





C’est sans doute plus lié au ton que tu emploies qu’à ce qui anime tes neurones réellement mais tu n’en restes pas moins responsable du ressenti général qu’ont les lecteurs de tes écrits.



&nbsp;Ce qui ressort de tes interventions c’est :&nbsp; tous des branques, moi j’sais quoi faire pour avoir zéro souçaille c’est pourtant simple et si tu me files une nuance ou un argument contraire je te balaye la table aussi sec d’un revers de manche.



Voilou… Et c’est pas donné à tout le monde de répondre au fond quand la forme crève les yeux (et les susceptibilités)