Una vulnerabilidad de clickjacking en WhatsApp permite ataques de phishing

• Se descubrió una vulnerabilidad de phishing que permite mostrar en mensajes de WhatsApp un enlace y una vista previa que parecen apuntar a un sitio legítimo, mientras que el clic real redirige al sitio del atacante
• La causa está en que el enlace del cuerpo del mensaje y los datos de la vista previa se envían por separado, y al eliminar matchedText es posible crear una incongruencia en la vista previa
• El carácter U+202E Right-To-Left Override puede invertir la dirección visible de una URL, haciendo que el dominio real parezca un dominio legítimo
• El atacante puede preparar un dominio espejo del objetivo suplantado, conservar la vista previa del sitio original y cambiar solo el valor de text para engañar a la víctima
• Meta respondió que puede ajustar dinámicamente la lógica de normalización de URL, y los usuarios deberían copiar el enlace antes de hacer clic para verificar la dirección real

---

Dónde se separan la vista previa del enlace y el enlace real en WhatsApp

• El investigador envió a un amigo un enlace de webhook.site para comprobar si, cuando el receptor renderiza la vista previa del enlace en un mensaje de WhatsApp, se genera una solicitud HTTP
• La solicitud HTTP solo ocurrió una vez del lado del remitente, y se confirmó que el receptor no renderiza el enlace por separado
• A partir de este comportamiento, concluyó que los mensajes de WhatsApp se envían incluyendo juntos el enlace y la información de vista previa, y probó si podían hacerse diferentes entre sí

Issue #1: incongruencia en la vista previa del enlace

• Intentó modificar directamente los mensajes de WhatsApp Web mediante un proxy, pero debido al E2EE de WhatsApp no era fácil hacer una alteración simple con herramientas como Burp Suite
• En su lugar, puso un breakpoint en el JavaScript justo antes de que el mensaje cifrado se enviara por WebSocket y examinó el objeto del mensaje
• En el objeto del mensaje, el texto del enlace y la información de vista previa existen como propiedades separadas
  • text: cuerpo del mensaje
  • canonicalURL: dominio mostrado en la parte inferior de la vista previa
  • matchedText: parece ser el valor que se compara con canonicalURL, y se probó si ese valor también aparecía dentro de text
• Si en el objeto del mensaje para instagram.com se cambiaba text a google.com, la vista previa desaparecía y quedaba solo el enlace de Google
• Al eliminar la propiedad matchedText, fue posible crear un mensaje incongruente donde el enlace real y la vista previa eran distintos

Issue #2: camuflar la visualización del enlace con U+202E

• Para evitar que quedara expuesto el texto real del enlace, hizo fuzzing para ver si caracteres Unicode podían alterar cómo se muestra el texto
• U+202E es el carácter Right-To-Left Override, que hace que el texto se muestre en orden inverso para el usuario
• Usar solo U+202E hacía que el enlace se viera extraño y pareciera menos probable que alguien hiciera clic, por lo que había que construir una cadena invertida que pareciera una URL normal

Cómo se construye la URL espejo

• El objetivo era crear una URL que, al invertirse, pareciera https://instagram.com
• Una cadena simplemente invertida sería moc.margatsni//:sttph, pero no se puede registrar un TLD como .margatsni
• La solución fue usar un TLD realmente registrable de forma que pareciera un subdominio
  • Por ejemplo, usando el TLD neerlandés .nl se puede formar una cadena que parezca ln.instagram.com
• Como también debía parecer que la URL comienza con https://, se añadió al final la ruta válida //:sptth
• Como resultado, https://moc.margatsni.nl//:sptth, al combinarse con U+202E, puede verse como https://ln.instagram.com//:sptth
• El investigador llamó a este método 2K2E

Flujo del ataque

• El atacante compra un dominio espejo del sitio que quiere suplantar
  • Ejemplo: para que parezca ln.instagram.com, compra moc.margatsni.nl
• Primero crea un mensaje con un enlace al dominio original para obtener la vista previa de ese sitio
  • En el objeto de ejemplo, text, matchedText y canonicalUrl contienen https://instagram.com/
  • También se incluyen valores relacionados con la vista previa como description, title, jpegThumbnail y thumbnailDirectPath
• Después elimina matchedText y cambia el valor de text a la forma \u202ehttps://moc.margatsni.nl//:sptth
• El mensaje final muestra la vista previa de Instagram, pero al hacer clic puede llevar al dominio preparado por el atacante

