¿Los ataques de "hombre en el medio" son extremadamente raros?

Mi recurso actual favorito para datos del mundo frío, duro y real es Informe de investigación de violaciones de datos de Verizon 2011 . Un extracto de la página 69 del informe:

  

Acciones

     

Las tres categorías principales de acción de amenaza fueron   Hacking, Malware, y Social. Los más comunes   tipos de acciones de piratería utilizados fueron el uso de   credenciales de inicio de sesión robadas, explotando puertas traseras,   y ataques de hombre en el medio.

Al leer eso, deduzco que es una acción secundaria utilizada una vez que alguien tiene un punto de apoyo en el sistema, pero los datos de la Unidad de Crímenes de Alta Tecnología de Holanda dicen que es bastante creíble para preocuparse. De las 32 violaciones de datos que conformaron sus estadísticas, 15 involucraron acciones MITM.

Definitivamente no te detengas ahí, sin embargo. Todo el informe es una mina de oro de la lectura y el mejor trabajo que he encontrado para demostrar dónde se encuentran realmente las amenazas.

Para obtener referencias más difusas a los ataques y métodos de MiTM, vea también esta excelente respuesta a los ataques MITM: ¿qué tan probables son? en Serverfault.

Iría más allá al decir que cualquier instancia de una raíz SSL que arroje un certificado incorrecto es una señal de un ataque, de lo contrario serían compromisos inútiles. Finalmente, debido a que soy ese chico , definitivamente trataría de unirme a su caja de red fuera del edificio si estuviera haciendo su Pentest. Uno puede hacer cosas increíbles con un programa de radio incluso en una conexión por cable.

La respuesta simple es no, hay una gran variedad de pruebas de que este tipo de ataque es común.

Algunos de los controles introducidos por los bancos (autenticación de dos factores, etc.) se requerían en parte para combatir los ataques MITM cada vez más comunes en los clientes.

Si bien hay otras formas de ataque (el compromiso del cliente es una buena) que ahora puede ser más fácil de llevar a cabo mediante el uso de malware para colocar un troyano en la PC del cliente, MITM sigue siendo relativamente fácil en la mayoría de los casos.

El hecho central a recordar es que los delincuentes tienden a trabajar con un buen retorno de la inversión. El ROI para un atacante es muy bueno:

• bajo riesgo de ser atrapado
• bajo riesgo físico
• algunos esfuerzos para codificar el exploit pueden llevar a ganancias monetarias del mundo real
• el código se puede reutilizar o vender a otros delincuentes

Como dijo @CanBerk, nunca vamos a tener ningún protocolo 'completamente seguro', pero hacer la vida más difícil para los delincuentes es una solución parcial. MITM no desaparecerá hasta que se haga demasiado difícil para ser rentable.

El reciente compromiso de la autoridad de certificación DigiNotar dio como resultado la emisión de más de 500 certificados falsos para google.com, microsoft.com, cia.gov y cientos de otros sitios. Estos certificados de alguna manera llegaron a 40 ISP iraníes diferentes, lo que resultó en un ataque masivo de hombres en el medio , se confirmó que ha afectado a más de 300,000 usuarios iraníes en el transcurso de varios meses .

El (los) hacker (es) responsable (s) - confirmó que es el mismo responsable de ataque anterior en el CA Comodo - afirma tener acceso completo a otros cinco CA, aunque él (ellos) solo nombrado uno de ellos .

Así que sí, Los ataques de hombre en el medio son una amenaza muy real , incluso hoy.

Nota: Para evitar que este tipo de ataques te ocurran, considera usar un programa / complemento para rastrear certificados en busca de cambios sospechosos, como Certificate Patrol , o pruebe uno de los nuevos reemplazos de lujo para el modelo de autoridad de certificados de lo que todos están hablando.

Esta respuesta es principalmente sobre la declaración de Chris Dixon más que por la respuesta "Cuántos ataques vienen de MiTM".

Si afirmamos la forma diferente en que uno podría convertirse en MiTM y las consecuencias dadas, creo que podemos llegar a algunas conclusiones sobre si nos importa o no la importancia de los ataques MiTM.

