Curso MIT "Seguridad de sistemas informáticos". Lección 8: Modelo de seguridad de red, parte 3

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3

Público: ¿por qué siempre se incluye un token aleatorio en la URL y no en el cuerpo de la solicitud?

Profesor: HTTPS se usa de esta manera, pero no hay una buena razón para no incluir variables aleatorias en el cuerpo de la solicitud. Es solo que hay algunas formas de herencia que funcionan de esa manera a través de la URL. Pero en la práctica, puede colocar esta información en otro lugar de la solicitud HTTPS, excepto el encabezado.

Sin embargo, tenga en cuenta que simplemente mover esta información al cuerpo de la solicitud es potencialmente inseguro si hay algo allí que el atacante puede adivinar. Entonces el atacante aún puede llamar de alguna manera las URL que necesita. Por ejemplo, cuando hago una solicitud HTTP XML, y luego pongo explícitamente contenido en el cuerpo que el atacante puede adivinar.



Si simplemente configura el marco en la URL, el atacante puede controlarlo. Pero si usa una solicitud XML HTTP y un atacante puede generar una de ellas, la interfaz HTTP XML le permite configurar el cuerpo de la solicitud. Una solicitud HTTP XML está limitada al mismo origen. Sin embargo, si un atacante puede hacer algo como:

<script> var x = “ntrusted”; </script> 

Luego podrá implementar la solicitud HTTP XML, que se ejecutará con la autoridad de la página incrustada.

Todo depende de a qué tenga acceso el atacante. Si puede forzar a la página a ejecutar una secuencia de comandos no verificada, como se muestra arriba, entonces puede usar la propiedad JavaScript llamada HTML interno y obtener todo el contenido HTML de la página. Si un atacante puede o no puede generar una solicitud AJAX, esto es una cosa, si puede o no puede ver el código HTML correcto, esto es otra, y así sucesivamente. En resumen, este token generado aleatoriamente puede prevenir ataques CSRF.

Hay una cosa más a la que debe prestar atención son las direcciones de red. Se relacionan con la parte de nuestra conversación que decía quién no podía comunicarse el atacante a través de una solicitud XML HTTP.

En cuanto a las direcciones de red, la trama puede enviar solicitudes HTTP y HTTPS a (host + puerto) correspondiente a su origen. Tenga en cuenta que la seguridad de la misma política de la misma fuente está muy relacionada con la seguridad de la infraestructura DNS, porque todas las políticas de este tipo se basan en lo que se llama.

Entonces, si puedes controlar lo que me llaman, puedes hacer algunos ataques bastante maliciosos, por ejemplo, un ataque de enlace de DNS. El propósito de este ataque es lanzar un JavaScript controlado por el atacante con la autoridad (o en nombre del) sitio de la víctima, llamémosle victim.com. En este caso, el atacante usa las reglas de la misma política de origen y de alguna manera lanzará el código que escribió con el permiso de otro sitio.

Esto se hace de la siguiente manera. Primero, un atacante registra un nombre de dominio, digamos attacker.com. Es muy simple, solo paga un par de dólares, y sobre la marcha, tienes tu propio nombre de dominio. El atacante también debe configurar el servidor DNS para responder a las solicitudes que vienen en nombre de los objetos ubicados en attacker.com.



Lo segundo que debería suceder es que el usuario debe visitar attacker.com. En particular, debe visitar algún sitio que dependa de este nombre de dominio. Tampoco hay nada complicado en esta parte del ataque.

Vea si puede crear una campaña publicitaria, por ejemplo, ofrecer un iPad gratis. Todos quieren un iPad gratis, aunque no conozco a nadie que haya ganado un iPad gratis. Entonces, al hacer clic en un mensaje de este tipo en un correo electrónico de phishing, ya está en el sitio del atacante. Nada especial, esta parte no es complicada.

Entonces, ¿qué pasará después de eso? El navegador comenzará a generar consultas DNS para attacker.com porque la página que visitó contiene objetos que enlazan con objetos ubicados en attacker.com. Pero el navegador dirá: "¡Nunca antes había visto este dominio, así que permítame enviar una solicitud de DNS para obtener permiso para contactar a attacker.com"!



Y el servidor DNS del atacante responde a esta solicitud, pero su respuesta contiene una vida útil TTL muy corta, lo que evita que la respuesta se almacene en caché. Por lo tanto, el navegador pensará que es válido solo por un período de tiempo muy corto antes de que necesite salir y confirmar esto, lo que en realidad significa prohibir el almacenamiento en caché.

