Existen muchos miedos dando vueltas por internet, desde el miedo a que te roben la identidad , pasando por la publicacion de tus mails mas reservados o la distribucion de tus fotos mas intimas, pero desde hace un tiempo a hoy con las sucesivas fallas que se le estan encontrando a SSL el sueño de la seguridad de nuestras comunicaciones mas privadas se esta volviendo una pesadilla.
SSL provee la capacidad de encriptar y verificar la identidad de la informacion que se transmite entre dos equipos.
El funcionamiento basico para una comunicacion tipica se resume en el siguiente grafico :
Este tipo de comunicaciones encriptadas las vivimos cuando accedemos a gmail, la banca electronica o en sitios que hacen uso de SSL.Por supuesto que la ingenieria de clave publica y clave privada que existe detras del SSL es mucho mas compleja que ese simple grafico.
En el grafico anterior, se verifica la autenticidad del server pero no del cliente. Veamos que ocurre durante este proceso.
Fase de Negociacion:
- El cliente envia un mensaje ClientHello que especifica el protocolo TLS mas fuerte que soporta, un numero random y una lista de suites de cifrado y metodos de compresion.
- El server responde con un mensaje ServerHello , que contiene la version de protocolo elegida, un numero random , la suite de cifrado y el metodo de compresion basados en lo ofrecido por el cliente. El server puede enviar incluso un session_id como una forma de simplificar la negociacion.
- El server envia su mensaje Certificado
- El server envia un mensaje de ServerHelloDone , indicando que termino la negociacion.
- El cliente responde con un mensaje de ClientKeyExchange , que puede contener un PreMasterSecret, una clave publica o nada. (Esto depende del cifrado seleccionado.)
- El cliente y el server usan numeros random y un PreMasterSecret para crear un secreto compartido, llamado "master secret". Toda la informacion para esta conexion deriva de este secreto maestro.
- El cliente ahora envia un registro ChangeCipherSpec , que le dice al server, "Todo lo que te diga de ahora en adelante sera autenticado (y encriptado si esto fue negociado )."
- El cliente envia un mensaje Finished autenticado y encriptado, conteniendo un hash y MAC referenciando los mensajes anteriormente negociados.
- El server intentara desencriptar el mensaje Finished y verificar el hash y MAC, si esto falla la negociacion se considerara que fallo y debera ser detenida.
- El server envia un ChangeCipherSpec, que le dice al cliente, "Todo lo que te diga de ahora en adelante sera autenticado (y encriptado si esto fue negociado )."
- Por ultimo, el server envia un mensaje Finished autenticado y encriptado, conteniendo un hash y MAC referenciando los mensajes anteriormente negociados.
- El cliente intentara desencriptar el mensaje Finished y verificar el hash y MAC, si esto falla la negociacion se considerara que fallo y debera ser detenida.
Fase de aplicacion:
En este momento la fase de negociacion esta completa y el protocolo de aplicacion esta habilitado. La transmision de los datos se encontrara autenticada y opcionalmente encriptada.
Todo esto ocurre en fraccion de segundos.
Si existiera una biblia del hacking, las primeras palabras dirian "Al principio Dios creo el Man in the Middle". Y volviendo sobre el tema religioso, una de las herramientas que permite aprovechar este metodo para atacar sitios con autenticacion SSL es Cain y Abel.
En verdad Cain es quien permite mediante el exploit de ciertas caracteristicas de la capa 2 del modelo OSI, realizar un Man in the Midle situandonos entre la victima y el server.
La utilidad APR-HTTPS permite realizar el sniffing de conexiones SSL. Al tomar el control de los paquetes que envia la victima hacia el server, Cain envia un Certificado Falso. Por lo tanto el cliente vera un mensaje de alerta como el siguiente.
Cuando trata de ver el certificado, encontrara la siguiente informacion.
La informacion desencriptada se encontrara bajo el directorio https bajo el directorio de instalacion de Cain.
Por supuesto que esta es una herramienta que tiene varios años y genera un alerta de certificado falso. Pero lamentablemente el usuario comun esta indefenso ante este tipo de situaciones, ya que sitios validos con certificados vencidos tambien muestran mensajes similares y generan mayor confusion.
Vimos esto hace unos dias atras con el sitio de Claro Puerto Rico
Y anteriormente con un sitio de Cisco que se encuentra activo.
El año pasado hable sobre SurfHacking . El termino session hijacking se refiere a la posibilidad de "duplicar" las credenciales de autorización en una comunicación valida ya establecida entre un server y un cliente
( también llamada session ) para obtener el acceso a la información o los servicios en el server.
En Defcon16 Mike Perry demostro en su presentacion 365-Day: HTTPS Cookie Stealing que el robo de identidad aun es posible utilizando https.
Creo una herramienta que se llama CookieMonster y que publico meses atras.
Pero existe otro metodo que podemos decir es mucho mas maquiavelico y del cual hable tambien en el post de Surfhacking.
HTTP Redirect
Cuando un cliente HTTP o un browser reciben como respuesta "“301 Moved Permanently” desde el webserver, automaticamente seran redirigidos a otro sitio que es espicificado en el header HTTP "Location" de la respuesta. Lo mismo ocurre con los codigos de respuesta 302,303 y 307. Ademas de estos metodos, web browsers pueden ser redirigidos mediante Javascripts y posiblemente utilizando otros metodos.
Veamos como afectan a los sitios con SSL.
Como funciona ?
Tenemos dos posibles formas de realizar esto.
Pasemos a explicar como funciona, utilizando palabras de Sandro Gauci quien si publico su herramienta.
-- La victima se loguea en un sitio seguro https://somesecurebank.com/
-- El sitio seguro envia una session cookie luego de logueado el cliente.
-- Estando logueado , la victima abre una ventan del browser y se dirige a http://www.example.org/
--El atacante envia de respuesta "301 Moved Permanently" en respuesta al pedido de acceder a http://www.example.org/. Ademas la respuesta contiene en el header “Location: http://somesecurebank.com/” que hace creer que http://www.example.org/ esta volviendo su browser al sitio de somesecurebank.com pero e que aqui el
protocolo cambio por http.
--El browser de la victima comienza una nueva session en claro hacia somesecurebank.com y expone la cookie de session.
--El atacante graba la cookie y la almacena para acceder suplantando la
identidad de la victima.
Si luego el atacante envia un nuevo paquete con el mensaje "301 Moved Permanently" y lo redirecciona hacia http://www.example.org/ el ataque sera totalmente transparente para el usuario ya que todo ocurre sin que el lo note.
Ahora el ataque propuesto por Perry
– Ayer: Usuario se loguea en to httpS://mail.google.com
– Hoy: Usuario visitas www.cnn.com en un hot spot abierto
– Hoy: Injectamos
– Hoy: El browser transmite la cookie GX de gmail para bajar la imagen.
– Hoy: Hacemos sniff de las cookies, las escribimos a cookies.txt
– Mañana: Usamos cookies.txt para leer su mail
Este tipo de ataques es posible en los siguientes escenarios.
• Redes wireless inseguras ( hot spots abiertos )
• Switched networks permitiendo ARP poisoning
• routers comprometidos
• Tunnel networks como TOR
• DNS poisoned domain names
La herramienta que libero Sandro surfjack.py es un script python que utiliza scapy como backend.
Ahora una herramienta ultimo modelo, llamada SSLstrip y lanzada en el 2009.
Utiliza tambien el concepto de Man in the Middle para interceptar los paquetes de la victima y rutearlos por el equipo del atacante.
Cuando SSLstrip detecta que el cliente envia una peticion, SSL automaticamente la cambia por una conexion no encriptada pero muestra al cliente el look de estar conectandose a un sitio seguro.
En verdad la aplicacion mediante el Man in the Middle , negocia las peticiones encriptadas con el server, lo que le permite observar las informaciones que se transmiten.
La presentacion que dio Moxie Marlinspike en BlackHat 2009 es mas que completa y habla de otra herramienta que tambien se aprovecha de problemas en la implementacion de SSL, llamada SSLSniff.
Conclusion
Como observamos en este post un tanto extenso, cuando la red donde nos conectamos es factible de sufrir ataques de ARP spoofing, DNS spoofing o un Rogue DHCP permitiendo que seamos víctimas de Man in the Middle, podemos decir "Game Over".
Vimos diferentes tipos de ataques, desde el basico mediante Cain hasta el mas elaborado de SSLSniffing del cual hasta el ojo mas entrado puede ser facilmente engañado.
Como nos protegemos del COCO SSL ? Primero siguiendo las buenas practicas de configuración de nuestros dispositivos de red, y fuera de nuestra red utilizando el sentido comun al conectarnos en redes que pueden ser promiscuas.
fuente imagenes : www.blogdelossimpson.com.ar
No comments:
Post a Comment