BreizhCTF 2017

Cette année encore nous avons eu le plaisir de rejoindre Rennes pour l’édition 2017 du BreizhCTF, toujours aussi bien organisé par Bretagne Développement Innovation, @SaxX et @Kaluche dans les locaux d’Epitech Rennes.

A l’issue de la nuit, nous nous sommes classés en 8ème place, mais avec la satisfaction d’avoir résolu presque toutes les épreuves.Bravo aux gagnants et merci aux organisateurs et sponsors !

Spy [realistic]

250 points | 49% de résolution

Une des épreuves identifiée comme « réaliste », nous donnait pour unique instruction de vérifier s’il était possible de compromettre le serveur cible ayant pour adresse IP « 10.119.227.111 » :

Une première phase d’analyse des ports accessibles sur ce serveur a donc été réalisée via l’outil nmap, afin d’identifier la surface d’exposition de celui-ci :

L’utilisation des scripts NSE nous révèle la version de Windows utilisée :

En recoupant ces informations avec le titre de l’épreuve (SPY), nous savons que nous allons devoir utiliser les exploits Windows révélés ces dernières semaines par les Shadow Brokers.

Note : Il est important de rappeler qu’au vu du peu de retours concernant la composition de ces outils, nous ne préconisons pas leurs utilisations en dehors d’un environnement de test cloisonné.

Après avoir installé les différentes dépendances nécessaires, nous lançons le Framework d’exploitation FuzzBunch, et plus précisément le module EternalBlue, permettant d’exploiter la vulnérabilité MS17-010 sur le protocole SMB :

Une fois le module lancé en précisant les différents paramètres souhaités, celui-ci installe une « backdoor » sur le poste (nous sommes sur la bonne voie :p).

Nous générons alors une DLL au préalable via le Framework Empire :

L’utilitaire « DoublePulsar » permet ensuite de charger cette DLL arbitraire sur le poste vulnérable, en spécifiant le chemin complet vers celle-ci :

Une fois l’ensemble des informations vérifié, nous pouvons lancer l’attaque :

Un agent Empire est alors récupéré avec les droits « NT SYSTEM » (\0/) :

Afin de simplifier la suite du scénario d’exploitation, nous créons simplement un utilisateur local appartenant au groupe des administrateurs locaux du poste compromis :

Il suffit alors de se connecter au service RDP précédemment identifié via le compte Administrateur créé :

Et de parcourir les dossiers de l’utilisateur « NSA » pour enfin accéder au flag de l’épreuve :

Pour information, la majorité des vulnérabilités révélées par les Shadow Brokers et impactant les systèmes d’exploitation Windows a été corrigée par Microsoft (cf. communication officielle).

Comme toujours, il convient donc d’appliquer les derniers correctifs de sécurité disponibles afin de se prémunir de ce type de scénario d’exploitation.

Enfin, le module Metasploit auxiliary/scanner/smb/smb_ms17_010 permet de vérifier la présence de la vulnérabilité MS17-010, en vérifiant les codes de retour lors des tentatives d’accès au partage IPC$ et l’envoi d’une transaction sur l’ID de fichier 0 (FID 0).

The Voting Machine [web]

175 points | 31% de résolution

Il s’agit d’une application Web simpliste avec seulement un formulaire qui propose de voter pour un président. Au-delà des champs textuels classiques (nom, prénom…) nous avons un upload d’image.

L’application vérifie que le fichier envoyé porte bien une extension d’image et l’upload d’une image invalide génère une erreur 500 laissant supposer que l’image est traitée d’une certaine manière. Sans indice sur l’éventuel stockage du fichier ni sur son emplacement, nous abandonnons la piste de l’upload d’un webshell et nous nous rappelons la fameuse vulnérabilité ImageTragick (CVE-2016–3714).

Le site officiel nous donne des pistes de payloads intéressants, nous confirmons la vulnérabilité par le déclenchement d’une SSRF en direction de notre machine avec le fichier foo.mvg suivant (cette extension exotique était acceptée par l’application Web, ce qui est suffisamment rare pour confirmer notre intuition) :

Nous nous sommes ensuite intéressés au payload plus intéressant : celui permettant d’exécuter des commandes arbitraires. Il est nécessaire de charger une image avec « https:// » pour déclencher l’injection de commande. Ici nul besoin d’obtenir un reverse shell interactif, le fichier suivant était suffisamment pour recevoir sur notre port 80 le résultat de la commande ls :

Logiquement nous repérons un fichier flag.txt dans le répertoire courant et obtenons son contenu :

Eddy Malou [web]

350 points | 57% de résolution

Cette application PHP simple permet de se connecter pour accéder à une liste de messages déposés par les utilisateurs. Nous pouvons également déposer notre message.

Toutes ces actions sont déclenchées par des requêtes POST sur la racine du site avec un paramètre action et un paramètre data.

Une valeur invalide du paramètre action déclenche une ReflectionException : le message d’erreur indique sans ambigüité que la méthode d’introspection getMethod est appelée sur l’objet courant avec le paramètre passé :