Resulta que tan pronto como el usuario va al dominio del hacker, el servidor DNS del atacante primero devuelve la dirección IP real del servidor web que le proporcionó al usuario un código malicioso. Este código del lado del cliente accede a attacker.com porque la política de origen permite tales solicitudes. El usuario recibe una respuesta, y ahora el sitio web malicioso se ejecuta en el lado del cliente.

Mientras tanto, el atacante va a configurar el servidor DNS, que controla, para vincular el nombre atacker.com y la dirección IP de victim.com. Esto significa que si el navegador del usuario solicita una resolución de nombre de dominio para algo dentro de attacker.com, en realidad obtendrá algún tipo de dirección interna de victim.com.



¿Por qué un DNS atacante puede hacer esto? Debido a que el pirata informático lo configura para esto, y el servidor DNS del intruso no necesita consultar para volver a conectarse con victim.com.

Además, si nuestro sitio quiere obtener un nuevo objeto a través de, digamos, AJAX, considerará que esta solicitud AJAX va a atacker.com en algún lugar externo, pero de hecho esta solicitud AJAX va adentro, a victim.com. Esto es malo, porque ahora tenemos este código en el lado en el que se encuentra la página web de Attacker.com, que en realidad obtiene acceso a los datos de victim.com con una fuente de origen diferente.



En pocas palabras, cuando se ejecuta una secuencia de comandos en el navegador de la víctima debido a la obsolescencia de la respuesta DNS anterior, se realiza una nueva consulta DNS para este dominio que, debido a la prohibición del almacenamiento en caché, se envía al servidor DNS del atacante. Él responde que ahora atacker.com parece tener una nueva dirección IP de algún otro sitio web, y la solicitud va a otro servidor. Y luego, para devolver la información recopilada por el código, el atacante proporciona su dirección IP correcta en una de las siguientes consultas DNS.

Público: ¿No sería más prudente hacer un ataque por el contrario, desde victim.com para obtener todas las cookies del atacante y similares?

Profesor: sí, esa opción también funcionará. Esto le permitirá hacer cosas tan buenas como el escaneo de puertos. Quiero decir, tu enfoque funcionará correctamente. Porque puede, paso a paso, reasignar constantemente atacker.com a varios nombres de computadora y diferentes puertos dentro de la red victim.com. En otras palabras, la página web attacker.com siempre pensará que va a attacker.com y recibe una solicitud AJAX desde allí.

De hecho, cada vez que el servidor DNS se vuelve a conectar con attacker.com, envía solicitudes a alguna otra dirección IP dentro de la red victim.com. De esa manera, él simplemente puede "caminar" a través de las direcciones IP una por una y ver si alguien está respondiendo a estas solicitudes.

Audiencia: pero el usuario que está atacando no necesariamente tiene acceso interno a la red victim.com.

Profesor: como regla general, este ataque es que hay ciertas reglas de firewall que podrían evitar que el sitio externo atacker.com vea las direcciones IP dentro de la red victim.com. Sin embargo, si está dentro de una red corporativa como corp.net detrás de un firewall corporativo, las computadoras a menudo tienen la capacidad de conectarse a máquinas fuera de su red.

Audiencia: ¿Funciona este método de ataque a través de HTTPS?

Profesor: esta es una pregunta interesante! El hecho es que HTTPS usa claves. Si usa HTTPS, cuando envíe una solicitud AJAX, la máquina de la víctima no tendrá las claves HTTPS del atacante, y la verificación del cifrado en victim.com mostrará que la clave no coincide. Por lo tanto, creo que HTTPS descarta la posibilidad de este tipo de ataque.

Audiencia: ¿qué pasa si la víctima usa solo HTTPS?

Profesor: Creo que esto detendrá al atacante.

Audiencia: ¿por qué un atacante responde principalmente a la computadora de la víctima con su dirección IP?

Profesor: porque el atacante de alguna manera debe ejecutar su propio código en la máquina de la víctima antes de que pueda tomar más medidas para encontrar algo dentro de la red de la víctima. Pero no perdamos el tiempo, por lo tanto, si tiene preguntas sobre la reasignación de DNS, acuda a mí después de la conferencia.

Entonces, ¿cómo puedes arreglar esto? Una forma de corregir esta vulnerabilidad es modificar la resolución del cliente DNS para que los nombres de host externos nunca tengan acceso a las direcciones IP internas.

Es un poco estúpido que alguien fuera de su red pueda crear un DNS que esté vinculado a algo dentro de su red. Esta es la solución más simple.



Puede imaginar que el navegador puede hacer algo llamado "fijación de DNS" o fijación de DNS. Como resultado, si el navegador recibe un registro de DNS resuelto, siempre considerará este registro aceptable, por ejemplo, para la interacción dentro de los 30 minutos, independientemente de qué TTL asigne el atacante, y de esta manera puede resistir el ataque.
Esta solución es un poco complicada, porque hay sitios que intencionalmente usan DNS dinámico para cosas como balancear la carga del servidor y similares. Por lo tanto, la primera solución con fijación de DNS es la mejor opción.

