O dilema em reportar uma vulnerabilidade em um programa de Bug Bounty ou lucrar com ela por outros meios não é algo que ocorre com todos os white hats, mas aquele “1%” é o complicado.
O pessoal do site GBHackers, com a ajuda de Ilan Abitbol da Resonance Security, analisou um recente caso envolvendo as empresas Kraken e Certik e usou como exemplo para discutir sobre problemas relacionadas aos programas de recompensa de bugs que surgiram nos últimos anos na indústria de tecnologia em geral e na de criptomoedas em particular.
Para mais detalhes sobre este caso veja este post no site do Cointelegraph Brasil.
Uma Vulnerabilidade de Reentrada no sistema da Kraken
Em 9 de junho de 2024, um pesquisador de segurança da CertiK reportou à empresa de exchange de criptomoedas Kraken, que havia encontrado um bug em seus sistemas. Era um bug significativo, aliás, o equivalente a uma vulnerabilidade de reentrada, mas na interface web da exchange.
Bugs de reentradas são explorações nas quais você pode sacar dinheiro ou criptomoedas, e em seguida, interromper o sistema antes que o valor retirado seja subtraído do seu saldo. Ou o contrário, iniciar um depósito, aguardar que o seu saldo aumente no sistema e assim encerrar o depósito antes que ele seja concluído.
Pense que é como se você sacasse 400 pila do caixa eletrônico e o desligasse antes que o sistema do banco fosse informado por ele de que o valor deve ser debitado da sua conta.
Agora ligue o caixa eletrônico novamente e você poderá repetir o processo até que todo o dinheiro seja retirado do caixa sem diminuir o saldo da sua conta.
É por isso que programadores competentes de Smart Contracts (pra quem é do mundo das criptomoedas já ouviu falar) utilizam um padrão chamado “checks-effect-interactions” (verificação-efeito-interação) em seu código, que é detalhado aqui:
- Verificar se o cliente possui saldo suficiente para cobrir o valor do saque (a verificação);
- Reduzir o saldo pelo valor da retirada (o efeito)
- e então, só então, enviar ao cliente o valor do saque (a interação)
Ou para o caixa eletrônico, não disponibilizar as notas até receber a confirmação do banco de que o saldo foi reduzido.
No caso da Kraken, um pesquisador de segurança encontrou uma maneira de efetuar um deposito na exchange (Kraken), retirar o dinheiro de sua conta e, em seguida, cancelar o depósito antes de ser concluído, muito parecido com o exemplo do caixa eletrônico.
O que diz a lei?
Se você for contratado como parte de um exercício de pentest, onde especialistas em segurança tentam invadir um determinado sistema com a chancela da empresa, então posso fizer para você “ficar tranquilo”. Você não pode ser processado criminalmente (e de outro tipo de processo que possa ser feito contra você), porque o acesso foi explicitamente concedido. Você está autorizado a fazer o que está fazendo.
Agora, caso você seja uma pessoa desconhecida que está invadido o servidor de outra pessoa e causando danos, excluindo arquivos ou extraindo dados e outros ativos, então você tá muito errado. O que você está fazendo é criminoso, e se for pego, as penalidades podem ser severas. Em alguns casos, estamos falando de anos ou décadas em que você poderá ver o sol nascendo quadrado.
Até quem é correto “pode” infringir a lei
“Ser um white hat é mais uma forma de pensar do que um status”.
Surge um problema que fica numa área cinzenta da cibersegurança, pois não existe uma definição formal do que constitui ser um Hacker White Hat. E se, no processo de uso legítimo de um interface web em um site, você encontrar um bug que lhe permita acessar mais do que deveria? De acordo com a legislação padrão de prevenção ao uso indevido de computadores, até mesmo “cutucar” um bug significa que você está infringindo a lei.
Em abril de 2024, um grupo de quatro estudantes da Universidade de Malta encontrou um falha de segurança numa aplicação para estudantes chamada FreeHour, que lhes permitia ter acesso aos registros dos estudantes como se fossem administradores do sistema.
Eles relataram o bug (que se tratava de um problema de configuração no banco de dados), seguiram a regra usual dos white hats ao fornecer um prazo de três meses ao FreeHour para corrigir o bug antes de que ele fosse divulgado publicamente e perguntaram se poderiam ter uma recompensa pela descoberta do bug.
A FreeHour afirma que relatou isso às autoridades apenas para cumprir a legislação do GDPR. A polícia acabou prendendo os estudantes, revistando-os e confiscando seus equipamentos de acordo com o que pedia a lei Maltesa, que torna ilegal o acesso a um sistema sem a devida autorização.
Os alunos declararam que estavam agindo de boa fé, e provavelmente estavam mesmo. Afinal, eles não fizeram nenhuma exigência, nem tentaram exigir ao FreeHour um pagamento por regate de dados.
A empresa diz que estava seguindo os requisitos regulatórios. O pessoal do site GBHackers não obtiveram qualquer resposta por parte da polícia maltesa, mas se fosse pressionada, provavelmente diriam que estavam apenas cumprindo a lei.
É provável que estes estudantes nunca mais reportarão um bug a uma empresa ou governo.
A treta entra a CertiK e Kraken
Voltando a este caso, a empresa de auditoria CertiK certamente não recebeu permissão da Kraken para retirar quase 3 milhões de dólares de criptomoedas como parte de um exercício de hacking white hat.
Como disse Ilan Abitbol ao site GBHackers, “ser um white hat é mais uma forma de pensar do que um status”.
O programa de Bug Bounty
Claramente computadores que estão em rede terão alguma vulnerabilidade. Agora de uma perspectiva mais útil, o que queremos é incentivar as pessoas a agirem como cidadãs responsáveis e a reportarem vulnerabilidades, em vez de as ignorarem, ou pior, de explorarem-nas de formas criminal.
A solução da indústria é a recompensa por bugs: uma forma legítima de especialistas em tecnologia independentes a lucrarem com suas descobertas
Basicamente, as empresas fornecem uma lista de requisitos e regras para hackers white hats, e se você seguí-las à risca, o empresa diz que não irá processá-lo, podendo até lhe dar uma recompensa em dinheiro pelo seu esforço, dentro de uma escala proporcional ao risco da vulnerabilidade que você reportou.
Problemas que podem ocorrer em um programa de Bug Bounty
- E se você acidentalmente quebrar uma das regras (geralmente são muitas) estabelecidas para o programa de bug bounty?
- A recompensa que você receberá será realmente proporcional ao dano que você ajudou a empresa a evitar ao reportar o bug?
- Como não existe um contrato explícito entre entre o hacker ético e a empresa, o que dizer do fato de que as autoridades ainda podem decidir processá-lo e prendê-lo, mesmo que você tenha cumprido todas as regras do programa de bug bounty?
A Kraken possui uma política de recompensa por bugs. Uma das coisas que a política diz é que para ser considerado um hacker white hat ou ético, o report da vulnerabilidade “nunca poderá conter ameaças ou qualquer tentativa de extorsão”. Ao manter os fundos que sacaram, pode-ser argumentar que a CertiK fez exatamente isso.
O que podemos concluir?
Ironicamente, as recompensas por bugs e o espaço das criptomoedas conseguiram de alguma forma evoluir para uma situação em que os riscos em entrar para um programa de Big Bounty às vezes são maiores e as recompensas obtidas são menores do que se você entrar para o lado negro da força.
Podemos dizer que as empresas deveriam:
- Estabelecer um programa de Bug Bounty generoso e bem estruturado/claro;
- e cumpri-lo rigidamente;
Creio que na prática isso não ocorrerá.
Mas uma coisa é certa: os programa de bug bounty precisam ser repensados seriamente, ainda mais nesta época de criptomoedas em que nos encontramos.
O que vimos neste post?
- Um funcionário da CertiK encontrou e explorou uma vulnerabilidade na aplicação web da exchange Kraken, sem seguir as regras do programa de bug bounty da Kraken;
- Estudantes da Universidade de Malta encontraram uma falha de segurança no sistema da FreeHour e reportaram à empresa, dando alguns dias para que a mesma corrigisse a falha, algo usual entre os white hats. O que não ficou claro é se os estudantes estavam atuando dentro de um programa de bug bounty ou se apenas pediram uma recompensa pelo bug encontrado (mesmo que agindo eticamente). O problema com isso é que mesmo atividades legítimas podem ser enquadradas criminalmente pelas autoridades.
- Você caro profissional de segurança ao encontrar uma falha deve ficar com um pé atrás antes de divulgar publicamente (e quando não der um tempo legal para a empresa corrigir). Alguns podem falar que deram dias, semanas ou meses antes de publicar a vulnerabilidade.
Já vi caso de empresa que não tinha programa de bug bounty. O hacker ético encontrou a falha (que no caso era uma vulnerabilidade IDOR), reportou à empresa (não pediu nenhuma recompensa, apenas sugeriu que a falha fosse corrigida), que na mesma hora começou a “atacar” o hacker ético, alegando que ele tinha invadido seus sistemas, quando na verdade não tinha. Foi necessário até acionar o ministério público para a coisa tomar um rumo legal…
Créditos
https://gbhackers.com/the-problem-with-bug-bounties
Créditos da imagem usada na capa do post:
Conheça a distro Linux para ser utilizada por profissionais que atuam no segmento do Bug Bounty:
https://www.canalhacker.com.br/2023/01/11/bugbuntu-conheca-a-distro-linux-com-foco-em-bugbounty
Como está se sentindo?
