Robo de cookies HTTPS de Facebook con portal cautivo

20

Tengo un problema de seguridad. Como sabemos, muchos puntos de acceso públicos lo redirigen a una pantalla de inicio de sesión cuando intenta navegar por el primer sitio web.

Por ejemplo, si me conecto a un hotspot de ese tipo y luego visito enlace (desde una computadora donde ya he iniciado sesión en ese sitio ) Me redireccionan a la pantalla de inicio de sesión del punto de acceso, sin ninguna advertencia de certificado en mi navegador.

Obviamente, la solicitud HTTPS inicial realizada desde mi navegador contiene mi cookie de sesión ("Cookie:" encabezado HTTP).

Al realizar la redirección a la pantalla de inicio de sesión (redirección basada en ICMP o DNS), ¿el punto de acceso sabrá el contenido de mi solicitud de HTTPS y, por lo tanto, mi cookie de sesión?

Supongo que un punto de acceso malicioso puede leer mi primera solicitud de HTTPS:

  • Cuando el navegador intente conectarse a facebook.com:443, realizará el protocolo de enlace;
  • El hotspot responderá enviando un certificado válido basado en IP, por lo tanto, el hotspot se hará pasar por "facebook.com" y leerá el contenido de mi solicitud HTTPS original;
  • Después de eso, puede responder con un redireccionamiento 301/302 a la pantalla de inicio de sesión HTTPS del punto de acceso, sin ninguna advertencia en el cliente del navegador.

De esta manera, ¿será posible que un punto de acceso conozca el contenido de la primera solicitud HTTPS?

    
pregunta Marco Marsala 02.01.2016 - 18:18
fuente

2 respuestas

29

Si visita los sitios HTTPS y se redirige sin advertencias, entonces el problema es que su navegador no valida correctamente los certificados: un buen navegador mostrará una advertencia ya que el certificado del portal cautivo no contiene el dominio que desea visitar. su campo de nombre común.

Una posible vulnerabilidad sería si visita el sitio a través de HTTP, pero existen soluciones para mitigar esto, como el indicador seguro en cookies que le dicen al navegador que no envíe esta cookie a través de HTTP - y HSTS que hace que el navegador se convierta automáticamente sus solicitudes HTTP al sitio en solicitudes HTTPS, además de evitar que evite el error de certificado si no se puede establecer una conexión HTTPS.

    
respondido por el André Borie 02.01.2016 - 19:05
fuente
9

El comportamiento depende del navegador. Si el navegador realmente enviará la solicitud HTTPS destinada a Facebook al portal cautivo, entonces es claramente una vulnerabilidad del navegador. Pero hay otras formas de manejar la situación.

Recientemente he tenido que usar una red con un portal cautivo unas cuantas veces. Y en esos casos empecé Chromium, que tenía un par de pestañas de Facebook abiertas desde una sesión anterior.

Lo que sucedió fue que se mostraba un mensaje de error adecuado. Pero al mismo tiempo, Chromium abrió una nueva pestaña que accedía a una URL HTTP específica con la intención real de ser secuestrada por el portal cautivo. Tan pronto como pasé el portal cautivo, las pestañas de Facebook se recargarían automáticamente y esta vez no obtendría un error.

Así que parece que Chromium detecta la presencia de un portal cautivo, lo abre de forma segura y, finalmente, lo detecta una vez que haya pasado el portal cautivo.

La detección de un portal cautivo similar existe en Android e iOS, aunque no está vinculado al navegador, sino que se realiza como parte de la asociación con el punto de acceso.

Veo algunos conceptos erróneos en su comprensión de cómo funcionan los portales cautivos. Los portales cautivos con los que me he encontrado ciertamente funcionaron de una manera diferente.

No se realizó ninguna intercepción para el tráfico DNS. Mientras use el servidor DNS proporcionado a través de DHCP, su computadora podrá realizar búsquedas de DNS sin restricciones sin haber accedido al portal cautivo.

Tampoco se extraen trucos de ICMP. Más bien, uno de los enrutadores en la ruta legítima entre su computadora y el servidor secuestrará las conexiones TCP al puerto 80. Una vez que la conexión TCP haya sido secuestrada, se enviará una redirección al portal cautivo al navegador. En las implementaciones adecuadas, esto redirige a una URL de HTTPS y de alguna manera incluye información sobre la URL original, de modo que pueda ser enviado allí más tarde. Toda la comunicación con el portal cautivo se realiza mediante un certificado legítimo para un nombre de dominio que realmente pertenece al portal cautivo.

Este enfoque funciona para HTTP, pero no para HTTPS. El enrutador que realiza el secuestro no tendrá un certificado válido para el sitio al que está accediendo, por lo que en cualquier navegador seguro recibirá una advertencia de certificado si se realiza el mismo secuestro para HTTPS.

Hay tres maneras de evitar que esto no funcione para HTTPS:

  • Confíe en que los usuarios ignoren las advertencias de seguridad y acepten que su información privada será interceptada incluso después de haber sido presentada para una advertencia muy detallada sobre el riesgo.
  • Confíe en que los usuarios entiendan cómo funciona todo y, por su cuenta, abra una URL HTTP para ser secuestrado y luego sepa que debe ir a la URL HTTPS original después de haber pasado el portal cautivo.
  • Permita que el software del cliente detecte la presencia de portales cautivos y trate el problema de manera apropiada. Esto todavía depende de que los usuarios puedan detectar si un portal cautivo está intentando realizar ataques de phishing, pero al menos no filtra ninguna cookie.
respondido por el kasperd 02.01.2016 - 23:48
fuente

Lea otras preguntas en las etiquetas