Comment pirater à distance les ordinateurs utilisant 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ée, 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 à 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 à des scélérats de prendre en charge les systèmes à 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éponses hachées 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 cœur 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 octet n’est contrôlé, 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 si 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. »