Translated ['src/hardware-physical-access/firmware-analysis/README.md',

2025-10-10 18:36:50 +00:00 · 2025-08-13 22:35:15 +00:00 · 2025-08-13 22:35:15 +00:00 · 472af6c212
commit 472af6c212
parent 4faed708eb
4 changed files with 216 additions and 23 deletions
--- 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)
--- 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 <bin> > hexdump.out
 hexdump -C <bin> | head #useful for finding signatures in the header
 fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
 ```
-Per valutare lo stato di crittografia dell'immagine, si controlla l'**entropia** con `binwalk -E <bin>`. 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 <bin>`. 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 <bin>`, è 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 <bin>`, è 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
--- a/src/hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md
+++ 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}}
--- 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}}