Y ahora veremos qué protege la misma política de origen. ¿Qué hay de los píxeles? ¿Cómo protege la política de origen los píxeles?

Al final resultó que, los píxeles en realidad no tienen origen. Por lo tanto, cada cuadro tiene su propio cuadro delimitador, básicamente solo un cuadrado, y el cuadro puede dibujar en cualquier lugar dentro de esa área.

Esto es realmente un problema porque significa que el marco principal puede dibujar encima del marco secundario. Y esto, a su vez, puede conducir a ataques muy insidiosos.

Digamos que un atacante crea una página que dice: "haga clic aquí para ganar un iPad". El mismo truco estándar. Este es el marco principal.



Y este marco principal puede crear un marco secundario, que en realidad es el marco del botón Me gusta en un sitio de Facebook. Por lo tanto, Facebook le permite ejecutar este pequeño fragmento de código de Facebook que puede poner en su página.

Usted sabe que si un usuario hace clic en "me gusta", significa que irá a Facebook y dirá: "¡Hola, me gusta esta página en particular"! Entonces, ahora tenemos este marco secundario del botón Me gusta.



Ahora, un atacante puede superponer este marco en el área de la pantalla en la que el usuario debe hacer clic para obtener un iPad gratis, y también hacer que este marco sea invisible, CSS lo permite.

Entonces, ¿qué pasará? Como ya instalamos, todos quieren obtener un iPad gratis. El usuario va a ir a este sitio haciendo clic en esta área de la pantalla, asegurándose de hacer clic exactamente en lo que le dará el iPad gratis. Pero, de hecho, hace clic en el botón invisible Me gusta. Es como superponer sobre el índice C.

Esto significa que ahora, tal vez, el usuario termina en un perfil de Facebook, donde observa que le gustó attacker.com. Sabes, él ni siquiera recordará cómo sucedió. Entonces esto es en realidad lo que se llama un ataque de jacking de clic: soporte para un ataque de clic. De la misma manera, puede hacer muchas cosas malas: robar contraseñas, obtener datos personales, en resumen, esto es una locura. Enfatizo: esto es posible debido al hecho de que el marco principal puede dibujar cualquier cosa dentro de este cuadro delimitador.

Por lo tanto, el marco principal es lo que ve en la página, la llamada para obtener una tableta gratuita, y el marco secundario es el botón Me gusta, que se superpone de forma transparente en el marco principal.

Hay varias soluciones a este problema. El primero es usar el código de ruptura de trama. De esa manera, puede usar expresiones de JavaScript para averiguar si alguien ha incrustado su propio marco en su marco. Por ejemplo, una de estas pruebas es una comparación de la siguiente forma: if (self! = Top).

Aquí, la declaración propia se refiere a la parte superior del cuadro superior, que se compara con la jerarquía de todo el cuadro. Por lo tanto, si hace esta prueba y descubre que uno mismo no es igual a la parte superior del marco principal, entonces comprenderá que tiene un marco secundario. En este caso, puede negarse a descargarlo.

Esto sucede si intenta crear un marco, por ejemplo, para CNN.com. Si observa el código fuente de JavaScript, puede ver que realiza esta prueba porque CNN.com no quiere que otras personas usen su contenido. Por lo tanto, este marco siempre ocupa la posición más alta. Entonces, esta es una de las soluciones que se pueden usar aquí.

La segunda solución es que su servidor web envíe un encabezado HTTP llamado opciones x-Frame en respuesta. Por lo tanto, cuando el servidor web devuelve una respuesta, puede establecer este encabezado, que dirá: "¡Hola, navegador, no dejes que nadie ponga mi contenido dentro del marco!". Esta solución permite al navegador realizar acciones de cumplimiento.

Entonces es bastante simple. Pero todavía hay muchos otros ataques locos que puedes organizar.

Como mencioné anteriormente, el hecho de que ahora vivamos en Internet internacional crea problemas al usar un dominio o nombre de host.

Supongamos que tenemos la letra C. ¿Pero en qué idioma? ¿De qué alfabeto es esta letra del latín ASCII o es C en cirílico? Esto le permite organizar ataques que utilizan diferentes interpretaciones y el uso de letras diferentes, pero aparentemente similares. Por ejemplo, un atacante registrará un nombre de dominio cats.com. Y los usuarios irán a este dominio, pensando que visitarán el sitio "cats.com", pero en realidad llegarán al sitio del atacante "sats.com", porque la primera letra aquí no es latina, sino cirílica.

