Proteger un sistema desplegado en un entorno "hostil"

https://stackoverflow.com/questions/4868170

28-10-2019
|

Pregunta

En mi empresa estamos desarrollando un sistema grande, compuesto por varios servidores. El sistema se compone de aproximadamente 5 componentes lógicos. Los datos se almacenan en XMLS, MS SQL y SQLite. Es un sistema .NET (principalmente), los componentes se comunican usando WCF y algunos UDP personalizados. Los clientes acceden al sistema principalmente a través del UDP o web personalizado (ASP.NET y Silverlight).

Proteger la comunicación es fácil, algunos SSL y cierta seguridad en el WCF y terminamos.

El principal problema que enfrentamos es que el sistema debe implementarse en el sitio de un cliente, un cliente en el que no necesariamente confiamos. Necesitamos defender los datos en los servidores y el software en sí mismo de la ingeniería inversa. Ambos son de manera crucial para nosotros.

También necesitamos un interruptor de asesinato, me gustaría algo que destruya los datos y el software, al mando o si no pueda llamar a casa por un cierto período de tiempo.

La dirección en la que estaba pensando es usar TPM, o algo similar: una solución de cifrado de hardware, en combinación con otro servicio que podríamos mantener internamente para cifrar todo el software y los datos en los servidores, para que las clave provengan de nuestro servidor Safamente en nuestro sitio, y tal vez la cortina de memoria del TPM.

¿Cómo sugiere resolver tal problema?

ACTUALIZAR 04/02 Estoy buscando sugerencias prácticas o consejo sobre productos que puedan ayudarme, así que estoy comenzando una recompensa ...

Miren, muchachos, estamos básicamente poniendo nuestra máquina en el sitio del cliente (por razones comerciales y practiciales), somos dueños de esa máquina, y el cliente recibe todo lo que está pagando en cuestión de horas, y puede hacer con los datos lo que quiera. Pero yo los algoritmos que se ejecutan en esa máquina, y algunos de los datos almacenados allí son nuestros secretos comerciales que queremos proteger. Idealmente, me gustaría que la máquina no funcione ni siquiera arrancar si no digo que está bien, y sin mi OK para que todo en la máquina permanezca encriptado. La cortina de memoria también parece una buena manera de proteger la máquina mientras se ejecuta.

También idealmente me gustaría que los HD y el almacenamiento en todas las máquinas exploten tan pronto como alguien se acerque a ellos con un destornillador ... :-) Pero creo que eso lo llevaría demasiado lejos ...

ACTUALIZAR 10/02 OK Después de investigar un poco, creo que vamos a probar algo en la misma dirección que el sistema de cifrado PS3, excepto que vamos a traer las claves para descifrar el software y los datos de nuestros servidores. Al hacerlo, podemos decidir sobre nuestras máquinas si confiamos en el servidor que solicita las claves, podemos obtener un interruptor de asesinato simplemente volviendo a colocar la máquina. Esto probablemente se basa en TPM o algo similar, tal vez el txt de Intel ... también estoy realmente interesado en la cortina de memoria como una característica de seguridad importante ...

Por cierto, no podemos resolver esto moviendo las valiosas partes de nuestro sistema a nuestro sitio, tanto por requisitos comerciales como porque no es tecnológicamente factible, necesitaríamos un gran ancho de banda ...

Solución

Lo que estás pidiendo, en efecto, es el Santo Grial. Esto es más o menos equivalente a lo que se hace para las consolas de juegos, donde tienes una plataforma confiable que se ejecuta en un entorno no confiable.

Considere si puede tratar la máquina como comprometida desde el día 1. Si puede trabajar bajo esa suposición, entonces las cosas se vuelven considerablemente más fáciles para usted, pero eso no suena terriblemente viable aquí.

En términos de asegurarlo realmente, hay algunas preocupaciones:

Debe cifrar el sistema de archivos y usar el descifrado de hardware
Debe aislar sus aplicaciones entre sí, para que los problemas de seguridad en uno no comprometan a los demás.
Debe planificar que ocurran problemas de seguridad, lo que significa colocar estrategias de mitigación como un hipervisor seguro en su lugar

Sé que estos son bastante vagos, pero esta es realmente la historia de las protecciones de la consola de juegos en los últimos años, si tienes curiosidad sobre cómo esto se ha resuelto (y roto) una y otra vez, mira a los fabricantes de la consola .

