Curso MIT "Seguridad de sistemas informáticos". Lección 13: Protocolos de red, parte 2

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
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3
Lección 10: “Ejecución simbólica” Parte 1 / Parte 2 / Parte 3
Lección 11: "Ur / Lenguaje de programación web" Parte 1 / Parte 2 / Parte 3
Lección 12: Seguridad de red Parte 1 / Parte 2 / Parte 3
Lección 13: "Protocolos de red" Parte 1 / Parte 2 / Parte 3

Estudiante: el cliente no puede descifrar este ticket porque está cifrado con la clave de servicio.

Profesor: sí, eso es realmente inteligente, ¿no? Tenemos la clave Kc, s que el cliente puede recibir, pero aquí, en el ticket Tc, s, hay otra copia de esta clave, encriptada con Ks.



La razón por la que se hace esto es porque el servidor Kerberos realmente está tratando de asegurar la comunicación del cliente con el otro tipo. Por lo tanto, Kerberos crea una clave aleatoria Kc, sy le da una copia al cliente y otra al servidor con el que el cliente va a hablar. Imagine que Kerberos simplemente llamaría al servicio con las palabras: "oye, servicio, este tipo quiere hablar contigo, ¡esta es la clave para esto!" Esto sería lamentable porque el servidor Kerberos accedería al servicio una y otra vez en cada solicitud. Entonces, KDS crea 2 copias de la clave de sesión: una para el cliente y la otra para TGS.

Por lo tanto, en cambio, a los desarrolladores se les ocurrió un buen truco, donde le proporcionan al cliente este boleto, y él no puede hacer nada con él excepto contactarlo con el servicio adecuado. Y si este servicio tiene la clave Ks correcta, la descifrará y dirá: "Sí, esta es la misma clave que debo usar para hablar con este cliente". Por lo tanto, ambos participantes en la conexión, el cliente y el servicio, establecerán una clave común para proteger su conexión.

Estudiante: entonces, ¿qué es TGS?

Profesor: Hay dos puntos de vista sobre lo que es TGS. Desde el punto de vista del cliente, este es solo otro servicio para el que puede obtener un boleto. Cuantas más funciones ofrezca este servicio, más tickets proporcionará. Esto es en realidad un servicio de entradas.

Estudiante: lo siento, quise decir que tenemos un boleto llamado TGS.

Profesor: oh, sí, lo siento, la inscripción tgs debajo de la flecha en este diagrama es solo una abreviatura de todo el bloque de grabación, excepto el índice s en el parámetro Tc, s, lo que significa que el nombre real de este servicio es TGS. Puede imaginar que tenemos un servidor Kerberos, existe este servicio TGS y hay un servicio real al que desea acceder. Entonces, primero tiene que pedirle a Kerberos que le dé un ticket para obtener acceso a un servicio en particular.



Puede pedirle a Kerberos que le dé un ticket directamente al servidor de archivos, y eso podría funcionar. Pero para esto necesitaría su Kc para descifrar y para el resto del tiempo usar el servidor. En cambio, obtienes un boleto para el servicio especial de TGS. Se ve igual que otros servicios, excepto que se coloca en una casilla separada. Y estará encantado de darle más boletos más tarde sin volver a proporcionar su clave de cliente Kc original.

Estudiante: es decir, su idea es que tan pronto como reciba un boleto de TGS, ¿puede deshacerse de su clave Kc?

Profesor: sí, lo bueno de esto es que tan pronto como reciba este ticket Tc, s del servicio TGS, se deshará de la contraseña y la clave Kc. Por lo tanto, tan pronto como inicie sesión en la estación de trabajo Athena y después de un par de segundos reciba un ticket T, su contraseña se borrará de la memoria. Entonces, incluso si alguien te agarra, selecciona la computadora y huye con él, todo lo que tiene es tu boleto. Es bueno si puede obtener acceso a su información por 10 horas, o por la duración del boleto, pero no por más tiempo, porque la contraseña no se ha guardado y la próxima vez que ingrese "Athena" deberá ingresarla nuevamente.

