Conférence DEFCON 20. Capture en 60 secondes: d'un compte invité à un administrateur de domaine Windows. Partie 1

Bonjour, je suis Zach Feysel, je vais parler rapidement, si c'est trop rapide, vous pouvez me ralentir. Le jour, je suis pentester, le soir je suis DJ et photographe, je peux être trouvé sur Twitter par @zfazel. Les gens me demandent toujours des diplômes. Je ne fais pas partie de ces personnes qui énumèrent un tas de diplômes, alors vous feriez mieux de me juger sur la base de cette présentation, et non sur le nombre de certificats que j'ai.



Un commentaire sans honte: nous avons peu de compétition ici, en ce moment les gars de Chicago sont sur la piste 4, nous sommes tous de Chicago, levez rapidement la main qui est ici de Chicago. Donc, je pense que j'ai perdu le pari. Je serai DJ ce soir dans la piscine, donc si vous êtes libre, bienvenue dans la bataille avec Kate Myers, après quoi je reviendrai à Chicago pour une autre conférence de hackers. L'année dernière, 500 personnes étaient présentes, cette année nous espérons qu'il y aura plus d'invités. Mes 312 gars seront également là, plus d'informations sur cette conférence peuvent être trouvées sur thotcon.org.

Donc, pour ne pas perdre de temps: nous parlerons d'une alternative à l'attaque Pass-the-hash appelée NTLM-Relay, d'un nouvel ensemble d'outils pour le relais inter-protocoles Cross Protocol Relaying pour les demandes d'authentification NTLM, de nouvelles méthodes d'authentification automatique du client et de nouvelles fins pour lesquelles vous pouvez utiliser Pass-the-hash.
Commençons par NTLM, pour ceux qui ne savent pas ce qu'est NTLM 101, le point peut être énoncé en moins de 10 minutes. Alors qu'est-ce que LM / NTLM? Il s'agit d'un référentiel de mots de passe et d'un protocole d'authentification réseau développés par Microsoft pour une utilisation sur Windows. Merde, mes diapositives sont en panne! Ainsi, le hachage LM est un format de stockage des mots de passe utilisateur de moins de 15 caractères, le mot de passe est divisé en 2 parties de 7 octets et est converti en majuscules. J'espère que vous pouvez voir à quoi ressemblent les hachages LM et NTLM. Je ne vais pas perdre de temps à dire à quel point le LM est mauvais et faible, vous le savez tous, et sinon, google.



Un hachage NTLM est généralement sensible à la casse, a une longueur illimitée, n'est pas divisé en groupes de caractères et est légèrement plus fort que LM, mais il n'est pas non plus sans problème. Je vais maintenant en parler. La première vulnérabilité est la possibilité d'une attaque Pass-the-hash, qui permet à un pirate de se connecter à un serveur distant qui utilise l'authentification client basée sur les protocoles NTLM / LM. Désolé, les gars, j'ai mélangé les diapositives, je les ai faites il y a 5 minutes, bref, LM craint.

Qu'est-ce que l'authentification NTLM? Il s'agit de l'authentification réseau pour les services distants. Elle est nécessaire pour prouver que vous êtes vraiment ce que vous vous appelez. Le service s'exécute généralement sur un ordinateur distinct, sur lequel vous souhaitez accéder aux ressources offertes par le service, par exemple, un serveur de fichiers est un service et les fichiers sont des ressources. Dans une minute, nous verrons quels sont ces services.

Nous pouvons être confus lorsque nous parlons de NTLM v1, v2, NTLM 2, qu'il soit signé ou non, alors passons rapidement en revue l'authentification NTLM. Lors de l'authentification, 3 types de messages sont envoyés.



Le type 1 est la demande du client au serveur pour établir un contact, quelque chose comme "Je veux m'authentifier". Vous voyez le paquet fragmenté, capturé par Wireshark, il y a des drapeaux pour prendre en charge l'authentification, le nom du poste de travail et son nom de domaine.

