OKIOK a assisté à l’événement annuel NorthSec et a participé à son CTF. L’une des pistes s’appelait « OuYaYa intranet » et avait pour objectif de compromettre un intranet depuis une perspective externe. Elle a été conçue par David Lebrun (@davidlebr1) et s’est révélée réaliste, exigeante et amusante. Nous étions à quelques étapes de la terminer pendant le CTF, alors que la piste complète valait 28 points. Voici son compte rendu.
Premier drapeau
Description
Date: 20 mai 2022
L’intranet Ouyaya est une architecture réseau de classe mondiale
bâtie pour résister aux attaques les plus avancées. Tout a été méticuleusement
conçu pour offrir simplicité et sécurité à nos employés. Vous pouvez toujours regarder,
mais vous ne trouverez pas grand-chose: seul notre serveur Exchange est exposé pour que
nos employés accèdent à leurs courriels depuis Internet.
Notre responsable du développement web, Ph alias Pete Achety, peut aussi témoigner de la robustesse
de l’environnement. Il a développé d’excellents outils et contribue à plusieurs projets
libres. Je vous laisse trouver son Github; l’OSINT devrait couler dans vos veines, non?
Bref, si vous voulez quand même jeter un œil, voici le lien:
[Ouyaya Email Access](https://mail.yrr.ctf)
Rosie Meyer – A+, Server+, CCNA, CCNP, CCIE, MSDST, CSM
Administratrice réseau
Résolution
L’introduction du défi mentionnait un serveur Exchange externe qui pouvait servir de point d’entrée vers le réseau interne. La navigation dans l’OWA du serveur Exchange n’a rien donné.
Des vulnérabilités connues comme ProxyShell ont été tentées, sans succès. Il apparaissait que la première étape n’était pas une exploitation logicielle, ce qui est de moins en moins le cas. La description du défi mentionnait aussi un développeur web, Pete Achety, son GitHub et l’OSINT: un indicateur clair du chemin à suivre. Le profil GitHub de Pete a été trouvé rapidement, son nom d’utilisateur étant son prénom et son nom séparés par un trait d’union.
Il n’avait qu’un dépôt, presque vide à l’exception de son commit initial et d’un ticket. Le ticket avait été ouvert par Rosie Meyer, l’autrice de l’introduction du défi et administratrice réseau d’Ouyaya.
Son dépôt GitHub était vide et ses seules activités étaient les tickets ouverts dans le dépôt de Pete.
L’OSINT sur Pete et Rosie n’a rien donné. Heureusement, ce que nous cherchions ne se trouvait pas dans le dépôt lui-même, mais dans un Gist GitHub. En visitant la page du profil GitHub de Rosie, nous avons trouvé une liste d’une centaine de noms d’utilisateurs, potentiellement ceux du réseau interne, dans le fichier « yrr-users.txt ».
Avec une liste d’utilisateurs potentiels, le chemin d’attaque habituel consiste à vérifier la présence de mots de passe faibles. À l’aide de Ruler, une attaque par pulvérisation de mots de passe a été menée sur le serveur Exchange avec divers mots de passe courants, comme « Password1 ». Lorsqu’une politique force le changement fréquent de mot de passe, les utilisateurs choisissent parfois un mot de passe fondé sur la période de l’année. Comme le CTF se déroulait en mai 2022, nous avons commencé par « May2022 »: 4 utilisateurs l’employaient. Ce mot de passe était aussi suggéré dans la description du défi.
La connexion à ces comptes et la lecture de leurs courriels nous ont menés au premier drapeau trouvé pour ce défi. Il se trouvait dans la boîte de « mikhail.volkov ».
Deuxième drapeau
Description
Vraiment? Mais… comment est-ce possible? Notre politique de mots de passe est très robuste, avec au moins 7 caractères.
De toute façon, ce n’est qu’un compte de courriel. Vous n’irez pas plus loin.
Résolution
Le corps du courriel qui contenait le premier drapeau donnait aussi des indices sur les prochaines étapes menant au deuxième.
Le courriel, d’Anatoli Boon, mentionnait qu’il attendait un message de Mikhail et qu’il avait mis en place un script automatisé pour répondre lorsqu’une URL pointant vers le document était reçue, plutôt qu’une pièce jointe, afin de contourner la politique de sécurité. C’est peut-être un peu trop réaliste. Nous avons créé une charge utile exécutable dans Cobalt Strike, l’avons hébergée sur la machine prévue à cette fin (shell.ctf) et avons envoyé l’URL à M. Boon.
Après quelques minutes, la charge utile a été téléchargée et exécutée, ce qui nous a donné un shell distant avec les permissions de M. Boon sur le système nommé « WKST01 ».
Youpi, comme on dit en français!
Le deuxième drapeau se trouvait sur le bureau de la machine compromise.
Troisième drapeau
Description
Ahhhhh, c’est le genre de chose que je craignais.
Je me souviens de cette demande d’Anatoli Boon. Je n’aurais pas dû
autoriser ce script.
Mais… vous savez quoi? Je pense que vous êtes hors portée.
Je croyais que vous regardiez seulement d’un point de vue
externe.
Tant pis, rendus là, continuez votre travail et voyons
jusqu’où vous pouvez aller. J’espère que… laissez faire.
Résolution
À partir de là, nous avions un accès à faibles privilèges sur WKST01. Nous avons tenté une élévation de privilèges locale, un chemin typique dans les CTF.
Le répertoire « C:\script » contenait les scripts du défi précédent. Le script « run.bat » révélait le mot de passe d’anatoli.boon. Même si nous avions déjà une session avec ce compte, disposer de son mot de passe permettait plus de persistance.
À ce stade, nous préférions une session RDP sur WKST01, alors nous avons monté un proxy SOCKS à travers notre session Cobalt Strike et démarré une session RDP par le proxy pour obtenir une session graphique. L’outil bien connu WinPEAS a été exécuté pour repérer les mauvaises configurations courantes exploitables en élévation de privilèges locale. Il a listé le service « yrrservice », sur lequel notre utilisateur avait un accès complet.
Comme le service était exécuté par l’utilisateur SYSTEM, il était clair que ce chemin permettrait d’obtenir un accès à privilèges élevés sur le système. Le chemin de l’exécutable du service « yrrservice » a été remplacé par une valeur arbitraire, correspondant à notre charge utile.
En démarrant le service, nous avons obtenu une connexion en tant que SYSTEM sur WKST01, et le drapeau a pu être récupéré sur le bureau de l’administrateur.
Quatrième drapeau
Description
Rendu là, je crois que vous savez ce que vous faites
et vous devez être un excellent pirate. Je ne sais même pas comment
vous avez pu obtenir les droits d’administrateur sur un poste de travail d’employé
qui est durci.
Nous avons un portail d’applications web pour nos employés. Auriez-vous
le temps d’y jeter un œil?
Résolution
La description pointait vers une application web, et il s’agissait de deux défis web conçus par Marc Olivier Bergeron (@mo_bergeron).
Pendant la reconnaissance interne, nous avons obtenu la liste des ordinateurs du domaine; l’un d’eux s’appelait WEB01. Il hébergeait le portail web des employés mentionné dans la description du défi.
Ayant le mot de passe d’anatoli.boon, nous l’avons utilisé pour nous connecter et avons rapidement trouvé une section de l’application contenant trois fichiers, dont l’un portait un drapeau à 0 point.
Cinquième drapeau
Description
Bravo, vous avez trouvé le portail web. Je me demande ce que vous pourriez
trouver avec vos compétences. L’application web a été développée par
Pete Hachety et elle devrait être exempte de vulnérabilités.
Résolution
Le drapeau à 0 point confirmait que le prochain défi consistait à compromettre l’application web. L’application comportait différentes sections, dont deux seulement étaient accessibles avec nos privilèges. Nous avons aussi essayé avec les autres comptes compromis lors de la pulvérisation de mots de passe sur le serveur Exchange, sans succès.
Les sections accessibles étaient « Documents » et « Users ». La section « Documents » était surtout statique et avait probablement déjà rempli son rôle avec le drapeau à zéro point. La section « Users », par contre, était une liste d’utilisateurs internes dotée d’une recherche par nom. Nous trouvions que ça criait l’injection SQL, et nous avions raison.
À l’aide de sqlmap, nous avons découvert un point d’injection permettant, entre autres techniques, les requêtes empilées.
Deux tables ont été trouvées et extraites avec succès. L’analyse a révélé que certains utilisateurs avaient des privilèges élevés, ce que reflétait la valeur « role_id ». Comme les mots de passe étaient stockés sous forme d’empreintes SHA512, il était clair que le défi consistait à changer le « role_id » d’un compte que nous contrôlions plutôt qu’à casser des empreintes.
Puisque l’injection SQL fonctionnait avec des requêtes empilées, elle permettait plus que la seule extraction. Nous avons aussi pu exécuter des requêtes UPDATE sur la base de données pour changer le « role_id » de notre utilisateur.
La commande s’est exécutée avec succès et nous avons obtenu le cinquième drapeau après nous être connectés avec les nouveaux privilèges.
Sixième drapeau
Description
Euh, c’est… euh… QUOI!? C’est quoi ça? Vous avez dit injection SQL?
Je vais contacter Pete, il pourra peut-être me donner
plus de détails là-dessus.
J’imagine que vous pouvez continuer… je crains où ça vous mènera.
Résolution
À ce stade, nos privilèges donnaient accès à trois nouvelles sections. Dans « Upload », nous pouvions téléverser un document vers le serveur; nos tentatives se sont toutefois toutes soldées par une erreur applicative. Dans « Update », un bouton « Update » cliquable nous était présenté. Dans « Error Logs », nous pouvions consulter les journaux d’erreurs du serveur, à commencer par une entrée intéressante en tête de journal: « C:\inetpub\OuYayaDocuments\wwwroot\update.bat ». Le reste des journaux provenait de nos tentatives d’injection SQL précédentes.
Nous avons relié les trois sections et bâti ce scénario: le bouton « Update » appelle « update.bat » à l’emplacement indiqué dans le journal, et nous téléversons à cet emplacement grâce à la fonction Upload. Le scénario a été exécuté en téléversant une charge utile au chemin indiqué, puis en la déclenchant avec le bouton « Update ».
Nous avons obtenu une session à faibles privilèges sur WEB01 avec le rôle de serveur web.
Le drapeau nous attendait dans « C:\Users\Public\flag.txt ».
Septième drapeau
Description
Personne ne m’a parlé de cette fonctionnalité dans l’application web.
Pour être honnête, je n’ai même pas d’accès administratif
au portail web.
Résolution
À partir de notre accès à faibles privilèges, nous voulions passer à un accès à privilèges élevés sur le serveur web. Les privilèges de notre utilisateur ont été listés et l’intéressant « SeImpersonatePrivilege » lui était accordé. L’exploit Sweet Potato pouvait servir à l’élévation de privilèges locale.
En l’exploitant, nous avons obtenu une connexion et récupéré le septième drapeau sur le bureau de l’administrateur.
Huitième drapeau
Description
Donc… si je comprends bien, vous avez obtenu les privilèges Administrateur sur WEB01.
Si c’est le cas, je ne sais plus quoi dire. Je pense que c’est trop pour moi.
Résolution
À une étape précédente, nous avions tenté une élévation de privilèges sur le réseau plutôt que sur le poste de travail. Cela nous avait donné de l’information sur les hôtes du domaine et leur configuration. L’un d’eux comportait une délégation contrainte configurée de WEB01 vers EXCH01. Ayant compromis WEB01, nous savions que ce serait le chemin d’attaque.
Nous avons demandé un TGT de délégation pour notre utilisateur WEB01$ et l’avons utilisé pour demander un TGS pour EXCH01$, qui disposait d’un accès complet à EXCH01.
À cette étape, nous avions pour WEB01 un ticket autorisé à agir en tant qu’EXCH01 avec des privilèges élevés. Le drapeau se trouvait de nouveau sur le bureau de l’administrateur.
Neuvième drapeau
Description
Avez-vous acheté un 0 day? Je sais que certains APT achètent des 0 day pour atteindre leur but.
Rendu là, je crois que vous pouvez vous arrêter. De toute façon, vous n’arriverez pas à accéder au contrôleur de domaine,
puisque l’antivirus est à jour et actif.
Bon, vous pouvez y perdre votre temps.
Résolution
Le dernier drapeau a été obtenu en accédant au contrôleur de domaine. Comme c’est souvent le cas lors de tests d’intrusion internes, les privilèges du domaine étaient laxistes et exploitables. Ayant le contrôle d’EXCH01, nous avons remarqué que ce compte machine pouvait ajouter des membres au groupe AD important « Enterprise Key Admins ».
Le compte utilisateur que nous contrôlions, anatoli.boon, a été ajouté à ce groupe. « Enterprise Key Admins » était une cible de choix parce que ses privilèges laxistes lui donnaient le contrôle sur les administrateurs du domaine.
Avec les privilèges d’administrateur de domaine ainsi obtenus, nous avons mené une attaque DCSync. Même si l’antivirus était activé sur le contrôleur de domaine, le DCSync s’effectue par la technique DRSUAPI, qui n’est habituellement pas détectée. Cela nous a permis de récupérer les empreintes NTLM des utilisateurs du domaine, dont celles d’un compte à privilèges élevés. Au final, il a été possible de récupérer le drapeau sur le contrôleur de domaine à l’aide des privilèges d’administrateur de domaine, ce qui complétait la piste!