Un atacante puede registrar el dominio fcebook.com, pero las personas no están atentas, lo tomarán como facebook.com e irán allí. Entonces, si controlas Facebook.com, recibirás una gran cantidad de tráfico de personas que piensan que han iniciado sesión en Facebook.



Hay un montón de diferentes y extraños ataques que puedes lanzar a través del sistema de registro de nombres de dominio contra los que es difícil defenderse, porque ¿cómo puedes evitar que los usuarios cometan errores tipográficos? ¿O cómo le indica el navegador al usuario: "Oye, esto es cirílico, no latino"?

Si el navegador advierte al usuario cada vez que se encienden las fuentes cirílicas, molestará a las personas que realmente usan cirílico como fuente nativa. Por lo tanto, no está del todo claro cómo se pueden resolver estos problemas desde un punto de vista técnico, por lo que aquí surgen problemas de seguridad muy delicados.

Otra cosa interesante son los complementos. ¿Cómo interactúan los complementos con las políticas de origen? Los complementos a menudo tienen incompatibilidad con el resto del navegador con respecto a la misma fuente de origen. Por ejemplo, si observa el complemento de Java, se supone que los diferentes nombres de host que tienen la misma dirección IP también tienen el mismo origen.

De hecho, esta es una desviación bastante grande de la interpretación estándar de las políticas del mismo origen. Este enfoque significa que si tiene algo como xycom y zycom y se proyectan en la misma dirección IP, Java asumirá que tienen la misma fuente de origen. Esto puede ser un problema, ya que en realidad un sitio tiene una fuente de origen confiable y el otro no. Hay muchas otras dificultades asociadas con los complementos, que puede encontrar en fuentes disponibles públicamente en Internet o en las notas de la conferencia.

Lo último que quiero discutir es un ataque para compartir pantalla o un ataque para compartir pantalla.

HTML5 en realidad define una nueva API mediante la cual una página web puede compartir todos sus bits para compartir con otro navegador o servidor. Esto parece una idea realmente genial, porque permite que varios usuarios trabajen simultáneamente en el mismo documento. Esto es genial porque vivimos en el futuro.

¡Pero lo más divertido es que cuando desarrollaron esta nueva API, no pensaron en absoluto en una política de fuente común!

Supongamos que tiene una página en la que se encuentran varios marcos, y cada uno de ellos tiene derecho a tomar una captura de pantalla de todo su monitor. Puede tomar una captura de pantalla de todos los marcos ubicados en la pantalla y todo el contenido, independientemente de las fuentes de donde provengan.



Entonces, de hecho, este es un defecto bastante destructivo en la política de la misma fuente de origen, por lo que debería considerar solucionarlo. Por ejemplo, si una persona del cuadro derecho tiene la capacidad de tomar capturas de pantalla, podrá tomar una captura de pantalla solo del cuadro correcto, y no de la pantalla completa en su conjunto.

¿Por qué los desarrolladores del navegador no lo implementaron de esta manera? Debido a que están experimentando presión competitiva y se ven obligados a concentrar sus esfuerzos en desarrollar más y más funciones nuevas, nuevas características, en lugar de prestar atención a mejorar las cosas ya desarrolladas.

Muchas de las preguntas que los estudiantes hicieron en Internet sobre esta conferencia fueron: “¿Por qué los desarrolladores no hicieron lo que podían hacer? ¿No está claro? o: “Parece que este esquema en particular está muerto. ¿No sería mejor el otro? Y así sucesivamente.

Te diré honestamente: sí, eso es seguro, casi todo sería mejor si los desarrolladores lo tomaran de manera responsable. Así que me da vergüenza que estoy conectado con esto.

Pero el hecho es que esto es lo que teníamos antes. Si observa todos los elementos que existían antes, verá que los navegadores web se están desarrollando y las personas se han preocupado un poco más por la seguridad. Pero no en el caso de compartir pantalla, donde los desarrolladores estaban tan preocupados por las capacidades innovadoras del navegador que olvidaron por completo la posibilidad de una fuga.



Por lo tanto, le pido que siempre preste atención a las cosas que discutimos hoy. Imagínese si comenzáramos desde cero, destruyéramos todo lo que teníamos ante nosotros y tratáramos de elaborar una mejor política de seguridad, ¿qué piensa, cuántos sitios funcionarían para nosotros? Creo que no más del 2%. Por lo tanto, los usuarios probablemente se quejarían de nosotros.

Hay otra propiedad interesante relacionada con la seguridad.Una vez que asigna una función a los usuarios, es muy difícil recuperarla, incluso si no es seguro usarla. Por lo tanto, hoy discutimos muchas cosas relacionadas con la política de origen, y continuaremos hablando de esto en la próxima conferencia.


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?