Puerta trasera (informática)

Muchos gusanos informáticos , como Sobig y Mydoom , instalan una puerta trasera en el ordenador afectado (generalmente un PC con conexión de banda ancha que ejecuta Microsoft Windows y Microsoft Outlook ). Estas puertas traseras parecen instalarse para que los spammers puedan enviar correo basura desde los equipos infectados. Otros, como el rootkit de Sony/BMG , colocado secretamente en millones de CD de música hasta finales de 2005, tienen como objetivo implementar medidas de DRM y, en ese caso, actuar como agentes de recopilación de datos , ya que ambos programas subrepticios que instalaban contactaban periódicamente con servidores centrales.

Un sofisticado intento de instalar una puerta trasera en el kernel de Linux , descubierto en noviembre de 2003, añadió un pequeño y sutil cambio de código mediante la subversión del sistema de control de versiones . ^{[ 20 ]} En este caso, un cambio de dos líneas parecía comprobar los permisos de acceso de root de quien llamaba a la sys_wait4función, pero debido a que utilizaba la asignación =en lugar de la comprobación de igualdad ==, en realidad otorgaba permisos al sistema. Esta diferencia es fácil de pasar por alto e incluso podría interpretarse como un error tipográfico accidental, en lugar de un ataque intencional. ^{[ 21 ] [ 22 ]}

En enero de 2014, se descubrió una puerta trasera en ciertos productos Android de Samsung , como los dispositivos Galaxy. Las versiones propietarias de Android de Samsung incorporan una puerta trasera que permite el acceso remoto a los datos almacenados en el dispositivo. En concreto, el software Android de Samsung, encargado de gestionar las comunicaciones con el módem mediante el protocolo IPC de Samsung, implementa una clase de solicitudes conocidas como comandos de servidor de archivos remoto (RFS), que permiten al operador de la puerta trasera realizar operaciones de E/S remotas a través del módem en el disco duro u otro almacenamiento del dispositivo. Dado que el módem ejecuta el software propietario Android de Samsung, es probable que ofrezca control remoto inalámbrico que podría utilizarse para emitir los comandos RFS y, por lo tanto, acceder al sistema de archivos del dispositivo. ^{[ 23 ]}

Las puertas traseras más difíciles de detectar implican la modificación del código objeto , en lugar del código fuente. El código objeto es mucho más difícil de inspeccionar, ya que está diseñado para ser legible por máquina, no por humanos. Estas puertas traseras pueden insertarse directamente en el código objeto en disco o en algún punto durante la compilación, el ensamblaje, el enlace o la carga. En este último caso, la puerta trasera nunca aparece en el disco, solo en la memoria. Las puertas traseras en el código objeto son difíciles de detectar mediante la inspección del código objeto, pero se detectan fácilmente simplemente comprobando si hay cambios (diferencias), especialmente en la longitud o en la suma de verificación, y en algunos casos pueden detectarse o analizarse desensamblando el código objeto. Además, las puertas traseras en el código objeto pueden eliminarse (siempre que el código fuente esté disponible) simplemente recompilando desde el código fuente en un sistema de confianza.

Por lo tanto, para que estas puertas traseras eviten ser detectadas, todas las copias existentes de un binario deben ser manipuladas, las sumas de verificación de validación también deben estar comprometidas y el código fuente debe ser inaccesible para evitar la recompilación. Alternativamente, estas otras herramientas (verificaciones de longitud, diff, sumas de verificación, desensambladores) pueden ser comprometidas para ocultar la puerta trasera; por ejemplo, detectando que el binario manipulado está siendo sometido a una suma de verificación y devolviendo el valor esperado, no el real. Para ocultar estas manipulaciones adicionales, las herramientas también deben ocultar los cambios en sí mismas; por ejemplo, un sumador de verificación manipulado debe detectar si se está sometiendo a una suma de verificación (u otras herramientas manipuladas) y devolver valores falsos. Esto conlleva la necesidad de realizar cambios extensos en el sistema y en las herramientas para ocultar un solo cambio.

