Ataque de desanonimización 0-click dirigido a plataformas como Signal y Discord
(gist.github.com/hackermondev)- Cuando se combinan la caché de Cloudflare y las notificaciones push, es posible un ataque de desanonimización 0-click que reduce la ubicación del usuario a un rango de cientos de millas en teléfonos con apps vulnerables instaladas o laptops con apps en segundo plano
- El atacante hace que el dispositivo objetivo cargue automáticamente un recurso detrás de Cloudflare y luego investiga en qué centro de datos de Cloudflare quedó cacheado para estimar una zona cercana al objetivo
- En Signal, por la caché de archivos adjuntos de
cdn2.signal.orgy las notificaciones push móviles, una imagen adjunta puede descargarse incluso sin abrir la conversación; en Discord, el mismo ataque es posible mediante la URL del avatar en una notificación de solicitud de amistad - Cloudflare corrigió un bug relacionado con Cloudflare Teleport que permitía enviar solicitudes a centros de datos específicos, pero se afirma que, incluso usando servidores VPN, fue posible volver a acceder a cerca del 54% de todos los centros de datos de Cloudflare
- Signal y Discord trasladaron la responsabilidad a Cloudflare o al usuario, mientras que Cloudflare sostuvo que desactivar la caché de los recursos que requieren protección es responsabilidad del cliente, por lo que persiste un riesgo de privacidad en el que se entrelazan el diseño de apps, CDN y notificaciones
Principio para acotar la ubicación con la caché de Cloudflare
- Este ataque usa la información de estado de caché de Cloudflare y sus centros de datos distribuidos geográficamente para estimar la ubicación aproximada de un usuario
- Cloudflare proporciona información en los encabezados de respuesta para solicitudes de recursos cacheables
cf-cache-statusmuestraHIToMISScf-rayincluye el centro de datos que procesó la solicitud y un código de aeropuerto cercano
- Cuando el dispositivo objetivo carga un recurso de un sitio basado en Cloudflare, ese recurso puede quedar cacheado en un centro de datos cercano al objetivo
- Luego, al consultar varios centros de datos de Cloudflare para encontrar dónde quedó cacheado el recurso, se puede estimar una zona cercana al objetivo
- Cloudflare explica que opera cientos de centros de datos en más de 120 países y 330 ciudades, y que para residentes de países desarrollados es muy probable que el centro de datos más cercano esté dentro de un radio de 200 millas
Cloudflare Teleport y recorrido de centros de datos
- En general, los rangos de IP de Cloudflare funcionan con anycast, por lo que un usuario no puede solicitar directamente una conexión TCP a un centro de datos específico
- A partir de una publicación en un foro de la comunidad que indicaba que era posible hacer un bypass usando Cloudflare Workers y rangos de IP internos de Cloudflare WARP para enviar solicitudes HTTP a un centro de datos específico, se creó Cloudflare Teleport
- Cloudflare Teleport era una herramienta de proxy basada en Cloudflare Workers que permitía especificar un valor
coloconcreto para enviar la solicitud al centro de datos deseado- Por ejemplo, se usaban códigos como
SEA, que representa el centro de datos de Seattle - La correspondencia entre ciertos rangos de IP y centros de datos se organizaba en forma de
colos.json
- Por ejemplo, se usaban códigos como
- Cloudflare corrigió por completo este bug posteriormente, y la herramienta Teleport ya no funciona con ese método
Prueba de concepto verificada con el favicon de Namecheap
- Para la primera verificación se usó el
favicon.icode Namecheap - Ese recurso era una imagen estática simple con caché de Cloudflare habilitada, y la protección contra bots no era estricta, por lo que fue elegido como objetivo de prueba
- La herramienta CLI enumera, para una URL especificada, qué centros de datos cachearon el recurso y la antigüedad de la caché
- Aunque Namecheap configuró la antigüedad de la caché en un valor muy bajo de 5 minutos, fue posible confirmar los centros de datos que habían cacheado el favicon en los últimos 5 minutos
- Como el navegador descarga automáticamente el favicon al abrir un sitio, este resultado funciona como una prueba de concepto que muestra que usuarios de varias regiones visitaron Namecheap.com en los últimos 5 minutos
Aplicación en Signal
- Signal usa dos CDN para entregar contenido
cdn.signal.org: basado en CloudFront, para avatares de perfilcdn2.signal.org: basado en Cloudflare, para archivos adjuntos de mensajes
- La ruta
https://cdn2.signal.org/attachments/*tiene configurada la caché de Cloudflare, por lo que cuando un dispositivo que recibe un adjunto lo descarga, este puede quedar cacheado en un centro de datos cercano -
Método 1-click
- Cuando un usuario envía un archivo adjunto en Signal, el archivo se sube a
cdn2.signal.org - Si el destinatario abre la conversación, su dispositivo descarga automáticamente el adjunto, y el método de estimación geográfica mediante la caché de Cloudflare puede acotar la ubicación del destinatario
- En las pruebas, se eliminó el SSL pinning de la app de escritorio de Signal y se usó Burp para revisar solicitudes y respuestas
- Si el dispositivo del atacante descarga primero el adjunto, puede generarse una caché en un centro de datos cercano al atacante y contaminar los resultados, por lo que se bloquearon las solicitudes GET a
cdn2.signal.org/attachments/*en la app de Signal del lado del atacante - En una prueba ejecutada en Nueva York contra uno mismo, se identificó el centro de datos
EWRde Newark, NJ, a unas 150 millas de las coordenadas reales
- Cuando un usuario envía un archivo adjunto en Signal, el archivo se sube a
-
Método 0-click
- La app móvil de Signal incluye por defecto el remitente y el mensaje en las notificaciones push
- En los mensajes con una imagen adjunta, el dispositivo descarga la imagen desde el CDN de Signal para mostrarla a la derecha de la notificación
- Aunque el objetivo no abra la conversación de Signal, al llegar la notificación push la imagen adjunta puede descargarse y, en ese proceso, se genera una caché en un centro de datos de Cloudflare cercano al objetivo
- Este método deriva en un ataque 0-click que estima la ubicación actual sin interacción del usuario
- Como Signal es un servicio usado por periodistas, activistas e informantes, existe riesgo de abuso para rastrear cuentas, correlacionar identidades o estimar la ubicación de empleados que se reúnen con periodistas
Aplicación en Discord
- También se confirmó que Discord es una app vulnerable al mismo tipo de ataque debido a recursos de CDN con caché de Cloudflare configurada
- En el método 1-click se usan emojis personalizados disponibles para suscriptores de Nitro
- Los emojis personalizados se cargan desde el CDN de Discord
- Pueden mostrarse en varios lugares, como mensajes, estados de usuario y canales
- Un atacante puede mostrar un emoji personalizado en su estado de usuario y esperar a que el objetivo abra el perfil
- El informe completo de HackerOne enviado a Discord fue publicado en un Gist separado
-
0-click con notificaciones de solicitud de amistad
- Las notificaciones push móviles de Discord se envían para varios eventos además de mensajes
- Al enviar una solicitud de amistad, se genera una notificación push en el dispositivo móvil del objetivo
- Aunque el objetivo esté usando Discord, la notificación de solicitud de amistad siempre se envía al dispositivo móvil
- La notificación de solicitud de amistad incluye la URL del avatar del usuario que envió la solicitud, y el teléfono descarga ese avatar sin interacción del usuario para mostrarlo en la notificación
- El formato de las URL de avatar de Discord varía según el contexto
- Notificación push:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash} - Visualización en el sitio web:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png - Ambas URL apuntan a la misma imagen, pero como sus rutas son distintas se cachean por separado, lo que permite distinguir la caché cargada por la notificación push de la caché generada por la visualización del perfil en la app
-
Automatización con GeoGuesser
- El procedimiento del ataque 0-click en Discord fue automatizado con el bot privado de Discord GeoGuesser
- Con un solo comando, el bot recibe un nombre de usuario y realiza las siguientes tareas
- Usa credenciales de cuenta con la Discord User API
- Cambia el avatar del usuario por una imagen aleatoria para generar un nuevo hash de avatar
- Envía una solicitud de amistad al usuario especificado
- Ejecuta el ataque de enumeración de caché mediante una API privada basada en la CLI de Cloudflare Teleport
- Muestra los resultados dentro de Discord en menos de 30 segundos
- En una demostración contra el CTO de Discord, Stanislav Vishnevskiy, se observó que dos centros de datos de Cloudflare habían cacheado el avatar
- La razón de que aparecieran dos centros de datos podría ser que varios dispositivos recibieron la notificación, o que las solicitudes de un mismo dispositivo se balancearon entre distintos centros de datos
- GeoGuesser calcula el punto medio entre los dos centros de datos con la Google Maps API y muestra un círculo de radio
- En el mapa de demostración, la sede de Discord está en San Francisco, CA, dentro del círculo exterior, y la ubicación real se estimó cerca del borde del círculo interior, con un rango de unas 300 millas
- Todo el proceso terminó en menos de 1 minuto, y el ataque es casi imposible de detectar
Bug bounty y respuestas de cada organización
- Signal rechazó el reporte de inmediato y sostuvo que nunca intentó replicar por completo funciones de anonimato a nivel de red como WireGuard, Tor o software VPN open source
- La réplica frente a Signal se basa en que Signal se promociona como una plataforma de comunicación centrada en la privacidad, y en que los usuarios esperan minimizar riesgos de privacidad más allá del cifrado de extremo a extremo
- Telegram se menciona como un caso no vulnerable a este ataque
- Usa un protocolo propio que no depende de HTTP
- No depende de la caché de proveedores cloud como Cloudflare
- El equipo de seguridad de Discord inicialmente dijo que evaluaría cambios para proteger a los usuarios, pero luego cambió su postura y afirmó que era un problema de Cloudflare que también afectaba a otros clientes de Cloudflare
- Cloudflare corrigió el bug que Cloudflare Teleport usaba para recorrer centros de datos
- Ese bug había sido reportado en HackerOne por otro informante un año antes, pero en ese momento se consideró que no tenía impacto
- Después de compartirse esta investigación, Cloudflare reabrió el reporte existente y lo resolvió, pagando una recompensa de 200 dólares tanto al informante original como a este reporte
Problemas que persisten después del parche
- Lo que Cloudflare corrigió fue el bug que permitía recorrer centros de datos desde la red interna, pero no desaparecen las condiciones centrales de la estimación de ubicación basada en caché
- Se afirma que los ataques descritos en el artículo se ejecutaron dentro de las 24 horas posteriores al parche
- Cloudflare Teleport se reimplementó con un método basado en VPN 24 horas después del parche
- El proveedor VPN elegido cuenta con más de 3,000 servidores en 31 países
- Con este método fue posible volver a acceder a alrededor del 54% de todos los centros de datos de Cloudflare, y se explica que cubre la mayoría de las zonas con alta población
- La postura final de Cloudflare es que no considera este ataque de desanonimización como una vulnerabilidad de sus sistemas, y que desactivar la caché de los recursos que necesitan protección es responsabilidad del cliente
- Clientes como Discord lo ven como responsabilidad de Cloudflare, mientras que Cloudflare sostiene que el cliente debe ajustar la caché, lo que deja divididos los límites de responsabilidad
Protección e implicancias prácticas
- Este ataque muestra que, cuando se combinan funciones de rendimiento y usabilidad como caché y notificaciones push, pueden abusarse como mecanismo de rastreo
- El bug de Cloudflare Teleport fue corregido y algunas apps como Signal y Discord podrían haber aplicado mitigaciones después de la divulgación pública, pero el riesgo de base permanece
- Las apps que entregan contenido mediante CDN y usan caché pueden ser vulnerables al mismo tipo de ataque si no toman las precauciones adecuadas
- Los recursos que requieren protección deben considerar en conjunto la política de caché del CDN, las imágenes que se cargan automáticamente en notificaciones push y el comportamiento de caché de URL únicas por usuario
- Periodistas, activistas, hackers y usuarios sensibles a la privacidad deben tener presente que las notificaciones de apps y la carga automática de recursos externos pueden terminar exponiendo su ubicación
1 comentarios
Comentarios de Hacker News
Si le envías una foto a un usuario de Signal, la obtiene a través de Cloudflare y queda en caché en el centro de datos cercano a ese usuario. Después, al consultar el estado de la caché, se puede averiguar qué centro de datos se usó.
A menos que el usuario esté en una zona remota, llamarlo una desanonimización parece un poco exagerado, pero aun así es un artículo interesante.
Aun así, Cloudflare no va a servir la caché desde Seattle, Manchester o Tokio, así que reducir la ubicación geográfica aproximada de un usuario desconocido de Signal ya constituye un metadato importante que puede combinarse para identificar a una persona. Es un gran ataque.
Cloudflare puede ver una enorme cantidad de metadatos de chats privados y grupales, y por el tamaño de los archivos puede rastrear quién envió el medio original, quién lo leyó, cuándo lo leyó, quién lo reenvió y a quién. Aunque no pueda ver directamente la imagen o el video, basta con conocer su tamaño de antemano o averiguarlo después, por ejemplo mediante una solicitud de las autoridades.
Incluso si esa información por sí sola sigue siendo insuficiente, puede ayudar a confirmar a un sospechoso específico. Si puedes acercarte directamente a la persona sospechosa y hasta hacerte amigo de su perfil “limpio”, también podrías comparar ambos perfiles de ubicación con la misma técnica. La desanonimización no se trata de una sola pieza de información, sino de un proceso donde toda la información se suma a un perfil que reduce la lista de sospechosos o confirma sospechas.
Aquí, “investigador” no se refiere a un agente de IA ni a una autoridad, sino a una persona común. Si fueran las autoridades, probablemente podrían obtener información de Cloudflare de forma más directa.
Si este nivel y tipo concreto de desanonimización es problemático para tu caso de uso es otra pregunta. En lo personal, a mí no me importaría mucho que mis contactos mutuos vieran directamente mi dirección IP, pero no todos los usuarios piensan igual.
Ese nivel de información sí fue importante en la investigación de Silk Road. Ulbricht expuso por error su zona horaria al principio, y eso permitió a las autoridades de EE. UU. reducir la búsqueda a alguien que estaba en ese país. Sin esa información, podría haber estado en cualquier parte del mundo.
Es un buen artículo con una técnica y un enfoque interesantes.
Aun así, expresiones como “desanonimización” u “obtención de la ubicación del usuario” son algo exageradas. Está muy lejos de una ubicación precisa, y 150 millas equivalen más o menos a 2 horas por carretera entre Atlanta, GA y Augusta, GA. Dentro de ese radio probablemente haya más de 700 mil personas.
La función de obtención automática de archivos adjuntos de Signal sí me preocupa un poco. Si es un mensajero privado, esperaría una opción para desactivarla, como cuando en Tor desactivas JavaScript; puede que no haya buscado lo suficiente, pero no vi una función así.
Parece que Signal adoptó un enfoque “útil por defecto”, equilibrando privacidad y usabilidad para lograr adopción masiva. Los usuarios realmente preocupados probablemente ya estén reforzando Signal con guías como https://www.privacyguides.org/articles/2022/07/07/signal-con.... Para escenarios de alto riesgo, siempre se han recomendado VPN/proxy y cambios de configuración.
Ni el caché ni CloudFlare van a desaparecer. La amenaza de DDoS en los antiguos lobbies multijugador P2P, donde sí se exponía la IP, me parece mayor que esto, y de los tres actores, la respuesta de CloudFlare parece la mejor. El principio es no poner en caché información sensible, y la responsabilidad de indicar a una CDN o servicio intermedio que ciertos elementos no deben cachearse recae en la aplicación que se comunica.
Genial. A diferencia de algunas otras, esto sí puede considerarse claramente desanonimización, o al menos está lo bastante cerca. Si se hubiera podido saber la ubicación de Satoshi con un margen de 250 millas, ¿qué tan anónimo habría seguido siendo hasta ahora?
Si este ataque se aplica repetidamente, ocultándolo de alguna manera, se puede rastrear el movimiento a lo largo del tiempo. A menudo basta con 4 o 5 ubicaciones del tamaño de un código postal para identificar de forma única a una persona.
La forma en que Apple y Cloudflare lo usan en su software de privacidad también parte de la idea de que la región no es un dato que revele identidad. Ese es el caso de iCloud Private Relay de Apple y WARP de Cloudflare; si activas Apple Private Relay, se oculta la IP original, pero la IP por la que se enruta el tráfico sigue estando en el mismo país.
https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
Este ataque es interesante y novedoso desde el punto de vista académico, pero no es “desanonimización”.
Claro, podría no haber sido él y haber sido un usuario inicial cualquiera al azar. Aun así, creo que hay cierta probabilidad de que sí fuera él.
Más detalles: https://news.ycombinator.com/item?id=29728339
No apoyo los intentos de encontrar y publicar su nombre y dirección, porque podrían complicarle la vida. Pero como misterio no resuelto, pese a tantos años y tantas miradas encima, me parece muy interesante en un sentido abstracto.
No entiendo por qué tantos comentarios principales le restan gravedad. Este es exactamente el tipo de ataque que puede permitir a las fuerzas del orden o a actores maliciosos establecer evidencia de ubicación.
Probar ubicación no es desanonimizar, especialmente cuando esa “ubicación” es tan amplia.
Primero intentan ignorarlo y ver si por la mañana el problema sigue ahí. Hasta entonces, esperan que alguien encuentre una razón por la que esto no sea un problema.
¿Por qué Signal tenía habilitado el caché para esas URL? En el caso más común, un adjunto se descargaría una vez y listo.
Más bien habría esperado que no se pudiera descargar más de una vez y que se eliminara inmediatamente después de la primera descarga exitosa. Claro, el cliente puede fallar a mitad del proceso, así que podría haber un período de gracia para volver a descargarlo. Aun así, no parece que ese sea el caso más común, y ojalá desactivar el caché del CDN arregle este problema sin aumentar demasiado los costos.
De todos modos, “desanonimización” aquí suena un poco a clickbait. Acotar la ubicación de alguien a unas 250 millas no está bien, pero no desanonimiza a esa persona.
Edit: no había pensado en el caso de que un adjunto se envíe a un chat grupal y varias personas lo descarguen. Pero incluso en ese caso, ¿el adjunto no se cifra individualmente para cada persona del grupo? Claro, en realidad no sé bien cómo funciona.
Las cosas que mencionaste pueden configurarlas, en la práctica, quienes de verdad quieren ese nivel loco de privacidad y seguridad. Puedes hacer que los mensajes se borren automáticamente 30 segundos después de verlos, configurar que todo el tráfico pase por un proxy y ajustar muchas otras cosas según las preferencias del usuario.
La razón del caché probablemente sea el costo de envío. Los archivos adjuntos, mensajes de voz, videos y demás se acumulan.
Esta persona es el mismo joven de 15 años que hace unos meses encontró la vulnerabilidad de toma de control de Zendesk Slack [1].
[1]: https://news.ycombinator.com/item?id=41818459
Eso significaría que ese bug report enviado a Adobe lo escribió cuando tenía cinco años: https://hackerone.com/daniel?type=user
Definitivamente es un “ataque”, pero no es el tipo que normalmente uno imagina como zero-click. No hay ejecución de código; el método consiste en obtener la región muy aproximada del usuario mediante algunos trucos para averiguar qué centro de datos de Cloudflare ya almacenó en caché la imagen
Aun así, es impresionante y ofrece buenas ideas
Ese tipo de actores puede coordinarse con recursos locales para investigar más. Solo saber qué recursos de qué región hay que movilizar ya puede ahorrar mucho costo
Como se dijo, es impresionante y aporta ideas. El documento también da un poco la impresión de haber recibido ayuda de ChatGPT, pero tiene muchas frases muy claras y específicas. Para este tipo de uso, es un caso excelente, así que no lo digo como crítica. Fue un buen texto
A menos que se me esté escapando algo, esto parece una forma tremendamente rebuscada de verificar la ubicación de la IP del usuario
Por ejemplo, si me conecto a una VPN y luego reviso https://cloudflare.com/cdn-cgi/trace, aparece
colo:CPH(Copenhague), que está lejos del centro de datos de CF más cercano a mí geográficamente y más cerca de la ubicación IP del proveedor de la VPN en Oslo, aunque tampoco está exactamente cercaSi no uso VPN, ni siquiera aparece la capital del país donde estoy ahora, sino un centro de datos unas 250 millas al norte. Así que también me cuesta estar de acuerdo con la afirmación de que Cloudflare siempre devuelve “el centro de datos disponible más cercano”
El texto en sí está bueno y claramente es interesante, pero no estoy seguro de su utilidad práctica
La utilidad real y el riesgo potencial aparecen cuando este dato se combina con otros. Las técnicas de desanonimización usando conjuntos de datos escasos han sido un campo de investigación activo durante al menos 15 años, y a la gente le sorprende a menudo cuánto se puede averiguar a partir de unos pocos fragmentos de datos que parecen no tener relación
Hay una razón por la que las aplicaciones hacen tanto esfuerzo para proxear solicitudes de recursos como imágenes. Eso no sale gratis
¿Cuál sería la ventaja de almacenar en caché en un CDN las imágenes en Signal?
Suponiendo que haya caché local en el cliente, el número total de solicitudes para ese recurso debería ser muy pequeño y, en la mayoría de los casos, probablemente una sola vez
Aparte de eso, parecería muy fácil que CloudFront arreglara este problema simplemente no devolviendo el encabezado
cf-rayo dando a los clientes una opción para eliminarlo. Aunque quizá todavía se podría inferir por la información de tiempoAquí “cercanía” es una heurística aproximada y una propiedad de las tablas de enrutamiento anycast de los routers BGP por los que pasa la solicitud. En la práctica, es más bien “la ruta óptima”
cf-ray, basta con mirar el tiempo de respuesta. Si el recurso tiene que venir de otro continente, probablemente se pueda medir de forma consistenteEsto se parece a los sitios web que intentan ocultar si cierto usuario existe. Si haces una solicitud de inicio de sesión con un nombre de usuario existente, se ejecuta el hash de la contraseña y normalmente el tiempo de respuesta aumenta al menos 50 ms; con un nombre de usuario inexistente, el proceso termina antes. La solución es ejecutar siempre el mismo código y hacer siempre el hash, pero muy pocos sitios lo hacen. O, si encaja con el modelo de amenazas, también puedes simplemente decir de inmediato que el nombre de usuario no existe
Volviendo al caso de Cloudflare, no ayuda a menos que retrase la respuesta. Pero retrasar la respuesta es justo lo contrario de lo que Cloudflare está para hacer
¿No es que el “ataque” aquí consiste en que cualquier usuario puede enviarle a otro un enlace a un recurso almacenado en caché en el CDN dentro de un mensaje? Tal vez lo entendí mal
No lo entiendo del todo. ¿Quién alguna vez consideró a Signal anónimo? Lo mismo con Discord. Si es así, tengo malas noticias. Ninguno de los dos es anónimo; para nada, en absoluto, ni un poco
Tampoco creo que alguna vez hayan hecho esa afirmación. Signal solo afirma que no puede leer los mensajes. De Discord no estoy seguro y me genera dudas. Incluso esa afirmación tiene huecos. Aunque la criptografía sea sólida, ¿revisaste a fondo la versión que estás usando y la compilaste tú mismo?
Como mucho, ofrecen una seudonimidad débil. Siempre ha sido común que las aplicaciones sacrifiquen algo de seguridad por comodidad del usuario y carguen medios por defecto, y en un modelo de amenazas general eso suele ser una decisión aceptable. Incluir medios en los mensajes también ha sido siempre un clásico de los ataques de desanonimización
Al final, esto solo demuestra que los píxeles de rastreo siguen siendo una técnica válida hoy en día; bien, pero no sorprende
Si quieres seguir siendo anónimo, no deberías usar Discord ni Signal, y tampoco recomendaría publicar en HN. Tal vez habría alguna posibilidad si usaras una cuenta desechable a través de Whonix, sin JavaScript, con mensajes reescritos por un LLM local y pegados automáticamente en horarios aleatorios. Aun así, no habría que darlo por seguro
La anonimidad ya no existe