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 continuo targeting di appliance di rete documentato in un avviso CISA. CWE-78 si colloca tra i MITRE Top 25, insieme a out-of-bounds write, cross-site scripting e SQL injection.
Nell'OWASP Top 10, la categoria Injection più ampia mappa sia CWE-77 che CWE-78. Comprendere come funziona la vulnerabilità a livello di shell è il primo passo per fermarla.
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 di dominio. La shell esegue sia nslookup example.com che cat /etc/passwd, restituendo il file delle password del server.
Sottotipo 2: Indiretto (Full Command Control)
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 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 lo rendono possibile variano in base alla piattaforma.
Operatori e metacaratteri di injection comuni
L'OS command injection si basa su metacaratteri shell che alterano il modo in cui il sistema operativo interpreta una stringa di comando. Gli operatori disponibili per un attaccante dipendono dalla piattaforma target.
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 insufficiente dell'input
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
Calling system(), exec(), shell_exec(), or os.system() invoca la shell OS come intermediario. Ogni invocazione della shell crea una superficie di injection. La cheat sheet OWASP identifica le 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 filtraggio 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 i percorsi assoluti degli 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 flaw 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 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 |
| Remote Code Execution | 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 |
| Botnet Recruitment | Mirai variant |
| Ransomware Delivery | 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 vulnerability chaining.
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 di 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 metodi.
Chaining di bypass 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 prefissate da - 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.
Tipologie 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 a livello OS.
- IoT e firmware embedded: I dispositivi NAS QNAP (CVE-2023-47218), i router TP-Link (CVE-2023-1389) e i 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 di botnet.
- Applicazioni web con chiamate di sistema 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 l'exploitation delle interfacce di gestione Ivanti Cloud Service Application tramite chained command injection.
Settori a rischio più elevato
- Infrastrutture critiche e telecomunicazioni: CISA advisory documenta l'exploitation da parte di attori statali cinesi di command injection in appliance di rete rivolte 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 flaw a livello di codice a un danno su scala organizzativa.
Esempi reali di OS Command Injection
Incidenti confermati di OS command injection spaziano dalla massiccia 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 flaw 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 su 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 exploitation di massa 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 della categoria Injection. L'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 i network appliance di perimetro. 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 flaw di injection prima del deployment. Il suo limite principale è 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 la blind injection.
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 blind injection | Limite principale |
| 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 | Parzialmente | Bypassabile, non risolve la causa radice |
Individuare le vulnerabilità da solo non basta. 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 del tutto i comandi OS
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 la shell come intermediario.
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 al bypass da parte di attaccanti esperti. L'allowlisting è sempre preferibile.
Applica il principio del 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
Implementa sandboxing e containerizzazione
L'isolamento tramite container con filesystem root in sola lettura, namespace e cgroup Linux, e profili mandatory access control (AppArmor o SELinux) riducono il blast radius in caso di 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 application security testing, protezione runtime e visibilità endpoint. Un alert congiunto CISA e FBI rivolto specificamente all'OS command injection raccomanda 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 flaw 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 layer defense-in-depth 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
Piattaforme di endpoint security 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: la mancata separazione 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 di 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 stesso (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 filtraggio dei separatori di comando è in atto.
- 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 verso 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 verso l'esecuzione a livello OS, rendendo essenziale una difesa stratificata su tutti i tipi di injection.
CVE correlate
| ID CVE | Descrizione | Gravità | Prodotto interessato | Anno |
| Command injection nell'endpoint API git diff che 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 dalla 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 a livello 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.
Anche le applicazioni web che invocano comandi di sistema lato server e le interfacce di gestione aziendale presentano un rischio elevato.
Gli attaccanti testano i campi di input, gli header HTTP, i cookie e i 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 generano processi shell inattesi (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 di applicazioni 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 debolezze 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 una "compromissione completa del sistema, esfiltrazione di dati o infiltrazione della 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 le 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 encoding. 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 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.