Respuesta de Meta y comparación con otras plataformas

• Meta respondió que, como da soporte a múltiples plataformas y entornos, la forma en que cada plataforma normaliza URL puede diferir de la lógica del lado del servidor
• Indicó que tiene un sistema capaz de ajustar dinámicamente la lógica de normalización de URL cuando se produzcan casos reales de spam o abuso
• El investigador evaluó que Meta, más que resolver activamente este problema de seguridad, parece querer responder solo cuando el sistema lo detecta como spam
• X, TikTok y Pinterest sí aplican un proceso de saneamiento al carácter U+202E, a diferencia de WhatsApp

Medidas de mitigación que los usuarios pueden aplicar

• No es fácil confiar en un enlace de WhatsApp solo por cómo se ve en pantalla
• Para evitar el phishing 2K2E, se recomienda copiar el enlace antes de hacer clic y verificar la dirección real en la vista previa del portapapeles
• La vista previa del portapapeles puede mostrar la dirección del enlace con el carácter U+202E ya saneado
• Después, el investigador también encontró otros servicios vulnerables a 2K2E por no aplicar un saneamiento adecuado

[GN⁺]

Opiniones de Hacker News

• Es una combinación bastante ingeniosa de usos indebidos de funciones, pero diría que el impacto de seguridad general es bajo.
  En el mejor de los casos, solo logra que el destinatario abra un enlace en el navegador; salvo que el atacante sea algo como la policía o una agencia de inteligencia, normalmente haría falta un ataque posterior, como explotar software sin parches en el dispositivo.
  Técnicamente, no es del todo correcto llamarlo clickjacking. El clickjacking suele referirse a una técnica muy específica: superponer un frame HTML invisible sobre otro contenido.
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • Yo tampoco lo llamaría clickjacking. El clickjacking real es una técnica que hace que la víctima realice acciones relacionadas con su cuenta sin darse cuenta, y abrir un enlace no deseado no es tan grave como eso.
  • Si ese enlace muestra una pantalla de inicio de sesión idéntica a la de Instagram, me pregunto qué porcentaje de usuarios, después de confundirse una vez con la vista previa de WhatsApp, volvería a revisar la URL.

• Todos se enfocan solo en los caracteres UTF de derecha a izquierda, pero Meta al menos debió reconocer el problema de que la URL de la vista previa puede ser distinta de la URL del mensaje.
  Entiendo que esto sirve para expandir URLs acortadas, pero seguramente hay alguna solución alternativa inteligente que Meta y WhatsApp podrían implementar.

  • No. Con cifrado de extremo a extremo, la vista previa tiene que generarse del lado del remitente o del receptor. Si la genera el receptor, se filtra su IP. Al final habría que eliminar la función de vista previa.

• El clickjacking consiste en que crees que haces clic en un elemento, pero en realidad otro elemento, normalmente transparente y superpuesto, intercepta el evento de clic.
  Si se enfoca la capa visible inferior y se detecta que se dispara el evento onblur, el atacante puede saber que hubo un clic aunque el usuario no reciba el evento.
  Lo que encontró el OP está genial, pero no es clickjacking. Yo también usé hace años caracteres RTL para hacer que un archivo de protector de pantalla —es decir, un ejecutable normal de Windows con otra extensión— pareciera un documento de Word. Creo que era para hacerles una broma a amigos o profesores, aunque ya no recuerdo bien por qué.
  El OP fue un paso más allá y encontró una forma de que la visualización cambie en otro sistema. No es que el usuario se confunda sobre qué elemento está clicando, sino sobre a dónde irá el enlace; por eso no es clickjacking, y la página de Wikipedia enlazada al comienzo del artículo también lo confirma.
  Nunca he visto que el clickjacking se explote en la práctica, pero sí creo que el método que encontró el OP podría abusarse.
  Sinceramente, hace mucho que renuncié a la expectativa de que los usuarios puedan distinguir el dominio final cuando hacen clic en un enlace. La gran mayoría ni siquiera entiende el concepto, y para el resto también es difícil distinguirlo.
  Incluso quienes creen que sí pueden hacerlo terminan frustrados cuando todos los enlaces apuntan a algo como sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o. Todos los días entrenamos a la gente para hacer clic en enlaces sospechosos y ofuscados para rastreo, y a nadie le importa.

• Es un hack genial. El verdadero problema no es WhatsApp ni los caracteres Unicode inversos, sino que las URL son difíciles.
  Con un ejemplo simple como visa.securesite.com ya se engaña a mucha gente. No veo una buena solución en el futuro cercano.

  • En este caso específico, cuando el usuario intenta entender en qué va a hacer clic, se lo induce activamente a error, así que se parece más a una sanitización deficiente.
    La confusión general alrededor de los nombres de host y los dominios es un problema más difícil, aunque los navegadores han intentado mitigarlo en cierta medida resaltando la parte del nombre de dominio. Como con la mayoría de las técnicas de phishing, probablemente las passkeys terminen con esto.

• RTL ha sido una fuente enorme de vulnerabilidades de seguridad durante toda su existencia. No entiendo por qué los sistemas operativos no tienen una opción para desactivar todo RTL, para que quienes no hablan esos idiomas no queden expuestos a riesgos sin obtener ningún beneficio.

  • Más allá del sistema operativo, todos los widgets de OS que muestran texto deberían tener esa opción. Eso incluye TextView de Android.
    A menos que el desarrollador revise y permita explícitamente un rango de texto específico, el valor predeterminado debería desactivar todos los bypasses de texto bidireccional.
    No tiene sentido hacer que todo el stack de renderizado de texto sea vulnerable por defecto con el pretexto de atender a menos del 1% de la población mundial.

• Es decepcionante que Meta no corrija este problema y que tampoco vaya a pagarle una recompensa de bug bounty a este investigador.

  • A comienzos de este año reporté un problema similar a Google, pero lo rechazaron con los argumentos de que “solo puede ocurrir mediante ingeniería social” y que “no creemos que solucionarlo haga que los usuarios sean significativamente menos vulnerables”.
    No voy a entrar en detalles aquí, pero por la forma en que Google Search a veces reescribe URLs, un atacante puede engañar sobre la URL real.
    Conviene no confiar nunca en las URLs que se muestran en sitios web y apps.
  • Parece que están demasiado ocupados enviando amenazas legales a proyectos OSS.
  • Probablemente no logró dejar claro qué quería que corrigieran —por ejemplo, que bloquearan caracteres RTL—, y Meta pudo haberlo interpretado como una petición para arreglar todas las URLs engañosas. Eso es prácticamente imposible.
  • Lo van a arreglar. Solo que no van a compensar al cazador de recompensas.

• El punto de “tal como esperábamos, ¡el enlace y la vista previa se enviaron por separado!” es un problema mayor de diseño de UI. ¿Por qué un usuario común debería comparar el enlace y la vista previa por seguridad?

  • Es una concesión de seguridad. Para ofrecer una función útil como la vista previa de enlaces, hay varias opciones:
    1. Generarla del lado del remitente. La desventaja es que se puede falsificar.
    2. Generarla del lado del receptor. La desventaja es que se filtra la IP del receptor.
    3. Generarla mediante un tercero. La desventaja es que se filtra información al tercero.
       En general, creo que la opción 1 es la mejor. Después de todo, el remitente ya puede “falsificar” todos sus propios mensajes, y que incluya la vista previa como parte del mensaje no es muy distinto.
       El problema aquí es que no queda claro que ese contenido proviene del remitente. Como se muestra como una burbuja separada, sospecho que el 99% de los usuarios no sabrá que ese contenido lo proporcionó el remitente.
       Además, de todos modos la URL es lo importante. Si haces clic en una URL controlada por el atacante, este puede mostrar lo que quiera en la vista previa. Por eso, el beneficio de forzar que la vista previa sea “real” es muy pequeño.
       La opción 3 también podría estar bien. En especial si se implementa con algo tipo doble ciego: podrías conectarte a una parte y que esta reenvíe a la segunda. Así, la primera ve la IP y la segunda ve el destino, pero ninguna ve ambas cosas al mismo tiempo salvo que se coordinen.
       Aun así, el beneficio es relativamente pequeño para construir y mantener tanta infraestructura.

• Me gusta que al final del artículo lo clasifiquen como ingeniería inversa.

• Esto no es clickjacking. El clickjacking es cuando el atacante intercepta un clic para que el usuario realmente haga clic en otro objetivo que no pretendía o del que no era consciente.
  Los codepoints RTL que hacen que el texto fluya de derecha a izquierda son una función de internacionalización, y confundir a la gente con eso no es una vulnerabilidad nueva.