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)