Em respeito aos nossos afiliados e à própria história que construímos juntos, voltamos a todos vocês com mais informações sobre o processo implantado este ano para a realização dos pagamentos.

Desde a criação do MinerID até o anúncio oficial do plano, em fevereiro - que previa quitação em até 24 meses do saldo, de acordo com a opção escolhida - a Minerworld não poupou esforços para realizar os pagamentos.

Seja por meio de palestras, mensagens, comunicados oficiais ou mesmo respostas à imprensa, a Min-erworld nunca escondeu os problemas enfrentados em uma plataforma internacional de compra e venda de criptomoedas desde o fim de outubro de 2017, causa principal dos atrasos. Até então, cabe ressaltar, jamais tivemos problemas dessa natureza em toda a nossa história.

Desde outubro do ano passado, a Minerworld não poupou esforços para resgatar os bitcoins bloquea-dos na referida plataforma. E se comprometeu, por orientação de nossos advogados, para o melhor andamento dos procedimentos, a não informar mais detalhes publicamente sobre o caso. Agora, pas-sados mais de 5 meses do ocorrido, e ainda sem uma solução definitiva, cumpre-nos prestar a todos os seguintes esclarecimentos:

• No dia 29 de outubro de 2017 recebemos do responsável pela área de trading da empresa a informação de que houve uma fraude na página da Poloniex, exchange norte-americana até então considerada uma das maiores e mais confiáveis do mundo;• Ao consultar nosso saldo, verificamos na ocasião a transferência criminosa de 851 bitcoins de nossa conta para diversas outras contas de terceiros dentro da plataforma, que valeriam no câmbio do dia 16 de dezembro de 2017 cerca de US$ 16.300.000,00 (dezesseis milhões e trezentos mil dólares);• Em contato com a plataforma, fomos informados de que nossa conta havia sido bloqueada para análise interna em razão da suspeita de fraude. Para melhor compreensão dos fatos: os hackers duplicaram a página da empresa e muitos usuários, além de nós, tiveram suas aplicações desviadas internamente na plataforma;• Imediatamente, a Minerworld acionou seus advogados no Brasil e constituiu advogados nos Estados Unidos na tentativa de reverter a situação com a maior brevidade possível;• Ao mesmo tempo, a empresa contratou profissionais para uma análise detalhada sobre o caso, no sentido de auxiliar na solução do problema;• Infelizmente, até o momento, a Minerworld não recebeu oficialmente qualquer informação sobre a data de devolução dos bitcoins bloqueados.

INFORMAÇÕES DETALHADAS SOBRE O CASO PODEM SER CONFERIDAS NO LAUDO PERICIAL EM ANEXO (Anexo I – Parecer Técnico: Ataque Phishing Poloniex).

Reiteramos que não foram poupados esforços no sentido de pagar a todos os afiliados por meio de fontes próprias de recursos e pela entrada de um grupo internacional de investidores que pretendiam compor o quadro societário da empresa - negociação que até esta data não foi concluída.

No dia 29 de março de 2018, o CEO Jonhnes Carvalho atendeu um grupo de líderes que possuem em sua rede, de forma direta ou indireta, aproximadamente 20 mil afiliados. Na ocasião, foram expostas pelo grupo as principais inquietações da rede, principalmente no que se refere ao cumprimento do plano de pagamento apresentado pela empresa.

Levando em consideração todas as informações aqui colocadas e em respeito a todas as pessoas que acreditam na Minerworld, foi definida em reunião de diretoria uma nova postura de total transparência em relação à crise financeira enfrentada pela empresa, que envolve:

• Divulgação de todo o ativo construído pelo empresa juntamente com seus afiliados, até out-ubro de 2017. Consideradas as máquinas adquiridas, mineradora construída e o patrimônio em bitcoins bloqueados conforme os fatos acima descritos. *A empresa divulgará, de modo oficial, até o dia 5 de abril de 2018, a relação de ativos;• A divulgação mensal de relatório de produção dos ativos acima mencionados.

Em virtude da já citada crise financeira da empresa e da impossibilidade de honrar os compromissos firmados no plano de pagamento, mudaremos a sistemática nos seguintes termos:

• Parametrização do sistema de pagamento, que a partir de agora será realizado de forma pro-porcional. Ou seja, cada afiliado receberá de acordo com o percentual que seu crédito no MinerID rep-resenta no passivo total da empresa, considerando a capacidade de produção dos ativos acima men-cionados. Exemplo: O afiliado X possui um crédito de US$ 1.000,00 (mil dólares) em sua conta do MinerID, que representa 0,1% do passivo total da empresa no MinerId. Tomando como exemplo que a produção mensal de todos os ativos acima mencionados seja de US$ 400.000,00 (quatrocentos mil dólares), o afiliado X receberá US$ 400,00 (quatrocentos dólares americanos), que representam 0,1% da produção dos ativos da empresa acima mencionados, até o total adimplemento do saldo devedor no MinerID.

