Reino: Input Validation and Representation

Los problemas de validación y representación de entradas están causados por metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad surgen de entradas en las que se confía. Estos problemas incluyen: «desbordamientos de búfer», ataques de «scripts de sitios», "SQL injection" y muchas otras acciones.

Command Injection

Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: El siguiente código de una utilidad del sistema utiliza la clave del registro APPHOME para determinar el directorio en el que está instalado y, a continuación, ejecuta una secuencia de comandos de inicialización basada en una ruta de acceso relativa desde el directorio especificado.


...
CALL FUNCTION 'REGISTRY_GET'
EXPORTING
KEY = 'APPHOME'
IMPORTING
VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la entrada del registro APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Dado que el programa no valida el valor leído desde el registro, si un usuario malintencionado puede controlar el valor de la clave del registro APPHOME, podrá engañar a la aplicación para que ejecute código malintencionado y tome el control del sistema.

Ejemplo 2: El siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y después ejecutar una secuencia de comandos cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
EXPORTING
commandname = cmd_exe
long_params = cmd_string
EXCEPTIONS
no_permission = 1
command_not_found = 2
parameters_too_long = 3
security_risk = 4
OTHERS = 5.
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. El módulo de función SXPG_COMMAND_EXECUTE_LONG no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a CALL 'SYSTEM'. Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aCALL 'SYSTEM'. Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código utiliza la entrada del archivo de configuración para determinar el directorio en el que está instalado y, a continuación, ejecuta una secuencia de comandos de inicialización basada en una ruta de acceso relativa desde el directorio especificado.


...
var fs:FileStream = new FileStream();
fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
home = String(fs.readObject(home));
var cmd:String = home + INITCMD;
fscommand("exec", cmd);
...


