¿Qué es la inyección de comandos del sistema operativo?
La inyección de comandos del sistema operativo es una vulnerabilidad que permite a los atacantes ejecutar comandos arbitrarios del sistema operativo en un servidor a través de una aplicación vulnerable. Clasificada como CWE-78 por MITRE, ocurre cuando una aplicación construye comandos del sistema operativo utilizando entradas externas sin neutralizar adecuadamente los caracteres especiales que pueden alterar el comando previsto. El resultado es un acceso directo y no autorizado al sistema operativo subyacente.
Esta clase de vulnerabilidad se ha relacionado con ciberataques importantes, desde la explotación masiva de Shellshock en 2014 hasta la focalización continua de dispositivos de red documentada en un aviso de CISA. CWE-78 se encuentra entre los 25 principales de MITRE, situándose junto a escritura fuera de límites, cross-site scripting y SQL injection.
En el OWASP Top 10, la categoría más amplia de Inyección abarca tanto CWE-77 como CWE-78. Comprender cómo funciona la vulnerabilidad a nivel de shell es el primer paso para detenerla.
¿Cómo funciona la inyección de comandos del sistema operativo?
La inyección de comandos del sistema operativo explota una falla fundamental: una aplicación pasa la entrada controlada por el usuario directamente a un comando de shell del sistema operativo sin separar los datos de las instrucciones de control.
MITRE identifica dos subtipos de inyección de comandos del sistema operativo.
Subtipo 1: Directa (inyección de separador de comandos)
La aplicación pretende ejecutar un solo programa fijo, utilizando la entrada externa solo como argumentos. Los atacantes inyectan separadores de comandos (;, |, &&, || o saltos de línea) para agregar comandos adicionales.
Considere una aplicación web que realiza búsquedas DNS:
Un atacante suministra example.com; cat /etc/passwd como parámetro de dominio. El shell ejecuta tanto nslookup example.com como cat /etc/passwd, devolviendo el archivo de contraseñas del servidor.
Subtipo 2: Indirecta (control total del comando)
La aplicación acepta una entrada que determina completamente qué programa ejecutar. El atacante controla el comando completo, no solo sus argumentos:
Si un atacante controla la propiedad SCRIPTNAME, puede apuntar a cualquier ejecutable en el sistema.
Flujo del ataque
Un ataque típico de inyección de comandos del sistema operativo sigue esta secuencia:
- El atacante identifica un campo de entrada, como un parámetro de formulario, encabezado HTTP, cookie o cadena de consulta URL, que alimenta un comando del lado del servidor.
- El atacante inyecta metacaracteres de shell combinados con un comando malicioso en esa entrada.
- La aplicación pasa la entrada no saneada al shell del sistema operativo.
- El shell interpreta los metacaracteres y ejecuta el comando inyectado con los mismos privilegios que el proceso de la aplicación. Si la aplicación se ejecuta como root, el atacante obtiene esos mismos privilegios.
Cada uno de estos pasos depende de que el shell interprete caracteres específicos como instrucciones de control. Los operadores que hacen esto posible varían según la plataforma.
Operadores y metacaracteres comunes de inyección
La inyección de comandos del sistema operativo depende de metacaracteres de shell que alteran cómo el sistema operativo interpreta una cadena de comandos. Los operadores disponibles para un atacante dependen de la plataforma objetivo.
Separadores de comandos y ejecución en línea
| Operador | Función | Plataforma |
| ; | Ejecuta comandos secuencialmente | Unix |
| & | Ejecuta el segundo comando en segundo plano | Unix y Windows |
| && | Ejecuta el segundo comando solo si el primero tiene éxito | Unix y Windows |
| || | Ejecuta el segundo comando solo si el primero falla | Unix y Windows |
| | | Redirige la salida del primer comando al segundo | Unix y Windows |
| ` (backticks) | Ejecución en línea; la salida reemplaza la expresión | Unix |
| $() | Ejecución en línea; funcionalmente equivalente a backticks | Unix |
| 0x0a (salto de línea) | Inicia un nuevo comando en algunos shells | Unix |
Cuando la entrada del usuario se encuentra dentro de una cadena entre comillas en el comando original, el atacante debe primero cerrar la comilla (" o ') antes de que cualquier separador surta efecto. Técnicas de codificación como codificación URL, doble codificación y normalización Unicode también pueden evadir filtros que buscan estos caracteres en su forma literal. Estos operadores llegan al shell debido a patrones de codificación específicos que no mantienen separados los datos del usuario de la sintaxis del comando.
Causas de la inyección de comandos del sistema operativo
La inyección de comandos del sistema operativo se origina en prácticas de codificación que permiten que la entrada del usuario llegue a un shell del sistema sin controles adecuados. Cinco causas raíz explican la mayoría de las vulnerabilidades.
Validación insuficiente de entradas
Esta es la causa más directa. Según la guía de OWASP, los ataques de inyección de comandos son posibles cuando una aplicación pasa datos no seguros proporcionados por el usuario, como formularios, cookies y encabezados HTTP, a un shell del sistema sin saneamiento. Cuando se confía en que los usuarios proporcionarán valores esperados, puede omitirse la validación por completo.
Uso de ejecución de shell en lugar de APIs nativas del lenguaje
Llamar a system(), exec(), shell_exec() u os.system() invoca el shell del sistema operativo como intermediario. Cada invocación de shell crea una superficie de inyección. La hoja de referencia de OWASP identifica APIs peligrosas en los principales lenguajes:
| Lenguaje | APIs peligrosas |
| 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() |
Dependencia de filtrado por lista de denegación
Puede intentar bloquear caracteres peligrosos específicos en lugar de definir lo que está permitido. Este enfoque, clasificado como CWE-184 (lista de denegación incompleta), falla de manera consistente. OWASP documenta explícitamente que escapeshellcmd() de PHP previene la ejecución de comandos adicionales pero aún permite la inyección de argumentos. Los atacantes pueden inyectar flags como --output-document= para lograr escritura de archivos sin usar separadores de comandos.
Manipulación de variables de entorno
Cuando las aplicaciones no especifican rutas absolutas para los ejecutables y no limpian las variables de entorno, los atacantes pueden redirigir $PATH para apuntar a binarios maliciosos. Si la aplicación se ejecuta con privilegios setuid root, el binario del atacante se ejecuta con acceso root.
Violación del principio de mínimo privilegio
Las aplicaciones que se ejecutan con privilegios elevados amplifican cada falla de inyección. Una inyección de comandos contra una aplicación que se ejecuta como www-data limita al atacante a los permisos de ese usuario. La misma inyección contra un proceso a nivel root otorga control total del sistema. Cuando cualquiera de estas causas no se aborda, el impacto resultante se extiende mucho más allá de la aplicación vulnerable en sí.
Impacto y riesgo de la inyección de comandos del sistema operativo
La inyección de comandos del sistema operativo obtiene consistentemente las puntuaciones más altas en los sistemas de clasificación de vulnerabilidades. El OWASP Top 10:2021 identifica la inyección como una categoría de riesgo importante y persistente. El impacto funcional es directo: un atacante obtiene la capacidad de ejecutar comandos arbitrarios en su servidor con los mismos privilegios que el proceso de la aplicación comprometida.
Gravedad por categoría de impacto
| Impacto | Evidencia |
| Ejecución remota de código | CVE-2024-3400 |
| Compromiso completo del sistema | Informe SANS: "compromiso completo del sistema, exfiltración de datos o infiltración de red" |
| Movimiento lateral | Aviso de CISA: inyección de comandos del sistema operativo combinada con recorrido de rutas que permite intrusión en múltiples etapas |
| Reclutamiento de botnets | Variante Mirai |
| Entrega de ransomware | Aviso de CISA; Aviso de CISA |
Las puntuaciones CVSS no cuentan toda la historia
CVE-2024-20399 (Cisco NX-OS) tiene una puntuación CVSS relativamente modesta y requiere acceso local y privilegios administrativos. Sin embargo, CISA lo añadió al catálogo de Vulnerabilidades Conocidas Explotadas tras confirmar su explotación por la campaña Velvet Ant vinculada a China.
Este caso ilustra que las puntuaciones CVSS por sí solas no reflejan el riesgo operativo. La pertenencia al catálogo KEV, la explotación por estados-nación y la posición de red del dispositivo son factores de riesgo independientes que pueden superar con creces una puntuación base. Comprender las técnicas específicas que utilizan los atacantes ayuda a explicar por qué la explotación confirmada es tan común.
Cómo explotan los atacantes la inyección de comandos del sistema operativo
Los atacantes utilizan una progresión de técnicas para encontrar, confirmar y explotar la inyección de comandos del sistema operativo, comenzando con el descubrimiento y escalando a través de inyección ciega y encadenamiento de vulnerabilidades.
Descubrimiento y enumeración
Los atacantes identifican campos de entrada que interactúan con comandos del sistema en el lado del servidor, probando todos los parámetros, encabezados HTTP (User-Agent, Referer), cookies, cadenas de consulta URL y entradas de datos estructurados (JSON, XML, SOAP).
Inyección directa de salida
Un atacante inyecta un separador de comandos seguido de un comando de salida conocido:
Si la respuesta contiene el nombre de usuario del proceso en ejecución, se confirma la inyección y el atacante puede proceder a comandos más dañinos.
Inyección ciega mediante retardos de tiempo
Cuando la salida del comando no aparece en la respuesta HTTP, los atacantes inyectan comandos de retardo de tiempo y miden la latencia de la respuesta. Inyectar & sleep 10 & en un objetivo Linux produce un retardo medible si el comando se ejecuta.
Exfiltración fuera de banda (OAST)
Los atacantes inyectan comandos que desencadenan callbacks DNS a infraestructura que controlan:
Una consulta DNS que llega al servidor del atacante confirma la ejecución de código, incluso cuando no hay salida ni diferencia de tiempo observable. PortSwigger OAST señala que Burp Collaborator permitió encontrar vulnerabilidades de inyección de comandos del sistema operativo ciegas previamente no identificables por otros medios.
Encadenamiento de bypass de autenticación
CVE-2024-21887 (Ivanti Connect Secure) requiere acceso autenticado de administrador, pero los atacantes lo combinaron con CVE-2023-46805 (bypass de autenticación) para eliminar ese requisito por completo. Según el aviso de CISA, actores patrocinados por el estado chino utilizaron sistemáticamente este patrón de encadenamiento en Ivanti, Cisco y otros dispositivos de red.
Bypass de inyección de argumentos
Cuando los defensores filtran separadores de comandos (;, |, &&), los atacantes recurren a inyección de argumentos (CWE-88). Inyectando flags u opciones precedidas por - o --, manipulan el comportamiento de un programa ya invocado sin introducir nuevos comandos. OWASP documenta que escapeshellcmd() de PHP permite esta vía de ataque incluso cuando los separadores de comandos están bloqueados. La amplitud de estas técnicas significa que el impacto no se limita a un solo tipo de aplicación o industria.
¿Quiénes se ven afectados por la inyección de comandos del sistema operativo?
La inyección de comandos del sistema operativo afecta a cualquier sistema donde el código de la aplicación pasa la entrada del usuario a un shell del sistema operativo. Ciertos tipos de aplicaciones e industrias presentan un riesgo desproporcionado según los datos de explotación confirmada.
Tipos de aplicaciones más vulnerables
- Dispositivos de red y SSL-VPN: Esta categoría produce la mayor concentración de entradas CWE-78 confirmadas como explotadas en el catálogo KEV de CISA. CVE-2023-44221 (SonicWall SMA100), CVE-2024-8190 (Ivanti Cloud Services Appliance), CVE-2024-40891 (Zyxel CPE) y CVE-2023-28771 (Zyxel Firewall/VPN) involucran interfaces de gestión que pasan entradas directamente a la ejecución de comandos a nivel de sistema operativo.
- IoT y firmware embebido: Dispositivos NAS de QNAP (CVE-2023-47218), routers TP-Link (CVE-2023-1389) y routers Wavlink presentan vulnerabilidades CWE-78 confirmadas. La variante Mirai armó sistemáticamente CVEs de inyección de comandos del sistema operativo en múltiples plataformas de routers y firmware IoT para reclutamiento de botnets.
- Aplicaciones web con llamadas a sistemas del lado del servidor: El OWASP Top 10 describe como escenario canónico una aplicación Java que construye un comando del sistema operativo mediante Runtime.getRuntime().exec() con concatenación de cadenas.
- Interfaces de gestión empresarial: Aviso de CISA documenta la explotación de interfaces de gestión de Ivanti Cloud Service Application mediante inyección de comandos encadenada.
Industrias con mayor riesgo
- Infraestructura crítica y telecomunicaciones: Un aviso de CISA documenta la explotación por parte de actores estatales chinos de la inyección de comandos en dispositivos de red dirigidos a infraestructura de telecomunicaciones y routers.
- Gobierno federal: Las entradas KEV de CISA indican explícitamente que "representan riesgos significativos para la empresa federal". Las agencias federales enfrentan plazos KEV para los CVEs de inyección de comandos listados en KEV.
Los datos de explotación en estas categorías muestran cómo la inyección de comandos del sistema operativo se traduce de una falla a nivel de código a un daño a escala organizacional.
Ejemplos reales de inyección de comandos del sistema operativo
Los incidentes confirmados de inyección de comandos del sistema operativo abarcan desde la explotación masiva de software de código abierto hasta campañas dirigidas por estados-nación contra infraestructura de red.
Shellshock (CVE-2014-6271), 2014
GNU Bash hasta la versión 4.3 procesaba cadenas finales después de definiciones de funciones en variables de entorno, permitiendo valores manipulados para inyectar comandos de shell. Esta vulnerabilidad era explotable a través de scripts CGI, clientes DHCP y configuraciones SSH ForceCommand, demostrando la superficie de ataque a escala de Internet de una sola falla de inyección de comandos del sistema operativo.
Brecha de Equifax (CVE-2017-5638), 2017
Apache Struts 2 permitía a los atacantes inyectar expresiones OGNL a través de encabezados Content-Type, habilitando la ejecución arbitraria de código. Según el informe de la Cámara, Apache publicó un parche el 7 de marzo de 2017. Tres días después, el 10 de marzo, los atacantes explotaron por primera vez la vulnerabilidad en la red de Equifax. La brecha resultante llevó a un acuerdo de 700 millones de dólares y la renuncia de ejecutivos.
Log4Shell (CVE-2021-44228), 2021
La función de búsqueda de mensajes JNDI de Apache Log4j2 permitió la ejecución remota de código no autenticada mediante mensajes de registro manipulados, CVSS 10.0. Según un aviso de CISA, actores APT explotaron Log4Shell en servidores VMware Horizon sin parches, lograron movimiento lateral y exfiltraron datos sensibles. Afiliados de LockBit y grupos norcoreanos también explotaron esta vulnerabilidad.
Velvet Ant / CVE-2024-20399, 2024
El informe de Sygnia describió a un grupo de espionaje vinculado a China explotando una vulnerabilidad de inyección de comandos CLI en Cisco NX-OS. A pesar de su puntuación CVSS relativamente baja, el grupo ejecutó código malicioso en el sistema operativo Linux subyacente de los switches Nexus. CISA lo añadió al catálogo KEV, destacando que el riesgo operativo a menudo supera lo que refleja el CVSS.
Explotación de firewall Zyxel (CVE-2023-28771), 2023
El manejo incorrecto de mensajes de error en el firmware de firewall Zyxel permitió la ejecución remota no autenticada de comandos del sistema operativo, CVSS 9.8. Cybersecurity Dive informó de objetivos activos en un solo día sin actividad previa.
Estos incidentes forman parte de un patrón más amplio que se remonta a los primeros días de las aplicaciones web.
Línea de tiempo e historia de la inyección de comandos del sistema operativo
- 1988 a 1998: La era CGI. Los primeros servidores web invocaban scripts de shell con entradas de usuario no saneadas, creando las primeras superficies de ataque de inyección de comandos del sistema operativo. El conjunto de datos DARPA Intrusion Detection Evaluation en MIT Lincoln Laboratory catalogó ataques basados en CGI y explotación de sendmail de este período.
- 1999: Clasificación formal. CVE-1999-0067 documentó una de las primeras entradas formales de inyección de comandos: un programa CGI que no neutralizaba el metacarácter pipe (|) al invocar un programa de agenda telefónica. MITRE codificó la clase de vulnerabilidad como CWE-78.
- 2014: Shellshock. CVE-2014-6271 se convirtió en la primera vulnerabilidad de inyección de comandos del sistema operativo en lograr explotación masiva a escala de Internet.
- 2017: Consecuencias empresariales. La brecha de Equifax mediante CVE-2017-5638 demostró que los mecanismos de ejecución de comandos incrustados en frameworks de aplicaciones tienen consecuencias equivalentes a la inyección directa de comandos del sistema operativo a escala empresarial.
- 2021: Consolidación de la categoría de inyección. OWASP Top 10:2021 consolidó todos los tipos de inyección bajo la categoría A03 Injection. Log4Shell (CVE-2021-44228) extendió el patrón a una biblioteca de registro ubicua.
- 2023 a 2026: Focalización de dispositivos de red. La superficie de ataque se desplazó decisivamente hacia dispositivos perimetrales de red. Según un aviso de CISA, actores estatales chinos explotaron sistemáticamente la inyección de comandos en dispositivos de red entre 2021 y 2025. El OWASP Top 10:2025 añadió explícitamente CWE-88 (inyección de argumentos) como debilidad mapeada.
Con la explotación en curso, la identificación temprana sigue siendo una prioridad en todo el ciclo de vida de la aplicación.
Cómo detectar la inyección de comandos del sistema operativo
Encontrar la inyección de comandos del sistema operativo requiere un enfoque en capas que combine pruebas previas al despliegue con visibilidad en tiempo de ejecución.
Pruebas de seguridad de aplicaciones estáticas (SAST)
Según el OWASP Top 10, la revisión de código fuente es el mejor método para encontrar vulnerabilidades de inyección. Las herramientas SAST marcan llamadas a system(), exec(), popen(), shell_exec() y otras APIs peligrosas cuando reciben entrada controlada por el usuario. Los patrones clave a marcar incluyen la concatenación de cadenas que alimentan funciones de ejecución de comandos del sistema operativo y el uso de escapeshellcmd() en PHP en lugar del más seguro escapeshellarg().
Debe ejecutar SAST en su pipeline CI/CD para detectar fallas de inyección antes del despliegue. Su principal limitación es que no puede encontrar vulnerabilidades que solo se manifiestan en tiempo de ejecución.
Pruebas de seguridad de aplicaciones dinámicas (DAST)
DAST valida lo que realmente es explotable probando la aplicación en ejecución. Web Security Academy documenta tres técnicas DAST:
- Inyección directa de salida: Inyecte
& echo uniquestring &y verifique si la cadena aparece en la respuesta. - Inyección ciega basada en tiempo: Inyecte
& sleep 10 &y mida el retardo de la respuesta. - Inyección fuera de banda (OAST): Inyecte comandos de callback DNS y monitoree solicitudes externas a un servidor controlado. Esta es la técnica más confiable para inyección ciega.
Visibilidad de comportamiento a nivel de proceso
A nivel de host, NIST SP 800-53 (Monitoreo de Sistemas de Información) establece el marco para la identificación de anomalías de comportamiento. Su SOC debe buscar estos indicadores específicos:
- Procesos de servidor web (
apache, nginx, tomcat) que generan procesos de shell (bash, sh, cmd.exe, powershell) - Llamadas inesperadas a
execve()osystem()originadas desde contextos de procesos de aplicaciones web - Conexiones de red salientes iniciadas por procesos de aplicación hacia IPs externas
Reglas de firewall de aplicaciones web (WAF)
El OWASP ModSecurity Core Rule Set marca metacaracteres de shell (;, |, &, backticks, $()) y comandos comunes del sistema operativo (whoami, cat /etc/passwd, nslookup) en entradas HTTP. Las reglas WAF pueden ser evadidas mediante codificación y variación de mayúsculas/minúsculas, por lo que deben considerarse solo una fuente de señal, no un control completo.
Comparación de métodos
| Método | Momento | Detecta inyección ciega | Limitación clave |
| SAST | Previo al despliegue | N/A (estático) | No puede encontrar problemas solo en tiempo de ejecución |
| DAST | Pre/post-despliegue | Sí (vía OAST) | Puede omitir flujos complejos |
| Visibilidad de comportamiento | Producción | Sí | Requiere ajuste de línea base |
| WAF | Producción | Parcialmente | Se puede evadir, no soluciona la causa raíz |
Encontrar vulnerabilidades por sí solo es insuficiente. La prevención requiere eliminar la causa raíz en su código y arquitectura.
Cómo prevenir la inyección de comandos del sistema operativo
La prevención se centra en eliminar la causa raíz: la invocación directa del shell del sistema operativo con entrada controlada por el usuario. Cuando no se pueden eliminar las llamadas al shell, los controles en capas reducen la superficie de ataque.
Defensa principal: evitar completamente los comandos del sistema operativo
Según PortSwigger, la prevención más sólida es nunca invocar comandos del sistema operativo desde el código de la capa de aplicación. En casi todos los casos, puede implementar la funcionalidad requerida utilizando APIs nativas de la plataforma más seguras. Si necesita enviar correo electrónico, use una biblioteca SMTP. Si necesita resolución DNS, use una biblioteca DNS. Elimine el shell como intermediario.
Utilice APIs de comandos parametrizados
Cuando la ejecución de comandos del sistema operativo sea inevitable, utilice mecanismos estructurados que impongan la separación entre datos y comando. En Python, esto significa usar la forma de lista de subprocess.run():
La forma basada en listas evita que el shell interprete metacaracteres en cualquier argumento.
Validación de entradas mediante listas de permitidos
La hoja de referencia de OWASP recomienda la validación basada en listas de permitidos como la segunda capa de defensa. Defina los caracteres permitidos y la longitud máxima de la cadena utilizando expresiones regulares estrictas. OWASP proporciona el ejemplo ^[a-z0-9]{3,10}$, excluyendo todos los metacaracteres y espacios en blanco.
PortSwigger advierte explícitamente: nunca intente sanear la entrada escapando metacaracteres de shell. Este enfoque es propenso a errores y vulnerable a evasión por atacantes experimentados. La lista de permitidos siempre es preferible.
Aplicar el principio de mínimo privilegio (NIST AC-6)
NIST SP 800-53 exige emplear el principio de mínimo privilegio. Para la defensa contra inyección de comandos:
- Ejecute los procesos de aplicaciones web como cuentas de servicio dedicadas y no privilegiadas
- Restrinja los permisos de la cuenta de servicio solo a las rutas de archivos necesarias
- Deniegue el acceso al shell
(/bin/sh, /bin/bash)a las cuentas de servicio de aplicaciones web - Aplique perfiles
seccompen Linux para restringir las llamadas al sistema disponibles
Implemente sandboxing y contenedores
El aislamiento mediante contenedores con sistemas de archivos raíz de solo lectura, namespaces y cgroups de Linux, y perfiles de control de acceso obligatorio (AppArmor o SELinux) reducen el radio de impacto si ocurre una inyección. Estos controles se alinean con los principios de mínima funcionalidad de NIST CM-7.
Controles específicos para PHP
Si trabaja en PHP y debe invocar comandos de shell, utilice escapeshellarg() en lugar de escapeshellcmd(), ya que limita la entrada a un solo parámetro y previene la inyección de argumentos.
Estos controles de codificación y arquitectura forman la base, pero las herramientas proporcionan la visibilidad necesaria para aplicarlos a escala.
Herramientas para la detección y prevención de la inyección de comandos del sistema operativo
Una defensa eficaz requiere herramientas que abarquen pruebas de seguridad de aplicaciones, protección en tiempo de ejecución y visibilidad en el endpoint. Una alerta conjunta de CISA y FBI dirigida a la inyección de comandos del sistema operativo recomienda específicamente funciones de biblioteca integradas que separen los comandos de sus argumentos, la parametrización de entradas y la validación de toda entrada proporcionada por el usuario.
Herramientas de pruebas de seguridad de aplicaciones
- Las herramientas SAST analizan el código fuente en busca de llamadas a APIs peligrosas que reciben entrada del usuario. Puede integrarlas en su pipeline CI/CD para detectar fallas de inyección antes del despliegue.
- Las herramientas DAST como Burp Suite prueban aplicaciones en ejecución en busca de puntos de inyección explotables. Las capacidades OAST de Burp Suite son especialmente eficaces para encontrar inyección de comandos ciega que no produce salida visible.
Protección en tiempo de ejecución y red
- Soluciones WAF que utilizan el OWASP ModSecurity Core Rule Set proporcionan filtrado a nivel de red de metacaracteres de shell y cargas de inyección comunes. Actúan como una capa de defensa en profundidad pero no deben reemplazar la corrección de la causa raíz.
- Las soluciones RASP instrumentan aplicaciones en tiempo de ejecución y pueden bloquear intentos de inyección con contexto completo de la aplicación, sirviendo como control compensatorio para aplicaciones heredadas difíciles de remediar.
Visibilidad en endpoint y comportamiento
Las plataformas de seguridad de endpoint que monitorean la creación de procesos, relaciones padre-hijo y argumentos de línea de comandos son críticas para detectar actividad post-explotación. Cuando un proceso de servidor web genera un shell inesperado, el análisis de comportamiento a nivel de kernel se convierte en su última línea de defensa.
Ciberseguridad impulsada por la IA
Mejore su postura de seguridad con detección en tiempo real, respuesta a velocidad de máquina y visibilidad total de todo su entorno digital.
DemostraciónVulnerabilidades relacionadas
La inyección de comandos del sistema operativo pertenece a una familia de vulnerabilidades de inyección que comparten una causa raíz común: la falta de separación entre los datos del usuario y las instrucciones ejecutables. Varias clases de vulnerabilidad relacionadas pueden encadenarse o superponerse con CWE-78.
- SQL Injection (CWE-89): Apunta a motores de bases de datos SQL en lugar del shell del sistema operativo. La inyección SQL puede encadenarse con la inyección de comandos del sistema operativo mediante funciones de base de datos como
xp_cmdshell. - Inyección de código (CWE-94): Apunta al propio entorno de ejecución del lenguaje de la aplicación (PHP
eval(), Pythonexec()). La inyección de código permite al atacante agregar su propio código que luego es ejecutado por la aplicación, y puede escalar a inyección de comandos del sistema operativo si el código inyectado llama asystem()oexec(). - Inyección de argumentos (CWE-88): Una variante hija de CWE-78. En lugar de inyectar nuevos comandos mediante separadores, los atacantes manipulan los argumentos de un programa ya invocado usando caracteres de bandera (-, --). Este ataque tiene éxito incluso cuando se filtran los separadores de comandos.
- Inyección de plantillas del lado del servidor (CWE-1336): Apunta a motores de plantillas (Jinja2, FreeMarker). SSTI frecuentemente escala a inyección de comandos del sistema operativo porque los motores de plantillas suelen tener acceso al entorno de ejecución del lenguaje subyacente.
- Inyección de lenguaje de expresiones (CWE-917): Apunta a analizadores de lenguaje de expresiones en frameworks web (OGNL, Spring SpEL). Log4Shell (CVE-2021-44228) es el ejemplo más destacado, encadenándose frecuentemente a la ejecución de comandos del sistema operativo.
| Vulnerabilidad | CWE | Intérprete objetivo | Ruta directa a ejecución en SO |
| Inyección de comandos del sistema operativo | CWE-78 | Shell del sistema operativo | Directa |
| SQL Injection | CWE-89 | Motor SQL | Indirecta (vía xp_cmdshell) |
| Inyección de código | CWE-94 | Entorno de ejecución de la aplicación | Indirecta (vía llamadas al sistema) |
| Inyección de argumentos | CWE-88 | Analizador de argumentos del shell del SO | Directa (manipula el comando invocado) |
| SSTI | CWE-1336 | Motor de plantillas | Frecuentemente escala a comandos del SO |
| Inyección EL | CWE-917 | Analizador de lenguaje de expresiones | Frecuentemente escala a comandos del sistema operativos |
La tabla anterior muestra que varias clases de vulnerabilidad proporcionan una ruta directa o indirecta a la ejecución a nivel de sistema operativo, lo que hace esencial la defensa en profundidad en todos los tipos de inyección.
CVEs relacionados
| ID CVE | Descripción | Gravedad | Producto afectado | Año |
| La inyección de comandos en el endpoint API git diff elude los controles de ejecución de agentes | Crítica | OpenHands AI Platform | 2026 | |
| Inyección de comandos del sistema operativo en la funcionalidad de diagnóstico WAN mediante parámetro curl | Crítica | Tenda G300-F Router | 2026 | |
| Inyección de comandos del sistema operativo en módulos VPN; atacante adyacente autenticado | Alta | TP-Link Archer BE230 | 2026 | |
| Inyección de comandos del sistema operativo no autenticada en dispositivos de comunicación ICS | Crítica | Zenitel Devices | 2025 | |
| Inyección de comandos del sistema operativo no autenticada en plataforma de gestión EDR; explotada activamente | Crítica | Sangfor EDR | 2025 | |
| Inyección de comandos post-autenticación en configuración CLI de DDNS | Alta | Zyxel ATP/USG FLEX Firewalls | 2025 | |
| Inyección de comandos mediante entrada no saneada pasada a exec() en image.php | Crítica | ZoneMinder v1.36.34 | 2025 | |
| RCE no autenticada mediante inyección de comandos en endpoint API de middleware | Crítica | Hoverfly API Simulator | 2025 | |
| Inyección de comandos CLI en switches Nexus; explotada por la campaña Velvet Ant | Media | Cisco NX-OS | 2024 | |
| Inyección de comandos del sistema operativo no autenticada en el componente Task Manager | Crítica | Synology BeePhotos/Photos | 2024 | |
| Inyección de comandos no autenticada en el endpoint remote_help-cgi | Crítica | Zyxel NAS326/NAS542 | 2024 | |
| Inyección de comandos post-autenticación mediante HTTP POST en programa CGI; CISA KEV | Alta | Zyxel VMG1312-B10A | 2024 | |
| Inyección de comandos en solicitud CGI que permite ejecución de código a nivel root | Crítica | Webmin | 2024 | |
| Inyección de comandos a nivel root mediante interfaz web; explotada activamente; CISA KEV | Crítica | Cisco IOS XE | 2023 | |
| Inyección de comandos mediante nombres de archivos .tar maliciosos; explotada activamente; CISA KEV | Crítica | Barracuda ESG | 2023 | |
| Inyección de comandos del sistema operativo previa a la autenticación mediante solicitudes HTTP; CISA KEV | Crítica | Zyxel NAS326/540/542 | 2023 | |
| Inyección de comandos no autenticada en la función show_zysync_server_contents | Crítica | Zyxel NAS326/NAS542 | 2023 | |
| Inyección de comandos del sistema operativo mediante metacaracteres de shell en nombres de usuario o de host | Media | OpenBSD OpenSSH | 2023 | |
| Inyección de metacaracteres de shell no autenticada en la interfaz de inicio de sesión; CISA KEV | Crítica | Control Web Panel 7 | 2022 | |
| Inyección de comandos mediante nombres de archivos de certificados maliciosos en el script c_rehash | Crítica | OpenSSL | 2022 | |
| Inyección de comandos del sistema operativo no autenticada mediante interfaz de gestión web | Crítica | Zyxel NWA1100-NH | 2021 | |
| Inyección de comandos previa a la autenticación en firmware de router; CISA KEV | Crítica | DrayTek Vigor Routers | 2020 | |
| Inyección de comandos previa a la autenticación mediante weblogin.cgi; escalada a root; CISA KEV | Crítica | Zyxel NAS326 | 2020 | |
| Inyección de comandos mediante el parámetro deviceName en goform/setUsbUnload; CISA KEV | Crítica | Tenda AC15 Router | 2020 |
Conclusión
La inyección de comandos del sistema operativo otorga a los atacantes ejecución directa a nivel de sistema operativo a través de aplicaciones que pasan entradas no seguras a intérpretes de shell. Puede reducir la exposición eliminando las llamadas a comandos del sistema operativo cuando sea posible, utilizando APIs parametrizadas cuando sea necesario y aplicando validación por lista de permitidos.
Si la prevención falla, la visibilidad de comportamiento en el endpoint le ayuda a detectar rápidamente la generación de shells, conexiones salientes y otros signos de explotación.
Preguntas frecuentes
La inyección de comandos del sistema operativo (CWE-78) es una vulnerabilidad en la que una aplicación construye comandos del sistema operativo utilizando entradas externas no saneadas. Los atacantes inyectan metacaracteres de shell (;, |, &&) para añadir comandos maliciosos que el shell del sistema operativo ejecuta con los privilegios de la aplicación.
La causa raíz es la falta de separación entre los datos del usuario y la sintaxis del comando antes de pasar la entrada a un intérprete de shell.
Sí. La inyección de comandos del sistema operativo está incluida en la categoría de Inyección tanto en OWASP Top 10:2021 como en OWASP Top 10:2025. Tanto CWE-77 como CWE-78 están explícitamente incluidos.
La edición de 2025 también añadió CWE-88 (Argument Injection) como una debilidad mapeada.
Sí. La mayoría de las vulnerabilidades CWE-78 confirmadas como explotadas en el catálogo CISA KEV no requieren autenticación y son explotables de forma remota. CVE-2014-6271 (Shellshock), CVE-2023-28771 (Zyxel) y CVE-2024-3400 permiten explotación remota sin autenticación.
Los dispositivos de red, incluidos cortafuegos, concentradores VPN y switches empresariales, generan la mayor concentración de entradas CWE-78 confirmadas como explotadas. El firmware IoT y embebido, incluidos los dispositivos NAS y routers, son sistemáticamente atacados para el reclutamiento de botnets.
Las aplicaciones web que invocan comandos del sistema en el lado del servidor y las interfaces de gestión empresarial también presentan un riesgo elevado.
Los atacantes prueban campos de entrada, cabeceras HTTP, cookies y parámetros de URL inyectando metacaracteres de shell seguidos de comandos de diagnóstico. Para la inyección ciega, utilizan retardos de tiempo (sleep 10) o callbacks DNS a servidores controlados por el atacante.
Los escáneres y herramientas de fuzzing prueban sistemáticamente todos los vectores de entrada.
Los principales indicadores incluyen procesos de servidor web (apache, nginx, tomcat) que generan procesos de shell inesperados (bash, sh, cmd.exe). Otros signos son conexiones de red salientes desde procesos de la aplicación a IPs desconocidas y llamadas inusuales a execve() o system() desde contextos de procesos de aplicaciones web.
La inyección de comandos del sistema operativo es una clase de vulnerabilidad de alta gravedad porque otorga a los atacantes acceso directo a nivel de sistema operativo, lo que significa que pueden ejecutar cualquier comando que admita el sistema operativo anfitrión.
CWE-78 se encuentra entre las principales categorías de debilidades de software de MITRE, y los CVE confirmados suelen tener puntuaciones CVSS de 9.0 o superiores.
Sí. SANS informa que CVE-2024-40891 describe explícitamente "compromiso completo del sistema, exfiltración de datos o infiltración de la red." Cuando la aplicación comprometida se ejecuta con privilegios elevados, los atacantes obtienen acceso equivalente a nivel del sistema operativo.
Las consecuencias confirmadas incluyen la implementación de ransomware, movimiento lateral e instalación persistente de puertas traseras.
Las herramientas SAST detectan de forma fiable llamadas API peligrosas en el código fuente, pero no identifican vulnerabilidades presentes solo en tiempo de ejecución. Las herramientas DAST encuentran puntos de inyección explotables, especialmente al usar técnicas OAST para inyección ciega.
Las reglas WAF detectan patrones conocidos, pero pueden ser eludidas mediante codificación. La visibilidad del comportamiento a nivel de proceso proporciona la identificación en tiempo de ejecución más fiable. Ninguna herramienta detecta todas las variantes, por lo que es necesario un enfoque en capas.
La infraestructura crítica y las telecomunicaciones enfrentan el mayor riesgo confirmado. Documentos de CISA advierten sobre explotación patrocinada por el estado chino dirigida a telecomunicaciones e infraestructura de routers.
Las agencias gubernamentales federales enfrentan plazos obligatorios de remediación KEV. Cualquier industria que utilice dispositivos de red expuestos a internet o firmware embebido es un objetivo potencial.
