Realmente busqué una respuesta a esto, pero mi terminología es deficiente. Si un atacante estuviera en una posición MiTM ejecutando un proxy, ¿no sería posible para ellos detectar un binario como un archivo .exe o .pdf e implantar algunas instrucciones maliciosas o intercambiar completamente el archivo con algo malo?
Para aclarar: ¿Conoce algún software, papel o charla sobre esto?
Sí. Se puede hacer. Lo he hecho personalmente con python, usando un script que escribí llamado the-backdoor-factory e implementando un proxy en python. Una vez que haya instalado el sistema de parches, casi cualquier proxy funcionará. Solo deberá buscar la aplicación / octet-stream en el html, recuperar el binario, parchearlo y enviarlo al cliente. Publicaré un artículo completo en línea una vez que tenga un programa estable para las pruebas de la comunidad.
Aquí hay un video del POC en el que estoy trabajando: enlace
Lo que estás viendo en el video es mi POC a la izquierda escrito en python y la 'víctima' a la derecha navegando a través del proxy. El proxy busca binarios y solo intercepta PE / COFF en este momento. Una vez que el binario es parcheado, reenvía el binario al usuario, como se puede ver, es muy rápido.
Sí lo harían. Yo diría que inyectar código malicioso en un archivo .exe o .pdf sería difícil sin dañar la integridad del archivo hasta el punto en que rompe el archivo, lo más probable es que un reemplazo absoluto sea más inteligente, pero tendría que tener un tamaño de archivo similar o podría despertar sospecha. Como el objetivo está esperando un archivo, las sospechas serían bajas.
En general, no puede confiar en nada en una conexión no segura en ninguna red en la que pueda estar presente un MITM (es decir, no tiene el control físico completo y la seguridad del enrutamiento y el cableado). Un Man in the Middle podría monitorear y alterar cualquier conexión no segura pretendiendo ser usted al host y pretender ser el anfitrión para usted. Ningún sistema sería consciente de la presencia. El archivo podría reemplazarse por completo o el archivo ejecutable podría modificarse o reemplazarse para hacer cosas maliciosas con bastante facilidad.
Hay, sin embargo, varias formas de prevenir esto. Las conexiones autenticadas, como HTTPS, garantizan que solo dos puntos finales (al menos uno de los cuales es de confianza) pueden comunicarse. En resumen, el servidor HTTPS tiene una información especial que el navegador puede validar y es el servidor que usted cree que es. Esa información se puede usar para enviar una clave generada por su cliente al servidor de confianza de una manera que solo el servidor pueda entender. Debido a que MitM no conoce la nueva clave compartida, el servidor puede responder utilizando esa clave para cifrar la conexión y MitM ya no puede observar ni alterar el contenido significativo de esa comunicación y cualquier alteración haría que apareciera como una tontería ( o posiblemente ser detectado en base al protocolo en uso).
Otra técnica se llama sumas de comprobación. Una suma de comprobación es una pequeña pieza de información que se puede proporcionar de forma independiente para validar un archivo mucho más grande. Por lo general, consiste en un hash del archivo que se está enviando, que luego puede volver a aparecer después de su recepción para garantizar que el archivo no tenga ningún error en la transmisión. Si la suma de comprobación y el archivo se obtienen de diferentes conexiones, es un poco más difícil para MitM alterar ambas, sin embargo, todavía podría ser posible modificar ambas. La suma de control también podría ser firmada criptográficamente por el distribuidor de archivos para garantizar que MitM no pueda modificar la suma de control.
El mejor método es combinar los dos enfoques e incluir una suma de comprobación firmada criptográficamente que valide que el archivo provino del remitente y que también lo comunique a través de una conexión segura. Esto garantiza que los datos no se dañen durante la transmisión y también garantiza que provengan del host esperado.
El hombre en el medio puede hacer casi cualquier cosa con datos que pasan. La única defensa es el uso de claves / firmas que no pasaron por el atacante, por ejemplo, se entregaron antes de la inyección o por otro medio. Por supuesto, debe recordar que las claves también podrían verse comprometidas en algún momento en el futuro.
Lea otras preguntas en las etiquetas man-in-the-middle