El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa escriba más allá de los límites de la memoria asignada.

Ejemplo: el código siguiente desborda buf porque, según el tamaño de f, el especificador de cadena de formato "%d %.1f ... " puede superar la cantidad de memoria asignada.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de error por uno ("off-by-one") sigue siendo normal en algunas plataformas y comunidades de desarrollo, hay más tipos de buffer overflow, entre los que se incluyen los desbordamientos de búfer de pila y de montón. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

Ejemplo: El código siguiente contiene un desbordamiento del búfer por una unidad, que se produce cuando recv devuelve el máximo de bytes leídos: sizeof(buf). En este caso, la siguiente desreferencia de buf[nbytes] escribirá el byte null fuera de los límites de memoria asignada.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

Ejemplo: el código siguiente intenta evitar un buffer overflow por una unidad comprobando que el valor no confiable leído desde getInputLength() tiene un tamaño menor que el de la output del búfer de destino. Sin embargo, como la comparación entre len y MAX tiene signo, si len es negativo, se convertirá en un número positivo muy largo cuando se convierta a un argumento sin signo para memcpy().

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

Los motores de plantillas se usan para procesar contenido mediante datos dinámicos. El usuario suele controlar estos datos de contexto, a los que se les da formato mediante una plantilla para generar páginas web, correos electrónicos, etc. Los motores de plantillas permiten usar potentes expresiones de lenguaje en plantillas para procesar contenido dinámico; para ello, los datos de contexto se procesan con construcciones de codificación, como condicionales, bucles, etc. Si un atacante controla la plantilla que se desea procesar, puede inyectar expresiones que expongan los datos de contexto y ejecuten comandos arbitrarios en el explorador.

Ejemplo 1: en el ejemplo siguiente se muestra cómo recuperar una plantilla de una dirección URL y cómo se representa la información con AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

En este caso, $stateParams.expression tomará datos potencialmente controlados por el usuario y los evaluará como una plantilla para utilizarlos con un contexto especificado. Esto, a su vez, puede permitir a un usuario malintencionado ejecutar cualquier código que desee en el explorador, recuperando información sobre el contexto en el que se ejecute, buscando información adicional sobre cómo se crea la aplicación o convirtiéndolo en un auténtico ataque XSS.

Las vulnerabilidades de inclusión no autorizadas se producen cuando:

1. Los datos tienen acceso a una aplicación web a través de una fuente que no es de confianza; la mayoría de las veces mediante una solicitud web.

2. Los datos forman parte de la cadena que especifica el atributo template de una etiqueta <cfinclude>.
Ejemplo: el siguiente código utiliza la entrada de un formulario web para crear la ruta de acceso a un archivo especial que se utiliza para dar formato a la página de inicio del usuario. El programador no ha considerado la posibilidad de que un usuario malintencionado pueda proporcionar un nombre de archivo malintencionado, como "../../users/wileyh/malicious", que provocará que la aplicación incluya y ejecute el contenido de un archivo en el directorio de inicio del usuario malintencionado.

<cfinclude template =  
              "C:\\custom\\templates\\#Form.username#.cfm">

Si un atacante puede especificar el archivo incluido por la etiqueta <cfinclude>, puede provocar que la aplicación incluya el contenido de casi cada archivo en el sistema de archivos del servidor de la página actual. Esta capacidad se puede aprovechar como mínimo de dos maneras significativas. Si un atacante puede escribir en una ubicación del sistema de archivos del servidor, como el directorio de inicio del usuario o un directorio común de carga, podrá provocar que la aplicación incluya un archivo con contenido perjudicial en la página, que ejecutará el servidor. Incluso sin acceso de escritura al sistema de archivos del servidor, un atacante podría a menudo acceder a información confidencial o privada mediante la especificación de la ruta de acceso de un archivo del servidor.

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.

Las referencias directas a las expresiones de GitHub Actions en un script de ejecución se generan de forma dinámica. Esto permite que cualquiera que tenga el control de la entrada pueda comprometer el sistema mediante la inyección de comandos.

Ejemplo 1: El siguiente código de una GitHub Action hace referencia directa a una expresión en un script de ejecución que deja el sistema abierto para la inyección de comandos.

    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...
    

Cuando se ejecuta la acción, el script de shell se ejecuta de forma dinámica, incluido cualquier código que represente el valor github.event.pull_request.title. Si github.event.pull_request.title contiene código ejecutable malintencionado, la acción ejecuta el código malintencionado, lo que resulta en la inyección de comandos.