Las vulnerabilidades de control del proceso presentan dos formas:

- Un usuario malintencionado puede cambiar el nombre del programa o el código de la transacción que se invoca: el usuario malintencionado controla explícitamente el código de transacción o el nombre del programa.

- Un atacante puede cambiar el entorno en el que se invoca al programa o a la transacción: el usuario malintencionado controla implícitamente un área de comunicación que se pone a disposición de la transacción o el programa invocados.

En este caso, nos ocupamos principalmente del primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre del programa o el código de la transacción que se invoca. Las vulnerabilidades de control del proceso 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 una cadena que representa un nombre de programa o código de transacción que se invoca.



3. Mediante la ejecución de código desde la transacción o el programa invocados, la aplicación otorga al usuario malintencionado un privilegio o una capacidad que no tendría de otro modo.

Ejemplo 1: El siguiente fragmento de código de una utilidad del sistema con privilegios lee un valor de una solicitud HTTP para determinar el código de la transacción al que llamar.

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

Este fragmento de código permite a un usuario malintencionado llamar a cualquier transacción y ejecutar potencialmente código arbitrario con los privilegios elevados de la aplicación. Dado que el programa no valida el valor leído desde la solicitud HTTP, si un usuario malintencionado puede controlar este valor, podrá engañar a la aplicación para que ejecute código malintencionado y tome el control del sistema.

Las vulnerabilidades de control del proceso presentan dos formas:

- Un atacante podría cambiar el nombre de la biblioteca o del ejecutable que carga el programa: el atacante controla de manera explícita cuál es el nombre de la biblioteca o del ejecutable.

- Un atacante podría cambiar el entorno en el que se carga la biblioteca o el ejecutable: el atacante controla de manera implícita lo que significa el nombre de la biblioteca o el ejecutable.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso 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 una cadena, la cual representa una biblioteca o un ejecutable que la aplicación carga.



3. Al ejecutar el código desde la biblioteca o el ejecutable, la aplicación concede al atacante un privilegio o una capacidad que no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad de sistema con privilegios utiliza la propiedad de configuración de aplicación APPHOME y, a continuación, carga una biblioteca nativa en función de una ruta de acceso relativa desde el directorio especificado.

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

Este código permite a un atacante cargar una biblioteca o un ejecutable y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad APPHOME de la aplicación, con el objetivo de que apunte a una ruta diferente que contenga una versión malintencionada de LIBNAME. Como el programa no valida el valor leído en el entorno, si el atacante puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asumir el control del sistema.

Las vulnerabilidades de control del proceso presentan dos formas:

- Un atacante puede cambiar la biblioteca que el programa ejecuta: el atacante controla explícitamente cuál es la biblioteca.

- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso 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 parte de una cadena que representa un nombre de biblioteca cargada por la aplicación.

3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza una entrada del Registro para determinar el directorio en el que se ha instalado y carga un archivo de biblioteca en función de una ruta relativa desde el directorio especificado.

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

El código de este ejemplo permite a un usuario malintencionado cargar una biblioteca arbitraria desde la que se ejecutará el código con el privilegio elevado de la aplicación, modificando una clave del Registro para especificar una ruta diferente que contenga una versión maliciosa de INITLIB. Como el programa no valida el valor leído del entorno, si un usuario malintencionado puede controlar el valor de APPHOME, este puede engañar a la aplicación para que ejecute código malicioso.

Ejemplo 2: el siguiente código procede de una utilidad de administración basada en la Web que concede acceso a los usuarios a una interfaz mediante la que pueden actualizar su perfil en el sistema. La utilidad usa una biblioteca con el nombre liberty.dll, que se supone que se encuentra en un directorio del sistema estándar.

LoadLibrary("liberty.dll");

Sin embargo, el programa no especifica una ruta absoluta para liberty.dll. Si un usuario malintencionado traslada en el orden de búsqueda una biblioteca maliciosa con el nombre liberty.dll a una posición superior que el archivo previsto y consigue ejecutar el programa en su entorno en lugar de en el entorno del servidor web, la aplicación cargará la biblioteca maliciosa en lugar de la de confianza. Como este tipo de aplicación se ejecuta con privilegios elevados, el contenido del archivo liberty.dll del usuario malintencionado se ejecutará ahora también con este nivel de privilegios, lo que podría darle el control completo del sistema.

