• AgoraVox sur Twitter
  • RSS
  • Agoravox TV
  • Agoravox Mobile

Accueil du site > Tribune Libre > Comment pirater à distance les ordinateurs avec des puces non sécurisées (...)

Comment pirater à distance les ordinateurs avec des puces non sécurisées d’Intel : Il suffit d’utiliser une chaîne d’authentification vide

Incroyable....

Parlons peu parlons bien, vous devez utiliser le test d'Intel pour savoir si votre système est à risque.

https://downloadcenter.intel.com/download/26755

Décompresser l'archive et lancer l'application Intel-SA-00075-GUI

Pour ce qui est de l'AMT désactivez-le avec cet utilitaire :

https://github.com/bartblaze/Disable-Intel-AMT

Téléchargez l'archive, décompressez-la, et lancez : DisableAMT.exe

Voilà, les plus paranos peuvent aussi bloquer les ports indiqués dans l'article ; )

Comment pirater à distance les ordinateurs utilisant des puces non sécurisées d'Intel : Il suffit d'utiliser une chaîne d’authentification vide

Exploiter les systèmes utilisant vPro et AMT

5 mai 2017 à 19:52, Chris Williams

Plongée dans le Code

Vous pouvez commander et contrôler à distance des ordinateurs qui utilisent les chipsets Intel vulnérables en leur envoyant des chaînes d'authentification vides.

Vous avez bien lu. Lorsque vous êtes censé envoyer un hachage de mot de passe, vous envoyez zéro octets. Rien. Nada. Et vous serez récompensé avec le puissant accès bas niveau au matériel d'une unité vulnérable à travers le réseau - ou sur Internet si l'interface de gestion fait face à la bande publique.

Rappelez-vous cela la prochaine fois qu’Intel, un géant des semi-conducteurs internationaux de $ 180 milliards, parle de l'importance de la sécurité.

Pour récapituler : Intel offre une boîte à outils de gestion à distance appelée AMT pour ses processeurs de large gamme utilisés dans les entreprises ; ce logiciel fait partie de la suite de vPro Chipzilla et fonctionne au niveau du firmware, en-dessous et hors de la vue de Windows, Linux, ou tout autre système d'exploitation que vous utilisez. Le code est exécuté sur l'ordinateur secret au sein de votre ordinateur, qui a le contrôle complet du matériel et parle directement aux ports réseaux, ce qui permet a un appareil d’être commandé à distance indépendamment de tout système d'exploitation et des applications qui sont en cours d' exécution, ou pas, au niveau supérieur.

Ainsi, AMT est conçu pour permettre aux administrateurs informatiques de se connecter à distance dans les entrailles d'ordinateurs afin qu'ils puissent redémarrer une machine planté, réparer et modifier le système d'exploitation, installer un nouveau système d'exploitation, accéder à une console série virtuelle, ou accéder a un bureau à distance complet via VNC. Il est, pour l'essentiel, le mode dieu.

Normalement, AMT est protégé par mot. Cette semaine, il est apparu que cette authentification pouvait être contournée, ce qui pourrait permettre a des scélérats de prendre en charge les systèmes a distance ou une fois à l’intérieur d’un réseau d’entreprise. Ce problème de sécurité critique a été désigné CVE-2017-5689. Alors que Intel a patché son code, les gens doivent pester leurs fournisseurs de matériel pour les mises à jour nécessaires avant de pouvoir procéder à l’installation de leur système.

Aujourd'hui, nous avons appris qu'il est trivial d'exploiter cette faille, permettant à quiconque de prendre le contrôle des systèmes vulnérables sans mot de passe.

AMT est accessible via le réseau dans une interface d'authentification web standard : le service écoute sur les ports 16992 et 16993. La visite de cette porte avec un navigateur ouvre une invite de login pour un mot de passe, et ce mot de passe est envoyé en utilisant la norme HTTP Digest authentification : le nom d’utilisateur et le mot de passe sont hachés à l'aide d'un nonce à partir du microprogramme AMT ainsi que quelques autres bits de métadonnées. Cette réponse brouillée est vérifiée par le logiciel AMT pour être valide, et le cas échéant, l'accès est accordé à l'interface de gestion.