La única vez que necesita una contraseña es cuando envía una solicitud al servidor Kerberos, recibe esta respuesta con un ticket y la descifra. Después de eso, puedes olvidarte de la contraseña. Pero, por supuesto, no puede soltar la contraseña antes de usarla para descifrar.
Por lo tanto, la primera interfaz superior C en nuestro esquema se utiliza para obtener un ticket con la clave inicial Kc, y la segunda interfaz inferior S se utiliza para acceder a los servicios, pero sin la necesidad de obtener la clave inicial Kc.



Por lo tanto, ya hemos hablado sobre dos problemas específicos del protocolo Kerberos, que, por así decirlo, están integrados en él, lo que causó algunos inconvenientes. Primero, los creadores asumieron que el cifrado también proporcionaría autenticación o integridad del mensaje, pero esto no sucedió. Esta falla se ha corregido en Kerberos versión 5, donde se realiza la autenticación explícita de mensajes. En segundo lugar, para clientes arbitrarios, tuvieron la oportunidad de adivinar las contraseñas de otras personas.

¿Cómo se puede arreglar esto? ¿Cómo evitar ataques adivinando la contraseña en protocolos de este tipo? Que podemos probar

Estudiante: No estoy seguro, pero puedes intentar "saltear" la contraseña.

Profesor: "salazón" simplemente significa que el cliente puede tener que descifrar la contraseña de diferentes maneras. Pero esto no hace daño para tratar de recogerlo. Por lo tanto, podría ser más costoso construir un diccionario.

Estudiante: puede intentar complicar la función de calcular la contraseña.

Profesor: sí, otra buena idea es hacer que el proceso de hash sea muy costoso. Quizás esto sea razonable. Por lo tanto, si esta función hash toma un segundo de tiempo de cálculo, como lo hicieron en el segundo laboratorio, en este caso, seleccionar contraseñas sería una tarea muy costosa. Esto parece un plan razonable: usar una combinación de "salazón" y complicar el proceso de adivinanzas.

Otra defensa puede ser complicar la respuesta. Ha escuchado que en las primeras versiones del protocolo, el servidor Kerberos no tenía idea de si el cliente correcto estaba accediendo a él o no. Lo que podría hacer es proporcionar evidencia de que usted es el cliente correcto, es decir, cifrar la marca de tiempo actual con un hash de contraseña, o algo así. Luego, el servidor Kerberos podría verificar si estas cosas son correctas y, si coinciden, proporcionarle un ticket.

Probablemente no desee agregar más pasos de prueba, pero eso podría funcionar. Por ahora, suponga que puede tomar una marca de tiempo y hacer un hash junto con la clave Kc, y también simplemente agregar una marca de tiempo.



En este caso, el servidor puede ver que tiene su clave Kc y también puede cambiar la marca de tiempo actual. Si recibe el mismo valor, probablemente la solicitud la realice el usuario correcto al que se puede enviar el ticket. Si no, era la contraseña incorrecta.

Estudiante: simplemente puede limitar la emisión de tickets si los servidores registran demasiadas solicitudes para su provisión.

Profesor: muy cierto, podemos introducir una restricción. Sin embargo, no hay ninguna razón para que un hacker solicite un ticket en el servidor más de una vez. Simplemente solicita un usuario específico, recibe este bloque cifrado de él y puede intentar descifrarlo sin conexión tantas veces como lo desee, con diferentes contraseñas sin una segunda solicitud. Por lo tanto, creo que todo el punto de protección es que el servidor de alguna manera reacciona a la cantidad de llamadas si el atacante solicita repetidamente el servidor, tratando de ingresar al sistema con diferentes contraseñas. En este caso, se puede alcanzar el límite de consulta, lo que proporcionará una mejor protección contra la piratería.

Estudiante: ¿cómo puede un atacante enviar una solicitud al servidor Kerberos?