Este tipo de ataque es posible debido al orden de búsqueda usado por LoadLibrary() cuando no se especifica una ruta absoluta. Si se realiza una búsqueda en el directorio actual antes que en los directorios del sistema, como era el caso hasta las versiones más recientes de Windows, este tipo de ataque pasa a ser trivial si el atacante puede ejecutar de forma local el programa. El orden de búsqueda depende de la versión del sistema operativo y, en los sistemas operativos más recientes, se controla mediante el valor de esta clave del Registro:

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

La clave no está definida en los sistemas Windows 2000/NT ni Windows Me/98/95.

En los sistemas en los que existe la clave, LoadLibrary() presenta el siguiente comportamiento:
Si SafeDllSearchMode es 1, se utiliza el siguiente orden de búsqueda:
(Configuración predeterminada para Windows XP-SP1 y versiones posteriores, así como para Windows Server 2003.)
1. El directorio desde el que se cargó la aplicación.
2. El directorio del sistema.
3. El directorio del sistema de 16 bits, si existe.
4. El directorio de Windows.
5. El directorio actual.
6. Los directorios enumerados en la variable de entorno PATH.
Si SafeDllSearchMode es 0, se utiliza el siguiente orden de búsqueda:
1. El directorio desde el que se cargó la aplicación.
2. El directorio actual.
3. El directorio del sistema.
4. El directorio del sistema de 16 bits, si existe.
5. El directorio de Windows.
6. Los directorios enumerados en la variable de entorno PATH.

Las vulnerabilidades de control del proceso presentan dos formas:

- Un usuario malintencionado puede cambiar el nombre del programa que se invoca: el usuario malintencionado controla explícitamente el nombre del programa de aplicación.

- Un usuario malintencionado puede cambiar el entorno en el que se invoca el programa: el usuario malintencionado controla implícitamente un área de comunicación que pasa a estar disponible para el programa invocado.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el nombre del programa que se invoca. Las vulnerabilidades de control del proceso 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 parte o totalidad de una cadena que representa un programa que se invoca, o determina el grado de control sobre el entorno en el que se invoca el programa.



3. Mediante la ejecución de código desde el programa invocado, la aplicación brinda al usuario malintencionado un privilegio o capacidad que dicho usuario no tendría en caso contrario.

Ejemplo 1: El siguiente código de una utilidad de sistema con privilegios lee un valor desde el terminal para determinar el nombre del programa al que se transfiere el control.

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

Este código permite a un usuario malintencionado transferir el control a un programa y potencialmente ejecutar el código arbitrario con el privilegio elevado de la aplicación. Dado que el programa no valida el valor leído del terminal, si un usuario malintencionado controla este valor, entonces puede engañar a la aplicación para que ejecute código malintencionado y tomar el control del sistema.

Las vulnerabilidades de control del proceso presentan dos formas:

- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.

- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso 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 que representa una biblioteca cargada por la aplicación o como parte de esta.



3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Ejemplo 1: el código siguiente utiliza una "función" no documentada actualmente de Express para cargar un archivo de biblioteca de forma dinámica. Node.js seguirá buscando en la ruta de carga de biblioteca habitual un archivo o un directorio que contenga dicha biblioteca[1].

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

En Express, la página que se transfiere a Response.render() cargará una biblioteca de la extensión cuando no se conozca de antemano. Esto suele estar bien para las entradas como "foo.pug", ya que implica la carga de la biblioteca pug, un motor de creación de plantillas muy conocido. Sin embargo, si un atacante controlase la página, y por lo tanto la extensión, podría cargar cualquier biblioteca de las rutas de carga de módulos Node.js. Dado que el programa no valida la información recibida del parámetro de URL, un atacante podría engañar a la aplicación para que ejecutara código malintencionado y tomara el control del sistema.

Las vulnerabilidades de control del proceso presentan dos formas:

- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.

- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso 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 que representa una biblioteca cargada por la aplicación o como parte de esta.



3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza la propiedad del sistema APPHOME para determinar el directorio en el que se ha instalado y, a continuación, carga una biblioteca nativa en función de una ruta relativa desde el directorio especificado.

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad APPHOME para que señale a una ruta diferente que contiene una versión maliciosa de LIBNAME. 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, pueden engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código utiliza dl() para cargar código de una biblioteca denominada sockets.dll, que puede cargarse desde varios ubicaciones, según la instalación y configuración.

	...
	dl("sockets");
	...

El problema aquí es que dl() acepta un nombre de biblioteca y no una ruta para que se cargue la biblioteca.

