Che cos'è l'OS Command Injection?
L'OS command injection è una vulnerabilità che consente agli attaccanti di eseguire comandi arbitrari del sistema operativo su un server tramite un'applicazione vulnerabile. Classificata come CWE-78 da MITRE, si verifica quando un'applicazione costruisce comandi OS utilizzando input forniti esternamente senza neutralizzare correttamente i caratteri speciali che possono alterare il comando previsto. Il risultato è un accesso diretto e non autorizzato al sistema operativo sottostante.
Questa classe di vulnerabilità è stata collegata a importanti attacchi informatici, dalla massiccia exploitation di Shellshock del 2014 al targeting continuo di appliance di rete documentato in un avviso CISA. CWE-78 si colloca tra i primi 25 della classifica MITRE, insieme a out-of-bounds write, cross-site scripting e SQL injection.
Nell'OWASP Top 10, la categoria più ampia Injection mappa sia CWE-77 che CWE-78. Comprendere come funziona la vulnerabilità a livello di shell è il primo passo per fermarla.
.jpg)
Come funziona l'OS Command Injection?
L'OS command injection sfrutta un difetto fondamentale: un'applicazione passa input controllato dall'utente direttamente in un comando shell OS senza separare i dati dalle istruzioni di controllo.
MITRE identifica due sottotipi di OS command injection.
Sottotipo 1: Diretto (Command Separator Injection)
L'applicazione intende eseguire un singolo programma fisso, utilizzando input esterni solo come argomenti. Gli attaccanti iniettano separatori di comando (;, |, &&, || o newline) per aggiungere comandi aggiuntivi.
Considera un'applicazione web che esegue ricerche DNS:
Un attaccante fornisce example.com; cat /etc/passwd come parametro dominio. La shell esegue sia nslookup example.com sia cat /etc/passwd, restituendo il file delle password del server.
Sottotipo 2: Indiretto (Controllo Completo del Comando)
L'applicazione accetta input che determina interamente quale programma eseguire. L'attaccante controlla il comando completo, non solo i suoi argomenti:
Se un attaccante controlla la proprietà SCRIPTNAME, può puntarla a qualsiasi eseguibile sul sistema.
Il flusso dell'attacco
Un tipico attacco di OS command injection segue questa sequenza:
- L'attaccante identifica un campo di input, come un parametro di form, header HTTP, cookie o stringa di query URL, che alimenta un comando lato server.
- L'attaccante inietta metacaratteri della shell combinati con un comando malevolo in quell'input.
- L'applicazione passa l'input non sanificato alla shell OS.
- La shell interpreta i metacaratteri ed esegue il comando iniettato con gli stessi privilegi del processo applicativo. Se l'applicazione gira come root, l'attaccante ottiene gli stessi privilegi.
Ognuno di questi passaggi dipende dall'interpretazione da parte della shell di caratteri specifici come istruzioni di controllo. Gli operatori che rendono possibile ciò variano in base alla piattaforma.
Operatori e Metacaratteri di Injection Comuni
L'OS command injection si basa su metacaratteri della shell che alterano il modo in cui il sistema operativo interpreta una stringa di comando. Gli operatori disponibili per un attaccante dipendono dalla piattaforma di destinazione.
Separatori di Comando ed Esecuzione Inline
| Operatore | Funzione | Piattaforma |
| ; | Esegue i comandi in sequenza | Unix |
| & | Esegue il secondo comando in background | Unix e Windows |
| && | Esegue il secondo comando solo se il primo ha successo | Unix e Windows |
| || | Esegue il secondo comando solo se il primo fallisce | Unix e Windows |
| | | Passa l'output del primo comando al secondo | Unix e Windows |
| ` (backticks) | Esecuzione inline; l'output sostituisce l'espressione | Unix |
| $() | Esecuzione inline; funzionalmente equivalente ai backticks | Unix |
| 0x0a (newline) | Avvia un nuovo comando su alcune shell | Unix |
Quando l'input utente finisce all'interno di una stringa quotata nel comando originale, l'attaccante deve prima chiudere la quota (" o ') prima che qualsiasi separatore abbia effetto. Tecniche di encoding come URL encoding, double encoding e normalizzazione Unicode possono anche bypassare i filtri che cercano questi caratteri nella loro forma letterale. Questi operatori raggiungono la shell a causa di pattern di codifica specifici che non separano i dati utente dalla sintassi del comando.
Cause dell'OS Command Injection
L'OS command injection deriva da pratiche di codifica che consentono all'input utente di raggiungere una shell di sistema senza controlli adeguati. Cinque cause principali spiegano la maggior parte delle vulnerabilità.
Validazione dell'Input Insufficiente
Questa è la causa più diretta. Secondo la guida OWASP, gli attacchi di command injection diventano possibili quando un'applicazione passa dati non sicuri forniti dall'utente, come form, cookie e header HTTP, a una shell di sistema senza sanificazione. Se si presume che gli utenti forniscano valori attesi, si può saltare completamente la validazione.
Uso dell'Esecuzione Shell invece delle API Native del Linguaggio
Chiamare system(), exec(), shell_exec() o os.system() invoca la shell OS come intermediario. Ogni invocazione della shell crea una superficie di injection. La cheat sheet OWASP identifica API pericolose nei principali linguaggi:
| Linguaggio | API Pericolose |
| Java | Runtime.exec() |
| C / C++ | system(), exec(), ShellExecute() |
| Python | exec(), eval(), os.system(), os.popen(), subprocess.Popen(), subprocess.call() |
| PHP | system(), shell_exec(), exec(), proc_open(), eval(), passthru() |
| Node.js | child_process.exec(), execSync(), spawn() |
Affidamento al Filtering Denylist
Si può tentare di bloccare caratteri pericolosi specifici invece di definire ciò che è permesso. Questo approccio, classificato come CWE-184 (Denylist Incompleto), fallisce costantemente. OWASP documenta esplicitamente che escapeshellcmd() di PHP previene l'esecuzione di comandi aggiuntivi ma consente comunque l'argument injection. Gli attaccanti possono iniettare flag come --output-document= per ottenere la scrittura di file senza usare separatori di comando.
Manipolazione delle Variabili d'Ambiente
Quando le applicazioni non specificano percorsi assoluti per gli eseguibili e non puliscono le variabili d'ambiente, gli attaccanti possono reindirizzare $PATH verso binari malevoli. Se l'applicazione gira con privilegi setuid root, il binario dell'attaccante viene eseguito con accesso root.
Violazione del Principio del Minimo Privilegio
Le applicazioni che girano con privilegi elevati amplificano ogni difetto di injection. Una command injection contro un'applicazione in esecuzione come www-data limita l'attaccante ai permessi di quell'utente. La stessa injection contro un processo a livello root concede il controllo completo del sistema. Se una di queste cause non viene affrontata, l'impatto risultante si estende ben oltre l'applicazione vulnerabile stessa.
Impatto e Rischio dell'OS Command Injection
L'OS command injection ottiene costantemente i punteggi più alti nei sistemi di classificazione delle vulnerabilità. L' OWASP Top 10:2021 identifica l'injection come una categoria di rischio importante e persistente. L'impatto funzionale è diretto: un attaccante ottiene la capacità di eseguire comandi arbitrari sul server con gli stessi privilegi del processo applicativo compromesso.
Gravità per Categoria di Impatto
| Impatto | Evidenza |
| Esecuzione di Codice Remoto | CVE-2024-3400 |
| Compromissione Completa del Sistema | SANS report: "compromissione completa del sistema, esfiltrazione dati o infiltrazione di rete" |
| Lateral Movement | CISA advisory: OS command injection combinato con path traversal che abilita intrusioni multi-stage |
| Reclutamento Botnet | Mirai variant |
| Distribuzione Ransomware | CISA advisory; CISA advisory |
I punteggi CVSS non raccontano tutta la storia
CVE-2024-20399 (Cisco NX-OS) ha un punteggio CVSS relativamente modesto e richiede accesso locale e privilegi amministrativi. Tuttavia CISA lo ha aggiunto al catalogo Known Exploited Vulnerabilities dopo aver confermato l'exploitation da parte della campagna Velvet Ant di matrice cinese.
Questo caso illustra che i punteggi CVSS da soli non riflettono il rischio operativo. L'appartenenza al catalogo KEV, l'exploitation da parte di stati-nazione e la posizione del dispositivo nella rete sono fattori di rischio indipendenti che possono superare di gran lunga un punteggio base. Comprendere le tecniche specifiche utilizzate dagli attaccanti aiuta a spiegare perché l'exploitation confermata è così comune.
Come gli Attaccanti Sfruttano l'OS Command Injection
Gli attaccanti utilizzano una progressione di tecniche per trovare, confermare e sfruttare l'OS command injection, iniziando dalla discovery ed escalando tramite blind injection e chaining di vulnerabilità.
Discovery ed Enumerazione
Gli attaccanti identificano campi di input che interagiscono con comandi di sistema lato server, testando tutti i parametri, header HTTP (User-Agent, Referer), cookie, stringhe di query URL e input dati strutturati (JSON, XML, SOAP).
Direct Output Injection
Un attaccante inietta un separatore di comando seguito da un comando di output noto:
Se la risposta contiene il nome utente del processo in esecuzione, l'injection è confermata e l'attaccante può procedere con comandi più dannosi.
Blind Injection tramite Ritardi Temporali
Quando l'output del comando non appare nella risposta HTTP, gli attaccanti iniettano comandi di ritardo temporale e misurano la latenza della risposta. Iniettando & sleep 10 & su un target Linux si ottiene un ritardo misurabile se il comando viene eseguito.
Exfiltration Out-of-Band (OAST)
Gli attaccanti iniettano comandi che attivano callback DNS verso infrastrutture sotto il loro controllo:
Una query DNS che arriva al server dell'attaccante conferma l'esecuzione del codice, anche quando non è osservabile alcun output o differenza di tempo. PortSwigger OAST osserva che Burp Collaborator ha permesso di trovare vulnerabilità di OS command injection blind prima non identificabili con altri mezzi.
Chaining di Bypass di Autenticazione
CVE-2024-21887 (Ivanti Connect Secure) richiede accesso amministrativo autenticato, ma gli attaccanti lo hanno combinato con CVE-2023-46805 (bypass autenticazione) per eliminare completamente tale requisito. Secondo CISA, attori statali cinesi hanno utilizzato sistematicamente questo pattern di chaining su Ivanti, Cisco e altri appliance di rete.
Bypass tramite Argument Injection
Quando i difensori filtrano i separatori di comando (;, |, &&), gli attaccanti passano all' argument injection (CWE-88). Iniettando flag o opzioni con prefisso - o --, manipolano il comportamento di un programma già invocato senza introdurre nuovi comandi. OWASP documenta che escapeshellcmd() di PHP consente questa via di attacco anche quando i separatori di comando sono bloccati. L'ampiezza di queste tecniche significa che l'impatto non è limitato a un solo tipo di applicazione o settore.
Chi è colpito dall'OS Command Injection?
L'OS command injection colpisce qualsiasi sistema in cui il codice applicativo passa input utente a una shell OS. Alcuni tipi di applicazioni e settori presentano un rischio sproporzionato in base ai dati di exploitation confermata.
Tipi di Applicazioni più Vulnerabili
- Network Appliance e Dispositivi SSL-VPN: Questa categoria produce la più alta concentrazione di entry CWE-78 confermate come sfruttate nel catalogo CISA KEV. CVE-2023-44221 (SonicWall SMA100), CVE-2024-8190 (Ivanti Cloud Services Appliance), CVE-2024-40891 (Zyxel CPE) e CVE-2023-28771 (Zyxel Firewall/VPN) coinvolgono tutte interfacce di gestione che passano input direttamente all'esecuzione di comandi OS.
- IoT e Firmware Embedded: I dispositivi NAS QNAP (CVE-2023-47218), router TP-Link (CVE-2023-1389) e router Wavlink presentano tutti vulnerabilità CWE-78 confermate. La variante Mirai ha sistematicamente sfruttato CVE di OS command injection su più piattaforme router e firmware IoT per il reclutamento botnet.
- Applicazioni Web con System Call lato Server: Lo scenario canonico dell' OWASP Top 10 descrive un'applicazione Java che costruisce un comando OS tramite Runtime.getRuntime().exec() con concatenazione di stringhe.
- Interfacce di Gestione Enterprise: CISA advisory documenta exploitation di interfacce di gestione Ivanti Cloud Service Application tramite chained command injection.
Settori a Maggior Rischio
- Infrastrutture Critiche e Telecomunicazioni: CISA advisory documenta exploitation da parte di attori statali cinesi di command injection in appliance di rete rivolti a infrastrutture telecom e router.
- Pubblica Amministrazione: Le entry CISA KEV dichiarano esplicitamente che "pongono rischi significativi per l'enterprise federale". Le agenzie federali affrontano scadenze KEV per le CVE di command injection elencate in KEV.
I dati di exploitation in queste categorie mostrano come l'OS command injection si traduca da un difetto a livello di codice a un danno su scala organizzativa.
Esempi Reali di OS Command Injection
Incidenti confermati di OS command injection spaziano dalla mass exploitation di software open-source a campagne mirate di stati-nazione contro infrastrutture di rete.
Shellshock (CVE-2014-6271), 2014
GNU Bash fino alla versione 4.3 processava stringhe finali dopo definizioni di funzione nelle variabili d'ambiente, consentendo a valori craftati di iniettare comandi shell. Questa vulnerabilità era sfruttabile tramite script CGI, client DHCP e configurazioni SSH ForceCommand, dimostrando la superficie di attacco su scala Internet di un singolo difetto di OS command injection.
Violazione Equifax (CVE-2017-5638), 2017
Apache Struts 2 consentiva agli attaccanti di iniettare espressioni OGNL tramite header Content-Type, abilitando l'esecuzione di codice arbitrario. Secondo il rapporto della Camera, Apache ha rilasciato una patch il 7 marzo 2017. Tre giorni dopo, il 10 marzo, gli attaccanti hanno sfruttato per la prima volta la vulnerabilità sulla rete Equifax. La violazione risultante ha portato a un accordo da 700 milioni di dollari e alle dimissioni dei dirigenti.
Log4Shell (CVE-2021-44228), 2021
La funzionalità JNDI message lookup di Apache Log4j2 ha consentito l'esecuzione remota di codice non autenticata tramite messaggi di log craftati, CVSS 10.0. Secondo CISA advisory, attori APT hanno sfruttato Log4Shell su server VMware Horizon non patchati, ottenuto lateral movement ed esfiltrato dati sensibili. LockBit affiliates e gruppi nordcoreani hanno entrambi sfruttato questa vulnerabilità.
Velvet Ant / CVE-2024-20399, 2024
Sygnia report ha descritto un gruppo di spionaggio di matrice cinese che ha sfruttato una vulnerabilità di command injection CLI su Cisco NX-OS. Nonostante il punteggio CVSS relativamente basso, il gruppo ha eseguito codice malevolo sul sistema operativo Linux sottostante degli switch Nexus. CISA lo ha aggiunto al catalogo KEV, evidenziando che il rischio operativo spesso supera quanto riflesso dal CVSS.
Sfruttamento Firewall Zyxel (CVE-2023-28771), 2023
La gestione impropria dei messaggi di errore nel firmware dei firewall Zyxel ha consentito l'esecuzione remota non autenticata di comandi OS, CVSS 9.8. Cybersecurity Dive ha riportato targeting attivo in un solo giorno senza attività precedente.
Questi incidenti fanno parte di un pattern più ampio che risale ai primi giorni delle applicazioni web.
Timeline e Storia dell'OS Command Injection
- 1988-1998: L'era CGI. I primi web server invocavano script shell con input utente non sanificato, creando le prime superfici di attacco OS command injection. Il dataset DARPA Intrusion Detection Evaluation presso MIT Lincoln Laboratory ha catalogato attacchi CGI-based e exploitation di sendmail di questo periodo.
- 1999: Classificazione formale. CVE-1999-0067 ha documentato una delle prime entry formali di command injection: un programma CGI che non neutralizzava il metacarattere pipe (|) quando invocava un programma rubrica. MITRE ha codificato la vulnerabilità come CWE-78.
- 2014: Shellshock. CVE-2014-6271 è diventata la prima vulnerabilità di OS command injection a raggiungere la mass exploitation su scala Internet.
- 2017: Conseguenze Enterprise. La violazione Equifax tramite CVE-2017-5638 ha dimostrato che primitive di esecuzione comandi incorporate nei framework applicativi hanno conseguenze equivalenti all'OS command injection diretta su scala enterprise.
- 2021: Consolidamento delle categorie Injection. OWASP Top 10:2021 ha consolidato tutti i tipi di injection sotto la categoria A03 Injection. Log4Shell (CVE-2021-44228) ha esteso il pattern a una libreria di logging ubiqua.
- 2023-2026: Targeting di Network Appliance. La superficie di attacco si è spostata decisamente verso appliance di rete perimetrali. Secondo CISA, attori statali cinesi hanno sfruttato sistematicamente command injection nei dispositivi di rete dal 2021 al 2025. L'OWASP Top 10:2025 ha esplicitamente aggiunto CWE-88 (Argument Injection) come weakness mappata.
Con l'exploitation ancora in corso, l'identificazione precoce rimane una priorità lungo tutto il ciclo di vita applicativo.
Come rilevare l'OS Command Injection
Individuare l'OS command injection richiede un approccio stratificato che combina test pre-deployment con visibilità runtime.
Static Application Security Testing (SAST)
Secondo l' OWASP Top 10, la revisione del codice sorgente è il metodo migliore per trovare vulnerabilità di injection. Gli strumenti SAST segnalano chiamate a system(), exec(), popen(), shell_exec() e altre API pericolose quando ricevono input controllato dall'utente. I pattern chiave da segnalare includono concatenazione di stringhe che alimenta funzioni di esecuzione comandi OS e l'uso di escapeshellcmd() in PHP invece del più sicuro escapeshellarg().
Dovresti eseguire SAST nella pipeline CI/CD per intercettare difetti di injection prima del deployment. La sua principale limitazione è che non può trovare vulnerabilità che si manifestano solo a runtime.
Dynamic Application Security Testing (DAST)
DAST valida ciò che è effettivamente sfruttabile testando l'applicazione in esecuzione. Web Security Academy documenta tre tecniche DAST:
- Direct output injection: Inietta
& echo uniquestring &e verifica se la stringa appare nella risposta. - Blind time-based injection: Inietta
& sleep 10 &e misura il ritardo della risposta. - Out-of-band (OAST) injection: Inietta comandi di callback DNS e monitora richieste esterne verso un server controllato. Questa è la tecnica più affidabile per l'injection blind.
Visibilità Comportamentale a Livello di Processo
A livello host, NIST SP 800-53 (Information System Monitoring) stabilisce il framework per l'identificazione di anomalie comportamentali. Il SOC dovrebbe cercare questi indicatori specifici:
- Processi web server (
apache, nginx, tomcat) che generano processi shell (bash, sh, cmd.exe, powershell) - Chiamate
execve()osystem()inattese originate da contesti di processo applicativo web - Connessioni di rete in uscita avviate da processi applicativi verso IP esterni
Regole Web Application Firewall (WAF)
L'OWASP ModSecurity Core Rule Set segnala metacaratteri shell (;, |, &, backticks, $()) e comandi OS comuni (whoami, cat /etc/passwd, nslookup) negli input HTTP. Le regole WAF possono essere bypassate tramite encoding e variazioni di case, quindi dovrebbero essere considerate come una fonte di segnale, non un controllo completo.
Confronto dei Metodi
| Metodo | Tempistica | Rileva Injection Blind | Limitazione Chiave |
| SAST | Pre-deployment | N/A (statico) | Non trova problemi solo runtime |
| DAST | Pre/post-deployment | Sì (tramite OAST) | Può mancare flussi complessi |
| Visibilità Comportamentale | Produzione | Sì | Richiede tuning baseline |
| WAF | Produzione | Parziale | Bypassabile, non risolve la causa radice |
Trovare le vulnerabilità da solo non è sufficiente. La prevenzione richiede l'eliminazione della causa radice nel codice e nell'architettura.
Come prevenire l'OS Command Injection
La prevenzione si concentra sull'eliminazione della causa radice: invocazione diretta della shell OS con input controllato dall'utente. Dove le chiamate shell non possono essere rimosse, controlli stratificati riducono la superficie di attacco.
Difesa Primaria: Evitare Comandi OS del tutto
Secondo PortSwigger, la prevenzione più forte è non chiamare mai comandi OS dal codice applicativo. Nella quasi totalità dei casi, è possibile implementare la funzionalità richiesta usando API native della piattaforma più sicure. Se serve inviare email, usa una libreria SMTP. Se serve la risoluzione DNS, usa una libreria DNS. Elimina l'intermediario shell.
Usa API di Comando Parametrizzate
Quando l'esecuzione di comandi OS è inevitabile, usa meccanismi strutturati che impongano la separazione tra dati e comando. In Python, ciò significa usare la forma lista di subprocess.run():
La forma basata su lista impedisce alla shell di interpretare metacaratteri in qualsiasi argomento.
Validazione Input tramite Allowlisting
La cheat sheet OWASP raccomanda la validazione basata su allowlist come secondo livello di difesa. Definisci caratteri permessi e lunghezza massima della stringa usando espressioni regolari rigorose. OWASP fornisce l'esempio ^[a-z0-9]{3,10}$, escludendo tutti i metacaratteri e gli spazi.
PortSwigger avverte esplicitamente: non tentare mai di sanificare l'input tramite escaping dei metacaratteri shell. Questo approccio è soggetto a errori e vulnerabile a bypass da parte di attaccanti esperti. L'allowlisting è sempre preferibile.
Applicare il Minimo Privilegio (NIST AC-6)
NIST SP 800-53 impone l'applicazione del principio del minimo privilegio. Per la difesa dal command injection:
- Esegui i processi applicativi web come account di servizio dedicati e non privilegiati
- Limita i permessi dell'account di servizio solo ai percorsi filesystem necessari
- Nega l'accesso shell
(/bin/sh, /bin/bash)agli account di servizio applicativi web - Applica profili
seccompsu Linux per limitare le system call disponibili
Implementare Sandboxing e Containerizzazione
L'isolamento tramite container con filesystem root in sola lettura, namespace e cgroup Linux, e profili di accesso obbligatorio (AppArmor o SELinux) riducono il raggio d'azione se si verifica un'injection. Questi controlli sono in linea con i principi NIST CM-7 di least functionality.
Controlli Specifici per PHP
Se lavori in PHP e devi invocare comandi shell, usa escapeshellarg() invece di escapeshellcmd(), poiché limita l'input a un singolo parametro e previene l'argument injection.
Questi controlli di codifica e architetturali costituiscono la base, ma gli strumenti forniscono la visibilità necessaria per applicarli su larga scala.
Strumenti per il Rilevamento e la Prevenzione dell'OS Command Injection
Una difesa efficace richiede strumenti che coprano test di sicurezza applicativa, protezione runtime e visibilità endpoint. Un avviso congiunto CISA e FBI mirato all'OS command injection raccomanda specificamente funzioni di libreria integrate che separano i comandi dagli argomenti, la parametrizzazione degli input e la validazione di tutti gli input forniti dall'utente.
Strumenti di Application Security Testing
- Strumenti SAST analizzano il codice sorgente alla ricerca di chiamate API pericolose che ricevono input utente. Puoi integrarli nella pipeline CI/CD per intercettare difetti di injection prima del deployment.
- Strumenti DAST come Burp Suite testano le applicazioni in esecuzione per punti di injection sfruttabili. Le capacità OAST di Burp Suite sono particolarmente efficaci per trovare command injection blind che non producono output visibile.
Protezione Runtime e di Rete
- Soluzioni WAF che utilizzano l'OWASP ModSecurity Core Rule Set forniscono filtraggio a livello di rete di metacaratteri shell e payload di injection comuni. Questi agiscono come livello di difesa in profondità ma non devono sostituire la correzione della causa radice.
- Soluzioni RASP strumentano le applicazioni a runtime e possono bloccare tentativi di injection con pieno contesto applicativo, fungendo da controllo compensativo per applicazioni legacy difficili da correggere.
Visibilità Endpoint e Comportamentale
Le piattaforme di sicurezza endpoint che monitorano la creazione di processi, le relazioni padre-figlio e gli argomenti della riga di comando sono fondamentali per individuare attività post-exploitation. Quando un processo web server genera una shell inattesa, l'analisi comportamentale a livello kernel diventa l'ultima linea di difesa.
Liberate la cybersicurezza alimentata dall'intelligenza artificiale
Elevate la vostra posizione di sicurezza con il rilevamento in tempo reale, la risposta automatica e la visibilità totale dell'intero ambiente digitale.
Richiedi una demoVulnerabilità Correlate
L'OS command injection appartiene a una famiglia di vulnerabilità di injection che condividono una causa radice comune: il mancato isolamento tra dati utente e istruzioni eseguibili. Diverse classi di vulnerabilità correlate possono concatenarsi o sovrapporsi a CWE-78.
- SQL Injection (CWE-89): Prende di mira i motori database SQL invece della shell OS. L'SQL injection può concatenarsi all'OS command injection tramite funzionalità database come
xp_cmdshell. - Code Injection (CWE-94): Prende di mira il runtime del linguaggio applicativo (PHP
eval(), Pythonexec()). Il code injection consente all'attaccante di aggiungere codice proprio che viene poi eseguito dall'applicazione, e può scalare a OS command injection se il codice iniettato chiamasystem()oexec(). - Argument Injection (CWE-88): Una variante figlia di CWE-78. Invece di iniettare nuovi comandi tramite separatori, gli attaccanti manipolano gli argomenti di un programma già invocato usando caratteri flag (-, --). Questo attacco riesce anche quando il filtering dei separatori di comando è attivo.
- Server-Side Template Injection (CWE-1336): Prende di mira i motori di template (Jinja2, FreeMarker). L'SSTI spesso scala a OS command injection perché i motori di template hanno spesso accesso al runtime del linguaggio sottostante.
- Expression Language Injection (CWE-917): Prende di mira i parser di expression language nei framework web (OGNL, Spring SpEL). Log4Shell (CVE-2021-44228) è l'esempio più noto, spesso concatenato all'esecuzione di comandi OS.
| Vulnerabilità | CWE | Interprete Target | Percorso Diretto a Esecuzione OS |
| OS Command Injection | CWE-78 | Shell OS | Diretto |
| SQL Injection | CWE-89 | Motore SQL | Indiretto (tramite xp_cmdshell) |
| Code Injection | CWE-94 | Runtime applicativo | Indiretto (tramite system call) |
| Argument Injection | CWE-88 | Parser argomenti shell OS | Diretto (manipola comando invocato) |
| SSTI | CWE-1336 | Motore template | Spesso scala a comandi OS |
| EL Injection | CWE-917 | Parser expression language | Spesso scala a comandi OSs |
La tabella sopra mostra che diverse classi di vulnerabilità forniscono un percorso diretto o indiretto all'esecuzione a livello OS, rendendo essenziale una difesa in profondità su tutti i tipi di injection.
CVE Correlate
| ID CVE | Descrizione | Gravità | Prodotto Interessato | Anno |
| Command injection nell'endpoint API git diff bypassa i controlli di esecuzione agent | Critica | OpenHands AI Platform | 2026 | |
| OS command injection nella funzionalità diagnostica WAN tramite parametro curl | Critica | Tenda G300-F Router | 2026 | |
| OS command injection nei moduli VPN; attaccante autenticato adiacente | Alta | TP-Link Archer BE230 | 2026 | |
| OS command injection non autenticata in dispositivi di comunicazione ICS | Critica | Zenitel Devices | 2025 | |
| OS command injection non autenticata in piattaforma di gestione EDR; sfruttata attivamente | Critica | Sangfor EDR | 2025 | |
| Command injection post-autenticazione nella configurazione CLI DDNS | Alta | Zyxel ATP/USG FLEX Firewalls | 2025 | |
| Command injection tramite input non sanificato passato a exec() in image.php | Critica | ZoneMinder v1.36.34 | 2025 | |
| RCE non autenticata tramite command injection in endpoint API middleware | Critica | Hoverfly API Simulator | 2025 | |
| CLI command injection su switch Nexus; sfruttata da campagna Velvet Ant | Media | Cisco NX-OS | 2024 | |
| OS command injection non autenticata nel componente Task Manager | Critica | Synology BeePhotos/Photos | 2024 | |
| Command injection non autenticata in endpoint remote_help-cgi | Critica | Zyxel NAS326/NAS542 | 2024 | |
| Command injection post-autenticazione tramite HTTP POST in programma CGI; CISA KEV | Alta | Zyxel VMG1312-B10A | 2024 | |
| Command injection tramite richiesta CGI che abilita esecuzione codice a livello root | Critica | Webmin | 2024 | |
| Command injection a livello root tramite web UI; sfruttata attivamente; CISA KEV | Critica | Cisco IOS XE | 2023 | |
| Command injection tramite nomi file .tar malevoli; sfruttata attivamente; CISA KEV | Critica | Barracuda ESG | 2023 | |
| OS command injection pre-autenticazione tramite richieste HTTP; CISA KEV | Critica | Zyxel NAS326/540/542 | 2023 | |
| Command injection non autenticata nella funzione show_zysync_server_contents | Critica | Zyxel NAS326/NAS542 | 2023 | |
| OS command injection tramite metacaratteri shell in nomi utente o host | Media | OpenBSD OpenSSH | 2023 | |
| Injection di metacaratteri shell non autenticata nell'interfaccia di login; CISA KEV | Critica | Control Web Panel 7 | 2022 | |
| Command injection tramite nomi file certificato malevoli nello script c_rehash | Critica | OpenSSL | 2022 | |
| OS command injection non autenticata tramite interfaccia di gestione web | Critica | Zyxel NWA1100-NH | 2021 | |
| Command injection pre-autenticazione nel firmware router; CISA KEV | Critica | DrayTek Vigor Routers | 2020 | |
| Command injection pre-autenticazione tramite weblogin.cgi; escalation root; CISA KEV | Critica | Zyxel NAS326 | 2020 | |
| Command injection tramite parametro deviceName in goform/setUsbUnload; CISA KEV | Critica | Tenda AC15 Router | 2020 |
Conclusione
L'OS command injection offre agli attaccanti esecuzione diretta a livello OS tramite applicazioni che passano input non sicuro agli interpreti shell. Riduci l'esposizione eliminando dove possibile le chiamate a comandi OS, usando API parametrizzate quando necessario e applicando la validazione tramite allowlist.
Se la prevenzione fallisce, la visibilità comportamentale sull'endpoint aiuta a individuare rapidamente spawning di shell, connessioni in uscita e altri segnali di exploitation.
Domande frequenti
L'OS command injection (CWE-78) è una vulnerabilità in cui un'applicazione costruisce comandi del sistema operativo utilizzando input esterno non sanificato. Gli attaccanti iniettano metacaratteri della shell (;, |, &&) per aggiungere comandi dannosi che la shell del sistema operativo esegue con i privilegi dell'applicazione.
La causa principale è la mancata separazione tra i dati dell'utente e la sintassi dei comandi prima di passare l'input a un interprete della shell.
Sì. L'OS command injection è classificato nella categoria Injection sia in OWASP Top 10:2021 che in OWASP Top 10:2025. Sia CWE-77 che CWE-78 sono esplicitamente inclusi.
L'edizione 2025 ha inoltre aggiunto CWE-88 (Argument Injection) come debolezza mappata.
Sì. La maggior parte delle vulnerabilità CWE-78 confermate nel catalogo CISA KEV non richiede autenticazione ed è sfruttabile da remoto. CVE-2014-6271 (Shellshock), CVE-2023-28771 (Zyxel) e CVE-2024-3400 consentono tutte lo sfruttamento remoto senza autenticazione.
Le appliance di rete, inclusi firewall, concentratori VPN e switch aziendali, producono la più alta concentrazione di voci CWE-78 confermate come sfruttate. Il firmware IoT e embedded, inclusi dispositivi NAS e router, è sistematicamente preso di mira per il reclutamento in botnet.
Le applicazioni web che richiamano comandi di sistema lato server e le interfacce di gestione aziendale presentano anch'esse un rischio elevato.
Gli attaccanti testano campi di input, header HTTP, cookie e parametri URL iniettando metacaratteri della shell seguiti da comandi diagnostici. Per l'injection cieca, utilizzano ritardi temporali (sleep 10) o callback DNS verso server controllati dall'attaccante.
Scanner e strumenti di fuzzing testano sistematicamente tutti i vettori di input.
Indicatori chiave includono processi del web server (apache, nginx, tomcat) che avviano processi shell inaspettati (bash, sh, cmd.exe). Altri segnali sono connessioni di rete in uscita da processi applicativi verso IP sconosciuti e chiamate insolite a execve() o system() da contesti di processo dell'applicazione web.
L'OS command injection è una classe di vulnerabilità ad alta gravità perché offre agli attaccanti accesso diretto a livello di sistema operativo, consentendo l'esecuzione di qualsiasi comando supportato dal sistema operativo host.
CWE-78 è tra le principali categorie di debolezza software MITRE e i CVE confermati riportano regolarmente punteggi CVSS pari o superiori a 9.0.
Sì. Il SANS, nel suo report su CVE-2024-40891, descrive esplicitamente "compromissione completa del sistema, esfiltrazione di dati o infiltrazione nella rete." Quando l'applicazione compromessa viene eseguita con privilegi elevati, gli attaccanti ottengono un accesso equivalente a livello di sistema operativo.
Le conseguenze confermate includono la distribuzione di ransomware, movimento laterale e installazione persistente di backdoor.
Gli strumenti SAST segnalano in modo affidabile chiamate API pericolose nel codice sorgente ma non rilevano vulnerabilità presenti solo a runtime. Gli strumenti DAST individuano punti di injection sfruttabili, soprattutto utilizzando tecniche OAST per injection cieca.
Le regole WAF rilevano pattern noti ma possono essere aggirate tramite codifica. La visibilità comportamentale a livello di processo offre l'identificazione runtime più affidabile. Nessuno strumento rileva ogni variante, quindi è necessaria una copertura stratificata.
Le infrastrutture critiche e le telecomunicazioni affrontano il rischio confermato più elevato. I documenti di advisory CISA segnalano lo sfruttamento da parte di attori statali cinesi contro infrastrutture di telecomunicazioni e router.
Le agenzie governative federali sono soggette a tempistiche obbligatorie di remediation KEV. Qualsiasi settore che utilizza appliance di rete esposte a Internet o firmware embedded è un potenziale bersaglio.