Si observamos algunos riesgos para las diferentes situaciones, podríamos tener algo como:

• ¿Alguien está robando la base de datos mediante la explotación de la aplicación web?
• Alguien que ataca al usuario / administrador a través de un ataque MiTM

Yo diría que el primero tiene un impacto mucho mayor (en general) y en muchos aspectos debería ser mitigado y tratado como el primero.

¡Entonces, para que el punto 2 prevalezca sobre el punto 1, creo que MiTM realmente tendría que estar loco para que lo valoremos tan alto como un obstáculo de seguridad como el punto 1 (como indica Chris en la cita)!

Ahora si vemos en los diferentes vectores de ataque. Primero para MiTM. Para convertirse en MiTM uno podría, por ejemplo:

• Poseer un punto de acceso inalámbrico no autorizado. Esto es trivial, pero para un ataque dirigido deberías estar en la misma ubicación física de la víctima con tu aplicación web.
• Detectar datos inalámbricos sin cifrar o datos que vienen a través de un HUB (¿ya existen?)
• Usa ARP Poisoning para atacar a los usuarios. No es trivial a menos que esté en la misma red que los usuarios objetivo que utilizan su aplicación web.
• Envenenamiento de caché de DNS. Para que esto funcione, necesita envenenar el DNS que utilizan los usuarios seleccionados. Si el DNS no está configurado correctamente, este ataque se vuelve algo trivial de realizar, sin embargo, hay mucho en que confiar para que esto funcione.
• Ataques de phishing. Estos todavía engañan a los usuarios ingenuos e ingenuos, sin embargo, gran parte de la responsabilidad es del usuario.

Todo esto solo para atacar a uno o un pequeño subconjunto de usuarios. Incluso entonces, atacar a estos usuarios les dará una advertencia en sus navegadores (también hay formas de atacar esto, pero no lo estoy tomando aquí). Solo al comprometer una CA raíz o al encontrar una falla en el algoritmo utilizado para generar los certificados, se le permitirá hacerse pasar por un emisor de certificados confiable.

Si, por otro lado, observamos todas las cosas potencialmente desagradables que podemos ver si no invertimos en la seguridad de la propia aplicación web, vemos vectores de ataque como:

• Inyección de SQL: trivial y fácil de explotar y descubrir. Daño muy alto impacto.
• XSS (Cross Site Scripting): fácil de descubrir, más difícil de explotar. Creo que veremos un impacto cada vez mayor en los usuarios de esto en el futuro. Preveo que esto se está convirtiendo en la tendencia de "nueva inyección de SQL" que hemos estado viendo en los últimos días.
• CSRF (falsificación de solicitud de sitios cruzados): moderada para descubrir, moderada para explotar. Esto requeriría que los usuarios naveguen a un sitio que ya es de su propiedad, lo que provocará una solicitud a su aplicación web que haría una transacción en nombre del usuario.

Entonces, solo mencionando estos pocos, pero los métodos populares para atacar la aplicación web y convertirse en MiTM lo dejarían para un análisis específico de riesgo / consecuencia de la organización específica que está tratando de asegurar, ya sea que defienda o no. usuarios directamente implementando SSL o defendiendo la aplicación web en su totalidad (que también incluye propiedad intelectual, datos de usuarios, datos confidenciales, datos potenciales que podrían violar otras aplicaciones, etc.).

En mi humilde opinión, estoy muy de acuerdo con la declaración de Chris Dixon. Priorice la protección de la aplicación web tanto como pueda antes de comenzar a pensar en proteger la capa de transporte.

Editar : En una nota al margen: páginas como Facebook, Gmail y otros sufrieron fuertes ataques de MiTM durante la estela de Firesheep. Esto solo podría ser mitigado a través de SSL y conocimiento.

Sin embargo, si lo piensa bien, detectar el tráfico inalámbrico con Firesheep y secuestrar las sesiones requeriría que la LAN inalámbrica a la que está conectado no tenga ningún cifrado.

