Pesquisador descobre falha no site da a16z que expôs dados de algumas empresas

 (kibty.town)
1 pontos por GN⁺ 2024-07-21 | 1 comentários | Compartilhar no WhatsApp
  • Um pesquisador de segurança descobriu que, no subdomínio relacionado à a16z portfolio.a16z.com, o process.env completo de uma instância Heroku estava sendo incluído dinamicamente em JavaScript
  • Entre os valores expostos estavam várias credenciais de serviços, como DATABASE_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, MAILGUN_API_KEY e outros
  • O pesquisador afirmou que, durante uma checagem rotineira em busca de segredos em arquivos JS com o lunchcat, encontrou uma referência a chaves da AWS e que isso podia ser verificado apenas pela aba Sources das ferramentas de desenvolvedor do navegador
  • O impacto potencial incluía banco de dados com PII, AWS, Salesforce e Mailgun; no caso do Mailgun, ele alegou que era possível enviar e-mails arbitrários a partir do domínio da a16z e ler e-mails antigos
  • A a16z não pagou recompensa de bug bounty alegando que o pesquisador tentou contato publicamente, e ele disse que não havia contato no site principal e que o e-mail que encontrou retornou

Variáveis de ambiente expostas durante auditoria de subdomínio

  • O pesquisador disse que encontrava alvos buscando empresas no Twitter e fazendo testes rápidos de invasão, usando com frequência a aba Relevant People
    • Neste caso, o caminho foi: empresa ligada a crypto → venture capital de cripto → a16z crypto → a16z
  • Durante a investigação da a16z, ele fez um scan de subdomínios comum e usou a ferramenta lunchcat para inspecionar o domínio e detectar segredos em arquivos JS
  • portfolio.a16z.com parecia ser uma ferramenta de gestão de portfólio para empresas pertencentes à a16z, e durante a auditoria foi detectada em algum ponto do site uma referência a chaves da AWS
  • Dentro do JS, valores que pareciam ser todo o process.env da instância Heroku estavam sendo inseridos dinamicamente
    • Entre os itens incluídos estavam MARKETPLACE_URL, DATABASE_URL, SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, SESSION_SECRET, MAILGUN_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, COOKIE_SECRET, HEROKU_POSTGRESQL_CRIMSON_URL e outros
    • O pesquisador disse ter verificado rapidamente as credenciais e que elas pareciam ser credenciais reais, não falsas
    • Segundo ele, bastava abrir a aba Sources nas ferramentas de desenvolvedor do navegador

Alcance potencial da exposição e polêmica sobre bug bounty

  • Os serviços que o pesquisador listou como potencialmente comprometidos foram os seguintes
    • Banco de dados: ele afirmou que continha PII
    • AWS: foi mencionada a possibilidade de acesso por meio das chaves expostas
    • Salesforce: ele não verificou diretamente e acrescentou que os privilégios da conta poderiam ser limitados
    • Mailgun: ele disse que era possível enviar e-mails arbitrários a partir do domínio da a16z e também ler e-mails antigos
    • Também mencionou a possibilidade de haver outros serviços afetados
  • A a16z não pagou bug bounty alegando que o pesquisador tentou contato publicamente em vez de entrar em contato de forma privada
  • O pesquisador apresentou dois motivos para ter tentado contato publicamente
    • Não conseguiu encontrar um contato utilizável no site principal da a16z
    • O e-mail que conseguiu encontrar retornou
  • Como material relacionado, foi anexado um artigo da TechCrunch; o pesquisador disse que Lorenzo viu o tweet que ele publicou tentando falar com a a16z e então entrou em contato para escrever a matéria

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-21
Comentários no Hacker News

  • Quando lançamos nosso projeto open source(https://github.com/heyPuter/puter/), a Eva fez um teste de invasão bem abrangente e também lidou com o reporte de vulnerabilidades de forma muito profissional
    Na época nem existia programa de bug bounty, e ela também não pediu recompensa; a Eva é uma hacker excelente e responsável, então a a16z deveria tratá-la melhor

  • Já cometi um erro parecido
    Eu usava o CMS Node.js chamado apostrophecms, e usava o painel administrativo de global settings para gerenciar chaves de API do servidor de autenticação, mas só meses depois percebi que aqueles valores estavam sendo exibidos no código-fonte HTML
    Aquilo foi feito assim para uso em JavaScript, e estava documentado, então não culpo eles por isso, mas nós deixamos passar
    O mais irritante é que pagamos um bom dinheiro a uma grande consultoria para fazer teste de invasão, e eles também não perceberam; no fim, acabamos descobrindo por conta própria e, ao verificar os logs, não parecia haver sinais de exploração, mas foi um vazamento bem chocante

    • Nesse teste de invasão eu no mínimo pediria reembolso
      Até hoje, nunca vi teste de invasão que fosse mais do que preencher checklist
    • Sinto muito que você tenha passado por uma exposição inesperada usando ApostropheCMS
      Como você disse, essa forma de compartilhamento de dados estava na documentação, mas ainda assim pode surpreender
      Para quem for investigar isso no futuro, vale acrescentar que a principal versão do Apostrophe atualmente suportada não funciona mais assim
      Injetar dados no frontend deslogado agora é algo que o desenvolvedor precisa escolher intencionalmente, e isso foi alterado justamente para evitar esse tipo de surpresa
      Ainda assim, continuam existindo casos de uso em que é preciso incluir chaves de API nas configurações de certos widgets e em parte do conteúdo
      Para referência, sou o responsável de design do Apostrophe e também atuo em funções de engenharia
    • Fico me perguntando por que um sistema de gerenciamento de conteúdo baseado na web foi usado para gerenciar segredos
    • Correção: não estou tentando culpar o apostrophe cms
      Essa situação aconteceu por causa da nossa configuração multitenant e da nossa falta de entendimento sobre o apostrophe
    • Você disse “estava na documentação, então não culpo eles. Nós deixamos passar”, mas ainda assim deveria culpar sim
      Documentar um comportamento perigoso não isenta ninguém de responsabilidade, e acho que essa lição já deveria ser amplamente conhecida

  • Quando você cria um novo serviço e coloca um certificado LetsEncrypt no servidor com ACME, os logs logo ficam cheios de requisições lixo
    Dá para ver claramente bots procurando configurações frágeis que desenvolvedores talvez tenham deixado abertas, e eu já vi até pedirem o arquivo de ambiente do processo
    Não sei como esse tipo de vulnerabilidade não foi descoberto ou explorado, e a a16z ou teve muita sorte ou isso já foi explorado e não veio a público
    O que aconteceu foi que um pesquisador bem-intencionado, ou alguém entediado com mentalidade de white hat, entrou em contato primeiro; é uma pena que não exista uma estrutura legal para esse tipo de negligência, mas acho que a a16z deveria levar uma multa pesada

    • “Como esse tipo de vulnerabilidade não foi descoberto ou explorado?”
      Talvez já tenha sido
      Pode ter sido mais valioso deixar isso aberto do que simplesmente quebrar tudo
    • Sendo justo, o site principal em si não parece tão interessante assim
      Mas algumas credenciais do tipo OKTA parecem bem perigosas

  • A parte “não pagaram bug bounty porque o contato foi feito publicamente; isso aconteceu porque não havia contato no site principal e o engineering@a16z.com que ela encontrou devolveu a mensagem” parece um tipo esperto de life hack para economizar dinheiro da empresa
    Se você não deixar nenhum jeito de contatar a equipe de engenharia em privado, todo reporte de bug bounty vai acontecer em público, e aí você não precisa dar nada a ninguém

    • Esperto de várias formas
      Aposto que também economizaram bastante espremendo gente do fiverr ou coisa parecida para fazer o desenvolvimento, e se algum grupo russo de ransomware levar tudo com facilidade, ainda vão economizar bastante indiretamente em custos contábeis
    • Mas da próxima vez isso ensina o pesquisador de segurança a não reportar e vender a informação
    • A empresa não precisa fazer um “hack” separado para evitar pagar
      Se não existe programa público de bug bounty, ela não deve nada
      Além disso, há um endereço de e-mail de contato no rodapé de https://a16z.com/connect, que o pesquisador convenientemente deixou passar
      Parece mais uma busca por notoriedade do que divulgação responsável
    • Se isso se repetir, ela vai ficar conhecida como um lugar que não paga bounty, e as pessoas também terão menos chance de reportar problemas que encontrarem
    • Se alguém tivesse feito um post no HN perguntando como entrar em contato com a engenharia da a16z, provavelmente teria dado resultado

  • Quando empresas dizem que “foram hackeadas”, hoje isso já soa como uma expressão corporativa para “não protegemos adequadamente credenciais importantes, mas por favor joguem a culpa em alguma entidade sem rosto que chamamos de ‘hacker’”

    • Se você deixasse a porta da frente escancarada por engano e alguém entrasse e roubasse tudo, ainda assim diria que foi “roubado”
      Existem distinções legais como “invasão de domicílio”, “furto”, “entrada não autorizada”, e o fato de a porta estar aberta pode afetar a ilegalidade ou a punição, mas, na linguagem cotidiana, ainda assim você foi roubado

  • Não pagar nem mesmo uma bounty de valor simbólico por uma falha tão escancarada é bem ruim

    • Da próxima vez que alguém encontrar as chaves deles, pode ver este post e, em vez de reportar, simplesmente jogar tudo em um repositório público no GitHub

  • Eles estão ocupados demais escrevendo um white paper gigante sobre arquitetura de IA generativa
    Vamos dar um tempo, eles estão sonhando com um futuro de agentes em que chatbots semiacabados ficam se mexendo por aí
    Enquanto isso o mundo está pegando fogo por causa de atualizações de software quebradas

    • O mundo já está pegando fogo por causa dos efeitos da mudança climática
      A atualização de software quebrada de sexta-feira foi só a cereja do bolo
    • “o engineering@a16z.com devolveu a mensagem”
      Não é nem um pouco surpreendente

  • Se realmente fosse possível acessar a instância do Salesforce, isso seria muito preocupante do ponto de vista dos fundadores
    Normalmente e-mails ficam registrados em lugares como o Salesforce, e ali podem continuar guardados planos de captação de recursos ou de M&A que fundadores de empresas do portfólio não compartilharam externamente

    • Coletar chaves no código-fonte público de uma página web é legal e pode ser reportado com segurança
      Mas usar essas chaves para acessar sistemas sem autorização é crime
      Essa diferença é enorme
    • Se houver informações de LP incluídas, isso também pode causar um dano bem grande

  • O fato de essa empresa de VC não ter pago bug bounty por um buraco de segurança tão grande não inspira confiança

  • A moderação do HN mudou o título para algo menos constrangedor
    Nada surpreendente

    • Acho que meu comentário também era crítico demais em relação à a16z
      A pontuação não mudou, mas ele foi movido do topo para o fim
      Realmente existem várias formas de oferecer uma resposta, né