Ataque de desanonimização 0-click contra plataformas como Signal e Discord
(gist.github.com/hackermondev)- Quando o cache da Cloudflare e as notificações push se combinam, é possível realizar um ataque de desanonimização 0-click que reduz a localização do usuário a uma faixa de algumas centenas de milhas em celulares com apps vulneráveis instalados ou notebooks com apps em segundo plano
- O atacante faz o dispositivo alvo carregar automaticamente recursos por trás da Cloudflare e depois investiga em qual data center da Cloudflare eles foram armazenados em cache para estimar a região próxima ao alvo
- No Signal, por causa do cache de anexos em
cdn2.signal.orge das notificações push no celular, imagens anexadas podem ser baixadas mesmo sem abrir a conversa; no Discord, o mesmo ataque é possível com a URL do avatar em notificações de solicitação de amizade - A Cloudflare corrigiu um bug relacionado ao Cloudflare Teleport que permitia enviar requisições a data centers específicos, mas foi relatado que, mesmo usando servidores VPN, ainda foi possível recuperar acesso a cerca de 54% de todos os data centers da Cloudflare
- Signal e Discord atribuíram a responsabilidade à Cloudflare ou ao usuário, enquanto a Cloudflare afirmou que desativar o cache de recursos protegidos é responsabilidade do cliente, deixando um risco de privacidade ligado ao design de apps, CDN e notificações
Como o cache da Cloudflare permite estimar localização
- Esse ataque usa as informações de estado de cache da Cloudflare e sua rede de data centers distribuídos geograficamente para estimar a localização aproximada do usuário
- A Cloudflare fornece informações em cabeçalhos de resposta para requisições de recursos que podem ser armazenados em cache
cf-cache-statusmostraHITouMISScf-rayinclui o data center que processou a requisição e o código do aeroporto mais próximo
- Quando o dispositivo alvo carrega um recurso hospedado atrás da Cloudflare, esse recurso pode ser armazenado em cache em um data center próximo ao alvo
- Depois, ao investigar vários data centers da Cloudflare para descobrir em quais o recurso foi armazenado em cache, é possível estimar a região próxima ao alvo
- A Cloudflare opera centenas de data centers em mais de 120 países e 330 cidades, e explica que, em países desenvolvidos, há alta chance de o data center mais próximo ficar a menos de 200 milhas de distância
Cloudflare Teleport e varredura de data centers
- Em geral, as faixas de IP da Cloudflare operam com anycast, então o usuário não consegue solicitar diretamente uma conexão TCP com um data center específico
- Com base em uma postagem de fórum da comunidade relatando que era possível contornar isso usando Cloudflare Workers e a faixa interna de IPs do Cloudflare WARP para enviar requisições HTTP a um data center específico, foi criado o Cloudflare Teleport
- O Cloudflare Teleport era uma ferramenta de proxy baseada em Cloudflare Workers que enviava requisições ao data center desejado ao definir um valor
colo- Por exemplo, era usado um código como
SEA, referente ao data center de Seattle - As informações de mapeamento entre certas faixas de IP e data centers eram organizadas em um arquivo como
colos.json
- Por exemplo, era usado um código como
- Depois, a Cloudflare corrigiu completamente esse bug, e a ferramenta Teleport não funciona mais dessa forma
Prova de conceito com o favicon da Namecheap
- Na primeira validação, foi usado o
favicon.icoda Namecheap - Esse recurso era uma imagem estática simples com cache da Cloudflare ativado, e foi escolhido como alvo de teste porque a proteção contra bots não era rígida
- A ferramenta de CLI listava, para uma URL especificada, quais data centers armazenaram o recurso em cache e a idade desse cache
- A Namecheap configurava a idade do cache para apenas 5 minutos, mas ainda assim foi possível verificar quais data centers haviam armazenado o favicon em cache nos 5 minutos anteriores
- Como o navegador baixa automaticamente o favicon ao abrir um site, esse resultado serviu como prova de conceito de que usuários em várias regiões haviam visitado Namecheap.com nos 5 minutos anteriores
Aplicação no Signal
- O Signal usa duas CDNs para entrega de conteúdo
cdn.signal.org: baseada em CloudFront, para avatares de perfilcdn2.signal.org: baseada em Cloudflare, para anexos de mensagens
- O caminho
https://cdn2.signal.org/attachments/*tem cache da Cloudflare configurado, então, quando um dispositivo baixa um anexo, ele pode ser armazenado em cache em um data center próximo -
Método 1-click
- Quando um usuário envia um anexo no Signal, o arquivo é enviado para
cdn2.signal.org - Quando o destinatário abre a conversa, o dispositivo baixa automaticamente o anexo, e a técnica de estimativa geográfica via cache da Cloudflare pode ser usada para restringir a localização do destinatário
- Nos testes, o SSL pinning do app Signal Desktop foi removido e as requisições e respostas foram inspecionadas com Burp
- Se o dispositivo do atacante baixar o anexo primeiro, um cache pode ser criado em um data center próximo ao atacante e contaminar o resultado; por isso, as requisições GET para
cdn2.signal.org/attachments/*foram bloqueadas no app Signal do lado do atacante - Em um teste contra si mesmo em Nova York, foi identificado o data center
EWR, em Newark, NJ, a cerca de 150 milhas das coordenadas reais
- Quando um usuário envia um anexo no Signal, o arquivo é enviado para
-
Método 0-click
- O app móvel do Signal inclui por padrão remetente e mensagem na notificação push
- Quando a mensagem contém uma imagem anexada, o dispositivo baixa essa imagem da CDN do Signal para exibi-la à direita da notificação
- Mesmo sem o alvo abrir a conversa no Signal, a chegada da notificação push pode fazer o download da imagem anexada e gerar cache em um data center da Cloudflare próximo ao alvo
- Isso leva a um ataque 0-click de estimativa da localização atual, sem interação do usuário
- Como o Signal é usado por jornalistas, ativistas e denunciantes, há risco de abuso para rastrear contas, correlacionar identidades e estimar a localização de pessoas que se encontram com repórteres
Aplicação no Discord
- O Discord também foi identificado como um app vulnerável ao mesmo tipo de ataque por causa de recursos em CDN com cache da Cloudflare ativado
- No método 1-click, foram usados emojis personalizados disponíveis para assinantes Nitro
- Emojis personalizados são carregados a partir da CDN do Discord
- Eles podem ser exibidos em mensagens, status de usuário, canais e outros locais
- O atacante pode colocar um emoji personalizado no status do usuário e esperar que o alvo abra o perfil
- O relatório completo enviado ao HackerOne sobre o Discord foi publicado em um Gist separado
-
0-click usando notificações de solicitação de amizade
- As notificações push do Discord para celular são enviadas em vários eventos, além de mensagens
- Ao enviar uma solicitação de amizade, uma notificação push é gerada no dispositivo móvel do alvo
- Mesmo que o alvo esteja usando o Discord, a notificação de solicitação de amizade ainda é sempre enviada ao celular
- A notificação inclui a URL do avatar do usuário que enviou o pedido, e o telefone baixa esse avatar sem interação do usuário para exibi-lo na notificação
- O formato da URL do avatar do Discord varia conforme o contexto
- Notificação push:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash} - Exibição no site:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png - As duas URLs apontam para a mesma imagem, mas como os caminhos são diferentes, são armazenadas em cache separadamente, permitindo distinguir o cache carregado pela notificação push daquele gerado pela exibição do perfil no app
-
Automação com GeoGuesser
- O procedimento do ataque 0-click no Discord foi automatizado por um bot privado do Discord chamado GeoGuesser
- Com um único comando, o bot recebia um nome de usuário e executava o seguinte
- Usava credenciais de conta na Discord User API
- Trocava o avatar do usuário por uma imagem aleatória para gerar um novo hash de avatar
- Enviava uma solicitação de amizade ao usuário especificado
- Executava o ataque de enumeração de cache por meio de uma API privada baseada na CLI do Cloudflare Teleport
- Exibia o resultado dentro do Discord em menos de 30 segundos
- Em uma demonstração com o CTO do Discord, Stanislav Vishnevskiy, foi mostrado que dois data centers da Cloudflare haviam armazenado o avatar em cache
- A razão para dois data centers terem sido observados pode ter sido o recebimento da notificação em vários dispositivos ou balanceamento de carga da mesma requisição para data centers diferentes
- O GeoGuesser calculava o ponto médio entre os dois data centers usando a Google Maps API e desenhava um círculo de raio correspondente
- No mapa da demonstração, a sede do Discord em San Francisco, CA, ficava dentro do círculo externo, e a localização real foi estimada perto da borda do círculo interno, em um alcance de cerca de 300 milhas
- Todo o processo levou menos de 1 minuto e o ataque era praticamente difícil de detectar
Bug bounty e resposta das organizações
- O Signal rejeitou imediatamente o relatório, afirmando que nunca tentou reproduzir completamente recursos de anonimato de camada de rede como WireGuard, Tor ou software VPN open source
- A contestação a essa posição é que o Signal é promovido como uma plataforma de comunicação com foco em privacidade, e os usuários esperam minimização de riscos de privacidade para além da criptografia de ponta a ponta
- O Telegram é citado como exemplo de app não vulnerável a esse ataque
- Usa um protocolo próprio que não depende de HTTP
- Não depende do cache de provedores de nuvem como a Cloudflare
- A equipe de segurança do Discord inicialmente disse que avaliaria mudanças para proteger os usuários, mas depois mudou de posição e passou a tratar isso como um problema da Cloudflare que também afeta outros clientes dela
- A Cloudflare corrigiu o bug usado pelo Cloudflare Teleport para percorrer data centers
- Esse bug havia sido reportado no HackerOne por outro pesquisador um ano antes, mas na época foi considerado sem impacto
- Após o compartilhamento desta pesquisa, a Cloudflare reabriu o relatório anterior e resolveu o problema, pagando US$ 200 de bounty tanto ao autor original quanto a este novo relato
Problema remanescente mesmo após o patch
- O que a Cloudflare corrigiu foi o bug que permitia percorrer data centers pela rede interna, mas a condição central que viabiliza a estimativa de localização por cache não desapareceu
- Foi informado que, mesmo após o patch, os ataques descritos no texto ainda foram executados nas 24 horas seguintes
- O Cloudflare Teleport foi reimplementado em uma abordagem baseada em VPN 24 horas após o patch
- O provedor de VPN escolhido tinha mais de 3.000 servidores em 31 países
- Com esse método, ainda foi possível recuperar acesso a cerca de 54% de todos os data centers da Cloudflare, cobrindo a maior parte das regiões densamente povoadas
- A posição final da Cloudflare é que esse ataque de desanonimização não é uma vulnerabilidade do seu sistema e que desativar o cache de recursos que exigem proteção é responsabilidade do cliente
- Clientes como o Discord tratam isso como responsabilidade da Cloudflare, enquanto a Cloudflare diz que o cliente deve ajustar o cache, deixando a fronteira de responsabilidade indefinida
Proteção e implicações práticas
- Esse ataque mostra que recursos de desempenho e usabilidade, como cache e notificações push, podem ser abusados como mecanismo de rastreamento quando combinados
- O bug do Cloudflare Teleport foi corrigido, e alguns apps como Signal e Discord podem ter aplicado mitigações após a divulgação, mas o risco básico permanece
- Apps que distribuem conteúdo por CDN e usam cache podem ficar vulneráveis ao mesmo tipo de ataque se não houver os devidos cuidados
- Para recursos que exigem proteção, é preciso considerar em conjunto a política de cache da CDN, imagens carregadas automaticamente em notificações push e o comportamento de cache de URLs exclusivas por usuário
- Jornalistas, ativistas, hackers e usuários sensíveis à privacidade precisam estar cientes de que notificações de apps e carregamento automático de recursos externos podem levar à exposição de localização
1 comentários
Opiniões no Hacker News
Se você envia uma foto a um usuário do Signal, ela é buscada via Cloudflare e armazenada em cache em um data center perto desse usuário. Depois, é possível consultar o status do cache para descobrir qual data center foi usado.
A menos que o usuário esteja em uma região isolada, chamar isso de desanonimização parece exagero, mas ainda assim é um texto interessante.
Ainda assim, a Cloudflare não vai servir o cache de Seattle, Manchester ou Tóquio, então só conseguir restringir um usuário desconhecido do Signal a uma localização geográfica aproximada já vira um metadado importante que pode ser combinado para identificar uma pessoa. É um ataque elegante.
A Cloudflare consegue ver uma quantidade enorme de metadados em conversas privadas e de grupo, e, pelo tamanho dos arquivos, rastrear quem enviou a mídia original, quem leu, quando leu, quem encaminhou e para quem. Mesmo sem ver diretamente imagens ou vídeos, basta saber o tamanho previamente, ou descobri-lo depois por meio de uma solicitação de autoridades, por exemplo.
Só essa informação ainda seria insuficiente, mas, se houver um suspeito específico, ajuda na confirmação. Se for possível abordar diretamente a pessoa suspeita e também tornar-se amigo do perfil “limpo” dela, a mesma técnica poderia ser usada para comparar os dois perfis de localização. Desanonimização não é uma única informação; é um processo em que todas as informações se somam a um perfil que estreita os suspeitos ou confirma uma suspeita.
Aqui, “investigador” significa uma pessoa comum, não um agente de IA nem uma autoridade policial. Se fosse uma autoridade policial, provavelmente conseguiria informações de forma mais direta na Cloudflare.
Se esse nível e tipo específicos de desanonimização são um problema para o seu caso de uso é outra questão. Pessoalmente, eu não me importaria muito se meus contatos vissem diretamente meu endereço IP, mas nem todos os usuários são assim.
Na investigação do Silk Road, esse tipo de informação de fato foi importante. Ulbricht revelou acidentalmente seu fuso horário no início, e isso permitiu às autoridades dos EUA restringi-lo a alguém que estava nos Estados Unidos. Sem essa informação, ele poderia estar em qualquer lugar do mundo.
É um bom texto, com uma técnica e uma abordagem interessantes.
Mas expressões como “desanonimização” ou “obter a localização do usuário” são um pouco exageradas. Está longe de ser uma localização precisa; 150 milhas é mais ou menos uma viagem de 2 horas pela estrada de Atlanta, GA, a Augusta, GA. Provavelmente há mais de 700 mil pessoas dentro desse raio.
O recurso de busca automática de anexos do Signal é um pouco preocupante. Em um mensageiro privado, eu esperaria haver uma opção para desativá-lo, como desligar JavaScript no Tor; talvez eu não tenha procurado a fundo, mas não encontrei esse recurso.
O Signal parece ter adotado uma abordagem “útil por padrão”, equilibrando privacidade e usabilidade para adoção em massa. Usuários realmente preocupados provavelmente já reforçam o Signal seguindo guias como https://www.privacyguides.org/articles/2022/07/07/signal-con.... Para cenários de alto risco, VPN/proxy e mudanças de configuração sempre foram recomendados.
O cache e a CloudFlare não vão desaparecer. A ameaça de DDoS nos antigos lobbies de multiplayer P2P, em que o IP ficava exposto, parecia maior do que isso, e, entre as terceiras partes, a resposta da CloudFlare parece a melhor. A regra é não armazenar informações sensíveis em cache, e a responsabilidade de avisar a CDN ou serviços intermediários para não armazenarem itens específicos em cache é da aplicação de comunicação.
Legal. Diferentemente de algumas outras coisas, isto certamente pode ser visto como desanonimização, ou pelo menos chega bem perto. Se fosse possível saber a localização de Satoshi dentro de um raio de 250 milhas, quão anônimo ele teria continuado até hoje?
Aplicando esse ataque repetidamente, escondido de alguma forma, seria possível rastrear deslocamentos ao longo do tempo. Normalmente, apenas 4 ou 5 localizações do tamanho de um CEP já bastam para identificar uma pessoa de forma única
A abordagem que Apple e Cloudflare usam em seus softwares de privacidade também se baseia na ideia de que a região não é uma informação que revela a identidade. É o caso do iCloud Private Relay da Apple ou do WARP da Cloudflare; quando o Apple Private Relay está ativado, o IP original fica oculto, mas o IP pelo qual o tráfego é roteado fica no mesmo país
https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
Esse ataque é academicamente interessante e novo, mas não é “desanonimização”
Claro, pode não ter sido ele; pode ter sido um usuário inicial aleatório. Mesmo assim, acho que há alguma chance de ter sido ele
Mais detalhes: https://news.ycombinator.com/item?id=29728339
Não apoio tentativas de descobrir e divulgar o nome e o endereço dele, pois isso poderia dificultar sua vida. Mas, em abstrato, é extremamente interessante como um mistério que, apesar de tantos olhares ao longo de anos, permaneceu sem solução
Não entendo por que tantos comentários no topo estão minimizando a gravidade. Este é exatamente o tipo de ataque que permite a órgãos de aplicação da lei ou agentes mal-intencionados estabelecerem prova de localização
Prova de localização não é desanonimização, especialmente quando essa “localização” é tão ampla assim
Primeiro tentam ignorar e ver se o problema ainda está lá de manhã. Até lá, esperam que alguém encontre um motivo para isso não ser um problema
Por que o Signal deixou cache ativado nesses URLs? O caso mais comum deve ser o anexo ser baixado uma vez e pronto
Eu esperaria, pelo contrário, que não permitisse mais de um download e que apagasse imediatamente após o primeiro download bem-sucedido. Claro que o cliente pode falhar no meio, então dá para ter um período de carência para novo download. Ainda assim, isso não parece ser o caso comum; desativar o cache no CDN corrigiria esse problema e espero que não aumente muito os custos
De todo modo, “desanonimização” aqui é uma expressão um pouco caça-cliques. Restringir a localização de alguém a cerca de 250 milhas não é bom, mas não desanonimiza essa pessoa
Edit: não tinha pensado no caso de anexos enviados em chats em grupo e baixados por várias pessoas. Mas, mesmo nesse caso, o anexo não é criptografado individualmente para cada pessoa do grupo? Claro, não sei exatamente como isso funciona na prática
Os itens mencionados são, na prática, configuráveis por quem quer esse nível insano de privacidade e segurança. Você pode fazer as mensagens serem apagadas automaticamente 30 segundos depois de vistas, configurar todo o tráfego para passar por um proxy e ajustar muitas outras coisas ao gosto do usuário
O motivo para usar cache provavelmente é o custo de tráfego de saída. Anexos de arquivos, mensagens de voz, vídeos etc. se acumulam e ficam grandes
Essa é a mesma pessoa de 15 anos que encontrou, alguns meses atrás, a vulnerabilidade de sequestro do Zendesk Slack [1]
[1]: https://news.ycombinator.com/item?id=41818459
Aquele bug report enviado à Adobe teria sido escrito quando ele tinha cinco anos: https://hackerone.com/daniel?type=user
Sem dúvida é um “ataque”, mas não é o tipo que normalmente se imagina ao falar em zero click. Não há execução de código; é um método para obter a localização muito aproximada do usuário usando alguns truques para descobrir em qual data center da Cloudflare a imagem foi cacheada.
Ainda assim, é impressionante e perspicaz.
Esse pessoal pode cooperar com recursos locais para fazer investigações adicionais. Só saber quais recursos, em qual região, precisam ser mobilizados já pode economizar muito dinheiro.
Como foi dito, é impressionante e perspicaz. O documento também dá um pouco a impressão de ter tido ajuda do ChatGPT, com muitas frases bem claras e específicas. Para esse tipo de uso, é um ótimo caso de uso, então não é uma crítica. Foi um bom texto.
Se eu não estiver deixando passar algo, isso parece uma forma extremamente prolixa de verificar a localização do IP do usuário.
Por exemplo, depois de me conectar a uma VPN e verificar https://cloudflare.com/cdn-cgi/trace, aparece
colo:CPH(Copenhague), que fica longe do data center da CF geograficamente mais próximo de mim e mais perto da localização do IP do provedor de VPN, em Oslo, embora ainda assim não seja exatamente perto.Sem VPN, nem aparece a capital do país onde estou agora, e sim um data center cerca de 250 milhas ao norte. Por isso, também é difícil concordar com a afirmação de que a Cloudflare sempre retorna “o data center disponível mais próximo”.
O texto em si é legal e sem dúvida interessante, mas não tenho certeza sobre a utilidade prática.
A utilidade prática e o risco potencial surgem quando esse dado é combinado com outros. Técnicas de desanonimização usando conjuntos de dados esparsos são uma área de pesquisa ativa há pelo menos 15 anos, e as pessoas frequentemente se surpreendem com o quanto é possível descobrir a partir de alguns fragmentos de dados que parecem não ter relação entre si.
Há um motivo para aplicativos se esforçarem tanto para fazer proxy de requisições a recursos como imagens. Isso não é de graça.
Qual seria a vantagem de cachear imagens em uma CDN no Signal?
Supondo que exista cache local no cliente, o número total de requisições para esse recurso deveria ser muito pequeno e, na maioria dos casos, provavelmente apenas uma.
Separadamente, parece que o CloudFront poderia corrigir esse problema com muita facilidade se não retornasse o cabeçalho
cf-rayou oferecesse aos clientes uma opção para removê-lo. Mas talvez ainda seja possível descobrir pelas informações de timing.Aqui, “próximo” é uma heurística aproximada e uma propriedade das tabelas de roteamento anycast dos roteadores BGP pelos quais a requisição passa. Na prática, é mais próximo de “melhor rota”.
cf-ray, basta olhar o tempo de resposta. Se o recurso tiver que ser buscado em outro continente, provavelmente dá para medir de forma confiável.É parecido com sites que tentam ocultar quais usuários existem. Se você faz uma tentativa de login com um nome de usuário existente, o site executa o hashing da senha, o que normalmente aumenta o tempo de resposta em pelo menos 50 ms; com um nome de usuário inexistente, ele encerra cedo. A solução é sempre executar o mesmo código e também sempre fazer o hashing, mas pouquíssimos sites fazem isso. Ou, se fizer sentido para o modelo de ameaça, também dá para informar imediatamente que o nome de usuário não existe.
Voltando ao caso da Cloudflare, isso não ajuda a menos que a resposta seja atrasada. Só que atrasar respostas é o oposto do que a Cloudflare deve fazer.
O “ataque” aqui não é que qualquer usuário possa enviar a outro usuário uma mensagem contendo um link para um recurso cacheado em uma CDN? Talvez eu tenha entendido errado.
Não entendi muito bem. Alguém algum dia considerou o Signal anônimo? O Discord idem. Se sim, tenho uma má notícia. Nenhum dos dois é anônimo; de jeito nenhum, nem um pouco
Eles nunca alegaram isso. O Signal só afirma que não consegue ler as mensagens. Sobre o Discord, não sei bem e tenho minhas dúvidas. Mesmo essa alegação tem brechas. Ainda que a criptografia seja sólida, você revisou minuciosamente a versão que está usando agora e compilou por conta própria?
No máximo, é uma pseudonimidade fraca. Sempre foi comum que aplicativos que sacrificam um pouco de segurança pela conveniência do usuário carreguem mídia por padrão, e isso é uma escolha aceitável nos modelos de ameaça comuns. Colocar mídia em mensagens também sempre foi um clássico dos ataques de desanonimização
No fim, isso só mostrou que pixels de rastreamento ainda são uma técnica válida hoje em dia; é algo bom, mas não surpreendente
Se você quer permanecer anônimo, não deveria usar Discord nem Signal, e eu também não recomendaria postar no HN. Talvez houvesse alguma chance se você, via Whonix, usasse uma conta descartável, sem JavaScript, colando automaticamente em horários aleatórios mensagens reescritas por um LLM local. Mesmo assim, não dá para garantir
Anonimato não existe mais