Nunca se ha hecho completamente con éxito, pero puede elevar significativamente la barrera de entrada.

Otros consejos

... Para ser honesto, parece que está preguntando cómo escribir un virus en su aplicación, lo que me hace pensar que su cliente probablemente tiene más razones para no confiar en usted que al revés.

Dicho esto, esta es una idea terrible por varias razones:

¿Qué sucede si su conexión a Internet muere o mueven oficinas y desconectan la máquina por un momento?
¿Qué pasa si lo codifica mal y fallan? ¿Eliminar datos incluso si el cliente los está utilizando correctamente?
Solo puedo asumir que su solicitud implica que su aplicación no ofrece capacidades de respaldo. ¿Estoy en lo correcto? Suena exactamente como un producto que no compraría.
¿Qué tan valiosos son los datos que administra su aplicación? Si se elimina, ¿en qué tipo de pérdidas financieras darían esto para el cliente? ¿Su departamento legal ha firmado esto y verificado que no puede ser considerado responsable?

Esta pregunta se hace en el así 2-3 veces a la semana, y la respuesta siempre es la misma: lo que le haya dado al usuario ya no es suyo.

Puede dificultar que el usuario llegue a los datos, pero no puede evitar que llegue por completo. Puede cifrar los datos, puede mantener la clave de descifrado en USB CryptOtoken (que no expone la clave secreta), pero en teoría si el código puede llamar a Cryptotoken y pedirle que descifra la parte de los datos, entonces el hacker puede duplicar Su código (en teoría) y haga que este código llame a CryptOtoken para descifrar todos los datos.

Prácticamente la tarea puede ser lo suficientemente complicada como para que sea inviable obtener los datos. En este punto, debe verificar lo importante que realmente son los datos descifrados para el usuario.

Acerca de Kill Switch: Esto no funciona. Nunca. El usuario puede hacer una copia y restaurarla desde la copia de seguridad si es necesario. Puede cambiar el reloj de la computadora. Probablemente incluso pueda reducir la velocidad del reloj de la computadora (si los datos son tan valiosos que es factible invertir en hardware de emulación personalizado).

Sobre datos críticos: A veces resulta que su activo valioso es realmente de poco valor para cualquier otra persona [y algún otro aspecto de su solución es]. Ejemplo: enviamos código fuente de nuestros productos de controladores. Es el activo más valioso para nosotros, pero los usuarios no pagan por líneas de código, sino por soporte, actualizaciones y otros beneficios. El usuario no podrá usar de manera efectiva el código fuente [robado] sin invertir la suma, comparable al costo de nuestra licencia.

Sobre la ofuscación: La virtualización de las piezas de código (por ejemplo, el producto VMProtect) parece ser bastante efectiva, sin embargo, también se puede pasar por alto con cierto esfuerzo.

En general, puedo pensar en algún hardware personalizado con sistema operativo personalizado, sellado como una máquina de efectivo (para que el cliente no pueda entrar sin romper el sello), con inspecciones regulares, etc. Esto podría funcionar. Por lo tanto, la tarea no es solo técnica sino en su mayoría organizacional: deberá organizar inspecciones regulares de la máquina, etc.

Para resumir: Si los datos son que valioso, manténgalo en sus servidores y ofrezca solo conexión a Internet. De lo contrario, solo puede minimizar los riesgos, no evitarlos por completo.

Como dijeron todos los demás, no hay bala mágica. El usuario podría apagar la máquina, obtener el HD como esclavo en otra máquina, hacer una copia de seguridad de todo, revertir el motor su código y luego romperlo con éxito. Una vez que el usuario tiene acceso físico al ejecutable, está potencialmente comprometido y no hay nada que hacer para detenerlo en el 100% de los casos.

Lo mejor que puede hacer es hacer que el trabajo de una galleta potencial sea difícil como el infierno, pero no importa lo que haga, no sería inquebrantable.

Usar una autodestrucción en caso de algo mal puede ser trabajado por una galleta que respalda todo.

El uso de una llave en un controlador USB ayuda a dificultar la vida de la galleta, pero puede ser derrotada en última instancia por una galleta determinada competente: el código que no entrelazan las cosas no pueden estar en un estado encriptado (incluida la parte que obtiene la clave), por lo que Es el gran punto débil. Hackear esa parte del código para salvar la clave en otro lugar derrota a la clave.