REITERAMOS QUE COM O DESBLOQUEIO DOS BITCOINS A EMPRESA DESTINARÁ OS ATIVOS PARA PAGAMENTO DO PASSIVO EXISTENTE NO MINERID.

Seguiremos obstinadamente usando de todos os nossos recursos para reaver os ativos bloqueados. Ao longo desse processo, manteremos uma comunicação próxima, direta e eficaz.

IMPORTANTE: esse fato não compromete, em absoluto, os afiliados já cadastrados na plataforma Miner360, na qual os pagamentos seguem e seguirão normalmente. Da mesma forma, importante ressaltar que obtivemos pleno êxito com o lançamento mundial da MCash, assim como da mais nova plataforma para compra e venda do criptoativo – a M360.exchange.

Como sempre, continuaremos trabalhando incessantemente para alcançar o objetivo de todos os nossos afiliados, vencermos esta crise e construirmos uma Miner muito maior! Estamos certos de que as adversidades nos fortalecem e criam novos horizontes de negócio.

A Direção | Minerworld

ANEXO I – PARECER TÉCNICO: ATAQUE PHISHING POLONIEX

ESCOLA POLITÉCNICA DA UNIVERSIDADE DE SÃO PAULO

Departamento de Engenharia de Computação e Sistemas Digitais

Parecer Técnico:

Phishing da Poloniex Versão 1.0 – 20/Dezembro/2017

Prof. Dr. Marcos A. Simplicio Jr.

mjunior@larc.usp.br

Sumário 1. Introdução ............................................................................................................................................. 3

2. Descrição da fraude: phishing via homógrafos ..................................................................................... 3

3. Análise do incidente (pré-ataque): falha de segurança no processo de registro de domínios na

CloudFlare ..................................................................................................................................................... 8

4. Análise do incidente (durante ataque): provável redirecionamento equivocado ................................ 9

5. Análise do incidente (pós-ataque): processos falhos de autenticação e bloqueio da Poloniex ......... 11

6. Conclusões .......................................................................................................................................... 13

7. Referências .......................................................................................................................................... 14

1. Introdução

Este documento refere-se à invasão da conta exchange@minerworld.com.br cadastrada junto à

empresa Poloniex, uma plataforma para compra e venda de moedas digitais. Esse incidente ocorreu em

29/Outubro/2017, conforme informações fornecidas pelo dono da conta em questão, após o acesso e

fornecimento de credenciais de autenticação a uma página de phishing que, esteticamente, era

praticamente idêntico ao site real da Poloniex. Isso permitiu ao invasor realizar uma série de transações

de compra e venda na carteira digital da vítima, reduzindo rapidamente seu saldo a uma parcela ínfima

do original. Direta ou indiretamente, o caso também envolveu a CloudFlare, empresa que oferece

serviços de distribuição de conteúdo e proteção contra ataques de negação de serviço (Denial of Service

-- DoS), e que atua como intermediária no acesso à Poloniex via Internet.

Dado esse contexto, o presente parecer tem como objetivo mostrar que os eventos que possibilitaram

essa invasão não podem ser creditados a um mero descuido do usuário, mas potencialmente

envolveram falhas de segurança que poderiam ter sido sanadas (ou ao menos evitadas) por meio de

políticas de segurança mais robustas da Poloniex e da Cloudflare. A argumentação apresentada tem

caráter técnico, tomando como base os documentos e relatos da vítima e também informações de

domínio público, devidamente referenciadas quando pertinente.

O restante deste documento está organizado da seguinte forma. A Seção 2 descreve o tipo de ataque

que possibilitou a fraude (phishing via páginas homógrafas). Em seguida, são discutidas potenciais falhas

de segurança que permitiram que o ataque se concretizasse, antes (Seção 3), durante (Seção 4) e após

(Seção 5) o acesso do usuário à página fraudulenta. A Seção 6 apresenta as conclusões do trabalho com

base nas observações realizadas. A Seção 7 lista as referências mencionadas ao longo do documento.

2. Descrição da fraude: phishing via homógrafos

De uma forma geral, ataques conhecidos como "phishing" podem ser definidos como um "tipo de

fraude por meio da qual um golpista tenta obter dados pessoais e financeiros de um usuário, pela

utilização combinada de meios técnicos e engenharia social" [1]. Um exemplo comum é o envio de

mensagens por e-mail contendo links para páginas que, embora falsas, imitam a página real com o

objetivo de roubar credenciais de acesso das vítimas (e.g., senhas ou números de cartão de crédito).

Para evitar esse tipo de fraude, existem diversas recomendações de segurança, como aquelas descritas

na Cartilha de Segurança para Internet do Centro de Estudos, Resposta e Tratamento de Incidentes de

Segurança no Brasil (CERT.br) [1]. Os itens referentes a phishing dessa cartilha, projetada para servir

como um guia para usuários da Internet em geral, são reproduzidos no Quadro 1.

Quadro 1 - Recomendações de segurança anti-phishing do Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil (CERT.br) [1]

A. Fique atento a mensagens, recebidas em nome de alguma instituição, que tentem induzi-lo a fornecer informações, instalar/executar programas ou clicar em links;

B. Questione-se por que instituições com as quais você não tem contato estão lhe enviando mensagens, como se houvesse alguma relação prévia entre vocês (por exemplo, se você não tem conta em um

determinado banco, não há porque recadastrar dados ou atualizar módulos de segurança); C. Fique atento a mensagens que apelem demasiadamente pela sua atenção e que, de alguma forma, o

ameacem caso você não execute os procedimentos descritos; D. Não considere que uma mensagem é confiável com base na confiança que você deposita em seu

remetente, pois ela pode ter sido enviada de contas invadidas, de perfis falsos ou pode ter sido forjada (mais detalhes na Seção 3.3 do Capítulo Ataques na Internet);

E. Seja cuidadoso ao acessar links. Procure digitar o endereço diretamente no navegador Web; F. Verifique o link apresentado na mensagem. Golpistas costumam usar técnicas para ofuscar o link real

para o phishing. Ao posicionar o mouse sobre o link, muitas vezes é possível ver o endereço real da página falsa ou código malicioso;

G. Utilize mecanismos de segurança, como programas antimalware, firewall pessoal e filtros antiphishing (mais detalhes no Capítulo Mecanismos de segurança);

H. Verifique se a página utiliza conexão segura. Sites de comércio eletrônico ou Internet Banking confiáveis sempre utilizam conexões seguras quando dados sensíveis são solicitados (mais detalhes na Seção 10.1.1 do Capítulo Uso seguro da Internet);

I. Verifique as informações mostradas no certificado. Caso a página falsa utilize conexão segura, um novo certificado será apresentado e, possivelmente, o endereço mostrado no navegador Web será diferente do endereço correspondente ao site verdadeiro (mais detalhes na Seção 10.1.2 do Capítulo Uso seguro da Internet);

J. Acesse a página da instituição que supostamente enviou a mensagem e procure por informações (você vai observar que não faz parte da política da maioria das empresas o envio de mensagens, de forma indiscriminada, para os seus usuários).

Embora a definição de phishing e as recomendações de segurança do CERT.br possam à primeira vista

levar à impressão de que apenas usuários incautos seriam vítimas desse tipo de ataque, a realidade

atual não é tão simples. Afinal, fraudadores têm usado técnicas cada vez mais sofisticadas, capazes de

enganar até mesmo usuários bastante cautelosos. Um exemplo de estratégia de phishing bastante

engenhosa é aquela explora o crescente suporte que navegadores da Internet têm dado a caracteres

não latinos, incluindo símbolos visualmente bastante semelhantes aos latinos [2][3]. Isso permite a

construção de domínios como "https://www.аррІе.com", que embora pareça idêntico a

"https://www.apple.com", foi aqui escrito com os caracteres cirílicos "A", "Er", "Er", "Palochka" e "Ie"

(em Unicode1: 0x0430, 0x0440, 0x0440, 0x0406, 0x0435) em vez dos caracteres latinos "a", "p", "p", "l"

e "e" (em Unicode: 0x61, 0x70, 0x70, 0x6C, 0x65). Esse tipo de ataque baseado em homógrafos [4], que

ganhou as páginas do jornal The Guardian em Abril/2017 [5], é bastante difícil de detecção por

humanos, mesmo que sejam seguidas diversas recomendações de segurança.

No caso em questão, a técnica utilizada foi basicamente a mesma descrita acima. A única diferença foi

que o domínio "https://www.poloniex.com" foi imitado pelo domínio "https://www.poloṇiex.com",

substituindo-se a letra latina "n" (em Unicode: 0x6E) pelo caractere "ṇ" (em Unicode: 0x1E47), que

corresponde a um "n" com um ponto abaixo dele. A página web correspondente é mostrada na captura

