Sigue a ZDNET: Agréganos como fuente preferida en Google.
Takeaways de llave de ZDNET
- Un investigador desarrolló una exploit que secuestra la autenticación de PassKey.
- La exploit depende de una combinación no trivial de condiciones preexistentes.
- Ni los Passkeys ni el Protocolo se demostró que eran vulnerables.
En la Conferencia Def Con de este año en Las Vegas, investigador de seguridad de White Hat Marek Tóth demostró cómo los actores de amenaza podrían usar un ataque de clickjack para activar y secuestrar subrepticiamente una ceremonia de autenticación basada en Passey.
En el panorama general, esta es una historia sobre cómo los administradores de contraseñas podrían engañarse para divulgar la información de inicio de sesión, ya sea credenciales tradicionales, como ID de usuario y contraseñas o artefactos similares a las credenciales asociados con las veras pasas, a los actores de amenaza.
¿Los administradores de contraseñas tienen la culpa? Tóth, el investigador que descubrió la hazaña, sugiere que lo son, pero la respuesta es más complicada.
Bloquear completamente cualquier proceso automatizado es invariablemente el resultado de la seguridad en las capas. En la gran mayoría de los casos de uso donde importa la seguridad digital, casi nunca hay una sola bala de plata que elimine a los piratas informáticos. Dependiendo de las capas de tecnología que se combinan para completar un flujo de trabajo (por ejemplo, iniciar sesión en un sitio web), las partes que controlan cada una de esas capas comparten la responsabilidad de la seguridad de ese proceso que controlan cada una de esas capas.
Sí, los administradores de contraseñas son una capa para detener el exploit. Pero los operadores de sitios web y los usuarios finales, las partes en control de las otras capas, deben intercambiar demasiada seguridad por conveniencia para que la exploit funcione. Señalar los dedos es inútil. Todas las partes en cada capa deben tomar medidas.
Las grandes ideas detrás de Passkeys
Cada verano, la industria de la ciberseguridad se reúne en Las Vegas para el consumo de atrás Sombrero negro y Def con Conferencias, donde los investigadores de seguridad se turnan para presentar sus «grandes revelaciones». Durante el año previo al evento, estos investigadores trabajan para descubrir nuevas vulnerabilidades no reportadas. Cuanto mayor sea la vulnerabilidad y cuanto más afectados los usuarios afectan, mayor es la atención (y posiblemente la recompensa financiera) que espera a un investigador.
Este año, varios investigadores anunciaron un puñado de problemas que desafiaron la supuesta superioridad de los pases de control como una credencial de inicio de sesión.
Aquí en ZDNet, he estado escribiendo mucho sobre Passkeeys y por qué, desde la perspectiva de seguridad y técnica, son inmensamente mejores que las ID de usuario y las contraseñas (incluso cuando están involucrados factores adicionales de autenticación).
Las tres grandes ideas detrás de Passkeys son:
- No se pueden adivinar en la forma en que las contraseñas a menudo pueden (y lo son).
- El mismo PassKey no se puede reutilizar en diferentes sitios web y aplicaciones (la forma en que las contraseñas pueden).
- No puede ser engañado para que divulguen sus referencias a actores maliciosos (la forma en que las contraseñas pueden).
Desafortunadamente, a pesar de su superioridad, la experiencia del usuario de PassKey varía tan salvajemente de un sitio web y la aplicación (colectivamente, «depender de las partes») a la siguiente que los usuarios se arriesgan a nivel mundial. A pesar de estas barreras para la adopción, y en nombre de hacer lo más para protegerse (a menudo de usted mismo), mi recomendación sigue siendo: Aproveche las veras pasas siempre que sea posible.
En aras de brindar consejos sólidos a los lectores de ZDNET, siempre verifique la veracidad de cualquier titular que desafíe la viabilidad y la seguridad superior de las veras pasas. Surgieron varios informes del Hat y Def Con de este año, citando posibles problemas en Passkey Paradise. El que recibió la mayor atención provino de TótoOMS — bajo una combinación de condiciones previas técnicas muy específicas -ha descubierto una forma de secuestrar autenticaciones basadas en Passkey, mientras que esas autenticaciones están en progreso.
Mi investigación involucró a largas comunicaciones con Tóth, funcionarios de la Alianza FIDO (la organización responsable del desarrollo y promoción del estándar PassKey), un desarrollador de un complemento llave en mano que permite sitios web para la autenticación basada en PassKey y los proveedores de varios administradores de contraseñas. ¿Por qué los administradores de contraseñas? Desde la perspectiva del usuario final, es imposible participar en la autenticación basada en PassKey, técnicamente conocida como una «ceremonia de autenticación», sin la ayuda de un administrador de contraseñas. Juegan un papel clave en los hallazgos de Tóth.
En cuanto a la especificación de la credencial de Fido2 PassKey en sí, Tóth me dijo: «El protocolo en sí es probablemente seguro. No lo he probado ampliamente, ya que no fue el foco de mi investigación». En otras palabras, no sugiere que los propietarios mismos sean inseguros. De hecho, la investigación de Tóth también cubre las ID de usuario y las contraseñas, y sus hallazgos esencialmente demuestran que esas credenciales tradicionales son mucho más explotables de lo que nunca será la versión de pasas adecuadas.
Sin embargo, a través de una combinación de gestión de sitios web descuidada e indiferencia del usuario cuando se trata de configurar de forma segura sus administradores de contraseñas, existe una oportunidad previamente no revelada para que los actores maliciosos secuestren una ceremonia de autenticación basada en Passey mientras está en progreso. Esto es cierto a pesar de que los mismos pases no pueden ser robados.
En lugar de señalar su dedo a la especificación de FIDO2 o los operadores de sitios web descuidados, Tóth culpa principalmente a los administradores de contraseñas, quienes, en su opinión, podrían haber hecho más para proteger al usuario de su exploit.
«No, no es solo culpa del operador del sitio web», me escribió Tóth por correo electrónico. «Pero también los proveedores de contraseñas, ya que la vulnerabilidad está en su software». En piar Donde Tóth resume algunos de sus hallazgos, él llama a 12 administradores de contraseñas (incluidos todos los populares) por su nombre como vulnerables en una extensión u otra.
Si los diversos administradores de contraseñas son realmente vulnerables depende de su definición de «vulnerabilidad». Ninguno de los proveedores de administración de contraseñas con los que contacté estuvo de acuerdo con la afirmación de que su administrador de contraseñas tenía una vulnerabilidad.
Sin embargo, dados los permisos agresivos del navegador que los usuarios deben otorgar a sus administradores de contraseñas en el momento de la instalación (los mismos permisos que permiten que un administrador de contraseñas evite el uso de las aplicaciones SaaS no autorizadas), los administradores de contraseñas están en una posición única para detectar y evitar esta y otras amenazas antes de que se haga daño.
No es sorprendente que algunos de los administradores de contraseñas estén lanzando nuevas versiones para abordar la exploit de Tóth.
El corazón del ataque
Aunque la exploit ocurre en el abrir y cerrar de ojos, implica un conjunto complicado de interacciones y condiciones previas que, en conjunto, presentan una serie de obstáculos no triviales a las posibilidades de éxito del atacante. En su fondo, la exploit de Toth nunca roba el PassKey de un usuario (uno de los principios principales de Passkeys es que no pueden ser robados). Pero esencialmente roba la siguiente mejor opción.
En el momento en que un usuario es engañado para que se autentica inadvertidamente a un sitio web con una clave de passación, el exploit intercepta una carga útil de información que fue fabricada por el Administrador de contraseñas del usuario con la ayuda de su PassKey a ese sitio. Como se describe en la Parte 5 de mi serie sobre cómo funcionan los passkeys, esta carga útil se llama PublicKeyCredential, y es como un boleto de oro de un solo uso único que contiene todo lo necesario para que el usuario inicie sesión en su cuenta en el sitio web legítimo. Una vez que el atacante gana posesión de este boleto de oro, se puede usar para registrar el sistema del atacante en la cuenta de la víctima como si el sistema del atacante fuera el sistema de la víctima.
Y eso es exactamente lo que hace este exploit.
Después de cargar malware en el navegador de la víctima, el exploit, un script de sitio cruzado malicioso (XSS), intercepta ese boleto dorado y, en lugar de presentarlo para ingresar al sitio legítimo (como el navegador del usuario suele hacerlo a pedido del administrador de contraseñas), lo envía al sitio web del atacante. Luego, con ese boleto de oro en la mano, el atacante envía ese mismo boleto de su propio sistema al sitio web legítimo, registrando efectivamente el sistema del atacante en la cuenta del usuario en el sitio web legítimo.
Pero, como se mencionó anteriormente, el descubrimiento de Tóth se basa en la preexistencia de varias condiciones que involucran el sitio web en cuestión, la elección del usuario del administrador de contraseñas del usuario, cómo tienen ese administrador de contraseñas configurado y la elección de tecnología del operador del sitio web para agregar la capacidad de autenticarse con una clave de passey. Ya sea que sea un usuario final, el operador de un sitio web o el proveedor de un administrador de contraseñas, es importante comprender estas condiciones porque, una vez que lo haga, también comprenderá la defensa. También puede juzgar por usted mismo que entre las partes involucradas es más responsable de la vulnerabilidad.
Si bien Tóth señala su dedo a los administradores de contraseñas, creo que el operador del sitio web sería principalmente culpable si un actor de amenaza real utilizara esta exploit en la naturaleza. Dejando de lado por un momento el desafío de lograr que la víctima se encuentre con el malware (un JavaScript de sitios cruzados malicioso que se ejecuta en el navegador de la víctima), hay dos configuraciones que frustraron el ataque que todo operador de sitios web profesional debería saber.
Llega un momento durante la ceremonia de autenticación de PassKey, una vez que el usuario ha indicado el deseo de iniciar sesión con una tecla PassKey, cuando el sitio web responde al usuario con un desafío como parte de una carga útil más grande llamada PublicKeyCredentialRequestOptions. Al igual que cada respuesta de un servidor web, esa respuesta también incluye varios parámetros conocidos como encabezados HTTP, uno de los cuales puede usarse para establecer una sesión de comunicación específica con el sistema del cliente utilizando una cookie codificada de forma única, y luego para configurar esa cookie como una cookie httponly.
Una versión simplificada de ese parámetro de encabezado, conocido como el parámetro Set-Cookie, puede verse algo así (como parte de una transmisión más grande desde el servidor web al navegador del usuario):
Set-Cookie: session_id=123456789abcdefg; HttpOnly
Cuando se configura un servidor web para incluir un encabezado como este durante el intento de un usuario de autenticarse con una tecla Passey, coloca permanentemente el desafío (y el resto de la conversación entre el navegador y el servidor web del usuario) al ID de sesión especificado. Una vez que un desafío está vinculado a una ID de sesión específica, el servidor solo honrará un boleto dorado empaquetado con esa misma identificación. Para la hazaña de Tóth para trabajar, el sistema del atacante no solo debe tomar posesión del boleto de oro interceptado, sino que también debe saber la identificación exacta de la sesión al presentar ese boleto al servidor web legítimo.
Aquí es donde entra en juego el parámetro httponly. Cuando el encabezado Set-Cookie incluye este parámetro (como se muestra arriba), es como una capa de invisibilidad mágica. La ID de sesión se vuelve invisible para cualquier JavaScript, legítimo o malicioso, que podría estar ejecutándose en el navegador del usuario. Como resultado, si ese JavaScript es malicioso, no puede hacer lo que hace la hazaña de Tóth; No puede descubrir la identificación de la sesión, ni puede incluirla con el boleto de oro interceptado que se adelanta al sistema del atacante. Entonces, incluso si el JavaScript malicioso reenvía el boleto de oro interceptado al sistema del atacante, sería inútil para el atacante sin la identificación de la sesión faltante.
Para los eones, esta «unión de sesión» de una conversación de autenticación (relacionada con la clave de passey o no) entre un sitio web y el navegador del usuario final se ha considerado la principal línea de defensa contra tal ataque. La falla del operador de un sitio web para bloquear sus procesos de autenticación con esta mejor práctica simple y conocida sería vista por la mayoría de los profesionales de ciberseguridad como altamente negligente.
Mucha culpa para dar vueltas
Pero en mis entrevistas con Tóth, también culpa a otros dos grupos: los proveedores de soluciones que venden los complementos utilizados por depender de las partes para agregar soporte de PassKey a sus sitios web, y la Alianza FIDO, la organización responsable del desarrollo, promoción y adopción de PassKeys.
En su investigación, Tóth anotado Que, de las siete soluciones de complemento que probó, cuatro «no implementaron ‘desafío unido a la sesión’ (por lo tanto) haciendo que este ataque sea explotable». En otras palabras, si un operador del sitio web instaló una de esas cuatro bibliotecas (de Hanko, SK Telecom, Noknok o Authsignal) y las dejó en su estado predeterminado, sería el equivalente a ignorar las mejores prácticas.
Tóth también fue incrédulo de que la alianza Fido incluyó esas cuatro soluciones en su escaparate en línea de fido certificado soluciones. En opinión de Tóth, hacer alarde de la mejor práctica ampliamente conocida y el incumplimiento de los desafíos no obligatorios debería descalificar un complemento de la certificación de Fido. La Alianza Fido no está de acuerdo.
Fido Alliance CTO Nishant Kaushik me dijo:
«Con respecto a las cuatro compañías que señaló como no usar la vinculación de la sesión, vale la pena señalar que el investigador probó los sitios de demostración que estas compañías aprovechan para mostrar la experiencia del usuario que proporcionan sus productos. Los sitios de demostración no se endurecerían de la misma manera que una implementación real».
Kaushik pasó a hablar sobre la criticidad de la encuadernación de la sesión, diciendo que la alianza FIDO operó passkeycentral.org incluye un correo Demostrar que «la alianza FIDO (ha sido) clara que la unión de sesión es ‘esencial’ para evitar el secuestro de sesiones». Sin embargo, el artículo se refiere a técnicas criptográficas de unión a sesiones como Credenciales de sesión de dispositivo para dispositivos (DBSC) y Demostrando prueba de posesión (DPOP)y no sugiere la mejor práctica mucho más simple y ampliamente publicitada de la unión de sesión con el encabezado de cookies Set.
Además, mientras que la alianza FIDO defendió sus certificaciones, esencialmente afirmando que nadie desplegaría de manera realista los complementos de la manera que Tóth hizo, el CEO de uno de esos complementos golpeó un tono mucho más genuino, conciliatorio y culpable de una manera que calificó la precisión de la respuesta de Kaushik.
«Somos conscientes del problema y nuestro equipo está trabajando activamente en una solución», dijo Hanko.io CEO Felix Magedanz. «La implementación de PassKey es uno de los primeros componentes de Hanko. Si bien desde entonces hemos agregado funcionalidad, como sesiones y administración de usuarios, se mantuvo una brecha en la forma en que los flujos de webauthn estaban vinculados a las sesiones de usuario. Estamos tratando esto con la más alta prioridad y lanzará una versión actualizada de Hanko muy pronto».
Mientras que las soluciones provienen de Hanko.io (y tal vez los demás), está muy claro que la responsabilidad está en confiar a las partes para implementar la vinculación de la sesión de manera responsable para proteger mejor a sus usuarios finales.
Capas sobre capas
Pero supongamos, como lo hace Tóth, que el operador del sitio web ha ignorado catastróficamente una de las técnicas más importantes y conocidas para asegurar un flujo de trabajo de autenticación. La exploit de Tóth todavía implica otras condiciones no triviales.
El primero de ellos implica la instalación de un script malicioso en su navegador web. Señalando un 2019 Post hackerone Eso documentó la existencia de un XSSS Malicioso en PayPal, Tóth dice que los usuarios finales deberían asumir que incluso los sitios web más de buena reputación y supuestamente bien defendidos pueden ser la fuente de tales guiones maliciosos. En mis conversaciones con él, señaló que los sitios que incluyen una cantidad significativa de contenido generado por el usuario son un objetivo favorito de los actores de amenaza porque pueden agregar scripts a una publicación o una revisión y, si el sitio carece de las protecciones adecuadas para rechazar dichas entradas (otro acto de negligencia en nombre del operador del sitio), todo un usuario inocente debe hacer es visitar esa publicación o revisión en el orden de ejecución.
Suponiendo que un usuario tropieza en un sitio de este tipo y carga el guión malicioso en su navegador, el guión debe engañar subrepticiamente al usuario para que lance inadvertidamente una ceremonia de autenticación con un tipo de ataque conocido como un Ataque de clickjack.
Como sugiere la frase, un ataque de clickjack ocurre cuando un actor de amenaza lo engaña para que haga clic en un elemento que se puede hacer clic (por ejemplo, un botón o un enlace) que podría no ser visible para usted. En la exploit de Tóth, el malicioso JavaScript pinta la ventana del navegador con un diálogo aparentemente inocente como un anuncio emergente o una forma de consentimiento de cookies, el tipo de cosas que vemos todo el tiempo y solo queremos eliminar nuestra pantalla. Sin embargo, cuando hacemos clic en ese elemento para deshacerse de él, lo que no nos damos cuenta es que en realidad estamos haciendo clic en algo más que estaba oculto detrás de él. Insidioso, ¿verdad?
En ese momento, el clic del mouse ha sido secuestrado esencialmente. Pero, ¿en qué ha hecho clic realmente?
En la prueba de concepto de Tóth, su guión malicioso implica un formulario de inicio de sesión oculto, que a su vez desencadena a su administrador de contraseñas en acción (como lo hacen los administradores de contraseñas cuando lo hacen cuando detectan la presencia de un formulario de inicio de sesión). Luego, el clic que los secuestra es el que le indica al administrador de contraseñas que prepare un boleto dorado para la transmisión al sitio web legítimo. Teóricamente, dado que el formulario de inicio de sesión se ocultó a la vista, ni siquiera se da cuenta de que acaba de completar una ceremonia de autenticación de PassKey. Una vez que el Administrador de contraseñas prepara ese boleto para la transmisión, el script malicioso lo intercepta y, en lugar de enviarlo (con un comando de publicación HTTP) al servidor legítimo, HTTP lo publica en el servidor del atacante como se describió anteriormente.
Pero, como se sugirió, el ataque no es posible sin la participación del administrador de contraseñas del usuario. Entonces, ¿qué, si algo, el Administrador de contraseñas puede hacer para mitigar el ataque?
Los pros y los contras de la región
Cuando los proponentes describen los pases de aprobación como más seguros que las credenciales tradicionales, a menudo hablan sobre cómo el proceso de Keyk es tan simple como iniciar sesión en su teléfono con un código biométrico (huella digital, identificación facial, etc.) o código PIN. Por ejemplo, en Una de sus páginas de apoyoMicrosoft afirma: «Las versas pasas son un reemplazo para su contraseña. Con Passkeys, puede iniciar sesión en su cuenta personal de Microsoft o en su cuenta de trabajo/escuela utilizando su cara, huella digital o pin». Incluso los passkeycentral.org operados por la alianza FIDO Introducción a Passkeys afirma: «Un PassKey es una credencial de autenticación FIDO basada en los estándares FIDO, que permite al usuario iniciar sesión en aplicaciones y sitios web con los mismos pasos que usan para desbloquear su dispositivo (biometría, pin o patrón)», como si ese sea siempre el caso.
Otros proponentes de PassKey incluyen un lenguaje sorprendentemente similar en sus sitios web que hacen que suene como si cada vez que intente autenticarse con una PassKey, tendrá que proporcionar un biométrico o PIN para completar el proceso (similar al de iniciar sesión en una aplicación móvil que lo solicita una huella digital). Sin embargo, este es principalmente el caso cuando su administrador de contraseñas también está configurado para requerir un biométrico o PIN para cada intento de autenticación. Dado que algunos usuarios no quieren ser molestados con esta capa adicional de seguridad cada vez que inician sesión en un sitio web, la mayoría de los administradores de contraseñas brindan a los usuarios la opción de relajar la molestia. En otras palabras, puede configurarlo para que te molestes cada vez, de vez en cuando, o nunca.
Recuerde que la exploit de Tóth depende de que el usuario sea engañado para autenticarse inadvertidamente con un sitio web. En otras palabras, oculta todas las señales visuales de que una autenticación está en progreso para no alertar al usuario sobre la posibilidad de una actividad sospechosa. Si su administrador de contraseñas está configurado como el mío está, para requerir un PIN o un biométrico para permitir que continúe cualquier ceremonia de autenticación, se dará cuenta instantáneamente de que algo está mal. Supongamos, por ejemplo, el ataque de ClickJack requiere que haga clic en el botón «Aceptar» en un formulario de consentimiento de cookies. Si su administrador de contraseñas se da vida de repente, pidiendo su huella digital o un pin después de hacer clic en ese botón, debería ser una bandera roja evidente que no continúe. Un formulario de consentimiento de cookies no necesita su huella digital.
Al configurar su Administrador de contraseñas para solicitarle más agresivamente su huella digital, PIN o contraseña, esencialmente está agregando un botón de pausa al proceso de autenticación. Le brinda la oportunidad de confirmar que el Administrador de contraseñas está haciendo algo que realmente tiene la intención de hacer. Elegir un entorno más relajado para esta preferencia es el equivalente a renunciar a una importante capa de seguridad controlada por el usuario a los actores de amenaza.
Tóth estuvo de acuerdo con esta evaluación, pero señaló que muchos usuarios podrían desconocer cómo, durante la instalación, algunos administradores de contraseñas predeterminados en una configuración más permisiva. Es un punto justo. Pero también es un recordatorio de cómo, en la búsqueda constante de las excelentes prácticas de OPSEC (seguridad operativa), los usuarios deben tomar precauciones de seguridad progresivamente después de educarse sobre las opciones de seguridad que están disponibles para ellos.
La opción nuclear
Sin embargo, incluso cuando los usuarios han descuidado batear sus escotillas, los operadores del sitio web tienen una opción nuclear especial a su disposición. Además de hacer todas las ceremonias de autenticación que se encuentran en la sesión y aplicar las contramedidas necesarias para evitar que los actores de amenaza instalen JavaScript malicioso en los navegadores de los usuarios, depender de las partes también tienen el poder de anular las preferencias de los usuarios para cuando los administradores de contraseñas los solicitan sus biometrices, alfileres o contraseñas.
Cuando la parte de conflicto envía el desafío mencionado anteriormente al Administrador de contraseñas como parte de la carga útil de PublicKeyCredentialRequestOptions, también puede incluir una bandera especial llamada parámetro de VERIFICACIÓN. Este parámetro permite tres configuraciones posibles: desanimado, preferido y requerido. Si la parte de confía establece el indicador de UserVerification en «requerido», el Administrador de contraseñas está obligado a solicitar al usuario un biométrico, PIN o contraseña, independientemente de cómo el usuario haya configurado ese administrador de contraseñas. En otras palabras, el operador del sitio web tiene una forma de obligar al usuario a experimentar el aviso de una manera que debería alertarlos sobre el comportamiento inesperado del sitio web.
Existe una posibilidad que haga que la opción nuclear sea discutible: ¿qué pasa si el administrador de contraseñas simplemente no honra la opción «requerida» cuando la parte confía lo especifica? Pero, de los proveedores de Administrador de contraseñas que probé aleatoriamente (1Password, Bitwarden, LastPass y Nordpass), indicaron que honran completamente la configuración «requerida» cuando se especifican como parte de las requisiciones de huellas públicas de la parte de conflicto.
Si ves algo, di algo
DE ACUERDO. Como usuario final, tienes poco o ningún control sobre los sitios que visita. Estás actuando sobre la fe ciega de que están haciendo todo lo que pueden hacer para detener un ataque de esta naturaleza, pero nunca puedes estar seguro. Al mismo tiempo, está iniciando sesión en tantos sitios que configurar su administrador de contraseñas para su forma más agresiva de reautorización lo está volviendo loco, y se pregunta si hay una red de seguridad alternativa.
Para responder a esa pregunta, debemos volver a los administradores de contraseñas. Resulta que, para que su administrador de contraseñas haga lo que hace, debe otorgarle el tipo de permisos que nunca debe dar a ninguna otra extensión del navegador web. Su administrador de contraseñas no solo puede leer todo el contenido de cada página web que visite, sino que también puede modificarlo. Y, debido a esos permisos, su administrador de contraseñas también puede detectar los signos reveladores de un ataque de clickjack en progreso.
Por ejemplo, para hacer lo que normalmente hace (por ejemplo, ID de usuario y contraseñas de Autocomisos), su Administrador de contraseñas debe detectar la presencia de un formulario de inicio de sesión. Sin embargo, debido a que el Administrador de contraseñas puede analizar cada bit de HTML que constituye una página web, también puede tomar medidas después de detectar si se oculta un formulario de inicio de sesión desde su vista o si ese formulario de inicio de sesión está superpuesto por otros objetos clickables (la marca verdadera de un ataque de clickjack).
Aunque no me puse en contacto con todos los proveedores de contraseñas, verifiqué un puñado. No es sorprendente que las versiones actualizadas de su software estén en proceso o ya se han lanzado.
«Bitwarden ha implementado mitigaciones para esta clase de ataque en los lanzamientos más recientes la semana pasada», según el director de comunicaciones de Bitward, Mike Stolyar. «Actualizaciones recientes introdujeron salvaguardas que deshabilitan el enfoque automático en línea cuando el estilo del sitio sugiere una posible manipulación, como superposiciones ocultas o cambios en la opacidad».
Por correo electrónico, 1Password Ciso Jacob Deprester me dijo que «el 20 de agosto de 2025, lanzamos la Versión 8.11.7, que agrega la opción de que los usuarios se notifiquen y aprueben o denegan las acciones de AutoCill antes de que ocurran. Esto extiende la alerta de confirmación existente para la información de pago, una alerta que no puede estar oculta o sobrepuesta al hacer clic en Jacking, dando a los usuarios una mayor visibilidad y control antes de que se llene nada». «.». «.». «.» «.». «.». »
«Los iconos de Nordpass ahora se representan con el más alto índice Z, evitando que cualquier cosa sea superpuesta sobre ellos», dijo el jefe de productos empresariales de Nordpass, Karolis Arbaciauskas. «Ahora también es imposible cambiar el atributo de estilo del diálogo, que anteriormente permitió que el diálogo se hiciera invisible».
LastPass también ha fortalecido sus defensas contra los posibles ataques de clickjack. La última actualización «es detectar los tipos de elementos de opacidad cero y no (Autocomise)», dijo el director de gestión de productos de LastPass, Greg Armanini. Cuando pregunté si LastPass le da al usuario una advertencia sobre cualquier comportamiento de riesgo potencial que podría haber observado en la página web actual, Armanini respondió que «en la primera versión, parecerá que no pasa nada». Pero, (si decidimos llevar la solución un paso más allá), probablemente sería similar a lo que ya hacemos para sus tarjetas de crédito, lo cual es un aviso decir ‘Antes de hacer esto, asegúrese de confiar en este sitio’ «.
Mientras tanto, Tóth está monitoreando a los diversos administradores de contraseñas para ver cómo sus actualizaciones, algunas ya aplicadas, otras aún se están llevando a cabo contra su metodología de prueba. También se apresuró a señalar cómo las actualizaciones por sí solas no ayudarán a menos que los usuarios instalen esas actualizaciones. Mientras los usuarios permanezcan en versiones antiguas de sus administradores de contraseñas, podrían caer presa de un ataque de clickjack de opacidad cero.
Finalmente, a pesar del potencial de un actor de amenaza para secuestrar una ceremonia de autenticación de PassKey una vez que se cumplen las condiciones previas no triviales, la exploit de Tóth ofrece evidencia adicional de que las veras pasas son más seguras que las credenciales tradicionales. La unión de la sesión hace que el boleto de oro de Key Key sean inutilizables del sistema del atacante. Sin embargo, no hace nada para detener la exfiltración del actor de amenaza de la identificación y la contraseña del usuario cuando el ataque de clickjack de Tóth encuentra un intento de autenticarse con esas credenciales tradicionales versus los passas más sensibles y seguras.
