Desenvolvedor alemão que expôs credenciais hardcoded em app é condenado por “hacking”

• Na Alemanha, um desenvolvedor encontrou dados de acesso ao banco de dados de um fornecedor enquanto investigava logs de software no trabalho e informou o problema, mas o tribunal considerou o caso como hacking
• O software em questão fazia uma conexão MySQL com o servidor de banco de dados do fornecedor, que continha não apenas os dados do cliente do desenvolvedor, mas também os dados de todos os clientes do fornecedor
• As credenciais estavam hardcoded em texto puro dentro da aplicação e estavam tão expostas que nem era necessário fazer decompilação
• O tribunal entendeu que a simples existência de uma senha significava que havia um mecanismo de proteção, e decidiu que contorná-lo configurava hacking
• Uma decisão como essa pode inibir pesquisas de segurança legítimas e tornar os usuários mais vulneráveis, ao permitir que empresas com segurança precária evitem responsabilidade

---

Da descoberta à denúncia criminal

• O caso levanta preocupações de que a lei alemã possa tornar a pesquisa de segurança uma atividade arriscada
• Um desenvolvedor foi encarregado de investigar um software que gerava mensagens de log em excesso
• Durante a investigação, ele constatou que o software fazia uma conexão MySQL com o servidor de banco de dados do fornecedor
• O banco de dados continha não apenas os dados de seu cliente, mas também os dados de todos os clientes do fornecedor
• Depois de confirmar isso, o desenvolvedor informou imediatamente o fornecedor, que corrigiu a vulnerabilidade, mas apresentou uma denúncia criminal contra ele

O mecanismo de proteção segundo o tribunal

• A questão central era se as credenciais de banco de dados hardcoded na aplicação constituíam uma proteção suficiente para justificar a acusação de hacking
• Essas credenciais estavam expostas em texto puro, e nem sequer era necessário decompilar o software
• O tribunal decidiu que, como havia uma senha, existia um mecanismo de proteção, e que contorná-lo constituía hacking

O risco que fica para a pesquisa de segurança

• A razão pela qual há reações esperando que a decisão seja revertida em instância superior é que, por mais precária que seja uma proteção, sua simples existência pode transformar pesquisa de segurança em hacking criminoso sob a lei alemã
• Se pesquisas legítimas forem inibidas, empresas poderão manter segurança inadequada e ainda assim evitar responsabilidade, deixando os usuários em risco no fim

Fonte original

• Artigo relacionado em alemão: Gericht sieht Nutzung von Klartext-Passwörtern als Hacken an

[GN⁺]

Comentários do Hacker News

• O título da matéria é meio confuso e parece quase caça-cliques. Se entendi direito, o crime dele foi ter usado as credenciais expostas do banco de dados para fazer login em um servidor de banco de dados de terceiros.
  Ou seja, ele não foi processado simplesmente por “expor” credenciais, como o título sugere; está mais para ele ter realmente usado aquilo para dar uma olhada por dentro.

  • Muitas vezes, a única forma de saber o que é um sistema é acessá-lo e investigar.
    É parecido com receber um crachá de acesso a um prédio e presumir que as portas que ele abre são salas em que você pode entrar. Se a equipe de segurança me encontra em uma sala onde eu não deveria estar, fica ambíguo se a culpa é minha ou de quem me deu um cartão com permissões erradas.
    Se eu abri a porta, olhei dentro e imediatamente percebi “ok, não era para eu estar aqui” e avisei a segurança, também fica a dúvida se eu deveria ser punido.
  • Sim, ele fez login no servidor usando credenciais embutidas no app. Como o servidor continha informações de outros usuários, se ele tivesse usado isso de forma maliciosa ou feito login sabendo que não tinha autorização de acesso, claramente poderia ser crime.
    Mas o ponto central é se ele tinha como saber disso antes de fazer login. Se as credenciais estão dentro do app, será que ele deveria presumir que a segurança da empresa era tão relaxada a ponto de dar acesso a todos os dados de clientes? Ele tinha direito de usar o app e, como o app usa essas credenciais, não é um salto tão grande ele pensar que também poderia usá-las.
    De todo modo, o resultado dessa decisão será claramente ruim para a segurança da computação. Daqui em diante, quem encontrar esse tipo de vulnerabilidade pode deixar de reportá-la por medo de retaliação legal.
  • Não há nada confuso. Apenas não foi enquadrado do jeito que você prefere.
    Do ponto de vista de um desenvolvedor, é natural ver a senha como algo destinado a impedir o acesso de não usuários, não de usuários legítimos. Para começo de conversa, as credenciais nem estavam escondidas nem ofuscadas.
    Quando ficou claro que usuários não deveriam ter acesso, ele reportou ao fornecedor. Estou deixando passar alguma coisa? De um lado há um desenvolvedor fazendo seu trabalho; do outro, uma empresa envergonhada retaliando e assustando potenciais relatores de bugs. Parece bem claro o que está acontecendo.
  • “Ele realmente usou para dar uma olhada” é verdade, mas ele acreditava que aquele banco de dados era dedicado àquele cliente e continha apenas os dados desse cliente, e esse cliente havia autorizado o acesso aos próprios dados.
    Pelo visto, o nome do banco de dados também dava essa impressão. Assim que percebeu que ali estavam os dados de todos os clientes, ele encerrou a conexão.
  • Apoio a frase Hacking Is Not A Crime.
    O importante é o que foi feito com aqueles dados depois do acesso. Se nada foi feito, não deveria ser crime; o crime deveria se configurar quando os dados fossem de fato usados de forma maliciosa.

• Isso é um problema bem grande na Alemanha. Por causa dos artigos citados, StGB 202 e seguintes, a pesquisa de segurança no setor privado se tornou, na prática, impossível ou, no mínimo, muito pouco atraente.
  Criou-se um vazio de quase 20 anos, em que jovens engenheiros quase não se interessaram por essa área nem foram treinados nela. As grandes empresas mais ricas absorveram a mão de obra que conseguiram encontrar, e os melhores talentos foram para o exterior. Por isso, as pequenas e médias empresas, que formam a maioria das empresas alemãs, são hackeadas cada vez mais todos os dias. Ninguém faz auditoria. Hoje em dia, tudo que está conectado à rede é um risco de segurança.
  Acho muito ingênuo esperar que isso seja revertido em instâncias superiores. O réu pode acabar desperdiçando anos indo do AG para o LG, OLG e BGH. Imagino que os custos também cheguem a uns 100 mil euros. E para quê? A empresa não conseguiu proteger seus próprios dados direito e, quando alguém a avisou, retribuiu o “obrigado” levando-o ao tribunal.
  Meu conselho é este: se não houver um programa de bug bounty claro, se não for sua própria empresa, ou se a empresa em questão não tiver solicitado explicitamente por escrito e pago por esse trabalho, não transforme o problema em um problema seu. Controle o complexo de bom samaritano, apague todos os arquivos e não conte a ninguém. Especialmente no trabalho, não conte mesmo. Quando o processo começar, alguém que for questionado vai dizer: “Ah, foi o Mike de DevOps que descobriu isso no dump hexadecimal”, e você vai se arrepender.
  Alguns dos veteranos alemães de segurança da informação estão tão irritados com esse problema que se recusam a ajudar até mesmo quando órgãos governamentais sofrem incidentes. A ideia é: aprendam pela dor.

• Este caso já se arrasta há anos.
  No verão passado, o tribunal rejeitou o caso da promotoria. Nesse sistema, a promotoria apresenta o caso ao tribunal, e o tribunal faz uma análise rápida; se ele for claramente fraco, pode rejeitá-lo antes de marcar o julgamento, o que é algo bastante raro. A promotoria conseguiu reverter isso em um tribunal superior e, por isso, o julgamento aconteceu no mesmo tribunal de primeira instância, mas com um juiz diferente daquele que havia rejeitado o caso inicialmente.
  “Segundo a decisão do Tribunal Distrital de Jülich de 10 de maio de 2023, o processo criminal contra o pesquisador de segurança foi rejeitado. O tribunal entende que não houve crime, porque os dados acessados pelo pesquisador de segurança não estavam suficientemente protegidos. ‘Somente dados especialmente protegidos contra acesso não autorizado entram no escopo de proteção desse crime. Isso pressupõe que tenham sido tomadas medidas objetivamente adequadas para impedir o acesso aos dados’, afirmou a decisão do tribunal. ‘O tribunal não concorda com a visão da promotoria de que a proteção por senha, por si só, seja suficiente. Por exemplo, quando a senha é simples demais ou usada de forma padronizada em uma determinada aplicação, ela nem sempre oferece proteção efetiva aos dados. Nesses casos, disponibilizar acesso aos dados não constitui crime.’”
  “A heise online conseguiu confirmar, em sua própria análise do software da Modern Solution, que ele de fato continha uma senha padrão embutida. Isso significa que qualquer pessoa que analisasse o software disponível para download livre no site da empresa podia acessar os dados nos servidores da Modern Solution.”

• Não, ele foi condenado por usar essas credenciais para se conectar ao banco de dados. Não conheço a lei alemã, mas pelo menos no Reino Unido isso é uma violação clara do Computer Misuse Act, então o desfecho era óbvio
  Goste você ou não, se está em posição de fazer esse tipo de pesquisa, precisa conhecer pelo menos o básico da lei

  • Chamar isso de “esse tipo de pesquisa” é exagero: o trabalho dele era “dar uma olhada em um software que emitia mensagens de log demais”
    Pelo que parece, o desenvolvedor não estava fazendo pesquisa de segurança, e sim investigando um bug. Conectar-se ao banco de dados, perceber do que se tratava, desconectar imediatamente e reportar de forma responsável não deveria levar a punição
    Como outra pessoa disse, desse jeito as pessoas acabam sendo incentivadas a vender esse conhecimento a quem de fato vá “usá-lo indevidamente”
  • Abrir o app já é “usar” essas credenciais. Então todos os consumidores dessa empresa também são culpados de hacking?
    Não vejo qual é a diferença. Talvez seja violação dos termos de uso, mas chamar isso de “hacking” está muito longe da realidade
    Só porque há uma senha não quer dizer que havia uma intenção de impedir as pessoas. Eles distribuíram a senha junto
    É como entregar um cartão de acesso para entrar em um prédio e dizer “não vá aonde não deve”, mas depois se descobrir que ele era uma chave mestra. Como alguém poderia saber de antemão que aquele cartão abriria até lugares onde não deveria entrar?
    Eu também tenho credenciais de serviços do Google, mas elas só me permitem acessar o que é meu
  • Não sei se é tão simples assim. Pelo que entendi, ele foi contratado por um cliente para investigar por que o sistema estava sendo inundado por certos dados
    Ele executou o conector de outro serviço de onde aqueles dados pareciam estar vindo e observou, no firewall, a abertura de uma conexão em texto claro com um servidor MySQL remoto. Ao examinar, viu que as credenciais usadas eram as mesmas em todos os tenants do banco MySQL. Portanto, o que ficou exposto não foram só os dados do cliente, mas os dados de todos os tenants
    Depois disso, pelo que sei, ele criou hashes dos dados de usuários, exportou-os para denunciar às autoridades e para permitir que os usuários verificassem se estavam incluídos em um sistema que deveriam considerar comprometido. Esse DB expôs dados de cerca de 700 mil usuários finais. Ele também informou o problema à empresa que operava o DB
    O fornecedor desse conector lançou um novo cliente que usava TLS, e ele também o contornou para mostrar que o problema ainda existia
    Ele também foi acusado de ter obtido a senha descompilando o software cliente, mas, se me lembro bem, ele alegou que simplesmente abriu o arquivo no Bloco de Notas
  • Se as credenciais do banco de dados estavam embutidas na aplicação, parece que era o comportamento pretendido a aplicação fazer login nos servidores do fornecedor. Então todos os usuários desse fornecedor também deveriam ser processados por hacking?
  • Lendo a matéria, não parece tão claro assim. O desenvolvedor descobriu as credenciais do banco de dados enquanto investigava o problema e, como o software se conectava diretamente, parece ter presumido que aquela conexão com o banco seria single-tenant ou limitada pelas permissões do usuário
    Quando percebeu que era possível acessar mais dados do que o pretendido, desconectou
    Eu já fiz exatamente a mesma coisa em uma situação parecida. Havia um fornecedor de software desktop com problema, vi que as credenciais do banco de dados estavam armazenadas em texto claro no arquivo de configuração e me conectei. No meu caso, aquele banco era single-tenant, dedicado à nossa empresa, então consegui resolver o que precisava
    Ao aplicar a lei a casos como esse, a intenção certamente deveria ser considerada, não? Não parece que esse desenvolvedor tivesse intenção de acessar um sistema restrito

• Leis assim parecem precisar ser reescritas. A intenção importa, e não parece que esse “hacker” quisesse causar dano
  A empresa passou vergonha porque uma falha de segurança foi exposta, e quer punir quem a tornou pública

  • Exato. Isso vai gerar um efeito inibidor que tornará os sistemas alemães menos seguros, e outros países fora do alcance do Ministério Público alemão vão explorar isso
    Só esse caso já basta para eu não querer trabalhar na Alemanha como desenvolvedor; na área de segurança, menos ainda
  • Concordo. Essa condenação é, na prática, uma punição por desafiar o corporativismo e envergonhá-los
    Eles querem que os “camponeses” saibam seu lugar e não espiem pelas janelas da nobreza. A menos que advogados de algum modo façam a luz da opinião pública incidir sobre o caso, o Estado quase sempre fica do lado de quem tem mais dinheiro. Por isso, esse tipo de coisa precisa ser feito anonimamente

• Já tive uma startup de alimentos na Holanda
  Trabalhamos com a PostNL, uma grande empresa responsável por envios postais e antiga organização estatal. Toda semana fazíamos upload dos nossos pedidos no sistema deles e conseguíamos ver nosso histórico
  Até que um dia, de repente, passamos a ter acesso ao histórico de todos os outros clientes e a poder exportar dados de usuários. Muitos deles eram concorrentes diretos, e suas listas de mailing teriam bastante valor para nós
  Meu sócio exportou para o Excel todos os dados da Marley Spoon, uma concorrente que havia recebido um investimento maior, e alguns outros dados. Quando ele me contou, mandei apagar imediatamente. Poderia ser divertido, mas não deveríamos criar responsabilidade jurídica. Ainda assim, se tivéssemos usado aquilo, talvez pudéssemos ter crescido de 10% a 30% em poucas semanas
  Eles nunca notificaram o incidente, embora fossem obrigados pela legislação da UE
  No fim, se você recebe as chaves do castelo, talvez seja melhor não usá-las. Ou talvez usar
  Poderíamos ter usado isso na negociação de preços, e talvez devêssemos. Nos meses seguintes, eles quase dobraram nossos preços e não tiveram piedade. Sem falar que processavam incorretamente de 3% a 8% dos pedidos e não reembolsavam
  Mas, em vez disso, migramos para alguns outros serviços de entrega, e cada um deles também tinha seus próprios defeitos

  • Se você teme retaliação, pode denunciar anonimamente à Autoriteit Persoonsgegevens e deixá-los investigar
    Capturas de tela com evidências de vazamento de dados pessoais certamente ajudariam, e duvido que a PostNL tenha corrigido aquele sistema horrível
    Pela lei holandesa, se seu colega sabia que não deveria ter acesso e, ainda assim, baixou dados além do necessário para confirmar o vazamento, ele cometeu um crime
    Se você tivesse “usado” essa informação em uma negociação, isso seria chantagem, e é algo que você definitivamente não gostaria de fazer contra uma empresa tão grande e sem concorrentes reais. Eles chamariam a polícia, e você estaria acabado

