Una puerta trasera es un método típicamente encubierto para eludir la autenticación o el cifrado normales en una computadora, producto, dispositivo integrado (por ejemplo, un enrutador doméstico ) o su forma de realización (por ejemplo, parte de un criptosistema , algoritmo , chipset o incluso una "computadora homúnculo", una pequeña computadora dentro de una computadora como la que se encuentra en la tecnología AMT de Intel ). [1] [2] Las puertas traseras se utilizan con mayor frecuencia para asegurar el acceso remoto a una computadora u obtener acceso a texto sin formato en criptosistemas. Desde allí, se pueden usar para obtener acceso a información privilegiada como contraseñas, corromper o eliminar datos en discos duros o transferir información dentro de redes autoschediales.
Una puerta trasera puede tomar la forma de una parte oculta de un programa, [3] un programa separado (por ejemplo, Back Orifice puede subvertir el sistema a través de un rootkit ), código en el firmware del hardware, [4] o partes de un sistema operativo como Windows . [5] [6] [7] Los caballos de Troya se pueden utilizar para crear vulnerabilidades en un dispositivo. Un caballo de Troya puede parecer un programa completamente legítimo, pero cuando se ejecuta, desencadena una actividad que puede instalar una puerta trasera. [8] Aunque algunas se instalan en secreto, otras puertas traseras son deliberadas y ampliamente conocidas. Este tipo de puertas traseras tienen usos "legítimos", como proporcionar al fabricante una forma de restaurar las contraseñas de los usuarios.
Muchos sistemas que almacenan información dentro de la nube no logran crear medidas de seguridad precisas. Si muchos sistemas están conectados dentro de la nube , los piratas informáticos pueden obtener acceso a todas las demás plataformas a través del sistema más vulnerable. [9] Las contraseñas predeterminadas (u otras credenciales predeterminadas) pueden funcionar como puertas traseras si el usuario no las cambia. Algunas funciones de depuración también pueden actuar como puertas traseras si no se eliminan en la versión de lanzamiento. [10] En 1993, el gobierno de los Estados Unidos intentó implementar un sistema de cifrado , el chip Clipper , con una puerta trasera explícita para el acceso de las fuerzas del orden y la seguridad nacional. El chip no tuvo éxito. [11]
Las propuestas recientes para contrarrestar las puertas traseras incluyen la creación de una base de datos de sus desencadenantes y el posterior uso de redes neuronales para detectarlas. [12]
La amenaza de las puertas traseras surgió cuando los sistemas operativos multiusuario y en red se adoptaron ampliamente. Petersen y Turn analizaron la subversión informática en un artículo publicado en las actas de la Conferencia AFIPS de 1967. [13] Observaron una clase de ataques de infiltración activa que utilizan puntos de entrada "trampillas" en el sistema para eludir las funciones de seguridad y permitir el acceso directo a los datos. El uso de la palabra " trampillas " aquí coincide claramente con definiciones más recientes de una puerta trasera. Sin embargo, desde la llegada de la criptografía de clave pública , el término "trampillas" ha adquirido un significado diferente (véase función de la "trampilla "), y por lo tanto ahora se prefiere el término "puerta trasera", sólo después de que el término "trampillas" dejara de usarse. De manera más general, estas brechas de seguridad se analizaron en profundidad en un informe del grupo de trabajo de la Corporación RAND publicado bajo el patrocinio de la DARPA por JP Anderson y DJ Edwards en 1970. [14]
Aunque inicialmente se dirigían al dominio de la visión artificial, los ataques de puerta trasera se han expandido para abarcar varios otros dominios, incluidos texto, audio, diseño asistido por computadora basado en ML y clasificación de señales inalámbricas basada en ML. Además, se han demostrado vulnerabilidades en las puertas traseras en modelos generativos profundos , aprendizaje de refuerzo (por ejemplo, AI GO) y modelos de gráficos profundos. Estos riesgos potenciales de amplio alcance han provocado inquietudes de las agencias de seguridad nacional con respecto a sus consecuencias potencialmente desastrosas. [15]
Una puerta trasera en un sistema de inicio de sesión puede adoptar la forma de una combinación de usuario y contraseña codificada de forma rígida que otorga acceso al sistema. Un ejemplo de este tipo de puerta trasera se utilizó como recurso argumental en la película WarGames de 1983 , en la que el arquitecto del sistema informático " WOPR " había insertado una cuenta codificada sin contraseña que otorgaba al usuario acceso al sistema y a partes no documentadas del mismo (en particular, un modo de simulación similar a un videojuego y la interacción directa con la inteligencia artificial ).
Aunque no se conoce ampliamente la cantidad de puertas traseras en sistemas que utilizan software propietario (software cuyo código fuente no está disponible públicamente), se las descubre con frecuencia. Los programadores incluso han logrado instalar en secreto grandes cantidades de código benigno como huevos de Pascua en programas, aunque estos casos pueden implicar una tolerancia oficial, si no un permiso real.
Hay una serie de consideraciones de carácter cuasi secreto que entran en juego a la hora de distribuir la responsabilidad.
A veces, las puertas traseras encubiertas se hacen pasar por defectos involuntarios (errores) por razones de negación plausible . En algunos casos, pueden comenzar como un error real (error involuntario) que, una vez descubierto, se deja deliberadamente sin corregir ni divulgar, ya sea por un empleado deshonesto para obtener una ventaja personal o con conocimiento y supervisión de un ejecutivo de alto nivel.
También es posible que la base tecnológica de una corporación completamente transparente sea contaminada de manera encubierta e imposible de rastrear por agentes externos (piratas informáticos), aunque se cree que este nivel de sofisticación existe principalmente a nivel de actores de estados nacionales. Por ejemplo, si una fotomáscara obtenida de un proveedor de fotomáscaras difiere en algunas puertas de su especificación de fotomáscara, un fabricante de chips tendría dificultades para detectarlo si por lo demás fuera funcionalmente silencioso; un rootkit encubierto que se ejecuta en el equipo de grabado de fotomáscaras también podría ejecutar esta discrepancia sin que lo sepa el fabricante de la fotomáscara, y por esos medios, una puerta trasera potencialmente conduce a otra. [nota 1]
En términos generales, las largas cadenas de dependencia de la economía moderna, tecnológicamente altamente especializada y los innumerables puntos de control de procesos compuestos por elementos humanos hacen difícil señalar con certeza la responsabilidad cuando se descubre una puerta trasera encubierta.
Incluso las admisiones directas de responsabilidad deben ser examinadas cuidadosamente si la parte que confiesa está en deuda con otros intereses poderosos.
Muchos gusanos informáticos , como Sobig y Mydoom , instalan una puerta trasera en el equipo afectado (generalmente un PC con banda ancha que ejecuta Microsoft Windows y Microsoft Outlook ). Estas puertas traseras parecen estar instaladas para que los spammers puedan enviar correo basura desde las máquinas infectadas. Otros, como el rootkit de Sony/BMG , colocado secretamente en millones de CD de música hasta finales de 2005, están pensados como medidas de DRM y, en ese caso, como agentes de recopilación de datos , ya que ambos programas subrepticios que instalaron se comunicaban rutinariamente con servidores centrales.
Un sofisticado intento de implantar una puerta trasera en el núcleo de Linux , expuesto en noviembre de 2003, agregó un pequeño y sutil cambio de código subvirtiendo el sistema de control de versiones . [16] En este caso, un cambio de dos líneas parecía verificar los permisos de acceso root de un llamador a la sys_wait4función, pero debido a que utilizó la asignación =en lugar de la verificación de igualdad ==, en realidad otorgó permisos al sistema. Esta diferencia se pasa por alto fácilmente, e incluso podría interpretarse como un error tipográfico accidental, en lugar de un ataque intencional. [17] [18]
En enero de 2014, se descubrió una puerta trasera en ciertos productos Android de Samsung , como los dispositivos Galaxy. Las versiones Android propietarias de Samsung están equipadas con una puerta trasera que proporciona acceso remoto a los datos almacenados en el dispositivo. En particular, el software Android de Samsung que se encarga de gestionar las comunicaciones con el módem, utilizando el protocolo Samsung IPC, implementa una clase de solicitudes conocidas como comandos de servidor de archivos remoto (RFS), que permiten al operador de la puerta trasera realizar a través del módem operaciones de E/S remotas en el disco duro del dispositivo u otro almacenamiento. Como el módem ejecuta el software Android propietario de Samsung, es probable que ofrezca un control remoto por aire que luego podría usarse para emitir los comandos RFS y, por lo tanto, acceder al sistema de archivos del dispositivo. [19]
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áquinas, no por humanos. Estas puertas traseras se pueden insertar directamente en el código objeto en disco o en algún punto durante la compilación, el enlace de ensamblaje o la carga; en este último caso, la puerta trasera nunca aparece en el disco, solo en la memoria. Las puertas traseras de código objeto son difíciles de detectar mediante la inspección del código objeto, pero se detectan fácilmente simplemente verificando los cambios (diferencias), especialmente en la longitud o en la suma de comprobación, y en algunos casos se pueden detectar o analizar desensamblando el código objeto. Además, las puertas traseras de código objeto se pueden eliminar (suponiendo que el código fuente esté disponible) simplemente recompilando desde la fuente en un sistema confiable.
Por lo tanto, para evitar que se detecten estas puertas traseras, es necesario subvertir todas las copias existentes de un binario, comprometer también las sumas de comprobación de validación y no poder acceder a la fuente para evitar la recompilación. Alternativamente, estas otras herramientas (verificaciones de longitud, diff, suma de comprobación, desensambladores) pueden verse comprometidas para ocultar la puerta trasera, por ejemplo, detectando que se está realizando una suma de comprobación del binario subvertido y devolviendo el valor esperado, no el valor real. Para ocultar estas subversiones posteriores, las herramientas también deben ocultar los cambios en sí mismas; por ejemplo, un sumador de comprobación subvertido también debe detectar si se está realizando una suma de comprobación a sí mismo (o a otras herramientas subvertidas) y devolver valores falsos. Esto lleva a cambios extensos en el sistema y a la necesidad de herramientas para ocultar un solo cambio.
Como el código objeto se puede regenerar recompilando (reensamblando, volviendo a vincular) 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 bajo ataque inserte la puerta trasera) o, alternativamente, el ensamblador, el enlazador o el cargador. Como esto requiere subvertir el compilador, esto a su vez se puede solucionar recompilando el compilador, eliminando el código de inserción de la puerta trasera. Esta defensa a su vez se puede subvertir colocando una metapuerta trasera de origen en el compilador, de modo que cuando detecte que se está compilando a sí mismo, inserte este generador de metapuerta trasera, junto con el generador de puerta trasera original para el programa original bajo ataque. Una vez hecho esto, se puede eliminar la metapuerta trasera de origen y se puede volver a compilar el compilador a partir del código fuente original con el ejecutable del compilador comprometido: la puerta trasera se ha arrancado. Este ataque data de un artículo de 1974 de Karger y Schell, [20] y se popularizó en el artículo de Thompson de 1984, titulado "Reflexiones sobre la confianza en la confianza"; [21] por lo tanto, se lo conoce coloquialmente como el ataque "Confianza en la confianza". Vea las puertas traseras del compilador, a continuación, para obtener más detalles. Ataques análogos pueden apuntar a niveles inferiores del sistema, como el sistema operativo, y pueden insertarse durante el proceso de arranque del sistema ; Karger y Schell también los mencionaron en 1974, y ahora existen en forma de virus del sector de arranque . [20] [22]
Una puerta trasera tradicional es una puerta trasera simétrica: cualquiera que la encuentre puede a su vez usarla. El concepto de puerta trasera asimétrica fue introducido por Adam Young y Moti Yung en Proceedings of 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 de la puerta trasera se hace pública (por ejemplo, mediante la publicación, siendo descubierta y divulgada por ingeniería inversa , etc.). Además, es computacionalmente intratable detectar la presencia de una puerta trasera asimétrica bajo 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 es parte de un campo más amplio ahora llamado criptovirología . Cabe destacar que la NSA insertó una puerta trasera cleptográfica en el estándar Dual EC DRBG . [4] [23] [24]
Existe una puerta trasera asimétrica experimental en la generación de claves RSA . Esta puerta trasera RSA OpenSSL, diseñada por Young y Yung, utiliza un par trenzado de curvas elípticas y ya está disponible. [25]
Una forma sofisticada de puerta trasera de caja negra es una puerta trasera de compilador , en la que no solo se subvierte un compilador (para insertar una puerta trasera en algún otro programa, como un programa de inicio de sesión), sino que también se modifica para detectar cuándo se está compilando a sí mismo y luego inserta tanto el código de inserción de la puerta trasera (que apunta al otro programa) como la autocompilación que modifica el código, como el mecanismo a través del cual los retrovirus infectan a su anfitrión. Esto se puede hacer modificando el código fuente, y el compilador comprometido resultante (código objeto) puede compilar el código fuente original (sin modificar) e insertarse a sí mismo: el exploit ha sido arrancado.
Este ataque fue presentado originalmente en Karger & Schell (1974), [nota 2] que fue un análisis de seguridad de Multics por parte de la Fuerza Aérea de los Estados Unidos , donde describieron un ataque de este tipo a un compilador PL/I y lo llamaron una "trampa del compilador". También mencionaron una variante donde el código de inicialización del sistema se modifica para insertar una puerta trasera durante el arranque , ya que esto es complejo y poco comprendido, y lo llamaron una "trampa de inicialización"; esto ahora se conoce como un virus del sector de arranque . [22]
Este ataque fue implementado por Ken Thompson y popularizado en su discurso de aceptación del Premio Turing en 1983, "Reflexiones sobre la confianza en la confianza", [21] que señala que la confianza es relativa y el único software en el que realmente se puede confiar es el código en el que se ha inspeccionado cada paso del arranque. Este mecanismo de puerta trasera se basa en el hecho de que las personas solo revisan el código fuente (escrito por humanos), y no el código de máquina compilado ( código objeto ). Se utiliza un programa llamado compilador para crear el segundo a partir del primero, y generalmente se confía en que el compilador haga un trabajo honesto.
El artículo de Thompson [21] describe una versión modificada del compilador C de Unix que colocaría una puerta trasera invisible en el comando de inicio de sesión de Unix cuando notara que se estaba compilando el programa de inicio de sesión, y también agregaría esta característica de manera indetectable a futuras versiones del compilador al compilarlas. Como el compilador en sí era un programa compilado, sería extremadamente improbable que los usuarios notaran las instrucciones de código de máquina que realizaban estas tareas. (Debido a la segunda tarea, el código fuente del compilador parecería "limpio"). Lo que es peor, en la implementación de prueba de concepto de Thompson , el compilador subvertido también subvirtió el programa de análisis (el desensamblador ), de modo que cualquiera que examinara los binarios de la manera habitual no vería en realidad el código real que se estaba ejecutando, sino algo más.
Karger y Schell dieron un análisis actualizado del exploit original en 2002 y, en 2009, Wheeler escribió una descripción histórica y un estudio de la literatura. [nota 3] En 2023, Cox publicó una versión anotada del código fuente de la puerta trasera de Thompson. [27]
Oficialmente, la versión de Thompson nunca se publicó. Sin embargo, se cree que se distribuyó una versión a BBN y se registró al menos un uso de la puerta trasera. [nota 4] Hay informes anecdóticos dispersos de tales puertas traseras 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 de Windows. El virus introdujo su propio código en la compilación de nuevos programas de Delphi, lo que le permitió infectar y propagarse a muchos sistemas, sin el conocimiento del programador del software. El virus busca una instalación de Delphi, modifica el archivo SysConst.pas, que es el código fuente de una parte de la biblioteca estándar y lo compila. Después de eso, todos los programas compilados por esa instalación de Delphi contendrán el virus. Un ataque que se propaga mediante la creación de su propio troyano puede ser especialmente difícil de descubrir. Esto provocó que muchos proveedores de software lanzaran ejecutables infectados sin darse cuenta, a veces afirmando falsos positivos. Después de todo, no se manipuló 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 que se descubriera. [nota 5]
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 descubrió que 4.000 aplicaciones estaban afectadas. No era un verdadero troyano Thompson, ya que no infecta las herramientas de desarrollo en sí, pero demostró que el envenenamiento de la cadena de herramientas puede causar daños sustanciales. [30]
Una vez que un sistema ha sido comprometido con una puerta trasera o un caballo de Troya, como el compilador Trusting Trust , es muy difícil para el usuario "legítimo" recuperar el control del sistema; por lo general, se debe reconstruir un sistema limpio y transferir datos (pero no ejecutables). Sin embargo, se han sugerido varias debilidades prácticas en el esquema Trusting Trust . Por ejemplo, un usuario lo suficientemente motivado podría revisar minuciosamente el código de máquina del compilador no confiable antes de usarlo. Como se mencionó anteriormente, existen formas de ocultar el caballo de Troya, como subvertir el desensamblador; pero también hay formas de contrarrestar esa defensa, como escribir un desensamblador desde cero. [ cita requerida ]
Un método genérico para contrarrestar los ataques de confianza se denomina compilación doble diversa . El método requiere un compilador diferente y el código fuente del compilador bajo prueba. Esa fuente, compilada con ambos compiladores, da como resultado dos compiladores de etapa 1 diferentes, que sin embargo deberían tener el mismo comportamiento. Por lo tanto, la misma fuente compilada con ambos compiladores de etapa 1 debe dar como resultado dos compiladores de etapa 2 idénticos. Se proporciona una prueba formal de que la última comparación garantiza que el supuesto código fuente y el ejecutable del compilador bajo prueba se corresponden, bajo algunas suposiciones. Este método fue aplicado por su autor para verificar que el compilador C de la suite GCC (v. 3.0.4) no contenía ningún troyano, utilizando icc (v. 11.0) como el compilador diferente. [26]
En la práctica, los usuarios finales no realizan estas verificaciones, excepto en circunstancias extremas de detección y análisis de intrusiones, debido a la rareza de estos sofisticados ataques y porque los programas suelen distribuirse en formato binario. La eliminación de las puertas traseras (incluidas las puertas traseras del compilador) suele realizarse simplemente reconstruyendo un sistema limpio. Sin embargo, las verificaciones sofisticadas son de interés para los proveedores de sistemas operativos, para asegurarse de que no están distribuyendo un sistema comprometido, y en entornos de alta seguridad, donde este tipo de ataques son una preocupación real.