Si un usuario malintencionado es capaz de incluir en el orden de búsqueda una copia maliciosa de sockets.dll en una posición superior a la del archivo que pretende cargar la aplicación, esta cargará la copia malintencionada en lugar del archivo previsto. Dada la naturaleza de la aplicación, esta se ejecuta con privilegios elevados. Es decir, que el contenido de sockets.dll del usuario malintencionado se ejecutará con privilegios elevados, dándole la posibilidad de tener un control completo del sistema.

Dentro de Ruby, el control de procesos puede producirse habitualmente cuando se ejecuta un comando, lo que habilita dos ataques:

1. Control de procesos
Las vulnerabilidades de control de procesos presentan dos formas:

- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.

- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.

En este caso, nos interesa principalmente el segundo escenario, la posibilidad de que un atacante pueda ser capaz de controlar el entorno de forma que el programa cargue una versión malintencionada de la biblioteca nombrada.

1. Un atacante proporciona una biblioteca malintencionada a una aplicación.

2. La aplicación carga la biblioteca malintencionada porque no consigue especificar una ruta de acceso absoluta o verificar el archivo que se está cargando.

3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Tenga en cuenta que el control de procesos puede ocurrir en plataformas Windows al ejecutar un programa externo, ya que el shell utilizado para ejecutar los comandos se elige mediante las variables de entorno RUBYSHELL o COMSPEC. Si un usuario malintencionado es capaz de modificar cualquiera de estas variables de entorno en el entorno actual, significa que el programa al que apuntan estas variables de entorno se ejecutará con el permiso o el programa de Ruby en ejecución.

2. Inyección de comandos
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 1: El siguiente código ejecuta Kernel.system() para ejecutar un ejecutable llamado program.exe, que normalmente se encuentra dentro de un directorio estándar del sistema.

...
system("program.exe")
...

Esto plantea un doble problema:
1. En las plataformas Windows, Kernel.system() ejecuta algo a través de un shell. Si un usuario malintencionado es capaz de manipular las variables de entorno RUBYSHELL o COMSPEC, es posible que apunten a un ejecutable malintencionado al que se llamará con el comando dado a Kernel.system(). 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 program.exe del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionándole un control completo del sistema.
2. En todas las plataformas de este escenario, el problema es que el programa no especifica una ruta absoluta y no puede limpiar su entorno antes de ejecutar la llamada a Kernel.system(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un archivo binario malintencionado llamado program.exe y, a continuación, ejecutar la aplicación en su entorno, el archivo malintencionado binario 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 program.exe del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionándole un control completo del sistema.

En las aplicaciones de IA, las indicaciones del sistema proporcionan instrucciones de preprocesamiento o contexto que guía las respuestas de la IA. Los atacantes pueden crear entradas que, cuando se integran como indicaciones del sistema, alteran el comportamiento del modelo de IA para ejecutar operaciones no autorizadas o revelar información confidencial.

Ejemplo 1: El siguiente código ilustra una inyección de aviso del sistema en el modelo de IA de Anthropic:

client = new Anthropic();

# Simulated attacker's input attempting to inject a malicious system prompt
attacker_input = ...

response = client.messages.create(
    model = "claude-3-5-sonnet-20240620",
    max_tokens=2048,
    system = attacker_input,
    messages = [
        {"role": "user", "content": "Analyze this dataset for anomalies: ..."}
    ]
);
...

En este ejemplo, el atacante manipula entradas no validadas en un mensaje del sistema, lo que puede provocar una violación de la seguridad.

En las aplicaciones de IA, las indicaciones del sistema proporcionan instrucciones de preprocesamiento o contexto que guía las respuestas de la IA. Los atacantes pueden crear entradas que, cuando se integran como indicaciones del sistema, alteran el comportamiento del modelo de IA para ejecutar operaciones no autorizadas o revelar información confidencial.

Ejemplo 1: El siguiente código Python ilustra una inyección de aviso del sistema en el modelo de IA de OpenAI:

  client = OpenAI()

  # Simulated attacker's input attempting to inject a malicious system prompt
  attacker_input = ...

  completion = client.chat.completions.create(
      model="gpt-3.5-turbo",
      messages=[
          {"role": "system", "content": attacker_input},
          {"role": "user", "content": "Compose a poem that explains the concept of recursion in programming."}
      ]
  )

En este ejemplo, el atacante manipula entradas no validadas en un mensaje del sistema, lo que puede provocar una violación de la seguridad.