Plot#
Seems like Meridian is stuck again. Good news for you if you want the Ion$. They were even kind enough to provide you with a foothold this time, more info below:
[INTERCEPTED TRANSMISSION: VANGUARD ORBITAL SECURITY]
Priority: CRITICAL
Subject: Deprecation of Local Signing Keys
To all Flight Software Engineers:
Effective immediately, local compiling and binary signing for the Vanguard CubeSat constellation is strictly prohibited. The PROD_SIGNING_KEY has been securely injected into the internal CI/CD runner environments.
Do not submit IT tickets asking for the key. If your code passes the automated checks, the runner will sign the release bundle for you. The internal Gitea server (127.0.0.1:3000) is air-gapped from the public net. Security is absolute.
Find a way to exfiltrate the production key, they'll take it from there.
Access Terminal: https://[challenge-url]/shell/
https://starpwn-112a18b481da-bad-gitea-0-0.chals.io/Résolution#
En déployant l’application et en se rendant sur l’URL, voici ce que l’on obtient :
Puis, en fouillant un peu, on trouve deux pages intéressantes :
La première page nous permet de leak deux users :
builddevadmin
Et la deuxième page nous permettra de nous connecter dès lors que l’on aura récupéré des creds valides.
Pour le moment, intéressons-nous au terminal disponible à https://[challenge-url]/shell/.
Les premières informations sont les suivantes :
En refaisant le challenge, je me suis rendu compte qu’il était possible de récupérer le flag bien plus rapidement. Peu importe si cela était fait exprès par les créateurs du challenge, le hacking, c’est aussi contourner les chemins “officiels”.
La méthode plus rapide sera décrite dans la section Raccourci.
Faisons comme si de rien n’était.
En fouillant dans les fichiers présents dans le répertoire courant, on trouve des creds du user builddev :
Nous en profitons directement pour nous connecter à la plateforme Gitea.
Immédiatement, nous voyons un repository nommé build-service.
Les fichiers app.py, Makefile et package-release.sh ne contiennent rien d’intéressant. Le dossier scripts non plus.
Il ne nous reste plus que le dossier .gitea/workflow, qui contient le fichier principal de la pipeline CI/CD.
Immédiatement, on peut remarquer la variable SIGNING_KEY, qui charge le secret PROD_SIGNING_KEY, qui est la clé qui nous intéresse.
Pour comprendre ce que fait la pipeline, commençons par le bloc on.
Le bloc on est le bloc dans lequel on retrouve les conditions pour que la pipeline se déclenche. Ici, elle se déclenche sous l’une des deux conditions suivantes :
Un push sur n’importe quelle branche (caractérisé par "**" sous le bloc branches) ou bien une pull_request (pas de condition supplémentaire).
Ensuite, le bloc jobs décrit les actions qui vont être réalisées si la pipeline se déclenche. On voit donc que des variables sont chargées, puis une suite de commandes git, ainsi qu’un make et l’exécution d’un script shell (on s’en fout un peu).
Étant donné qu’on sait quel élément nous intéresse (SIGNING_KEY), il ne nous reste plus qu’à ruser pour récupérer son contenu.
Première idée : on va simplement afficher, à l’aide de la commande echo, la valeur de cette variable. Ainsi, lors de l’exécution de la pipeline, nous serons en mesure de voir son contenu dans les logs de la pipeline.
C’est parti !
- On modifie la pipeline.
- On crée une branche (afin de faire une PR ensuite et de déclencher la pipeline).
- Puis on crée une PR.
- On check les logs de la pipeline.
Malheureusement, l’output nous donne ***.
En fait, cela est tout à fait normal : la pipeline masque les variables qui proviennent du contexte secrets.*. De la même manière, il n’est pas possible d’afficher directement un fichier contenant la variable d’environnement dans les logs. Il va donc falloir ruser un peu.
Je suis retourné sur le /shell pour interagir avec le système et récupérer d’autres informations utiles.
La première chose que je voulais faire, c’était énumérer les users sur la machine.
On trouve le user git (moyennement intéressant tant qu’on n’a pas le mdp).
On va tester la stratégie suivante :
- Créer un fichier
.txtcontenant la variable d’environnement. - Placer ce fichier dans le répertoire
/home/player, puis lire le fichier depuis le terminal.
Allons-y !
On lance la pipeline, toujours grâce à la PR.
On se rend sur le terminal :
Et bingo !
On remarque que l’on a plusieurs fois le flag, c’est tout simplement parce que la pipeline s’est exécutée plusieurs fois.
Raccourci#
Ainsi, en repartant de la première étape avec le terminal :
Et en affichant les variables d’environnement :
Voilà pourquoi j’ai utilisé l’expression “bien plus rapidement”.