La seguridad a través de la oscuridad es un principio utilizado para garantizar la seguridad en diversas áreas de la actividad humana. La idea básica es ocultar las partes internas de un sistema o implementación para garantizar la seguridad.
Un sistema que se basa en la "seguridad a través de la oscuridad" puede tener vulnerabilidades existentes o sospechadas , pero sus propietarios o desarrolladores creen que si no se conocen las fallas, un atacante no podrá detectarlas. El sistema también puede utilizar la seguridad a través de la oscuridad como una de las capas de protección del sistema, ya que da tiempo a los desarrolladores del sistema para corregir la vulnerabilidad encontrada, mientras que la divulgación pública de productos y versiones los convierte en el objetivo principal para explotar las vulnerabilidades descubiertas en estos productos y versiones. El primer paso del atacante suele ser la recopilación de información, una tarea que se hace más difícil al utilizar la seguridad a través de la oscuridad.
La literatura oficial existente sobre la seguridad a través de la oscuridad es bastante escasa. Los libros de ingeniería de seguridad se refieren al principio de Kerckhoff de 1883, si es que se refieren a algo.
En el campo del derecho, Peter Swire ha escrito sobre el equilibrio entre "la seguridad a través de la oscuridad es una ilusión" y la visión militar de que "los rumores hunden barcos" y cómo la competencia afecta los incentivos de divulgación.
El principio de seguridad a través de la oscuridad era un lugar común en el trabajo criptográfico en los días en que esencialmente todos los criptógrafos bien informados trabajaban para agencias de inteligencia nacional como la Agencia de Seguridad Nacional . Los criptógrafos ahora suelen trabajar en universidades, donde los investigadores publican muchos o incluso todos sus resultados y prueban públicamente los diseños de otras personas, o en el sector privado, donde los resultados están más controlados por patentes y derechos de autor que por el secreto, por lo que el principio ha perdido parte de su antigua popularidad. Por ejemplo, PGP se publica como código fuente y generalmente se considera (si se usa correctamente) como un criptosistema de grado militar.
Presentamos argumentos a favor del uso del principio. Aunque es una mala idea crear una defensa del sistema que se base únicamente en el principio de seguridad a través de la oscuridad, usar este principio para mantener en secreto algunos detalles del sistema puede ser una táctica inteligente dentro de un sistema de seguridad en capas. Por ejemplo, cuando los creadores descubren una vulnerabilidad del sistema , la seguridad a través de la oscuridad puede ser una barrera temporal para los atacantes hasta que se solucione la vulnerabilidad. En este caso, el propósito de utilizar el principio es reducir en el corto plazo el riesgo de explotar una vulnerabilidad en los componentes principales del sistema.
Considere una red informática que contiene una vulnerabilidad conocida. Al no tener información sobre el dispositivo específico del sistema, un atacante debe decidir si usar esta vulnerabilidad o no. Si un sistema está configurado para detectar esta vulnerabilidad, detectará que está bajo ataque y puede responder, ya sea bloqueando el sistema hasta que los administradores tengan la oportunidad de responder, o monitoreando y rastreando el ataque del atacante, o desconectando al atacante. . La esencia de usar el principio en esta situación es que un atacante no puede obtener rápidamente la información necesaria sobre el sistema para tomar una decisión firme sobre la relación entre el riesgo de ser bloqueado al intentar explotar una vulnerabilidad y la posible recompensa en caso de que de un ataque exitoso. Además, como consecuencia de la falta de información necesaria sobre la estructura del sistema, no puede elegir sin ambigüedad la parte del sistema que necesita ser atacada en primer lugar.
Otra estrategia para usar el principio implica la existencia de una doble capa de vulnerabilidades, las cuales se mantienen en secreto. Al mismo tiempo, los creadores del sistema permiten que una de las vulnerabilidades se “filtre”. La idea es dar al atacante una falsa sensación de certeza de que la defensa ha sido superada y ha ganado. Por ejemplo, se puede utilizar como parte de un cebo (el equivalente ruso del término es "pesca con cebo vivo").
Los argumentos en contra del principio de seguridad a través de la oscuridad se remontan al principio de Kerckhoffs , propuesto en 1883 por Auguste Kerckhoffs . Este principio establece que el diseño de un sistema criptográfico no debe requerir secreto y no debe causar inconvenientes si cae en manos del enemigo. Los desarrolladores deben asumir que los atacantes conocen todo el diseño del sistema de seguridad, con la excepción de las claves criptográficas (la seguridad de un sistema criptográfico reside completamente en la clave criptográfica). En 1940, Claude Shannon formuló este principio como "el enemigo conoce el sistema".
Cuanto mayor sea el número de puntos de posible compromiso contenidos en el sistema, más probable es que exista o se desarrolle una estrategia de ataque sobre uno de estos puntos. Los sistemas que contienen secretos de estructura u operación que también son puntos de posible compromiso son menos seguros que sistemas similares sin esos puntos si el esfuerzo requerido para obtener una vulnerabilidad como resultado de revelar la estructura de un proyecto o el método de operación, así como el esfuerzo para explotar esta vulnerabilidad, requiere menos esfuerzo para obtener la clave secreta. El nivel de seguridad del sistema se reduce al esfuerzo necesario para explotar esta vulnerabilidad.
Por ejemplo, si alguien guarda una llave de repuesto debajo del tapete, en caso de que las puertas estén cerradas desde afuera, entonces está confiando en la seguridad por oscuridad. La vulnerabilidad de seguridad teórica es que alguien podría entrar en la casa abriendo la puerta con esta llave de repuesto. Además, debido a que los ladrones a menudo conocen los escondites previstos, el propietario de la casa correrá un mayor riesgo de robo si oculta la llave, ya que es probable que el esfuerzo requerido para encontrar la llave sea menor que el esfuerzo requerido para forzar la entrada (p. irrumpiendo) de otra manera, como a través de un vidrio. El propietario agregó una vulnerabilidad, el hecho de que la clave de entrada se almacena debajo del tapete, en el sistema, y es muy fácil de adivinar y explotar.
En el pasado, varios algoritmos o sistemas de software con detalles internos ocultos han hecho públicos estos detalles internos. La divulgación accidental se ha producido en varias ocasiones, por ejemplo, en el famoso caso GSM , la documentación confidencial relativa a un cifrado se transfirió a la Universidad de Bradford sin que se impusieran los requisitos habituales de confidencialidad [1] . Además, se descubrieron y explotaron vulnerabilidades en el software incluso cuando los detalles internos permanecieron en secreto. En conjunto, estos y otros ejemplos muestran que es difícil o ineficiente mantener en secreto los detalles de los sistemas y algoritmos.
La seguridad a través de la oscuridad no se reconoce como un enfoque de ingeniería apropiado para la seguridad del sistema, ya que es contrario al principio "KISS" . El Instituto Nacional de Estándares y Tecnología recomienda específicamente usar la seguridad a través de la oscuridad en no más de un documento. Según NIST , "un sistema de seguridad no debería depender del secreto de una implementación o sus componentes" [2] .
Existe un consenso general, incluso entre quienes abogan por la seguridad a través de la oscuridad, de que el principio de "seguridad a través de la oscuridad" nunca debe utilizarse como medida de seguridad principal. Esta es, en el mejor de los casos, una medida secundaria, y la divulgación de la ambigüedad no debería conducir a un compromiso .
El valor de usar el principio al crear software abierto o cerrado es muy diferente y ambiguo. Considere el proceso de creación de software de código abierto. La mayoría de las veces, los desarrolladores están más interesados en crear código nuevo que en analizar el código existente en busca de vulnerabilidades. Dado que la creación de software de código abierto es un esfuerzo voluntario, generalmente se pone menos énfasis en la seguridad que si uno de los deberes de los autores fuera analizar la seguridad del programa. Por otro lado, está la ley de Linus , que establece que "con suficientes ojos, los errores flotan a la superficie", sugiere una mayor seguridad de los algoritmos y protocolos, cuya descripción se publica. Más personas pueden ver los detalles de dichos algoritmos, identificar fallas y corregirlas antes. Los partidarios de este punto de vista creen que la frecuencia y la gravedad de las consecuencias de un compromiso serán menores que para el software propietario o secreto. De todo esto, podemos concluir que en el caso de crear software de código abierto, la seguridad depende directamente de la popularidad del programa, es decir, a mayor popularidad, más voluntarios analizan el código del programa y mayor es la probabilidad de encontrar vulnerabilidades. en eso. Para respaldar esto, daremos un ejemplo de que el código fuente de Linux tiene 0,17 errores por mil líneas de código fuente [3] , mientras que el software comercial cerrado tiene un promedio de 20-30 errores por 1000 líneas de código fuente.
En cuanto al software cerrado, al crearlo, se presta mucha atención al análisis de seguridad del código, lo que aumenta la confiabilidad del sistema. Por otro lado, dado que el número de desarrolladores suele ser menor que en el caso del software de código abierto, la probabilidad de encontrar vulnerabilidades existentes en el programa disminuye. Además, los operadores y desarrolladores/fabricantes de sistemas que confían en la seguridad a través de la oscuridad pueden mantener en secreto el hecho de que se ha encontrado una vulnerabilidad en su sistema para evitar reducir la confianza en sus servicios o productos y, por lo tanto, evitar reducir su competitividad, inculcando así información falsa. confianza en la seguridad de sus productos. Ha habido casos, al menos desde la década de 1960, de una empresa que retrasó el lanzamiento de correcciones y parches, priorizando sus reglas corporativas sobre las preocupaciones o riesgos de los clientes.
El ingeniero de desarrollo Sean O`Neil es conocido como el creador del algoritmo criptográfico bastante flexible EnRUPT . También es conocido en círculos estrechos de criptoanalistas como una persona que participó en descifrar el cifrado secreto en los chips Mifare RFID . Estos chips forman la base de las tarjetas de transporte, los pases electrónicos y otras tarjetas inteligentes sin contacto , que hoy en día se cuentan por miles de millones en todo el mundo.
En julio de 2010, apareció en Internet la noticia de que Sean O'Neill y un grupo de colegas lograron divulgar los códigos fuente de los programas que protegen el conocido servicio de telefonía IP Skype . Más concretamente, consiguieron obtener los códigos fuente de los protocolos de cifrado propietarios del servicio de Skype. En su blog, Sean O'Neill da un enlace al sitio cryptolib.com , donde, según él, se encuentran los códigos recibidos.
Por su propia cuenta, Sean O'Neill y sus compañeros ingenieros inversos han estado lidiando con los problemas de seguridad de Skype durante un largo período de tiempo. Como eran especialistas en el análisis de códigos binarios, pudieron recuperar el programa de los códigos binarios bastante rápido, a pesar de que los programadores de Skype usaron una ofuscación muy intensiva . Precisamente porque los desarrolladores de Skype usaron la ofuscación de manera intensiva, pocas personas lograron restaurar el programa desde códigos binarios antes, y quienes pudieron hacerlo no publicaron los códigos fuente, ya que parecían intimidantes.
Finalmente, Sean O'Neill logró crear un código equivalente que funciona como Skype en todos los modos principales, pero que se escribe sin usar el código de Skype. Aunque la creación del código se hizo de forma privada, a las pocas semanas logró filtrarse a Internet y de inmediato se convirtió en una herramienta para los spammers que enviaban mensajes a través del servicio de mensajería instantánea Skype. Sintiéndose responsable de lo que está sucediendo, Sean O'Neill decidió exponer el secreto principal del protocolo de comunicación de Skype: un algoritmo de extensión ofuscado para el vector de inicialización de cifrado RC4 . Más específicamente, cryptolib.com tiene un programa en C que se puede usar para descifrar el tráfico de servicios entre los clientes de Skype y los supernodos del sistema. A pesar de que se utiliza el método de cifrado de flujo RC4 para cifrar los datos del servicio, no hay claves secretas que deban descifrarse. Lo único que realmente existe es una transformación constante que convierte la información legible en ilegible. El significado de este algoritmo era que ninguna otra persona podía desarrollar aplicaciones compatibles con Skype, porque sin conocer los algoritmos para transferir datos del servicio, es imposible crear tales aplicaciones. Era una defensa de la propiedad exclusiva de Skype de su sistema.
Aunque pirateadas y publicadas, estas acciones no dañan de ninguna manera y no revelan la confidencialidad de los mensajes y archivos que se envían en el servicio de Skype entre usuarios. El hackeo se dirigió únicamente al canal de servicio, a través del cual se transmiten las consultas de búsqueda de los usuarios, sus perfiles, listas de contactos, etc. Este es uno de los ejemplos más claros de cómo incluso las grandes empresas utilizan el principio de "seguridad a través de la oscuridad" en sus productos, y que esta acción puede causar tanto un enorme daño financiero como una disminución en la credibilidad del producto.
Hay muchos ejemplos de seguridad a través de la oscuridad en los productos de Microsoft . Algunos de ellos pueden ser utilizados por administradores de sistemas, otros por desarrolladores de software. Todos ellos están destinados a reducir el riesgo de vulnerabilidad ocultando esta vulnerabilidad. Algunos de ellos pueden no tener un efecto positivo, pero esto no es prueba de que la seguridad a través de la oscuridad no funcione.
Un uso del principio de "seguridad a través de la oscuridad" es la capacidad de ocultar las letras de las unidades en el Explorador de Windows. Este procedimiento se usa a menudo en los laboratorios de computación de las escuelas, cibercafés u otros lugares donde es necesario crear condiciones en las que el usuario pueda usar la computadora, pero no pueda guardar datos en el disco duro. Sin embargo, vale la pena señalar que la mayoría de las aplicaciones aún pueden guardar datos en el disco duro, lo que reduce en gran medida el valor de esta medida de seguridad.
Además, Windows a menudo implementa un método para deshabilitar los recursos de red administrativos compartidos (como C$, Admin$, etc.). La base de la idea es que este procedimiento debería evitar que los intrusos se conecten de forma remota a una computadora. Sin embargo, un atacante con una cuenta de administrador puede conectarse de forma remota a los recursos administrativos. Sin embargo, al igual que con el procedimiento anterior, las organizaciones informan que deshabilitar los recursos administrativos reduce la cantidad de malware en las redes.
La opción Permitir que los operadores del servidor programen trabajos le permite programar trabajos para los usuarios del grupo Operadores del servidor. Pero tenga en cuenta que los operadores de servidores pueden convertirse en administradores de muchas maneras diferentes, por lo que evitar que programen trabajos no es gran cosa. Sin embargo, muchas organizaciones prefieren esta opción porque permite que sus especialistas sean operadores en lugar de administradores, lo que reduce la posibilidad de que los especialistas destruyan el servidor por accidente.
Otro ejemplo es cambiar el nombre de la cuenta de administrador con un identificador relativo ( RID ) de 500 a algo desconocido, lo que a menudo recomiendan los expertos en seguridad, así como algunas pautas de Microsoft. El significado de esta operación es que el atacante no sabrá el nombre de la entrada de administrador real. La desventaja de este método es que la cuenta de administrador siempre tiene un RID de 500 y cualquier usuario puede averiguar el nombre de la cuenta de administrador a partir del RID.
Demos un ejemplo del uso de la ofuscación. La ofuscación es una técnica destinada a ofuscar el código fuente o ejecutable de un programa, cuyo propósito es preservar la operatividad, pero dicho código será difícil de analizar.
La ofuscación se puede aplicar tanto a nivel de algoritmo, como a nivel de código fuente del programa, e incluso a nivel de código ensamblador . Por ejemplo, la generación de código ensamblador ofuscado se puede lograr mediante el uso de compiladores especiales . Dichos compiladores tienden a recrear el código utilizando funciones no documentadas del entorno de tiempo de ejecución del programa. También hay programas especiales diseñados para ofuscar el código: ofuscadores.
Algunos procedimientos para la ofuscación del código del programa:
Ejemplo #1 (En lenguaje C )
Código fuente antes de la ofuscación:
int CONTAR = 100 ; float TASA_DE IMPUESTO = 0.2 ; para ( int i = 0 ; i < CONTAR ; i ++ ) { impuesto [ i ] = orig_price [ i ] * TAX_RATE ; precio [ i ] = precio_origen [ i ] + impuesto [ i ]; }Después de la ofuscación:
for ( int a = 0 ; a < 100 ; a ++ ){ b [ a ] = c [ a ] * 0.2 ; re [ a ] = c [ a ] + b [ a ];}Ejemplo #2 (En Perl )
Código fuente antes de la ofuscación:
mi $filtro ; if ( @pod ) { my ( $buffd , $buffer ) = File::Temp:: tempfile ( UNLINK => 1 ); imprimir $buffd "" ; imprime $buffd @pod o muere "" ; imprime $buffd cierra $buffd o muere "" ; @encontrado = $búfer ; $filtro = 1 ; } salir ; sub is_tainted { my $arg = shift ; mi $ nada = substr ( $arg , 0 , 0 ); # longitud cero local $@ ; # preservar la versión de la persona que llama eval { eval " #" }; devolver longitud ($@) != 0; } sub am_taint_checking { my ( $k , $v ) = cada %ENV ; return está_contaminado ( $v ); }Después de la ofuscación:
sub z109276e1f2 { ( mi $ z4fe8df46b1 = turno ( @_ ) ) ; ( mi $zf6f94df7a7 = substr ( $z4fe8df46b1 , ( 0x1eb9 + 765 - 0x21b6 ) , ( 0 × 0849 + 1465 - 0x0e02 ) )) ) ; locales $ @ ; evaluación { evaluación ( ( "" ) ) ; } ; return ( ( longitud ( $@ ) != ( 0x26d2 + 59 - 0x270d ) ) ); } mi ( $z9e5935eea4 ) ; if ( @ z6a703c020a ) { ( my ( $ z5a5fa8125d , $ zcc158ad3e0 ) = Archivo:: Temp:: archivo temporal ( "" , ( 0x196a + 130 - 0x19eb ) ) ) ; imprimir ( $z5a5fa8125d "" ) ; ( imprimir ( $z5a5fa8125d @z6a703c020a ) o morir ( ( ( ( "" . $zcc158ad3e0 ) . " \ x3a \ x20 " ) . $! ) ) ) ; imprimir ( $z5a5fa8125d "" ) ; ( cerrar ( $ z5a5fa8125d ) o morir ( ( ( ( "" ) ) ) ; ( @ z8374cc586e = $ zcc158ad3e0 ) ; ( $ z9e5935eea4 = ( 0 × 1209 + 1039 - 0 × 1617 ) ) ; } salir ; sub z021c43d5f3 { ( mi ( $z0f1649f7b5 , $z9e1f91fa38 ) = cada uno ( %ENV ) ) ; return ( z109276e1f2 ( $z9e1f91fa38 ) ) ; }Estos son ejemplos de la llamada ofuscación de alto nivel. Si el objetivo es ocultar el código del virus , en la mayoría de los casos se utiliza ofuscación de bajo nivel (usando comandos ensambladores), así como programas de ofuscación automática como Afx!AVSpoffer, EPProt y PETools.
Una variante del principio básico se basa en las características de los programas poco conocidos que, cuando se utilizan, reducen la probabilidad de descubrir vulnerabilidades en ataques aleatorios y automáticos. Este enfoque tiene muchos nombres, siendo el más común "seguridad a través de la minoría". También existen los términos "seguridad por rareza", "seguridad por impopularidad", "seguridad por falta de interés". Este principio se encuentra predominantemente al explicar por qué la cantidad de vulnerabilidades conocidas encontradas en un programa para un amplio segmento de mercado tiende a ser mayor que la relación lineal implícita en la participación de mercado del programa, pero esta participación es un factor en la selección de programas para algunas organizaciones grandes. . El principio de seguridad por minoría puede ser útil para organizaciones que no están sujetas a ataques dirigidos y planean usar el producto a largo plazo. Sin embargo, identificar nuevas vulnerabilidades en un programa líder en el mercado es más difícil que en productos menos conocidos, ya que muchas vulnerabilidades ya han sido identificadas debido a la amplia distribución del programa, por lo que un programa con una gran participación de mercado es más adecuado para las organizaciones. .bajo ataque constante. El problema también se complica por el hecho de que el descubrimiento de nuevas vulnerabilidades en un software oscuro convierte a todos los usuarios de ese software en un objetivo de ataque. Para el software líder en el mercado, la probabilidad de que nuevas vulnerabilidades en ellos puedan convertirse inadvertidamente en un objetivo para los ataques es aún mayor.
En general, el problema está estrechamente relacionado con el principio conocido como "seguridad a través de la diversidad" - la presencia de una amplia gama de programas oscuros, aparentemente más diversos que la oferta del líder del mercado en cualquier tipo de programa, lo que reduce los riesgos de un accidente ataque.
El argumento a favor del principio de seguridad por medio de una minoría es contrario al principio observado en la naturaleza en el escenario depredador-presa. En este escenario, el principio de "un hombre no es un guerrero" contrarresta el principio de "seguridad a través de una minoría". Sin embargo, existen algunas diferencias muy significativas entre, por ejemplo, un león cazando una gacela y el funcionamiento de un sistema automatizado. La mayoría de las víctimas de la piratería de software no son de ninguna manera un objetivo directo para el ataque.
Un tipo de seguridad por principio de minoría es la seguridad por obsolescencia. Este principio, por ejemplo, puede basarse en el uso de protocolos de red heredados (como IPX , no TCP / IP ), lo que reduce la posibilidad de ataques desde Internet .