Mais si vous envoyez une réponse vide, le firmware est dupé en pensant que cela est correct et vous laisse passer. Cela signifie que si vous utilisez un proxy pour modifier la réponse à une chaîne vide, ou autrement si vous configurez votre navigateur pour envoyer des réponses d'authentification HTTP Digest vides, vous pouvez contourner les contrôles de mot de passe.

Pour l'essentiel, dans les coulisses, votre navigateur normalement envoie quelque chose comme ceci au service AMT, qui comprend la chaîne de réponse hachée contenant le nom d'utilisateur, le mot de passe et le serveur nonce :

GET /index.htm HTTP/1.1
Host : 192.168.1.2:16992
User-Agent : Mozilla/5.0 (X11 ; Linux x86_64 ; rv:45.0) Gecko/20100101
Firefox/45.0
Accept : text/html,application/xhtml+xml,application/xml ;q=0.9,*/* ;q=0.8
Accept-Language : en-US,en ;q=0.5
Accept-Encoding : gzip, deflate
Referer : http://192.168.1.2:16992/logon.htm
Connection : keep-alive
Authorization : Digest username= »admin »,
realm= »Digest:048A0000000000000000000000000000 »,
nonce= »Q0UGAAQEAAAV4M4iGF4+Ni5ZafuMWy9J », uri= »/index.htm »,
response= »d3d4914a43454b159a3fa6f5a91d801d », qop=auth, nc=00000001,
cnonce= »9c5beca4011eea5c »

Eh bien regardez ça - en utilisant un proxy entre vous et l'appareil ou un outil similaire d’édition de trafic de bande, il suffit juste de modifier le hachage de réponse à envoyer à la place :

GET /index.htm HTTP/1.1
Host : 127.0.0.1:16992
User-Agent : Mozilla/5.0 (X11 ; Linux x86_64 ; rv:45.0) Gecko/20100101
Firefox/45.0
Accept : text/html,application/xhtml+xml,application/xml ;q=0.9,*/* ;q=0.8
Accept-Language : en-US,en ;q=0.5
Accept-Encoding : gzip, deflate
Connection : keep-alive
Authorization : Digest username= »admin »,
realm= »Digest:048A0000000000000000000000000000 »,
nonce= »qTILAAUFAAAjY7rDwLSmxFCq5EJ3pH/n », uri= »/index.htm », response= » »,
qop=auth, nc=00000001, cnonce= »60513ab58858482c »

Remarquez comment response est maintenant vide. Et pourtant, et le videur d'Intel vous laisse passer, même si vous avez flashé le portier sans mot de passe sans - aucune identité valide - :

HTTP/1.1 200 OK
Date : Thu, 4 May 2017 16:09:17 GMT
Server : AMT
Content-Type : text/html
Transfer-Encoding : chunked
Cache-Control : no cache
Expires : Thu, 26 Oct 1995 00:00:00 GMT

Si vous fouillez l'intérieur du firmware d'Intel, vous trouverez ce petit bijou qui se trouve au coeur de la matière – du code machine, qui une fois décompilé en C ressemble à peu près à ceci :

if(strncmp(computed_response, user_response, response_length))
   deny_access() ;

Comme vous le savez peut-être, cette fonction standard compare pas plus que response_length octets dans les deux chaînes distinctes pour vérifier si elles sont identiques ou non. Les deux chaînes sont comparées ici la réponse d'authentification envoyée par la personne qui tente de se connecter est (user_response) la réponse attendue par le service (computed_response). Si les deux chaînes correspondent, la fonction retourne zéro, ce qui indique que le mot de passe est bon comme prévu, et le code continue d'accorder l'accès. Si les chaînes sont différentes, la valeur de retour de la fonction est non nulle, ce qui signifie que le mot de passe est erroné, et l’accès est refusé. Jusqu'ici tout va bien.