El código del Example 1 permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación del contenido del archivo de configuración configStream para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Dado que el programa no valida el valor leído desde el archivo, si un usuario malintencionado puede controlar este valor, podrá engañar a la aplicación para que ejecute código malintencionado y tomar el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var btype:String = String(params["backuptype"]);
var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
fscommand("exec", cmd);
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función fscommand() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a fscommnd(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
fscommand("exec", "make");
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada afscommand(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.actionscript.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta un script de inicialización en función de una ruta relativa desde el directorio especificado.


...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
+ btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...


El problema aquí es que el programa no realiza ninguna validación en BackupTypeField. La función Process.Start() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Process.Start(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: el siguiente código es de una aplicación web que concede a los usuarios acceso a una interfaz a través de la cual se puede actualizar la contraseña en el sistema. Parte del proceso de actualización de contraseñas en este entorno de red consiste en ejecutar el comando update.exe de la siguiente forma:


...
Process.Start("update.exe");
...


El problema aquí es que el programa no especifica una ruta absoluta y no puede limpiar su entorno antes de ejecutar la llamada a Process.start(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina update.exe y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando update.exe del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.dotnet.command_injection
Abstract
La ejecución de comandos que incluyen entradas de usuario no validadas puede provocar que la aplicación actúe en nombre del usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En ese caso, nuestra principal inquietud es el primer escenario, en el que un usuario malintencionado controla de forma explícita el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos forman parte de una cadena que la aplicación ejecuta como comando.


3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: en el siguiente programa de ejemplo se acepta un nombre de archivo como argumento de línea de comandos y se muestra el contenido del archivo al usuario. El programa se instala en setuid root porque está diseñado como herramienta de aprendizaje para permitir a los administradores del sistema en formación inspeccionar los archivos del sistema con privilegios sin concederles la capacidad de modificarlos o dañar el sistema.


int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}


Como el programa se ejecuta con privilegios root, la llamada a system() también se ejecuta con privilegios root. Si un usuario especifica un nombre de archivo estándar, la llamada presenta el funcionamiento previsto. Sin embargo, si un atacante transfiere una cadena con el formato ";rm -rf /", la llamada a system() no se ejecuta cat debido a la falta de argumentos y, a continuación, pasa a eliminar de forma recursiva el contenido de la partición raíz.

Ejemplo 2: el siguiente código de un programa con privilegios utiliza la variable de entorno $APPHOME para determinar el directorio de instalación de la aplicación y, a continuación, ejecuta una secuencia de comandos de inicialización en ese directorio.


...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...


Al igual que en el Example 1, el código de este ejemplo permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación. En este ejemplo, el atacante puede modificar la variable de entorno $APPHOME para especificar una ruta diferente que contenga una versión malintencionada de INITCMD. Como el programa no valida el valor leído del entorno, al controlar este, el atacante puede engañar a la aplicación para que ejecute código malicioso.

El usuario malintencionado utiliza la variable de entorno para controlar el comando al que llama el programa, por lo que el efecto del entorno es explícito en este ejemplo. Ahora nos centraremos en lo que puede ocurrir cuando el atacante puede cambiar la forma en que se interpreta el comando.

Ejemplo 3: El siguiente código procede de una utilidad CGI basada en la Web que permite a los usuarios cambiar sus contraseñas. El proceso de actualización de contraseñas bajo NIS conlleva la ejecución de make en el directorio /var/yp. Tenga en cuenta que, como el programa actualiza los registros de contraseñas, se ha instalado setuid root.

El programa llama a make de la siguiente forma:


system("cd /var/yp && make &> /dev/null");


A diferencia de los ejemplos anteriores, el comando de este ejemplo está codificado, por lo que el usuario malintencionado no puede controlar el argumento transferido a system(). Sin embargo, como el programa no especifica una ruta absoluta para make ni limpia ninguna variable de entorno antes de llamar al comando, el atacante puede modificar la variable $PATH para que señale a un archivo binario malicioso denominado make y ejecutar la secuencia de comandos de CGI desde el indicador de shell. Y, como el programa ha instalado setuid root, la versión de make del usuario malintencionado se ejecuta ahora con privilegios root.

En Windows existen riesgos adicionales.

Ejemplo 4: al invocar CreateProcess() directamente o mediante una llamada a una de las funciones de la familia _spawn(), se debe tener cuidado en el caso de que haya un espacio en un ejecutable o en una ruta.


...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...


Debido a la forma en que CreateProcess() analiza los espacios, el primer ejecutable que el sistema operativo intentará ejecutar es Program.exe y no MyApplication.exe. Por lo tanto, si un atacante es capaz de instalar una aplicación malintencionada llamada Program.exe en el sistema, cualquier programa que de manera incorrecta llame a CreateProcess() utilizando el directorio Program Files ejecutará esta aplicación en lugar de la que pretendía ejecutar.

El entorno desempeña un papel fundamental en la ejecución de los comandos del sistema en los programas. Las funciones como system(), exec() y CreateProcess() utilizan el entorno del programa que les llama, por lo que los atacantes disponen de una oportunidad potencial de influir en el comportamiento de dichas llamadas.
desc.dataflow.cpp.command_injection
Abstract
Ejecutar comandos sin especificar una ruta absoluta puede permitir a un atacante usar el programa para ejecutar un binario malintencionado modificando $PATH u otros aspectos del entorno de ejecución del programa.
Explanation
Las vulnerabilidades Command Injection se presentan de dos formas:

- Un atacante puede cambiar el comando que el programa ejecuta: el atacante controla explícitamente el comando.

- Un atacante puede controlar parámetros del programa.

- Un atacante puede cambiar el entorno en el que se ejecuta el comando: el atacante controla implícitamente el significado del comando.

En este caso, nos interesa principalmente el segundo escenario, en el que un usuario malintencionado puede cambiar el significado de un comando mediante la modificación de una variable de entorno o la inserción de un ejecutable malintencionado en la parte inicial de la ruta de búsqueda. Se producen vulnerabilidades Command Injection de este tipo cuando:

1. Un atacante modifica el entorno de una aplicación.

2. La aplicación ejecuta un comando sin especificar una ruta absoluta o verificar el binario que se está ejecutando.



3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: Este ejemplo muestra lo que puede pasar si el atacante puede modificar la manera de interpretar un comando. El código procede de una utilidad CGI basada en la Web que permite a los usuarios cambiar sus contraseñas. El proceso de actualización de contraseñas bajo NIS conlleva la ejecución de make en el directorio /var/yp. Tenga en cuenta que, como el programa actualiza los registros de contraseñas, se ha instalado setuid root.

El programa invoca a make de la siguiente manera:


MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
length of command-line
run-unit-id
stack-size
flags


El comando en este ejemplo está codificado de forma rígida, por lo que un atacante no puede controlar el argumento transferido a CBL_EXEC_RUN_UNIT. Sin embargo, dado que el programa no especifica una ruta absoluta para make y no limpia sus variables de entorno antes de invocar el comando, el atacante puede modificar su variable de $PATH para que se dirija a un binario malintencionado denominado make y ejecutar el script CGI desde una indicación del comando de shell. Además, puesto que en el programa se ha instalado setuid root, la versión del atacante de make funciona con privilegios de root.

Ejemplo 2: El siguiente código usa una variable de entorno para determinar el directorio temporal que contiene el archivo que se va a imprimir con el comando pdfprint.


DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
ws-temp-dir DELIMITED SPACE
"/" DELIMITED SIZE
ws-pdf-filename DELIMITED SPACE
x"00" DELIMITED SIZE
INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer


Al igual que en el ejemplo anterior, el comando está codificado de forma rígida. Sin embargo, dado que el programa no especifica una ruta absoluta para pdfprint, el atacante puede modificar su variable de $PATH para que se dirija a un binario malintencionado. Además, aunque las frases DELIMITED SPACE evitan los espacios incrustados en ws-temp-dir y ws-pdf-filename, podrían existir metacaracteres del comando de shell (como &&) incrustados en cualquiera de ellos.
desc.semantic.cobol.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código permite a un usuario malintencionado especificar comandos arbitrarios mediante el parámetro de solicitud cmd.


...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
desc.dataflow.cfml.command_injection
Abstract
Al ejecutar comandos de un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un atacante.
Explanation
Las vulnerabilidades Command Injection se presentan de dos formas:

- Un atacante puede cambiar el comando que el programa ejecuta: el atacante controla explícitamente qué comando es.

- Un atacante puede cambiar el entorno en el que se ejecuta el comando: el atacante controla implícitamente el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el comando que se ejecuta. Se producen vulnerabilidades Command Injection de este tipo cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena, o como parte de ella, que representa un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: El siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio en el que está instalado y luego ejecuta un guion de inicialización basado en una ruta relativa del directorio especificado.


...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(cmd);
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.
desc.dataflow.dart.command_injection
Abstract
Al ejecutar comandos de un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un atacante.
Explanation
Las vulnerabilidades Command Injection se presentan de dos formas:

- Un atacante puede cambiar el comando que el programa ejecuta: el atacante controla explícitamente el comando.

- Un atacante puede cambiar el entorno en el que se ejecuta el comando: el atacante controla implícitamente el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el comando que se ejecuta. Se producen vulnerabilidades Command Injection de este tipo cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos se utilizan como una cadena, o como parte de ella, que representa un comando que ejecuta la aplicación.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo: El siguiente código utiliza un comando controlado por el usuario.


cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
desc.dataflow.golang.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.


...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función Runtime.exec() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Runtime.exec(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
System.Runtime.getRuntime().exec("make");
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aRuntime.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades clásicas como la inyección de comandos no tienen ningún sentido: ¿por qué se atacaría a sí mismo un usuario? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 4: El siguiente código lee comandos que se van a ejecutar desde una finalidad de Android.


...
String[] cmds = this.getIntent().getStringArrayExtra("commands");
Process p = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(p.getOutputStream());
for (String cmd : cmds) {
os.writeBytes(cmd+"\n");
}
os.writeBytes("exit\n");
os.flush();
...


En un dispositivo con acceso Root, una aplicación malintencionada puede forzar a una aplicación víctima para que ejecute comandos arbitrarios con privilegios de superusuario.
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la variable de entorno APPHOME para determinar el directorio de instalación y, a continuación, ejecuta un script de inicialización en función de una ruta relativa desde el directorio especificado.


var cp = require('child_process');
...
var home = process.env('APPHOME');
var cmd = home + INITCMD;
child = cp.exec(cmd, function(error, stdout, stderr){
...
});
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var btype = url.parse(request.url, true)['query']['backuptype'];
if (btype !== undefined){
cmd = "c:\\util\\rmanDB.bat" + btype;
cp.exec(cmd, function(error, stdout, stderr){
...
});
}
...
}
...
http.createServer(listener).listen(8080);


El problema de esto es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario aparte de verificar su existencia. Una vez que se invoca el shell, puede permitir la ejecución de varios comandos y, debido a la naturaleza de la aplicación, se ejecutará con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el atacante introduzca se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...


El problema aquí es que el programa no especifica una ruta de acceso absoluta para make y no puede limpiar su entorno antes de ejecutar la llamada a child_process.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.javascript.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.


...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(cmd);
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función Runtime.exec() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Runtime.exec(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
$result = shell_exec("make");
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aRuntime.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.php.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo: el siguiente código define un procedimiento almacenado T-SQL que, cuando se llama con datos que no son de confianza, ejecutará un comando de sistema controlado por un atacante.


...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.


...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
os.system(cmd);
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función Runtime.exec() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Runtime.exec(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
result = os.system("make");
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aos.system(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.python.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.


...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: El siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y después ejecutar una secuencia de comandos cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. Una vez que se invoca el comando de shell mediante Kernel.spawn, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
system("make")
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aKernel.system(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.ruby.command_injection
Abstract
Si se ejecutan comandos que incluyen la entrada del usuario sin validar puede hacer que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos ocupamos principalmente del segundo escenario, la posibilidad de que un usuario malintencionado pueda cambiar el significado del comando cambiando una variable de entorno o colocando un ejecutable malintencionado al principio en la ruta de búsqueda. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Un usuario malintencionado modifica el entorno de una aplicación.

2. La aplicación ejecuta un comando sin especificar una ruta de acceso absoluta o comprobar el archivo binario que se está ejecutando.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema.


def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
Al ejecutar comandos desde un origen o en un entorno que no son de confianza, es posible que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta un script de inicialización en función de una ruta relativa desde el directorio especificado.


...
Dim cmd
Dim home

home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...


En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.


...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...


El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.


...
$result = shell_exec("make");
...


El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aRuntime.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.
desc.dataflow.vb.command_injection