de tela na Figura 1.

1 Unicode é um padrão internacional que permite aos computadores representar e manipular, de forma

consistente e sem ambiguidades, caracteres de qualquer sistema de escrita do mundo.

Figura 1 - Site falso da Poloniex, com endereço usando o caractere "ṇ" no lugar do "n". (Nota: imagem fornecida pela vítima)

Nesse cenário, até mesmo um usuário cauteloso, que seguisse a grande maioria das recomendações da

cartilha do CERT.br contra phishing, ainda teria grandes chances de ser vítima de uma fraude dessa

natureza. Mais precisamente, mesmo seguindo todas as recomendações listadas no Quadro 1 com

exceção do item I, ainda assim a fraude seria possível:

A vítima alega ter digitado manualmente o endereço no seu navegador, seguindo o que dita a

recomendação E.

Conforme mostrado na Figura 2, foi estabelecida uma conexão segura com o site falso, de modo

que a recomendação H também foi satisfeita.

As recomendações A, B, C, D e J dizem respeito a cenários em que o alvo recebe uma

mensagem falsa e clica em um link lá apresentado. Portanto, além de não se aplicarem ao

procedimento adotado pela vítima, ainda se não fosse esse o caso tais recomendações teriam

pouco ou nenhum efeito no cenário em questão. A razão é que a vítima era usuário da Poloniex

há algum tempo e interagia com o site a empresa, de modo que não seria incomum receber

uma mensagem da mesma.

Também não teria efeito a recomendação G no caso em questão, pois aparentemente o site de

phishing ainda não havia sido reportado como tal à época do incidente -- afinal, a CloudFlare

explica em [6] que, quando um site é suspeito de phishing, tentativas de acesso ao mesmo

levam à apresentação de uma página de alerta ao usuário. Logo, como a própria CloudFlare,

ferramentas anti-phishing instaladas na máquina do usuário dificilmente detectariam a fraude.

Já a recomendação F seria potencialmente útil se a vítima tivesse recebido uma mensagem

falsa, pois nesse caso o usuário poderia colocar o mouse sobre o link na mensagem e o

navegador (Google Chrome, versão 61) mostraria a representação ASCII2 do endereço na base

da página, no formato conhecido como Punycode [3][7]. Especificamente, deveria ser exibido o

endereço "https://xn--poloiex-s13c.com", o mesmo presente no certificado mostrado na Figura

2, permitindo à vítima perceber que algo estaria errado . Entretanto, tal recomendação

novamente não se aplica quando o usuário digita o endereço diretamente no navegador.

Figura 2 - Certificado digital apresentado pelo site falso da Poloniex, com o nome sendo exibido em sua representação ASCII. (Nota: imagem fornecida pela vítima)

