- Um garoto de 15 anos que gosta de caçar bugs no tempo livre encontrou uma falha relacionada à autenticação por e-mail no Zendesk, usado por empresas da Fortune 500
- Ele relatou isso a várias empresas e ganhou mais de US$ 50.000, mas o texto apresenta como o Zendesk corrigiu o problema e ainda assim não deu nenhuma recompensa ao pesquisador
Introdução ao Zendesk
- O Zendesk é uma ferramenta de atendimento ao cliente usada por algumas das maiores empresas do mundo
- Ao conectar e-mails de suporte ao Zendesk, a plataforma gerencia os e-mails recebidos e cria tickets
- É surpreendente que muitas grandes empresas dependam do Zendesk em vez de construir seu próprio sistema de tickets
O elo mais fraco
- Como diz a expressão "uma corrente é tão forte quanto seu elo mais fraco", o Zendesk muitas vezes é tratado apenas como uma ferramenta simples de tickets e usado sem configuração cuidadosa
- Usar o domínio "@company.com" em Single Sign-On (SSO) e conectá-lo ao Zendesk pode criar vulnerabilidades de segurança
- Como o Zendesk processa os e-mails do domínio, se o sistema de SSO não validar corretamente os endereços de e-mail, alguém com acesso ao Zendesk pode abusar de sistemas internos.
Spoofing de e-mail
- Foi descoberta uma vulnerabilidade grave no Zendesk, pela qual um atacante podia ler tickets de suporte ao cliente de empresas que usam a plataforma
- O Zendesk não tinha proteções eficazes contra spoofing de e-mail
- Se o atacante soubesse o endereço de e-mail de suporte e o ID do ticket, podia acessar o ticket se passando pelo remetente original por meio de spoofing de e-mail
- O autor reportou o bug, mas o Zendesk inicialmente não demonstrou interesse
- A resposta foi que spoofing de e-mail (questões de SPF, DKIM, DMARC) estava fora do escopo
- O reporte foi tratado pelo serviço do HackerOne, e quando o autor pediu para reportar diretamente a um membro da equipe do Zendesk, o pedido foi recusado
Escalando esse problema para tomar controle do Slack
- O bug de spoofing de e-mail poderia ter sido reportado a empresas individualmente, mas a intenção era causar um impacto maior
- No passado, outro pesquisador já havia comprometido o Slack de centenas de empresas por meio do Zendesk (TICKETTRICK)
- O autor tentou reproduzir isso usando seu próprio bug, mas encontrou algumas dificuldades
- O Slack havia mudado para um método de verificação que adicionava um token aleatório ao endereço de e-mail
- No entanto, ao fazer login com Apple ID via OAuth, o token não era usado, o que permitia contornar a proteção
Etapas de reprodução: Apple → Zendesk → Slack
- Criar um Apple ID com "support@company.com" e solicitar um código de verificação, o que gera um ticket no Zendesk
- Criar um ticket com seu próprio e-mail no portal de suporte de
company.com para rastrear a faixa de IDs
- Usar o bug de spoofing de e-mail para tentar se adicionar a todos os tickets naquela faixa de IDs
- Fazer login no portal de suporte da empresa com a conta
daniel@wearehackerone.com e verificar os tickets em CC
- Inserir o código de verificação no Apple ID
- Usar o recurso "Entrar com a Apple" do Slack para fazer login com o Apple ID vinculado a um e-mail @company.com e entrar no Slack
O autor aplicou essas 6 etapas a centenas de instâncias de Zendesk e Slack
As consequências do caso
- Durante uma semana, ele reportou a vulnerabilidade a empresas individuais; algumas agiram imediatamente, enquanto outras disseram que o problema era do Zendesk
- Quando algumas empresas entraram em contato com o Zendesk, o Zendesk finalmente pediu que o reporte fosse mantido em sigilo e solicitou etapas de reprodução da vulnerabilidade no Slack
- Depois de receber um PoC de tomada de controle do Slack, o Zendesk confirmou o problema, mas levou 2 meses para resolvê-lo
- Muitas empresas protegeram suas instâncias desativando o recurso de colaboração por e-mail
- O autor recebeu mais de US$ 50.000 em recompensas por meio desse reporte de bug bounty, pagos por empresas individuais em plataformas como HackerOne e outras
- Algumas empresas encerraram seus contratos com o Zendesk
A correção do Zendesk e meu bounty de US$ 0
- Dois meses depois, o Zendesk confirmou que havia resolvido o problema
- A empresa usava os filtros antispam Cloudmark e Rspamd EAP, mas como não aproveitava a pontuação do Rspamd, muitos e-mails não ficavam retidos
- Inicialmente, a correção foi feita com uma mudança para alternar automaticamente para o Rspamd em certas condições
- Depois, foi implementado um filtro para reter automaticamente e-mails de autenticação da Apple e do Google
- Apesar de ter resolvido o problema, o Zendesk decidiu no fim não pagar recompensa por esse reporte de bug bounty
- O autor teria violado as diretrizes de divulgação do HackerOne ao compartilhar a vulnerabilidade com as empresas afetadas
Conclusão
- Um pequeno bug de e-mail acabou levando à invasão de sistemas internos de algumas das maiores empresas do mundo
- O Zendesk acabou corrigindo a vulnerabilidade, mas o processo foi difícil, com recusas, lentidão na resposta e descaso
- Essa é a realidade da caça a bugs: às vezes se ganha, às vezes se perde
Opinião do GN⁺
- O caso do Zendesk mostra o risco de adotar soluções de terceiros sem uma análise crítica. Mesmo produtos de empresas muito conhecidas exigem revisão de segurança.
- O comprometimento de sistemas internos de grandes empresas pode causar danos enormes, e a demora do Zendesk em responder foi extremamente irresponsável. Também não é desejável desmotivar pesquisadores de segurança ao recusar o pagamento da recompensa.
- As empresas devem escolher com cuidado os domínios de SSO e reforçar os processos de verificação de e-mail. É necessário usar ativamente tecnologias de autenticação de e-mail como DMARC, SPF e DKIM.
- As diretrizes de divulgação do HackerOne são rígidas demais do ponto de vista do pesquisador. Vulnerabilidades graves precisam ser compartilhadas rapidamente, então parece necessário aplicá-las com mais flexibilidade conforme a situação.
- A caça a bugs deve ser benéfica para empresas e pesquisadores. Espera-se que se consolide uma cultura de respeito à boa-fé e ao esforço dos pesquisadores, com recompensas adequadas.
2 comentários
Quando vejo questões assim, parece muito melhor trazer e formar especialistas em segurança do que simplesmente adotar soluções de segurança de terceiros ;_;
Comentários no Hacker News
Um usuário menciona que, em junho de 2024, reportou o mesmo bug para Zendesk, Apple e Slack, e que provavelmente eles não pagaram recompensa porque ele não foi o primeiro
Outro usuário afirma que a Zendesk criou uma banda falsa chamada "Zendesk Alternative" para poluir os resultados de busca do Google
Um usuário diz que é decepcionante que a Zendesk tenha se recusado a pagar pela falha, e comenta que é assim que se faz as pessoas não quererem participar de grandes programas de recompensa
Outro usuário menciona que programas ineficientes de bug bounty têm impacto negativo sobre serviços de software
Um usuário critica a falta de pagamento da Zendesk apesar de ser uma empresa com receita de 1,3 bilhão de dólares, dizendo que isso é uma visão de curto prazo
Outro usuário explica que a Zendesk provavelmente ignorou o problema porque não entendeu corretamente o impacto da falha
Um usuário aponta que a Zendesk corrigiu apenas o problema do e-mail de verificação da conta Apple, mas não resolveu a questão fundamental
É explicado que existem duas vulnerabilidades separadas
Há críticas ao fato de a Zendesk ter ignorado o problema e tentado mantê-lo em sigilo
Por fim, um usuário critica a recusa da Zendesk em pagar pela falha e enfatiza que quem reportou seguiu todos os procedimentos corretamente