Malheureusement, response_length est calculé à partir de user_response, donc si une chaîne vide est fournie, la longueur est égale à zéro, aucun octets n’est contrôlés, aucun octet n’est donc différent, et - comme prévu - strncmp()retourne zéro, ce qui indique un succès et l’accès est accordé. Ainsi, une chaîne de réponse vide se faufile comme valide quand elle est en fait invalide.

Intel devrait vraiment vérifier que les deux chaînes sont de la même longueur, puisque les réponses valides sont toujours des hash 32 octets MD5.

Merci à Embedi, pour le reverse engineering du code [ PDF ] et pour avoir également rapporté la faille à Intel en Mars. Tenable a également poussé autour de ce service et est venu à la même conclusion plus tôt cette semaine.

Intel a publié un peu plus d' informations sur la vulnérabilité ici, qui comprend des liens vers un outil pour vérifier si votre système est à risque avec des coordonnées de support, et une liste de conseils pour réduire la menace. Cet outil est apparemment dédié à Windows uniquement ; il y a une note d'info ici pour les utilisateurs Linux.

Il y a aussi cet outil tiers, ici , pour désactiver AMT à partir de Windows.

On nous dit que l'erreur de programmation est présente dans divers, (mais pas tous), les chipsets processeur Intel de la famille Kaby Lake d’aujourd'hui jusqu’au silicium vendu dans les années 2010 : elle affecte principalement les PC d'entreprise, les postes de travail professionnels et les petits serveurs, plutôt que des dispositifs destinés à des gens normaux. Cependant, Chipzilla a admis aujourd'hui que « les consommateurs et les petites entreprises » peuvent finir par utiliser des processeurs à présent à la technologie vulnérable.

Si vous utilisez un processeur vPro et vous utilisez les versions AMT 6 à 11.6 sur votre réseau, vous êtes certainement à risque concernant la vulnérabilité ci-dessus. Cela affecte également la norme Manageability (ISM) d'Intel et des produits de petite Business Technology (SBT). Nous vous recommandons d'utiliser l'utilitaire d'Intel pour doublement vérifier si oui ou non vous êtes silencieusement menacé par ce bogue.

Quelle est la gravité de ce bug ? Plutôt mauvaise. « L'exploit est trivial, d’un maximum de cinq lignes de python, et pourrait être faisable dans une commande shell d’une ligne », a dit l’inventeur SSH Tatu Ylonen.

« Il donne un contrôle total des machines affectées, y compris la capacité de lire et tout modifier qui peut être utilisée pour installer des logiciels malveillants persistants. - Peut-être dans le firmware -. Et lire et modifier les données pour les serveurs de sécurité, il peut permettre de désactiver les fonctions de sécurité, créer des fausses informations d'identification, ou obtenir les clés racine.

« Désactiver AMT aujourd'hui, mobilisez qui vous avez besoin à partir de serveurs les plus critiques : ... comme les serveurs Active Directory, ou les autorités de certification, les bases de données critiques, les serveurs de signature de code, les pare-feu, les serveurs de sécurité, les SMH (si elles en ont permis) pour les centres de données, si vous le pouvez, bloquez les ports 16992, 16993, 16994, 16995, 623, 664 dans les pare-feu internes dès maintenant.

« Si vous avez quoi que ce soit connecté à Internet avec AMT, désactivez-le maintenant. Et supposez que le serveur a déjà été compromis. »

La dernière fois que nous avons regardé sur Shodan, il y avait plus de 8000 systèmes potentiellement vulnérables sur l'Internet public. Il y en aurait des milliers et des milliers d’autres sur les réseaux d’entreprise internes.

Maintenant, nous jouons le jeu de l'attente : Montrez-nous les correctifs

Alors, où en sommes-nous avec ces patchs, qui doivent être distribués par les vendeurs de machines, probablement parce qu'ils doivent signer les mises à jour du firmware avant qu'ils ne soient mis entre les mains des clients. Nous avons demandé aux principaux fournisseurs de matériel fonctionnant sous Intel pour avoir leurs avis. Voici avec quoi nous sommes revenus :

HP Inc

