Encontrei uma vulnerabilidade. Eles encontraram um advogado

• O autor, instrutor de mergulho e engenheiro de plataforma, encontrou uma vulnerabilidade de segurança grave no portal de membros de uma seguradora de mergulho
• Como o portal usava IDs de usuário sequenciais e a mesma senha padrão, qualquer pessoa podia acessar os dados pessoais de outros membros com uma combinação simples
• Ele reportou o problema simultaneamente ao CSIRT Malta e à organização, mas, em vez de agradecer, a organização alertou sobre possível responsabilidade criminal por meio de representantes legais
• O autor recusou a exigência de assinar um acordo de confidencialidade (NDA) e propôs uma declaração revisada que apenas confirmava a exclusão dos dados, mas a organização voltou a ameaçar com possível difamação
• O caso expõe a importância do processo de divulgação responsável de vulnerabilidades e a realidade de que ameaças legais enfraquecem a proteção de pesquisadores

---

Descoberta da vulnerabilidade

• Durante uma viagem de mergulho à Ilha do Coco, na Costa Rica, ele encontrou uma falha estrutural no portal de membros de uma seguradora de mergulho
  • Quando o instrutor registrava um aluno, o sistema gerava um ID numérico sequencial e uma senha padrão que nunca era alterada
  • Como muitos usuários não trocavam a senha, era possível acessar todos os dados pessoais de outros membros (nome, endereço, data de nascimento, contato etc.)
• Não havia nenhuma medida básica de segurança, como troca obrigatória de senha, limitação de login ou MFA
• Algumas contas também continham informações de menores de idade (14 anos)
• O autor confirmou o problema com acesso mínimo, interrompeu imediatamente e apagou permanentemente todos os dados coletados

Verificação e prova

• Ele tentou com Python requests, mas, como a estrutura de sessão era complexa, fez a validação com automação de navegador usando Selenium
  • Bastava inserir o ID do usuário e a senha padrão para fazer login
  • O script de automação foi divulgado como código de exemplo não funcional, com todos os identificadores reais removidos
• O exemplo de saída incluía dados completos de perfil, como nome, e-mail, endereço e data de nascimento
• Nesse processo, foi confirmado que várias contas de menores de idade estavam expostas da mesma forma

Processo de divulgação da vulnerabilidade

• Em 28 de abril de 2025, ele reportou oficialmente a vulnerabilidade e definiu um prazo de 30 dias para correção
• O aviso foi enviado por e-mail simultaneamente ao CSIRT Malta e à organização
  • O relatório incluía resumo do problema, possível violação do GDPR, capturas de tela e um link PoC criptografado
  • Ele pediu confirmação de recebimento em até 7 dias e correção em até 30 dias
• Esse era um procedimento padrão compatível com a política nacional de divulgação de vulnerabilidades (NCVDP)

Resposta da organização

• Dois dias depois, a resposta veio não da equipe de TI, mas de advogados responsáveis por proteção de dados (escritório jurídico do DPO)
  • Eles mencionaram redefinição de senhas e adoção de 2FA, mas questionaram o fato de ele ter informado primeiro uma entidade governamental
  • Também alertaram que a conduta do autor poderia ser considerada crime segundo o código penal maltês, com possível responsabilização legal
• A organização exigiu a assinatura de uma declaração de confidencialidade, pedindo cópia do passaporte e prazo para assinatura no mesmo dia
  • O texto incluía uma cláusula determinando que “o conteúdo desta declaração seja mantido em sigilo”, funcionando na prática como um NDA (acordo de confidencialidade)
• Depois disso, seguiram novos pedidos repetidos de assinatura, como “lembrete amigável” e “alerta urgente”

Recusa e contestação do pesquisador

• O autor recusou assinar a cláusula de confidencialidade e, em vez disso, propôs uma declaração revisada que apenas confirmava a exclusão dos dados
  • Ele esclareceu que notificar o CSIRT Malta fazia parte do procedimento oficial e que publicar análises após a divulgação é prática padrão do setor de segurança
