diff --git a/src/SUMMARY.md b/src/SUMMARY.md index bb1d3f659..0c1f23d74 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -769,6 +769,7 @@ - [Ret2vDSO](binary-exploitation/rop-return-oriented-programing/ret2vdso.md) - [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md) - [SROP - ARM64](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md) + - [Synology Encrypted Archive Decryption](hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md) - [Array Indexing](binary-exploitation/array-indexing.md) - [Chrome Exploiting](binary-exploitation/chrome-exploiting.md) - [Integer Overflow](binary-exploitation/integer-overflow.md) diff --git a/src/hardware-physical-access/firmware-analysis/README.md b/src/hardware-physical-access/firmware-analysis/README.md index 96361df94..2c3720e5e 100644 --- a/src/hardware-physical-access/firmware-analysis/README.md +++ b/src/hardware-physical-access/firmware-analysis/README.md @@ -4,6 +4,12 @@ ## **Introduzione** +### Risorse correlate + +{{#ref}} +synology-encrypted-archive-decryption.md +{{#endref}} + Il firmware è un software essenziale che consente ai dispositivi di funzionare correttamente gestendo e facilitando la comunicazione tra i componenti hardware e il software con cui gli utenti interagiscono. È memorizzato in memoria permanente, garantendo che il dispositivo possa accedere a istruzioni vitali dal momento in cui viene acceso, portando al lancio del sistema operativo. Esaminare e potenzialmente modificare il firmware è un passo critico per identificare vulnerabilità di sicurezza. ## **Raccolta di Informazioni** @@ -15,11 +21,11 @@ Il firmware è un software essenziale che consente ai dispositivi di funzionare - Layout hardware e schede tecniche - Metriche del codice sorgente e posizioni - Librerie esterne e tipi di licenza -- Storie degli aggiornamenti e certificazioni normative +- Storia degli aggiornamenti e certificazioni normative - Diagrammi architettonici e di flusso - Valutazioni di sicurezza e vulnerabilità identificate -A questo scopo, gli strumenti di **intelligence open-source (OSINT)** sono inestimabili, così come l'analisi di eventuali componenti software open-source disponibili attraverso processi di revisione manuale e automatizzati. Strumenti come [Coverity Scan](https://scan.coverity.com) e [Semmle’s LGTM](https://lgtm.com/#explore) offrono analisi statica gratuita che può essere sfruttata per trovare potenziali problemi. +A questo scopo, gli strumenti di **intelligence open-source (OSINT)** sono inestimabili, così come l'analisi di eventuali componenti software open-source disponibili attraverso processi di revisione manuale e automatizzati. Strumenti come [Coverity Scan](https://scan.coverity.com) e [Semmle’s LGTM](https://lgtm.com/#explore) offrono analisi statica gratuita che possono essere sfruttate per trovare potenziali problemi. ## **Acquisizione del Firmware** @@ -37,7 +43,7 @@ Ottenere il firmware può essere affrontato attraverso vari mezzi, ognuno con il - **Dumping** dal bootloader o dalla rete - **Rimuovendo e leggendo** il chip di memoria, quando tutto il resto fallisce, utilizzando strumenti hardware appropriati -## Analizzando il firmware +## Analizzare il firmware Ora che **hai il firmware**, devi estrarre informazioni su di esso per sapere come trattarlo. Diversi strumenti che puoi utilizzare per questo: ```bash @@ -126,13 +132,13 @@ hexdump -C -n 512 > hexdump.out hexdump -C | head #useful for finding signatures in the header fdisk -lu #lists partitions and filesystems, if there are multiple ``` -Per valutare lo stato di crittografia dell'immagine, si controlla l'**entropia** con `binwalk -E `. Un'entropia bassa suggerisce una mancanza di crittografia, mentre un'entropia alta indica una possibile crittografia o compressione. +Per valutare lo stato della crittografia dell'immagine, si controlla l'**entropia** con `binwalk -E `. Un'entropia bassa suggerisce una mancanza di crittografia, mentre un'entropia alta indica una possibile crittografia o compressione. -Per estrarre i **file incorporati**, si raccomandano strumenti e risorse come la documentazione **file-data-carving-recovery-tools** e **binvis.io** per l'ispezione dei file. +Per estrarre i **file incorporati**, si raccomandano strumenti e risorse come la documentazione di **file-data-carving-recovery-tools** e **binvis.io** per l'ispezione dei file. ### Estrazione del Filesystem -Utilizzando `binwalk -ev `, è possibile solitamente estrarre il filesystem, spesso in una directory chiamata in base al tipo di filesystem (ad esempio, squashfs, ubifs). Tuttavia, quando **binwalk** non riesce a riconoscere il tipo di filesystem a causa di byte magici mancanti, è necessaria un'estrazione manuale. Questo comporta l'uso di `binwalk` per localizzare l'offset del filesystem, seguito dal comando `dd` per estrarre il filesystem: +Utilizzando `binwalk -ev `, è possibile solitamente estrarre il filesystem, spesso in una directory chiamata con il tipo di filesystem (ad esempio, squashfs, ubifs). Tuttavia, quando **binwalk** non riesce a riconoscere il tipo di filesystem a causa di byte magici mancanti, è necessaria un'estrazione manuale. Questo comporta l'uso di `binwalk` per localizzare l'offset del filesystem, seguito dal comando `dd` per estrarre il filesystem: ```bash $ binwalk DIR850L_REVB.bin @@ -147,7 +153,7 @@ Con il filesystem estratto, inizia la ricerca di vulnerabilità di sicurezza. Si **Posizioni chiave** e **elementi** da ispezionare includono: - **etc/shadow** e **etc/passwd** per le credenziali degli utenti -- Certificati e chiavi SSL in **etc/ssl** +- Certificati SSL e chiavi in **etc/ssl** - File di configurazione e script per potenziali vulnerabilità - Binari incorporati per ulteriori analisi - Server web e binari comuni dei dispositivi IoT @@ -180,7 +186,7 @@ E per installare gli strumenti di emulazione necessari: ```bash sudo apt-get install qemu qemu-user qemu-user-static qemu-system-arm qemu-system-mips qemu-system-x86 qemu-utils ``` -Per MIPS (big-endian), si utilizza `qemu-mips`, e per i binari little-endian, `qemu-mipsel` sarebbe la scelta. +Per MIPS (big-endian), si utilizza `qemu-mips`, e per i binari little-endian, la scelta sarebbe `qemu-mipsel`. #### Emulazione dell'Architettura ARM @@ -194,22 +200,22 @@ Strumenti come [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware An A questo stadio, viene utilizzato un ambiente di dispositivo reale o emulato per l'analisi. È essenziale mantenere l'accesso shell al sistema operativo e al filesystem. L'emulazione potrebbe non imitare perfettamente le interazioni hardware, rendendo necessari occasionali riavvii dell'emulazione. L'analisi dovrebbe riesaminare il filesystem, sfruttare le pagine web e i servizi di rete esposti, ed esplorare le vulnerabilità del bootloader. I test di integrità del firmware sono critici per identificare potenziali vulnerabilità di backdoor. -## Tecniche di Analisi in Esecuzione +## Tecniche di Analisi Runtime -L'analisi in esecuzione implica l'interazione con un processo o binario nel suo ambiente operativo, utilizzando strumenti come gdb-multiarch, Frida e Ghidra per impostare breakpoint e identificare vulnerabilità attraverso fuzzing e altre tecniche. +L'analisi runtime implica l'interazione con un processo o un binario nel suo ambiente operativo, utilizzando strumenti come gdb-multiarch, Frida e Ghidra per impostare breakpoint e identificare vulnerabilità attraverso fuzzing e altre tecniche. ## Sfruttamento Binario e Proof-of-Concept -Sviluppare un PoC per vulnerabilità identificate richiede una profonda comprensione dell'architettura target e programmazione in linguaggi di basso livello. Le protezioni binarie in esecuzione nei sistemi embedded sono rare, ma quando presenti, tecniche come il Return Oriented Programming (ROP) possono essere necessarie. +Sviluppare un PoC per vulnerabilità identificate richiede una profonda comprensione dell'architettura target e programmazione in linguaggi di basso livello. Le protezioni runtime binarie nei sistemi embedded sono rare, ma quando presenti, tecniche come il Return Oriented Programming (ROP) possono essere necessarie. ## Sistemi Operativi Preparati per l'Analisi del Firmware -Sistemi operativi come [AttifyOS](https://github.com/adi0x90/attifyos) e [EmbedOS](https://github.com/scriptingxss/EmbedOS) forniscono ambienti pre-configurati per il testing della sicurezza del firmware, dotati degli strumenti necessari. +Sistemi operativi come [AttifyOS](https://github.com/adi0x90/attifyos) e [EmbedOS](https://github.com/scriptingxss/EmbedOS) forniscono ambienti preconfigurati per il testing della sicurezza del firmware, dotati degli strumenti necessari. ## OS Preparati per Analizzare il Firmware -- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS è una distribuzione destinata ad aiutarti a eseguire valutazioni di sicurezza e penetration testing di dispositivi Internet of Things (IoT). Ti fa risparmiare molto tempo fornendo un ambiente pre-configurato con tutti gli strumenti necessari caricati. -- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Sistema operativo per il testing della sicurezza embedded basato su Ubuntu 18.04 pre-caricato con strumenti per il testing della sicurezza del firmware. +- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS è una distribuzione destinata ad aiutarti a eseguire valutazioni di sicurezza e penetration testing di dispositivi Internet of Things (IoT). Ti fa risparmiare molto tempo fornendo un ambiente preconfigurato con tutti gli strumenti necessari caricati. +- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Sistema operativo per il testing della sicurezza embedded basato su Ubuntu 18.04 precaricato con strumenti per il testing della sicurezza del firmware. ## Attacchi di Downgrade del Firmware e Meccanismi di Aggiornamento Insicuri @@ -224,7 +230,7 @@ Flusso di attacco tipico: 2. **Caricare o servire l'immagine al dispositivo** tramite qualsiasi canale di aggiornamento esposto: * Interfaccia Web, API dell'app mobile, USB, TFTP, MQTT, ecc. * Molti dispositivi IoT consumer espongono endpoint HTTP(S) *non autenticati* che accettano blob di firmware codificati in Base64, li decodificano lato server e attivano il ripristino/aggiornamento. -3. Dopo il downgrade, sfruttare una vulnerabilità che è stata corretta nella versione più recente (ad esempio, un filtro di iniezione di comandi che è stato aggiunto successivamente). +3. Dopo il downgrade, sfruttare una vulnerabilità che è stata corretta nella versione più recente (ad esempio, un filtro di injection di comandi che è stato aggiunto successivamente). 4. Facoltativamente, flashare l'immagine più recente o disabilitare gli aggiornamenti per evitare il rilevamento una volta ottenuta la persistenza. ### Esempio: Iniezione di Comandi Dopo il Downgrade @@ -238,7 +244,7 @@ Nel firmware vulnerabile (downgradato), il parametro `md5` è concatenato dirett ### Estrazione del Firmware da App Mobili -Molti fornitori includono immagini firmware complete all'interno delle loro applicazioni mobili companion in modo che l'app possa aggiornare il dispositivo tramite Bluetooth/Wi-Fi. Questi pacchetti sono comunemente memorizzati non crittografati nell'APK/APEX sotto percorsi come `assets/fw/` o `res/raw/`. Strumenti come `apktool`, `ghidra`, o anche il semplice `unzip` ti consentono di estrarre immagini firmate senza toccare l'hardware fisico. +Molti fornitori includono immagini firmware complete all'interno delle loro applicazioni mobili companion in modo che l'app possa aggiornare il dispositivo tramite Bluetooth/Wi-Fi. Questi pacchetti sono comunemente memorizzati non crittografati nell'APK/APEX sotto percorsi come `assets/fw/` o `res/raw/`. Strumenti come `apktool`, `ghidra` o anche il semplice `unzip` ti consentono di estrarre immagini firmate senza toccare l'hardware fisico. ``` $ apktool d vendor-app.apk -o vendor-app $ ls vendor-app/assets/firmware diff --git a/src/hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md b/src/hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md new file mode 100644 index 000000000..105698572 --- /dev/null +++ b/src/hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md @@ -0,0 +1,162 @@ +# Decrittazione dell'Archivio Crittografato PAT/SPK di Synology + +{{#include ../../banners/hacktricks-training.md}} + +## Panoramica + +Diverse apparecchiature Synology (DSM/BSM NAS, BeeStation, …) distribuiscono il loro firmware e i pacchetti applicativi in **archivi PAT / SPK crittografati**. Questi archivi possono essere decrittografati *offline* con nient'altro che i file di download pubblici grazie a chiavi hard-coded incorporate all'interno delle librerie di estrazione ufficiali. + +Questa pagina documenta, passo dopo passo, come funziona il formato crittografato e come recuperare completamente il **TAR** in chiaro che si trova all'interno di ciascun pacchetto. La procedura si basa sulla ricerca di Synacktiv effettuata durante Pwn2Own Irlanda 2024 e implementata nello strumento open-source [`synodecrypt`](https://github.com/synacktiv/synodecrypt). + +> ⚠️ Il formato è esattamente lo stesso per gli archivi `*.pat` (aggiornamento di sistema) e `*.spk` (applicazione) – differiscono solo nella coppia di chiavi hard-coded selezionate. + +--- + +## 1. Ottieni l'archivio + +L'aggiornamento del firmware/applicazione può normalmente essere scaricato dal portale pubblico di Synology: +```bash +$ wget https://archive.synology.com/download/Os/BSM/BSM_BST150-4T_65374.pat +``` +## 2. Dump the PAT structure (opzionale) + +`*.pat` immagini sono esse stesse un **cpio bundle** che incorpora diversi file (boot loader, kernel, rootfs, pacchetti…). L'utilità gratuita [`patology`](https://github.com/sud0woodo/patology) è comoda per ispezionare quel wrapper: +```bash +$ python3 patology.py --dump -i BSM_BST150-4T_65374.pat +[…] +$ ls +DiskCompatibilityDB.tar hda1.tgz rd.bin packages/ … +``` +Per `*.spk` puoi saltare direttamente al passo 3. + +## 3. Estrai le librerie di estrazione di Synology + +La vera logica di decrittazione si trova in: + +* `/usr/syno/sbin/synoarchive` → wrapper principale della CLI +* `/usr/lib/libsynopkg.so.1` → chiama il wrapper dall'interfaccia DSM +* `libsynocodesign.so` → **contiene l'implementazione crittografica** + +Entrambi i binari sono presenti nel rootfs di sistema (`hda1.tgz`) **e** nel init-rd compresso (`rd.bin`). Se hai solo il PAT puoi ottenerli in questo modo: +```bash +# rd.bin is LZMA-compressed CPIO +$ lzcat rd.bin | cpio -id 2>/dev/null +$ file usr/lib/libsynocodesign.so +usr/lib/libsynocodesign.so: ELF 64-bit LSB shared object, ARM aarch64, … +``` +## 4. Recupera le chiavi hard-coded (`get_keys`) + +All'interno di `libsynocodesign.so`, la funzione `get_keys(int keytype)` restituisce semplicemente due variabili globali da 128 bit per la famiglia di archivi richiesta: +```c +case 0: // PAT (system) +case 10: +case 11: +signature_key = qword_23A40; +master_key = qword_23A68; +break; + +case 3: // SPK (applications) +signature_key = qword_23AE0; +master_key = qword_23B08; +break; +``` +* **signature_key** → Chiave pubblica Ed25519 utilizzata per verificare l'intestazione dell'archivio. +* **master_key** → Chiave radice utilizzata per derivare la chiave di crittografia per ogni archivio. + +Devi solo estrarre queste due costanti una volta per ogni versione principale di DSM. + +## 5. Struttura dell'intestazione e verifica della firma + +`synoarchive_open()` → `support_format_synoarchive()` → `archive_read_support_format_synoarchive()` esegue quanto segue: + +1. Leggi magic (3 byte) `0xBFBAAD` **o** `0xADBEEF`. +2. Leggi little-endian 32-bit `header_len`. +3. Leggi `header_len` byte + la successiva **firma Ed25519 di 0x40 byte**. +4. Itera su tutte le chiavi pubbliche incorporate fino a quando `crypto_sign_verify_detached()` ha successo. +5. Decodifica l'intestazione con **MessagePack**, producendo: +```python +[ +data: bytes, +entries: [ [size: int, sha256: bytes], … ], +archive_description: bytes, +serial_number: [bytes], +not_valid_before: int +] +``` +`entries` consente successivamente a libarchive di controllare l'integrità di ciascun file mentre viene decrittografato. + +## 6. Derivare la sottochiave per archivio + +Dal blob `data` contenuto nell'intestazione MessagePack: + +* `subkey_id` = little-endian `uint64` all'offset 0x10 +* `ctx` = 7 byte all'offset 0x18 + +La **chiave di stream** di 32 byte è ottenuta con libsodium: +```c +crypto_kdf_derive_from_key(kdf_subkey, 32, subkey_id, ctx, master_key); +``` +## 7. Backend personalizzato di **libarchive** di Synology + +Synology include una libarchive patchata che registra un formato "tar" falso ogni volta che il magic è `0xADBEEF`: +```c +register_format( +"tar", spk_bid, spk_options, +spk_read_header, spk_read_data, spk_read_data_skip, +NULL, spk_cleanup, NULL, NULL); +``` +### spk_read_header() +``` +- Read 0x200 bytes +- nonce = buf[0:0x18] +- cipher = buf[0x18:0x18+0x193] +- crypto_secretstream_xchacha20poly1305_init_pull(state, nonce, kdf_subkey) +- crypto_secretstream_xchacha20poly1305_pull(state, tar_hdr, …, cipher, 0x193) +``` +L'`tar_hdr` decrittografato è un **header TAR POSIX classico**. + +### spk_read_data() +``` +while (remaining > 0): +chunk_len = min(0x400000, remaining) + 0x11 # +tag +buf = archive_read_ahead(chunk_len) +crypto_secretstream_xchacha20poly1305_pull(state, out, …, buf, chunk_len) +remaining -= chunk_len - 0x11 +``` +Ogni **nonce di 0x18 byte** è preceduto dal chunk crittografato. + +Una volta che tutte le voci sono state elaborate, libarchive produce un **`.tar`** perfettamente valido che può essere estratto con qualsiasi strumento standard. + +## 8. Decrittografa tutto con synodecrypt +```bash +$ python3 synodecrypt.py SynologyPhotos-rtd1619b-1.7.0-0794.spk +[+] found matching keys (SPK) +[+] header signature verified +[+] 104 entries +[+] archive successfully decrypted → SynologyPhotos-rtd1619b-1.7.0-0794.tar + +$ tar xf SynologyPhotos-rtd1619b-1.7.0-0794.tar +``` +`synodecrypt` rileva automaticamente PAT/SPK, carica le chiavi corrette e applica l'intera catena descritta sopra. + +## 9. Errori comuni + +* Non scambiare `signature_key` e `master_key` – servono a scopi diversi. +* Il **nonce** viene *prima* del ciphertext per ogni blocco (header e dati). +* La dimensione massima del chunk crittografato è **0x400000 + 0x11** (tag libsodium). +* Gli archivi creati per una generazione DSM possono passare a chiavi hard-coded diverse nella release successiva. + +## 10. Strumenti aggiuntivi + +* [`patology`](https://github.com/sud0woodo/patology) – analizza/dumpa archivi PAT. +* [`synodecrypt`](https://github.com/synacktiv/synodecrypt) – decripta PAT/SPK/altro. +* [`libsodium`](https://github.com/jedisct1/libsodium) – implementazione di riferimento di XChaCha20-Poly1305 secretstream. +* [`msgpack`](https://msgpack.org/) – serializzazione dell'header. + +## Riferimenti + +- [Estrazione di archivi crittografati Synology – Synacktiv (Pwn2Own IE 2024)](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html) +- [synodecrypt su GitHub](https://github.com/synacktiv/synodecrypt) +- [patology su GitHub](https://github.com/sud0woodo/patology) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/command-injection.md b/src/pentesting-web/command-injection.md index 09a528c79..442166a0f 100644 --- a/src/pentesting-web/command-injection.md +++ b/src/pentesting-web/command-injection.md @@ -2,7 +2,7 @@ {{#include ../banners/hacktricks-training.md}} -## Cos'è l'iniezione di comandi? +## Che cos'è l'iniezione di comandi? Un **command injection** consente l'esecuzione di comandi arbitrari del sistema operativo da parte di un attaccante sul server che ospita un'applicazione. Di conseguenza, l'applicazione e tutti i suoi dati possono essere completamente compromessi. L'esecuzione di questi comandi consente tipicamente all'attaccante di ottenere accesso non autorizzato o controllo sull'ambiente dell'applicazione e sul sistema sottostante. @@ -10,7 +10,7 @@ Un **command injection** consente l'esecuzione di comandi arbitrari del sistema A seconda di **dove il tuo input viene iniettato**, potresti dover **terminare il contesto citato** (utilizzando `"` o `'`) prima dei comandi. -## Command Injection/Esecuzione +## Command Injection/Execution ```bash #Both Unix and Windows supported ls||id; ls ||id; ls|| id; ls || id # Execute both @@ -29,7 +29,7 @@ ls${LS_COLORS:10:1}${IFS}id # Might be useful > /var/www/html/out.txt #Try to redirect the output to a file < /etc/passwd #Try to send some input to the command ``` -### **Bypass delle Limitazioni** +### **Limitazioni** Bypass Se stai cercando di eseguire **comandi arbitrari all'interno di una macchina linux** ti interesserà leggere riguardo a questi **Bypass:** @@ -73,9 +73,9 @@ Ecco i 25 parametri principali che potrebbero essere vulnerabili a iniezioni di ?run={payload} ?print={payload} ``` -### Estrazione di dati basata sul tempo +### Time based data exfiltration -Estrazione di dati: carattere per carattere +Estrazione dei dati: carattere per carattere ``` swissky@crashlab▸ ~ ▸ $ time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi real 0m5.007s @@ -87,7 +87,7 @@ real 0m0.002s user 0m0.000s sys 0m0.000s ``` -### Esfiltrazione di dati basata su DNS +### DNS based data exfiltration Basato sullo strumento di `https://github.com/HoLyVieR/dnsbin` anche ospitato su dnsbin.zhack.ca ``` @@ -117,7 +117,29 @@ powershell C:**2\n??e*d.*? # notepad ../linux-hardening/bypass-bash-restrictions/ {{#endref}} -## Elenco di Rilevamento Brute-Force +### Node.js `child_process.exec` vs `execFile` + +Quando si eseguono audit su back-end JavaScript/TypeScript, ci si imbatte spesso nell'API `child_process` di Node.js. +```javascript +// Vulnerable: user-controlled variables interpolated inside a template string +const { exec } = require('child_process'); +exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(payload)}'`, (err, stdout) => { +/* … */ +}); +``` +`exec()` genera una **shell** (`/bin/sh -c`), quindi qualsiasi carattere che ha un significato speciale per la shell (back-ticks, `;`, `&&`, `|`, `$()`, …) risulterà in **command injection** quando l'input dell'utente è concatenato nella stringa. + +**Mitigazione:** usa `execFile()` (o `spawn()` senza l'opzione `shell`) e fornisci **ogni argomento come un elemento separato dell'array** in modo che non sia coinvolta alcuna shell: +```javascript +const { execFile } = require('child_process'); +execFile('/usr/bin/do-something', [ +'--id_user', id_user, +'--payload', JSON.stringify(payload) +]); +``` +Caso reale: *Synology Photos* ≤ 1.7.0-0794 era sfruttabile attraverso un evento WebSocket non autenticato che inseriva dati controllati dall'attaccante in `id_user`, successivamente incorporati in una chiamata `exec()`, ottenendo RCE (Pwn2Own Irlanda 2024). + +## Elenco di rilevamento Brute-Force {{#ref}} https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/command_injection.txt @@ -125,7 +147,9 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/command_inject ## Riferimenti +- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection) - [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection) - [https://portswigger.net/web-security/os-command-injection](https://portswigger.net/web-security/os-command-injection) +- [Extraction of Synology encrypted archives – Synacktiv 2025](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html) {{#include ../banners/hacktricks-training.md}}