Dado que el código objeto puede regenerarse recompilando (reensamblando, volviendo a enlazar) el código fuente original, crear una puerta trasera persistente en el código objeto (sin modificar el código fuente) requiere subvertir el compilador mismo, de modo que cuando detecte que está compilando el programa atacado, inserte la puerta trasera; o bien, el ensamblador, el enlazador o el cargador. Como esto requiere subvertir el compilador, a su vez, esto puede solucionarse recompilándolo y eliminando el código de inserción de la puerta trasera. Esta defensa puede, a su vez, subvertirse colocando una meta-puerta trasera en el código fuente del compilador, de modo que cuando detecte que se está compilando a sí mismo, inserte este generador de meta-puerta trasera junto con el generador de puerta trasera original del programa atacado. Una vez hecho esto, se puede eliminar la meta-puerta trasera del código fuente y recompilar el compilador desde el código fuente original con el ejecutable del compilador comprometido: la puerta trasera se ha activado. Este ataque se remonta a un artículo de 1974 de Karger y Schell, ^{[ 24 ]} y se popularizó en el artículo de Thompson de 1984, titulado "Reflexiones sobre la confianza en la confianza"; ^{[ 25 ]} por lo que se le conoce coloquialmente como el ataque "Confiar en la confianza" . Ataques análogos pueden dirigirse a niveles inferiores del sistema, como el sistema operativo, y pueden insertarse durante el proceso de arranque del sistema ; estos también son mencionados por Karger y Schell en 1974, y ahora existen en forma de virus del sector de arranque . ^{[ 24 ] [ 26 ]}

Una puerta trasera tradicional es simétrica: cualquiera que la encuentre puede usarla. La noción de puerta trasera asimétrica fue introducida por Adam Young y Moti Yung en las Actas de Advances in Cryptology – Crypto '96 . Una puerta trasera asimétrica solo puede ser utilizada por el atacante que la instala, incluso si la implementación completa se hace pública (por ejemplo, mediante su publicación, descubrimiento y divulgación por ingeniería inversa , etc.). Además, es computacionalmente intratable detectar la presencia de una puerta trasera asimétrica mediante consultas de caja negra. Esta clase de ataques se ha denominado cleptografía ; pueden llevarse a cabo en software, hardware (por ejemplo, tarjetas inteligentes ) o una combinación de ambos. La teoría de las puertas traseras asimétricas forma parte de un campo más amplio que ahora se denomina criptovirología . Cabe destacar que la NSA insertó una puerta trasera cleptográfica en el estándar Dual EC DRBG . ^{[ 8 ] [ 27 ] [ 28 ]}

Existe una puerta trasera asimétrica experimental en la generación de claves RSA . Esta puerta trasera RSA de OpenSSL, diseñada por Young y Yung, utiliza un par de curvas elípticas retorcidas y se ha puesto a disposición del público. ^{[ 29 ]}

El envenenamiento de modelos en modelos de lenguaje grandes implica introducir datos maliciosos durante el proceso de entrenamiento o ajuste fino, de modo que el modelo se comporte normalmente con entradas estándar, pero active un comportamiento malicioso cuando aparece un desencadenante de puerta trasera específico. Un estudio reciente presentó tres ataques —SIMPLE, COVERT y TROJANPUZZLE— que se centran principalmente en envenenar modelos de generación de código mediante la incrustación de cargas útiles de múltiples tokens o desencadenantes fuera de contexto. ^{[ 30 ]} Estos ataques demuestran cómo incluso los modelos fundamentales grandes pueden ser explotados con un envenenamiento sutil que permanece oculto hasta que se cumple la condición de desencadenante específica.

Dado que estos ataques de puerta trasera se dirigen al proceso de entrenamiento, eluden muchas defensas tradicionales que se centran en ejemplos adversarios durante la inferencia. Por ejemplo, COVERT y TROJANPUZZLE muestran cómo una muestra envenenada en un conjunto de datos de ajuste fino puede eludir el análisis estático sin ser detectada por los procedimientos de validación normales. ^{[ 30 ]} Con conjuntos de datos de código abierto o generados por la comunidad , el riesgo es aún mayor, ya que las contribuciones maliciosas pueden colarse en el proceso de actualización sin un proceso de revisión central de confianza. Esto dificulta que los desarrolladores detecten el ataque hasta que se activa el desencadenante, a menudo mucho después de que el modelo se haya implementado.

