HTTPS Cookie Hijacking
35 views
Skip to first unread message
Andrés Gattinoni
Sep 10, 2008, 11:25:36 AM9/10/08
to weban...@googlegroups.com
Bueno, el otro día a partir del problema de Demián, Oscar mencionó que había habido una vulnerabilidad detectada en GMail y que era necesario usar HTTPS.
Creo que a lo que hacía referencia era a esto: http://it.slashdot.org/article.pl?sid=08/08/19/1433206&tid=172
Y no es algo que afecte sólo a Gmail, sino a una gran cantidad de sitios incluidos Yahoo, Hotmail, Facebook, la mayoría de los sitios con Drupal, etc.
Es un descubrimiento que hizo Mike Perry descripto aca: http://fscked.org/blog/fully-automated-active-https-cookie-hijacking
La vulnerabilidad deriva de que la mayoría de los sitios no define para las cookies de sus dominios de HTTPS la propiedad "Encrypted Sessions Only", con lo cual algunas cookies pueden viajar en texto plano, en requests HTTP. De todas formas, lo que no explica y habrá que googlear un poco es cómo se configura para que esto funcione bien.
El artículo está bastante interesante y no sé si llegué a comprenderlo al 100%. Básicamente el tipo diseñó un tipo de ataque que se puede realizar teniendo un mínimo control sobre la red de los objetivos (en una red local, wi-fi, o haciendo un hijacking de DNS, o teniendo un cablemodem customizado). Los pasos serían los siguientes (ni da traducirlos):
Según entiendo las cookies a las que no le ponés "Encrypted Sessions Only", si vos hacés un request por HTTP te vienen en texto plano, en cambio las otras solamente vienen en responses HTTPS. Por lo cual, si vos a un sitio que tiene cookies inseguras, le mandás un request HTTP, en la respuesta te tienen que venir esas cookies sin encriptar.
La forma de chequear si las cookies de un sitio son seguras es, en el Firefox ir a Preferencias, a Privacy, "Show Cookies" y ahí buscar para un determinado dominio las cookies. Borrar las que tienen "Send For: Encrypted connections only". Luego ingresar al sitio de nuevo y si te deja entrar es porque hay un problema. (Esta es la explicación que da él, yo calculo que será que si borrás esas cookies es porque hay otras no encriptadas, y que si con las no encriptadas ya entrás, entonces es inseguro).
Saludos,
A
Creo que a lo que hacía referencia era a esto: http://it.slashdot.org/article.pl?sid=08/08/19/1433206&tid=172
Y no es algo que afecte sólo a Gmail, sino a una gran cantidad de sitios incluidos Yahoo, Hotmail, Facebook, la mayoría de los sitios con Drupal, etc.
Es un descubrimiento que hizo Mike Perry descripto aca: http://fscked.org/blog/fully-automated-active-https-cookie-hijacking
La vulnerabilidad deriva de que la mayoría de los sitios no define para las cookies de sus dominios de HTTPS la propiedad "Encrypted Sessions Only", con lo cual algunas cookies pueden viajar en texto plano, en requests HTTP. De todas formas, lo que no explica y habrá que googlear un poco es cómo se configura para que esto funcione bien.
El artículo está bastante interesante y no sé si llegué a comprenderlo al 100%. Básicamente el tipo diseñó un tipo de ataque que se puede realizar teniendo un mínimo control sobre la red de los objetivos (en una red local, wi-fi, o haciendo un hijacking de DNS, o teniendo un cablemodem customizado). Los pasos serían los siguientes (ni da traducirlos):
Cache all DNS responses on the network to obtain a mapping of what host name clients are resolving, so you know the host they are using for server IPs.
When a client IP connects to a server IP using https (port 443), look up what hostname they resolved in the DNS cache to get this IP.
Add this domain as a target for that client IP.
When that IP then connects to ANY http website, look up what targets it has accumulated, and optionally add on a list of custom targets for completely insecure sites such as mail.yahoo.com and mail.live.com. Inject images for each of these into that TCP connection.
When the browser fetches these images, it will transmit any insecure cookies for that domain and path. Record the resulting cookies (and any others we happen to see while we're at it) to a Firefox-compatible cookies file.
Según entiendo las cookies a las que no le ponés "Encrypted Sessions Only", si vos hacés un request por HTTP te vienen en texto plano, en cambio las otras solamente vienen en responses HTTPS. Por lo cual, si vos a un sitio que tiene cookies inseguras, le mandás un request HTTP, en la respuesta te tienen que venir esas cookies sin encriptar.
La forma de chequear si las cookies de un sitio son seguras es, en el Firefox ir a Preferencias, a Privacy, "Show Cookies" y ahí buscar para un determinado dominio las cookies. Borrar las que tienen "Send For: Encrypted connections only". Luego ingresar al sitio de nuevo y si te deja entrar es porque hay un problema. (Esta es la explicación que da él, yo calculo que será que si borrás esas cookies es porque hay otras no encriptadas, y que si con las no encriptadas ya entrás, entonces es inseguro).
Saludos,
A
Tio Oscar
Sep 11, 2008, 3:49:02 AM9/11/08
to weban...@googlegroups.com
Mira, es una webada, google como muchos sitios, hacen el login por ssl, para que no pasen las contraseñas en texto plano, por un tema de micro/transferencia, se realiza todo en el login, luegos los datos van libremente por la red, considerando que ya no se necesitan cuidar tanto.
No es un problema de implementacion, es solo una problema de coste de las empresas que tienen que dar el servicio, y de comodidad del usuario.
El SSL (Secure noSeque Layer), algo asi como una capa de tranmicion segura, hace un intercambio de llaves, y una certificacion del lado del servidor, para saber que realmente le estemos mandando los datos al servidor correcto. Como una capa, esta iria por debajo de la capa de presentacion de datos (HTTP), asi que los cookies y de mas, no importa qué, cualquier cosa, va encriptado, los requests, las cookies y toda la bola, pero como ya dije, esto solo lo hace en el logueo, lo que estaria en la capa de aplicacion gmail/js/firefox por ejemplo, de ahí en mas, va todo en texto plano..
El problema: Si bien se protegio la clave, los datos en el medio no, y al capturar el trafico, ya sea envenenando dns o sniffiando (como me gusta sniffiar :P) se puede tener la transmicion de autentificacion de sesión a nivel aplicacion: Las cookies.
Y en escenario real, supongamos un sniff de los buenos, yo colandome a una terminal de una red, hago un Arp Posoning o una falcificacion de mac, y capturo los paquetes entre demian y gmail por ejemplo, y listo, ya tengo una session autentificada.
Peor aún, hay aplicaciones, y creo que es lo que hacia gmail, por lo menos hotmail lo hizo por mucho tiempo, es mandar la password encriptada, normalmente en ha1 o md5, lo que hace que la capturemos, y la podamos desencriptar, ya sea con diccionario o buscando coliciones, la md5 por ejemplo, es una DB de 32GB, que hoy por hoy no es taaanto.
En gmail, laparte de configuracion, pusieron una opcion (siempre mandar por https) y por default viene desativada, activenla muchachos...
No es un problema de implementacion, es solo una problema de coste de las empresas que tienen que dar el servicio, y de comodidad del usuario.
El SSL (Secure noSeque Layer), algo asi como una capa de tranmicion segura, hace un intercambio de llaves, y una certificacion del lado del servidor, para saber que realmente le estemos mandando los datos al servidor correcto. Como una capa, esta iria por debajo de la capa de presentacion de datos (HTTP), asi que los cookies y de mas, no importa qué, cualquier cosa, va encriptado, los requests, las cookies y toda la bola, pero como ya dije, esto solo lo hace en el logueo, lo que estaria en la capa de aplicacion gmail/js/firefox por ejemplo, de ahí en mas, va todo en texto plano..
El problema: Si bien se protegio la clave, los datos en el medio no, y al capturar el trafico, ya sea envenenando dns o sniffiando (como me gusta sniffiar :P) se puede tener la transmicion de autentificacion de sesión a nivel aplicacion: Las cookies.
Y en escenario real, supongamos un sniff de los buenos, yo colandome a una terminal de una red, hago un Arp Posoning o una falcificacion de mac, y capturo los paquetes entre demian y gmail por ejemplo, y listo, ya tengo una session autentificada.
Peor aún, hay aplicaciones, y creo que es lo que hacia gmail, por lo menos hotmail lo hizo por mucho tiempo, es mandar la password encriptada, normalmente en ha1 o md5, lo que hace que la capturemos, y la podamos desencriptar, ya sea con diccionario o buscando coliciones, la md5 por ejemplo, es una DB de 32GB, que hoy por hoy no es taaanto.
En gmail, laparte de configuracion, pusieron una opcion (siempre mandar por https) y por default viene desativada, activenla muchachos...
Andrés Gattinoni
Sep 11, 2008, 9:08:56 AM9/11/08
to weban...@googlegroups.com
Si, igual no entendí mucho a dónde iba tu argumento :P
Lo que yo entendí del ataque va por este lado:
- Si vos podés interceptar las cookies (capturando paquetes, etc.), fácilmente podés hacer un hijacking de la sesión del usuario (ya expliqué cómo en algún otro post hace tiempo sobre cookies, en función de cómo se usan las cookies para el manejo de sesiones de PHP por ejemplo) y podés obtener cualquier otra información sensible que pudiera viajar por ese medio (el riesgo menor).
- El HTTPS se utiliza cuando la información que se envía tanto en los parámetros por POST/GET, el contenido y las cookies, puede tener información sensible.
- El HTTPS como bien lo explicaste es HTTP que utiliza SSL (Secure Socket Layer), con lo cual se hace un handshake con llaves públicas/privadas antes de enviar la información y luego todos los datos se encriptan con esas llaves. Como sabrán, este mecanismo lo que permite es evitar ataques Man-In-The-Middle, porque para desencriptar un mensaje del server es necesario la llave pública y para desencriptar los del cliente es necesaria la clave privada, como el atacante nunca podría tener la clave privada, nunca podría reconstruir el flujo entero de la comunicación.
- El protocolo HTTP establece que las cookies son enviadas en cada request y response mientras dure la sesión. En el momento en que el cliente deja de mandar las cookies, la sesión deja de existir.
- El ataque que explica este post habla de que justamente hay algunas cookies que se pueden definir como "Encrypted Sessions Only", eso quiere decir que sólamente se van a enviar en una sesión segura, es decir sólo a través de HTTPS. Si una cookie no tiene ese flag activado, por más que se haya creado a través de HTTPS, yo podría forzar un request por HTTP y para mantener la sesión, el server me la va a devolver las cookies en ese response... que va a venir por HTTP, en texto plano.
Saludos,
A
Lo que yo entendí del ataque va por este lado:
- Si vos podés interceptar las cookies (capturando paquetes, etc.), fácilmente podés hacer un hijacking de la sesión del usuario (ya expliqué cómo en algún otro post hace tiempo sobre cookies, en función de cómo se usan las cookies para el manejo de sesiones de PHP por ejemplo) y podés obtener cualquier otra información sensible que pudiera viajar por ese medio (el riesgo menor).
- El HTTPS se utiliza cuando la información que se envía tanto en los parámetros por POST/GET, el contenido y las cookies, puede tener información sensible.
- El HTTPS como bien lo explicaste es HTTP que utiliza SSL (Secure Socket Layer), con lo cual se hace un handshake con llaves públicas/privadas antes de enviar la información y luego todos los datos se encriptan con esas llaves. Como sabrán, este mecanismo lo que permite es evitar ataques Man-In-The-Middle, porque para desencriptar un mensaje del server es necesario la llave pública y para desencriptar los del cliente es necesaria la clave privada, como el atacante nunca podría tener la clave privada, nunca podría reconstruir el flujo entero de la comunicación.
- El protocolo HTTP establece que las cookies son enviadas en cada request y response mientras dure la sesión. En el momento en que el cliente deja de mandar las cookies, la sesión deja de existir.
- El ataque que explica este post habla de que justamente hay algunas cookies que se pueden definir como "Encrypted Sessions Only", eso quiere decir que sólamente se van a enviar en una sesión segura, es decir sólo a través de HTTPS. Si una cookie no tiene ese flag activado, por más que se haya creado a través de HTTPS, yo podría forzar un request por HTTP y para mantener la sesión, el server me la va a devolver las cookies en ese response... que va a venir por HTTP, en texto plano.
Saludos,
A
2008/9/11 Tio Oscar <tio...@gmail.com>
Tio Oscar
Sep 11, 2008, 11:45:35 AM9/11/08
to weban...@googlegroups.com
Si bueno, pero volvemos al tema, no es un error, es por cuestiones de proceso/transferencia, asi que no lo van a hacer...
Igual tanpoco te creas que el https es taaaaaaaan seguro.
Y digamos que es solo un mail.... Cerrando la session debidamente y cambiando la pass de vez en cuando ya esta.
Igual tanpoco te creas que el https es taaaaaaaan seguro.
Y digamos que es solo un mail.... Cerrando la session debidamente y cambiando la pass de vez en cuando ya esta.
Andrés Gattinoni
Sep 11, 2008, 11:56:44 AM9/11/08
to weban...@googlegroups.com
Al contrario, me parece que por ser tan pelotudo y haber quedado tan expuesto, lo van a corregir porque no les cuesta nada. De hecho te puede ahorrar transferencia si pensás que para hacer un request de una imágen no tendrías por qué enviarle todas las cookies que tenés.
Además es cierto que cerrando la sesion y cambiando los password en general la vas a pilotear bien, pero la mayoría de la gente no lo hace. Yo de hecho en mi máquina no lo hago. Y si alguien tiene control de una red (y con el problema que comenté el otro día con BGP vemos que hay varias formas), tranquilamente se puede poner a jugar con estas cosas y empezar a hacer hijackings a lo loco para mandar spam. Fijate que el tipo que descubrió el bug está liberando en estos días un programita que hizo para hacer el hijacking en forma automática: http://fscked.org/blog/why-full-disclosure
Además es cierto que cerrando la sesion y cambiando los password en general la vas a pilotear bien, pero la mayoría de la gente no lo hace. Yo de hecho en mi máquina no lo hago. Y si alguien tiene control de una red (y con el problema que comenté el otro día con BGP vemos que hay varias formas), tranquilamente se puede poner a jugar con estas cosas y empezar a hacer hijackings a lo loco para mandar spam. Fijate que el tipo que descubrió el bug está liberando en estos días un programita que hizo para hacer el hijacking en forma automática: http://fscked.org/blog/why-full-disclosure
Tio Oscar
Sep 11, 2008, 12:34:11 PM9/11/08
to weban...@googlegroups.com
Con todas las cookies que te ahorras para pedir imagenes xD (1kb en 500kb de imagenes...) no llegas a ahorrar lo que gasta la transeferencia de un minuto de actividad en ssl, aparte de eso, el micro que se usa en el server que tiene que escriptar/desencriptar toda la comunicacion....
Y esto, no es un error, igual que el BGP, tampoco es un error... a quien carajo le importa el mail de una persona que no sabe ponerse en https o que no cambia su pass ni cierra la session??? aca no pasa por la seguridad, sino por el spam, y si hay que poner un captcha cada vez que se tenga que mandar un mail.. y bueno...
Andrés Gattinoni
Sep 11, 2008, 12:58:17 PM9/11/08
to weban...@googlegroups.com
Convengamos que el overhead de encriptar/desencriptar la comunicación a esta altura no es tan grave. Lo mismo que comprimir/descomprimir con gzip. Esto es un tema muy largo, sobre lo que se ha escrito mucho. Es cierto que hay un overhead, pero en algunos casos es sumamente justificable en aras de la seguridad. No te olvides que entre las aplicaciones vulnerables que lista el tipo se incluyen bancos.
Por otro lado estamos hablando de sitios que de por sí ya usan HTTPS y que las cookies viajan por HTTPS, el problema es que esas mismas cookies PUEDAN viajar por HTTP. No es una cuestión de utilizar más recursos, porque esos recursos ya se están utilizando ahora. Es cuestión de agregar una medida extra de seguridad para evitar un problema que está dando mucho que hablar últimamente en internet y por lo cual va a haber mucha gente jodiendo con eso.
Es verdad que no es bug o un error de código, pero no deja de ser una vulnerabilidad o un error lógico en la arquitectura. Lo de BGP es un problema de arquitectura: se desarrolló todo sobre la base de la confianza de los nodos, una vez que se quiebra esa premisa, la lógica que se construye sobre eso tambalea. Acá pasa lo mismo, hay una confianza en cierta flexibilidad en una configuración que ahora nos damos cuenta que puede dar problemas: una vez que se rompe esa confianza o lo asegurás o te atenés a las consecuencias.
Concuerdo en que el problema principal es el tema del SPAM. Espero que no llegue el día que tenga que poner un captcha cada vez que escribo un mail, porque ahí creo que voy a dejar de mandar mails jajaja. Pero también es un problema de seguridad desde el punto de vista de que cualquiera puede hacer un hijacking de mi cuenta, entrar con mi usuario y hacer lo que se me cante. De ahí a que en mi cuenta no haya nada importante, y que a nadie le vaya a importar un carajo entrar con mi usuario, eso es otra cosa, pero no deja de ser una vulnerabilidad de seguridad.
Por otro lado estamos hablando de sitios que de por sí ya usan HTTPS y que las cookies viajan por HTTPS, el problema es que esas mismas cookies PUEDAN viajar por HTTP. No es una cuestión de utilizar más recursos, porque esos recursos ya se están utilizando ahora. Es cuestión de agregar una medida extra de seguridad para evitar un problema que está dando mucho que hablar últimamente en internet y por lo cual va a haber mucha gente jodiendo con eso.
Es verdad que no es bug o un error de código, pero no deja de ser una vulnerabilidad o un error lógico en la arquitectura. Lo de BGP es un problema de arquitectura: se desarrolló todo sobre la base de la confianza de los nodos, una vez que se quiebra esa premisa, la lógica que se construye sobre eso tambalea. Acá pasa lo mismo, hay una confianza en cierta flexibilidad en una configuración que ahora nos damos cuenta que puede dar problemas: una vez que se rompe esa confianza o lo asegurás o te atenés a las consecuencias.
Concuerdo en que el problema principal es el tema del SPAM. Espero que no llegue el día que tenga que poner un captcha cada vez que escribo un mail, porque ahí creo que voy a dejar de mandar mails jajaja. Pero también es un problema de seguridad desde el punto de vista de que cualquiera puede hacer un hijacking de mi cuenta, entrar con mi usuario y hacer lo que se me cante. De ahí a que en mi cuenta no haya nada importante, y que a nadie le vaya a importar un carajo entrar con mi usuario, eso es otra cosa, pero no deja de ser una vulnerabilidad de seguridad.
Andrés Gattinoni
Sep 11, 2008, 1:19:03 PM9/11/08
to weban...@googlegroups.com
Por cierto, adjunto un interesante paper que encontré en el link de google que mandé recién donde se explica cómo funciona el handshake de SSL.
Me enferma lo coloquial del lenguaje que utilizan los yankies para escribir papers. Si yo escribo una mera reseña y pongo algo del tino de que tal cosa es "una patada en la cabeza para la performance", me cagan a piñas.
A
Me enferma lo coloquial del lenguaje que utilizan los yankies para escribir papers. Si yo escribo una mera reseña y pongo algo del tino de que tal cosa es "una patada en la cabeza para la performance", me cagan a piñas.
A
2008/9/11 Andrés Gattinoni <andresg...@gmail.com>
Tio Oscar
Sep 11, 2008, 1:23:29 PM9/11/08
to weban...@googlegroups.com
Che gatty...... ¿siempre estas taaan al pedo en el laburo? xD
Andrés Gattinoni
Sep 11, 2008, 1:36:26 PM9/11/08
to weban...@googlegroups.com
Qué laburo? :P
Estoy en casa.
Entre que leo un poco sobre la pobreza y el desarrollo de formas de control durante el siglo XVI en España, y escucho música, me pongo a responder estas cosas.
Así me va después, pero bue...
Estoy en casa.
Entre que leo un poco sobre la pobreza y el desarrollo de formas de control durante el siglo XVI en España, y escucho música, me pongo a responder estas cosas.
Así me va después, pero bue...
Tio Oscar
Sep 11, 2008, 1:41:29 PM9/11/08
to weban...@googlegroups.com
Haaaaaaaaaaa, yo pensaba que laburabas xD
Andrés Gattinoni
Sep 11, 2008, 1:46:17 PM9/11/08
to weban...@googlegroups.com
jeje no, renuncié para poder escribir más en la lista..... 8-)
2008/9/11 Tio Oscar <tio...@gmail.com>
Reply all
Reply to author
Forward
0 new messages