Profesor: Creo que podría reproducir el mensaje del usuario correcto, es decir, verlo, copiarlo, enviarlo y también recibir una respuesta del servidor Kerberos. Si un hacker escanea la red, puede interceptar el mensaje durante la transmisión. Por lo tanto, limitar el número de solicitudes es una medida temporal que solo aumenta ligeramente la seguridad. Pero, por supuesto, si está mirando la red de otra persona, verá cómo se devuelve este paquete desde el servidor, independientemente de lo que sucedió en la etapa de formación de Tc, s. Para que el hacker pueda ver la respuesta del servidor al cliente e intentar atacarlo.

Probablemente haya esquemas más complejos que podría desarrollar, pero no creo que Kerberos 5 implemente algo más complicado que el plan que revisamos, lo que parece lo suficientemente bueno como para evitar que personas aleatorias intenten romper algo o usar el bruto forzar a descifrar una contraseña.

Estudiante: suponga que puede proporcionar autenticación u otra cosa para establecer una clave compartida. Y luego puede cifrar esta cosa y la clave compartida con Kc.

Profesor: sí, lo es. Si realmente lo hace bien, entonces para esto hay un protocolo llamado Intercambio de clave autenticada por contraseña, PAKE, que realiza la autenticación de contraseña. Esto es exactamente lo que sucede en Kerberos.



Puede ver en Google para qué sirven los protocolos SRP o PAKE. Estos protocolos y sus elementos asociados funcionan mucho mejor con su tarea, en la que debe demostrar a ambas partes que ha instalado una nueva clave. En este caso, ambas partes deben estar convencidas de la corrección mutua y de que no hay forma de adivinar esta contraseña fuera de línea y atacar el conjunto de paquetes de red que está observando, y así sucesivamente.

Estos son protocolos que dependen en gran medida de la criptografía, por lo que es difícil explicar en la pizarra por qué funcionan.

Estudiante: Una de las razones por las que los desarrolladores hicieron esto fue porque querían admitir la capacidad de enviar solo una contraseña. Y los protocolos solo le permiten enviar una sola cosa como autenticador.

Profesor: sí, hay muchos requisitos extraños que estos tipos tuvieron en cuenta. Por supuesto, en la práctica, estos servidores pueden aceptar conexiones Kerberos y no Kerberos. Y para las conexiones que no son de Kerberos, obtienes la imagen como si alguien se conectara a un servidor de correo pero no usara una estación de trabajo Athena. Solo quiere enviar su contraseña.



Y luego, el cliente de correo electrónico aquí, digamos, tomará esta contraseña y obtendrá un ticket en su nombre solo para verificarla, lo que le permitirá usar este cliente de correo electrónico. Por lo tanto, es probable que aún desee Kerberos para verificar las contraseñas de Kerberos. No creo que esto esté fuera de discusión porque, por supuesto, Kerberos 5 implementa estos hash de marca de tiempo y todo eso.

Creo que una cosa más a la que debe prestar atención en los materiales de la conferencia es que los desarrolladores de Kerberos 4 eligieron un esquema de cifrado: DES, el algoritmo de cifrado más popular de la época. Este es un cifrado de bloque simétrico, bastante rápido. En ese momento, proporcionaba suficiente seguridad, y simplemente lo incorporaron al protocolo.

Se suponía que todo en Kerberos debía usar solo DES, o al menos todo en Kerberos versión 4. Esto se ha vuelto problemático, porque ahora, 25-30 años después, el cifrado DES es fácil de descifrar usando el método de fuerza bruta, ya que las claves de cifrado tienen tamaño muy pequeño: solo 56 bits.

Por lo tanto, simplemente puede crear algún tipo de equipo de usuario que calcule de 2 a 56 grados de combinaciones y descubra la contraseña real. Esto es lo que desea evitar en cualquier protocolo que se desarrolle hoy en día.

Kerberos versión 5 admite varios esquemas de cifrado diferentes, incluidos AES y otros algoritmos criptográficos. Esto parece una forma mucho mejor de garantizar la seguridad. Por otro lado, MIT continuó apoyando DES hace 2 años, pero ahora lo ha rechazado, por lo que hoy su rector está protegido, al menos de este tipo de ataque. Ahora veamos qué sucede en el servicio TGS del cual recibe un boleto. La interacción con este servicio se ve un poco diferente.

