Nem sempre a criptografia é o sinônimo de segurança de dados. Isso é o que revela o relatório sobre segurança das corretoras brasileiras de criptomoedas feito pela Cryptocurrency Exchange Security Standards (CESS), uma associação que busca criar uma certificação de segurança para exchanges, após analisar as exchanges com volume diário acima de 10 Bitcoins.
Não há menção, contudo, a nenhuma empresa específica. Em diversas corretoras foram encontrados endpoints. Isto é: “possibilitam uploads de arquivos” e isso “poderia ser utilizado de maneira mal intencionada”, segundo o documento. Isso, contudo, é uma vulnerabilidade de baixo risco.
A análise foi feita por três profissionais de segurança: Deivison Franco, perito Forense Computacional; Leonardo Marciano, fundador da Sudo Financial; e Vinícius Valerio, pesquisador de segurança de informação. O documento aponta que o problema maior está nos repositórios GIT encontrados em pastas de acessos públicos, onde “foi possível montar a árvore de envio e chegar até o código-fonte da corretora”. Uma espécie de vulnerabilidade classificada como de alto risco.
Com isso é possível ter acesso à chave privada tanto das cold wallets quanto das hot wallets e a “todos fundos da corretora”, bastando apenas “uma montagem de repositório das alterações enviadas para o servidor”.
Foram encontrados servidores “com autenticação fraca” podendo sofrer ataques para a obtenção das credenciais de acesso; um Bucket da Amazon sem autenticação, o que deixaria sem proteção dados de clientes das corretoras como documentos pessoais e contas bancárias (ver imagem abaixo).
Outro problema relatado foi a da vulnerabilidade em tecnologia de terceiros, utilizados como base de software de corretoras. Do mesmo modo que ocorre com uma das maiores corretoras nos Estados Unidos, segundo aponta o relatório, essa falha possibilita “acesso aos repositórios de todos os clientes” incluindo os de versões betas, conforme é demonstrado na imagem a seguir:
Ainda sobre a vulnerabilidade de dados, o relatório apontou que nem os administradores estão a salvo e que é possível se obter seus dados “tais como login e CMS utilizados em páginas institucionais de algumas corretoras”.
Isso é considerado uma falha de risco médio e um dos fatores para isso acontecer é a manutenção do DEBUG ativo. Um dos principais recursos do modo de depuração (DEBUG) é a exibição de páginas de erro detalhadas.
Parâmetros dos testes
A seleção das corretoras foi feita a partir de uma lista disponibilizada no dia 07 de agosto desse ano no site Coin Trader Monitor, a qual trazia um ranking entre as corretoras com maior volume.
A tabela abaixo seguiu a ordem das cinco maiores, sendo as demais incluídas de modo aleatório, com exceção das corretoras Troca Ninja e Walltime, que de fato estão nas últimas posições.
Foram analisados os sites e ambientes computacionais das corretoras acima listadas com o intuito de se testar a sua resistência “aos tipos de ataques inerentes à metodologia para a realização de testes de intrusão do OWASP”.
O estudo considerou “os próprios agentes de ameaça e os impactos nos negócios” pelo fato de que “falhas flagrantes de software podem não representar um risco sério” sem que haja a ameaça de ataques.
As corretoras passaram “por três testes envolvendo APIs, infraestrutura, criptografia, encapsulamento e pentest”, sendo que para cada um desses “foi proposto um índice de vulnerabilidade”.
A pontuação apontada acima é resultado do somatório dos fatores de risco da “explorabilidade” dessa vulnerabilidade apontada, bem como da sua prevalência, detecção e do seu impacto, nos termos da tabela a seguir:
Apesar de não citar os nomes das corretoras, o relatório apontou duas tabelas com as principais vulnerabilidades encontradas:
Detalhes com perícia
Deivison Franco, perito forense computacional e presidente do Conselho que preparou o relatório, afirmou ao Portal do Bitcoin que os testes feitos em APIs servem para verificar se elas mantêm as séries ou se podem ser alteradas a partir de um ataque pelo qual o invasor “modificar a lógica da aplicação ou realizar a execução arbitrária de código remoto nesta”.
Franco diz que não se deve usar APIs que “estão à toa por aí”. Eles podem estar com vulnerabilidades conhecidas e “isso prejudica as defesas da aplicação ao permitir que a mesma entre em produção suscetível a vários ataques simultâneos ao ambiente”.
“As boas práticas de segurança recomendam não aceitar objetos ‘serializados’ de fontes não confiáveis ou, se usar, que use ‘serialização’ média para permitir apenas dados primitivos.”
Os testes de infraestrutura são importantes para saber “o quanto alguém consegue de fora acessar o que não deveria”, afirma o perito.
Insegurança criptográfica
Os testes de criptográfica têm como objetivo “verificar a resistência das chaves criptográficas”. O perito diz que a criptografia pode ser decodificada, “dependendo do tamanho da chave”.
Ele afirma que mesmo que o atacante não quebre a criptografia isso não quer dizer sinônimo de segurança total.
“Por mais que eu não consiga decodificar uma mensagem trocada entre A e B, ainda assim eu posso ou interromper o tráfego, ou interceptar e corromper um bit. Perceba que o objetivo aqui, não é ler a mensagem trocada, mas de torná-la indisponível, corrompendo-a ou interrompendo-a”.
O perito ainda afirma que há outro tipo de ataque, pelo qual “mesmo que um remetente esteja enviando mensagens criptografadas para um destinatário”, um invasor pode saber quando e a partir de que celular essas mensagens foram enviadas, bastando recorrer aos “metadados das conversas”.
Franco diz que mesmo que se possa conhecer a “conexão entre dois telefones e dizer que o telefone de ‘Fulano’ trocou mensagens com o de ‘Beltrano’”, “não é possível dizer ou saber o conteúdo do que foi conversado”.
Hashes sem “SALT”
O relatório faz menção ao risco que se tem de um banco de dados utilizar “hashes simples ou sem SALT para armazenar as senhas de todos”.
“Uma falha de upload de arquivo permite que um invasor recupere o banco de dados de senhas. Todos os hashes sem salt podem ser expostos com uma tabela de arco-íris de hashes pré-calculados.”
Deivison Franco diz que o hash é um algoritmo que “transforma qualquer bloco de dados em uma série de caracteres”, essa série terá sempre o mesmo número de caracteres. Daí vem a importância do salt, que é um “dado aleatório que é usado como uma entrada adicional junto a uma senha”.
O perito explica que isso ocorre em uma espécie de “função de mão única”, que gera como saída um hash. Cada senha de usuário gera um novo salt aleatoriamente. A segurança é maior nesses casos porque “o salt e a senha são concatenados e processados com uma função de hash criptográfica, então apenas o resultado e o sal são guardados no banco de dados”, afirma.
“Sendo assim, podemos dizer que a função primária do salt é defender tanto contra ataques de dicionário aliados a aplicação de hash quanto a ataques pré-computados como rainbow table.”
Caso o banco de dados esteja comprometido, a integridade dos dados estaria garantida tendo em vista que a senha purotexto que somente o usuário conhece estará protegida e o hash “poderá ser recalculado com o salt guardado”, diz o presidente do Conselho.
A questão, entretanto, é que os hashes gerados por funções hash simples ainda assim podem “ser forçados a bruto” pelas unidades de processamento gráfico (GPUs) e nem o SALT poderá salvá-lo de possível decodificação.
Recomendações
Além de apontar as falhas de segurança das corretoras brasileiras, o relatório traz uma série de recomendações que podem ajudar a evitar problemas de vulnerabilidade como as que foram apontadas anteriormente:
I – Não deixar informações de acesso ao seu banco de dados em arquivos como app.bundle.xxxx.js, mesmo que esteja configurado para apenas consulta. Atacantes mal intencionados podem utilizar para conseguir informações privilegiadas de seu banco de dados;
II – Não utilizar o CloudFlare pela facilidade de squashing para descobrir o IP Real da aplicação, opte por Sucuri ou Fastly;
III – Não deixar diretórios de acesso administrativo acessíveis a todos, e se possível utilize soluções captcha para impedir ataques bruteforce;
IV – Não deixar exposto a página de acesso do PhpMyAdmin e/ou documentações que exponha a versão do mesmo, com essas informações é possível fazer ataques contra o gerenciador;
Leia o relatório completo aqui.
Procurando o melhor lugar para fazer seus trades?
A Huobi, exchange líder em ativos digitais, chegou ao Brasil! Crie sua conta em menos de 1 minuto. Plataforma em português, mais de 150 altcoins, taxa de apenas 0,20%, liquidez e muita segurança, acesse: https://www.huobi.com/