Gagner PHDays 9 The Standoff: la chronique de l'équipe True0xA3

Ceci est un résumé en anglais de deux articles absolument exceptionnels écrits par Vitaliy Malkin de "Informzashita" dont l'équipe, True0xA3, est devenue lauréate du prestigieux concours de chapeau noir The Standoff lors des Positive Hack Days 9 en mai 2019.

Vitaliy a publié trois articles détaillés sur Habr, dont deux étaient consacrés à la description des stratégies que l'équipe True0xA3 a utilisées avant et pendant la compétition pour garantir à cette équipe le titre de vainqueur. J'ai senti que la seule chose qui manquait à ces deux articles était un résumé en anglais afin qu'un plus large public de lecteurs puisse en profiter. Donc, ci-dessous est le résumé de deux articles de Vitaliy Malkin , ainsi que des images que Vitaliy a publiées pour clarifier ses points. Vitaliy m'a autorisé à faire la traduction et à la publier.

PARTIE I. Se préparer pour la bataille

L'article original est ici

I. Objectifs initiaux

L'équipe était composée de 16 pentesters authentiques et de 4 stagiaires, armés de 6 serveurs et de notre propre station CUDA, plus la volonté de tenir la distance.

Les préparatifs actifs ont commencé 8 jours avant le début de The Standoff. C'était notre troisième tentative de gagner The Standoff, donc certains d'entre nous étaient suffisamment expérimentés pour savoir ce qui devait être fait. Depuis le début, nous avons discuté des priorités suivantes pour l'équipe:

1. Coordination harmonieuse entre les membres de l'équipe
2. Collection de fruits suspendus bas
3. Exploiter des vulnérabilités inhabituelles pour nous telles que les systèmes de contrôle automatisé des processus (APCS), les systèmes de contrôle distribués (DCS), l'IoT, le GSM
4. Mise en place de nos propres infrastructures et équipements à l'avance
5. Élaboration d'une stratégie de persistance et de durcissement

Coordination:

C'est la faiblesse de tous les débutants dans le Standoff: les tâches ne sont pas distribuées efficacement; plusieurs personnes travaillent sur la même tâche; il n'est pas clair quelles tâches ont déjà été accomplies; les résultats d'une tâche ne sont pas transmis aux membres appropriés de l'équipe, etc. Plus l'équipe est grande, moins la coordination entre les membres de l'équipe est efficace. Plus important encore, il doit y avoir au moins une personne qui comprend l'ensemble de l'image du point de vue de l'infrastructure et qui peut regrouper plusieurs vulnérabilités en un seul vecteur d'attaque ciblé.

Cette année, nous avons utilisé la plateforme de collaboration Discord. Il est similaire au chat IRC mais avec des fonctionnalités supplémentaires comme le téléchargement de fichiers et les appels vocaux. Pour chaque cible de la carte Standoff, nous avons créé un canal distinct dans lequel toutes les données seraient collectées. De cette façon, un nouveau membre de l'équipe affecté à une tâche pourrait facilement voir toutes les informations qui ont déjà été collectées pour cette tâche, les résultats des déploiements, etc. Toutes les chaînes d'information avaient une limite de 1 message par minute pour éviter les inondations. Chaque objet dans le Standoff avait son propre espace de discussion dédié.

Chaque membre de l'équipe s'est vu attribuer un champ de travail clairement défini. Pour améliorer la coordination, une personne a été désignée pour prendre les décisions finales sur toutes les tâches. Cela nous a empêché d'entrer dans de longues discussions et désaccords pendant la compétition.

Récolte de fruits bas

Je crois que le facteur le plus important du jeu s'est avéré être la capacité de gérer plusieurs projets et de hiérarchiser correctement les objectifs. Dans le jeu de l'année dernière, nous avons pu reprendre un bureau et y rester simplement parce que nous avons utilisé des vulnérabilités bien connues. Cette année, nous avons décidé de faire une liste de ces vulnérabilités à l'avance et d'organiser nos connaissances:

ms17-010; ms08-67; SMBCRY LibSSH RCE; HP DATA Protectoer; HP iLo; ipmi Installation intelligente de Cisco Java RMI JDWP; JBOSS; drupalgeddon2; weblogic saigner shellshock; ibm websphere iis-webdav; rservices; vnc; ftp-anon; NFS smb-null; Tomcat

Ensuite, nous avons créé 2 services, checker et penetrator, qui ont automatisé le test des vulnérabilités et le déploiement des exploits et métasploits accessibles au public. Les services ont utilisé les résultats de nmap pour accélérer notre travail.

Exploiter des vulnérabilités non typiques pour nous

Nous n'avions pas beaucoup d'expérience avec l'analyse des vulnérabilités des systèmes de contrôle de processus automatisés (APCS). Environ 8 jours avant l'impasse, nous avons commencé à approfondir le sujet. La situation avec l'IoT et le GSM était encore pire. Nous n'avons jamais eu d'expérience avec ces systèmes en dehors des précédents entretiens.

Par conséquent, au stade de la préparation, nous avons sélectionné 2 personnes pour étudier les systèmes de contrôle de processus automatisés (APCS) et 2 autres pour étudier le GSM et l'IoT. La première équipe en moins d'une semaine a créé une liste d'approches typiques de pentesting des systèmes SCADA et a étudié en détail des vidéos de l'infrastructure de l'année précédente au sein de Standoff. Ils ont également téléchargé environ 200 Go de divers IHM, pilotes et autres logiciels liés aux contrôleurs. L'équipe IoT a préparé du matériel et lu tous les articles disponibles sur GSM. Nous espérions que ce serait suffisant (alerte spoiler: ce n'était pas le cas!)

Mise en place de nos propres infrastructures et équipements

Comme nous avions une assez grande équipe, nous avons décidé que nous aurions besoin d'équipement supplémentaire. Voici ce que nous avons emporté avec nous:

• Serveur CUDA
• Ordinateur portable de secours
• Routeur Wifi
• Commutateur
• Variété de câbles réseau
• WiFi Alfa
• Canards en caoutchouc

L'année dernière, nous avons compris l'importance de l'utilisation des serveurs CUDA lors du piratage de quelques poignées de main. Il est important de noter que cette année, ainsi que les années précédentes, tous les teamers rouges étaient derrière un NAT, nous n'avons donc pas pu utiliser les connexions inverses de DMZ. Cependant, nous avons supposé que tous les hôtes autres que les systèmes de contrôle de processus automatisés (APCS) auraient une connexion Internet. Dans cet esprit, nous avons décidé de faire tourner 3 serveurs-écouteurs disponibles sur Internet. Pour faciliter le pivotement, nous avons utilisé notre propre serveur OpenVPN avec client à client activé. Malheureusement, la création automatisée de chaînes n'a pas été possible. Par conséquent, pendant 12 heures sur 28, l'un des membres de l'équipe n'a été consacré qu'à la gestion des chaînes.

Élaboration d'une stratégie de persistance et de durcissement

Notre expérience précédente avec le Standoff nous a déjà appris qu'il ne suffisait pas de prendre la relève d'un serveur. Il était tout aussi important d'empêcher les autres équipes de prendre pied également. Nous avons donc passé beaucoup de temps sur le RAT (Remote Administration Tool) avec de nouvelles signatures et de nouveaux scripts pour durcir les systèmes Windows. Nous avons utilisé un RAT standard mais avons légèrement modifié la méthode d'obscurcissement. Les règles ont présenté une plus grande difficulté. Dans l'ensemble, nous avons développé la liste de scripts suivante:

• Fermeture des ports SMB (serveur de messages) et RPC (appel de procédure distante)
• Déplacement de RDP (Remote Desktop Protocol) vers des ports non standard
• Désactivation du chiffrement réversible, des comptes invités et d'autres problèmes typiques de la base de sécurité

Pour les systèmes Linux, nous avons développé un script d'initialisation spécial qui fermait tous les ports, déplaçait SSH vers un port non standard et créait des clés publiques pour permettre à l'équipe d'accéder à SSH.

II. Briefing

Le 17 mai, 5 jours avant la confrontation, les organisateurs ont fourni le briefing aux équipes rouges. Ils ont fourni beaucoup d'informations qui ont affecté notre préparation. Ils ont publié la carte du réseau, ce qui nous a permis de diviser le réseau en zones et d'attribuer les responsabilités de chaque zone à un membre de l'équipe. Les informations les plus importantes fournies par les organisateurs étaient que l'APCS ne serait accessible qu'à partir d'un segment du réseau et que ce segment n'est pas protégé. De plus, il a été révélé que les points les plus élevés seront attribués pour l'APCS et pour les bureaux sécurisés. Ils ont également déclaré qu'ils récompenseraient la capacité des équipes rouges à se mettre hors-réseau.

Nous avons interprété cela comme signifiant ce qui suit: "Celui qui capture le bigbrogroup gagnera probablement le match." En effet, notre expérience antérieure nous a appris que, quelle que soit la manière dont les organisateurs pénalisent la perte de service, les équipes bleues tueront les serveurs vulnérables si elles ne peuvent pas les corriger assez rapidement. En effet, leurs entreprises respectives sont beaucoup plus préoccupées par la publicité d'un système totalement piraté que par certains points perdus dans un jeu. Notre supposition était correcte, comme nous le verrons bientôt.

Nous avons donc décidé de diviser l'équipe en 4 parties:

I. Bigbrogroup . Nous avons décidé de prioriser cette tâche au-dessus de toutes les autres, nous avons donc placé nos pentesters les plus expérimentés dans ce groupe. Cette mini-équipe comptait 5 personnes et son objectif principal était de reprendre le domaine et d'empêcher d'autres équipes d'accéder à l'APCS.

II. Réseaux sans fil . Cette équipe était chargée de regarder le Wifi, de suivre les nouveaux WAP, de capturer les poignées de main et de les renforcer. Ils étaient également responsables de GSP, mais leur objectif principal était d'empêcher d'autres équipes de prendre le contrôle du Wifi

III. Réseaux non protégés . Cette équipe a passé les 4 premières heures à tester tous les réseaux non protégés et à analyser les vulnérabilités. Nous avons compris que dans les 4 premières heures, rien d'intéressant ne pouvait se produire dans les segments protégés, du moins rien que les équipes bleues ne pouvaient pas supprimer, nous avons donc décidé de passer ces premières heures à enfermer les réseaux non protégés, où les choses pourraient changer. Et il s'est avéré que c'était une bonne approche.

IV. Groupe de scanners . Les équipes bleues nous ont dit à l'avance que la topologie du réseau changera constamment, nous avons donc consacré 2 personnes à l'analyse du réseau et à la détection des changements. L'automatisation de ce processus s'est avérée difficile car nous avions plusieurs réseaux avec plusieurs paramètres. Par exemple, dans la première heure, notre nmap a fonctionné en mode T3, mais à midi, il fonctionnait à peine en mode T1.

Un autre vecteur important a été la liste des logiciels et technologies fournis par les organisateurs lors du briefing. Nous avons créé un groupe de compétences pour chacune des technologies qui pourrait rapidement évaluer les vulnérabilités typiques. Pour certains services, nous avons trouvé des vulnérabilités connues mais nous n'avons trouvé aucun exploit publié. C'était par exemple le cas du Redis Post-exploitation RCE. Nous étions à peu près sûrs que cette vulnérabilité serait présente dans l'infrastructure Standoff, nous avons donc décidé d'écrire notre propre exploit d'une journée. Bien sûr, nous n'avons pas pu écrire l'intégralité de l'exploit, mais dans l'ensemble nous avons rassemblé 5 exploits non publiés que nous étions prêts à déployer.

Malheureusement, nous n'avons pas pu enquêter sur toutes les technologies, mais il s'est avéré que ce n'était pas si critique. Puisque nous avons examiné les plus prioritaires, cela s'est avéré suffisant. Nous avons également préparé la liste des contrôleurs pour APCS, que nous avons également étudiée en détail.

Lors de la phase de préparation, nous avons rassemblé plusieurs outils pour la connexion clandestine au réseau APCS. Par exemple, nous avons préparé une version bon marché d'un ananas en utilisant une framboise. Il se connecterait à l'Ethernet du réseau de production et via GSM au service de contrôle. Nous pourrions alors configurer à distance une connexion Ethernet puis la diffuser via un module wifi intégré. Malheureusement, pendant le jeu, les organisateurs ont clairement indiqué que la connexion physique à l'APCS serait interdite, nous avons donc fini par ne pas pouvoir utiliser le module.

Nous avons trouvé pas mal d'informations sur le travail de la banque, les comptes offshore et la lutte contre la fraude. Cependant, nous avons également découvert que la banque n'avait pas beaucoup d'argent, nous avons donc décidé de ne pas passer de temps à préparer cet objet et de le jouer à l'oreille pendant le jeu.

En résumé, nous avons fait pas mal de travail pendant la phase de préparation. Je voudrais noter que, en plus de l'avantage évident d'être les gagnants du concours Standoff, nous avons récolté des avantages moins visibles mais non moins importants, tels que

• Nous avons pris une pause de la minutie quotidienne du travail et essayé quelque chose que nous espérions depuis longtemps faire
• C'était notre première expérience où toute l'équipe de pentesting travaillait sur une seule tâche, donc l'effet de team building était très perceptible
• Une grande partie des informations que nous avons recueillies lors de la préparation du jeu, nous pouvons les utiliser pour nos projets de pentesting réels, nous avons augmenté notre niveau de compétence et créé de nouveaux outils prêts à l'emploi

Avec le recul, je me rends compte que notre victoire dans le Standoff a probablement été obtenue bien avant le début du match, lors de la phase de préparation. Maintenant, ce qui s'est réellement passé pendant l'impasse sera décrit dans la partie II de cette série

Partie II. Gagner l'impasse. Partager les lifehacks

L'article d'origine est ici

De Vitaliy Malkin, le chef de l'équipe rouge de la société InformZachita et le capitaine de l'équipe True0xA3. True0xA3 a remporté l'une des compétitions de chapeaux blancs les plus prestigieuses de Russie - The Standoff aux PHDays 2019.

Premier jour

9:45 MSK

La journée a commencé par la réception des résultats du MassScan. Nous avons commencé par répertorier tous les hôtes avec 445 ports ouverts, et à 10 heures exactement, nous avons déployé le vérificateur pour le métasploit MS17-010. Selon notre plan, notre objectif principal était de capturer le contrôleur de domaine du domaine bigbrogroup, donc 2 personnes de notre équipe se sont consacrées uniquement à cela. Ci-dessous, vous verrez les affectations initiales pour chaque groupe.



Comme vous pouvez le voir, nous avons tenté de pénétrer tous les bureaux du jeu, et le fait que nous avions 20 personnes faisait une grande différence.

10:15

Un des membres de l'équipe de Team1 trouve un hôte dans le domaine bigbrogroup.phd qui est vulnérable à MS17-010. Nous avons déployé l'exploit très rapidement. Il y a quelques années, nous avons eu la situation où nous avons pu obtenir le compteur de mètres (attaque de phishing portant le code d'exécution à distance) vers une cible importante, mais nous en avons été expulsés en 10 secondes. Cette année, nous étions mieux préparés. Nous prenons en charge l'hôte, fermons le port SMB et passons le RDP au port 50002. Nous accordons une grande attention au processus de persistance sur le domaine, nous créons donc quelques comptes d'administrateur local et déployons nos propres outils d'administration à distance (RAT) . Ce n'est qu'après que nous sommes passés à la tâche suivante

10:25

Nous continuons à parcourir les résultats des informations que nous avons recueillies auprès de l'hôte. Outre l'accès au réseau interne et la connexion au contrôleur de domaine, nous trouvons également le jeton de l'administrateur du domaine. Avant de nous enthousiasmer, nous vérifions si le jeton est toujours valide. Et puis nous nous réjouissons. Le premier domaine est tombé. Le temps total passé est de 27 min 52 secondes

Une demi-heure après l'heure de début, nous visitons le portail des joueurs pour comprendre les règles de mise en drapeau et de réception de points. Nous voyons la liste standard: les connexions d'administrateur de domaine, les administrateurs locaux, les administrateurs d'échange et quelques autres administrateurs. Depuis le domaine, nous téléchargeons ntds.dit tout en préparant notre station CUDA. Ensuite, nous découvrons que le chiffrement réversible est celui-ci dans le domaine, alors maintenant nous pouvons obtenir tous les mots de passe dont nous avons besoin. Pour comprendre les mots de passe dont nous avons besoin, nous formons une équipe de 2 personnes qui commencent à analyser la structure de l'AD et de ses groupes. 5 minutes plus tard, ils rendent les résultats. Nous tournons nos drapeaux et attendons. Il était temps d'obtenir notre premier sang, au moins pour remonter le moral de l'équipe, si rien d'autre. Mais rien. Il nous a fallu une heure pour essayer de comprendre que le vérificateur fonctionne comme ceci:

• Il est automatisé
• Il a un format très rigide
• Si vous tournez vos drapeaux sur le chèque et n'avez pas reçu de réponse en quelques secondes, votre format ne correspond pas au format du vérificateur

Enfin, nous trouvons le bon format et vers 11 h nous obtenons notre First Blood. Ouf!

11:15

L'équipe 1 est divisée en deux sous-équipes. La sous-équipe 1 continue de fortifier le domaine: ils obtiennent krbtgt, renforcent la base de référence, changent les mots de passe pour les services d'annuaire. Les organisateurs de Standoff nous ont dit lors du briefing que les premiers du domaine pouvaient jouer comme ils le souhaitaient. Nous modifions donc les mots de passe administrateur afin que même si quelqu'un entre et parvienne à nous expulser, il ne pourra pas obtenir les connexions pour activer leurs indicateurs de points.

L'équipe 2 continue d'étudier la structure du domaine et trouve un autre indicateur. Sur le bureau du directeur financier, ils trouvent un rapport financier. Malheureusement, il est zippé et protégé par mot de passe. Donc, nous allumons la station CUDA. Nous transformons le zip en hachage et l'envoyons à hashcat.

L'équipe 2 continue de trouver des services intéressants avec RCE (exécution de code à distance) et commence à les étudier. L'un d'eux est un service de surveillance du domaine cf-media construit sur la base de Nagios. Un autre est le gestionnaire d'horaires d'une compagnie maritime construit autour d'une technologie étrange que nous n'avons jamais vue auparavant. Il existe également quelques services intéressants tels que les convertisseurs DOC vers DPF.

La deuxième sous-équipe de l'équipe 1 a déjà commencé à travailler sur la banque et a trouvé une base de données intéressante dans MongoDB, qui contient, entre autres choses, le nom de notre équipe et d'autres équipes, et leurs soldes. Nous modifions le solde de notre équipe à 50 millions et continuons.

14 h

La chance nous a quittés. Tout d'abord, les deux services pour lesquels nous avions RCE dans les segments protégés sont devenus indisponibles. L'équipe bleue les a simplement éteints. Bien sûr, nous nous plaignons auprès des organisateurs des violations des règles, mais sans effet. Dans l'impasse, il n'y a aucun processus métier à protéger! Deuxièmement, nous ne trouvons pas de liste de clients. Nous soupçonnons qu'il est caché quelque part dans les profondeurs de 1C, mais nous n'avons pas de bases de données, pas de fichiers de configuration. Impasse.

Nous essayons de configurer le canal VPN entre nos serveurs distants et les systèmes de contrôle de processus automatisés (APCS). Pour une raison étrange, nous ne le faisons pas sur le contrôleur de domaine de bigbrogroup, et la connexion entre les interfaces est rompue. Maintenant, le contrôleur de domaine n'est pas accessible. La partie de l'équipe chargée de l'accès au domaine souffre presque d'une crise cardiaque. La tension entre les membres de l'équipe augmente, le pointage commence.

Ensuite, nous réalisons que le contrôleur de domaine est accessible, mais la connexion VPN est instable. Nous revenons en arrière dans nos étapes, via RDP, nous désactivons le VPN, et le tour est joué, le contrôleur de domaine est à nouveau accessible. L'équipe exhale collectivement. Au final, nous avons configuré le VPN à partir d'un autre serveur. Le contrôleur de domaine est babillé et choyé. Toutes les équipes en compétition ont encore 0 point, ce qui est rassurant.

16:50

Les organisateurs publient enfin un mineur. En utilisant psexec, nous l'avons configuré sur tous les points finaux que nous contrôlons. Cela apporte un peu de flux de revenu stable.

L'équipe 2 travaille toujours sur la vulnérabilité de Nagios. Ils ont la version avec la vulnérabilité
<= 5.5.6 CVE-2018-15710 CVE-2018-15708. Un exploit public est disponible, mais il a besoin d'une connexion inversée pour télécharger le web-shell. Puisque nous sommes derrière le NAT, nous devons réécrire l'exploit et le diviser en deux parties. La première partie oblige Nagios à se connecter à notre serveur distant via Internet, et la deuxième partie, située sur le serveur lui-même, donne à Nagios le web-shell. Cela nous donne accès via proxy au domaine cf-media. Mais la connexion est instable et difficile à utiliser, nous décidons donc de vendre l'exploit pour les dollars BugBounty, tout en essayant en même temps d'augmenter notre accès à root.

18:07

Voici venir les "surprises" promises par les organisateurs. Ils annoncent que BigBroGroup vient d'acheter des médias CF. Nous ne sommes pas terriblement surpris. Au cours de notre enquête sur le domaine bigbrogroup, nous avons remarqué les relations de confiance entre les domaines bigbrogroup et cf-media.

Au moment où la prise de contrôle des médias CF a été annoncée, nous n'avions toujours pas de connexion à leur réseau. Mais après l'annonce, l'accès est apparu. Cela nous a évité de faire tourner nos roues en essayant de pivoter depuis Nagios. Les informations d'identification de Bigbrogroup fonctionnent sur le domaine cf-media, mais les utilisateurs n'ont pas de privilèges. Aucune vulnérabilité facilement exploitable n'a encore été trouvée, mais nous sommes assez optimistes quant à ce que quelque chose se produira.

18h30

Soudain, nous sommes lancés du domaine bigbrogroup. Par qui? Comment? Il semble que l'équipe TSARKA soit la coupable! Ils changent le mot de passe administrateur, mais nous avons 4 autres comptes administrateurs dans les réserves. Nous modifions à nouveau le mot de passe d'administrateur de domaine, réinitialisons tous les mots de passe. Mais quelques minutes plus tard, nous sommes à nouveau expulsés! A ce moment précis, nous trouvons un vecteur vers le domaine cf-media. Sur l'un de leurs serveurs, le nom d'utilisateur et le mot de passe correspondent à ceux que nous avons précédemment trouvés sur le domaine bigbrogroup. Oh, réutilisation du mot de passe! Que ferions-nous sans vous? Maintenant, nous avons juste besoin d'un hachage. Nous utilisons hashkiller et obtenons le mot de passe P @ ssw0rd. Continuons.

19h00

La lutte pour le contrôle du bidbrogroupe devient un problème sérieux. TSARKA a changé le mot de passe en krbtgt deux fois, nous perdons tous les comptes d'administrateur ... quelle est la prochaine étape? Une impasse?

19h30

Nous obtenons enfin les privilèges d'administrateur de domaine sur cf-media et commençons à activer nos drapeaux. Malgré le fait qu'il s'agisse d'un domaine sécurisé, nous constatons un cryptage réversible. Donc, maintenant nous avons les identifiants et les mots de passe, et nous procédons aux mêmes étapes qu'avec le bigbrogroup. Nous créons des administrateurs supplémentaires, renforçons notre position, durcissons la base de référence, modifions les mots de passe, créons une connexion VPN. On retrouve un deuxième rapport financier, également sous forme de zip protégé. Nous vérifions avec l'équipe responsable du premier rapport. Ils ont réussi à le brutaliser, mais les organisateurs ne l'accepteront pas. Il s'avère qu'il devait être transformé en 7zip protégé! Donc, nous n'avons même pas eu à le brutaliser! 3 heures de travail pour rien.

Nous transformons les deux rapports en fichiers 7zip protégés. Notre solde total à ce jour est de 1 million de points, et TSARKA en a 125 000, et ils commencent à tourner leurs drapeaux du domaine bigbrogroup. Nous réalisons que nous devons les empêcher de tourner leurs drapeaux, mais comment?

19h30

Nous trouvons une solution! Nous avons toujours les informations d'identification des administrateurs locaux. Nous nous connectons, prenons en charge le ticket et désactivons simplement le contrôleur de domaine. Le contrôleur se met hors tension. Nous fermons tous les ports du serveur à l'exception de RDP et changeons les mots de passe de tous nos administrateurs locaux. Maintenant, nous sommes dans notre petit espace et ils sont dans le leur. Si seulement la connexion VPN restait stable! L'équipe exhale collectivement.

En attendant, nous avons installé des mineurs sur tous les points de terminaison dans le domaine cf-media. TSARKA est en avance sur nous dans le volume global, mais nous ne sommes pas loin derrière, et nous avons plus de puissance.

La nuit

Ici, vous pouvez voir les changements que nous avons apportés à l'équipe pendant la nuit.



Certains membres de l'équipe doivent partir pour la nuit. À minuit, nous en sommes à 9 personnes. La productivité tombe à près de zéro. Toutes les heures, nous nous levons pour nous éclabousser le visage d'eau et sortir pour prendre l'air, juste pour nous débarrasser de la somnolence.

Maintenant, nous arrivons enfin aux systèmes de contrôle de processus automatisés (APCS)

02.00

Les dernières heures ont été très décourageantes. Nous avons trouvé plusieurs vecteurs, mais ils sont déjà fermés. Nous ne pouvons pas dire s'ils ont été fermés au départ ou si TSARKA est déjà venu ici. En étudiant lentement l'APCS, nous trouvons un contrôleur NetBus vulnérable. Nous utilisons un module métasploit dont nous ne comprenons pas entièrement le fonctionnement. Soudain, les lumières de la ville s'éteignent. Les organisateurs annoncent qu'ils compteront cela si nous pouvons rallumer la lumière. À ce moment, notre VPN tombe en panne. Le serveur gérant le VPN a été repris par TSARKA! Il semble que nous discutions trop fort de l'APCS et ils ont réussi à prendre le relais.

03h30

Même les plus dévoués d'entre nous commencent à s'endormir. Seulement 7 fonctionnent encore. Du coup, sans aucune explication, le VPN est de retour. Nous répétons rapidement le tour avec les lumières de la ville, et nous voyons notre solde augmenter de 200 000 points !!!

Une partie de l'équipe est toujours à la recherche de vecteurs supplémentaires, tandis qu'une autre travaille sur l'APCS. Nous y trouvons deux vulnérabilités supplémentaires. L'un d'eux, nous pouvons l'exploiter. Mais le résultat de l'exploit pourrait être une réécriture du firmware du microcontrôleur. Nous en discutons avec les organisateurs et décidons que nous attendrons que le reste de notre équipe nous rejoigne le matin, puis décidons collectivement de ce que nous devons faire.

05:30

Notre VPN fonctionne environ 10 minutes toutes les heures, puis il se déconnecte à nouveau. Pendant ce temps, nous essayons de travailler. Mais la productivité est proche de zéro. Finalement, nous décidons de prendre une heure chacun pour faire la sieste. Alerte spoiler - mauvaise idée!

5 personnes travaillent toujours sur l'APCS.

Le matin

Dans la matinée, nous réalisons soudain que nous sommes en avance sur les autres équipes de près d'un million de points. TSARKA a pu remettre deux drapeaux d'APCS, ainsi que plusieurs drapeaux du fournisseur de télécommunications et du bigbrogroup. De plus, ils ont des mineurs qui travaillent et ils doivent avoir une crypto qu'ils n'ont pas encore rendue. Nous avons estimé qu'ils avaient au moins 200 à 300 000 points de crypto en plus. C'est énervant. Nous avons le sentiment qu'ils pourraient avoir encore quelques drapeaux qu'ils retiennent stratégiquement jusqu'aux dernières heures. Mais notre équipe revient en ligne. Le contrôle du son du matin sur l'arène principale est un peu ennuyeux mais chasse le sommeil.

Nous essayons toujours de faire irruption dans l'APCS, mais l'espoir s'obscurcit. La différence de points entre la première et la deuxième équipe et le reste des équipes est gigantesque. Nous craignons que les organisateurs ne décident de lancer quelques "surprises" supplémentaires pour faire bouger les choses.

Après avoir participé à une conférence de presse avec TSARKA sur l'arène principale, nous décidons de changer notre stratégie de "obtenir plus de drapeaux" à "empêcher TSARKA de tourner plus de drapeaux".

Sur l'un de nos serveurs, nous démarrons Cain & Abel et redirige tout le trafic vers notre serveur. Nous trouvons des VPN du Kazakhstan et les tuons. Ensuite, nous décidons de tuer tout le trafic partout, nous créons donc un pare-feu local sur le canal VPN pour supprimer tout le trafic au sein du réseau APCS. C'est ainsi que vous protégez un APCS! Les organisateurs se plaignent maintenant d'avoir perdu la connexion avec l'APCS. Nous ouvrons l'accès à leurs adresses IP (ce n'est PAS ainsi que vous protégez l'APCS).

12:47

Nous avions raison de nous inquiéter des organisateurs qui essayaient de faire bouger les choses. De nulle part, il existe un vidage de données contenant 4 connexions pour chaque domaine. Nous mobilisons toute l'équipe.

Objectifs:
Équipe 1 : reprendre immédiatement tous les segments protégés.
Équipe 2 : utilisez Outlook Web Access pour remplacer tous les mots de passe par les connexions.

Certaines équipes bleues, sentant beaucoup d'activité, désactivent simplement le VPN. D'autres sont plus compliqués et changent la langue du système en chinois. Techniquement, le service est toujours en place! Mais bien sûr, en pratique, ce n'est pas utilisable (organisateurs, attention!). Via VPN, nous pouvons nous connecter à 3 des réseaux. Dans l'un d'eux, nous ne durons qu'une minute avant d'être expulsé.



12:52

Nous localisons un serveur sain avec la vulnérabilité MS17-010 (soi-disant un segment protégé?). Nous l'exploitons rapidement, ne rencontrant aucune résistance. Nous obtenons le hachage de l'administrateur du domaine et via Pth nous accédons au contrôleur de domaine. Et devinez quoi trouvons-nous là? Cryptage réversible!

Celui qui protégeait ce segment n'a pas fait ses devoirs. Nous collectons tous les drapeaux, à l'exception de la partie liée à 1C. Il y a de fortes chances que nous puissions l'obtenir si nous y avons passé 30 à 40 minutes supplémentaires, mais nous décidons simplement de désactiver le contrôleur de domaine sain. Qui a besoin de compétition?

13:20

Nous tournons nos drapeaux. Nous avons maintenant 2 900 000 points, plus quelques primes de bogues exceptionnelles. TSARKA en a un peu plus d'un million. Ils remettent leur crypto-monnaie et obtiennent 200 000 autres. Nous sommes maintenant à peu près sûrs qu'ils ne pourront pas rattraper leur retard, ce serait presque impossible.

13:55

Les gens arrivent et nous félicitent. Nous sommes toujours inquiets de la surprise des organisateurs, mais il semble que nous soyons vraiment annoncés comme gagnants!

C'est la chronique des 28 heures de True0xA3. Bien sûr, j'ai laissé de côté beaucoup. Par exemple, les conférences de presse sur l'arène, la torture qu'ont été le Wifi et le GSM, l'interaction avec les journalistes ... mais j'espère avoir capturé les moments les plus intéressants.

Ce fut l'une des expériences les plus stimulantes pour notre équipe, et j'espère avoir pu vous donner au moins un peu une idée de l'atmosphère de Standoff et vous inciter à essayer de participer aussi. !

Ensuite, je publierai la dernière partie de cette série, où j'analyserai nos erreurs et les moyens de les corriger à l'avenir. Parce qu'apprendre sur les erreurs de quelqu'un d'autre est le meilleur type d'apprentissage, non?