Por un lado, como cliente, va a hablar con él como si estuviera hablando con cualquier otro servicio habilitado para Kerberos. Considere cómo realiza su propia autenticación con un ticket para una máquina. Pero la respuesta que va a devolver es solo un boleto a algún otro principio, sobre la base del cual se comunicará, por ejemplo, con un servidor de archivos.

Por lo tanto, los mensajes de nivel de protocolo se verán así: a la derecha dibujaré TGS y a la izquierda, el cliente. El cliente ya tiene un ticket para TGS, obtenido utilizando el protocolo que se muestra en la parte superior.



Ahora el cliente enviará una combinación de mensajes que demuestren que es el cliente correcto, y estos mensajes están relacionados con la emisión de una solicitud sobre un principio específico a través de TGS.

Entonces, el cliente enviará un mensaje de este tipo a TGS: S es el servicio con el que se va a comunicar más, puede ser un servidor de correo o de archivos, luego esto incluye el ticket del cliente Tc que recibió para tgs, encriptado usando la clave K tgs y un autenticador que está encriptado con la clave Kc, tgs común al cliente y al servicio TGS. Así es como se ve el mensaje que va a enviar a TGS: dice: "mire este mensaje, haga algo con él y responda con un ticket para este nuevo servicio S". La respuesta aquí se ve casi igual que en la figura anterior, y de hecho es la misma: este es un ticket entre el cliente y este nuevo servicio, encriptado usando Ks. Pero ahora se ha vuelto un poco diferente.



En lugar del cifrado con la clave Kc, que el cliente debe haber olvidado desde entonces, ahora el cifrado se realiza utilizando la clave común Kc, tgs entre el cliente y el servicio TGS.

¿Cómo determina el servidor lo que quiere el cliente y cómo el servidor autentica al cliente? El servidor TGS conoce su propia clave Ktgs, por lo que primero descifrará este mensaje Tc, tgs, mirará dentro del ticket y descubrirá qué sucede. ¿Por qué necesitamos todos estos campos en el ticket? ¿Por qué es importante tener el nombre del servidor S en el ticket? ¿Qué saldría mal si no tuviéramos S?

Estudiante: si no existiera, podría obtener permiso para usar cualquier servidor.

Profesor: sí, lo es. En general, es una buena idea hacer los protocolos de red para que pueda decir exactamente qué significa este mensaje. En caso de que omita S, puede confiar en el hecho de que si usa un ticket para el S incorrecto, entonces tal vez tenga otras claves K y no podrá realizar el descifrado o algo así. Entonces, ¿parece una buena idea incluir el nombre del servicio para asegurarse de que el servidor que recibe estos tickets los descifra y comprueba si es un ticket para mí o para otra persona?

Estudiante: ¿qué hace el cliente con la clave Ktgs recibida?

Profesor: buena pregunta! El cliente no tiene idea de qué es. Porque es una clave de alto secreto. Si lo supieras, podrás descifrar todos los Kerberos. Entonces el cliente no tiene idea de qué es Ktgs.

Estudiante: ¿de dónde viene este Ktgs?

Profesor: el servidor Kerberos mismo genera para usted todo este mensaje, que ya tiene Tc, tgs y Ktgs, no lo crea usted mismo, simplemente cópielo desde aquí.

Entonces, ¿por qué es tan importante el nombre del cliente? Esto es fácil de resolver. Si no pone el nombre del cliente en el ticket, el servidor recibe este mensaje, pero no tiene idea con quién está tratando de hablar. No sabe para quién debe emitir un boleto, ni para usted ni para otra persona.

¿Qué pasa con los otros campos? ¿Por qué los desarrolladores insertan la dirección addr en el ticket de Tc? Es solo la dirección IP del cliente, entonces, ¿por qué no usarla directamente?