Las implicaciones de la manipulación de modelos de lenguaje a gran escala son significativas en áreas como la generación de código o la posible filtración de información confidencial al activarse ciertos desencadenantes. Los investigadores han demostrado cómo la manipulación de modelos puede alterar su comportamiento, incluso cuando se entrenan con conjuntos de datos masivos, manteniendo un alto rendimiento con entradas inocuas. ^{[ 30 ]} Estos riesgos resaltan la necesidad de una auditoría más rigurosa de los conjuntos de datos, pruebas de desencadenantes y un monitoreo continuo de los resultados de los modelos en diferentes contextos.

La versión de Thompson nunca se publicó oficialmente. Sin embargo, se cree que se distribuyó una versión a BBN y que se registró al menos un uso de la puerta trasera. ^{[ nota 3 ]} Existen informes anecdóticos dispersos sobre puertas traseras similares en años posteriores.

En agosto de 2009, los laboratorios Sophos descubrieron un ataque de este tipo. El virus W32/Induc-A infectó el compilador de programas de Delphi , un lenguaje de programación para Windows. El virus introdujo su propio código en la compilación de nuevos programas Delphi, lo que le permitió infectar y propagarse a muchos sistemas sin el conocimiento del programador. El virus busca una instalación de Delphi, modifica el archivo SysConst.pas, que contiene el código fuente de una parte de la biblioteca estándar, y lo compila. Posteriormente, todos los programas compilados por esa instalación de Delphi contendrán el virus. Un ataque que se propaga creando su propio troyano puede ser especialmente difícil de detectar. Esto provocó que muchos proveedores de software lanzaran ejecutables infectados sin darse cuenta, a veces alegando falsos positivos. Al fin y al cabo, no se había manipulado el ejecutable, sino el compilador. Se cree que el virus Induc-A se había estado propagando durante al menos un año antes de ser descubierto. ^{[ nota 4 ]}

En 2015, una copia maliciosa de Xcode, XcodeGhost , también realizó un ataque similar e infectó aplicaciones iOS de una docena de empresas de software en China. A nivel mundial, se detectaron 4000 aplicaciones afectadas. No se trataba de un verdadero troyano Thompson, ya que no infecta las herramientas de desarrollo en sí mismas, pero sí demostró que la infección de la cadena de herramientas puede causar daños sustanciales. ^{[ 36 ]}

Una vez que un sistema se ve comprometido por una puerta trasera o un troyano, como el compilador Trusting Trust , resulta muy difícil para el usuario legítimo recuperar el control del sistema; normalmente, se debería reconstruir un sistema limpio y transferir los datos (pero no los ejecutables). Sin embargo, se han señalado varias debilidades prácticas en el esquema Trusting Trust . Por ejemplo, un usuario con la motivación suficiente podría revisar minuciosamente el código máquina del compilador no confiable antes de usarlo. Como se mencionó anteriormente, existen maneras de ocultar el troyano, como manipular el desensamblador; pero también existen maneras de contrarrestar esa defensa, como escribir un desensamblador desde cero.

Un método genérico para contrarrestar los ataques de confianza basada en confianza se denomina compilación doble diversa . Este método requiere un compilador diferente y el código fuente del compilador bajo prueba. Dicho código fuente, compilado con ambos compiladores, da como resultado dos compiladores de etapa 1 diferentes, que, sin embargo, deberían tener el mismo comportamiento. Por lo tanto, el mismo código fuente compilado con ambos compiladores de etapa 1 debe dar como resultado dos compiladores de etapa 2 idénticos. Se proporciona una prueba formal de que esta última comparación garantiza que el supuesto código fuente y el ejecutable del compilador bajo prueba se corresponden, bajo ciertas suposiciones. Este método fue aplicado por su autor para verificar que el compilador C del conjunto GCC (v. 3.0.4) no contenía ningún troyano, utilizando icc (v. 11.0) como compilador diferente. ^{[ 32 ]}

En la práctica, los usuarios finales no realizan este tipo de verificaciones, salvo en casos extremos de detección y análisis de intrusiones, debido a la rareza de ataques tan sofisticados y a que los programas suelen distribuirse en formato binario. La eliminación de puertas traseras (incluidas las del compilador) generalmente se realiza reconstruyendo un sistema limpio. Sin embargo, las verificaciones sofisticadas son de interés para los proveedores de sistemas operativos, para garantizar que no distribuyan un sistema comprometido, y en entornos de alta seguridad, donde este tipo de ataques representan una preocupación real.