• A organização citou o artigo 337E do código penal (abuso de computador) e advertiu que atos praticados no exterior também poderiam ser tratados como crime em Malta
• Também informou que, caso o nome da organização fosse citado em blog ou conferência, poderia haver ação por difamação e pedido de indenização por danos
• Atualmente, a vulnerabilidade foi corrigida, e a redefinição da senha padrão e a introdução de 2FA estão em andamento
• No entanto, não foi confirmado se as vítimas foram notificadas nos termos dos artigos 33 e 34 do GDPR

Transferência de responsabilidade e violação do GDPR

• A organização alegou que “trocar a senha é responsabilidade do usuário”
• Porém, de acordo com o artigo 5(1)(f) e o artigo 24(1) do GDPR, o controlador de dados deve adotar medidas técnicas e organizacionais adequadas
• O uso da mesma senha padrão junto com IDs sequenciais constitui claramente uma medida de segurança inadequada

Um padrão recorrente

• Ainda existe o “efeito inibidor” (chilling effect) em que pesquisadores de segurança, ao divulgarem vulnerabilidades de forma responsável, acabam enfrentando ameaças legais
• A resposta jurídica piora ainda mais a reputação, e o problema não é a vulnerabilidade em si, mas a forma como a organização reage

Procedimento de resposta correto

• Receber o relatório e corrigir o problema
• Agradecer ao pesquisador
• Estabelecer uma política de CVD (Coordinated Vulnerability Disclosure)
• Notificar os usuários afetados, especialmente no caso de menores de idade
• Não impor silêncio por meio de NDA

Conselhos para organizações e pesquisadores

• Organizações devem preparar um processo claro de divulgação, como security.txt, e agradecer aos pesquisadores
• Pesquisadores devem envolver o CSIRT nacional, preservar todos os registros e recusar confidencialidade após apagar os dados
• A diretiva NIS2 incentiva a divulgação responsável de vulnerabilidades na União Europeia
• Mesmo em 2026, a realidade em que um simples reporte de vulnerabilidade leva a ameaças legais continua existindo

[GN⁺]

Comentários do Hacker News

• Há casos de outras pessoas que encontraram IDs de usuário monotonicamente crescentes e foram testar, acabando na cadeia
  No momento em que você testa dessa forma, passa a existir risco de violação do CFAA
  Se você já sabia que os IDs eram monotonicamente crescentes e que havia uma senha padrão definida, deveria ter reportado a vulnerabilidade imediatamente naquele ponto
  No instante em que executou o teste, isso pode já ter configurado violação da lei
  Escrever isso agora é praticamente uma confissão, então você precisa contratar um advogado e estudar a legislação relevante

• Não tenho especialização jurídica, mas tenho três pensamentos

  1. Se o processo de divulgação legal for difícil demais, no fim só ficaremos sabendo das vulnerabilidades por meio de criminosos
  2. Em outros setores, seria absurdo que um arquiteto descobrisse um defeito em um prédio e fosse processado por isso. A diferença é que, em cibersegurança, saber da falha em si já pode aumentar o risco
  3. É instável demais depender de uma pessoa aleatória que passava por ali para fazer auditoria. Se um site exige meu PII (informações de identificação pessoal), eu deveria ter o direito de exigir a segurança desses dados
     Lugares como seguradoras deveriam ser obrigados por lei a passar por auditorias de cibersegurança, white hat hackers deveriam ser protegidos, e usuários deveriam poder entrar com ações coletivas
     Se isso acontecesse, vulnerabilidades básicas desapareceriam, e engenheiros de software se tornariam economicamente mais valiosos do que advogados
  • Em outros setores existem engenheiros profissionais com responsabilidade legal
    Fico curioso se a área de CS vai caminhar nessa direção na era da IA
    Engenheiros profissionais aprovam projetos e fazem inspeções, cumprindo um papel central na garantia da segurança
    Por isso, têm grande autoridade e responsabilidade, e também remuneração alta
  • Em outros setores, quem projeta tem seguro e licença
    Não quero impedir a atividade open source de desenvolvedores iniciantes, mas acho que sites que lidam com grandes volumes de dados pessoais ou dinheiro deveriam exigir assinatura de um engenheiro de software certificado
    Só assim haveria força para conter exigências abusivas da diretoria
    Claro, vendo casos como Boeing ou Volkswagen, isso não é uma solução perfeita
  • Em alguns países, difamação pode existir mesmo sendo verdade
    Ou seja, reportar às autoridades e divulgar à imprensa são questões completamente diferentes
    Especialmente em lugares como Malta, onde crime organizado e corrupção são graves, quem torna isso público pode acabar sofrendo um “acidente”

• Eu uso um endereço de e-mail diferente para cada serviço
  Há cerca de 15 anos, comecei a receber spam no endereço diversalertnetwork
  Avisei a DAN sobre o incidente e só recebi um e-mail mandando trocar a senha
  Acho que tive sorte de não ter sido alvo de denúncia criminal

  • Isso pode ter sido invasão, ou a empresa pode ter vendido os dados a terceiros
  • Tive experiência parecida. Comecei a receber spam em um e-mail exclusivo para uma companhia aérea portuguesa, e a empresa não respondeu nada

• O fato de o autor ter medo de revelar o nome da organização significa que a ameaça jurídica funcionou

  • Ou, na comunidade de mergulho, talvez só a expressão “seguradora de mergulho sediada em Malta” já aponte para a DAN Europe
  • Pelas pistas do texto, entre as seguradoras internacionais de mergulho registradas em Malta, praticamente só existe a DAN Europe, então é quase certo
  • Claro, também não dá para descartar a possibilidade de ele ter vendido as informações para black hats

• Sobre a exigência de “assinar um certificado de exclusão de dados”, fica a dúvida de por que ele assinou
  A empresa parece ter querido mais controle do que cooperação

  • Mas, se você fizer a outra parte concordar com as suas condições, acaba neutralizando a estratégia de controle dela e cria força vinculante legal

• O padrão de pesquisadores de segurança reportarem vulnerabilidades e receberem ameaças legais em troca se repete há décadas
  Governos e empresas falam da importância da cibersegurança, mas na prática são hostis aos pesquisadores
  É preciso legislação para impedir esse tipo de resposta abusiva
  Casos relacionados podem ser vistos neste link

• Fico me perguntando se o alvo deste caso é a DAN Europe e sua subsidiária IDA Insurance Limited

  • Outros comentários já chegaram a essa conclusão

• Na Alemanha, executar um script assim para acessar dados de outras pessoas é ilegal
  É como ver a porta do carro de outra pessoa aberta e achar que pode entrar e dar partida
  Para uma explicação jurídica relacionada, veja este texto

  • Então a lei precisa mudar. Um nível assim de negligência com segurança nunca vai melhorar sem denunciantes de boa-fé ou um grande vazamento
  • Também concordo. É preciso saber onde parar
    Tirar capturas de tela e reportar dentro do uso normal do site é aceitável, mas coletar dados com um script em Python já passa do limite
    É como ver a porta de um banco aberta e, em vez de chamar a polícia, entrar lá dentro
  • Esperemos que criminosos não explorem essa brecha

• No ano passado, encontrei uma vulnerabilidade no sistema de ingressos de um grande evento
  O link do ingresso recebido por e-mail era apenas o número sequencial do pedido codificado em base64
  Ou seja, dava para baixar facilmente o ingresso de outras pessoas
  Enviei e-mails aos organizadores e à empresa desenvolvedora, mas não houve reação, e continua exposto até hoje
  Vou observar neste ano se foi corrigido durante o evento

• Se os IDs de usuário eram sequenciais e a senha padrão era a mesma, a verdadeira vulnerabilidade era a “suposição de que existe alguém responsável por segurança”
  Hoje em dia, “divulgação responsável” no fim das contas serve apenas para dar tempo para a empresa contratar advogados