Cet article a été rédigé sur la base d'un test d'intrusion très réussi mené par les spécialistes du Groupe-IB il y a quelques années : une histoire s'est produite et pourrait être adaptée au cinéma à Bollywood. Maintenant, probablement, la réaction du lecteur suivra : "Oh, un autre article de relations publiques, encore une fois, ils sont décrits, à quel point ils sont bons, n'oubliez pas d'acheter un pentest." Eh bien, d’une part, c’est le cas. Cependant, il existe un certain nombre d’autres raisons pour lesquelles cet article est paru. Je voulais montrer ce que font exactement les pentesters, à quel point ce travail peut être intéressant et non trivial, quelles circonstances amusantes peuvent survenir dans les projets et, surtout, montrer du matériel en direct avec des exemples réels.
Pour rétablir l’équilibre de la modestie dans le monde, nous parlerons au bout d’un moment d’un pentest qui ne s’est pas bien passé. Nous montrerons comment des processus bien conçus dans une entreprise peuvent protéger contre toute une série d'attaques, même celles qui sont bien préparées, simplement parce que ces processus existent et fonctionnent réellement.
Pour le client de cet article, tout était également généralement excellent, au moins meilleur que 95 % du marché de la Fédération de Russie, selon nos sentiments, mais il y avait un certain nombre de petites nuances qui formaient une longue chaîne d'événements, qui d'abord a donné lieu à un long rapport sur les travaux, puis à cet article.
Alors, faisons le plein de pop-corn et bienvenue dans le roman policier. Mot - Pavel Supruniouk, responsable technique du département « Audit et Conseil » du Groupe-IB.
Partie 1. Docteur Pochkin
2018 Il y a un client - une société informatique de haute technologie, qui sert elle-même de nombreux clients. Vous souhaitez obtenir une réponse à la question : est-il possible, sans aucune connaissance ni accès préalable, en travaillant via Internet, d'obtenir les droits d'administrateur de domaine Active Directory ? Je ne suis intéressé par aucune ingénierie sociale (), ils n'ont pas l'intention d'interférer volontairement avec le travail, mais ils peuvent accidentellement - recharger un serveur qui fonctionne étrangement, par exemple. Un objectif supplémentaire est d’identifier autant d’autres vecteurs d’attaque que possible contre le périmètre extérieur. L'entreprise effectue régulièrement de tels tests et la date limite pour un nouveau test est désormais arrivée. Les conditions sont presque typiques, adéquates, compréhensibles. Commençons.
Il y a un nom du client - que ce soit « Entreprise », avec le site Web principal . Bien sûr, le client s'appelle différemment, mais dans cet article tout sera impersonnel.
J'effectue une reconnaissance du réseau - découvrez quelles adresses et domaines sont enregistrés auprès du client, dessinez un schéma de réseau, comment les services sont distribués à ces adresses. J'obtiens le résultat : plus de 4000 adresses IP actives. Je regarde les domaines de ces réseaux : heureusement, la grande majorité sont des réseaux destinés aux clients du client, et ils ne nous intéressent pas formellement. Le client pense la même chose.
Il reste un réseau avec 256 adresses, pour lequel à ce moment il existe déjà une compréhension de la répartition des domaines et sous-domaines par adresses IP, il existe des informations sur les ports analysés, ce qui signifie que vous pouvez rechercher les services intéressants. En parallèle, toutes sortes de scanners sont lancés sur les adresses IP disponibles et séparément sur les sites Web.
Il existe de nombreux services. Habituellement, c'est de la joie pour le pentester et l'anticipation d'une victoire rapide, car plus il y a de services, plus le champ d'attaque est grand et plus il est facile de trouver un artefact. Un rapide coup d'œil sur les sites Web a montré que la plupart d'entre eux sont des interfaces Web de produits bien connus de grandes entreprises mondiales, qui, de toute évidence, vous disent qu'ils ne sont pas les bienvenus. Ils demandent un nom d'utilisateur et un mot de passe, effacent le champ de saisie du deuxième facteur, demandent un certificat client TLS ou l'envoient à Microsoft ADFS. Certains sont tout simplement inaccessibles depuis Internet. Pour certains, il faut évidemment avoir un client spécial rémunéré pour trois salaires ou connaître l'URL exacte à saisir. Sautons une autre semaine de découragement progressif en essayant de « percer » les versions logicielles des vulnérabilités connues, en recherchant du contenu caché dans les chemins Web et des comptes divulgués par des services tiers comme LinkedIn, en essayant également de deviner les mots de passe en les utilisant. comme l'exploration de vulnérabilités dans des sites Web auto-écrits - d'ailleurs, selon les statistiques, il s'agit aujourd'hui du vecteur d'attaque externe le plus prometteur. Je noterai immédiatement le pistolet de cinéma qui a tiré par la suite.
Nous avons donc trouvé deux sites qui se démarquent parmi des centaines de services. Ces sites avaient une chose en commun : si vous ne vous lancez pas dans une reconnaissance méticuleuse du réseau par domaine, mais recherchez de front les ports ouverts ou ciblez un scanner de vulnérabilités utilisant une plage IP connue, alors ces sites échapperont à l'analyse et ne seront tout simplement pas détectés. visible sans connaître le nom DNS. Peut-être qu'ils ont au moins été manqués plus tôt et nos outils automatiques n'ont trouvé aucun problème avec eux, même s'ils ont été envoyés directement à la ressource.
À propos, à propos de ce que les scanners précédemment lancés ont trouvé en général. Je vous le rappelle : pour certaines personnes, « pentest » équivaut à « scan automatisé ». Mais les scanners de ce projet n'ont rien dit. Eh bien, le maximum a été montré par les vulnérabilités moyennes (3 sur 5 en termes de gravité) : sur certains services, un mauvais certificat TLS ou des algorithmes de cryptage obsolètes, et sur la plupart des sites, un détournement de clics. Mais cela ne vous mènera pas à votre objectif. Peut-être que les scanners seraient plus utiles ici, mais permettez-moi de vous rappeler : le client lui-même peut acheter de tels programmes et se tester avec eux, et, à en juger par les résultats lamentables, il a déjà vérifié.
Revenons aux sites « anormaux ». Le premier est quelque chose comme un wiki local à une adresse non standard, mais dans cet article, ce sera wiki.company[.]ru. Elle a également immédiatement demandé un identifiant et un mot de passe, mais via NTLM dans le navigateur. Pour l'utilisateur, cela ressemble à une fenêtre ascétique demandant de saisir un nom d'utilisateur et un mot de passe. Et c'est une mauvaise pratique.
Une petite remarque. NTLM dans les sites Web de périmètre est mauvais pour un certain nombre de raisons. La première raison est que le nom de domaine Active Directory est révélé. Dans notre exemple, il s'est également avéré qu'il s'agissait de company.ru, tout comme le nom DNS « externe ». Sachant cela, vous pouvez préparer soigneusement quelque chose de malveillant afin qu'il soit exécuté uniquement sur la machine du domaine de l'organisation, et non dans un bac à sable. Deuxièmement, l'authentification passe directement par le contrôleur de domaine via NTLM (surprise, n'est-ce pas ?), avec toutes les fonctionnalités des politiques réseau « internes », y compris l'interdiction pour les comptes de dépasser le nombre de tentatives de saisie de mot de passe. Si un attaquant découvre les identifiants, il essaiera leurs mots de passe. Si vous êtes configuré pour empêcher les comptes de saisir des mots de passe incorrects, cela fonctionnera et le compte sera bloqué. Troisièmement, il est impossible d’ajouter un deuxième facteur à une telle authentification. Si l’un des lecteurs sait encore comment faire, n’hésitez pas à me le faire savoir, c’est vraiment intéressant. Quatrièmement, la vulnérabilité aux attaques pass-the-hash. ADFS a été inventé, entre autres, pour se protéger de tout cela.
Il y a une mauvaise propriété des produits Microsoft : même si vous n'avez pas spécifiquement publié un tel NTLM, il sera installé par défaut dans OWA et Lync, au minimum.
À propos, l'auteur de cet article a accidentellement bloqué environ 1000 XNUMX comptes d'employés d'une grande banque en une heure seulement en utilisant la même méthode et a ensuite semblé quelque peu pâle. Les services informatiques de la banque étaient également pâles, mais tout s'est bien terminé, nous avons même été félicités pour avoir été les premiers à trouver ce problème et à provoquer une solution rapide et décisive.
Le deuxième site avait l’adresse « évidemment une sorte de nom de famille.company.ru ». Je l'ai trouvé via Google, quelque chose comme ceci à la page 10. Le design datait du début du milieu des années XNUMX, et une personne respectable le regardait depuis la page principale, quelque chose comme ceci :
Ici, j'ai pris une photo de "Heart of a Dog", mais croyez-moi, elle était vaguement similaire, même le design des couleurs était dans des tons similaires. Que le site s'appelle preobrazhensky.company.ru.
C'était un site personnel... pour un urologue. Je me demandais ce que faisait le site Web d’un urologue sur le sous-domaine d’une entreprise de haute technologie. Une recherche rapide sur Google a montré que ce médecin était co-fondateur de l'une des entités juridiques de notre client et qu'il avait même contribué à hauteur d'environ 1000 XNUMX roubles au capital autorisé. Le site a probablement été créé il y a de nombreuses années et les ressources du serveur du client ont été utilisées comme hébergement. Le site a depuis longtemps perdu de sa pertinence, mais pour une raison quelconque, il est resté fonctionnel pendant longtemps.
En termes de vulnérabilités, le site Web lui-même était sécurisé. Pour l’avenir, je dirai qu’il s’agissait d’un ensemble d’informations statiques – de simples pages HTML avec des illustrations insérées sous forme de reins et de vessies. Il ne sert à rien de « casser » un tel site.
Mais le serveur Web en dessous était plus intéressant. À en juger par l'en-tête du serveur HTTP, il disposait de IIS 6.0, ce qui signifie qu'il utilisait Windows 2003 comme système d'exploitation. Le scanner avait précédemment identifié que ce site Web d'urologue particulier, contrairement à d'autres hôtes virtuels sur le même serveur Web, répondait à la commande PROPFIND, ce qui signifie qu'il exécutait WebDAV. À propos, le scanner a renvoyé cette information avec la marque Info (dans le langage des rapports du scanner, c'est le danger le plus faible) - de telles choses sont généralement simplement ignorées. En combinaison, cela a donné un effet intéressant, qui n'a été révélé qu'après une autre fouille sur Google : une rare vulnérabilité de débordement de tampon associée à l'ensemble Shadow Brokers, à savoir CVE-2017-7269, qui avait déjà un exploit prêt à l'emploi. En d’autres termes, il y aura des problèmes si vous disposez de Windows 2003 et que WebDAV s’exécute sur IIS. Bien que l'exécution de Windows 2003 en production en 2018 soit un problème en soi.
L'exploit s'est retrouvé dans Metasploit et a été immédiatement testé avec une charge qui envoyait une requête DNS à un service contrôlé - Burp Collaborator est traditionnellement utilisé pour intercepter les requêtes DNS. À ma grande surprise, cela a fonctionné du premier coup : un knock-out DNS a été reçu. Ensuite, il y a eu une tentative de création d'une backconnect via le port 80 (c'est-à-dire une connexion réseau du serveur à l'attaquant, avec accès à cmd.exe sur l'hôte victime), mais un fiasco s'est produit. La connexion n'a pas réussi et après la troisième tentative d'utilisation du site, ainsi que toutes les images intéressantes, ont disparu à jamais.
Habituellement, cela est suivi d'une lettre du style « client, réveillez-vous, nous avons tout laissé tomber ». Mais on nous a dit que le site n'a rien à voir avec les processus métiers et y fonctionne sans aucune raison, comme l'ensemble du serveur, et que nous pouvons utiliser cette ressource à notre guise.
Environ un jour plus tard, le site a soudainement commencé à fonctionner tout seul. Après avoir construit un banc à partir de WebDAV sur IIS 6.0, j'ai découvert que le paramètre par défaut consiste à redémarrer les processus de travail IIS toutes les 30 heures. Autrement dit, lorsque le contrôle a quitté le shellcode, le processus de travail IIS s'est terminé, puis il a redémarré plusieurs fois, puis s'est reposé pendant 30 heures.
Depuis que la connexion à TCP a échoué la première fois, j'ai attribué ce problème à un port fermé. Autrement dit, il a supposé la présence d'une sorte de pare-feu qui ne permettait pas aux connexions sortantes de passer à l'extérieur. J'ai commencé à exécuter des shellcodes qui recherchaient dans de nombreux ports TCP et UDP, il n'y avait aucun effet. Les charges de connexion inversées via http(s) depuis Metasploit n'ont pas fonctionné - meterpreter/reverse_http(s). Soudain, une connexion vers le même port 80 a été établie, mais immédiatement interrompue. J'ai attribué cela à l'action de l'IPS encore imaginaire, qui n'aimait pas le trafic des compteurs. À la lumière du fait qu'une connexion TCP pure au port 80 n'a pas abouti, mais qu'une connexion http l'a fait, j'ai conclu qu'un proxy http était d'une manière ou d'une autre configuré dans le système.
J'ai même essayé Meterpreter via DNS (merci pour vos efforts, sauvé de nombreux projets), rappelant le tout premier succès, mais cela n'a même pas fonctionné sur le stand - le shellcode était trop volumineux pour cette vulnérabilité.
En réalité, cela ressemblait à ceci : 3-4 tentatives d'attaques en 5 minutes, puis 30 heures d'attente. Et ainsi de suite pendant trois semaines consécutives. J'ai même mis un rappel pour ne pas perdre de temps. De plus, il y avait une différence dans le comportement des environnements de test et de production : pour cette vulnérabilité, il y avait deux exploits similaires, l'un de Metasploit, le second d'Internet, converti à partir de la version Shadow Brokers. Ainsi, seul Metasploit a été testé au combat, et seul le second a été testé sur banc, ce qui a rendu le débogage encore plus difficile et a été un véritable casse-tête.
Au final, un shellcode qui téléchargeait un fichier exe depuis un serveur donné via http et le lançait sur le système cible s'est avéré efficace. Le shellcode était suffisamment petit pour tenir, mais au moins il fonctionnait. Étant donné que le serveur n'aimait pas du tout le trafic TCP et que http(s) avait été inspecté pour détecter la présence de Meterpreter, j'ai décidé que le moyen le plus rapide était de télécharger un fichier exe contenant DNS-meterpreter via ce shellcode.
Là encore, un problème s'est posé : lors du téléchargement d'un fichier exe et, comme les tentatives l'ont montré, peu importe lequel, le téléchargement a été interrompu. Encore une fois, un dispositif de sécurité entre mon serveur et l'urologue n'aimait pas le trafic http contenant un exe. La solution « rapide » semblait être de modifier le shellcode afin qu'il obscurcisse le trafic http à la volée, afin que les données binaires abstraites soient transférées à la place des fichiers exe. Finalement, l'attaque a réussi, le contrôle a été reçu via le canal DNS léger :
Il est immédiatement devenu clair que je disposais des droits de flux de travail IIS les plus élémentaires, qui me permettent de ne rien faire. Voici à quoi cela ressemblait sur la console Metasploit :
Toutes les méthodologies pentest suggèrent fortement que vous devez augmenter les droits lors de l'accès. Je ne le fais généralement pas localement, car le tout premier accès est simplement considéré comme un point d'entrée au réseau, et compromettre une autre machine sur le même réseau est généralement plus facile et plus rapide que d'augmenter les privilèges sur un hôte existant. Mais ce n’est pas le cas ici, puisque le canal DNS est très étroit et ne permettra pas au trafic de s’éclaircir.
En supposant que ce serveur Windows 2003 n'a pas été réparé pour la célèbre vulnérabilité MS17-010, je tunnelise le trafic vers le port 445/TCP via le tunnel DNS du compteur sur localhost (oui, c'est également possible) et j'essaie d'exécuter l'exe précédemment téléchargé via la vulnérabilité. L'attaque fonctionne, je reçois une deuxième connexion, mais avec les droits SYSTEM.
Il est intéressant de noter qu'ils ont quand même essayé de protéger le serveur contre MS17-010 - les services réseau vulnérables étaient désactivés sur l'interface externe. Cela protège contre les attaques sur le réseau, mais l'attaque depuis l'intérieur de localhost a fonctionné, car vous ne pouvez pas simplement désactiver rapidement SMB sur localhost.
Ensuite, de nouveaux détails intéressants sont révélés :
- Ayant les droits SYSTÈME, vous pouvez facilement établir une connexion arrière via TCP. De toute évidence, la désactivation de TCP direct est strictement un problème pour l'utilisateur limité d'IIS. Spoiler : le trafic des utilisateurs IIS était en quelque sorte enveloppé dans le proxy ISA local dans les deux sens. Comment ça marche exactement, je ne l'ai pas reproduit.
- Je suis dans une certaine "DMZ" (et ce n'est pas un domaine Active Directory, mais un WORKGROUP) - cela semble logique. Mais au lieu de l’adresse IP privée (« grise ») attendue, j’ai une adresse IP complètement « blanche », exactement la même que celle que j’ai attaquée plus tôt. Cela signifie que l'entreprise est si ancienne dans le monde de l'adressage IPv4 qu'elle peut se permettre de maintenir une zone DMZ pour 128 adresses « blanches » sans NAT selon le schéma décrit dans les manuels Cisco de 2005.
Le serveur étant ancien, Mimikatz est assuré de fonctionner directement depuis la mémoire :
J'obtiens le mot de passe de l'administrateur local, tunnelise le trafic RDP via TCP et me connecte à un bureau confortable. Comme je pouvais faire ce que je voulais avec le serveur, j'ai supprimé l'antivirus et j'ai constaté que le serveur n'était accessible depuis Internet que via les ports TCP 80 et 443, et que le 443 n'était pas occupé. J'ai configuré un serveur OpenVPN sur 443, ajouté des fonctions NAT pour mon trafic VPN et obtenu un accès direct au réseau DMZ sous une forme illimitée via mon OpenVPN. Il est à noter qu'ISA, disposant de certaines fonctions IPS non désactivées, a bloqué mon trafic avec l'analyse des ports, pour lequel il a dû être remplacé par un RRAS plus simple et plus conforme. Les pentesters doivent donc parfois encore administrer toutes sortes de choses.
Un lecteur attentif demandera : « Qu'en est-il du deuxième site - un wiki avec authentification NTLM, sur lequel tant de choses ont été écrites ? Nous en reparlerons plus tard.
Partie 2. Vous ne chiffrez toujours pas ? Alors nous venons déjà vers vous ici
Il y a donc accès au segment de réseau DMZ. Vous devez vous adresser à l'administrateur du domaine. La première chose qui vient à l'esprit est de vérifier automatiquement la sécurité des services au sein du segment DMZ, d'autant plus que de nombreux autres services sont désormais ouverts à la recherche. Image typique lors d'un test d'intrusion : le périmètre externe est mieux protégé que les services internes, et lors de l'accès à l'intérieur d'une grande infrastructure, il est beaucoup plus facile d'obtenir des droits étendus dans un domaine uniquement du fait que ce domaine commence à être accessible aux outils, et deuxièmement, dans une infrastructure comptant plusieurs milliers d'hôtes, il y aura toujours quelques problèmes critiques.
Je charge les scanners via DMZ via un tunnel OpenVPN et j'attends. J'ouvre le rapport - encore une fois rien de grave, apparemment quelqu'un a suivi la même méthode avant moi. L'étape suivante consiste à examiner comment les hôtes du réseau DMZ communiquent. Pour ce faire, lancez d'abord l'habituel Wireshark et écoutez les demandes de diffusion, principalement ARP. Les paquets ARP ont été collectés toute la journée. Il s'avère que plusieurs passerelles sont utilisées dans ce segment. Cela vous sera utile plus tard. En combinant les données sur les requêtes et réponses ARP et les données d'analyse des ports, j'ai trouvé les points de sortie du trafic utilisateur depuis l'intérieur du réseau local en plus des services précédemment connus, tels que le Web et la messagerie.
Comme pour le moment je n'avais aucun accès à d'autres systèmes et je n'avais pas un seul compte pour les services d'entreprise, il a été décidé de récupérer au moins un compte du trafic en utilisant l'usurpation d'identité ARP.
Cain&Abel a été lancé sur le serveur de l'urologue. En tenant compte des flux de trafic identifiés, les paires les plus prometteuses pour l'attaque de l'homme du milieu ont été sélectionnées, puis une partie du trafic réseau a été reçue par lancement à court terme pendant 5 à 10 minutes, avec une minuterie pour redémarrer le serveur. en cas de gel. Comme dans la blague, il y avait deux nouvelles :
- Bon : de nombreuses informations d'identification ont été récupérées et l'attaque dans son ensemble a fonctionné.
- Le mauvais : toutes les informations d’identification provenaient des propres clients du client. Tout en fournissant des services d'assistance, des spécialistes clients se sont connectés aux services de clients qui n'avaient pas toujours configuré le cryptage du trafic.
En conséquence, j'ai acquis de nombreuses informations d'identification inutiles dans le cadre du projet, mais certainement intéressantes pour démontrer le danger de l'attaque. Routeurs frontaliers des grandes entreprises avec telnet, transfert des ports http de débogage vers le CRM interne avec toutes les données, accès direct à RDP depuis Windows XP sur le réseau local et autres obscurantismes. Ça s'est passé comme ça .
J'ai aussi trouvé une drôle d'occasion de collecter des lettres du trafic, quelque chose comme ça. Ceci est un exemple de lettre toute faite transmise par notre client au port SMTP de son client, encore une fois, sans cryptage. Un certain Andrey demande à son homonyme de renvoyer la documentation, et elle est téléchargée sur un disque cloud avec un identifiant, un mot de passe et un lien dans une seule lettre de réponse :
Ceci est un autre rappel pour chiffrer tous les services. On ne sait pas qui et quand lira et utilisera spécifiquement vos données - le fournisseur, l'administrateur système d'une autre entreprise ou un tel pentester. Je ne dis pas que de nombreuses personnes peuvent simplement intercepter du trafic non crypté.
Malgré le succès apparent, cela ne nous a pas rapproché du but. Il était bien sûr possible de rester assis longtemps et d'extraire des informations précieuses, mais ce n'est pas un fait qu'elles y apparaîtraient, et l'attaque elle-même est très risquée en termes d'intégrité du réseau.
Après une nouvelle fouille dans les services, une idée intéressante m’est venue à l’esprit. Il existe un tel utilitaire appelé Responder (il est facile de trouver des exemples d'utilisation sous ce nom), qui, en « empoisonnant » les requêtes de diffusion, provoque des connexions via divers protocoles tels que SMB, HTTP, LDAP, etc. de différentes manières, demande ensuite à tous ceux qui se connectent de s'authentifier et le paramétre pour que l'authentification s'effectue via NTLM et dans un mode transparent pour la victime. Le plus souvent, un attaquant collecte ainsi les poignées de main NetNTLMv2 et, à l'aide d'un dictionnaire, récupère rapidement les mots de passe du domaine utilisateur. Ici, je voulais quelque chose de similaire, mais les utilisateurs étaient assis « derrière un mur », ou plutôt, ils étaient séparés par un pare-feu et accédaient au WEB via le cluster proxy Blue Coat.
Rappelez-vous, j'ai précisé que le nom de domaine Active Directory coïncidait avec le domaine « externe », c'est-à-dire qu'il s'agissait de company.ru ? Ainsi, Windows, plus précisément Internet Explorer (et Edge et Chrome), permettent à l'utilisateur de s'authentifier de manière transparente en HTTP via NTLM s'il considère que le site est situé dans une « Zone Intranet ». L'un des signes d'un « Intranet » est l'accès à une adresse IP « grise » ou à un nom DNS court, c'est-à-dire sans points. Comme ils disposaient d'un serveur avec un nom IP et DNS « blanc » preobrazhensky.company.ru et que les machines du domaine reçoivent généralement le suffixe de domaine Active Directory via DHCP pour une saisie simplifiée du nom, il leur suffisait d'écrire l'URL dans la barre d'adresse. , afin qu’ils trouvent le bon chemin vers le serveur de l’urologue compromis, sans oublier que celui-ci s’appelle désormais « Intranet ». Autrement dit, en me donnant en même temps la poignée de main NTLM de l'utilisateur à son insu. Il ne reste plus qu'à faire réfléchir les navigateurs clients à la nécessité urgente de contacter ce serveur.
Le merveilleux utilitaire Intercepter-NG est venu à la rescousse (merci ). Il vous permettait de modifier le trafic à la volée et fonctionnait très bien sous Windows 2003. Il disposait même d'une fonctionnalité distincte permettant de modifier uniquement les fichiers JavaScript dans le flux de trafic. Une sorte de Cross-Site Scripting massif était prévue.
Les proxys Blue Coat, via lesquels les utilisateurs accédaient au WEB mondial, mettaient périodiquement en cache le contenu statique. En interceptant le trafic, il était clair qu'ils travaillaient XNUMX heures sur XNUMX, demandant sans cesse des parasites fréquemment utilisés pour accélérer l'affichage du contenu pendant les heures de pointe. De plus, BlueCoat disposait d’un User-Agent spécifique, qui le distinguait clairement d’un utilisateur réel.
Javascript a été préparé et, à l'aide d'Intercepter-NG, a été implémenté pendant une heure la nuit pour chaque réponse avec des fichiers JS pour Blue Coat. Le script a fait ce qui suit :
- Déterminé le navigateur actuel par User-Agent. S'il s'agissait d'Internet Explorer, Edge ou Chrome, cela continuait à fonctionner.
- J'ai attendu que le DOM de la page soit formé.
- Inséré une image invisible dans le DOM avec un attribut src du formulaire :8080/NNNNNNN.png, où NNN sont des nombres arbitraires afin que BlueCoat ne les mette pas en cache.
- Définissez une variable d'indicateur globale pour indiquer que l'injection est terminée et qu'il n'est plus nécessaire d'insérer des images.
Le navigateur a essayé de charger cette image ; sur le port 8080 du serveur compromis, un tunnel TCP l'attendait vers mon ordinateur portable, où s'exécutait le même répondeur, exigeant que le navigateur se connecte via NTLM.
À en juger par les journaux du répondeur, les gens sont venus travailler le matin, ont allumé leur poste de travail, puis ont commencé à visiter en masse et inaperçus le serveur de l'urologue, sans oublier de « vider » les poignées de main du NTLM. Les poignées de main ont plu toute la journée et ont clairement accumulé de la matière pour une attaque manifestement réussie de récupération de mots de passe. Voici à quoi ressemblaient les journaux du répondeur :
Visites secrètes de masse sur le serveur de l'urologue par les utilisateurs
Vous avez probablement déjà remarqué que toute cette histoire est construite sur le principe « tout allait bien, mais ensuite il y a eu une déception, puis il y a eu un dépassement, et puis tout est arrivé au succès ». Donc, il y a eu une déception ici. Sur les cinquante poignées de main uniques, aucune n’a été révélée. Et cela prend en compte le fait que même sur un ordinateur portable doté d'un processeur mort, ces poignées de main NTLMv2 sont traitées à une vitesse de plusieurs centaines de millions de tentatives par seconde.
J'ai dû m'armer de techniques de mutation de mot de passe, d'une carte vidéo, d'un dictionnaire plus épais et attendre. Après une longue période, plusieurs comptes avec des mots de passe du type « Q11111111....1111111q » ont été révélés, ce qui suggère que tous les utilisateurs étaient autrefois obligés de proposer un mot de passe très long avec une casse de caractères différente, qui était également censé être complexe. Mais on ne peut pas tromper un utilisateur chevronné, et c’est ainsi qu’il s’est facilité la tâche pour se souvenir. Au total, environ 5 comptes ont été compromis, et un seul d’entre eux disposait de droits précieux sur les services.
Partie 3. Roskomnadzor contre-attaque
Ainsi, les premiers comptes de domaine ont été reçus. Si vous ne vous êtes pas encore endormi après une longue lecture, vous vous souviendrez probablement que j'ai mentionné un service qui ne nécessitait pas de deuxième facteur d'authentification : c'est un wiki avec authentification NTLM. Bien entendu, la première chose à faire était d’y entrer. L’exploration de la base de connaissances interne a rapidement donné des résultats :
- L'entreprise dispose d'un réseau WiFi avec authentification par comptes de domaine avec accès au réseau local. Avec l'ensemble de données actuel, il s'agit déjà d'un vecteur d'attaque fonctionnel, mais vous devez vous rendre au bureau avec vos pieds et vous trouver quelque part sur le territoire du bureau du client.
- J'ai trouvé une instruction selon laquelle il existait un service qui permettait... d'enregistrer indépendamment un dispositif d'authentification « à deuxième facteur » si l'utilisateur se trouve à l'intérieur d'un réseau local et se souvient en toute confiance de son identifiant de domaine et de son mot de passe. Dans ce cas, « intérieur » et « extérieur » étaient déterminés par l'accessibilité du port de ce service à l'utilisateur. Le port n'était pas accessible depuis Internet, mais était tout à fait accessible via la DMZ.
Bien entendu, un « deuxième facteur » a été immédiatement ajouté au compte compromis sous la forme d’une application sur mon téléphone. Il existait un programme qui pouvait soit envoyer une demande push au téléphone avec des boutons « approuver »/« désapprouver » pour l'action, soit afficher silencieusement le code OTP sur l'écran pour une saisie indépendante ultérieure. De plus, la première méthode était supposée par les instructions être la seule correcte, mais elle n'a pas fonctionné, contrairement à la méthode OTP.
Une fois le « deuxième facteur » rompu, j’ai pu accéder à la messagerie Outlook Web Access et à l’accès à distance dans Citrix Netscaler Gateway. Il y a eu une surprise dans le courrier dans Outlook :
Dans cette photo rare, vous pouvez voir comment Roskomnadzor aide les pentesters
C’étaient les premiers mois après le fameux blocage par « fans » de Telegram, lorsque des réseaux entiers avec des milliers d’adresses disparaissaient inexorablement de l’accès. Il est devenu clair pourquoi le push n’a pas fonctionné tout de suite et pourquoi ma « victime » n’a pas sonné l’alarme parce qu’elle a commencé à utiliser son compte pendant les heures d’ouverture.
Quiconque connaît Citrix Netscaler imagine qu'il est généralement implémenté de telle manière que seule une interface graphique peut être transmise à l'utilisateur, en essayant de ne pas lui donner les outils nécessaires pour lancer des applications tierces et transférer des données, limitant de toutes les manières possibles les actions. via des coques de contrôle standards. Ma « victime », du fait de son métier, n'a eu que 1C :
Après avoir parcouru un peu l'interface 1C, j'ai découvert qu'il y avait des modules de traitement externes. Ils peuvent être chargés depuis l'interface, et ils seront exécutés sur le client ou le serveur, selon les droits et paramètres.
J'ai demandé à mes amis programmeurs 1C de créer un traitement qui accepterait une chaîne et l'exécuterait. En langage 1C, le démarrage d'un processus ressemble à ceci (tiré d'Internet). Êtes-vous d'accord que la syntaxe du langage 1C étonne les russophones par sa spontanéité ?
Le traitement a été parfaitement exécuté ; il s'est avéré être ce que les pentesters appellent un « shell » : Internet Explorer a été lancé à travers celui-ci.
Auparavant, l'adresse d'un système permettant de commander des laissez-passer pour le territoire avait été trouvée dans le courrier. J'ai commandé un pass au cas où je devrais utiliser un vecteur d'attaque WiFi.
On raconte sur Internet qu'il y avait encore de délicieux repas gratuits chez le client, mais j'ai quand même préféré développer l'attaque à distance, c'est plus calme.
AppLocker a été activé sur le serveur d'applications exécutant Citrix, mais il a été contourné. Le même Meterpreter a été chargé et lancé via DNS, car les versions http(s) ne voulaient pas se connecter et je ne connaissais pas l'adresse proxy interne à ce moment-là. À propos, à partir de ce moment, le pentest externe s'est essentiellement complètement transformé en un test interne.
Partie 4. Les droits d'administrateur des utilisateurs sont incorrects, d'accord ?
La première tâche d'un pentester lorsqu'il prend le contrôle d'une session utilisateur de domaine est de collecter toutes les informations sur les droits dans le domaine. Il existe un utilitaire BloodHound qui vous permet de télécharger automatiquement des informations sur les utilisateurs, les ordinateurs, les groupes de sécurité via le protocole LDAP à partir d'un contrôleur de domaine et via SMB - des informations sur l'utilisateur récemment connecté, où et qui est l'administrateur local.
Une technique typique pour saisir les droits d'administrateur de domaine semble simplifiée comme un cycle d'actions monotones :
- Nous accédons aux ordinateurs du domaine où il existe des droits d'administrateur local, basés sur des comptes de domaine déjà capturés.
- Nous lançons Mimikatz et obtenons les mots de passe en cache, les tickets Kerberos et les hachages NTLM des comptes de domaine récemment connectés à ce système. Ou nous supprimons l'image mémoire du processus lsass.exe et faisons de même de notre côté. Cela fonctionne bien avec Windows antérieur à 2012R2/Windows 8.1 avec les paramètres par défaut.
- Nous déterminons où les comptes compromis disposent des droits d'administrateur local. Nous répétons le premier point. À un moment donné, nous obtenons des droits d'administrateur pour l'ensemble du domaine.
«Fin du cycle», comme écriraient ici les programmeurs 1C.
Ainsi, notre utilisateur s'est avéré être un administrateur local sur un seul hôte avec Windows 7, dont le nom incluait le mot « VDI », ou « Virtual Desktop Infrastructure », des machines virtuelles personnelles. Probablement, le concepteur du service VDI voulait dire que puisque le VDI est le système d'exploitation personnel de l'utilisateur, même si l'utilisateur modifie l'environnement logiciel à sa guise, l'hôte peut toujours être « rechargé ». J'ai aussi pensé qu'en général l'idée était bonne, je suis allé chez cet hébergeur VDI personnel et j'y ai fait un nid :
- J'y ai installé un client OpenVPN, qui a créé un tunnel via Internet vers mon serveur. Le client a dû être obligé de passer par le même Blue Coat avec l'authentification de domaine, mais OpenVPN l'a fait, comme on dit, « prêt à l'emploi ».
- OpenSSH installé sur VDI. Eh bien, vraiment, qu'est-ce que Windows 7 sans SSH ?
Voilà à quoi ça ressemblait en live. Je vous rappelle que tout cela doit être fait via Citrix et 1C :
Une technique pour promouvoir l'accès aux ordinateurs voisins consiste à vérifier la correspondance des mots de passe des administrateurs locaux. Ici, la chance s'est immédiatement présentée : le hachage NTLM de l'administrateur local par défaut (qui s'est soudainement appelé Administrateur) a été approché via une attaque de hachage sur les hôtes VDI voisins, qui étaient plusieurs centaines. Bien entendu, l’attaque les a immédiatement touchés.
C’est là que les administrateurs VDI se sont tirés une balle dans le pied à deux reprises :
- La première fois, c'était lorsque les machines VDI n'étaient pas placées sous LAPS, conservant essentiellement le même mot de passe d'administrateur local de l'image qui avait été massivement déployée sur VDI.
- L'administrateur par défaut est le seul compte local vulnérable aux attaques par passe-hachage. Même avec le même mot de passe, il serait possible d'éviter une compromission massive en créant un deuxième compte d'administrateur local avec un mot de passe aléatoire complexe et en bloquant celui par défaut.
Pourquoi y a-t-il un service SSH sur ce Windows ? C'est très simple : désormais, le serveur OpenSSH fournit non seulement un shell de commande interactif pratique sans interférer avec le travail de l'utilisateur, mais également un proxy chaussettes5 sur VDI. Grâce à ces chaussettes, je me suis connecté via SMB et j'ai collecté les comptes mis en cache de toutes ces centaines de machines VDI, puis j'ai recherché le chemin vers l'administrateur de domaine qui les utilisait dans les graphiques BloodHound. Avec des centaines d’hébergeurs à ma disposition, j’ai trouvé cette voie assez rapidement. Les droits d'administrateur de domaine ont été obtenus.
Voici une image prise sur Internet montrant une recherche similaire. Les connexions indiquent qui se trouve là où se trouve l'administrateur et qui est connecté et où.
À propos, rappelez-vous la condition du début du projet : « ne pas utiliser l'ingénierie sociale ». Alors, je propose de réfléchir à combien tout ce Bollywood avec des effets spéciaux serait coupé s'il était encore possible d'avoir recours au phishing banal. Mais personnellement, c’était très intéressant pour moi de faire tout ça. J'espère que vous avez apprécié cette lecture. Bien sûr, tous les projets ne semblent pas aussi intrigants, mais le travail dans son ensemble est très exigeant et ne lui permet pas de stagner.
Quelqu'un se posera probablement une question : comment se protéger ? Même cet article décrit de nombreuses techniques, dont beaucoup ne sont même pas connues des administrateurs Windows. Cependant, je propose de les examiner du point de vue des principes et des mesures de sécurité de l'information éculés :
- n'utilisez pas de logiciels obsolètes (vous vous souvenez de Windows 2003 au début ?)
- ne laissez pas les systèmes inutiles allumés (pourquoi y avait-il un site Web d’urologue ?)
- vérifiez vous-même la force des mots de passe des utilisateurs (sinon les soldats... les pentesters le feront)
- ne pas avoir les mêmes mots de passe pour différents comptes (compromis VDI)
- et autres
Bien sûr, c'est très difficile à mettre en œuvre, mais dans le prochain article nous montrerons en pratique que c'est tout à fait possible.
Source: habr.com