Le message de type 2 est une réponse du serveur. Si vous avez remarqué dans le message de type 1 que nous ne savons pas encore qui est cet utilisateur, il a simplement demandé à se connecter au serveur et souhaite savoir si la demande est prise en charge.



Vous voyez ici la réponse du serveur NTML Challenge comme un ensemble de nombres qui change à chaque fois. La capture d'écran montre une réponse statique qui peut être utilisée pour créer des «tables arc-en-ciel». Ainsi, le serveur répond avec un message du second type: «voici ce que je supporte, voici mon nom de domaine, voici mon nom de serveur». Cette réponse est utilisée pour «saler» le hachage de votre mot de passe, donc à chaque fois qu'une réponse unique est obtenue, et vous ne pouvez pas la répéter encore et encore avec la même demande.

Message de type 3 - il s'agit du message d'authentification client.



Il s'agit de la réponse du serveur, qui est hachée avec le hachage de mot de passe pour le hachage NTML ainsi que le nom d'utilisateur, le nom du poste de travail et le nom de domaine et sa clé de session, si vous signez la session.

Voici la version 1 de NTML. La version 2 de NTML est très similaire, mais des paramètres supplémentaires ont été ajoutés au mot de passe de réponse et à l'appel du client afin de se protéger contre l'utilisation de «tables arc-en-ciel», c'est-à-dire que le client utilise contre eux un élément de hasard.

Une autre chose dont nous devons parler est l'authentification Windows intégrée. Il est nécessaire pour que, à chaque fois, vous n'ayez pas à entrer à nouveau dans le système avec un mot de passe pour utiliser les ressources et les services. Si vous êtes connecté à un serveur de domaine ou à un serveur Web interne, Windows ne vous demande pas de saisir un mot de passe, il demande simplement une API et en reçoit des informations que le système doit utiliser pour l'authentification.
Dans le contexte de la sécurité locale, HTTP protège en utilisant des zones de sécurité approuvées, des sites approuvés ou des sites locaux en vérifiant uniquement un nom de domaine en un seul mot. Je vais essayer de rafraîchir rapidement votre mémoire. Un domaine à mot unique recherche d'abord un nom DNS sur les serveurs DNS, puis vérifie son hôte ou son nom d'hôte DNS et le retransmet. Il vérifie la structure de votre nom complet, puis exécute NBNS, qui est la demande de diffusion pour ce nom de domaine. En fait, il demande au réseau: "hé, je cherche un nom , connaissez-vous quelqu'un avec ce nom?", Distribuant cette requête sur un réseau local en mode de diffusion multimédia MBNS.

Comme je l'ai dit, puisque nous utilisons le protocole SMB partout, il n'y a pas de restrictions, nous avons juste une authentification automatique en utilisant SMB. Cela pose quelques problèmes.

Considérez la méthode Pass-the-hash. Les protocoles montrent que NTML n'utilise pas le mot de passe d'origine pour l'authentification, donc tout ce dont nous avons besoin est le hachage NTML lui-même. Nous pouvons accéder au hachage NTML à l'aide de divers outils Windows, c'est-à-dire extraire ce hachage du stockage local ou de la mémoire. Tout cela a été décrit dans d'autres discours, je vais juste vous rappeler rapidement l'essence du problème pour montrer les différences entre les deux méthodes.
Le fait est qu'en général, pour ce Pass-the-hash, vous devez avoir accès au niveau de l'administrateur système local, car avec un compte invité, vous n'aurez pas accès au stockage local ou à la mémoire locale.

Alors, qu'est-ce que le relais NTLM et en quoi est-il différent de la méthode Pass-the-hash? Ils me disent constamment: "Ah, tu parles de Pass-the-hash!", Et je réponds: "Non, je parle de Relais NTLM!". La différence est que le relais NTLM ne nécessite pas de privilèges d'administrateur pour accéder au réseau ou au système. En fait, vous vous connectez au réseau de l'intérieur ou de l'extérieur et commencez à travailler en tant qu'invité. Il n'y a pas d'informations d'identification, il n'y a pas d'accès au système, seule la demande est authentifiée si vous revenez aux types de messages 1,2,3 ci-dessus. Il n'y a aucune vérification lorsque l'hôte répond à votre demande et s'assure que vous êtes bien vous.
Ce que nous faisons, c'est créer un serveur frauduleux pour recevoir les demandes d'authentification, puis les relayer vers le serveur cible.

Écoutons l'histoire pour comprendre l'essence du problème. En 1996, lorsque Dominic Brezinsky a découvert une vulnérabilité dans le processus d'authentification à l'aide du protocole d'accès CIFS, la première version du protocole SMB. Après cela, ils ont d'abord parlé de la possibilité d'utiliser le relais NTLM. En 2001, NTLM a réussi à trouver un trou dans SMB. Tout d'abord, un employé de Veracode, Christian Ryu (alias Dildog), l'a déclaré lors d'une conférence DefCon, puis le pirate Josh Bushbinder (alias Sir Dystic) a publié un code d'exploitation qui fonctionne avec cette vulnérabilité. Nous avons utilisé le protocole Telnet et la vulnérabilité du navigateur IE, où vous pouvez simplement taper telnet: // ip et vous authentifier automatiquement.



Après cela, la méthode de relais NTLM a commencé à être utilisée pour rediriger les demandes SMB vers d'autres hôtes ou vers son propre hôte. Cela s'est poursuivi jusqu'en novembre 2008, lorsque Microsoft Windows a corrigé les trous là où ils le pouvaient, empêchant la demande d'authentification NTLM de revenir avec le correctif MS08-068.

Ainsi, nous avons perdu la possibilité de renvoyer une demande d'authentification à notre hôte et nous ne pouvions la transmettre qu'à d'autres hôtes en raison des fonctionnalités de conception du protocole. En 2008, un gars sous le surnom de Grutz a fait une déclaration sur la mort de DefLon NTLM. Je pense que ce fut l'une des meilleures performances de ces dernières années, car cela a eu un impact énorme sur l'environnement de l'entreprise.



Il a appelé son instrument le nom du Pokemon Squirtle, et la technologie - "singe au milieu" par analogie avec "l'homme au milieu". Cet outil a permis au relais NTLM d'être exécuté via HTTP et a également bien fonctionné avec SMB, recevant des demandes d'authentification.



Cette capture d'écran a été prise il y a deux jours et le développement de son application Squirtle est toujours en cours. J'ai décidé que vous connaissiez tous ces vulnérabilités, dont nous parlons encore et encore des problèmes, car elles ne peuvent en aucun cas être corrigées et se manifester partout. J'appartiens à l'environnement de l'entreprise, donc je suis bien conscient du problème dont je me plains constamment: les sites ne font pas de cryptage SSL des demandes d'authentification, tout comme ils ne cryptent pas leurs cookies. En 2010, une extension de navigateur Firefox appelée Firesheep a été lancée.

Vous connaissez probablement cet outil pour intercepter les cookies HTTP non chiffrés de sites Web populaires et d'autres sessions de travail avec des sites via Wi-Fi ou sniffing réseau, se faisant passer pour d'autres utilisateurs.



Je me suis demandé où les gens avaient-ils envie de créer de tels outils. Il s'avère que tout est une question de facilité d'utilisation. Il est assez facile de créer une application qui vous permet d'usurper l'identité d'une autre personne. J'ai donc décidé de partir de la même chose et de faire une application qui permettrait d'utiliser la méthode de relais NTLM pour montrer aux gens que c'est aussi simple que Firesheep.



J'ai commencé à travailler sur le relais NTLM pour voir comment la prise en charge multi-protocoles est possible. Beaucoup de gens ont parlé de la possibilité théorique d'un tel soutien, mais personne ne l'a mis en pratique. Mon objectif était donc de créer Firesheep pour NTLM.
J'ai décidé de commencer à apprendre Ruby parce que j'allais à l'origine intégrer mon exploit dans Metasploit. En 2012, je voulais aborder ce sujet lors des conférences Black Hat et DefCon, mais mon rapport a été rejeté. Mes discours n'ont pas seulement été rejetés, j'ai reçu un faux email que DefCon a accepté mon rapport. Un ami a pensé que ce serait très drôle de me troller, c'est un idiot. Il avait un ami ici dont la performance a été approuvée, et mon ami a ramassé et m'a envoyé le contenu de son e-mail. Je n'ai pas fait attention à l'en-tête, qui disait "From Nikita" et a paniqué, réalisant que je devrais parler à DefCon dans une heure et demie, mais j'ai ensuite reçu une vraie lettre avec un refus.

Pensez-vous que cela termine l'histoire? Non, trois semaines plus tard, Nikita me dit: "Hé, nous avons une ouverture dimanche, quelqu'un a refusé de participer, tu veux parler à sa place?" Je pensais que c'était bien, mais j'ai réalisé que j'avais très peu de temps avant la performance et j'ai commencé à coder comme un fou, en essayant de tout finir à temps.

Quels étaient donc mes problèmes? Premièrement, les outils étrangers ne pouvaient pas faire le travail Pentester dont j'avais besoin, ils manquaient cruellement de divers protocoles qui pouvaient renvoyer des demandes d'authentification. La plupart des protocoles liés à l'utilisation de SMB et HTTP, et aucun d'entre eux ne prenait en charge LDAP pour l'authentification MySQL, ou au moins pour tester les postes de travail distants, les VPN et autres.

Un autre problème est qu'ils ont tous transmis chaque demande à la même destination. Autrement dit, nous avons reçu des données utilisateur, des comptes d'ordinateurs et envoyé toute l'authentification à une seule fin, par conséquent, nous n'avons pas pu identifier les utilisateurs avant l'authentification, c'est-à-dire avant de recevoir un message de type 3. Si vous vous souvenez de ces messages de type 1,2,3, alors le message de type 2 est la réponse du serveur. Il est unique pour chaque session, et je ne sais pas qui sont ces utilisateurs jusqu'à ce qu'ils envoient le dernier message de type 3, et je ne sais pas quelle réponse et à partir de quel serveur l'utilisateur est. Je m'intéressais à la raison pour laquelle il n'y a pas d'outils qui feraient cela, alors j'ai examiné de plus près les protocoles tels que SMB et HTTP, nous en parlerons plus en détail plus tard.

Windows 8 et Windows 2012 prennent toujours en charge NTLM par défaut. C'est effrayant parce que nous connaissons la vulnérabilité de ces protocoles, mais NTLM n'est pas parti. Par conséquent, en tant que pentesters, nous informons les organisations qu'elles doivent se protéger contre de telles attaques.
J'ai donc voulu résoudre ce problème et j'ai créé un outil appelé ZackAttack. Je sais que ça a l'air moche, mais nous avons parcouru tout un tas de noms, j'ai personnellement aimé le dernier - «NTLMv2? Chienne s'il te plait ... ".



Que contient cet outil? Je vais rapidement passer en revue ces diapositives, car je pense que vous avez déjà été assez diverti. ZackAttack se compose de plusieurs composants différents, nous parlerons de chacun d'eux et de la façon dont ils sont liés les uns aux autres.

Tout d'abord, il existe un serveur HTTP SMB - il s'agit d'un serveur frauduleux qui accepte les demandes d'authentification. Les clients ciblent donc ce serveur, s'authentifient et le serveur les maintient authentifiés. Ensuite, nous avons un ensemble de règles pour le fonctionnement automatique.

