Vulnerabilidade que permitia acessar o navegador Arc sem visitar um site

 (kibty.town)
2 pontos por GN⁺ 2024-09-20 | 1 comentários | Compartilhar no WhatsApp
  • A combinação entre os Boosts do navegador Arc e um problema nas regras do Firestore permitia que um invasor vinculasse à conta da vítima um Boost contendo JavaScript arbitrário
  • O uso de Firebase Authentication e Firestore foi confirmado por hooking com Frida, revelando o fluxo de acesso às coleções preferences, users, user_referrals e boosts
  • A vulnerabilidade surgiu porque o alvo de aplicação do Boost era determinado por creatorID, mas o invasor podia alterar o creatorID de seu próprio documento de Boost para o ID de outro usuário
  • O ID da vítima podia ser obtido em user_referrals, nos boostSnapshots de Boosts públicos, em Easels compartilhados etc.; quando a vítima visitasse o site-alvo, o Boost malicioso poderia ser executado
  • The Browser Company pagou uma recompensa de US$ 2.000 junto com a correção e, após a atribuição de CVE-2024-45489, decidiu avançar com a redução do uso do Firebase, auditorias de segurança e um programa de bug bounty

Recursos de nuvem do Arc e uso do Firestore

  • O Arc exigia uma conta para uso, e foi confirmado que o processo de cadastro usava Firebase Authentication
  • Na observação inicial da rede, não apareciam outras requisições, mas ao analisar o recurso de compartilhamento do Easels surgiu a possibilidade de uso do Firestore
  • Easels é uma interface do tipo quadro branco que, ao ser compartilhada com outras pessoas, pode ser visualizada na web
  • O Firestore é um serviço de database-as-a-backend que permite criar funcionalidades com regras de segurança de banco de dados e acesso direto pelo cliente, sem um backend separado
  • Como exemplo anterior de regras de segurança frágeis no Firestore, foi relacionado o Firewreck

Como as chamadas ao Firebase foram confirmadas

  • Como o SDK Swift do Firebase tende a não seguir as configurações de proxy do sistema, em vez do mitmproxy foi usado um script Frida para despejar as chamadas relacionadas
  • O script fazia hooking de chamadas do Firestore em classes Objective-C
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • Métodos de execução como getDocuments, addSnapshotListener:, getDocument
    • Métodos de escrita de documentos das famílias updateData e setData
  • Durante a execução do Arc, foram observados os seguintes tipos de caminhos e consultas do Firestore
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • Consulta em user_referrals com inviter_id == {userID}
    • Consulta em boosts com creatorID == {userID}
  • Nessa estrutura, o Arc armazenava no Firestore algumas preferências, o objeto básico do usuário, informações de indicação e Boosts

Por que os Boosts viraram o caminho de ataque

  • Arc Boosts é um recurso que permite aos usuários personalizar sites
    • Bloqueio de elementos
    • Alteração de fontes
    • Alteração de cores
    • CSS personalizado
    • JavaScript personalizado
  • Os Boosts são armazenados no Firestore, e o navegador Arc consulta pelo campo creatorID para decidir quais Boosts aplicar
  • O invasor criou, em sua própria conta, um Boost para Google.com e testou alterando alguns parâmetros do documento no Firestore
  • Por causa da consulta baseada em creatorID, não era possível consultar diretamente Boosts de outros usuários, mas era possível alterar o creatorID do próprio documento de Boost para o ID de usuário de outra conta
  • Em um teste com outra conta, quando o computador da vítima acessou Google.com, o Boost criado pelo invasor foi aplicado

Cadeia de ataque e obtenção do ID de usuário

  • O fluxo final do ataque era o seguinte
    • Obter o ID de usuário da vítima
    • Criar, na conta do invasor, um Boost malicioso contendo o payload desejado
    • Alterar o campo creatorID do documento do Boost para o ID da vítima
    • Quando a vítima visitar o site-alvo, o Boost malicioso será executado
  • Essa vulnerabilidade se sustentava porque Arc Boosts podia conter JavaScript arbitrário, era armazenado no Firestore e o alvo de aplicação era decidido pelo campo creatorID
  • Havia várias formas de obter o ID de usuário da vítima
    • user_referrals: ao convidar alguém para o Arc ou receber uma indicação, era possível obter o ID de usuário da outra pessoa na tabela user_referrals
    • Boosts públicos: Boosts sem JavaScript podem ser compartilhados, e os boostSnapshots do site público de Arc Boosts incluem o ID de usuário do criador
    • Easels: também era possível obter o ID de usuário por meio do recurso compartilhável de quadro branco

Correção e cronograma de divulgação

  • The Browser Company normalmente não mantinha bug bounty, mas pagou US$ 2.000 por essa vulnerabilidade
  • O cronograma da vulnerabilidade foi o seguinte
    • 25 de agosto, 17h48: primeiro contato por Signal com Hursh, cofundador do Arc
    • 25 de agosto, 18h02: execução do PoC da vulnerabilidade na conta Arc de Hursh
    • 25 de agosto, 18h13: detalhes compartilhados em formato criptografado, seguido de adição a um canal do Slack
    • 26 de agosto, 21h41: vulnerabilidade corrigida e recompensa paga
    • 6 de setembro, 19h49: CVE-2024-45489 atribuída
  • Depois disso, o Arc publicou seu próprio texto sobre o caso, CVE-2024-45489 incident response

Execução em páginas privilegiadas e conflito com privacidade

  • Mesmo que Boosts não pudessem ser criados no cliente, eles podiam ser executados em outros protocolos
  • Ao criar um Boost tendo a página settings como alvo, ele era executado em chrome://settings, o que poderia levar a elevação de privilégios
  • Ao visitar um site, ocorria a seguinte consulta ao Firestore
    • Consulta na coleção boosts com as condições creatorID == {userID} e hostPattern == "www.google.com";
  • Nesse caso, hostPattern significa o site visitado, o que entra em conflito com a política de privacidade do Arc, que afirmava que o Arc não sabia quais sites eram visitados

Medidas posteriores do Arc

  • Com a vulnerabilidade e a introdução de novos recursos, o Arc passou a caminhar na direção de sair do Firebase
  • O resumo do próprio Arc incluía as seguintes medidas
    • Confirmar a correção do problema
    • Adicionar um recurso para desativar Boosts no cliente
    • Auditoria interna das regras atuais de ACL do Firebase
    • Estabelecimento de um protocolo de resposta a questões de segurança
  • As medidas adicionais compartilhadas em discussões internas do Arc foram as seguintes
    • Corrigir o problema de privacidade na atualização v1.61.1
    • Deixar de usar Firebase em novos recursos e produtos
    • Auditoria externa de segurança para essa versão
    • Lançar um programa de bug bounty para vulnerabilidades futuras

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-20
Comentários do Hacker News

  • Aqui é Hursh, cofundador e CTO da The Browser Company, que faz o Arc. Não houve usuários realmente afetados e corrigimos isso imediatamente, mas considero a gravidade potencial dessa vulnerabilidade inaceitável
    Reuni aqui os detalhes técnicos e os planos de melhoria daqui para frente, incluindo sair do Firebase e criar um programa formal de bug bounty: https://arc.net/blog/CVE-2024-45489-incident-response
    Sinto muito de verdade tanto pela vulnerabilidade em si quanto pela demora na comunicação, e o feedback — incluindo decepção, raiva e encorajamento — me faz sentir ainda mais responsabilidade para fazer melhor

    • Fico na dúvida se esse texto foi escrito só para usuários do HN verem. Ele nem aparece na lista do blog (https://arc.net/blog) e também não foi postado no Twitter
      Parece que só reagiram quando a situação ficou barulhenta o suficiente
    • Alguns amigos meus gostam do Arc e eu até considerei migrar, mas agora não pretendo usar. Não é tanto pela vulnerabilidade em si, e sim porque pagaram apenas US$ 2 mil de recompensa por um bug capaz de comprometer todos os usuários de forma perigosa
      Não quero usar um navegador feito por uma empresa que trata a segurança dos usuários com tanta leveza. Não tenho certeza, mas para algo dessa gravidade provavelmente daria para vender por muito mais no mercado clandestino
    • Nos comentários abaixo há preocupação sobre se eles estariam enviando a URL e um ID de usuário identificável para a TBC a cada carregamento de página. Quem usa navegador que não seja Chrome provavelmente também tende a se importar mais com privacidade, então seria bom responder a isso
      Vulnerabilidades podem acontecer, mas enviar dados de navegação parece uma escolha deliberada de design
    • Depois de ver isso, não parece haver como convencer alguém de que a equipe tem a especialização necessária para manter um navegador. Independentemente de terem corrigido, não parecem ter capacidade de fazer um navegador seguro, nem agora nem no futuro
      Acho que é um caso em que o CTO deveria renunciar
    • Gostaria de saber se há planos para aumentar o valor pago no bug bounty. US$ 2.000 é um valor muito pequeno comparado ao que esse bug vale, e espero que deem uma recompensa adequada a quem o encontrou
      É praticamente uma oportunidade perfeita para tomar a direção certa

  • Muita gente aqui nos comentários está culpando o Firebase, mas parece mais repetir algo que não entende de fato. Eu não uso Firebase, mas já usei antes, e isso não é um caso de canto nem um problema difícil de resolver; é o básico do básico
    O problema real foi fazer a API confiar em um valor que o cliente informa para dizer “quem ele é”. No fim das contas, é provavelmente um erro de amador, e talvez desse para corrigir com uma única linha. Só de olhar a documentação, em https://firebase.google.com/docs/rules/rules-and-auth#cloud-... o request.auth já fornece o ID de usuário necessário (request.auth.uid)

    • Concordo, como alguém que opera um app feito com Firebase. Como o autor apontou corretamente, é muito fácil errar na configuração, mas essas práticas básicas de segurança são enfatizadas com avisos em destaque e em negrito na documentação do Firebase
      As regras de segurança precisam ser tratadas com seriedade e, na prática, são praticamente a única linha de defesa
    • É curioso ver engenheiros de software primeiro criando autenticação por conta própria, depois migrando para não fazer isso, e agora não conseguindo perceber nem um problema de segurança tão óbvio quanto este
      Fazendo autenticação própria ou não, o ponto central é um só: nunca confie no cliente
    • Se for “um erro de amador no fim das contas”, até que seria melhor. Meus colegas também já cometeram exatamente o mesmo erro várias vezes em apps internos de frontend
    • Um plano de segurança que depende da premissa de que ninguém jamais cometerá um erro de amador já é, por si só, um erro de amador
    • Se entendi corretamente, a correção desse problema teria sido algo como colocar a regra abaixo dentro de um match no firestore.rules. Isso aparece exatamente na documentação introdutória de segurança do Firebase Firestore 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

  • Eu adorei o pequeno gato em pixel art que vinha correndo até onde eu clicava. Foi um detalhe divertido e criativo, difícil de ver com frequência hoje em dia, e pareceu um lembrete de que a internet também pode ser um lugar assim, se quisermos

    • Aqui não apareceu, mas parece que o desenvolvedor respeitou prefers-reduced-motion, então ele não é exibido quando essa configuração está ativa. Uma excelente solução: dá alegria a quem quer isso e evita incômodo para quem não quer
    • Para um gato de 35 anos, ele está se mexendo muito bem
      https://en.wikipedia.org/wiki/Neko_(software)
    • No Debian, dá para instalar e executar o gato com o seguinte
      sudo apt install oneko
      oneko &
      Ótimo para presentear o computador do colega que deixou a mesa por um instante
    • É fofo, mas saber que o gato ia se mover toda vez que eu mexesse o mouse ou rolasse a página me atrapalhou a focar no texto. Abri o console e removi. Desculpa, gatinho
    • No celular, ele ficava cobrindo o texto e eu estava tentando descobrir como me livrar dele. O modo leitura do Firefox resolveu

  • Segundo este texto, o Arc exige conta e envia para o Google Firebase o nome do host de todas as páginas visitadas e o ID do usuário. Nesse caso, o Arc não seria o navegador com pior privacidade entre os que existem hoje?

    • Apaguei o Arc logo depois de instalar, quando vi que a conta era obrigatória. Parecia tão absurdo quanto uma escova de dentes que precisa de Wi‑Fi, mas agora vejo que é ainda pior
    • Acho que esse título ficaria com o OperaGX
    • Também fico curioso para saber o quanto o Arc quebraria se o Firebase saísse do ar
    • Quando baixei há alguns meses, vi que precisava de conta para usar e tive a impressão de que era melhor simplesmente continuar no Firefox
    • Eles não criptografam os dados enviados ao Firebase? Se forem dados sensíveis, até o próprio Google deve recomendar que façam isso

  • É um bug realmente impressionante. As regras de segurança de serviços de backend como o Firebase têm padrões estranhos que são difíceis de explicar. Se eu mesmo criasse a API, definiria o userId de um registro como o boost deste caso com base no ID de usuário da sessão, em vez de recebê-lo no payload da requisição
    Qualquer desenvolvedor minimamente experiente normalmente nem cogita deixar que o cliente envie, numa rota de API protegida, um valor alegando ser seu próprio userId. Já nas regras de segurança, é preciso imaginar todas as formas de abuso do sistema, independentemente de como o uso real foi programado

    • Sinceramente, se você aborda dessa forma, está fazendo errado. Se começar com negação por padrão, só precisa imaginar os usos legítimos
    • Isso vale para inserção, mas em atualização vejo com frequência casos em que jogam a requisição inteira no ORM ou no armazenamento de documentos. É fácil pensar “o dono pode atualizar o documento”, mas esquecer que certos campos que o cliente oficial não define — por exemplo, o proprietário ou o horário de criação — não deveriam poder mudar
      A solução correta provavelmente é ter permissões de negação por padrão para todos os campos. Assim, no mínimo, seria preciso marcar explicitamente o campo de proprietário como gravável e pensar nas implicações de transferir esse objeto para outro usuário

  • Impressiona o quão absurdamente idiota essa vulnerabilidade é. Para obter execução arbitrária de código, bastava literalmente enviar o ID de usuário de outra pessoa, e esse ID também era bem fácil de conseguir
    Não trabalho numa FAANG, e trabalho numa empresa que faz um produto ruim de que ninguém realmente precisa, mas nem eu cometeria um bug desses. Aí esses caras querem fazer um navegador e ainda assumir toda a especialização em segurança e a responsabilidade moral que isso implica?

    • Alguém pode explicar como seria possível obter o ID de usuário de outra pessoa? Entendo que é uma grande vulnerabilidade, mas queria entender como essa parte acontecia

  • Seria bom que colocassem Arc no título do post, para que quem usa o Arc ou conhece alguém que usa perceba melhor

    • Concordo totalmente. Quando vi isso pela primeira vez ontem, não percebi que se aplicava a mim, e só cliquei depois que o título foi alterado
      Sinceramente, acho fortemente que o título deveria ser algo como “Bug fundamental no navegador Arc (CVE 123-4567)”

  • Há muitas vulnerabilidades de segurança graves que são compreensíveis e podem ser perdoadas se tratadas com responsabilidade e corrigidas direito
    Mas este não é um desses casos. Pessoalmente, isso mostra um nível de incompetência capaz de arruinar reputações, a ponto de me fazer decidir nunca mais usar o Arc

    • Por outro lado, a velocidade da resposta em si foi bastante impressionante
      aug 25 5:48pm: primeiro contato com Hursh, cofundador do Arc, por canal criptografado do Signal
      aug 25 6:02pm: execução da prova de conceito da vulnerabilidade na conta do Arc de Hursh
      aug 25 6:13pm: detalhes divulgados em formato criptografado e entrada no canal do Slack
      aug 26 9:41pm: vulnerabilidade corrigida, recompensa paga
      sep 6 7:49pm: CVE atribuído (CVE-2024-45489)
      Quatro horas entre o contato inicial repentino e a distribuição da correção já seria bem bom, mesmo considerando que a correção talvez fosse simples. Correção: como a data virou, na verdade foram 28 horas. Ainda assim é respeitável, e responder com “entre no nosso canal do Slack” apenas 30 minutos após o primeiro contato foi muito rápido
    • O fato de até para testar o Arc uma vez ser preciso conta obrigatória já era um grande sinal de alerta desde o começo, por isso nem cheguei a experimentar. Agora fico feliz por não ter usado
    • Sinceramente, sempre vi o Arc, especialmente na questão da privacidade, como um lobo em pele de cordeiro
      Num produto tão importante e pessoal quanto um navegador, receber entre 50 e 60 milhões de dólares em caixa e uma avaliação de 500 milhões de dólares sem ter modelo de negócio é um enorme sinal de alerta. Não é filantropia; alguém vai acabar pagando a conta de algum jeito
    • Quando uma empresa distribui um navegador, é natural esperar que preste um pouco mais de atenção às regras de segurança
      Também é uma pena que o Firebase não consiga tornar isso mais à prova de idiotas. E foram mesmo só $2,500? Era literalmente possível tomar controle de todos os usuários do Arc; a NSA teria acrescentado mais alguns zeros
    • E ainda por cima Firebase, sério mesmo? Uma empresa que contratou até engenheiros de software de baixo nível está usando um backend CRUD de caixinha. Talvez tenha sido eficiente em custos, mas, se eu projetasse algo assim, o Firebase nem entraria na lista longa de candidatos a backend
      Ainda mais quando concorrentes funcionais como o Supabase seguem a abordagem de encapsular um DBMS comum e um modelo de autenticação

  • Obrigado por compartilhar. Uso o Arc desde a primeira semana do beta
    Mas o fato de eles não terem mencionado esse bug nem a correção em nenhuma rede social é bem preocupante. Foi agradável usar o Arc, mas vendo como trataram isso, não acho que conseguirei continuar usando

    • Não basta ter reconhecido o problema e corrigido em 28 horas? Com uma resposta dessas, eu pensaria que dá para continuar usando o Arc

  • $2,000 por uma vulnerabilidade desse tamanho é um valor insultante

    • Pelos posts de blog no HN, parece que muitas vezes vulnerabilidades desse tipo não recebem recompensa alguma ou recebem quantias muito baixas. Dá até a impressão de que as empresas estão implorando para que vendam o exploit a hackers
      Talvez isso aconteça porque elas não sofrem punições regulatórias por incidentes de violação
    • Sim, essa também foi minha primeira reação. Fiquei realmente surpreso com o quanto quiseram economizar
    • Seria preciso ter uma consciência muito forte para não vender isso para um lado malicioso disposto a pagar de 20 a 50 vezes esse valor