Un porte - parole nous a dit que le fabricant de PC sera en contact avec ses clients avec des détails des mises à jour du firmware nécessaire, ajoutant que le HP Inc « travaille en étroite collaboration avec Intel pour valider et mettre en œuvre leur mise à jour du firmware et aider nos clients à l’atténuation des risques potentiels. » La liste complète des produits visés est ici : la conséquence est un impact stupéfiant des produits touchés par ce bogue.

« Cette vulnérabilité est une faille de sécurité qui a pris naissance dans le développement et le déploiement du firmware de gestion d'Intel », a dit le représentant Inc HP Au Register.

« HP et Intel travaillent en étroite collaboration pour assurer qu'il y ait des correctifs et des outils appropriés pour les clients et leurs environnements spécifiques. HP coordonne avec nos clients sur un plan de déploiement. Notre priorité absolue est d’atténuer les problèmes de sécurité et de réduire la complexité du déploiement pour nos clients. »

Les correctifs devraient arriver vers la fin de ce mois-ci et en Juin, selon la famille de produits.

Lenovo

Le Slinger PC a une page importante ici détaillant les machines qui sont affectées, et lorsque des correctifs sont susceptibles d’arriver - la plupart du temps du 24 mai à juin. ThinkCentre, ThinkPad, ThinkServer, et les lignes de ThinkStation sont touchés.

« Lenovo est pleinement conscient de la vulnérabilité du firmware dans certaines versions de la facilité de gestion d'Intel et que cela impacte certains Lenovo, ainsi que d'autres périphériques PC et d'autres fabricants », nous a dit un porte-parole de Lenovo.

Le « Sécurité des produits Incident Response Team (de PSIRT) de Lenovo travaille en étroite collaboration avec Intel sur une solution permanente à la vulnérabilité, en attendant, Lenovo recommande à tous les clients de prendre les mesures suivantes pour atténuer le problème :

« La vulnérabilité du réseau peut être atténuée en déprovisant la facilité de gestion Intel SKU (AMT et ISM) ou la désactivation de la technologie de gestion Intel au sein de l'Intel MEBx. La vulnérabilité locale peut être atténuée par la désactivation ou la désinstallation du Service Manageability local (LMS) sur la gérabilité Intel UGS (AMT, ISM et SBT). »

Cette vulnérabilité locale est un vrai problème, mais à part : si vous avez vPro et AMT présents et activés sur votre ordinateur, mais pas provisionnés, vous êtes toujours à risque d'une escalade des privilèges locaux, comme détaillé dans l’avis original d’Intel.

Fujitsu

Le géant informatique japonais a une page ici avec la liste des étapes pour vérifier si vous êtes affecté et comment obtenir les mises à jour du firmware nécessaires.

Hewlett Packard Enterprise

Personne n'a été disponible pour commenter ni confirmer la disponibilité de tous les correctifs, si nécessaire.

Dell

Personne n'a été disponible pour commenter ni confirmer la disponibilité de tous les correctifs, si nécessaire.

Cisco

Le fournisseur d'équipements de réseau et de serveur dit qu’il n'est pas affecté. « Cisco PSIRT est au courant de cette question », nous a dit un porte-parole de Cisco.

« A cette époque, notre enquête n'a pas identifié de technologie Cisco affectée. Si quelque chose de nouveau est constaté auquel nos clients doivent être informés et répondre, nous nous assurerons que nos clients savent ce qu'il en est et comment y remédier grâce à notre processus de divulgation déjà établi. »

Apple

Les Macs fonctionnant avec un x86 d'Apple ne sont pas affectés, car ils ne sont pas livrés avec le logiciel AMT d'Intel. ®

 

Source : Crashdebug.fr via Theregister.co.uk

Traduction :  folamour 
Corrections :  chalouette 

Information complémentaire :

Crashdebug.fr : Des outils de piratage fuités de la NSA menacent les ordinateurs équipés de Windows 2000 à Windows 8

 


Moyenne des avis sur cet article :  4.8/5   (10 votes)




Réagissez à l'article