Nous pouvons donc appeler la méthode de notre choix, reste à découvrir la liste de ces méthodes. Nous pensons alors à la fonction magique __toString (voir notre write-up précédent du CTF de la Sthack 2017) ce qui fonctionne à merveille :

Nous appelons donc la méthode set_access pour devenir administrateur et nous voir offrir le flag (saluons au passage les tentatives d’injections diverses de nos concurrents) :

Shufflunatorz [web]

100 points | 63% de résolution

Cette application Web PHP nous propose de nous connecter en tant qu’admin et nous divulgue même son mot de passe, cependant l’application nous donne les bonnes lettres mais dans le désordre (shuffled), et les re-mélange à chaque soumission. Nous observons aussi la présence d’un jeton anti-rejeu qui change à chaque fois.

Nous générons en Python les 5040 combinaisons :

Puis décidons de tester toutes les combinaisons sur l’application. Pour ce faire nous utilisons Burp et le configurons pour extraire et reporter le jeton anti-rejeu d’une requête à l’autre, comme lorsque nous auditons une application comportant un jeton anti-CSRF.

Après un peu de patience (cette méthode ne permettant pas la parallélisation) nous sommes récompensés :

Cryptopat [crypto]

250 points | 9% de résolution

Nous avons réussi à intercepter une conversation entre Alice et Bob sur un canal non sécurisé. Malheureusement, le message contenant les informations sensibles dont nous souhaitons récupérer a été chiffré par le biais du chiffrement asymétrique RSA.

C’est pour cela que nous engageons les meilleurs cryptanalystes qui seront récompensés par des points s’ils parviennent à nous retrouver partiellement ou l’intégralité des données dont nous recherchons !

Pour vous faciliter la tâche nous vous avons extrait chacun de ces messages et les avons classés par ordre chronologique. (message1, puis message2 …). Nous avons également intercepté deux clés publique en provenance d’Alice. (d’abord pubkey, ensuite pubkey2). Espérons que cela suffise pour que vous puissiez nous aider !

Le challenge se présente sous la forme d’un archive contenant plusieurs fichiers : deux clés publiques, quatre messages déchiffrés et un message chiffré.

Les quatre messages contiennent l’extrait d’un échange entre Bob et Alice :

Trois informations importantes y sont présentées :

  • La première clé d’Alice est vulnérables à l’attaque de Wiener sur RSA ;
  • La seconde clé utilise le même exposant de chiffrement avec 15 bits de poids fort supplémentaires ;
  • La première moitié du flag est révélée dans les échanges !

L’objectif est donc d’utiliser l’attaque de Wiener sur la première clé publique afin de récupérer la clé privé correspondante, puis de bruteforcer la seconde clé privé à l’aide de la première.

Le challenge peut être résolu à l’aide d’un script effectuant les actions suivantes :

  • On effectue l’attaque de Wiener afin de récupérer l’exposant privé correspondant à la première clé publique ;
  • On valide que l’exposant privé récupéré correspond bien à la clé publique en déchiffrant un message ;
  • On itère sur toutes les solutions possible pour les 15 bits supplémentaire en essayant de déchiffrer un message pour trouver la seconde clé privée

On peut alors utiliser la clé privée pour déchiffrer la deuxième moitié du flag !

Script :

GoGoGoBabyGo [crypto]

100 points | 63% de résolution

Il s’agit d’une épreuve de crypto codée en Go. Le code était fourni, tâche à nous d’identifier la chaîne de départ ayant mené à la chaîne chiffrée présente dans le code.

L’algorithme de chiffrement plutôt simple est le suivant :

Nous choisissons une approche brute-force : nous allons générer la chaîne originale, en itérant caractère par caractère pour obtenir un chiffré qui correspond à celui qui est attendu. Voici le code écrit rapidement à partir duquel nous sommes partis :

Le début du flag, stocké dans input, nous était donné dans le script Go. La première exécution du script nous permet de découvrir un caractère supplémentaire, que nous reportons à la fin de input avant de le relancer. Nous répétons cette opération (qui aurait bien sûr pu être implémentée directement) quelques fois et obtenons enfin le flag qui correspond parfaitement à ce qui était souhaité :

BreizhCTF Party ! [crypto]

100 points | 71% de résolution

Nous arrivons sur une page Web au fond coloré flashy avec un titre et un fragment de binaire, qui nous renvoie en 1 seconde sur une seconde page avec un fond coloré flashy différent avec un autre fragment de binaire, ainsi de suite pour un total de 4 pages. Ce style stroboscopique flashy explique alors le sous-titre “party like it’s 1997” !

Nous avons l’intuition de XOR ces 4 fragments de binaire, octet par octet, avec ce script écrit rapidement :

Et nous obtenons instantanément le flag : bzhctf{XoRXoRXoR}

Diffie Failman [crypto]

200 points | 49% de résolution

Le titre de cette épreuve de crypto annonce clairement la couleur : il s’agit du protocole d’échange de clés Diffie Hellman. Nous avons à notre disposition un code-source Python, implémentant un client et un serveur, ainsi qu’une capture réseau pcap d’un échange utilisant ce programme.