Nous avons des clients pour de tels exploits automatiques, ainsi que des API que nous pouvons associer à toute application tierce qui transfère les demandes de relais NTLM.



Enfin, nous avons une génération de charges utiles qui obligent les clients à s'authentifier automatiquement pour nous.

Que sont les serveurs frauduleux? Premièrement, ils authentifient les utilisateurs et les enregistrent pour nous, plus tard je vous dirai comment nous les utilisons.



Nous avons besoin de toutes ces personnes pour maintenir leur état d'authentification. Il existe de nombreux outils qui désactivent les utilisateurs après la première authentification réussie, mais notre outil ZackAttack maintient les utilisateurs authentifiés aussi longtemps que possible. Sur Windows LAN pour SMB, cela se produit environ 30 fois avant que la connexion ne soit déconnectée. Nous devons donc savoir qui est cet utilisateur, tout en le gardant authentifié.

La première demande d'authentification est un appel statique de type 112233. Ceux d'entre vous qui sont impliqués dans le pentestage savent qu'il s'agit d'une sorte de tâche pour les «tables arc-en-ciel». Comme je l'ai dit, nous devons découvrir qui est cet utilisateur, mais nous ne le savons pas avant d'avoir reçu le message de type 3, nous envoyons donc un tas d'appels. J'appelle cela «l'élément d'Alzheimer» lorsque le système oublie qui est l'utilisateur et lui demande de s'authentifier à chaque fois pour se connecter sans fermer la session.

La raison pour laquelle nous le faisons est que HTTP, WPAD et d'autres requêtes ne prennent pas toujours en charge les cookies.En outre, l'identification SMB via IP ou le port source Le port source ne fonctionne pas si vous essayez de le faire à distance via Internet.

Par conséquent, pour le serveur HTTP, nous utilisons une redirection 302 avec le paramètre Keep-Alive, qui nous permet de garder la session ouverte pendant que le socket est fermé, et après nous être authentifiés, nous savons qui ils sont et nous le savons jusqu'à la fin de cette session.

Avec SMB c'était plus difficile, j'ai dû écrire un serveur SMB personnalisé, c'est un peu bogué, mais ça marche quand même. Je ne vais pas me plonger dans le mécanisme d'authentification du protocole SMB, car cela prendra quelques heures, je vais donc l'expliquer brièvement. Une fois que le serveur a reçu la demande d'authentification, il semble oublier qui est cet utilisateur et dire: "Oh, bonjour, ravi de vous rencontrer!" "Cool, je veux me connecter!" "Attendez, et qui êtes-vous?" Et nécessite à nouveau une demande d'authentification.

Nous devons donc recevoir les demandes d'authentification qui arrivent sur les serveurs HTTP et SMB. Beaucoup de gens demandent comment nous menons l'attaque de «l'homme au milieu». Il existe plusieurs façons différentes de faire en sorte que les gens s'authentifient auprès de notre serveur, puis de les envoyer pour faire autre chose. Par conséquent, considérez la charge utile de notre outil.

Tout d'abord, il s'agit de WPAD - un protocole de configuration automatique de proxy, qui vous permet de déterminer l'emplacement du fichier de configuration. Sous Windows, lorsque vous essayez de vous connecter, comme vous le savez, une fenêtre apparaît avec une petite coche «trouver automatiquement mes paramètres de connexion» qui active WPAD. Ce protocole envoie des demandes de vérification des diffusions DNS et réseau, afin que vous puissiez simuler ces demandes et y répondre.

Par défaut, sous Windows, l'ordinateur authentifie automatiquement le serveur WPAD via HTTP avec les informations d'identification utilisateur actuelles.

18:00 min

Conférence DEFCON 20. Capture en 60 secondes: d'un compte invité à un administrateur de domaine Windows. 2e partie



Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'au printemps gratuitement lors du paiement pendant six mois, vous pouvez commander ici .

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

Source: https://habr.com/ru/post/fr436472/


All Articles