Creo que el significado de esta solución es el deseo de los desarrolladores de aumentar la seguridad. Querían asegurarse de que si el cliente inició sesión desde alguna dirección IP, todo lo demás en el mismo ticket proviene de la misma dirección IP. Por ejemplo, si ha iniciado sesión desde alguna dirección IP, por ejemplo 18.26.4.9, cada conexión a un archivo o servidor de correo debe ser de la misma dirección IP. De lo contrario, el servidor debería rechazar su conexión, ya que puede sugerir que alguien robó su boleto. Por lo tanto, nos protegemos aquí contra el uso de boletos robados. Si todavía tiene el mismo ticket, está bien, pero si no utiliza la misma dirección IP, no tendrá éxito.

Esto parece una idea errónea en este momento, y Kerberos 5 todavía usa un enfoque similar, aunque esto no es necesario. De hecho, simplemente debe confiar en la criptografía en lugar de asegurar la dirección IP.

Pero, ¿cuál es el significado de la marca de tiempo y la marca de tiempo de vida en el boleto? ¿Para qué sirven y para qué sirven?

Estudiante: son necesarios para evitar ataques de repetición.
Profesor: los ataques de repetición nos ayudan a evitar el autenticador, porque esto se genera cada vez que realiza una nueva solicitud. Pero, por otro lado, el ticket sigue siendo el mismo, por lo que esto, por supuesto, no interfiere con los ataques de repetición.

Estudiante: esto evita que alguien robe su boleto y luego lo use para sus propios fines.
Profesor: sí, esto simplemente limita el tiempo durante el cual el boleto es válido, por lo que se reduce el daño de su robo. La marca de tiempo es la hora en que recibió el boleto, y la vida útil muestra cuántas horas es válido este boleto desde la marca de tiempo inicial. Por lo tanto, si intenta utilizarlo demasiado pronto o demasiado tarde, cualquier servidor debería rechazar dicho ticket utilizando el protocolo Kerberos. Esto significa que cada servidor debe sincronizar su reloj.

Estudiante: Usted dijo anteriormente que un cliente puede tirar su clave inicial, descartar Kc, pero debe almacenar los Kc recibidos de TGS.

Profesor: sí, lo es, el cliente deja caer Kc después de iniciar sesión, pero debe mantener Kc, s.

Estudiante: entonces, si alguien roba Kc, s, entonces tiene acceso ...

: , , ? , Kc,tgs, K?

: K,s, , K, .



: . , Kc,s — , , . , Tc,tgs, . , 56 Kc,s. . , Tc,tgs , Kc,s , - .

: , - — Tc,tgs, Kc,tgs, Kc,tgs, Kc — .

: , - , , , , 10 . Kc , .

, , , IP-, . - , , Kc,tgs, TGS. — , , , .

, , , . , , . TGS , , PO12, TGS PO12. , , Kc,s . , , . Kc,s.



, , Tc,mail, Kmail, , , , 5 – DELETE 5, Kc,mail.



, mail? Kmail, - , , Kc,s, Kerberos 5. : «, C , ».

: Kerberos Tc,tgs Kc,s. ?

: Ac . , Kc,s, , . , .



, Kerberos 4 , , , , , , , .

, , , , . , . , , . , , , , . , .
. Kerberos, , , Kerberos 4. , - .

, , , , , Kerberos 4, , , K,mail. , .



, , . , , . - : «, , DELETE 5, - ».

, Kerberos 5 -, . , , , , , .

: K,mail?

: .



, TGS , , S – mail, S Tc,s – mail, S Kc,s — mail. Kc,s K,mail. , .

: K,mail?

: , ? , , . K,mail ?

: ?

: , , ! Kmail, T,mail, , . , , .

, . . Kerberos , , 30 .
Por lo tanto, es inevitable que tengamos problemas que debe resolver. Entonces, un problema interesante de Kerberos 4 se refiere al método de cifrar y autenticar mensajes para aplicaciones. Consiste en el hecho de que aquí se usa la misma clave para encriptar mensajes del cliente al servidor y para mensajes de respuesta del servidor al cliente.

54:00 min

Curso MIT "Seguridad de sistemas informáticos". Lección 13: Protocolos de red, Parte 3


La versión completa del curso está disponible aquí .

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta diciembre de forma gratuita al pagar por un período de seis meses, puede ordenar aquí .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?