¿Podemos prevenir ataques basados en DNS con SSL / TLS? [duplicar]

Navega tus respuestas
0

Considere el siguiente escenario dando un ataque hipotético:

  • Crypto.com está vendiendo cryptostocks y acepta pagos usando un procesador de pagos PayEasy.com. Las páginas completas del sitio (de crypto.com) se sirven utilizando HTTPS.

  • Mientras viaja a un país extranjero, Bob visita crypto.com en su computadora portátil desde la red de su hotel y hace clic en el botón "comprar ahora" para obtener 10 cryptostocks. Se reenvía a PayEasy.com mediante un enlace. <a href='https://PayEasy.com/pay?amt=100&id=bob'/>

  • Un atacante (como el ISP) se las arregla para redirigir todo el tráfico destinado a PayEasy.com de la computadora de Bob a un sitio falso que ha configurado llamado PayEazy.com . Cuando Bob realiza una consulta de DNS para PayEasy.com, el atacante devuelve la dirección IP de PayEazy.com. Este sitio también tiene una conexión HTTPS usando un SSL genuino obtenido de una CA usando "domain-validation ". El certificado confirma que el sitio es servido por payeazy.com. Un atacante debe hacer esto, ya que de lo contrario, el navegador de Bob dará una advertencia y puede fallar el ataque. Por lo tanto, Bob hace clic en un enlace equivalente a <a href='https://PayEazy.com/pay?amt=100&id=bob'/>
  • Bob nunca sospecha nada porque ve la barra verde y ni siquiera se ha molestado en leer en el sitio de crypto.com que usa PayEasy.com. Incluso si Bob sabía que PayEasy.com es el procesador de pagos de crypto.com, no nota la leve diferencia en PayEazy.com. Bob hace el pago de $ 100 por 10 cryptostocks y espera, pero nunca llegan.
  • Bob asume que Crypto.com es un estafador y los demanda. A medida que se desarrolla el caso, los abogados de Crypto.com le piden a Bob que pruebe que Crypto.com lo envió a enlace en lugar de enlace . Bob no puede probar esto y pierde. El caso podría haber sido de cualquier manera, ya que incluso Crypto.com no pudo probar que efectivamente enviaron a Bob a enlace y no a enlace

En primer lugar, este ataque es realista. En segundo lugar, ¿cómo prevenirlo? (Esto es similar al ejemplo dado en el artículo PalmPilot de Schneier )

Como ejemplo de este ataque: enlace es un enlace seguro a google.com . Suponiendo que este sitio ( security.stackexchange.com ) se sirve a través de HTTPS. Ahora edite su ' hosts.file ' para que la dirección IP de google.com apunte a yahoo.com y haga clic en el enlace anterior.

    
pregunta Jus12 15.01.2016 - 17:18
fuente

2 respuestas

1

No. Esta es exactamente la razón por la que tenemos PKI: para evitar este tipo de ataque de envenenamiento de DNS que está describiendo.

Esto es lo que sucedería en el caso que está describiendo (incluidos los comentarios), después de que Bob haga clic en el enlace a enlace . Primero, el navegador de Bob haría una búsqueda de DNS para PayEasy.com.

Supongamos que el atacante (el ISP de Bob o su proveedor de WiFi) logró devolver una dirección IP falsa para PayEasy.com y devuelve una dirección IP a un servidor web que controla el atacante.

Bien, ahora el navegador de Bob se conecta al servidor web del atacante. Pero, aquí radica el problema, el servidor web del atacante entrega un certificado para PayEazy.com. En este punto, el navegador de Bob sabe que algo está mal, porque el navegador solicitó PayEasy.com, ¡no PayEazy.com! El navegador de Bob le mostraría una advertencia de la falta de coincidencia del certificado, y Bob debería dejar de conectarse con el sitio.

    
respondido por el mti2935 15.01.2016 - 18:04
fuente
0

En realidad, en caso de que lo hayas descrito (procesamiento de pagos) hay una cosa que te has perdido: proveedor (Crypto.com) < - > interacción payment_processor (PayEasy.com). He implementado tales vínculos, y así es como funciona:

  1. el proveedor realiza una devolución de llamada al procesador: "dame un ID de transacción para detalles completos de la transacción". Sus firmas se comprueban entre ellas mediante los certificados que han intercambiado anteriormente
  2. el proveedor recibe la identificación y redirige a Bob a enlace ... No "id = bob", "cantidad = 100 ": toda esta información y muchas otras se pasaron YA en el paso 1
  3. Bob ve TODOS los datos en su navegador, y solo después de eso aprueba el pago.

Incluso puede registrar enlace también como proveedor, pero por parte de Bob será nombre de comerciante diferente en pago confirmación, y esta página de confirmación estará firmada por HTTPS por PayEasy SSL cert. Eso es todo

    
respondido por el Alexey Vesnin 15.01.2016 - 18:34
fuente

Lea otras preguntas en las etiquetas

¿Cómo reanudo un ataque de diccionario usando un número inicial personalizado? Confiando en los datos de una API