Si el software hace autenticación en un servidor remoto, esto se puede trabajar atacando al cliente y circulando la autenticación. Si obtiene una clave del servidor, el olfateo de la red podría usarse para interceptar los datos del servidor que contienen la clave. Si los datos del servidor están encriptados, la galleta puede desencadenarlo analizando el software que los no ciencia y pesca los datos sin cifrar.

En especial, todo sería mucho más fácil para una galleta si usa un emulador para ejecutar su software que sea capaz de guardar instantáneas de la memoria (incluida una versión incrustada del algoritmo). Aún más fácil si puede manipular y fijar la memoria directamente mientras ejecuta su software.

Si no espera que su cliente no confiable esté muy decidido, puede complicar las cosas y esperar que nunca obtengan la energía y la habilidad suficientes para que Worthing lo rompa.

La mejor solución, en mi opinión, es obtener todo el software en su servidor de confianza, y hacer que su servidor solo solicite a su servidor que haga el trabajo y mantenga sus algoritmos en su servidor. Esto es mucho más seguro y más simple que todo lo demás, porque elimina el problema fundamental: el usuario ya no tiene acceso físico al algoritmo. Realmente, realmente debe pensar en una forma de hacerlo eliminando sus necesidades para mantener el código en el cliente. Sin embargo, incluso esto no es inquebrantable, un hacker puede deducir lo que hace el algoritmo analizando cuál es la salida en función de la entrada. En la mayoría de los escenarios (no parece que este sea su caso), el algoritmo no es el más importante en el sistema, sino que los datos son.

Entonces, si realmente no puede evitar ejecutar el algoritmo en la parte no confiable, no puede hacer mucho más de lo que ya dijo que hizo: cifrar todo (preferencialmente en el hardware), autenticar y verificar todo, destruir datos importantes antes de alguien Piensa en hacer una copia de seguridad si sospecha que algo está mal, y hace que sea difícil para que alguien lo rompa.

Pero, si realmente quieres algunas ideas y realmente quieres hacer esto, aquí vamos:

Podría sugerirle que haga su programa mutante. Es decir: Cuando descifra tu código, cifre con una llave diferente y tira la llave antigua. Obtenga una nueva clave del servidor y afirme que la clave está codificada de una manera que sería muy difícil burlarse del servidor con algo que proporciona nuevas claves comprometidas. Haga una garantía de que la clave es única y nunca se reutiliza. Una vez más, esto no es inquebrantable (y lo primero que haría una galleta es atacar esta misma característica).

Una cosa más: poner muchas arenques rojas no obvios que realizan verificaciones de consistencia extrañas sin sentido, que mucha versión falsa no funcional de su algoritmo y agregan una gran cantidad de exageración compleja que efectivamente no hace nada y afirma que ejecuta que ejecuta que ejecuta como se esperaba del código real. Haga que el código real haga algunas cosas que se ven extrañas y sin sentido también. Esto hace que la depuración y la participación inversa sean aún más difíciles, porque la galleta necesitará mucho esfuerzo tratando de separar lo que es útil de lo que es basura.

EDITAR: Y obviamente, haga que una parte del código de basura se vea mejor que el correcto, por lo que una galleta se vería allí en primer lugar, perdiendo el tiempo y la paciencia. No hace falta decir que ofuscan todo, por lo que incluso si la galleta obtiene el código de ejecución sin cifrar sin cifrar, todavía se ve confuso y muy extraño.

Sé que otros probablemente empujarán agujeros en esta solución, y no duden en hacerlo mientras hago este tipo de cosas para vivir y agradecería el desafío. - Pero por qué no hacer esto:

Dado que claramente está utilizando Windows, habilite la protección de la unidad de bloqueador de bits en el disco duro con la configuración de seguridad MAX. Esto ayudará a mitigar a las personas que clonan el impulso como mi entendimiento: si estoy equivocado, ¡dígalo! - ¿Su contenido se encriptará en función de esa configuración de hardware de sistemas?
Habilite TPM en el hardware y configúrelo correctamente para su software. Esto ayudará a detener el olfateo de hardware.
Deshabilite las cuentas que usted no utiliza y bloquee las cuentas y grupos del sistema para usar solo lo que necesita. Puntos de bonificación para configurar Active Directory y una VPN segura para que pueda acceder a su red de forma remota a través de una puerta trasera para verificar el sistema sin hacer una visita oficial en el sitio.
Para aumentar la barra técnica requerida para entrar en esto, escriba el software en C ++ o en algún otro idioma que no sea .Net, ya que el código de byte MSIL es fácilmente descompilable en el código fuente por herramientas gratuitas disponibles públicamente y se necesita más habilidad técnica para descompilar Algo en el ensamblaje incluso si todavía es muy factible con las herramientas adecuadas. Asegúrese de habilitar todas las instrucciones de CPU para el hardware que usará, para complicar aún más las cosas.
Haga que su software valida el perfil de hardware (ID de hardware únicos) del sistema implementado de vez en cuando. Si esto falla (como en el hardware ha cambiado), tenga la autodestrucción.
Una vez que el hardware ha sido validado, cargue su software desde una imagen binaria cifrada cargada en un disco RAM encriptado que luego se descripe en la memoria (¡no pintada!). No lo fije, ni use una dirección de memoria constante, ya que es una mala idea.
Tenga mucho cuidado de que una vez que se realice el descifrado, las claves se eliminan de la RAM, ya que algunos compiladores optimizarán estúpidamente las llamadas BZERO/MEMSET0 no aseguradas y dejarán su clave en la memoria.
Recuerde que las claves de seguridad se pueden detectar en la memoria por su aleatoriedad en relación con otros bloques de memoria. Para ayudar a mitigar esto, asegúrese de usar múltiples teclas "ficticias" que si se usan, active un escenario de detección de intrusos y explote. Dado que no debe estar fijando la memoria utilizada por las teclas, esto permitirá a las personas activar las mismas teclas ficticias varias veces. Puntos de bonificación Si puede tener todas las teclas ficticias generadas aleatoriamente, y la clave real diferente cada vez debido al #12 a continuación, para que no puedan simplemente buscar la clave que no cambia ... porque todos lo hacen.
Utilice el código de ensamblaje polimórfico. Recuerde que el ensamblaje es realmente solo números que se pueden modificar a sí mismo en función de las instrucciones y el estado de la pila/lo que se llamaba antes. Por ejemplo, en un sistema I386 simple 0x0f97 (establecer el byte si arriba) puede ser fácilmente la instrucción opuesta (establecer byte si a continuación) simplemente restando 5. Use sus claves para inicializar la pila y aprovechar el caché L1/L2 de la CPU si realmente usted realmente quiero ir duro.
Asegúrese de que su sistema comprenda la fecha/hora actual y valida la fecha/hora actual está dentro de los rangos aceptables. Comenzar el día antes de la implementación y darle un límite de 4 años sería compatible con la curva de campana de falla de hardware para discos duros bajo garantía/soporte para que pueda aprovechar dicha protección y permitirle un buen tiempo entre las actualizaciones de hardware. Al fracasar en esta validación, haz que se mate.
Puede ayudar a mitigar a las personas que se atornillan con el reloj asegurándose de que su archivo PID se actualice con la hora actual de vez en cuando; Comparar su último tiempo modificado (ya que tanto los datos encriptados como los atributos de sus archivos en el sistema de archivos) con la hora actual serán un sistema de alerta temprana para si las personas se han jodido con el reloj. En el problema detectado, explote.
Todos los archivos de datos deben estar encriptados con una clave que se actualice en su comando. Establezca su sistema para actualizarlo al menos una vez por semana y en cada reinicio. Agregue esto a la función de actualización del software de su servidor que debe tener.
Toda la criptografía debe seguir las pautas de FIPS. Por lo tanto, use criptográfico fuerte, use HMAC, etc. Debe intentar golpear las especificaciones FIPS-140-2-Level-4 dada su situación actual, pero comprensiblemente algunos de los requisitos pueden no ser factibles desde un punto de vista económico y de manera realista, FIPS-140 -2 nivel-2 puede ser tu límite.
En todos los casos de autodestrucción, póngase a su teléfono a casa para que sepa inmediatamente lo que sucedió.

Y finalmente algunas soluciones que no son de software:

Si no puede llamar a la casa a casa. Como último esfuerzo de zanja, un dispositivo de hardware personalizado conectado a un puerto de serie/USB interno que está configurado para activar un relé que luego establece un bloque de termita si detecta casos, hardware o modificación de software. . Ponerlo encima de los discos duros y colocarlos sobre la placa base hará el mejor trabajo. Sin embargo, deberá consultar con su departamento legal para los permisos, etc. requerido si esta no es una situación militar aprobada por los Estados Unidos, ya que supongo que está en los Estados Unidos.
Para asegurarse de que el hardware no esté manipulado, consulte los requisitos de seguridad física de FIPS para obtener más detalles sobre cómo asegurarse de que el sistema esté físicamente seguro. Puntos de bonificación si si puede ver sobre atornillar/soldar los bastidores modernos que está utilizando en una vieja caja AS400 como camuflaje para ayudar a mitigar el movimiento/manipulación del hardware. Los chicos más jóvenes no sabrán qué hacer y se preocuparán por romper "chupar cosas viejas", los chicos mayores se preguntarán "¿WTF?", Y la mayoría de los que todos dejarán sangre que se puede usar más tarde como evidencia de manipulación si se manipulan a menudo Estuche con bordes afilados, al menos en función de mi propia experiencia.
En el caso de una notificación de intrusión, lo discuera de la órbita. Es la única forma de estar seguro. ;) Solo asegúrese de tener todos los formularios y requisitos legales para el acceso completado, por lo que legal está contento con la mitigación del riesgo o la responsabilidad ... o puede configurar su sistema de notificación para enviar un correo electrónico/enviar mensajes de texto a las personas automáticamente una vez que obtenga un Notificación diciéndole que explotó.

"La única forma de tener un sistema totalmente seguro es aplastarlo con un martillo"

Dicho esto, es posible atornillar a los posibles piratas informáticos lo suficiente como para hacerlo más problemas de lo que vale. Si la máquina es una 'caja negra' en la que realmente no puede acceder a ella directamente, sino que tienen programas que se ocupan de ella, entonces su mayor amenaza para ella es el acceso físico. Puede bloquear las cajas e incluso instalar un artículo pequeño y rompible en el estuche que se rompa si se abre el estuche ... asegúrese de que las personas de su servicio siempre reemplace este artículo ... le informará si alguien ha abierto Sin autorización (sí, es un viejo truco para adolescentes, pero funciona). En cuanto a la caja en sí, deshabilite físicamente cualquier bits de hardware (como puertos USB) que no necesita absolutamente.

Si está tratando con una máquina que no es una caja negra, cifre el infierno de todo ... El cifrado de 256 bits es efectivamente imposible de romper sin la clave ... entonces el truco se convierte en la clave.

En teoría, potencialmente podrías tener la clave cambio (volviendo a entrenar los datos) y solo ser recuperable por un proceso que se comunique directamente con sus servidores (seguros).

Además, rastree todo lo que le sucede a la caja, especialmente cualquier cosa que ocurra en el software que está fuera del uso normal. Gran parte de esto no puede protegerte de alguien que está realmente muy decidido ... pero pueden Alertarlo de que su sistema se haya comprometido. (sobre el cual puedes demandar a los que se rompieron)

En cuanto al interruptor de matar ... bueno, los virus durmientes están ahí afuera, pero como se ha dicho, pueden ser engañados o partidos por accidente. Sugeriría que, en lugar de limpiarse, si sospecha una violación, hará que el sistema cifre todo lo que pueda con una clave generada al azar, envíe la clave a sus servidores (para que pueda deshacer el daño) y luego 'triturar' la Archivo que solía contener la clave. (Muchos trituradores de archivos pueden destruir los datos lo suficientemente bien como para que sea (casi) imposible recuperar).

Resumiendo las respuestas, sí. No hay soluciones 'perfectamente seguras' para este problema, ya que necesitaría cifrado homomórfico (que ahora existen ahora solo en forma de prototipos limitados que requieren cantidades ridículas de cálculo).

En la práctica, lo que necesita es la combinación de ingeniería de requisitos y ingeniería de seguridad adecuada (evalúe a las partes interesadas, intereses, activos valiosos dentro del sistema desplegado, posibles ataques y daños de cada escenario de ataque exitoso frente a los costos para defenderse de él).

Después de eso, verá que la protección no es realmente necesaria, o puede implementar algunas medidas razonables y cubrir otros 'agujeros' con cosas legales, o volver a diseñar el sistema por completo, comenzando con el modelo de negocio (poco probable, pero posible, también).

En general, la seguridad es el problema de ingeniería de sistemas, y no debe limitarse solo a los enfoques técnicos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow