A experiência de hackear um app de namoro (e a forma errada de tratar pesquisadores de segurança)

• Foi descoberta uma vulnerabilidade de segurança grave no app de namoro Cerca
• O OTP era exposto na resposta, permitindo que qualquer pessoa com o número de telefone acessasse a conta
• Vários endpoints de API abertos sem autenticação facilitavam o vazamento de dados pessoais
• Uma grande quantidade de informações sensíveis, como preferência sexual, conteúdo de mensagens e documentos de identidade, ficou exposta
• Mesmo após um relato responsável do pesquisador, o serviço teve resposta inadequada e comunicação insuficiente

---

A importância de startups levarem segurança a sério

• Recentemente, startups têm apressado o lançamento no mercado e deixado a segurança de lado
• Embora seja um app de namoro que concentra dados pessoais, a falta de maturidade no desenvolvimento e na operação expôs usuários a riscos

Descoberta da vulnerabilidade e processo de notificação

• Em 23 de fevereiro de 2025, foi enviado um e-mail à equipe da Cerca explicando a vulnerabilidade de segurança e problemas relacionados
• Em 24 de fevereiro, uma videoconferência discutiu em detalhes a vulnerabilidade, formas de mitigação e os próximos passos
• A equipe da Cerca informou que entendia a gravidade, prometeu agir rapidamente e avisar os usuários
• Depois disso, foram enviados vários pedidos de atualização sobre o andamento, mas em 21 de abril ainda não havia resposta nem comunicado
• Verificações independentes indicaram que a vulnerabilidade já havia sido corrigida

Vulnerabilidade no OTP e processo simples de invasão

• No processo de login do app, a senha de uso único (OTP) era exposta diretamente na resposta de rede
• Um invasor podia acessar contas de forma fácil e rápida sabendo apenas o número de telefone

Acesso a endpoints de API e vazamento de informações

• Foi confirmado que bastava informar o header da versão do app para acessar todos os caminhos da API
• O endpoint /docs expunha toda a documentação OpenAPI
• Com ferramentas como Burp Suite, era possível controlar a API injetando automaticamente headers e tokens do app
• Alguns endpoints apenas alteravam a lógica de negócio, mas os principais retornavam dados pessoais de forma grave
• Com rotas como user/{user_id}, era possível obter dados pessoais, números de telefone e até sequestrar contas

Exposição em massa de dados pessoais e documentos de identidade

• Por meio de endpoints de dados pessoais, houve exposição em massa de PII, incluindo gênero, cidade, data de nascimento, e-mail escolar e dados de identidade
• Em especial, campos ligados à verificação de identidade, como national_id_verified, permitiam acesso a arquivos sensíveis, como imagens de passaporte e documento de identidade
• Um script de ataque identificou 6.117 usuários, dos quais 207 haviam enviado até mesmo dados de identidade
• Entre eles, havia também algumas contas que indicavam vínculo com a Universidade Yale
• Segundo o Instagram oficial da Cerca, isso corresponde a cerca de 10 mil usuários na primeira semana

Risco real de danos e gravidade do problema

• O vazamento de preferência sexual, conversas e documentos de identidade, informações extremamente sensíveis, representa risco grave de stalking, roubo de identidade e chantagem
• A Cerca afirmava seguir padrões do setor, incluindo criptografia, mas isso não condizia com a operação real do serviço
• Como usuários não podem verificar isso diretamente, é essencial que o fornecedor do app mantenha uma gestão de segurança ativa e responsável
• Na prática, também existe a possibilidade de que um número indeterminado de pessoas já tenha roubado dados pessoais em massa

Conclusão e necessidade de uma cultura de segurança responsável

• Operar um app com segurança tão frágil que qualquer pessoa consegue hackeá-lo facilmente é um grave problema social
• Se a proteção dos dados dos usuários não for tratada como prioridade máxima, danos podem ocorrer em tempo real
• O caso da Cerca, que teve resposta insuficiente ao relato do pesquisador e falhou em orientar os usuários, deve servir de alerta
• Para construir uma internet mais segura, estabelecer uma estrutura sólida de segurança deve ser prioridade máxima para toda empresa de software

[GN⁺]

Opiniões no Hacker News

• Mesmo considerando que este app parece ser um produto bem iniciante feito por universitários, acho que ainda assim eles deveriam ter feito o máximo possível em segurança e comunicação. Dito isso, vendo até empresas adultas financiadas por grandes VCs esbarrarem nesse tipo de problema e reagirem de forma parecida, também acho que não faz sentido ser duro demais com estudantes. Compartilho o link da matéria

  • Discordo fortemente. “Não sabíamos” não pode servir como desculpa. O fato de terem seguido em frente sem saber torna a situação ainda pior. É como um motorista inexperiente causar um acidente sem carteira e ferir alguém
  • Eu também cliquei no link da fonte tentando encontrar mais informações sobre a Cerca, e era uma matéria de abril de 2025 elogiando um app criado cerca de dois meses antes. Isso parece um lixo alucinado por LLM. Como o OP disse que entrou em contato com a equipe da Cerca em fevereiro, ou era uma vulnerabilidade descoberta logo no lançamento, ou há algo estranho nessa história. Ainda assim, existe o contexto de “vulnerabilidade de dois meses” + “serviço estudantil de dois meses”
  • Se o app é lançado sob o nome “Cerca Applications, LLC”, não vejo como as pessoas poderiam saber que deveriam ser mais compreensivas por se tratar de um app feito por estudantes
  • Acho que esses estudantes deveriam estar estudando outra coisa
  • Isso parece defesa demais. Não dá para tratar app feito por universitários como algo que deve ser automaticamente perdoado. The Facebook também começou com universitários. O longo histórico da Meta de abuso de privacidade e desprezo pela segurança de dados já é bem conhecido. Então, esse tipo de comportamento não pode ser desculpado, e só será resolvido com regulação adequada e multas, independentemente da idade ou experiência dos fundadores
  • Se você vai lidar com dados sensíveis como passaporte e orientação sexual, no mínimo precisa responder quando alguém avisa que seus dados estão vazando. Isso é um desastre completo, e o nível de ausência de segurança aqui é absolutamente inaceitável
  • Acho que, se você não entende nada de segurança de aplicativos, simplesmente não deveria criar um app. Vou soar emocional, mas ver amigos usando apps de namoro e pensar que as informações deles podem estar expostas é horrível demais. Quem fez isso deveria sentir vergonha. E também deveria sentir vergonha por não responder ao contato de um pesquisador de segurança. Se eu tivesse sido ignorado desse jeito, teria escrito uma denúncia bem mais direta. Por favor, parem de fazer apps

• Trabalhando como desenvolvedor em empresa pequena, às vezes fico preocupado com minha responsabilidade pessoal. Muitas empresas operam em áreas que não precisam seguir regulações como PCI ou HIPAA. Em organizações pequenas, segurança costuma ser tratada não como responsabilidade da empresa inteira, mas como tarefa da engenharia. O time de produto só pensa em funcionalidades, PM só pensa em prazo, QA só pensa em bugs, e raramente alguém levanta a voz sobre segurança. O clima é de que engenheiro só precisa fazer o que foi atribuído. Se o engenheiro consegue cuidar de segurança, ótimo; se não, ainda leva crítica de PM e afins. E sempre se ouve a mesma conversa: “quanto tempo vai levar?”, “qual a chance disso acontecer de verdade?”, “vamos lançar o MVP logo e depois melhoramos”. Então, como funcionário, acabo fazendo apenas o que a empresa manda. Mas quando a empresa for processada por invasão ou vazamento, fico me perguntando com frequência se a responsabilidade vai cair sobre mim por eu ser o engenheiro que “deveria saber mais”

  • Na prática, você não é o engenheiro que assina certificações e garante a segurança, então não vai ser responsabilizado mesmo se ficar provado que não era seguro
  • Se a empresa for uma LLC ou Corp, você estará protegido pelo corporate veil. A menos que haja registro de conduta criminosa da sua parte, você não terá responsabilidade. Dito isso, a falta de padrões de segurança é um grande problema em empresas de todos os tamanhos. Sempre se prioriza lançar funcionalidade nova acima de segurança
  • Como engenheiros em organizações pequenas, acho que é nossa responsabilidade educar o time sobre esses riscos e defender com firmeza tempo de desenvolvimento voltado para segurança. Não é fácil, mas ignorar isso pode colocar a própria empresa em risco
  • Eu procuraria conhecer a lei o suficiente para me proteger, contestaria por escrito qualquer pedido ilegal e também exigiria por escrito qualquer autorização para ignorar isso. Mas numa startup pequena isso pode ser difícil. Se eu sentisse que não era legal, simplesmente sairia da empresa
  • Eu também não gosto da defesa do tipo “só segui ordens”, mas nesses casos é essencial deixar tudo por escrito: mandar e-mail dizendo que há um problema de segurança e guardar a resposta do chefe dizendo algo como “não precisa se preocupar com isso”. Pelo que sei, nunca vi funcionário de nível comum ser pessoalmente responsabilizado por vazamento de dados. Em geral ninguém é responsabilizado, e a empresa paga uma multa simbólica e pronto
  • Se você não for executivo da empresa, não acho que terá responsabilidade pessoal
  • Pela minha experiência, isso não acontece

• Para reduzir a responsabilidade legal do pesquisador, acho que bastaria criar mais uma conta, ou acessar com o consentimento de um amigo por meio de um perfil, só para obter o nível de acesso necessário. Nem seria preciso realmente extrair os dados: por exemplo, se meu id é 12345 e o id do meu amigo é 12357, dá para provar que é possível acessar o perfil de outras contas usando os ids intermediários. Como muita gente já disse, não é necessário acessar os dados pessoais de milhares de pessoas; basta demonstrar e divulgar a vulnerabilidade

  • Esse é um procedimento padrão e bem claro que qualquer pesquisador de segurança da informação conhece. Pode ser tentador raspar informações sensíveis para provar o ponto, mas isso é desnecessário e, no fim, hipócrita

• Este texto em si parece bastante confuso. A ideia é que a API que recebe o OTP (senha de uso único) era tão simples que o OTP vinha exposto na própria resposta do servidor, então qualquer pessoa que soubesse o número de telefone poderia entrar na conta. Como a API parecia ser algo como otp/número_de_celular e o OTP vinha na resposta, parece que bastava acertar o número para receber o código também. E depois o autor diz que enumerou IDs de usuários com um script, parando quando encontrava 1.000 IDs vazios consecutivos, e assim confirmou 6.117 usuários no total, 207 registros de identidade e 19 estudantes de Yale. Mas acessar esse volume de dados pessoais de terceiros sem consentimento lembra o caso do weev, que hackeou a AT&T e foi preso. Mesmo em escala menor, esse tipo de pesquisa é legalmente arriscado, e me preocupa que o autor pareça não entender o quanto o ambiente jurídico deixa pesquisadores de segurança desprotegidos

  • Ele menciona especificamente que a API otp/número devolvia diretamente o OTP final. Ou seja, bastava acertar o número de telefone para receber o OTP na hora
  • Se você ler a acusação original no caso Auernheimer, havia ali evidência suficiente de intenção criminosa, ao contrário deste caso. Eles também foram acusados de de fato divulgar os dados pessoais ao público, então esta situação não chega a esse nível

• Passei por algo parecido: tentei reportar um bug em outro app de namoro, não consegui contato, então alterei o perfil do fundador para “entre em contato comigo”. Eles simplesmente restauraram por backup. Anos depois vi um anúncio desse app no Instagram e tentei de novo; a mesma vulnerabilidade continuava lá. Qualquer pessoa que soubesse os endpoints da API podia obter privilégios de admin e acesso a todas as mensagens e matches. Estou pensando se vale a pena tentar contato de novo

  • Sugere entrar em contato, se apresentar como desenvolvedor responsável e apenas divulgar a existência do problema antes de seguir em frente

• Acho que, ao coletar dados sensíveis como passaporte ou endereço em um app, isso deveria fazer qualquer um pensar duas vezes. Não é algo que possa ser tratado como banal sob a justificativa de “foi feito por estudantes”

  • O governo britânico está tentando obrigar o uso de identidade para acessar sites pornôs, e estou curioso para ver no que isso vai dar
  • Se o app coletou dados de identidade como passaporte, então depois da entrada desses dados eles nunca deveriam precisar ser expostos externamente. Se existe uma API para mostrar esses dados na interface, ela deveria devolver apenas os últimos dígitos, e não o número completo. Num app de namoro, bastaria retornar uma flag booleana ou um enum indicando se o ID foi verificado ou não (não verificado/passaporte/carteira de motorista). Sistemas como apps de companhia aérea, que exigem escolher um documento específico, são exceção; mas mesmo o app da United, por exemplo, mostra só os últimos dígitos, e eu gostaria que APIs internas também fossem limitadas assim
  • Compartilha um link dizendo para consultar o GDPR (lei europeia de proteção de dados)
  • Acho que deveríamos ter um serviço de verificação de identidade seguro e privado operado pelo governo. Ou então por empresas como Apple ou Google, que hoje quase fazem papel de governo
  • Em geral o normal é usar um serviço terceirizado de verificação de identidade, mas fico me perguntando se esses serviços realmente fazem o app receber até a imagem do documento

• Devolver o OTP diretamente na resposta da API é uma situação absurda demais. Não entendo o motivo

  • Fizeram isso para comparar imediatamente com a entrada no UI. Se você não pensar em segurança, até parece plausível. Como apps de namoro lidam com uma quantidade enorme de dados pessoais, esse tipo de erro é aterrorizante
  • Assim dá para reduzir custo de banco de dados de uma vez só
  • É fácil isso passar batido quando você gera o OTP, devolve imediatamente a resposta do DB ou do cache e usa esse modelo meio improvisado em um POC ou MVP
  • Parece que o OTP estava sendo exposto diretamente na “resposta à solicitação de envio da senha de uso único”. Isso talvez aconteça porque o framework serializou o objeto inteiro do banco e o devolveu por HTTP
  • Você economiza uma requisição HTTP e melhora a UX, então superficialmente parece bom. O Pinterest também já expôs, em uma API antiga, todas as informações incluindo o segredo de 2FA. Eu reportei e até recebi recompensa, mas esse tipo de erro acontece com frequência até em big techs
  • Também não entendo. Só consigo imaginar que foi um erro para simplificar a construção do formulário

• Compartilha um link para outra matéria relacionada no Yale Daily News

• Gostaria que existissem leis tratando dados pessoais como lixo nuclear, algo extremamente perigoso. Em caso de vazamento, a empresa deveria quebrar e os responsáveis também enfrentar risco legal. Hoje é fácil demais coletar dados de usuários e, quando vaza, basta pedir desculpas e seguir em frente

  • Tratar PII como material nuclear parece exagerado. Algo como endereço de e-mail, usado só para autenticação ou contato, não é grande problema
  • Talvez só prisão de colarinho branco faça as pessoas levarem isso a sério

• Só agora descobri a ferramenta Charle's Proxy no iOS. Antigamente eu fazia pentest procurando strings diretamente no binário do app. Parece que isso vai ajudar muito na análise de apps exclusivos para iOS

  • É uma ferramenta boa, recomendo (desde que não haja SSL pinning)