Cuando hoy salgo a conducir en la guerra, ha disminuido drásticamente la cantidad de AP inalámbricos abiertos y también la cantidad de AP habilitados para WEP. Seguimos viendo más y más AP encriptados WPA2 que en la mayoría de los casos nos brindan suficiente seguridad.

Ahora, ¿cuál es el riesgo de que alguien cree una herramienta fácil y conveniente para detectar y secuestrar las sesiones de sus usuarios? ¿Cuál es el impacto para esos usuarios? También podría mitigarse de diferentes maneras (volviendo a autenticar al usuario cuando venía de diferentes huellas al mismo tiempo, notificando al usuario cuando algo se ve mal (gmail es un buen ejemplo de esto)).

No encontró ningún documento estático o blanco que incluya los datos del mundo real que quería tener.

Sin embargo, me gustaría agregar que los ataques MitM dentro de las empresas ocurren a diario y más de una vez. Varios proveedores de seguridad tienen soluciones para analizar el tráfico cifrado (por ejemplo, Palo Alto Networks ) y al menos la compañía Actualmente trabajo para ha activado esta función.

Para hacer esto, al dispositivo de firewall / proxy simplemente se le otorga un certificado de la Autoridad de Certificación (CA) interna en la que ya todos los clientes confían. Cuando una aplicación solicita una conexión segura, el firewall / dispositivo proxy genera un nuevo certificado para el servidor de destino sobre la marcha y lo envía al cliente. Dado que el cliente confía en la CA interna, también confía en el certificado del dispositivo y con gusto iniciará una conexión "segura".

Estoy de acuerdo con daramarak en que sería bastante difícil encontrar datos del mundo real sobre los ataques MitM. Una de las razones es que los ataques MitM son por naturaleza generalmente dirigidos a individuos, mientras que los ataques como DDoS o inyección SQL generalmente están dirigidos a compañías, organizaciones, etc.

Por lo tanto, si bien vemos un informe DDoS / injection / lo que sea casi todos los días, la información sobre los ataques MitM suele ser académica (por ejemplo, "¡Twitter fue DDoS'd" vs. "SSL es vulnerable a MitM")

Sin embargo, se debe tener en cuenta que "raro" no significa necesariamente "difícil". La mayoría de los ataques MitM son mucho más fáciles de manejar que la mayoría de los otros tipos de ataques, y muchos de los protocolos que utilizamos todos los días son vulnerables a tales ataques de una manera u otra, simplemente porque es bastante difícil diseñar un protocolo que sea completamente seguro contra MitM. De hecho, este es el caso de la mayoría de los problemas de seguridad, la mayoría de las soluciones son "mejor esfuerzo" en lugar de "completamente y absolutamente seguro".

Por lo tanto, creo que la razón principal por la que los ataques MitM son menos comunes es que generalmente no hay necesidad / incentivo para realizar uno.

Estoy bastante seguro de que detectar contraseñas en redes inalámbricas es extremadamente común. Solo mire cuántos tutoriales hay para él en la web desde un simple Búsqueda de Google o Búsqueda de Bing .

Bueno, supongo que si fueran raros, nadie comprometería a una AC, sin embargo, hemos visto varios intentos y algunos éxitos en esto (sospechosos, incluido Irán).

Así que supongo que tiene y se hará. De lo contrario, ¿por qué se molestan en comprometer a un CA. Esa no es la tarea más fácil del mundo. ¿Por qué no atacar directamente a tu objetivo?

Dicho esto, pueden ser raros. Cualquier persona que comprometa a una CA es lo suficientemente bueno como para cubrir suficientes pistas para que no sepamos el alcance de su trabajo. Sinceramente, no diría que el gobierno de EE. UU. Haya hecho lo mismo en el país y en el extranjero. En realidad me sorprendería si no lo hubieran hecho. Respaldando esto es que no puedo recordar haber leído nunca el HTTPS del gobierno de EE. UU. Lo escucho periódicamente con respecto al cifrado de Skype, TrueCrypt o al cifrado de disco PGP.