Verdadero o falso: HSTS es absolutamente inútil contra los ataques MITM

5

Entiendo que es una buena medida de seguridad implementar HSTS, porque reducirá la cantidad de incidentes.

Declaración 1: si el tráfico de IO de los clientes pasa por MITM desde el principio, ¿puede el atacante simplemente quitar el encabezado Strict-Transport-Security , incluso desde la conexión HTTPS inicial?

Soy consciente de las listas HSTS predefinidas que los navegadores están implementando. Esta medida no cubre todos los sitios / navegadores.

Declaración 2: el atacante puede pasar el encabezado Strict-Transport-Security: max-age=0 en cualquier momento y deshabilitar HSTS.

Si ambos son verdaderos, o incluso el número 2 solo, HSTS parece bastante inútil. No puede ser tan fácil, ¿dónde me equivoco?

    
pregunta Alph.Dev 01.09.2014 - 14:34
fuente

4 respuestas

10

Declaración 1: no debe haber un encabezado para que un atacante lo elimine desde enviarlo a través de HTTP es useles s. No tengo idea de por qué alguien lo enviaría a través de HTTP. Y si el atacante tiene certificados en los que el cliente confía para que se establezca una conexión HTTPS, entonces HTTPS no molestará al atacante. Una conexión a través de HTTP todavía es vulnerable, HSTS no cambiará esto. Cambiará de forma transparente de HTTP a HTTPS si existe una entrada HSTS válida.

Declaración 2: De nuevo, los navegadores solo deben actuar en los encabezados HSTS enviados a través de una conexión HTTPS. Si el atacante puede enviar ese (s) encabezado (s), no será molestado por HTTPS.

De todos modos, ¡Defensa en profundidad! Por eso no creo que el HSTS sea inútil. ¡Si actualiza inmediatamente todas las conexiones HTTP a una conexión HTTPS con redirecciones, sus usuarios pueden ser muy vulnerables en el transcurso de un año! Compare esto con la conexión inicial cuando use HSTS y un navegador que lo admita.

    
respondido por el Darsstar 01.09.2014 - 15:02
fuente
7
  

Verdadero o Falso: HSTS es absolutamente inútil contra los ataques MITM

Falso, HSTS protege contra ciertas categorías de ataques MITM pero no contra otras.

HKP (Sé que no preguntaste sobre esto, pero creo que no tiene sentido mirar uno sin mirar al otro) también protege contra ciertas categorías de ataques MITM pero no contra otros.

La combinación de HSTS y HKP protege contra un escenario de ataque que ninguno de los dos puede proteger.

Hay algunos tipos de ataques MITM que no se pueden proteger con la combinación de HSTS y HKP.

Veamos algunos escenarios. En todos los escenarios asumiré que example.com no está en ninguna lista de prelodios del navegador. También asumiré que enlace se redirige a enlace

Escenario 1:

El cliente visita enlace y no había visitado example.com antes de que MITM se hiciera público.

En este escenario, el MITM tendrá éxito. Simplemente puede interceptar la conexión inicial y evitar la redirección a https.

Escenario 2:

El cliente visita enlace . El atacante no posee un certificado que pase la validación de certificado normal de los navegadores.

En este escenario, la conexión https fallará la validación del certificado y el MITM fallará. HSTS y HKP no son necesarios.

Escenario 3:

El cliente visita enlace y había visitado example.com antes de que MITM se estableciera. El atacante no posee un certificado que pase la validación de certificado normal de los navegadores.

En este escenario sin HSTS, el MITM tendrá éxito. Simplemente puede interceptar la conexión inicial y evitar la redirección a https.

Con HSTS, el navegador nunca intentará establecer una conexión http simple, sino que se moverá directamente a https. La conexión https fallará en la validación del certificado y el MITM fallará.

Escenario 4:

El cliente visita enlace y no había visitado example.com antes de que MITM se estableciera. El atacante ha obtenido un certificado que cubre example.com de una CA en la lista de raíces confiables predeterminadas de los navegadores (por engaño, soborno, intimidación o lo que sea)

En este escenario, el atacante tiene éxito.

Escenario 5:

El cliente visita enlace y había visitado example.com antes de que MITM se estableciera. El atacante ha obtenido un certificado que cubre example.com de una CA en la lista de raíces confiables predeterminadas de los navegadores.

En este escenario sin HKP, el atacante tiene éxito. Con HKP, la validación del certificado falla.

Escenario 6:

El cliente visita enlace y había visitado example.com antes de que MITM se estableciera. El atacante ha obtenido un certificado que cubre example.com de una CA en la lista de raíces confiables predeterminadas de los navegadores.

En este escenario sin HSTS, el MITM tendrá éxito. Simplemente puede interceptar la conexión inicial y evitar la redirección a https.

En este escenario sin HKP, el MITM tendrá éxito. Puede MITM exitosamente la conexión https.

Con HSTS y HKP, el navegador nunca intentará establecer una conexión http simple, sino que se moverá directamente a https. La conexión https fallará en la validación del certificado gracias a HKP y el MITM fallará.

Escenario 7:

El MITM ha obtenido la clave privada para (uno de) los certificados legítimos del sitio

El MITM tendrá éxito

Escenario 8:

El MITM ha obtenido un certificado para exampe.com de una CA que se agregó manualmente a la lista de raíces de confianza.

Se omite HKP y el MITM se ejecutará correctamente. (Esto permite que los firewalls corporativos que inspeccionan https continúen funcionando, sea o no bueno, es discutible).

    
respondido por el Peter Green 07.01.2016 - 21:10
fuente
3

Otra forma en que HSTS podría verse comprometido sería si tuviera una CA raíz instalada en la computadora a la que se conectaba, lo que permitió que un atacante MITM pareciera ser el sitio web original.

Por ejemplo, Si estuviera utilizando una computadora de la empresa para conectarse a Gmail, la empresa podría interceptar el tráfico de la siguiente manera:

  • Los equipos de la empresa tienen instalada una CA raíz personalizada
  • La CA raíz personalizada se usa para firmar un certificado "malo" para Google
  • Su computadora se conecta a un dispositivo intermediario (por ejemplo, un firewall) usando este certificado "malo"
  • La comunicación se descifra y luego se vuelve a cifrar con el certificado original de Google.

Vea esta pregunta ¿Cómo puede mi empleador ser una persona de por medio cuando me conecto a Gmail?

    
respondido por el JonnyWizz 30.10.2015 - 14:09
fuente
1

Para responder a la pregunta original, "HSTS no sirve para MitM", la respuesta es a veces. Como han respondido otros, HSTS no se ve acosado por las dos afirmaciones que hizo. Sin embargo, hay diferentes maneras de romper HSTS y no tienen nada que ver con HSTS, TLS o certificados.

HSTS es un paso importante en la dirección correcta para la seguridad HTTP, pero desafortunadamente, otros componentes críticos aún no se han puesto al día. El DNS es una de las principales formas de romper, o más bien, subvertir los HSTS. Si un atacante es MitM en una red, eso significa que tienen la capacidad de falsificar las respuestas de DNS. Digamos que hay un cliente en la red que quiere conectarse a "accounts.google.com". El navegador del cliente sabe que este host utiliza HSTS y que debe conectarse a él solo a través de HTTPS. Sin embargo, el atacante está falsificando el DNS y ha agregado una entrada de CNAME tal que una búsqueda de DNS para "accounts.google.com" se resuelve como "accounts.google.con" (o cualquier otro nombre parecido), que a su vez resuelve una dirección bajo el control del atacante (tal vez un sitio web clonado o un proxy inverso). El navegador carga "accounts.google.con" a través de HTTP simple y lo más probable es que el usuario no se dé cuenta. Ahora, el atacante puede recopilar credenciales o realizar otros ataques MitM con facilidad.

En resumen, HSTS protege contra todo lo que está diseñado para proteger, pero la falta de integridad en DNS puede subvertirlo. Cosas como DNSSEC y DANE son la pieza que falta en este rompecabezas, pero aún faltan algunos años para que se adopte de forma generalizada.

    
respondido por el multithr3at3d 30.10.2015 - 15:58
fuente

Lea otras preguntas en las etiquetas