2 ASCII (do inglês American Standard Code for Information Interchange, ou "Código Padrão Americano para Troca

de Informações") permite aos computadores representar um conjunto limitado de caracteres, incluindo números e caracteres latinos básicos, mas não caracteres especiais como ç (cê-cedilha), ã (a-til) ou ṇ (n com ponto inferior).

Assim, pode-se concluir que a recomendação I, que dita a verificação do certificado digital da página

visitada, foi a única que poderia potencialmente ter prevenido a fraude se fosse seguida imediatamente

pela vítima. Entretanto, na prática isso dificilmente poderia ser considerado um "descuido". Afinal, o

usuário já havia visitado o site em ocasiões anteriores e, desta forma, não teria motivos para se sentir

impelido a verificar o certificado digital a cada nova visita ao mesmo. Tal ação seria esperada se o

certificado fosse identificado pelo navegador como inválido, o que não foi o caso: conforme observado

na Figura 1, o Google Chrome reconheceu a validade do certificado, colocando um cadeado fechado

verde junto à barra de endereços; tal validade é confirmada na Figura 2, quando o navegador informa

que "The page is secure (valid HTTPS)" -- "A página é segura (HTTPS válido)". A verificação do certificado

também seria cabível se houvesse algo estranho durante a interação com o site, o que novamente não

parece ter sido o caso dado que: (1) a página de phishing mostrada na Figura 1 é uma réplica bastante

fiel do site real da Poloniex mostrado na Figura 3, com exceção de alguns detalhes como o link "Forgot

your password?" ("Esqueceu sua senha?") e campos como "Support" ("Suporte") no rodapé da página; e

(2) o acesso às páginas real e de phishing eram ambos providos pela CloudFlare, de modo que o

eventual aviso de 5 segundos que a empresa comumente mostra aos usuários antes de redirecioná-los à

página desejada (ilustrado na Figura 4) apareceria tanto para a página de phishing quanto para a página

real.

Figura 3 - Site real da Poloniex em 15/Novembro/2017. Quando comparado à página de phishing (Figura 1), há poucas diferenças notáveis (e.g.,os link "Forgot your password" e campos do rodapé não estão presentes na página falsa).

Figura 4 - Exemplo de aviso de segurança da CloudFlare antes de permitir acesso a sites por ela protegidos. A imagem corresponde à página da Poloniex real, acessada em 15/Novembro/2017.

3. Análise do incidente (pré-ataque): falha de segurança no processo de registro

de domínios na CloudFlare

Não existe consenso na literatura sobre quem seriam os principais responsáveis por prevenir phishing

por meio de páginas homógrafas. Por exemplo, a equipe que desenvolve o Google Chrome assumiu para

si a tarefa de deixar claro aos usuários o uso de caracteres Unicode nos endereços sendo visitados;

como resultado, desde sua versão 58, o navegador por padrão mostra tais caracteres em ASCII para seus

usuários, usando o formato Punycode [2][3]. Já a equipe do navegador Mozilla Firefox acredita que os

donos de domínios que podem ter representações homógrafas (no caso em questão, a Poloniex)

deveriam se preocupar em registrar tais domínios alternativos para evitar que os mesmos sejam

usurpados para fins maliciosos [3][8]. Dada a dificuldade técnica de se prevenir tais ataques, entretanto,

o mais razoável é que todas as entidades preocupadas com a segurança de seus usuários e

tecnicamente capazes de fazê-lo atuem no sentido de mitigar ataques de phishing por endereços

homógrafos.

Quando se analisa o contexto específico da fraude ocorrida, uma primeira observação importante é que

a CloudFlare é uma empresa reconhecida pelo seu compromisso em prevenir invasões e vazamento de

dados de seus clientes, empregando diversas técnicas de segurança para atingir tal objetivo [9].

Consequentemente, seria esperado que a empresa investisse esforços para evitar o registro de páginas

de phishing em sua plataforma, em particular homógrafos, para proteger seus próprios clientes. Causa

certa estranheza, portanto, que isso não tenha ocorrido de forma efetiva no caso em questão: se a

política de segurança da CloudFlare para o registro de novos domínios incluísse uma análise mais

minuciosa de homógrafos com domínios já cadastrados, seja com o objetivo de impedir o registro ou de

avaliar o conteúdo da nova página antes de eventual aprovação, é improvável que a página de phishing

"https://www.poloṇiex.com" fosse disponibilizada na plataforma. Em retrospectiva, essa falha parece

ter sido significativa para viabilizar o phishing da página da Poloniex, pois a eventual visualização da

mensagem de redirecionamento da CloudFlare no início do acesso pode ter dado ao usuário a falsa

impressão de que estava na página correta. Em outras palavras, embora a hospedagem da página de

phishing fora do ambiente da CloudFlare pudesse eventualmente ter levado a um resultado semelhante,

o fato da página falsa estar no ambiente da CloudFlare potencialmente deu um ar de legitimidade

adicional à fraude, algo que poderia ter sido evitado se a empresa adotasse uma política mais estrita

para o registro de páginas.

4. Análise do incidente (durante ataque): provável redirecionamento

equivocado

Conforme mencionado na Seção 2 do presente documento, casos de phishing com maior probabilidade

de sucesso são aqueles nos quais o usuário acaba clicando em um link fraudulento (e.g., recebido por e-

mail), o que o leva à página falsa. De fato, diversas recomendações de segurança anti-phishing como as

apresentadas no Quadro 1 tentam exatamente chamar a atenção do usuário a esse tipo de situação.

No incidente em questão, entretanto, a vítima alega que não chegou ao site de phishing clicando em

algum link, mas sim digitando o nome do site diretamente na barra de endereços do navegador. Nesse

caso, é extremamente improvável que o caractere espúrio "ṇ" tenha sido gerado por uma eventual falha

de digitação. Afinal, esse caractere é bastante raro: em uma busca rápida na Internet, os exemplos

encontrados para sua aparição se limitam a linguagens como Inari Sami (dialeto da Finlândia) e

transcrições de dialetos indianos e afro-asiáticos3. Logo, eventuais atalhos de teclado que possam gerá-

lo devem ser semelhantemente raros e envolver diversas teclas, em especial no teclado ABNT2 utilizado

pela vítima. Para exemplificar esse fato, é possível gerar esse caractere no Microsoft Word por meio do

atalho “Alt+7751” (5 teclas), enquanto sua reprodução no Google Chrome foi possível inserindo-se a

sequência “%E1%B9%87” (9 teclas) na barra de endereços do navegador.

Pode-se, assim, formular duas hipóteses principais para explicar como a vítima acabou visitando o site

de phishing apesar de ter digitado outro endereço na barra de endereços de seu navegador. A primeira

é que pode ter havido um ataque do tipo “envenenamento de DNS” (Domain Name System, ou Sistema

de Nomes de Domínios ) [10]. Isso causaria um redirecionamento equivocado da vítima a despeito da

digitação do endereço correto, de modo similar ao que aconteceu com a página brasileira do Google em

Janeiro de 2017, conforme noticiado em [11]. Nesse caso, pode ter havido uma falha de segurança no

servidor de DNS utilizado pela vítima, no nível das autoridades de registro (registry) ou registradores

(registrar), ou o próprio computador da vítima pode ter sido infectado. A eventual ocorrência de falhas

nesses pontos do sistema não pode ser verificada/descartada sem informações adicionais, incluindo logs

de rede gerados durante o acesso e dados do próprio computador da vítima, não disponíveis no

momento da escrita deste documento. Entretanto, é relevante mencionar que uma análise preliminar

do domínio Poloniex.com mostra que o mesmo não segue todas as recomendações de segurança da

própria CloudFlare para proteção contra ataques baseados na subversão do DNS: conforme mostrado na

Figura 5, o domínio Poloniex.com falha em 4 dos 5 testes de segurança para verificação de resiliência

3 https://en.wikipedia.org/wiki/Dot_(diacritic)

contra esse tipo de ataque. Logo, ao menos em princípio não se pode descartar a possibilidade de que

tal ataque tenha sido explorado no caso em questão.

A segunda hipótese é que o redirecionamento errôneo tenha sido causado pela própria CloudFlare, que

oferece, como parte dos seus serviços de proteção, a análise de requisições e seu posterior

redirecionamento para a página desejada (conforme ilustrado anteriormente na Figura 4) . Caso esse

serviço de redirecionamento tenha sido corrompido, o efeito seria semelhante ao obtido no

supramencionado envenenamento de DNS. Novamente, entretanto, essa hipótese não pode ser

validada/refutada sem acesso a informações adicionais, como detalhes adicionais do funcionamento do

sistema de redirecionamentos da CloudFlare e os logs correspondentes ao dia do ocorrido.

Figura 5 - Análise da segurança do domínio Poloniex.com contra ataques de DNS, usando ferramenta da CloudFlare. Teste realizado em 21/Novembro/2017 via URL: https://www.cloudflare.com/domain-security-check/#poloniex.com.

5. Análise do incidente (pós-ataque): processos falhos de autenticação e

bloqueio da Poloniex

Finalmente, a mera existência da página de phishing e o redirecionamento da vítima para a mesma não

teriam tido o efeito observado no incidente em questão se o sistema da Poloniex utilizasse processos de

autenticação e bloqueio mais robustos, conforme discutido nesta seção.

O crescimento mundial de casos de invasão de contas tem levado muitas empresas a utilizar, além de

uma senha, um segundo fator de autenticação (2FA). A Poloniex segue essa boa prática de segurança,

adotando como 2FA o Google Authenticator [12], uma solução leve e de forma geral considerada

bastante efetiva (em especial quando comparada a soluções alternativas como o envio de SMS ao

aparelho celular dos usuários [13]). Entretanto, a forma de uso desse 2FA na Poloniex não é ideal, pois a

empresa limita-se a utilizá-lo durante a autenticação do usuário no momento do acesso a sua conta, não

havendo novos pedidos de confirmação de segurança para validar transações realizadas durante a

sessão. O risco de se utilizar um 2FA para autenticar apenas usuários em vez de transações é discutido

há muito tempo por profissionais de segurança (e.g., vide [14]). Exatamente por essa razão, a

reautenticação para validação de transações tem se tornado bastante comum em sites de bancos e

outras instituições que costumam ser alvo de criminosos. Muitas delas exigem a apresentação de um

2FA para todas as transações realizadas, enquanto outras o fazem apenas periodicamente e/ou quando

as transações são realizadas a partir de uma origem desconhecida (e.g., quando o acesso é feito a partir

de um novo dispositivo ou de uma localização diferente da comum para aquele usuário). A importância

dessa prática de segurança foi recentemente ressaltada por Itsik Martin, diretor de pesquisa em

segurança na Imperva4, em uma entrevista dada ao The Guardian exatamente sobre phishing usando

homógrafos [5]: “Administradores de sites deveriam assumir que as credenciais de alguns de seus

usuários foram roubadas (o que em quase 100% dos casos será verdade), e tomar medidas adequadas

para identificar a invasão de contas, como dispositivo irregular, geo-localização irregular ou atividades

anormais na conta”.

Analisando o ocorrido, pode-se perceber que o caso em questão é um bom exemplo de cenário em que:

(1) o dispositivo era irregular, pois se tratava da máquina do fraudador (provavelmente um robô), a qual

jamais havia sido usada pela vítima; (2) a geo-localização era irregular, pois o acesso foi feito a partir de

um IP da Bélgica (vide Figura 6), quando a vítima afirma que nunca acessou a referida conta fora do

Brasil; e (3) as atividades provavelmente poderiam ser consideradas anormais, dado que foi feito um

elevado número de transações em segundos (ou mesmo em um intervalo de tempo inferior a 1

segundo, conforme mostra a Figura 7). Apesar dessa combinação de três fatores anormais, a Poloniex

não bloqueou, nem mesmo temporariamente, o acesso do atacante. Adicionalmente, como não foi

exigida qualquer reapresentação do 2FA após algumas transações realizadas, o fraudador foi capaz de

extrair o saldo da vítima antes que ela tivesse tempo de ativar o processo de bloqueio manual indicado

pela Poloniex no e-mail da Figura 6. Conforme relato da vítima, esse e-mail foi enviado pela Poloniex

logo após perceber um acesso incomum à conta em questão, por se tratar de um IP não associado

previamente a essa conta.

4 Imperva: https://www.imperva.com/

Figura 6 - E-mail de notificação da Poloniex no momento do ataque, indicando acesso suspeito a partir de um IP da Bélgica (“BE”) . (Nota: imagem fornecida pela vítima)

Figura 7 - Extrato parcial das transações realizadas pelo invasor. O curto intervalo de tempo entre transações sugere que as mesmas foram realizadas por um robô. (Nota: imagem fornecida pela vítima)

6. Conclusões

Com base nas análises das informações fornecidas, pode-se concluir que a fraude que permitiu o roubo

de moedas digitais da vítima foi causada pelo phishing do site da Poloniex. Para isso, foi usado um site

falso homógrafo que reproduzia com boa fidelidade a página original da empresa, dificultando

consideravelmente a identificação da fraude pela vítima.

Embora a técnica de phishing por homografia tenha sido apontada por especialistas na área de

computação e segurança há muitos anos (o primeiro relato identificado data de 2002 [4]), recentemente

ela ganhou maior notoriedade devido à expansão do suporte à internacionalização em navegadores e na

Internet de forma geral. Como tal suporte deve crescer em anos vindouros, é provável que tentativas de

fraude similares voltem a ocorrer contra sistemas nos quais as informações dos usuários tenham alto

valor, como é o caso da Poloniex e de vários outros sites que usam os serviços da CloudFlare. Desta

forma, seria importante que ambas as empresas atentassem para as seguintes questões de segurança

que, ao menos em uma primeira análise, parecem ter facilitado a ocorrência da referida fraude:

O processo de registro de sites na plataforma CloudFlare deve ser mais cuidadoso. Mais

precisamente, é de certa forma compreensível que a tarefa de evitar sites de phishing não seja

simples, e inevitavelmente acabe contando com o auxílio de usuários que denunciam fraudes.

Entretanto, como casos de homógrafos estão entre os mais difíceis de serem percebidos pelos

próprios usuários, é importante que a empresa adote uma política efetiva para evitar essa

categoria específica de phishing, preferencialmente usando uma combinação de ferramentas

automáticas e intervenção humana. Ações nesse sentido certamente reforçariam o

compromisso da empresa de prevenir invasões e vazamento de dados de seus clientes, e

possivelmente teriam prevenido ou ao menos dificultado a fraude analisada neste documento.

O redirecionamento da vítima para o site de phishing é algo que merece uma maior

investigação. Afinal, as análises aqui realizadas não sejam suficientes para afirmar com um grau

razoável de certeza que um redirecionamento equivocado de fato ocorreu no caso em questão.

No entanto, a ocorrência do ataque em si é um potencial indicativo de falhas no processo de

redirecionamento da CloudFlare ou do registro de DNS da Poloniex. Adicionalmente, conforme

os critérios de avaliação da própria CloudFlare, atualmente o domínio Poloniex.com não adota

algumas práticas de segurança importantes para evitar ataques baseados em redirecionamento

de DNS. Por si só, essa é uma vulnerabilidade que deveria ser corrigida para aumentar a

segurança da plataforma e evitar a repetição de casos de fraude semelhantes ao aqui analisado.

A Poloniex deveria reconsiderar seu processo de autenticação, usando 2FA não apenas durante

o estabelecimento da sessão, mas também para validar transações realizadas durante as

sessões. No mínimo, essa deveria ser uma possibilidade oferecida (e, idealmente, recomendada)

aos seus usuários. Se esse mecanismo de segurança estivesse disponível e habilitado no

momento em que ocorreu a fraude analisada neste documento, os danos causados seriam

potencialmente bem menores.

7. Referências

[1] CERT.br (2017). Cartilha de Segurança para Internet -- Golpes na Internet. Centro de Estudos,

Resposta e Tratamento de Incidentes de Segurança no Brasil, Relatório Técnico. Disponível:

https://cartilha.cert.br/golpes/ (Acesso em 15/Nov/2017)

[2] Chromium Bugs (2017). Issue 683314 -- Security: Whole-script confusable domain label spoofing

(Cyrillic) ("Problema 683314 -- Segurança: Falsificação de rótulo de domínio confundível por script

completo"). Google Chrome Bugs, 20/Jan/2017. Disponível:

https://bugs.chromium.org/p/chromium/issues/detail?id=683314 (Acesso em 15/Nov/2017)

[3] X. Zheng (2017). Phishing with Unicode Domains ("Phishing usando domínios em Unicode"). April 14,

2017. Disponível: https://www.xudongz.com/blog/2017/idn-phishing/ (Acesso em 15/Nov/2017)

[4] E. Gabrilovich, A. Gontmakher (2002). The Homograph Attack. Communications of the ACM , volume

45, issue 2, Fevereiro 2002. DOI: 10.1145/503124.503156. Disponível:

http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf (Acesso em 21/Nov/2017)

[5] A. Hern (2017). "Unicode trick lets hackers hide phishing URLs" ("Truque usando Unicode permite

que hackers disfarcem URLs de phishing"). The Guardian, 19/Abril/2017. Disponível:

https://www.theguardian.com/technology/2017/apr/19/phishing-url-trick-hackers (Acesso em

15/Nov/2017)

[6] D. Billian (2012). Protecting CloudFlare sites from phishing ("Protegendo sites na CloudFlare contra

phishing"). CloudFlare Blog, 01/Jul/2012. Disponível: https://blog.cloudflare.com/127760418/

(Acesso em 15/Nov/2017)

[7] A. Costello (2003). Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names

in Applications (IDNA) (“Punycode: uma codificação textual do Unicode para Nomes de Domínio

Internacionalizados em Aplicações”). Request For Comments (RFC) 3492, Internet Engineering Task

Force (IETF), Março 2013. Disponível: https://www.ietf.org/rfc/rfc3492.txt

[8] Mozilla (2017). IDN Phishing using whole-script confusables on Windows and Linux ("Phishing de IDN

usando domínio confundível por script completo no Windows e no Linux"). Bugzilla@Mozilla, Bug

1332714. Disponível: https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 (Acesso em

15/Nov/2017)

[9] CloudFlare. Prevent Customer Data Breach ("Previna Vazamento de Dados de Clientes"). Disponível:

https://www.cloudflare.com/security/customer-data-breach/ (Acesso em 15/Nov/2017)

[10] Wikipédia. DNS cache poisoning (“Envenenamento de cache DNS”). Disponível:

https://pt.wikipedia.org/wiki/DNS_cache_poisoning (Acesso em 21/Nov/2017)

[11] L. Carvalho (2017). Ataque a servidor de DNS faz usuários acreditarem que o Google foi hackeado.

Olhar Digital, Janeiro/2017. Disponível: https://olhardigital.com.br/fique_seguro/noticia/ataque-a-

servidor-de-dns-faz-usuarios-acreditarem-que-o-google-foi-hackeado/65051

[12] Google Authenticator: https://support.google.com/accounts/answer/1066447

[13] T. Fox-Brewster (2017). All That's Needed To Hack Gmail And Rob Bitcoin: A Name And A Phone

Number ("Tudo que é necessário para invadir uma conta do Gmail e roubar bitocins: um nome e um

número de telefone"). Revista Forbes, 18/Setembro/2017. Disponível:

https://www.forbes.com/sites/thomasbrewster/2017/09/18/ss7-google-coinbase-bitcoin-hack/

[14] B. Schneier (2009). Hacking Two-Factor Authentication ("Burlando Autenticação de Dois Fatores") .

Schneier on Security, Setembro/2009. Disponível:

https://www.schneier.com/blog/archives/2009/09/hacking_two-fac.html (Acesso em 15/Nov/2017)