Me preguntaba si el siguiente escenario se podía alcanzar de manera realista.
Tenemos una red con una computadora que usa Bob. Él es una persona consciente de la seguridad y utiliza un administrador de contraseñas. Su computadora está conectada a Internet a través de un enrutador que Bob obtuvo de su ISP. El ISP y el fabricante del enrutador no han implementado actualizaciones para las vulnerabilidades críticas que tiene su enrutador.
Luego está Trudy, que realmente quiere saber las contraseñas de Bobs. Ella obtiene acceso completo a su enrutador a través de una hazaña. Hay un par de sitios web que le interesan, por lo que manipula las entradas de DNS para que apunten a un servidor web bajo su control. Como Trudy tiene mucho tiempo, se asume que la caché de DNS de la computadora de Bob se actualizará para contener las entradas manipuladas.
Bob se conecta a un sitio web en el que está interesado Trudy. Cree que está estableciendo una conexión con https://www.safewebsite.com , pero en realidad se está conectando al servidor web de Trudy. El servidor web baja la conexión a http simple, solo para establecer la conexión. Luego, el servidor web realiza una redirección a la URL real de sí mismo, por ejemplo. https://safewebsite.evil.com para el que Trudy tiene un certificado SSL válido (simple). Suponiendo que Bob no mira demasiado de cerca, no ve la diferencia en la barra de direcciones.
Como alternativa, Trudy consigue que Bob visite su servidor web de una manera que no active una excepción de certificado no válida.
Lo que Trudy debe hacer para extraer la contraseña de Bobs es incrustar el sitio web válido que Bob quería visitar. Esto también es menos trabajo para Trudy, ya que no quiere codificar un sitio web de phishing, sino que quiere engañar al administrador de contraseñas de Bob. Cuando Bob visita el sitio web malicioso de Trudy, el administrador de contraseñas ingresa sus credenciales en el sitio web incorporado, porque cree que esta es una conexión válida. Luego, una secuencia de comandos del sitio web de Trudy toma el contenido del campo de contraseña y el nombre de usuario, y los envía al servidor web.
Ahora Trudy tiene algo con lo que está luchando, muchos sitios web tienen la opción x-frame configurada para negar. Esto frustra el intento de Trudy en muchos casos. Tiene la idea de dejar que el Router huela para los paquetes que contengan la opción x-frame. Entonces sería modificado o eliminado. Entonces, si Bob visita el sitio web malicioso de Trudy, solicita el sitio web real incorporado y el enrutador realiza un MITM activo. Esto significa que el enrutador se conecta a https://www.safewebsite.com y solo le da a Bob la versión http. Bob todavía vería el https://safewebsite.evil.com , sin indicar un cambio visual en comparación con la versión anterior del ataque. La pregunta es si el enrutador podría eliminar o modificar la opción x-frame de una manera que no afecte la experiencia de navegación de Bob.
Esperemos que la idea sea clara. Si ve algo que no es realista, por favor deje un comentario. Tal vez tengas una idea aún más sencilla de cómo lograr esto.
Este es un escenario de ataque contra un administrador de contraseñas específico (que no se nombrará aquí) que me gustaría usar en una presentación para un curso en la universidad, pero solo si es plausible.
Actualizar
A pesar de que lo supe y lo he pensado varias veces, la idea escrita anterior tiene un defecto crucial, www.safewebsite.com tendría que cargarse como https; de lo contrario, el administrador de contraseñas no llenaría los datos. Trabajaré en el escenario y publicaré una versión actualizada.
Actualización 2
Parece que el administrador de contraseñas tiene un problema de seguridad al completar las credenciales en iframes. Sin embargo, el escenario es defectuoso y las respuestas son correctas para la pregunta original. Si el nuevo escenario funciona, primero me pondré en contacto con los desarrolladores y, posteriormente, lanzaré más información sobre el problema.