Una puerta trasera es un método típicamente encubierto para eludir la autenticación o el cifrado normal en una computadora, producto, dispositivo integrado (por ejemplo, un enrutador doméstico ) o su encarnación (por ejemplo, parte de un criptosistema , algoritmo , conjunto de chips 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 proteger el acceso remoto a una computadora u obtener acceso a texto sin formato en criptosistemas. Desde allí se puede utilizar para obtener acceso a información privilegiada como contraseñas, corromper o eliminar datos en discos duros o transferir información dentro de redes autoschediastic.
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 por ejemplo 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 totalmente 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 hay muchos sistemas 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 activadores y luego el 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 discutieron 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 "trampilla" al sistema para eludir las instalaciones de seguridad y permitir el acceso directo a los datos. El uso de la palabra trampilla aquí coincide claramente con definiciones más recientes de puerta trasera. Sin embargo, desde la llegada de la criptografía de clave pública, el término trampilla ha adquirido un significado diferente (ver función de trampilla ) y, por lo tanto, ahora se prefiere el término "puerta trasera", solo después de que el término trampilla dejó de usarse. De manera más general, tales violaciones de seguridad se discutieron extensamente en un informe del grupo de trabajo de RAND Corporation publicado bajo el patrocinio de DARPA por JP Anderson y DJ Edwards en 1970. [14]
Si bien inicialmente tenían como objetivo el dominio de la visión por computadora, 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 por refuerzo (p. ej., AI GO) y modelos de gráficos profundos. Estos riesgos potenciales de amplio alcance han generado preocupación por parte de las agencias de seguridad nacionales con respecto a sus consecuencias potencialmente desastrosas. [15]
Una puerta trasera en un sistema de inicio de sesión puede tomar la forma de una combinación de usuario y contraseña codificada que da 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 daba al usuario acceso al sistema y a accesos indocumentados. partes del sistema (en particular, un modo de simulación similar a un videojuego y la interacción directa con la inteligencia artificial ).
Aunque no se reconoce ampliamente el número de puertas traseras en sistemas que utilizan software propietario (software cuyo código fuente no está disponible públicamente), con frecuencia quedan expuestas. Los programadores incluso han logrado instalar en secreto grandes cantidades de código benigno como huevos de Pascua en los programas, aunque tales casos pueden implicar tolerancia oficial, si no permiso real.
Hay una serie de consideraciones de tipo secreto que entran en juego al repartir responsabilidades.
Las puertas traseras encubiertas a veces se hacen pasar por defectos inadvertidos (errores) por razones de negación plausible . En algunos casos, estos pueden comenzar como un error real (error involuntario) que, una vez descubierto, se deja deliberadamente sin corregir y sin revelar, ya sea por un empleado deshonesto para beneficio personal o con conocimiento y supervisión de un ejecutivo de nivel C.
También es posible que la base tecnológica de una corporación totalmente legítima esté contaminada de manera encubierta e imposible de rastrear por agentes externos (hackers), aunque se cree que este nivel de sofisticación existe principalmente a nivel de los actores estatales-nación. 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 detectar esto si, por lo demás, es funcionalmente silencioso; un rootkit encubierto que se ejecuta en el equipo de grabado de la fotomáscara podría generar esta discrepancia sin que el fabricante de la fotomáscara lo sepa y, de ese modo, una puerta trasera potencialmente conduce a otra. [nota 1]
En términos generales, las largas cadenas de dependencia en la economía tecnológica moderna y altamente especializada y los innumerables puntos de control de procesos con elementos humanos hacen difícil identificar de manera concluyente la responsabilidad en el momento en que se descubre una puerta trasera encubierta.
Incluso las admisiones directas de responsabilidad deben ser examinadas cuidadosamente si la parte que confesa está en deuda con otros intereses poderosos.
Muchos gusanos informáticos , como Sobig y Mydoom , instalan una puerta trasera en el ordenador afectado (generalmente un PC con banda ancha que ejecuta Microsoft Windows y Microsoft Outlook ). Estas puertas traseras parecen instalarse para que los spammers puedan enviar correo electrónico no deseado 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, pretenden ser medidas DRM y, en ese caso, agentes de recopilación de datos , ya que ambos programas subrepticios que instalaron contactaban rutinariamente con servidores centrales.
Un intento sofisticado de colocar una puerta trasera en el kernel de Linux , expuesto en noviembre de 2003, añadió un pequeño y sutil cambio de código al subvertir el sistema de control de revisiones . [16] En este caso, apareció un cambio de dos líneas para verificar los permisos de acceso raíz de una persona que llama a la sys_wait4función, pero debido a que usó asignación =en lugar de 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, más que como un ataque intencionado. [17] [18]
En enero de 2014, se descubrió una puerta trasera en ciertos productos Samsung con Android , como los dispositivos Galaxy. Las versiones de Android propiedad de Samsung están equipadas con una puerta trasera que proporciona acceso remoto a los datos almacenados en el dispositivo. En particular, el software Samsung Android que se encarga de manejar 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 permite al operador de puerta trasera realizarlas a través del módem de forma remota. Operaciones de E/S en el disco duro del dispositivo u otro almacenamiento. Como el módem ejecuta software Android propiedad de Samsung, es probable que ofrezca control remoto inalámbrico que luego podría usarse para emitir los comandos RFS y así acceder al sistema de archivos del dispositivo. [19]
Las puertas traseras más difíciles de detectar implican modificar el 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 el disco o en algún momento durante la compilación, el enlace del ensamblado o la carga; en este último caso, la puerta trasera nunca aparece en el disco, solo en la memoria. Las puertas traseras del código objeto son difíciles de detectar mediante la inspección del código objeto, pero se detectan fácilmente simplemente verificando cambios (diferencias), especialmente en longitud o en suma de verificación, y en algunos casos se pueden detectar o analizar desensamblando el código objeto. Además, las puertas traseras del código objeto se pueden eliminar (suponiendo que el código fuente esté disponible) simplemente recompilando desde el código fuente en un sistema confiable.
Por lo tanto, para que dichas puertas traseras eviten la detección, todas las copias existentes de un binario deben subvertirse, y cualquier suma de verificación de validación también debe verse comprometida, y la fuente no debe estar disponible para evitar la recompilación. Alternativamente, estas otras herramientas (verificaciones de longitud, diferencias, sumas de verificación, desensambladores) pueden verse comprometidas para ocultar la puerta trasera, por ejemplo, detectando que el binario subvertido se está sumando y devolviendo el valor esperado, no el valor real. Para ocultar estas subversiones adicionales, las herramientas también deben ocultar los cambios en sí mismas; por ejemplo, un checksummer subvertido también debe detectar si está sumando él mismo (u otras herramientas subvertidas) y devolver valores falsos. Esto conduce a grandes cambios 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 de código objeto persistente (sin modificar el código fuente) requiere subvertir el propio compilador , de modo que cuando detecte que está compilando el programa bajo ataque, inserta 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 puerta trasera. Esta defensa, a su vez, puede subvertirse colocando una meta puerta trasera en el 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 para el programa original bajo ataque. Una vez hecho esto, se puede eliminar la metapuerta trasera y se puede volver a compilar el compilador desde la fuente original con el ejecutable del compilador comprometido: la puerta trasera se ha iniciado. Este ataque se remonta a 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"; [21] Por eso se le conoce coloquialmente como el ataque "Trusting Trust". Consulte 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 utilizarla a su vez. La noción de puerta trasera asimétrica fue introducida por Adam Young y Moti Yung en Proceedings of Advances in Cryptology – Crypto '96 . Una puerta trasera asimétrica sólo puede ser utilizada por el atacante que la coloca, incluso si la implementación completa de la puerta trasera se hace pública (por ejemplo, mediante publicación, descubrimiento y divulgación mediante ingeniería inversa , etc.). Además, es computacionalmente intratable detectar la presencia de una puerta trasera asimétrica en consultas de caja negra. Esta clase de ataques se ha denominado cleptografía ; se pueden llevar 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 que ahora se llama criptovirología . En particular, 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 OpenSSL RSA, 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 del compilador , donde no sólo se subvierte un compilador (para insertar una puerta trasera en algún otro programa, como un programa de inicio de sesión), sino que se modifica aún más para detectar cuándo se está compilando y luego inserta tanto el código de inserción de puerta trasera (dirigido 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: el exploit ha sido arrancado.
Este ataque fue presentado originalmente en Karger & Schell (1974), [nota 2] , que era un análisis de seguridad de Multics de la Fuerza Aérea de los Estados Unidos , donde describieron dicho ataque a un compilador PL/I y lo llamaron una "trampilla del compilador". ". También mencionan una variante en la que 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 llaman "trampilla de inicialización"; esto ahora se conoce como 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", [21] que señala que la confianza es relativa y que el único software en el que realmente se puede confiar es el código donde 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 hará 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 el programa de inicio de sesión se estaba compilando, y también agregaría esta característica de manera indetectable a futuras versiones del compilador tras su compilación. también. Como el compilador en sí era un programa compilado, era muy poco probable que los usuarios notaran las instrucciones del código de máquina que realizaban estas tareas. (Debido a la segunda tarea, el código fuente del compilador aparecería "limpio"). Lo que es peor, en la implementación de la 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 en el La forma habitual no vería el código real que se estaba ejecutando, sino algo más.
Karger y Schell ofrecieron 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 comentada del código fuente de puerta trasera de Thompson. [27]
La versión de Thompson, oficialmente, nunca fue liberada. 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 sobre este tipo de puertas traseras en los años siguientes.
En agosto de 2009, los laboratorios de 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 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, cada programa compilado por esa instalación de Delphi contendrá el virus. Un ataque que se propaga mediante la creación de su propio caballo de Troya puede resultar especialmente difícil de descubrir. Esto dio lugar a que muchos proveedores de software publicaran ejecutables infectados sin darse cuenta, a veces alegando falsos positivos. Después de todo, el ejecutable no fue manipulado, 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 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 encontró 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; normalmente uno debe reconstruir un sistema limpio y transferir datos (pero no ejecutables) terminado. Sin embargo, se han sugerido varias debilidades prácticas en el esquema Trusting Trust . Por ejemplo, un usuario suficientemente motivado podría revisar minuciosamente el código de máquina del compilador que no es de confianza 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 necesaria ]
Un método genérico para contrarrestar los ataques de confianza se llama doble compilación 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 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 compilador diferente. [26]
En la práctica, tales verificaciones no las realizan los usuarios finales, excepto en circunstancias extremas de detección y análisis de intrusiones, debido a la rareza de ataques tan sofisticados y porque los programas generalmente se distribuyen en forma binaria. La eliminación de puertas traseras (incluidas las puertas traseras del compilador) generalmente se realiza simplemente reconstruyendo un sistema limpio. Sin embargo, las verificaciones sofisticadas son de interés para los proveedores de sistemas operativos, para garantizar que no estén distribuyendo un sistema comprometido y en entornos de alta seguridad, donde dichos ataques son una preocupación realista.