La capture montre clairement l’échange de deux grands entiers, puis ce qui ressemble à un échange chiffré :

Nous confirmons cette observation à la lecture du code. En voici l’extrait qui concerne le côté serveur de cet échange :

Le premier message du serveur sert à envoyer au client, en clair, sa public_key, or il s’agit du produit de shared et private_key. Nous connaissons shared=65535 donc une simple division nous donne la private_key générée aléatoirement : perdu !

Les échanges sont chiffrés avec shared_secret qui est le condensat SHA256 de intermediate qui vaut le produit de private_key (que nous savons deviner) et de pub qui est simplement la clé publique du client envoyée en clair (que nous connaissons donc également).

En conclusion, un attaquant en situation de Man-in-the-Middle et connaissant le secret partagé codé en dur shared=65535 aura tous les éléments pour calculer de son côté la clé de chiffrement et déchiffrer les messages.

Pour preuve nous nous attaquons à l’échange chiffré, avec ce court script largement copié/collé de celui qui était fourni, que nous appliquons sur les messages échangés jusqu’à parvenir au message qui contient le flag :

Message en clair avec le flag : “Sure : BZHCTF{This_key_exchange_Sux}”

En conclusion, cet échange de clé semble implémenter un mécanisme similaire à Diffie Hellman, seulement ici l’utilisation d’un simple produit au lieu d’une exponentiation modulaire (donc plus simple à inverser) ne permet plus de protéger le secret créé. Il est donc important de rappeler qu’une implémentation maison d’un algorithme de cryptographie est fortement déconseillée tant il est facile d’insérer par mégarde des vulnérabilités critiques.

Cyber Bullshit Cyber [crypto]

250 points | 57% de résolution

Pour cette épreuve de crypto nous avons un script Python qui implémente les fonctions de chiffrement et déchiffrement d’un algorithme maison “custom CBC cipher based on SHA256 MAC”. L’exemple fourni chiffre puis déchiffre une chaîne de caractères avec une clé secrète.

Enfin, le script débute par un commentaire qui donne la chaîne qu’il nous incombe de déchiffrer.

Nous analysons dans le détail le fonctionnement de l’algorithme de chiffrement. Le fonctionnement de cet algorithme est le suivant :

  1. un vecteur d’initialisation (IV) aléatoire est généré
  2. un keystream (ks) est généré en appliquant un HMAC-SHA256 avec clé=IV et msg=clé secrète. Ceci semble être une erreur dans l’ordre des arguments, toutefois ce défaut n’a pu être exploité.
  3. le message est découpé en blocs car il s’agit d’un mode de chiffrement par blocs (CBC)
  4. le premier bloc est chiffré en le mélangeant avec un XOR avec le keystream (ks) précédemment préparé
  5. puis chaque bloc est chiffré avec du XOR de la même manière en le mélangeant avec le bloc précédent, et ainsi de suite
  6. le message chiffré est retourné, préfixé du vecteur d’initialisation (IV)

Le chiffré fait une taille de 96 octets, sachant que les blocs font 32 octets, cela donne un bloc d’IV puis deux blocs de données.

Au final nous avons quelque chose qui paraît compliqué mais qui se rapporte à un simple chiffrement par XOR avec une faiblesse bien connue qui est que cette opération s’annule si elle est dupliquée avec les mêmes arguments. En effet nous avons :

bloc2_chiffré = bloc2_clair XOR bloc1_chiffré

=>

bloc2_chiffré XOR bloc1_chiffré = bloc2_clair XOR bloc1_chiffré XOR bloc1_chiffré = bloc2_clair

Il ne reste plus qu’à implémenter ceci en quelques lignes :

Voici le flag : bzhctf{YOLOCRYPTO2017}

Recon [trivia]

100 points | 57% de résolution

La description de l’épreuve annonce que les organisateurs sont présents sur les réseaux sociaux d’avenir : l’actualité nous fait immédiatement penser à Mastodon mais reste encore à trouver l’instance de ce réseau décentralisé sur laquelle ils se sont inscrits.

Nous obtenons sur https://instances.mastodon.xyz/list la liste des instances, après un peu de formatage et d’extraction nous avons une liste d’URL, il ne reste plus qu’à itérer sur chacune à la recherche d’un code HTTP 200 pour le compte @breizhctf. La commande suivante, bien qu’imparfaite (dans le feu de l’action…), a très bien fait l’affaire :

Au bout de quelques secondes l’instance est identifiée :

Nous avons bien identifié le compte mais visiblement le flag n’est pas encore à notre portée :

Certains caractères s’affichent bizarrement en raison de leur remplacement par des caractères Unicode similaires. Après quelques tentatives pour deviner manuellement le flag, nous cherchons des articles ou applications relatifs à la stéganographie Unicode pour enfin tomber sur http://holloway.co.nz/steg/ qui nous donne à partir du message posté un lien vers un fichier contenant une liste d’URLs. Le dernier lien de la liste (merci pour la balade) nous donnant enfin le flag.

 

— Walid Arnoult, Clément Notin, Arthur Villeneuve