Pasar de HTTP a HTTPS redirigir 301 en caché para usar SSLstrip

Navega tus respuestas
26

Estoy haciendo un poco de pluma. pruebas en un servidor HTTPS (443) que no tiene HSTS implementado (no hay encabezados HSTS en la respuesta y la dirección no está en la lista de precarga de Chrome HSTS).

El problema es que, en mi caso, el usuario ha visitado el sitio web anteriormente, por lo que tiene la primera respuesta de solicitud HTTP (80) en caché en Chrome.

Ahora, cuando el usuario escribe targetaddress.com , el navegador obtiene automáticamente la redirección en caché (301 - HTTP a HTTPS location=https://targetaddress.com ) haciendo que la tira de seguridad sea inútil.

Mi solución para esto fue bloquear el puerto 443 en el lado del cliente, de modo que el usuario, al no poder conectarse al objetivo, vaya y borre manualmente el caché / historial del navegador en un intento por restaurar la conexión. Entonces SSLstrip será efectivo ya que ahora interceptará / alterará la respuesta de la solicitud HTTP (redirección 301).

¿Hay alguna otra forma mejor de hacerlo, aparte del bloqueo del puerto 443?

Aquí está la redirección en caché: 

http://targetaddress.com/
HTTP/1.1 301 Moved Permanently
Date: Wed, 23 Dec 2015 18:31:19 GMT
Server: Apache
Location: https://www.targetaddress.com/
Content-Length: 237
Content-Type: text/html; charset=iso-8859-1
    
pregunta Bruno 23.12.2015 - 19:38
fuente

3 respuestas

2

Si puede hacer que el navegador realice una solicitud a http://targetaddress.com/whatever . El navegador realizará de forma predeterminada una solicitud HTTP simple, no una HTTPS ya que no hay respuesta en caché para /whatever , solo para / .

Esto se puede lograr de varias maneras. Una forma es MITM entre el navegador y cualquier sitio web accesible a través de HTTP simple e insertar una etiqueta <img> . Otra forma es engañar al usuario para que ingrese targetaddress.com/whatever en la barra de direcciones a través de la ingeniería social.

Tan pronto como el navegador realiza una solicitud de texto claro al dominio de destino, el MITM ha ganado el juego.

HTTP permite a un cliente realizar acciones en entidades . La acción que se realice depende del método HTTP especificado en la solicitud . La entidad en la que se realiza la acción depende de la URL especificada en la solicitud.

Diferentes URL s pueden hacer referencia a la misma entidad, pero el navegador no lo sabe. Cuando un navegador almacena en caché una respuesta de HTTP, lo hace para una URL .

http://www.target.com/ es una URL . http://target.com/ es otro. http://www.target.com/whatever es otro más. Así es http://www.target.com/? .

Ahora, supongamos que hay una entrada en caché para http://www.target.com/ en un navegador. ¿Implica que hay uno para cualquiera de los otros URL listados arriba? No, no lo hace.

Por lo tanto, volviendo a la pregunta, hacer que el navegador envíe una solicitud de texto sin formato en el caso de que una aplicación web devuelva un redireccionamiento permanente en el puerto HTTP es una cuestión de crear una URL que no coincide con una entrada de caché y engañar al usuario para que visite esta URL .

Prueba de que esto funciona: 

127.0.0.1 - - [13/Apr/2016:10:01:17 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:01:35 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:10 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:36 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:16 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:25 +0200] "GET /? HTTP/1.1" 301 227 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

He podido hacer seis solicitudes HTTP de texto claro (número arbitrario) al mismo sitio web con el mismo navegador, aunque se haya configurado una redirección permanente para todo. (Y no, ¡ no borramos el caché del navegador!)

Otras formas obvias de evitar un redireccionamiento permanente incluyen engañar al usuario para que cambie al modo de navegador anónimo (sin caché) o al otro navegador ("Tengo problemas al acceder a la aplicación con IE. ¿Puede echar un vistazo?" ).

    
respondido por el Erwan Legrand 11.03.2016 - 12:11
fuente
1

Hay más que unas pocas rutas prácticas para que los usuarios de destino borren sus cachés, lo que podría ser la solución más fácil. Esto puede no ser tan sospechoso, especialmente para objetivos no técnicos, ya que ha sido una sugerencia de solución de problemas de TI de parte de todos durante años.

Más fácil si está ejecutando / simulando un punto de acceso wifi para la intercepción. Levante una página de 'términos y condiciones' que tienen que aceptar cuando se conectan por primera vez, luego no les permita acceder y diga "Esto puede deberse a problemas de almacenamiento en caché. Limpie su caché haciendo X, Y, Z". Nadie realmente piensa en el almacenamiento en caché como una característica de seguridad, si es que lo entienden. La mayoría de la gente lo limpiará alegremente a cambio de Internet gratis, y luego estás de oro.

    
respondido por el Tim Perry 25.10.2016 - 14:44
fuente
0

Puedes intentar ejecutar synflood en el puerto 443. El cliente no podría conectarse y podría volver al puerto 80.

Sólo un descargo de responsabilidad, pero no he intentado esto. ¿Alguien quiere participar?

    
respondido por el Daisetsu 23.04.2016 - 09:07
fuente

Lea otras preguntas en las etiquetas

¿Cómo me aseguro de que haya suficiente entropía en un sistema integrado en el primer arranque? ¿Cuál sería el tamaño de la clave para una imagen utilizada como clave?