La página de phishing era la página real
Un kit llamado Bluekit ya no construye una pantalla de inicio de sesión falsa. Te transmite la genuina desde un navegador que el atacante controla, captura tu sesión en el momento en que inicias sesión y supera la MFA. Una passkey lo detiene donde un ojo más afinado para las falsificaciones no puede, y por eso Bromure permite que un perfil comparta solo passkeys desde tu Mac.
Durante veinte años, vencer al phishing significó aprender a detectar la falsificación. El browser-in-the-middle no te da nada que detectar. Te muestra la página de inicio de sesión real y te roba la sesión en vivo mientras miras. Lo que lo detiene es una credencial que no puedes copiar.
Recibes un mensaje sobre un documento compartido, un inicio de sesión marcado, una factura. Haces clic. Se abre una página de inicio de sesión de Microsoft, y es la real: las fuentes correctas, el logo correcto, la pequeña animación cuando pasas de un campo a otro con el tabulador, el aviso genuino de multifactor que hace vibrar tu teléfono. Lo apruebas. Ya estás dentro. Nada pareció ir mal, porque casi nada iba mal. La página en la que escribiste era la página de inicio de sesión de Microsoft. Pero no eras tú quien hablaba con ella.
A finales de junio, Harry Everett, de Netcraft, documentó cómo un kit de phishing llamado Bluekit daba este salto, y BleepingComputer lo cubrió la misma semana. Bluekit se vende como servicio: un kit de phishing alojado con plantillas para Outlook, Gmail, iCloud, GitHub y una o dos carteras de criptomonedas, además de un asistente integrado para redactar el correo señuelo. Su nuevo truco lleva un nombre que ronda desde que un investigador conocido como mr.d0x lo describió en 2022: browser-in-the-middle.
La página real, transmitida hasta ti.
El phishing de la vieja escuela construye una falsificación. Alguien clona la página de inicio de sesión, la aloja en un dominio parecido y espera que no mires la barra de direcciones. La defensa creció en torno a eso: detectar la falsificación, atrapar la errata en la URL.
Después llegó un kit de proxy inverso como Evilginx. No clona la página. Se sitúa en medio de la conexión, un «adversary in the middle», y pasa tu tráfico hacia el sitio real, raspando la cookie de sesión según fluye. (Esa cookie es el pequeño token que un sitio entrega a tu navegador tras el inicio de sesión, para dejar de pedirte la contraseña en cada clic.) Robarla derrota a la mayoría de los inicios de sesión multifactor, porque el atacante se lleva la prueba de un inicio de sesión completado en lugar de la contraseña.
El browser-in-the-middle es más extraño y, en cierto modo, más simple. El atacante ejecuta un navegador de verdad en su propio servidor y lo apunta a la página de inicio de sesión genuina. Una biblioteca de código abierto llamada rrweb, creada para reproducir sesiones de usuario, serializa esa página en vivo y te la transmite por un WebSocket, un canal persistente y bidireccional entre tu navegador y el suyo. Tu navegador renderiza la estructura de la página real como si la hubieras cargado tú mismo. No estás viendo una captura de pantalla ni un vídeo. Estás controlando a distancia un navegador que está dentro de la tienda genuina, y tus pulsaciones de teclado, tu ratón y tu aprobación de multifactor se retransmiten de vuelta hacia él. Cuando el inicio de sesión se completa, se completa en su navegador, y su servidor acuña el token de sesión. Han sido dueños de tu sesión desde el primer segundo.
¿Por qué tomarse la molestia? Porque convence de una forma en que un clon nunca lo hace. No hay página falsa que pueda salir mal. Y como el atacante usa un único navegador consistente para hablar con el sitio real, el inicio de sesión no dispara las alarmas de desajuste de huella (las pequeñas inconsistencias entre tu dispositivo y el de un proxy) que a veces delatan a un kit de proxy inverso. Netcraft contó alrededor de setenta hostnames nuevos de Bluekit en una sola semana. Eso es lo que produce un producto.
Lo que no lo detiene.
Empecemos por las malas noticias, porque hay muchas.
La autenticación multifactor, en sus formas habituales, no detiene esto. Un código de un solo uso y una aprobación push prueban lo mismo, que un inicio de sesión está ocurriendo ahora mismo, y el ataque necesita que ese inicio de sesión ocurra, porque el atacante es quien inicia sesión. Tú haces la prueba. Ellos se quedan con la sesión.
El endurecimiento de sesión más reciente ayuda menos de lo que cabría esperar. Netcraft señala que las Device Bound Session Credentials, un esquema que ata una cookie de sesión al dispositivo en el que se emitió, «no pueden proteger contra el Browser-in-the-Middle, aunque sí ofrecen cierta protección contra el Adversary-in-the-Middle». La sesión nace en el dispositivo del atacante, así que atarla a ese dispositivo protege al atacante, no a ti. Cualquier cosa atornillada después del inicio de sesión llega demasiado tarde, porque para entonces el atacante posee la sesión por derecho.
El aislamiento tampoco lo detiene, y conviene decirlo con claridad. Un navegador que ejecuta cada pestaña en una máquina virtual desechable, como hace el nuestro, contiene lo que una página puede hacerle a tu ordenador. El browser-in-the-middle no le hace nada a tu ordenador. Toma prestadas tus manos para un único inicio de sesión y guarda el resultado en un servidor que nunca verás. Puedes tirar tu propia sesión en el momento en que cierras la pestaña. La copia que importa nunca estuvo de tu lado para poder tirarla. La desechabilidad defiende contra una larga lista de ataques, y el browser-in-the-middle no está en la lista.
Lo que sí lo detiene.
Aquí no ayuda ningún mejor detector de páginas falsas, porque no hay página falsa. La solución es una credencial que el atacante no puede copiar.
Las contraseñas y los códigos de un solo uso comparten una propiedad fatal: son cadenas de texto. Escribes una cadena en una página transmitida, el cable la transporta y el navegador del otro extremo la reproduce. Ese es todo el modelo de negocio.
Una passkey es una clave privada que vive en tu dispositivo y nunca lo abandona. Iniciar sesión significa que tu Mac firma un reto de un solo uso después de que lo apruebas con Touch ID, y la firma que devuelve está atada al sitio web exacto para el que creaste la passkey. De ahí se siguen dos consecuencias, y ambas rompen el browser-in-the-middle.
Primero, no hay nada que escribir, así que no hay nada que retransmitir. El secreto nunca aparece en la página, nunca cruza el WebSocket y nunca se queda en un campo de formulario para que rrweb lo transmita de vuelta. El navegador del atacante puede pedir cuanto quiera; la firma ocurre en un chip de tu Mac al que el servidor del atacante no puede llegar.
Segundo, la passkey de tu banco real está registrada en el dominio de tu banco real. Cuando el host del atacante sirve la página frente a ti, tu Mac busca una passkey que no existe ahí y no ofrece nada. El inicio de sesión que debería costar un solo toque no ocurre. Ese silencio, el autocompletado que nunca se dispara y la passkey que no está en la lista, es el aviso que la barra de direcciones falsa solía darte y que ya no puede.
Dos maneras de prestar las credenciales de tu Mac.
El diseño del navegador importa aquí, porque una passkey solo te defiende si llega al lugar donde inicias sesión.
Bromure ejecuta cada sesión de navegación dentro de una máquina virtual de Linux desechable en tu Mac, un pequeño ordenador aparte que borra cuando cierras la ventana. Eso contiene bien las páginas hostiles, pero plantea una pregunta obvia: si el navegador vive en una máquina desechable, ¿de dónde salen tus inicios de sesión guardados? Bromure te hace elegir, por perfil, y divide la elección en dos interruptores a propósito.
Usar Contraseñas de macOS
La opción amplia y cómoda. La sesión autocompleta nombres de usuario y contraseñas desde las contraseñas guardadas de tu Mac y el Llavero de iCloud, y el propio almacén de contraseñas de Chromium queda inactivo. Sigue atada al dominio, así que no autocompletará en el host del atacante. Pero una contraseña es una cadena, y una persona decidida puede teclearla a mano. Comodidad, con un punto débil.
Usar Passkeys de macOS
La opción estrecha y resistente al phishing. La sesión se autentica con passkeys guardadas en tu Mac, y Touch ID o tu contraseña controlan cada solicitud. Puedes activar esto dejando desactivado el uso compartido completo de contraseñas: solo passkeys. Nada que escribir, nada que retransmitir, nada que ofrecer en el dominio equivocado. Este interruptor deja el browser-in-the-middle fuera de juego.
Separarlas es la idea. Compartir todo tu Llavero con una sesión es el valor predeterminado cómodo; compartir solo passkeys es la opción inmune al ataque de este artículo. El modo solo-passkeys tiene su propio interruptor, así que la elección resistente al phishing te cuesta una palanca en lugar de un proyecto de seguridad. Puedes ejecutar un perfil con exactamente una forma de autenticarte, la que no puede transmitirse fuera de tu pantalla.
Lo que esto no resuelve.
Una palanca no es un campo de fuerza, y los límites importan.
El grande conviene repetirlo. Si inicias sesión con una contraseña a través de una página de browser-in-the-middle, aunque haya un código de un solo uso o un push detrás, el atacante obtiene una sesión que funciona, y nada en una VM desechable ni en un navegador ingenioso la recupera. El uso compartido de solo passkeys protege los inicios de sesión donde usas una passkey, y ningún otro. Muchos sitios todavía no las ofrecen, y para esos el viejo consejo es el único consejo: no sigas enlaces de inicio de sesión que vengan en mensajes, abre el sitio tú mismo.
La detección ayuda, y Bromure la usa: DNS filtrado que bloquea dominios maliciosos conocidos, y una comprobación de phishing por IA que puntúa la URL y la estructura del formulario de una página antes de que actúes. Ambas reducen las probabilidades. Ninguna es una garantía, y el browser-in-the-middle está diseñado para dificultar la detección. Setenta hostnames nuevos a la semana superan a la mayoría de las listas de bloqueo, y un escáner de contenido no encuentra ninguna página falsa que marcar. La detección atrapa al atacante descuidado. Las credenciales resistentes al phishing atrapan al cuidadoso.
Y el límite más corriente de todos: a una persona se la puede convencer de muchas cosas. Si un mensaje convincente te lleva hasta un sitio sin passkey y escribes una contraseña que reutilizaste en otro lugar, ninguna configuración del navegador estuvo nunca en ese circuito. El uso compartido de solo passkeys no te hace invencible. Para los inicios de sesión que más importan, tu correo, tu host de código, tu proveedor de identidad, elimina la cadena que el atacante venía a buscar y deja una clave a la que no puede llegar.
La barra de direcciones falsa se jubila.
El consejo que repetimos durante dos décadas (revisa la URL, busca el candado, duda de la página) daba por hecho que el atacante tenía que falsificar algo. El browser-in-the-middle no falsifica nada. Te entrega el artículo genuino y se queda detrás de él con la bolsa abierta.
La conclusión honesta: un navegador que pone la seguridad primero no te hace inmune a esto, y preferimos decirlo a fingir lo contrario. La respuesta se trasladó de tus ojos a tus credenciales. Frente a una página que no puedes distinguir de la real, la defensa duradera es iniciar sesión con algo que no puedes copiar: una passkey, firmada en tu Mac, atada al dominio real, nunca ofrecida al del atacante. La parte de Bromure es pequeña y específica. Hace que eso sea el valor predeterminado fácil al permitir que un perfil comparta passkeys y nada más. Instálalo, activa solo-passkeys para las cuentas que no puedes permitirte perder, y deja que la próxima página de inicio de sesión de aspecto perfecto te pida un secreto que ya no tienes que darle.