• Parece semelhante a um caso que aconteceu onde eu moro
  https://www.techdirt.com/2022/02/25/turns-out-it-was-actuall...
  Aquele “hack” foi decodificar números de seguridade social em Base64

  • A mensagem dentro do Base64 codificado nesse artigo era engraçada e me lembrou de algo em que eu já tinha pensado
    Imagine quantos programadores preguiçosos colam coisas em decodificadores Base64 online. Quanta coisa deve haver dentro desses payloads
    Administrar um site como base64decode.org seria um excelente honeypot
  • Sim, foi o caso que me veio imediatamente à cabeça ao ver este título. Por algum motivo, assim que comentei sobre isso, fui imediatamente downvotado
    Se eles tivessem realmente criptografado os dados, tudo bem, mas codificação Base64 não é criptografia. Base64 é muito fácil de decodificar: https://developer.mozilla.org/en-US/docs/Glossary/Base64#the...

• Muitos “hacks” são como algum idiota deixar a porta da frente escancarada
  Se você deixasse a porta da frente escancarada e fosse roubado, o público não teria pena; mas quando empresas economizam e não fazem nada para atualizar, manter e impor práticas básicas de segurança, as pessoas gritam com o hacker

  • Não é uma questão de “pena”, é uma questão de crime
    Se você deixou a porta da frente escancarada e eu entrei e roubei, eu cometi um crime. “A porta estava aberta” não é desculpa
  • Mesmo que você tenha deixado a porta da frente escancarada e tenha sido roubado, ainda é crime
    Eu mereceria ser criticado, mas a pessoa que me roubou também deveria receber a punição adequada
  • Não sei onde você mora para isso ser assim, mas alguém entrar só porque deixei a porta aberta não é algo normal
    Mesmo que a pessoa alegue que “só estava verificando se estava tudo seguro”

• Isso não é o oposto de uma lei do bom samaritano? É como dizer: se vir algo, não diga nada e não faça nada
  Se é ilegal procurar esse tipo de problema, fico imaginando se, depois de perceber que pode haver um problema, seria legal parar e vender a descoberto as ações da empresa

  • Desde que você não use informação privilegiada, essa venda a descoberto é totalmente legal. É mais ou menos isso que empresas como a Hindenburg Research fazem
    O problema que você encontraria ao tentar fazer isso é que investidores quase não ligam para problemas de segurança. Então, mesmo que você divulgue a vulnerabilidade, é provável que o preço da ação não caia. Além disso, parece que essa empresa nem é listada em bolsa. Não sei alemão, então não devo afirmar com certeza, mas provavelmente é esta aqui: https://www.modernsolution.net/
  • Talvez uma combinação Tor + Twitter funcione, se for realmente possível se cadastrar lá via Tor
    Algo como: “Olá, por acaso descobri que há uma senha no offset X deste app. Nesta captura de tela do dump hexadecimal, a senha aparece. Ao lado também há um nome de usuário e um host, além de um indício claro de uma conexão SQL, mas não posso confirmar qual é a senha. Não acessem este IP com esse nome de usuário e essa senha. Obrigado!”
  • Falhas assim podem passar despercebidas por anos, então talvez seja preciso dar um empurrãozinho para a venda a descoberto dar certo
    Além disso, no caso de empresas dos EUA, grandes vazamentos ou invasões de dados muitas vezes não têm impacto negativo nas finanças da empresa

• O artigo 202a do Código Penal diz o seguinte
  https://www.gesetze-im-internet.de/stgb/__202a.html
  Em termos gerais, é “obter acesso, para si ou para outra pessoa, a dados protegidos de forma especial contra acesso não autorizado”
  aparentemente uma senha hardcoded embutida no cliente também se enquadra nisso

  • Sim. É uma lei notoriamente péssima e nunca deveria ter sido aprovada
    Mas a realidade é essa, e talvez a corrijam lá por 2050