¿Impedir que un hombre engañe en el ataque central?

12

Estaba trabajando con mi rutina habitual de escuchar viejos videos de Defcon tratando de entender algunos de los aspectos básicos de lo que está sucediendo en el mundo de la seguridad de TI, cuando me encontré con un hombre que explicaba los ataques intermedios.

Así que me puse a pensar. Bueno, ¿qué podrías hacer realmente con eso? Luego pensé en un hombre extraño en el ataque central que me pregunto si funcionaría.

Así que todos sabemos que los enrutadores dirigen los paquetes a lo largo de su camino hacia donde vayan. Esto está bien y dandy. Sin embargo, ¿qué pasa si configura algo un poco más mal. Cuando llega un paquete (cuyo destino es uno de una lista de sitios precompilados), ¿qué sucede si pretendo ser ese destino? ¿Qué pasa si dices "Sí, soy paypal.com! ¡Permite establecer una conexión segura!". Luego haces una conexión segura con ese thingy . Después de hacer esto, podría establecer una conexión segura con PayPal y hacer todo lo que el usuario está haciendo, sin embargo, obtiene toda la información que desea (es decir, cuántas caras sonrientes está enviando a su hermano Steve).

El único problema que se me ocurre es que el paquete decide tomar una ruta diferente. No estoy seguro de esto, pero es posible que pueda decirle al otro sistema que está cambiando su blah blah blah , por lo que debería conectarse a su verdadero blah blah blah .

¿Hay algo por ahí para prevenir esto? No puedo pensar en nada, y la idea de que las personas puedan hacer esto es un poco aterradora ...

    
pregunta Griffin Nowak 07.04.2013 - 20:03
fuente

3 respuestas

16

Un enrutador que se porta mal y trata de actuar como un servidor falso con respecto al cliente, y un cliente falso con respecto al servidor verdadero, reenviando datos en ambas direcciones, es la definición exacta de a man-in-the-middle attack . Además de los enrutadores (que actúan a nivel de IP), los métodos prácticos clásicos para MitM incluyen:

(Esta lista no es de ninguna manera exhaustiva.)

Para vencer estos ataques, usamos autenticación de servidor que, en el caso de los sitios web SSL (como https://www.paypal.com ), usa certificados X.509 . Cuando el cliente (un navegador web) se conecta al servidor de Paypal, requiere explícitamente una "conexión segura" (porque la URL comienza con https:// , no http:// ) y rechazará el servidor a menos que el servidor utiliza un certificado que:

  1. es emitido por una de las CA raíz en las que el navegador confía en a priori (Verisign / Entrust / Thawte / lo que haya incluido el proveedor del navegador), y:
  2. contiene el nombre del servidor esperado en él ( www.paypal.com , como se especifica en la URL).

Si no coinciden, el navegador advertirá al usuario de una manera espectacular. El MitM tendrá éxito solo si uno de los CA hace el tonto (es decir, el CA emite un certificado que contiene www.paypal.com a alguien que no es el propietario del dominio paypal.com ), o el usuario hace el tonto (usando un La URL que dice www.paypal.com.evilhacker.com , o al no prestar atención a la advertencia de miedo que muestra su navegador), o la máquina del usuario ya está comprometida (por ejemplo, a través de algún malware que instaló una CA raíz fraudulenta).

En términos generales , SSL se ha diseñado para que la seguridad se mantenga independientemente de los mecanismos de transporte. La seguridad SSL no se basa en que los enrutadores se comporten "honestamente". SSL asume que todos los enrutadores son hostiles.

    
respondido por el Tom Leek 07.04.2013 - 20:28
fuente
5

Esto es para lo que son los certificados SSL. Su navegador tiene una lista de certificados de confianza y proveedores de certificados, y cuando un sitio dice que soy PayPal.com, su navegador sabe que el certificado es incorrecto.

Un hombre en el ataque central puede falsificar certificados o persuadirlo para que acepte un certificado incorrecto, y uno exitoso de hecho podría hacer lo que dice y robar su dinero. Sucede mucho.

Aunque no es tan aterrador como piensas. Se aplican las pautas habituales: mantenga su sistema actualizado, use antivirus, evite comportamientos dudosos en línea, etc.

    
respondido por el Rory Alsop 07.04.2013 - 20:34
fuente
4

La prevención de este tipo de problema depende del tipo de protocolo que se utiliza. Suponiendo que estamos hablando de acceso web (HTTP) aquí, entonces la defensa principal contra este tipo de ataque es una configuración SSL bien configurada combinada con cierta conciencia del usuario.

Si intenta interceptar el acceso a un sitio web cifrado con SSL, deberá presentar un certificado al usuario en el que pretende ser el sitio que está falsificando (en su ejemplo paypal.com).

Sin embargo, el navegador de los usuarios solo aceptará certificados que hayan sido firmados por ciertos certificados de "raíz confiable" (esto generalmente se define en la base por el navegador o el proveedor del sistema operativo).

Por lo tanto, como atacante, puede intentar usar un certificado que no sea de confianza (uno que usted mismo declara que es www.paypal.com), en cuyo caso el usuario recibirá una advertencia de que no se puede confiar en el certificado, o podría intentarlo. Presentar al usuario www.paypal.com sin cifrar y esperar que no se den cuenta. que dichas protecciones, como la fijación de SSL y HSTS, podrían hacer que este tipo de ataque sea más difícil o incluso imposible.

De cualquier manera, si tiene una configuración de tipo MITM, tiene un grado considerable de ataques que puede llevar a cabo. Para las conexiones a Internet, potencialmente la pieza más difícil sería llegar al punto de ser un hombre en el medio.

    
respondido por el Rоry McCune 07.04.2013 - 20:24
fuente

Lea otras preguntas en las etiquetas