A comunidade brasileira de criptomoedas ainda é pequena e, dentro de uma comunidade, cada um ajuda com a habilidade que tem. Há algum tempo atrás eu acredito ter encontrado uma forma de ajudar a tornar esse cenário mais seguro.
Isso é feito usando algo poderoso e bastante simples: o livre mercado. Inspirado nele, eu criei uma espécie de ranking em que as exchanges e outras plataformas de criptomoedas possam concorrer pelo topo, de forma completamente livre, gratuita e imparcial. O importante aqui é desincentivar o amadorismo.
Dizer que é seguro todo mundo diz, agora é a hora de provar.
No começo de Julho, eu realizei testes de segurança na plataforma da Atlas Quantum, para rankear ela. Durante esses testes, eu bati em algumas falhas de segurança, sendo uma crítica.
Conforme meus procedimentos, realizei um relatório para eles levantando cada um dos achados e oferecendo dicas adicionais de segurança. A Atlas então se prontificou a corrigi-las.
Abaixo eu faço um relato das questões mais graves por mim levantadas, e que poderiam ter um impacto grave se não corrigidas:
Para esse ataque acontecer, seria necessário apenas saber o e-mail ou o número de telefone da vítima em questão, ao preencher essa informação no campo de “esqueci minha senha” o back-end enviava um e-mail com um link secreto para prosseguir com o procedimento de reset.
O problema é que o back-end acabava vazando e entregando esse link secreto também para a pessoa que executou a solicitação, como se pode ver pela tela abaixo. Isso significa que o atacante não precisava ter acesso ao e-mail da vítima para prosseguir com o processo de reset.
Para ser justo, na tela seguinte, no entanto, era necessário digitar 6 números enviados ao telefone ou o e-mail da vítima, sem captcha, mecanismo conhecido para evitar robôs, esses números não eram vazados, mas poderiam ser descobertos facilmente por tentativa e erro.
Um computador com uma boa conexão, no pior dos casos, levaria em torno de 3 a 5 dias tentando números até conseguir realizar a troca de senha com sucesso.
Prova de conceito
De forma a provar esse risco eu elaborei dois programas de brute-force como prova de conceito e enviei para a equipe de tecnologia deles. Através do uso da rede TOR esses programas trocavam periodicamente o endereço IP de origem, efetivamente permitindo a penetração de firewalls e ultrapassando medidas preventivas.
O primeiro programa elaborado realiza um ataque simples para adivinhar o código de 6 números, já o segundo reseta esse código diversas vezes para tentar forçá-lo a um valor desejado (retoken).
Ambos os códigos para as provas de conceito estão sendo liberadas agora no meu GitHub, vale ressaltar que esses programas de brute force não funcionam mais e estão sendo publicados agora apenas para fins educativos e de pesquisa.
Na implementação presente no momento dos testes, não era exigida a digitação desse código no ato de login, no entanto, após ter entrado, o cliente ou atacante já poderia imediatamente proceder para desligar o 2FA.
O ato de desativação (ou troca) do 2FA tem que ser um ato burocrático, exigindo prova da real identidade do cliente, caso contrário a segurança provida por ele acaba sendo inutilizada.
O vazamento de contas e a decisão de aguardar
Essas falhas unidas a lista de contas vazada da Atlas poderiam ser usadas em conjunto para fazer ataques direcionados, vale lembrar que a lista oferecia não só o login dos clientes como o saldo de cada um na plataforma.
O potencial destrutivo de um ataque direcionado seria extremo para os clientes, levando isso em questão, para não dar armas ao inimigo, eu segurei por diversos meses esse disclosure, programando então a release durante a conferência Bitconf Summer Edition de 2018.
Por motivos de força maior não poderei comparecer à conferência mas mantendo meu compromisso com a transparência e a comunidade estou liberando a falha que irá compor a nova lista de plataformas por ordem de segurança.
Um apelo às plataformas
Eu aproveito esse caso para fazer um apelo: é importante que as plataformas de criptos nunca usem telefone para recuperação de senhas, isso porquê é muito fácil “clonar” os números dos clientes para seguir com a troca de senhas.
Isso ficou provado após o vazamento da lista da Atlas em que uma série de ataques coordenados desse tipo foram tentados contra os clientes top 10 mais ricos dela. Um deles, um amigo próximo, só não teve a senha trocada e saldo roubado pois seguiu minhas recomendações logo após o incidente.
Permitir reset de senha por telefone é uma brecha de segurança por si só, eu sei que o Google, Twitter e grandes nomes permitem isso mas eles também estão errados.
Relatório antigo sobre a falha de 2FA encontrada na Foxbit, contém informações sobre boas práticas na implementação de 2FA e outras medidas de segurança: https://goo.gl/46oWm1
Tempo para correção: Mais de 30 dias, não recebi acompanhamento, respostas ou qualquer informação para poder dar um momento exato.
Nível de atenção ao relatório de falha: Baixo, o contato foi feito diretamente com a diretoria tecnológica da Atlas, no entanto, pelo meu ponto de vista, não acredito ter recebido a atenção devida.
Dizem que o pior de uma catástrofe não é ela em si, mas a repercussão dos dias seguintes. Nos olhos de um hacker, ou golpista, a lista de nomes da Atlas é um verdadeiro pote de ouro.
A lista contém o saldo em BTC, nome completo, email e telefone de mais de 260 mil clientes da plataforma financeira de arbitragem Atlas Quantum.
Olhando através desses olhos nada amigáveis o que temos na verdade é uma lista de alvos, grandes e rechonchudos, objetivos de roubo, e informações suficientes para começar a trabalhar.
Vejo muitas similaridades entre esse vazamento e o que ocorreu no banco Inter mais cedo esse ano, até mesmo por ambas as fintechs adotarem uma infraestrutura em comum.
Primeiro, quais medidas devo tomar?
Dependendo da sua posição, o vazamento de dados pode ser até mais catastrófico do que dinheiro em si. A lista contém diversas pessoas públicas, aqui estão em risco não só os ativos digitais mas sua integridade física, principalmente se você está nos top 10 mais ricos. O vazamento de saldos dá uma boa idéia de onde mirar. No meio hacker é conhecido que telefone = endereço, nome completo, CPF, etc. Um beijo pro CADSUS.
Você pode verificar se seus dados foram vazados no seguinte site: https://haveibeenpwned.com basta digitar seu e-mail no campo de busca, ele também vai te informar de outros vazamentos que possam conter seus dados, a referência cruzada entre vazamentos é um prato cheio de informações para os hackers.
Caso o resultado dê positivo, a medida a se tomar é não acreditar em nada mais que chegue a seu e-mail vazado, nem mesmo mensagens no seu telefone. A primeira coisa que os golpistas irão tentar é o mais fácil: usar suas informações pessoais para tentar te enganar.
Como se proteger
1ª medida: email
Ok, agora é hora de criar um email novo, você vai passar a ter um email só para exchanges e assuntos relacionados ao Bitcoin, isso é uma boa prática de segurança, neste exemplo vamos chamar ele de emaildosmeusbitcoins@gmail.com. A senha desse email deve ser única, usada SOMENTE nele.
Agora dê uma passada em todas as exchanges que você tem conta e troque seu email de cadastro. A dica no caso do Gmail é que você cadastre ele como sendo emaildosmeusbitcoins+atlasbla@gmail.com para a Atlas, emaildosmeusbitcoins+binancexyz@gmail.com, para a Binance, e assim por diante. O Google ignora tudo depois do + (sinal de mais), experimente enviar um email pro seu endereço + algo e ele chega sem pestanejar.
Reparem que no final eu coloquei 3 letrinhas aleatórias, o texto aleatório ajuda muito a dificultar que hackers encontrem seu login em novos vazamentos, não somente isso, tal medida evita phishing — ao receber email da exchange você tem uma garantia a mais de que veio dela mesmo pois só ela vai saber o que você colocou depois do + -.
Na hora de escolher as letras aleatórias, lembre-se: paranoicos de verdade dão murro em teclado. Não se preocupe de esquecer seu login, para relembrar basta olhar em que endereço chegaram os emails.
É importante que você não possa mais entrar nas plataformas com seu email antigo vazado, isso vai evitar que atacantes tentem resetar ou adivinhar sua senha em todas que tiver conta cadastrada, e acredite, isso vai acontecer muito ainda.
2ª medida: senha
Apesar de o vazamento não incluir as senhas dos cliente, o hacker ainda pode cruzar as informações com outros vazamentos. No comunicado oficial o CEO da Atlas afirma que estavam criptografadas, mas não sabemos exatamente qual cifra e se elas realmente estavam seguras.
Como eu mencionei, é importante manter uma senha diferente para cada serviço que usa, desde email até cada conta de exchange, mas a questão sempre é: como vou lembrar de tantas senhas assim?
É aí que entram gerenciadores de senha como o LastPass, KeePass e 1Password, o último sendo meu favorito por motivos que fogem do escopo aqui. Ao invés de reusar a mesma senha em todos os lugares você pode usar senhas aleatórias, através destes aplicativos você precisa lembrar apenas de uma senha para abrir seu cofre de senhas, ou seja, sua segurança fica concentrada em um ponto, então cuide bem dele.
Aproveite que já está trocando seu email nas exchanges e troque também suas senhas com as geradas por um destes aplicativos, você vai aprender a amá-los em pouco tempo.
3ª medida: telefone de recuperação
No dia 28 de dezembro, o especialista em segurança John McAfee (o do antivirus) teve sua conta no Twitter invadida por um descuido: o hacker sabia seu número de telefone. Sim, hoje em dia nada mais é necessário além de um simples número de telefone.
Existem falhas no protocolo de telecomunicações, além da possibilidade de se corromper funcionários de empresas de telefonia para roubar temporariamente o seu número, recebendo mensagens e ligações em seu lugar durante o período, recentemente esse tem sido o modelo de ataque preferido dos hackers.
O perigo mora na recuperação de senhas do seu email, redes sociais, contas em algumas exchanges, etc. Ou seja, se alguém pegar seu número por alguns segundos ele pode ter acesso a todas as suas contas que possam ser recuperadas por telefone.
A melhor medida a se tomar agora é trocar o telefone de recuperação do seu email e redes sociais, para manter as coisas simples, escolha um parente de muita confiança e troque o telefone de recuperação de suas contas para o dele, isso já irá mitigar o problema. Só não deixe o número vazado cadastrado como seu telefone de recuperação em hipótese alguma. Essa dica vale principalmente para os maiores investidores da lista.
Ative também o 2FA no Email, WhatsApp (Na tela de configurações), no Facebook, Twitter e onde mais tiver, use somente 2FA via aplicativo e negue todo 2FA por SMS, pode não parecer um risco alto mas alguém personificar você pedindo dinheiro aos seus familiares ou para dar golpes em terceiros é algo muito comum.
Adendo
Se você está na lista dos mais ricos todo cuidado é pouco, considere o uso de seguranças particulares para evitar sequestros ou assaltos. Eu ouvi dizer que a Europa está excelente essa época do ano…
Afinal, o que aconteceu?
A pergunta que fica no ar é o que aconteceu para tamanho vazamento? Não dá para ter certeza do motivo exato sem acesso aos logs internos da Atlas, mas olhando de fora da para ter uma ideia, para isso temos que analisar as cartas que estão na mesa.
Para tentar explicar o incidente começamos olhando para as informações em si, os dados vazados são algo que estariam à disposição de qualquer funcionário de suporte da empresa. A Atlas cresceu muito no último ano, a demanda por suporte com certeza estourou sem dar tempo suficiente para ajustar o modelo de confiança da plataforma.
Inside Job?
Então foi um inside job? Não necessariamente… Sabemos que o elo mais fraco de qualquer sistema de segurança são as pessoas, e contra isso não há dúvidas, um funcionário triste e carrancudo é algo muito fácil de se encontrar numa empresa desse porte.
Mas existe ainda o fator engenharia social para se levar em conta, uma empresa grande pode ser difícil de se invadir, a menos que a pessoa trabalhe lá. O vetor mais comum é o reúso de senhas: basta um funcionário leigo não ter prestado a devida atenção a uma senha vazada anteriormente que já se tem um bom caminho para seguir.
Ninguém está protegido contra isso, plataformas financeiras no entanto costumam mitigar esses riscos controlando de perto o círculo de confiança e os acessos. Isto é: um funcionário de suporte precisa mesmo saber tudo sobre todos? Ou só aqueles que pedem ajuda e somente ao longo do ticket?
Eu não descarto também um acesso indevido ao sistema de suporte interno por vias de invasão, o sistema aceitava plenamente o cadastro de scripts no nome do cliente, pode-se até observar um cookie jar em meio aos nomes vazados. Vale lembrar que recentemente a Atlas passou por uma reconstrução de sua plataforma, e com código novo surgem bugs novos.
Por que um vazamento, e não um roubo?
Agora vamos olhar um pouco pelos olhos do invasor, isso sempre ajuda, vamos supor que você tenha obtido acesso ao sistema interno de uma plataforma financeira, qual a primeira coisa que você tenta fazer? Roubar dinheiro.
Vazar informações dos clientes parece algo muito simples para se queimar uma ficha de acesso tão valiosa assim, um atacante só faria essa publicação mesmo caso não tenha obtido acesso a fundos, e apenas após uma boa sessão de extorsão mal sucedida — vide caso do Inter.
Acho difícil a pessoa ter obtido acesso ao banco de dados como muitos predizem, caso contrário os dados vazados poderiam ser bem mais completos e suculentos. Me parece que a real intenção do invasor não foi obtida, e esse vazamento foi, de fato, uma vingança.
Testes de invasão na Plataforma
No último mês, atendendo o desejo da comunidade, realizei testes de penetração não invasivos no sistema da Atlas de forma a dar uma colocação no ranking de segurança brasileiro. Diante destes testes, levantei algumas falhas de segurança e elaborei provas de conceito enviadas diretamente à diretoria tecnológica deles, somente a pessoas de confiança.
As questões levantadas por mim não tinham relação direta com o ocorrido neste vazamento, nenhuma permitia acesso ao sistema de suporte em questão. Foram recebidas pelo setor de tecnologia e algumas falhas já haviam sido corrigidas, outras ainda estavam em processo de correção.
Em virtude deste vazamento de dados, eu irei adiar a publicação das falhas encontradas por tempo indeterminado, primeiro para não fornecer munição ao inimigo, visto que as vítimas já vão receber atenção suficiente agora, segundo para não interferir com as investigações.
Parabéns a você que clicou no meu bait, mas fica aí que o assunto é interessante. Apesar desse título chamativo eu não invadi ninguém ok? Afinal isso seria ilegal... Mas eu descobri uma forma como eu poderia tê-lo feito com a, digamos, exchange X, sem muito trabalho, uma das exchanges Brasileiras campeãs em volume, e tudo isso estudando a plataforma por 30 minutinhos. Todas as falhas aqui descritas já foram informadas a eles e corrigidas, mas serve de aprendizado, tanto para quem faz exchange como para quem testa.
Eu só queria fazer um disclamer antes: todas as pesquisas de segurança que faço tem pura e unicamente o objetivo de fortificar a comunidade, tornando exchanges Brasileiras mais seguras e atentas, e usuários mais astutos. Este artigo tem finalidade PURAMENTE ACADÊMICA, aprenda com os erros dos outros para não os cometer; no fundo meu objetivo é formar white hats que possam ajudar esses ideais, agora, se você possui más intenções com essa informação, a porta é serventia da casa.
Se você não estiver acostumado com segurança de dados deve estar pensando nesse momento que invadir uma plataforma financeira deve ser a coisa mais complicada do mundo, afinal eles tem bastante para investir em segurança, e se mexem com dinheiro devem se preocupar bastante com isso. Espero que ao final eu tenha desmistificado isso, a coisa não é bem assim, você ficaria impressionado com o tanto de falhas bobas que acabam deixadas para trás - e essa é um bom exemplo.
Tudo começou quando eu fiz um saque de criptos na referida exchange, estava pensando aqui comigo: Por quê a API deles, dentre todas, é a única que não suporta saques? Isso é um pouco estranho e transparece medo ,implementar saques de forma segura realmente envolve riscos, são necessárias white lists de endereços, uma forma de cadastrar eles bem fechada, e por aí vai..
Apesar de estranho dei uma olhada em como o sistema requisita esses saques internamente - vai que dava pra implementar no meu robô usando esses meios. Primeiro eu olhei com o console do Chrome mesmo, era enviada a solicitação de saque para uma API que retornava um OK, até aí belezinha, seguindo fui olhar meu email:
Bom, achei esse token interessante, normalmente as exchanges usam UUID4 com um RNG criptográfico por trás, traduzindo, eles geram um numero bem grande totalmente aleatório. Esse aí parece um hexadecimal grande, mas por enquanto vamos botar um pino nisso e seguir estudando o motor de saques.
O próximo passo foi olhar a lista com meus saques solicitados para entender como ficam registrados no sistema - o meu saque ainda deve estar lá, não autorizado, afinal eu ainda não cliquei no link... Bom, vamos ver como o site requisita essa lista, e como ela vem pro navegador usando o console do Chrome de novo, guia Network...
Hohoho, papai noel chegou cedo esse ano... O retorno do backend veio com um brinde. Repare que esse aí é o mesmo token de saque que veio no email de confirmação logo acima. O que aconteceu aqui é que, talvez para fins de conveniência, talvez por esquecimento, o endpoint de listagem dos saques está vindo com todas as informações do objeto, e entre elas o link que tenho que clicar pra confirmar o saque.
Repare que aqui eu passei a chamar de objeto, pois já vi essa estrutura de informações no passado, isso aí se trata de um objeto do MongoDB, representado em Json. Note também que o tal "token" está aparecendo num campo chamado Id. Nesse momento me assustei, será mesmo que o token não é aleatório no final das contas?
Para confirmar essa suspeita joguei o "token" num conversor de ObjectId para Timestamp:
Psiu! você com olhar de paisagem! Respira que vou dar uma pausa na programação original para explicar a gravidade disso ok? 9.8 m/s2
Para entender certas coisas ajuda olhar pelos olhos do vilão, se eu fosse um hacker malvadão que acabou de pegar sua senha, ou achou sua máquina logada nessa exchange, o que me impede de sacar todo o seu saldo? O email de confirmação é para isso! Além de invadir sua conta eu precisaria invadir também o seu email, para obter o tão famigerado link que chega lá, só que não.
1- Em primeiro lugar, eu não precisaria mais invadir seu email, já que o site da exchange X me dá o token, que é a única parte que ninguém sabe do link, o trabalho é de simplesmente navegar até ele.
2- Em segundo lugar, e talvez até pior, o token não é aleatório, é determinístico, ou seja, mesmo que o site não me desse ele de mão beijada, eu poderia descobrir qual é seu token pela data e hora que solicitei o saque, mwahaha! Calma que explico a seguir:
A documentação do MongoDB diz o seguinte: "A BSON ObjectID is a 12-byte value consisting of a 4-byte timestamp (seconds since epoch), a 3-byte machine id, a 2-byte process id, and a 3-byte counter" - Fonte: http://www.mongodb.org/display/DOCS/Object+IDs
Bom, o timestamp eu tenho, pois fui eu quem solicitou o saque, caso não lembre ele vem na listagem de saques de toda forma, machine id é só ler em qualquer objeto, process id também, então tudo que resta é o contador sequencial do MongoDb, para resolver isso basta solicitar 2 saques em seguida, o primeiro você usa para extrair os dados, o segundo você confirma, incrementando aos poucos e testando o id, um mini-bruteforce, bobinho de ser feito.
Até o momento você leitor pode até estar decepcionado com o "bypass de email de confirmação", oras, de que serve uma falha que só quem pode explorar é quem já tem a senha do cliente? Apesar de grave, realmente é anticlimático, mas o clímax ainda está por vir...
De posse dessa falha a última peça do quebra cabeças seria uma forma de solicitar o saque no lugar do cliente, eu (o hacker malvadão), posso simplesmente fazer uma página idêntica à exchange X, e daí torcer para você (vítima) entrar nele e digitar sua senha, Laaaaaame...
Para não fazer do jeito mais chato, sobram ainda 2 possíveis metodologias:
1- Forçar o navegador da vítima a solicitar o saque.
2- Capturar o cookie contendo a sessão, e em seguida solicitar o saque.
Vamos de opção número 1, para isso eu trouxe à tona um antigo parceiro, o CSRF, dependendo de como são feitas as solicitações de saque, a nível de formulário, pode ser possível criar um segundo site "infectado" com um javascript simples, este site pode então mandar seu navegador pedir o saque, de forma invisível, basta entrar nele. Bem melhor que phishing né?
Masss nem tudo é perfeito, estudando o que é enviado no momento do saque podemos ver uma hash sendo passada, que também está presente no cookie, ou seja, a hash funciona como um token de CSRF, que a cada pedido de saque é validada novamente para garantir que esse pedido veio mesmo da exchange X. Além disso, não observamos o cabeçalho Access-Control-Allow-Origin, e de acordo com a política dos navegadores atuais, quando ele não está presente por padrão só são permitidas requisições vindas do mesmo domínio.
Com o CSRF fora da jogada, comecei a caçar um XSS Injection, o XSS (Refletido) é quando a gente consegue, através de um link, injetar javascript malicioso na página da exchange. Esse script pode fazer algumas tarefas para o atacante: enviar o cookie do cliente para algum lugar ou solicitar o saque e confirmar ele mesmo.
A idéia de injetar algo que pudesse sacar os valores e já confirmar, direto da máquina do cliente, seria excelente para um roubo em massa de Bitcoins. Os ataques, nesse caso, ficariam difíceis de detectar, afinal os saques viriam do mesmo ip do cliente; até que fosse possível encontrar o ponto de injeção (e que tinha uma injeção ocorrendo em primeiro lugar) muito dinheiro já teria sumido.
Comecei a escavar os endpoints do site, notei que o endpoint do extrato, que mostrava as operações realizadas com determinada cripto, permitia que se colocasse mais do que só o nome da moeda na url, por exemplo: /exchange/detail.php?cur=teste, e ele mostra o texto "teste" no site. Deste ponto em diante seria apenas confeccionar um script e colocar no lugar da moeda certo?
Ainda não tão simples, agora sim a parte difícil, normalmente os navegadores possuem detectores internos, para evitar que você se torne vítima de um XSS Injection, então ainda teria que bolar um script que além de efetivo pudesse enganar esse detector.
No Chrome a detecção basicamente procura por um fechamento de tag </script>, sabendo disso foi possível ultrapassar com o seguinte script: /exchange/detail.php?cur=<script>alert(1);
Isso deveria exibir uma mensagem de alerta, mas tem um problema ainda, como o site deixa o nome da cripto em maiúscula o script todo ficava em maiúsculas. No Javascript as maiúsculas influenciam no nome da função.
Esse endpoint não seria o ideal, a mensagem de alerta não surgiu pois o ALERT acabou todo em maiúsculas, foi então que decidi procurar outro endpoint melhor. Vamos atrás de um velho parceiro meu, o sistema de suporte.
Aqui foi bem fácil encontrar o Injection, no endpoint /exchange/interacao_add10.php o id do ticket provavelmente está sendo usado em algum momento para solicitar do backend as informações necessárias sobre ele, coloquei teste no lugar da hash mandei aquele CTRL+F para ver onde ele aparecia na página.
Jackpot! não só encontrei um Injection melhor, como encontrei um Injection que já está dentro de uma tag <script>!!!, isso é ótimo para ultrapassar o XSS Auditor, eu não preciso mais iniciar um <script> e finalizar com </script>, assim o bypass fica beeeem mais fácil.
Elaborei um script simples para teste, ele não faz nada malicioso, apenas uma mostra uma popup de mensagem no navegador, mas se a popup aparece então as possibilidades são infinitas...
Embuti o script na url da seguinte forma: /exchange/interacao_add10.php?h1='});alert(<texto aqui>);$.ajax({method:%27GET%27,url:%20%27json_interacoes.php
Voilá, conseguimos injetar com sucesso uma mensagem de alerta no site, qualquer um que acessar esse link também irá ver ela, mas não estamos muito interessados em espalhar mensagens de alerta por aí não é mesmo? É aqui que o hacker malvadão tem todas as ferramentas necessárias para um roubo massivo de criptomoedas.
Só um detalhe: ao clicar nesse link, aparece uma tela do Cloudfare, pedindo para eu clicar numa caixa de “eu não sou robô”. Ficou faltando preparar um script de bypass desse filtro também, mas no estado atual já está perfeitamente utilizável para um ataque, as pessoas tendem a clicar nessa caixa sem nem piscar, principalmente quando é contada uma boa história por trás.
Neste ponto a falha passou a ser crítica, acabei de descobrir que é possível criar um link que se as pessoas clicarem perdem todos os seus BTCs!
Corri para avisar a exchange e a resposta deles foi relativamente rápida, em poucos dias tudo se resolveu e o token também passou a ser aleatório de verdade. Que bom! Em troca ganhei só um muito obrigado deles, eles não gostaram muito da minha idéia de tornar as falhas públicas, mas esconder isso foge de todo o meu propósito de tornar o ambiente de criptomoedas brasileiro mais seguro.
Para o ataque em si já está quase tudo pronto, ele pode ser feito da seguinte forma: Criamos um script que solicita um saque pelo cliente e já confirma ele, com isso teremos o link bomba, podemos encurtar ele com o goo.gl ou outro serviço de diminuição de url.
Deste ponto em diante, o hacker malvadão passa a postar esse link em grupos, listas de email, sites sobre criptomoedas, comentários, uma verdadeira campanha de roubos instantâneos, todo mundo que clicar no link vai perder seu dinheiro.
Nem preciso dizer que esses últimos passos não foram tomados, evitando assim questionamentos legais, para mim basta ter encontrado a vulnerabilidade e avisado, ajudando assim na proteção dos clientes e ensinando que se você não investe em segurança, alguém investe por você, e isso nem sempre acaba com o final feliz de hoje.
Esse é um pouco antigo, mas para complementar melhor no blog irei publicá-la aqui também, onde ficarão todos os disclosures.
Começo de março detectei uma falha de segurança na Braziliex quando haviam requisições para o sistema de suporte sem hash identificadora do ticket, a seguinte requisição https://braziliex.com/exchange/interacao_add10.php?h1= acabava por retornar todas as mensagens de suporte dos usuário.
Esse erro ocorre pela forma em que são tratadas as requisições no MongoDB, caso haja a passagem de um id vazio no objeto ele acaba por retornar todos objetos que obedecem os critérios solicitados.
Dia 02/03/2018 realizei o aviso para que arrumassem o problema e fiquei impressionado com a velocidade que fizeram: em apenas 10 minutos!
Braziliex está de parabéns pela celeridade. Separei apenas tickets que não permitirão identificação de clientes como prova da falha; também removi toda informação que pudesse dar problema, publicados abaixo:
Vem surgindo muitos questionamentos a respeito dos meus estudos de segurança no mercado de criptoativos. O mais comum é de que estou trabalhando para algum concorrente em prol de difamar empresas, e esse é exatamente o oposto de minhas intenções.
Decidi escrever um mini-manifesto explicando minha visão de forma resumida, mini pois foi elaborado para ser publicado no facebook (ninguém lê textão). Segue:
O Brasil está no 7o lugar do mundo em crimes cibernéticos, mas é um dos países que menos investem em segurança de dados.
A grande consequência é um movimento natural do mercado em se criar analistas de segurança para o mal (black hats), aplica-se aqui a lei da oferta e procura pois é muito mais rentável roubar do que fazer o bem no Brasil.
Só se torna analista para o bem (white hat) quem possui um forte compasso moral. E mesmo assim, a pessoa ainda sofrerá perseguição das empresas que ajuda, ameaças e processos.
Ao mesmo tempo, programadores são formados para não ligarem para a segurança. O mercado incentiva a criação de profissionais que desenvolvam o máximo de funcionalidades no menor espaço de tempo, a clássica metodologia do "vai cavalo", depois se algo der errado é só botar a culpa no hacker ou no coitado do programador.
Criamos aqui uma receita para o desastre:
1- um país que persegue white hats
2- que não incentiva a preocupação com segurança na hora de desenvolver
3- voltado à filosofia do jeitinho Brasileiro
4- e que tem um ambiente propício para a impunidade dos verdadeiros criminosos
Nós da comunidade de criptomoedas estamos na vanguarda da tecnologia, e temos a OBRIGAÇÃO de reverter esse quadro, não estamos apenas lidando com dinheiro, o que por si só já é motivo suficiente, mas com o dinheiro do futuro.
É importantíssimo nesse momento que nosso mercado se auto-regule de forma a evitar incidentes como os que vimos no último ano, esses incidentes só farão com que os reguladores e juízes atuem cada vez mais na proibição das criptos, e tenham motivos de sobra para isso.
Deixando claro aqui, meu interesse não é financeiro e sim acadêmico, Satoshi Nakamoto não criou o Bitcoin pensando em lucro, até mesmo porquê os Bitcoins dele nunca foram movidos, quem faz software open-source e gratuito prioriza o caráter científico de suas pesquisas.
Este artigo é parte integrante de uma série de três artigos que serão publicados aqui, trata a respeito de uma investigação independente que fiz no mercado de criptomoedas como um todo, com foco em roubos recentes por Phishing que estavam ocorrendo na época de Março/2016 a Abril/2018 na Foxbit, bolsa brasileira de criptomoedas.
Uma implementação insuficiente na autenticação de dois fatores da Foxbit inutilizou tal modelo de segurança e abriu as portas para que hackers retirassem dinheiro das contas sem necessidade de confirmação da vítima.
Hackers de posse desse conhecimento criaram páginas falsas, simulando a da bolsa em questão e usaram o sistema de propagandas da Google para que essas páginas aparecessem no topo dos resultados (Exemplo na Imagem 2).
Uma vez capturada a senha das vítimas o sistema desenvolvido pelo hacker atuava de forma automática ou manual, explorando a falha para trocar a autenticação de dois fatores e subtraindo os seus saldos na forma de bitcoins, para uma carteira irrastreável.
As falhas no sistema da Foxbit aqui mencionadas permaneceram abertas e sendo exploradas por pelo menos 2 anos, desde Março/2016 até o final de Abril/2018.
2. Falhas de segurança observadas na Foxbit
Até o presente momento discutimos os ataques mais utilizados por hackers em todas as plataformas financeiras, de forma a comprometer contas individuais de clientes e roubá-los. Discutimos também quais são as implementações de segurança padrão no mercado de forma a proteger os clientes contra esses ataques.
O motivo em particular que me levou a essa investigação foi ter notado um aumento crescente de clientes da Foxbit reclamando de furtos a suas contas, é natural esperar que algumas pessoas tenham suas contas comprometidas em um sistema desse porte, mas a quantidade de pessoas sofrendo esses furtos passou do normal e continuava a crescer. Com a subida exponencial do preço do bitcoin, os ataques também cresceram exponencialmente.
Essa explosão de ataques me levou a desconfiar de que poderia haver algum erro com a implementação de segurança desta bolsa, até porque todas as pessoas encontradas reclamando afirmavam possuir a autenticação de dois fatores (2FA - Art2.2) ativada, o que significaria que suas contas deveriam ser as mais seguras.
De posse do conhecimento acima exposto comecei uma investigação independente do ocorrido, primeiramente conversando com pessoas roubadas e posteriormente fazendo perícia em suas máquinas para identificar porquê, quando, e como esses ataques ocorreram.
Ao estudar melhor os fatos, pude descobrir uma série de falhas de implementação na segurança da Foxbit que trouxeram à luz o ocorrido bem como a forma que os hackers se aproveitaram de todas ou algumas delas.
O código fonte da blinktrade é aberto ao público, se provando muito útil para descobrir regras de negócio e como elas afetam a segurança do cliente. Apesar de o código publicado ser antigo as regras de negócio não evoluíram muito, este encontra-se no seguinte endereço: https://github.com/blinktrade/
Adiante irei esclarecer algumas das falhas descobertas por mim, e ao final minhas conclusões sobre possíveis cenários de ataque em que ocorreram os furtos.
2.1. Reaproveitamento de 2FA
Para entender como funciona essa falha é necessário compreender o princípio da implementação do 2FA, discutido no artigo 2.2. Tal princípio é de que apenas o beneficiário e o serviço detém posse do segredo gerador de chaves, então um hacker de posse de uma chave gerada não seria capaz de fazer nada com o saldo pois não tem como prever a próxima chave e realizar a transação.
Para seguir isso é importante que a plataforma não permita o uso mais de uma vez da mesma chave, caso contrário o 2FA perde o propósito e se torna o mesmo que uma senha, uma vez o agente malicioso tendo uma chave ele pode usá-la para tudo dentro do prazo.
A plataforma da Foxbit porém, não pratica a invalidação de uma chave uma vez que é usada, permitindo que um hacker de posse apenas de uma chave tenha uma janela de 30 segundos para fazer saques ou quaisquer modificações que desejar na conta da vítima.
Note que 30 segundos é um prazo bastante curto, um humano utilizar-se desta falha torna-se bastante difícil, portanto essa falha deveria ser explorada por robôs. O ataque consiste em um hacker desenvolver um programa robô automatizado para realizar o saque da conta da vítima de forma praticamente instantânea quando esta digitar suas credenciais, seja em página de phishing ou por outros meios aqui discutidos.
2.2. Vulnerabilidade nos saques de Bitcoins
A regra de negócio da Blinktrade/Foxbit é extremamente vulnerável a qualquer ataque ao 2FA, isso acontece pois quando o cliente possui o 2FA ativo não é solicitada qualquer confirmação por e-mail ou outros meios de forma a realizar a transação, ela ocorre instantaneamente, o cliente recebe apenas um aviso pelo e-mail, e este pode acabar sendo visto tarde demais.
A confiança que a Foxbit colocou na implementação do sistema 2FA torna o peso sobre ele muito maior, se esse pilar cai, a segurança do cliente cai como um todo. Foi exatamente isso que ocorreu nos furtos como iremos demonstrar a seguir neste documento.
Imagem 19 - E-mail de aviso de saque de bitcoins da Foxbit, repare que não há confirmação (Art2.3) nem forma de cancelamento instantâneo (Art2.4)
Esta é a falha de segurança principal explorada nos casos de phishing estudados, de forma resumida além dela tornar o sistema de 2FA inútil, a falha facilita o trabalho do hacker, pois pode ser usada tanto para trancar o cliente fora de sua conta como permitir realização de saques sem e-mail de confirmação (Art2.3 e 2).
Estimo que ela vem sendo explorada livremente por hackers desde Julho/2017, porém o momento exato de início é difícil de estimar, logo podem haver casos anteriores a esses fora do meu conhecimento.
Imagem 20 - Explicação de como o 2FA deveria funcionar quando corretamente implementado, extraído do site da Foxbit.
O exemplo a seguir mostra o passo-a-passo de como essa falha pode ser explorada por um agente malicioso:
01 - De posse do e-mail e senha roubados pela página de phishing (ex: Imagem 3) entre com eles na página original da Foxbit
02 - Entre também com o código 2FA digitado pela vítima
03 - O atacante se encontra agora logado na conta da vítima, deste ponto ele pode seguir para sacar os bitcoins usando a falha 1 ou dar continuidade.
04 - Acesse a seção “Meu Perfil”
05 - Clique em desabilitar 2FA
05 - Vá em qualquer outra seção e volte em “Meu Perfil” para que o botão de habilitar 2FA apareça, clique nele.
06 - O hacker agora cadastra o 2FA em seu celular, preenche os dados e clica em “habilitar”, efetivamente sequestrando a conta da vítima.
07 - O ataque está completo, a vítima não conseguirá mais acessar a conta pois o 2FA está de posse do hacker, agora ele apenas precisa aguardar 24 horas e sacar todo o valor da conta, sem e-mail de confirmação (Art2.3 e 2)
Note que este ataque possui múltiplos usos, é importante que o hacker tranque a vítima fora de sua conta, assim ela não pode mais cancelar a transação. É igualmente importante que o hacker mantenha o 2FA ativado pois pode realizar o saque após 24 horas.
Se a vítima digitar o 2FA mais de uma vez na página de phishing o saque poderá ser feito na hora e essa falha é usada para impedir o cancelamento da transação(Art2.2); se o atacante criar um robô de ataque automatizado (1) o saque poderá ser feito na hora também; se o atacante não conseguir outro 2FA e não queira criar um robô de ataque automatizado ele só precisa esperar 24 horas para o saque, dificilmente o cliente irá notar que está trancado fora da conta e se notar, dificilmente o suporte da foxbit poderá responder em tempo hábil.
A seguir detalharei mais a fundo como essa falha afeta a segurança dos usuários.
2.4. Supressão do e-mail de confirmação
Conforme vimos na seção 2 a vítima não precisa confirmar através de e-mail nenhum saque que seja realizado enquanto o 2FA estiver ativo. Ao manter o 2FA ativo o hacker consegue pular esse passo na validação da transação.
Tal supressão é importantíssima, principalmente para phishing, pois a menos que o cliente reuse a senha do e-mail na bolsa em questão, o atacante não terá como invadir o e-mail da pessoa o que seria um impeditivo para o ataque.
2.5. Evitando o cancelamento da transação indevida
Esse ataque possibilita que o hacker tome posse da conta da vítima, efetivamente trancando ela de qualquer acesso à plataforma da Foxbit.
Como pudemos observar na Imagem 19, a Foxbit não fornece a funcionalidade de cancelamento instantâneo (Art2.2). A única forma de cancelar a transação que a vítima tem é acessando a plataforma e realizando o cancelamento manual, como o hacker trancou a vítima fora da conta isso fica impossível de ser feito em tempo hábil.
Os saques na Foxbit ocorrem de 5 em 5 minutos, o cliente precisaria acessar a plataforma digitando login senha e 2FA, ir em saques e cancelar o saque indevido nesse espaço de tempo. Somente é possível cancelar o saque, não é possível realizar bloqueio total da conta, então mesmo que a vítima o consiga, o hacker ainda pode solicitar mais saques.
3. Aviso de falha feito à Foxbit
Uma vez descoberta a falha 3 realizei a informação para a Foxbit, à luz do processo de responsible disclosure usado por pesquisadores de segurança. No dia 29/04/2018 enviei 2 e-mails, 1 mensagem no sistema de suporte e 1 mensagem via facebook.
As informações foram idênticas entre os 4 avisos e tiveram a forma seguinte:
Imagem 21 - Email com relatório da falha de segurança, enviado para a Foxbit em 29/03/2018.
O prazo que estimei para correção da falha foi em torno de 10 dias, porém após longo
silêncio, no dia 12/04, fui contactado pela Foxbit e Blinktrade, a última sendo a
responsável pelo desenvolvimento do sistema da Foxbit, esta solicitou um aumento no
prazo de mais 7 dias.
A solução por mim proposta foi a seguinte:
Solicitar a confirmação por e-mail para todos os saques, independente do 2FA
ativo (4.2).
Invalidar a chave 2FA depois de usada, fazendo com que somente a próxima
chave seja aceita (4.1).
Realizar a confirmação por e-mail também para ativar o 2FA (4.3).
A correção no entanto foi posta em produção pela Foxbit no dia 23/04, 25 dias após o
aviso, atualmente o sistema passou a solicitar e-mail de confirmação em todas as
transações (3.3) bem como confirmação por e-mail para realizar o login em um
navegador novo (3.5).
4. Conclusão
Imagem 22 - Pagina de phishing foxbits.exchange em ação, layout idêntico à original.
Imagem 23 - Ao digitar o 2FA a página retorna um erro para convencer a vítima a digitar os próximos códigos, mesmo que ela não digite, o hacker tem recursos suficientes para furtá-la.
Segundo os casos estudados e as falhas de segurança da Foxbit elucidadas acima pudemos chegar a uma conclusão de como devem ter sido realizados os phishings, nos levando aos seguintes cenários:
Cenário 1:
Hacker cria uma página idêntica a da Foxbit e registra um domínio de nome parecido (Imagem 3 - Art.1).
Contrata o serviço de propagandas da Google, AdWords, para aparecer no topo dos resultados em pesquisas (Imagem 2 - Art1).
Vítima cai na página falsa, acreditando estar lidando com a Foxbit digita suas credenciais e apenas um código 2FA.
Hacker explora a falha exposta em 2.3 e tranca a vítima fora de sua conta.
Após 24 horas o hacker troca todos os reais por bitcoins e retira todo o dinheiro da vítima para uma carteira irrastreável.
Cenário 2:
Hacker cria uma página idêntica a da Foxbit com um sistema automatizado de furto, registra um domínio de nome parecido (Imagem 3 - Art.1).
Contrata o serviço de propagandas da Google, AdWords, para aparecer no topo dos resultados em pesquisas (Imagem 2 - Art-1).
Vítima cai na página falsa, acreditando estar lidando com a Foxbit digita suas credenciais e apenas um código 2FA.
Sistema automático de furto explora a falha exposta em 1 e realiza o saque do saldo da vítima.
Sistema automático explora a falha exposta em 2.3 de forma a trancar a vítima fora de sua conta e impedir o cancelamento.
Cenário 3:
Hacker cria uma página idêntica a da Foxbit e registra um domínio de nome parecido (Imagem 3 - Art.1).
Contrata o serviço de propagandas da Google, AdWords, para aparecer no topo dos resultados em pesquisas (Imagem 2 Art.1).
Vítima cai na página falsa, acreditando estar lidando com a Foxbit digita suas credenciais e mais de um código 2FA.
Hacker utiliza os códigos 2FA posteriores para realizar o saque da conta da vítima sem e-mail de confirmação (2.2).
Hacker explora a falha exposta em 2.3 de forma a trancar a vítima fora de sua conta e impedir o cancelamento.
Os casos de furto por mim estudados todos apresentam características do cenário 1 e 3, não encontrei casos que explorem o cenário 2 até o momento apesar de ser uma possibilidade.
É importante frisar que o modelo de segurança 2FA na implementação atual da Foxbit tornava as contas dos clientes mais inseguras, deixando as vítimas indefesas mesmo se houvesse tempo hábil para reagir e cancelar as transações indevidas. Algo que foge ao propósito do 2FA elucidado na Imagem 18 pela bolsa. Os Hackers na realidade usaram ele como um mecanismo para facilitar os furtos.
É necessário que, para fins de auditoria, uma plataforma com características financeiras mantenha registros (logs) de todas as ações que são feitas pelos clientes dentro delas. Uma pessoa de fora do círculo não tem como saber se eles são de fato mantidos, mas supondo-se que tenham, significaria que ao longo de pelo menos 10 meses a Foxbit/Blinktrade tiveram conhecimento de como eram feitas essas invasões ou possuíam recursos suficientes para ter esse conhecimento.
5. Agradecimentos
Este relatório não seria possível sem a ajuda da comunidade, foram diversas pessoas entrevistadas e algumas dessas permitiram a realização de perícia por mim em suas máquinas.
Agradeço aqui pela solicitude de:
Evando de Oliveira
Mariano Portela
Cézar Ribeiro
Demais pessoas que não quiseram ser identificadas
Agradeço também o apoio jurídico dos advogados:
Dr. Boaz Bezerra
Dr. Bruno Cardoso
Muitas das informações constantes aqui foram obtidas em:
Este artigo é parte integrante de uma série de três artigos que serão publicados aqui, trata a respeito de uma investigação independente que fiz no mercado de criptomoedas como um todo, com foco em roubos recentes por Phishing que estavam ocorrendo na época de Março/2016 a Abril/2018 na Foxbit, bolsa brasileira de criptomoedas.
Vimos que existem diversas formas de se roubar senhas de um usuário, algumas quase impossíveis de se detectar. A popularização da informática trouxe muitos usuários inexperientes ao mundo da tecnologia, que são presas fáceis para os hackers usando os ataques aqui discutidos. Com isso a demanda por soluções seguras para garantir o controle de emails, contas de redes sociais, e mais importante instituições financeiras garantindo o acesso somente pelo beneficiário, cresceu muito.
Todo tipo de serviço hoje na internet tem que partir do pressuposto de que seu cliente é inexperiente e pode estar sofrendo um ataque neste exato momento, com isso foram criadas diferentes formas de se evitar a maioria deles, grande parte das soluções foram originadas no mercado financeiro, as quais discutiremos a seguir.
1. Prova de autenticidade
Provavelmente uma das implementações mais simples de segurança existentes no mercado é a prova de autenticidade, ela protege tanto contra phishing como man-in-the-middle e é tão simples que um programador sênior pode ser desenvolver ela em minutos.
Imagem 6 - Exemplo de prova de autenticidade usada pela Walltime, as cores serão sempre as mesmas quando acessada a partir da mesma máquina.
O princípio desta prova de autenticidade é criar uma camada a mais de segurança. Antes mesmo do login o serviço compartilha um segredo com o cliente que apenas eles sabem, desta forma se houver alguma informação divergente o cliente já fica em estado de alerta e evita digitar a senha por receio de ser roubado.
Apesar de simples a prova de autenticidade é uma forma poderosa de impedir que pessoas digitem senhas em páginas falsas criadas por phishing ou man-in-the-middle, é recomendado que esta prova venha acompanhada de outras medidas de segurança.
Imagem 7 - Prova de autenticidade do Mercado Bitcoin, o cliente cadastra uma palavra segredo que aparece em todas as páginas.
O maior exemplo de prova de autenticidade ocorre quando acessamos o internet banking de instituições financeiras, nestas é comum darem o nome do cliente antes de permiti-lo usar a senha, como o hacker não tem como saber o nome da pessoa de antemão isso já cria um alerta para o usuário de que ele pode estar sendo enganado.
Imagem 8 - Prova de autenticidade do Banco Itaú, ele afirma o nome do cliente antes dele digitar a senha de forma que ele possa desconfiar de um ataque caso o nome esteja errado ou não esteja presente.
Imagem 9- Prova de autenticidade do Banco Inter, assim como o Itaú ele informa o nome antes da senha.
Vale se atentar que a prova de autenticidade apesar de útil não é uma solução perfeita, pois o hacker pode programar um robô para acessar o mesmo site e copiar o nome da pessoa ou segredo. Apesar disso ela adiciona uma camada de dificuldade aos hackers uma vez que teriam que desenvolver um sistema de phishing mais avançado e isso dificulta e desestimula a fraude.
Como citado anteriormente a implementação da prova de autenticidade é bastante simples e é recomendado sempre ser utilizada em sistemas sensíveis, pois adiciona uma camada a mais de segurança, porém não deve ser utilizada sozinha.
2. Autenticação de dois fatores - 2FA
Essa talvez seja a melhor solução encontrada pelo mercado financeiro para evitar os ataques citados na segunda seção. A autenticação de dois fatores, também conhecida como 2FA (do inglês Two Factor Authentication) faz uso de um segredo que apenas você e seu banco possuem.
Imagem 10 - Token 2FA como era fornecido antigamente por bancos, desta forma era garantido que apenas o cliente saberia da chave gerada em determinado momento.
Um dos focos principais deste documento será como o 2FA, quando implementado corretamente, tem como dar garantia para o cliente de posse da sua conta a partir da posse do token.
O motivo do nome autenticação de dois fatores é porquê ele fatora a forma com que é feita a autenticação do cliente, a senha passa a não ser o fator mais importante para o uso da conta pelo beneficiário. Cada transação realizada na instituição financeira pela internet passa a exigir um código gerado pelo token na hora de sua execução.
Como apenas o cliente e o banco possuem posse do segredo gerador de números (chaves) a instituição tem como garantir a validade da transação com a mesma qualidade de quando o beneficiário está presente. O Banco possui em seu sistema um gerador de chaves eletrônico análogo ao do cliente e o cliente através do aparelho também tem posse física desse gerador.
Com a popularização dos smartphones foram desenvolvidas novas soluções no mercado que fazem uso destes e reduzem custos de operação, mas desta forma como se pode garantir que apenas o beneficiário saiba o segredo gerador?
Imagem 11 - Solução 2FA do Banco do Brasil, o BB Code, além de garantir segurança para a transação garante que o cliente esteja ciente da transação sendo realizada com a chave.
Note que agora o cliente estará usando seu smartphone pessoal para confirmar as transações, como ele não mais estará recebendo um aparelho de seu gerente é necessário muito cuidado no fornecimento deste segredo pois ele só pode ser fornecido para o beneficiário.
Para garantir isso os bancos usam uma combinação de internet banking com caixas eletrônicos, o cliente recebe parte do segredo via internet gravando em seu celular e posteriormente recebe a outra metade no caixa eletrônico após inserir seu cartão, impressão digital e uma série de respostas a perguntas pessoais. Desta forma ele tem como garantir que a pessoa por trás do celular é a mesma que fez a conta. Em certos casos uma foto é retirada em conjunto para confirmar a posse do segredo em casos de fraude.
Caso o cliente venha a perder seu celular, a pessoa que adquiriu nada pode fazer pois não sabe a senha, caso o cliente perca a senha, o invasor nada pode fazer sem ter posse do celular do cliente.
Em caso de perdas do aparelho o serviço financeiro precisa fornecer uma forma para o cliente trocar o segredo gerador. É de extrema importância que essa troca seja feita de forma segura, garantindo a identidade do cliente ao fazê-lo. Tal garantia é tão importante quanto no primeiro fornecimento pois se for oferecido uma forma de troca sem o mesmo rigor nas verificações de identidade a instituição estará abrindo a porta para hackers.
Imagem 12 - Aplicativo Authy, usando o protocolo de 2FA do Google Authenticator, tem sido o mais adotado atualmente no mercado de criptomoedas.
A implementação deste modelo de autenticação varia de moderada a complexa, para que haja a proteção contra ataques é preciso ter meios de garantir seu uso apenas pelo cliente e é preciso verificações adicionais de identidade, mas quando bem implementado é uma ferramenta forte contra roubo de contas.
Em questão de pouco tempo outros sistemas não financeiros começaram a adotar o token 2FA para aumentar a segurança dos usuários, redes sociais como Facebook ou Twitter, serviços de e-mail como o Gmail e até sistemas de armazenamento em nuvem e backups. A grande diferença desses sistemas é que eles não realizam transações que precisam de 2FA então ele serve apenas como barreira de defesa suplementar na hora do login, não é a mesma segurança que os padrões do mercado financeiro mas adiciona uma dificuldade a mais para os hackers.
3. E-mail de confirmação
Essa é uma forma simples e bastante poderosa de criar um bloqueio contra hackers, para cada transação é exigida uma confirmação enviada para o email do cliente.
O funcionamento desta solução é bem similar ao 2FA discutido anteriormente, porém com um adicional, o email enviado ao cliente deve conter um link para a página original da empresa. Desta forma mesmo que o cliente tenha sido atingido por um phishing ele irá se salvar ao clicar no link, pois será direcionado ao endereço correto da instituição financeira.
Normalmente usa-se um link com uma chave aleatória que representa somente aquela transação solicitada pelo cliente, o cliente então só consegue executar a transação se clicar no e-mail, ler a página com a transação e confirmar ela.
Imagem 13 - Email de autorização da transação do Mercado Bitcoin, repare que ele contém um link para dar prosseguimento ao pedido.
Imagem 14 - Email de confirmação de transação da Braziliex.
Note que a presença de links “https”, ou seja, com criptografia, é importante para evitar ataques man-in-the-middle, uma vez que o cliente poderá ver um alerta ao entrar na página caso ela seja falsificada por este ataque.
Ao exigir um email de confirmação, a plataforma financeira em questão se torna muito mais segura contra phishing, além de aumentar a segurança dos clientes contra man-in-the-middle, este tipo de técnica vem sido amplamente utilizada no mercado de criptomoedas e se tornou um padrão de mercado.
Uma vez adotada esta medida o agente malicioso terá que invadir a conta do cliente na plataforma bem como seu e-mail, sendo assim a real vulnerabilidade fica reduzida a clientes que possuem a mesma senha em seu email, sem 2FA, e na plataforma ao mesmo tempo.
3.4. Cancelamento instantâneo da transação
O cancelamento instantâneo funciona de uma forma muito similar ao email de confirmação, logo é comum que essas medidas sejam oferecidas em conjunto. Ela consiste em oferecer ao cliente uma forma de congelar tanto a transação a ser realizada como sua conta de forma imediata.
Imagem 15 - Exemplo de cancelamento instantâneo oferecido pelo Banco do Brasil, basta apenas uma mensagem SMS e a transação, bem como o cartão, serão bloqueados.
A simplicidade de implementação é a mesma do email de confirmação, é aconselhável para situações emergenciais em que o usuário foi trancado fora de sua conta e de outra forma não teria como cancelar a transação realizada pelo hacker, ela tem sido frequentemente utilizada no mercado financeiro de criptomoedas no exterior.
Imagem 16 - Email de confirmação da Bitstamp, bolsa européia de criptomoedas, note que além do link de confirmação é fornecido um link para congelamento da conta em caso de acesso indevido.
Note que é importante que o cancelamento da transação seja feito de forma instantânea, muitas bolsas oferecem o cancelamento apenas após o login do cliente, esta implementação é incorreta, pois nestes casos bastaria o hacker trocar a senha ou usar outro método para trancá-lo fora da conta, ficando a vítima impossibilitada de agir.
5. Validação de navegador novo
Navegadores podem ser identificados pelo serviço que acessam, através de uma espécie de impressão digital. Características únicas são enviadas para o serviço toda vez que ele é acessado, entre essas características o endereço de IP do usuário.
Vimos na imagem 6 que a Walltime implementa essa impressão digital de forma a criar uma imagem que o cliente pode memorizar para saber se está lidando com a página correta.
Essa informação pode ser usada por plataformas financeiras para saberem que estão lidando com a mesma pessoa que lidaram outras vezes. A solução não é perfeita, pois o IP do cliente ou o ambiente que usa pode mudar com o tempo. Porém é possível criar uma forma para o cliente cadastrar impressões digitais novas como se fossem dele, usando as técnicas de validação explicadas anteriormente como e-mail de confirmação (3) e 2FA (2).
Imagem 17 - Email de cadastro e confirmação de login por IP novo usado na Bittrex, bolsa internacional de criptomoedas.
Apesar de adicionar mais uma camada na segurança a maioria dos dados enviados pelo navegador podem ser forjados pelo atacante. Deixando o endereço IP como uma das únicas garantias na identificação.
Desta forma é fornecida uma forte proteção contra phishing (1.1) porém não há proteção contra man-in-the-middle (1.2) ou malwares (1.3) uma vez que eles permitem o uso do mesmo ip do cliente, como em casos por exemplo de invasão do roteador do cliente.
6. Anti-Malwares Personalizados
Existem hoje no mercado diversas soluções de antivírus que protegem contra malwares ou até mesmo man-in-the-middle, mas eles realizam a proteção de uma forma mais genérica e abrangente, para que a plataforma financeira garanta a proteção de seus clientes se faz necessário o uso de uma solução própria, com foco a ataques contra ela.
Este tipo de proteção é extremamente complexa e avançada, mas existem empresas terceiras que possuem soluções próprias e que pode ser personalizada para cada plataforma. Dado a complexidade dela no entanto o custo pode ser alto.
Imagem 16 - Instalação do Warsaw, solução da GAS Tecnologia e Diebold Nixdorf, usada em plataformas bancárias
A idéia por trás dessa solução é ter um software rodando continuamente na máquina do cliente, capaz de detectar malwares que possam furtar suas credenciais bancárias.
Além da proteção contra malware esse software pode prover anti-phishing, fazendo a autenticação criptográfica da plataforma que o cliente está se conectando e bloqueando acessos indevidos em uma lista negra de páginas não permitidas.
“A finalidade é impedir que o usuário interaja com páginas falsas e também que softwares maliciosos atuem nos sistemas protegidos pela solução. No momento em que é identificada uma página falsa, via lista negra de sites falsos conhecidos ou inteligência artificial sofisticada, técnicas variadas são utilizadas para proteger o usuário contra o roubo de suas informações.
Um grande diferencial é a utilização de um conjunto de regras e métodos avançados conhecido por heurística para identificação de sites maliciosos não conhecidos. Isso é essencial, já que inúmeros novos sites falsos são desenvolvidos diariamente, sendo necessária esta técnica para conseguir inviabilizá-los.” - Fonte: http://www.dieboldnixdorf.com.br/gas-antifraude.
Para a terceira parte, com a falha descoberta acesse aqui:
