A experiência de hackear um app de namoro e a forma errada de lidar com pesquisadores de segurança
(alexschapiro.com)- O Cerca Dating App combinava login baseado em número de telefone com APIs expostas, ficando em uma situação arriscada em que a resposta do OTP incluía o código de autenticação e isso podia levar até à consulta de dados pessoais
- Em
api.cercadating.com, ao incluir o cabeçalho de versão do app, os endpoints ficavam expostos pelo openapi.json em/docs, e algumas requisições permitiam manipular até lógica de negócio, como forçar matches user/{user_id}retornava PII como nome, localização, data de nascimento, escola, telefone, e-mail e status do perfil apenas com um ID de usuário válido, o que, combinado à vulnerabilidade de OTP, poderia levar ao sequestro de contas- Após acessar uma conta, era possível acessar, no caso de usuários que haviam enviado esses dados, informações de passaporte ou documento de identidade, URL de selfie e até mensagens privadas; com um script de verificação, foram encontrados 6.117 usuários, 207 usuários que informaram dados de documento e 19 usuários marcados como estudantes de Yale
- As vulnerabilidades foram reportadas à Cerca em 23 de fevereiro de 2025, e houve até uma chamada em 24 de fevereiro, mas até a publicação, em 21 de abril, não houve resposta posterior nem notificação aos usuários; apenas a correção foi confirmada de forma independente
Resposta interrompida após o reporte
- O Cerca Dating App tinha uma vulnerabilidade de segurança em app de namoro que podia expor mensagens privadas, informações de passaporte, preferências sexuais e outros dados pessoais
- Após descobrir as vulnerabilidades, elas foram reportadas por e-mail à equipe da Cerca em 23 de fevereiro de 2025; no dia seguinte, em uma chamada de vídeo, foram discutidas as vulnerabilidades, medidas de mitigação e próximos passos
- A equipe da Cerca reconheceu a gravidade do problema, agradeceu pela divulgação responsável e prometeu corrigir as vulnerabilidades e notificar os usuários afetados
- Depois disso, em 5 e 13 de março, foram solicitadas atualizações sobre a correção e o plano de notificação aos usuários, mas até a publicação em 21 de abril de 2025 não houve resposta
- Antes da publicação, foi confirmado de forma independente que as vulnerabilidades haviam sido corrigidas, e a divulgação foi feita com base nisso
Acesso à conta começando pelo login via OTP
- O app usava apenas login baseado em OTP, enviando um código para o número de telefone
- Para inspecionar as requisições de rede, foi usado Charles Proxy no app para iPhone para interceptar as requisições do aplicativo
- A resposta que disparava o OTP continha a senha de uso único diretamente
- Com essa estrutura, bastava saber o número de telefone de um usuário para acessar a conta dele
- Era necessário encontrar uma forma separada de descobrir o número de telefone de titulares de contas, o que levou à exploração dos endpoints da API
Endpoints expostos pela documentação OpenAPI
- Um fuzzer de diretórios foi usado contra
api.cercadating.compara enumerar caminhos - Sem cabeçalhos relacionados ao app, não era possível acessar nenhuma parte do site
- Ao enviar requisições com esse cabeçalho no Gobuster, o endpoint
/docsfoi encontrado, e nele era servido oopenapi.json - A função match-and-replace do Burp Suite foi configurada para sempre adicionar o cabeçalho de versão do app e o bearer token extraído pelo Charles Proxy
- Alguns endpoints desprotegidos afetavam a lógica de negócio, e também era possível fazer uma requisição para forçar o match entre duas pessoas
Exposição de perfis de usuários e dados pessoais
- O endpoint
user/{user_id}retornava vários dados pessoais ao receber um ID de usuário válido - A resposta incluía as seguintes informações
- Nome, gênero, gênero de interesse, cidade, latitude e longitude
- E-mail escolar e status de verificação, setor, profissão, data de nascimento, altura
- ID da escola e nome da escola, status de conclusão do perfil
- Status de verificação de documento nacional de identidade, status de verificação de celular e e-mail
- Status premium, status de conta ativa, suspensa e de onboarding
- Número de telefone, e-mail, ID de usuário, número restante de buscas
- Imagens de perfil, preferências de match, prompts do usuário, informações de contatos em comum, horários de criação e modificação, idade etc.
- Com um script em Python, era possível encontrar IDs de usuário válidos e enumerar dados de usuários em massa
- Os números de telefone retornados podiam ser combinados à vulnerabilidade de OTP para obter acesso completo à conta
- Mesmo sem login via OTP, os dados pessoais dos usuários estavam expostos
Acesso chegando até documentos de identidade e mensagens privadas
- O campo
national_id_verifiedmostrava que informações de passaporte ou documento de identidade eram armazenadas no sistema - As respostas relacionadas a documentos incluíam as seguintes informações
verification_type:PASSPORTdocument_numberfront_side_urlback_side_urlselfie_url- status, ID, ID do usuário
- Essas informações eram fornecidas apenas a usuários logados, mas, por causa da vulnerabilidade de OTP, era possível fazer login como um usuário arbitrário
- A estrutura permitia ver os dados de documento de qualquer pessoa que os tivesse enviado, embora o autor afirme que não fez isso na prática
- Também era possível ver mensagens pessoais com possíveis parceiros de encontro e, quando enviadas, acessar até informações de passaporte
Escala de exposição confirmada
- Um script rápido contabilizou o número de usuários cujas informações podiam ser obtidas, o número de usuários registrados como estudantes de Yale e o número de usuários que haviam inserido informações de documento
- O script contava IDs de usuário válidos e parava quando não encontrava nenhum ID válido por 1.000 tentativas consecutivas
- Esse método não exclui a possibilidade de haver mais usuários
- A Cerca afirmou ter 10 mil usuários na primeira semana
- Os números confirmados foram os seguintes
- 6.117 usuários
- 207 usuários que inseriram informações de documento
- 19 usuários marcados como estudantes de Yale
Promessas de privacidade e risco real
- A política de privacidade da Cerca afirma que “protege os dados com criptografia e outras medidas padrão do setor”
- Comparada ao estado real das vulnerabilidades, essa formulação é potencialmente enganosa
- A exposição podia incluir preferências sexuais, mensagens privadas e diversos dados pessoais
- Se um usuário mal-intencionado acessasse essas informações, isso poderia levar a roubo de identidade, stalking, chantagem e outros desdobramentos
- Como apps de namoro lidam com dados sensíveis, a segurança dos dados dos usuários deve vir antes da velocidade de lançamento do app
1 comentários
Comentários do Hacker News
Este app parece ser um projeto bem inicial feito por estudantes universitários. É claro que eles deveriam fazer o máximo para seguir boas práticas de segurança e comunicação, mas, pensando em como “empresas adultas” com grandes aportes de VCs também respondem de forma desastrosa a problemas parecidos, não quero pegar pesado demais
https://georgetownvoice.com/2025/04/06/georgetown-students-c...
É parecido com um motorista que mata alguém em um acidente e depois se descobre que ele nem tinha carteira
O post original diz que entrou em contato com a equipe da Cerca em fevereiro, então ou foi uma falha descoberta no dia do lançamento, ou há alguma estrutura estranha. De qualquer forma, é uma “vulnerabilidade de dois meses” e também um “app/serviço de dois meses feito por estudantes”
Além disso, não é algo feito por diversão, é um produto comercial. As compras dentro do app aparecem como Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99
Como engenheiro em uma empresa pequena, às vezes me preocupo com minha responsabilidade pessoal. Há muitas empresas operando em setores não regulados, onde PCI ou HIPAA não se aplicam, e em organizações pequenas a segurança acaba sendo empurrada para o lado como apenas uma preocupação de engenharia, não uma obrigação organizacional
O time de produto foca em funcionalidades, o PM em cronograma, o QA em encontrar bugs, e raramente alguém fala de segurança de forma razoável. Não se espera que o engenheiro faça muito além de concluir as tarefas no quadro. Se der para fazer de forma segura sem impactar o prazo, ótimo; se não, vem pressão do PM e de outros
A gente ouve coisas como “quanto tempo isso vai levar?”, “qual é o risco real de isso acontecer?”, “vamos lidar com segurança depois e primeiro colocar o MVP nas mãos dos clientes”. Como funcionário, estou fazendo o que meu empregador manda, mas se a empresa for processada por um hack ou vazamento de dados, fico me perguntando se eu acabaria sendo responsabilizado pessoalmente por ser a única pessoa que “deveria saber”
Dito isso, a falta de padrões de segurança em organizações de qualquer tamanho é lamentável. Parece que lançar novas funcionalidades sempre vem antes de garantir boas práticas de segurança
Mas entendo que, em uma startup com apenas um ou dois desenvolvedores, até isso pode ser difícil. Se eu sentisse que a empresa não busca fazer as coisas de forma legal, acho que eu iria embora
Não é fácil, mas é algo importante que pode afundar o próprio negócio se não for tratado com seriedade
É preciso ter registros de e-mails nos quais você levantou preocupações sobre a falta de segurança e também a resposta do chefe dizendo para não se preocupar. Não sei em que jurisdição você está, mas não conheço casos em que um funcionário comum tenha sido responsabilizado legalmente, como pessoa física, por um vazamento de dados. Normalmente ninguém sofre consequências reais por vazamentos de dados, e a empresa paga apenas uma multa simbólica e segue em frente
Como pesquisador, para reduzir a exposição legal, provavelmente bastaria criar uma segunda conta ou pedir a um amigo que criasse um perfil e desse consentimento de acesso
Não é necessário realmente raspar dados para provar uma vulnerabilidade de enumeração. Se meu ID é 12345 e um amigo se cadastra e recebe 12357, isso já é evidência suficiente de que é possível encontrar o ID de qualquer usuário e acessar o perfil
Como outros disseram, não é preciso acessar tantos dados de identificação pessoal de outros usuários para verificar e divulgar a vulnerabilidade
Querer que dados de identificação pessoal sejam protegidos, mas raspá-los para provar o ponto, é desnecessário e hipócrita
O texto é bem confuso. A parte que diz que, no login baseado em OTP, a resposta à solicitação da senha de uso único traz o OTP em claro é pouco explicada, mas provavelmente quer dizer que era uma API tipo api.cercadating.com/otp/, então, se você adivinhasse o número de telefone, poderia receber o código OTP mesmo sem ser dono daquele número.
Ele também diz que, com um script que parava quando não encontrava usuários válidos em 1.000 IDs consecutivos, encontrou 6.117 pessoas, 207 com informações de documento de identidade e 19 que afirmavam ser estudantes de Yale; não sei se o autor entende o quanto isso é perigoso. Na prática, é parecido com a forma como weev invadiu a AT&T, e ele foi preso[0].
Era uma empresa maior e um vazamento maior, mas eu não sairia me gabando publicamente de ter usado uma falha de segurança para acessar sem autorização os dados de milhares de pessoas. Não estou tentando julgar a moralidade; acho que pesquisadores de segurança precisam ter espaço para alertar, mas a lei é bastante desfavorável a eles.
[0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...
Os réus naquele caso também foram acusados de divulgar informações de identificação pessoal subjacentes, o que não parece ter acontecido aqui.
Passei por algo parecido em outro app de namoro, e eles nunca responderam. Para chamar a atenção do fundador, alterei a bio dele para uma frase dizendo “entre em contato comigo”, e aí eles restauraram um backup.
Alguns anos depois, vi um anúncio no Instagram e verifiquei se o problema ainda existia; ainda existia. Bastava conhecer um endpoint de API fácil de encontrar com app-proxy-servidor para qualquer pessoa ter privilégios totais de administrador e acessar todas as mensagens, matches etc.
Fico pensando se devo voltar lá e tentar mais uma vez.
Antes de coletar informações sensíveis como passaportes ou endereços, deveria ser obrigatório fazer as pessoas pensarem duas vezes. Não dá para simplesmente tratar isso como crianças criando um app e deixar passar.
Em um site de namoro, bastaria a API retornar, sobre o status do documento, um booleano verified/not-verified ou valores enumerados como ‘not-verified’, ‘passport’, ‘drivers-license’. Não há necessidade real de mostrar detalhes no cliente/UI.
Casos como apps de companhias aéreas, em que é preciso escolher um documento de identidade para fins de imigração, são exceções em que talvez faça sentido mostrar mais informações, mas basta fazer como o app da United e mostrar só os últimos dígitos do número do passaporte. Eu gostaria que até as APIs internas enviassem só isso.
Ou talvez algo “parecido com governo”, como Apple ou Google, pudesse assumir isso.
https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
Não faz sentido a resposta da API de solicitação retornar o OTP. Por que fariam isso?
Se você não pensa em segurança, é uma solução muito plausível e óbvia. Apps de namoro são, por natureza, um dos tipos de app mais perigosos de construir, porque têm muitas informações de identificação pessoal, e isso é horrível.
Em provas de conceito rápidas ou MVPs, é comum reutilizar o modelo de armazenamento como resposta da API para economizar tempo, então é fácil deixar isso passar.
Quando a nova API do Pinterest saiu, ela estava distribuindo todas as informações do usuário para todos os apps que usavam integração OAuth, incluindo até o segredo da autenticação em duas etapas. Reportei e recebi uma recompensa, mas esse tipo de coisa também acontece em APIs de grandes empresas que deveriam saber melhor.
Pode ter sido culpa do framework. Provavelmente era uma estrutura em que o objeto inserido no banco de dados era serializado diretamente por um ORM ou outro sistema de armazenamento e devolvido como resposta HTTP.
https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
Outra matéria sobre este caso.
Gostaria que houvesse uma lei que tornasse armazenar informações de identificação pessoal tão perigoso quanto armazenar lixo nuclear. Se houver vazamento, a empresa quase certamente deveria falir, e os responsáveis deveriam enfrentar riscos legais.
Acho que essa é a melhor forma de alinhar os incentivos corretamente. Hoje há pouquíssima desvantagem em armazenar o máximo possível de dados dos usuários. Vazamento de dados? Publica um tweet pedindo desculpas e segue em frente.
Assim esse problema talvez receba a atenção que merece.
Se “não recebeu nenhuma resposta”, é hora de avisar que, se o silêncio continuar, a vulnerabilidade será divulgada em 90 dias