2 pontos por GN⁺ 27 일 전 | 1 comentários | Compartilhar no WhatsApp
  • O tráfego HTTPS real do app iOS da Casa Branca foi capturado com um proxy MITM para analisar com quais servidores ele se comunica e quais dados troca
  • Além de whitehouse.gov, o app se comunica com 31 hosts de terceiros, incluindo Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook e Twitter
  • Para o OneSignal, são enviados continuamente dados de perfil do usuário como idioma, fuso horário, IP, modelo do dispositivo e número de sessões
  • Scripts externos são executados por meio do carregador de widgets do Elfsight, e o código de rastreamento publicitário do Google DoubleClick também roda dentro do app
  • Embora o manifesto de privacidade do app indique “nenhuma coleta de dados”, na prática ocorrem vários rastreamentos de terceiros e transmissões de dados

Visão geral da análise de tráfego de rede

  • O tráfego de rede do app oficial para iOS da Casa Branca foi capturado e analisado com um proxy MITM (man-in-the-middle)
    • No ambiente macOS, foi instalado o mitmproxy, e todo o tráfego HTTPS do iPhone foi registrado por meio do proxy
    • A versão do app era v47.0.4 (build 81), e foram exploradas todas as abas: Home, News, Live, Social e Explore
    • O tráfego foi descriptografado e registrado sem adulteração, exatamente como no uso normal de um usuário comum

Servidores acessados pelo app

  • Em uma única sessão, o app enviou requisições para 31 hosts únicos (excluindo o tráfego de sistema do iOS)
    • De um total de 206 requisições, apenas 48 (23%) foram enviadas para whitehouse.gov
    • As 158 restantes (77%) foram enviadas para serviços de terceiros como Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook e Twitter
  • Principais destinos das requisições
    • whitehouse.gov: API do WordPress (notícias, página inicial, galeria etc.)
    • YouTube: incorporação de vídeos e miniaturas
    • Elfsight: carregamento de widgets, ativos estáticos, armazenamento de arquivos e API de boot
    • OneSignal: análise e perfilamento de usuários
    • Facebook/Twitter CDN: carregamento de imagens
    • Google APIs e DoubleClick: publicidade e rastreamento

Dados enviados ao OneSignal

  • Ao iniciar o app, um corpo de requisição HTTPS é enviado para api.onesignal.com
    • Informações incluídas: idioma, fuso horário, país, endereço IP, horário da primeira execução e da última atividade, modelo do dispositivo, versão do sistema operacional, tipo de rede (Wi-Fi/celular), operadora, status de jailbreak, número de sessões, duração da sessão e identificador único
  • A cada execução do app, várias requisições PATCH são enviadas para atualizar o perfil
    • Na primeira execução, houve 18 requisições PATCH; na sessão inteira, foram confirmadas 9 requisições ao OneSignal
    • Sequência: consulta do perfil existente com GET → atualização das informações de sessão com PATCH
  • O OneSignal registra continuamente IP por sessão, horário de atividade, número de sessões e duração das sessões
    • Quando o endereço IP muda, o perfil é atualizado
    • O timestamp first_active não muda depois do momento da instalação
  • Como resultado, o OneSignal mantém um perfil persistente por usuário e rastreia padrões de uso do app e o ambiente de rede
  • O User-Agent do tráfego é WhiteHouse/81 CFNetwork/3860.400.51 Darwin/25.3.0

Tráfego relacionado ao Elfsight

  • Os 6 widgets e o carregador JavaScript em 2 etapas identificados na análise estática também foram confirmados no tráfego real
  • Ao abrir a aba Social, o app se conecta a 13 domínios do Elfsight
    • Incluindo elfsightcdn.com, core.service.elfsight.com, static.elfsight.com, storage.elfsight.com, widget-data.service.elfsight.com, video-proxy.wu.elfsightcompute.com etc.
  • Ao enviar cada ID de widget por meio da requisição /p/boot/, o servidor retorna uma lista de scripts a serem executados (array assets)
    • Exemplo: TikTok → tiktokFeed.js, Instagram → instashow.js, Facebook → facebookFeed.js, YouTube → yottie.js
  • A função loadAssets do app insere cada URL como <script> e a executa
    • Trata-se de uma estrutura em que o servidor decide qual código será executado
  • Os servidores do Elfsight definem mais de 10 cookies durante a sessão
    • Incluindo elfsight_viewed_recently, cookies de rastreamento da Cloudflare (_cfuvid, __cf_bm) e identificadores de sessão

Rastreamento publicitário do Google DoubleClick

  • Ao incorporar vídeos do YouTube, a infraestrutura de rastreamento publicitário do Google também é carregada
    • Foram confirmadas requisições para googleads.g.doubleclick.net e static.doubleclick.net
  • O DoubleClick é a plataforma de veiculação de anúncios e rastreamento do Google, e o código de rastreamento publicitário é executado dentro do app oficial da Casa Branca
    • Esse conteúdo não é declarado no manifesto de privacidade do app

Divergência entre o manifesto de privacidade e o comportamento real

  • Configurações de privacidade declaradas pelo app:
    NSPrivacyCollectedDataTypes: []
    NSPrivacyTracking: false
    
  • Transmissões de dados confirmadas na sessão real:
    • Envio ao OneSignal de modelo do dispositivo, sistema operacional, IP, fuso horário, idioma, número de sessões, duração das sessões e identificador único
    • Acesso a 13 domínios do Elfsight e recebimento de mais de 10 cookies de rastreamento
    • Execução do código de rastreamento publicitário do Google DoubleClick
    • Requisições para Facebook, Twitter/X, YouTube e Google APIs
  • Como resultado, embora o app indique “nenhuma coleta de dados”, na prática ocorrem vários rastreamentos de terceiros e transmissões de dados

Metodologia da análise

  • Ferramenta de proxy: mitmproxy (mitmdump)
  • Ambiente: macOS, iPhone (iOS), mesma rede Wi-Fi
  • Certificado: a CA do mitmproxy foi adicionada às configurações de confiança do iOS
  • Escopo da captura: tráfego HTTPS gerado durante a navegação completa pelas 5 abas do app
  • Houve adulteração?: não, o tráfego foi apenas observado
  • Tratamento de dados pessoais: IP, identificadores do dispositivo, ID do OneSignal etc. foram todos mascarados na publicação
  • Nenhuma invasão ou manipulação de servidores, apenas a comunicação voluntária do app foi registrada

Pesquisas relacionadas

  • Relatório de análise estática do app iOS da Casa Branca
  • Resultado da análise da Thereallo da versão Android

Sobre a Atomic Computer

  • A Atomic Computer é uma empresa que fornece serviços de cibersegurança, infraestrutura e desenvolvimento
  • Também realiza serviços de avaliação e análise de segurança de aplicativos móveis

1 comentários

 
GN⁺ 27 일 전
Comentários do Hacker News
  • De todos os pedidos para terceiros, 43% são relacionados ao Google (incluindo YouTube, Fonts e Analytics) e, somando Facebook e Twitter, dá algo em torno de 55%
    É problemático um app do governo incluir rastreamento ou código de analytics em excesso, mas não considero Google Fonts ou embeds do YouTube algo tão grave assim
    Pelo título, eu esperava algum domínio chocante como Palantir ou ICE, então ver Google/Facebook pareceu meio sem graça
    Em vez de simplesmente dizer no título que “77% são pedidos para terceiros”, ele deveria focar mais na natureza e gravidade desses pedidos
    Aliás, o atomic.computer também usa Google Fonts e Analytics. Antes de tratar qualquer pedido a terceiros como algo necessariamente ruim, vale checar o próprio site também

    • Nada impede que ICE ou Palantir comprem dados do Google ou do Facebook
      No fim, eles podem decidir por conta própria que tipo de dado rastrear via app, e até coletar dados de forma “lavada” por meio de provedores de rastreamento comuns
    • Na matéria em si, o foco estava mais nos pedidos para OneSignal e Elfsight do que em Google ou YouTube
      Os pedidos relacionados ao Google parecem ter sido incluídos por transparência, não como uma tentativa de atacar o app da Casa Branca
    • Dá para ver hoje tentativas do governo de empurrar os EUA para uma direção autoritária, mas acho que é um sistema grande demais para mudar tão facilmente
    • Rebater com algo como “o atomic.computer também usa pedidos para terceiros” é um argumento fraco de ‘atacar o mensageiro’
      O atomic.computer não disse que pedidos para terceiros são intrinsecamente ruins; apenas os analisou como mecanismos de coleta de dados e rastreamento
      O usuário não tem controle sobre como os dados serão usados depois de coletados, então no fim a questão central é a falta de controle
  • Disseram que instalaram o mitmproxy no Mac e rotearam o tráfego do iPhone por ele para descriptografar HTTPS
    Fiquei curioso se é mesmo tão fácil fazer o iPhone confiar em um certificado de usuário
    No Android, inspecionar o tráfego de rede costuma ser bem trabalhoso
    Esse tipo de experimento mostra bem por que precisamos ter controle sobre nossos dispositivos. Temos o direito de saber para onde os dados vão e o que está sendo enviado
    Também me lembrou do caso em que o Zoom enviava tráfego para a China, e de quando o Facebook rastreava dados de navegação dentro do app

    • O iOS ainda confia por padrão em certificados instalados pelo usuário
      A exceção é quando o app usa seu próprio OpenSSL ou aplica certificate pinning
      Apps grandes como Facebook ou Twitter geralmente usam pinning, mas apps simples assim normalmente não
    • No iOS, configurar o mitmproxy é muito mais fácil do que no Android
      Ainda assim, apps com pinning são difíceis de contornar, e plataformas onde é possível instalar o próprio app acabam sendo mais vantajosas
    • O processo de instalar a CA é meio incômodo, mas, se o app não usa pinning, interceptar o tráfego não é difícil
      Em casos como apps bancários, onde o pinning é forte, pode ser necessário um dispositivo com root
    • O curioso é que parte da comunidade de segurança critica proxies MITM, mas no fim está impregnada de uma visão centrada nas empresas
    • Quando o Zoom enviava tráfego para a China, pode até ter acontecido de vídeos de reuniões governamentais irem junto
      Dá até para imaginar que isso possa ter virado dados de treino para deepfakes
  • Há tópicos anteriores relacionados
    Discussão anterior 1, Discussão anterior 2

  • Eu bloqueio a maioria dos domínios de anúncios (por exemplo, doubleclick.net) no nível de DNS
    Impressiona como a maior parte dos sites, incluindo portais de notícias, abre uma infinidade de conexões com terceiros
    O atomic.computer também tenta carregar Cloudflareinsights e Google Fonts, mas isso é bloqueado na minha rede
    Esses pedidos são uma das principais razões pelas quais o Google consegue rastrear usuários por toda a internet

  • Apps do governo deveriam ser submetidos a um padrão muito mais alto do que apps B2C comuns
    Carregar Google Fonts tudo bem, mas enviar telemetria para OneSignal ou Facebook é outra história
    Na Austrália, pelas normas PSPF e ISM, dados do governo não podem ser enviados para fora não confiável
    Um app desses reprovaria imediatamente numa avaliação IRAP
    A solução é simples — hospedar as fontes localmente, usar analytics próprios e tratar pedidos externos como vetores de exfiltração de dados

    • Na prática, esses padrões altos existem, mas o governo atual não os segue
    • Há também quem questione por que apps do governo deveriam ter um padrão mais alto. No fim, seria só uma questão de marca
  • A maioria dos apps B2C também tem mais de 50% de pedidos para terceiros
    Os 77% do app da Casa Branca não são surpreendentes, mas o problema foi ele ter declarado incorretamente os itens de coleta de dados na App Store
    Depois isso foi corrigido e agora aparece de forma correta

    • Eu sou contra a telemetria de terceiros no app da Casa Branca e também nos outros apps. Dá para fazer multitarefa
    • O cerne do problema é justamente que o app da Casa Branca foi feito como se fosse um app B2C
    • Houve até alegações exageradas de que o app da Casa Branca enviava dados para a Huawei, mas o que surpreende de fato é ele ter 20% a mais do que outros apps
  • Apps do governo realmente deveriam ter padrões mais altos, mas a taxa de 77% talvez não esteja tão distante da média do setor
    Como inúmeros apps incluem código de anúncios e rastreadores, esse nível pode ser até algo comum

  • Dá para ver a lista de SDKs usados pelo app no AppGoblin

  • O Privacy manifest diz “nenhuma coleta de dados”, mas na prática ele envia para o OneSignal modelo do dispositivo, IP, número de sessões e ID de rastreamento
    Isso é claramente um caso de falsa declaração (false attestation)

  • O próximo passo provavelmente será adicionar anúncios