21 réactions à cet article    


  • folamour folamour 10 mai 2017 18:56

    Merci bernard,


    • Alren Alren 11 mai 2017 12:16

      @folamour

      Qu’en est-il des processeurs AMD ?


    • Remosra 10 mai 2017 21:08

      Oui très technique, déjà que je suis un peu parano par rapport à ça, je suis en train de retourner mon PC pour désactiver tout les systèmes de réseaux et autres qui n’ont rien à faire là !

      Bref, merci pour cette petit flippe !
      (vous exagérez quand même) smiley


      • Dom66 Dom66 11 mai 2017 00:20

        Oui article très technique et qui prouve que nous sommes espionné, et vulnérable…

        Alors suite a cet article j’ai amené mon ordi dans un coin paumé et je les truffé de 7,65 magnum...il ne parlera plus.


        • Remosra 11 mai 2017 03:32

          @Dom66

          Loool, vous avez bien fait !
          Je suis en train de couler le mien dans du béton pour le jeter à la mer !
           smiley  smiley


        • devphil devphil 11 mai 2017 07:52

          @Dom66

          Moi j’ai retiré la puce Intel de l’ordinateur  smiley

          Comme ça je me dis que personne ne pourras le pirater ...

          Merci pour l’article , il est vrai que c’est très technique

          Philippe


        • Gasty Gasty 11 mai 2017 15:43


          Moi je lui ai retiré son libre arbitre. Seul les ports 80 et 25 sont autorisés aux heures ou je suis là.

          C’est sévère mais c’est comme ça !


        • folamour folamour 11 mai 2017 00:28

          pas la peine d’en arriver a de tels extrémités, je vous ai mis en intro la marche à suivre pour neutraliser cette faille ; )


          • BOBW BOBW 11 mai 2017 10:04

            @folamour : Pour stériliser la « bécane » on peut par ordre d’actions :
             1°/ déconnecter la prise de courant qui alimente le PC.
             2°/ « griller » le fusible de l’ordi.
             3°/ Aller jeter la puce.
             4°/ Porter l’ordi à un incinérateur. ou tout simplement le mettre dans un four à micro-ondes.
            Enfin revenir à la « préhistoire des micros »avec un ZX 80 en b.a.s.i.c, une cassette et une tv !... smiley


          • folamour folamour 11 mai 2017 11:12

            lol moi j’ai commencé sur Oric 1 justement je pensais a ses 5Hmz, alors que mon dernier pc est a 4800 Mhz,

            le but de cet article c’est que les gens patche leur bécanes, et il y a d’autres faille que j’ai mis dans l’article en « informations complémentaires » en bas de l’article,


            • Ouam (Paria statutaire non vacciné) Ouam 12 mai 2017 01:03

              @folamour
              Salut à toi,
              déja pour commencer merci pour ton info, ouf ce truc la n’etais pas activé ni existant sur mon w7 x64 (parano mode bien avant cette nouvelle histoire).

              Juste pour infos, tu nous parle de l’oric 1 (lancetrede l’atmos je crois),
              c’est bizarre ton histoire de 5mhz, le 6502 tourne de base à 1Mhz, apres sur l’atmos, il etait possible en houant du fer à souder un peu sévèrement de doubler la fréquence d’horloge cad 2mhz, en changeant quelques circuits aussi autour (portes nand etc) et pas que le quartz ca va de soi.
              5mhz par contre j’aurai carrément pas osé le faire et encore moins y penser.
              ps et meme si tu penses au coté perfs par équivance (voir le wiki), c’est 4, d’ou mon inconpréhention de ton 5mhz ?
              le 6502 c’est ici
              https://fr.wikipedia.org/wiki/MOS_Technology_6502

              l’oric atmos la
              https://fr.wikipedia.org/wiki/Oric_Atmos

              l’oric 1
              https://fr.wikipedia.org/wiki/Oric_1

              et apres l’atmos, je crois que le telstrat est sorti (ou un truc du genre ?)
              a + ouam


            • Ouam (Paria statutaire non vacciné) Ouam 12 mai 2017 01:11

              @Ouam
              "Malheureusement, response_length est calculé à partir de user_response, donc si une chaîne vide est fournie, la longueur est égale à zéro, aucun octets n’est contrôlés, aucun octet n’est donc différent, et - comme prévu - strncmp()retourne zéro, ce qui indique un succès et l’accès est accordé. Ainsi, une chaîne de réponse vide se faufile comme valide quand elle est en fait invalide."
               
              Ps2 : Lolll qd meme, caustaud le programmeur qui à écrit ce truc en sécurité ^^
               
              Sinon cette faille, de ce que j’ai pu en comprendre vit fait en parcourant, elle craint le paté, et cher.....
              en poussant un peu l’histoire, une fois les privilèges au max, rien n’interdit plus de flasher le bios du h disk (si le/le gus sonts tres bons) et la c’est fini h disk infecté donnes irrécuperables ou espionnage non visible, si c’est le bios carte réseau ou bios de la cm...
              bref.... pâté et gaz à tous les etages ^^


            • folamour folamour 12 mai 2017 17:29

              @Ouam je disait 5mhz par ce que je ne me souvenais plus du clock, enfin c’était surtout pour bien montrer comment les cpu ont évolué,


            • Bernard Lermite Bernard Lermite 11 mai 2017 11:42

              Merci l’auteur.

              Suffit il que les port 16992 ou 16993 soient fermés pour s’assurer ne ne pas être vulnérable ?
               
              Par exemple, cela suffit il pour être tranquille de ce coté ? :

              $ telnet localhost 16992
              Trying 127.0.0.1...
              telnet : Unable to connect to remote host : Connection refused


              • Bernard Lermite Bernard Lermite 11 mai 2017 11:51

                @Bernard Lermite

                ... en partant évidemment de l’hypothèse que le PC n’ai pas déjà été « rootkité ».
                 
                En toute rigueur, il faudrait le faire d’un autre pc :

                $ telnet PC_à_tester 16992
                Trying 127.0.0.1...
                telnet : Unable to connect to remote host : Connection refused
                 
                Ouf  !  smiley


              • Bernard Lermite Bernard Lermite 11 mai 2017 11:54

                @Bernard Lermite
                « Trying 127.0.0.1... »
                 
                Houps !

                Trying 192.168.0.10 ...


              • folamour folamour 11 mai 2017 16:52

                @Bernard Lermite

                 il faut bloquer les ports qui sont dans l’article,


              • Bernard Lermite Bernard Lermite 12 mai 2017 11:27

                @folamour
                 
                En principe, il ne faut bloquer que des ports qui sont ouverts car bloquer des ports qui sont déjà fermé est inutile.
                 
                Ma commande « telnet localhost 16992 » montre + haut que le port de l’article (16992) est fermé (du moins en TCP et en « écoute ») sur mon PC. Mais il est vrai que l’application « AMT » pourrait fonctionner en UDP ou avec un protocole « propriétaire ».


              • lautrecote 11 mai 2017 12:02

                ah putain ouais (oh elle est bonne cette mousse...)
                moi j’ai bloqué les ports, mais pas les truies


                • Ouam (Paria statutaire non vacciné) Ouam 12 mai 2017 01:20

                  @lautrecote
                  pourquoi ils onts sorti une version « couverte » de la faille ? ^^ smiley smiley
                   


                • Ruut Ruut 12 mai 2017 06:21

                  C’est quoi l’intérêt de laisser une faille de sécurité de bas niveau pour des ordinateurs d’entreprises ?
                  Car AMT ça reste la faille ultime vue que la transmission n’est de toute façon pas cryptée.
                  C’est le truc qui ne devrait être utilisable que sur un intranet déconnecté du net et encore...

Ajouter une réaction

Pour réagir, identifiez-vous avec votre login / mot de passe, en haut à droite de cette page

Si vous n'avez pas de login / mot de passe, vous devez vous inscrire ici.


FAIRE UN DON



Publicité



Les thématiques de l'article


Palmarès



Publicité