ver/abrir - Repositório do Departamento de Ciência da Computação

Transcrição

Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação
PhiNo - Phishing Notier
Ferramenta para noticar emails com códigos maliciosos que
utilizam técnicas de Phishing e Spam
Gabriel Velasco Braga
Isabella Pinheiro Tavares
Monograa apresentada como requisito parcial
para conclusão do Bacharelado em Ciência da Computação
Orientador
Prof. Dr. Anderson Nascimento
Brasília
2011
Universidade de Brasília UnB
Bacharelado em Ciência da Computação
Coordenador: Prof. Dr. Marcus Vinicius Lamar
Banca examinadora composta por:
Prof. Dr. Anderson Nascimento (Orientador) ENE/UnB
Prof. MSc. Lucas Ferreira CIC/UnB
Prof. MSc. João Gondim CIC/UnB
CIP Catalogação Internacional na Publicação
Braga, Gabriel Velasco.
PhiNo - Phishing Notier: Ferramenta para noticar emails com códigos maliciosos que utilizam técnicas de Phishing e Spam / Gabriel Velasco Braga, Isabella Pinheiro Tavares. Brasília : UnB, 2011.
119 p. : il. ; 29,5 cm.
Monograa (Graduação) Universidade de Brasília, Brasília, 2011.
1. Phishing, 2. Spam, 3. Email, 4. Incidentes, 5. Tratamento,
6. Resposta a Incidentes
CDU 004.4
Endereço:
Campus Universitário Darcy Ribeiro Asa Norte
CEP 70910-900
BrasíliaDF Brasil
PhiNo - Phishing Notier
Ferramenta para noticar emails com códigos maliciosos que
utilizam técnicas de Phishing e Spam
Monograa apresentada como requisito parcial
para conclusão do Bacharelado em Ciência da Computação
Prof. Dr. Anderson Nascimento (Orientador)
ENE/UnB
Prof. MSc. Lucas Ferreira
Prof. MSc. João Gondim
CIC/UnB
CIC/UnB
Prof. Dr. Marcus Vinicius Lamar
Coordenador do Bacharelado em Ciência da Computação
Brasília, 13 de julho de 2011
Dedicatória
Primeiramente, dedico este trabalho a Deus, minha fonte inesgotável de forças e iluminação, sem O qual não teria sido possível atingir essa vitória. Aos meus pais Joaquim
e Fátima, meus maiores incentivadores, que sempre se sacricaram para que eu pudesse
chegar até este degrau da vida sem nunca deixar faltar amor ou apoio. Aos meus irmãos,
Douglas e Joaquim Jr. e a meus amigos queridos, eternas válvulas de escape dos problemas e refúgio em alegria, sempre torcedores fanáticos pelo meu sucesso.
i
Dedicatória
Dedico este trabalho a minha mãe Lívia, que sempre se sacricou para assegurar
que eu tivesse acesso a melhor educação possível e sempre esteve por perto com amor,
dedicação e suporte.
A meu pai João Batista, que me mostrou, desde cedo, o fascínio
pela Computação e, hoje, sigo seus passos. A meu irmão Rafael, que sempre esteve por
perto quando eu mais precisei dele. A minha namorada Natana, que foi peça fundamental
para que eu concluísse este trabalho ao motivar, compreender ausências e se apresentar
como um porto seguro no qual eu podia me refugiar de todos os problemas. A minha avó
Cândida e a meu Tio Edson que tiveram papéis cruciais para a formação do homem que
sou hoje.
Sem o apoio e o amor de vocês jamais alcançaria este objetivo. Se consegui enxergar
mais longe é porque estava apoiado sobre ombros de gigantes. Isaac Newton.
ii
Agradecimentos
Agradeço a todos os meus professores que contribuíram para minha formação acadêmica.
Especialmente ao professor Jorge Fernandes, referencial de conhecimento em Segurança da
Informação, que me apresentou ao tema gerador da vontade de desenvolver este trabalho.
Ao professor Lucas Ferreira que orientou a mim e ao Gabriel com grande prestimosidade
e paciência no desenvolver desta monograa e que muito nos ensinou. Ao professor Anderson Nascimento que acreditou no nosso potencial e orientou nosso trilhar no mundo
dos trabalhos cientícos.
iii
Agradecimentos
Registro meus sinceros agradecimentos:
a Deus, fonte inesgotável de amor e alento, por absolutamente tudo.
Aos profes-
sores Lucas Ferreira e Anderson Nascimento por indicarem a direção certa a ser tomada
nos momentos cruciais.
Agradeço-lhes também por ter acreditado no meu potencial e
no potencial da Isabella. A todos os professores do Departamento de Ciência da Computação pelos ensinamentos. Aos meus amigos e companheiros de computação: Bruno,
César, Diego Aquino, Diego Siqueira, Douglas, Éder, Frederico, Guilherme, Isabella, Luiz,
Rafael, Vanessa e Vítor por tornarem a jornada do curso muito menos árdua e penosa.
Aos meus amigos Andressa, Arthur, Diego, Emílio, Flora, Luana, Lucas, Marcel, Marcos,
Maria Clara, Pedro Hott, Rafael Rezende e Reginaldo por estarem presentes nos momentos mais diversos da minha vida. A meus tios e primos por sempre me apoiarem.
iv
Resumo
Este trabalho apresenta um estudo do crescente número de ataques por emails maliciosos de Phishing e Spam, incluindo um levantamento das soluções existentes para
tentar mitigar o problema.
O trabalho apresenta também um protótipo de ferramenta
para auxílio no tratamento de incidentes de e-mails cujos conteúdos são previamente reportados como Phishing ou Spam.
Palavras-chave:
Phishing, Spam, Email, Incidentes, Tratamento, Resposta a Incidentes
v
Abstract
This undergraduate dissertation presents a study about the growing number of attacks
by malicious emails of Phishing and Spam, including a survey of the proposed solutions
that try to mitigate the problem. This undergratuate work also presents a prototype of
a tool that assists in the response of incidents of emails whose content are previously
reported as Phishing or Spam.
Keywords:
Phishing, Spam, Email, Incidents, Treatment, Incident Response
vi
Sumário
1 Introdução
1
1.1
Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Organização dos Capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4.1
Capítulo 1 - Introdução
3
1.4.2
Capítulo 2 - Outras propostas de combate a Phishing . . . . . . . .
4
1.4.3
Capítulo 3 - Preliminares . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4.4
Capítulo 4 - Processo de desenvolvimento da ferramenta PhiNo
4
1.4.5
Capítulo 5 - Resultados e Análise . . . . . . . . . . . . . . . . . . .
4
1.4.6
Capítulo 6 - Conclusão . . . . . . . . . . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . . . . . . .
. .
2 Outras propostas de combate a Phishing
2.1
2.2
Certicação por terceiros . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
Modelos de conança hierárquicos e distribuídos . . . . . . . . . . .
2.1.2
6
2.2.1
Autenticação do usuário por múltiplos fatores
. . . . . . . . . . . .
6
2.2.2
Autenticação de servidor usando segredos compartilhados . . . . . .
7
2.2.3
Autenticação de servidor usando segredos compartilhados entre usuário
. . . . . . . . . . . . . . . . . . . . . . . .
8
Ferramentas Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.1
Barra de ferramentas do eBay . . . . . . . . . . . . . . . . . . . . .
9
2.3.2
Spoofguard
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.3
Spoofstick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1
Artifícios usados em emails de Phishing . . . . . . . . . . . . . . . . . . . .
3 Preliminares
3.1.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
11
Técnicas conhecidas de ataque . . . . . . . . . . . . . . . . . . . . .
11
Resposta a incidentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.1
A resposta ao incidente . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.2
Grupo de Resposta a Incidentes de Segurança em Computadores . .
23
Cabeçalhos de mensagens eletrônicas
3.3.1
3.4
5
6
Conclusão do capítulo
3.3
5
Trustbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
3.2
5
Autenticação direta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
e seu próprio dispositivo
2.3
3
Campos do Cabeçalho
WHOIS
. . . . . . . . . . . . . . . . . . . . .
24
. . . . . . . . . . . . . . . . . . . . . . . . .
24
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
vii
3.4.1
Utilização
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.4.2
Protocolo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.4.3
Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.4.4
Implementações de servidores
28
3.4.5
Métodos de acesso aos servidores
. . . . . . . . . . . . . . . . . . .
29
3.4.6
Crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
. . . . . . . . . . . . . . . . . . . . .
4 Processo de desenvolvimento da ferramenta PhiNo
31
4.1
Levantamento de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.3
Desenvolvimento
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.3.1
Codicação
4.3.2
Testes
4.3.3
Phishing Notier
5 Resultados e Análise
5.1
5.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1
Simulação
5.1.2
Resultados no ambiente real da organização
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Análise dos resultados
6 Conclusão
Referências
31
37
40
40
40
. . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
viii
43
45
Lista de Figuras
2.1
Screenshot da Trustbar em funcionamento
2.2
Ilustra um exemplo de alternância da borda do Browser.
3.1
Exemplo de email de phishing que faz uso da imagem de uma organização
de boa reputação
3.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Cabeçalho expandido para evidenciar a disparidade entre o email remetente
e o de resposta.
3.4
. . . . . . . . . .
6
Conteúdo de email malicioso cujo endereço de resposta difere do email
remetente.
3.3
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Exemplo de email malicioso que faz uso de premissa plausível para ludibriar
o usuário.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.5
Embuste que exige resposta rápida do usuário.
. . . . . . . . . . . . . . .
16
3.6
Selo Site Blindado
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.7
Selo de Vericação da Verisign . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.8
Selo da Certisign
16
3.9
Embuste que simula um email do Banco Itaú contendo link para uma página
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
que deveria servir para atualizar os dados do usuário. . . . . . . . . . . . .
3.10 Endereço da real página que coletaria as informações.
. . . . . . . . . . .
17
18
3.11 Email contendo link que, aparentemente, levará o usuário a https://www.santander.com.br/com
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.12 Evidencia o redirecionamento com o auxílio do PhiNo. O link, na verdade,
vai para http://cadastrosfacil.com.br/page/
. . . . . . . . . . . . . . . . .
19
3.13 Gráco com a quantidade de spams reportados ao CERT.br por ano(CERT
2011).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.14 Ilustra um exemplo de cabeçalho de mensagem eletrônica encontrado na
Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.15 Ilustra um exemplo de pesquisa WHOIS utilizando o cliente WHOIS instalado no ambiente linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.16 Exemplo de CAPTCHA utilizado atualmente por muitos sítios que disponibilizam consultas WHOIS para limitar a atuação de Spammers.
. . . . . .
30
3.17 Exemplo de CAPTCHA utilizado pelo sítio usado como fonte de pesquisa
para o desenvolvimento do sistema PhiNo.
. . . . . . . . . . . . . . . . . .
4.1
Descrição do comportamento básico com alto nível de abstração
4.2
from
received
. . . . . .
Descrição do sistema com um nível de abstração menor. *: Campo
30
32
do cabeçalho da mensagem. **: whois.geektools.com. ***: emails de
noticação que vem junto com a resposta WHOIS.
ix
. . . . . . . . . . . . .
33
4.3
Descrição do comportamento real do sistema junto a uma fábrica de emails
maliciosos para facilitar os testes.
from
received
* Mostrar original no caso de Gmail
ou campo Headers das mensagens em formato .msg. **: Campo
do cabeçalho da mensagem ou campo X-Originating IP quando pre-
sente.
***:
whois.geektools.com.
****:
emails de noticação que vem
junto com a resposta WHOIS, geralmente algo como [email protected] ou
4.4
4.5
[email protected]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Modelo de controle chamada-retorno (Sommerville 2007)
35
. . . . . . . . . .
Diagrama proposto pelos desenvolvedores com a nalidade de padronizar os
esforços. Ninguém de fora da equipe teve acesso a esse diagrama, pois este
deveria ser tratado como assunto interno e exclusivo de quem codicaria o
sistema.
4.6
4.7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Exemplo de um email aberto com o auxílio do sistema PhiNo . . . . . . . .
38
Exemplo do comportamento do sistema PhiNo ao receber a resposta de
um servidor WHOIS e montar automaticamente uma sugestão de email de
noticação para os responsáveis. . . . . . . . . . . . . . . . . . . . . . . . .
x
39
Lista de Tabelas
5.1
Comparação entre os passos executados manualmente e com o auxílio do
PhiNo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
41
Capítulo 1
Introdução
É crescente o problema relacionado a crimes cibernéticos, ataques de hackers e tentativas online de ludibriar os usuários (Filho 2006). Existe também uma intricada cadeia
de papéis e funções que cada um dos atores da comunicação informática assume: há o
envolvimento do provedor de internet, do fabricante do programa gerenciador de email, do
fabricante de softwares e soluções de segurança, do fabricante do software de navegação,
da própria organização alvo, dos responsáveis pelo desenvolvimento e manutenção ao sistema da organização, e do próprio internauta (cliente). Tendo em vista os membros dessa
cadeia, cada um deles apresenta um elo no escopo da Segurança da Informação. Para a
construção do presente trabalho, inicialmente, o foco foi direcionado ao fator humano.
Em se tratando de crimes cibernéticos, podemos dividir a ação dos criminosos em
basicamente duas categorias - ações que usam de tecnologia sosticada para obter acesso
às informações e ao sistema do alvo, ou ações traiçoeiras e simples, mais conhecidas como
ações de Engenharia Social. (Microsoft 2007)
Nas fontes abaixo listadas, a denição de Engenharia Social gira ao redor do conceito
da arte de enganar para fazer com que as pessoas façam o que é desejado pelo engenheiro
social. Abaixo algumas denições que corroboram esse pensamento:
•
Em Segurança da informação, é denido como Engenharia Social o conjunto das
práticas utilizadas para obter acesso a informações importantes ou sigilosas em
organizações ou sistemas por meio da enganação ou exploração da conança das
pessoas. (Wiki 2011)
•
Método de ataque em que uma pessoa faz uso da persuasão, muitas vezes abusando
da ingenuidade ou conança do usuário, para obter informações que podem ser
utilizadas para ter acesso não autorizado a computadores ou informações.
(Eiras
2004)
•
Método alternativo, utilizado por hackers e crackers para obter, pela conversa informal e aparentemente despretensiosa - por meio de telefonemas, envio de mensagens
por correio eletrônico, em salas de bate-papo ou pessoalmente - informações que lhe
permitam invadir um sistema corporativo. (Dicweb 2010)
•
Qualquer método usado para ganhar a conança do destinatário para que divulgue
informações pessoais ou para obter acesso ao seu computador. (Symantec 2011)
1
Com base nas fontes citadas acima, pode-se dizer que Engenharia Social é, geralmente,
uma manipulação esperta, por parte do hacker, da tendência natural do ser humano de
conar. A meta do hacker é obter informação que irá permitir que ele ganhe acesso não
autorizado a um sistema de valor e às informações residentes nestes sistemas. (Nakamura
2007)
Comumente aceito é o fato de que o elo mais fraco na cadeia de segurança é a predisposição natural das pessoas em aceitar e em acreditar nas palavras umas das outras, o
que acaba por tornar muitos de nós extremamente vulneráveis aos ataques de Engenharia
Social.
De acordo com (Mitnick 2003), não importa quantos artigos sejam publicados
sobre brechas de segurança em redes, patches e rewalls; quantos deles sejam pesquisados
e incorporados à organização, se um colaborador revela sua senha numa conversa informal
com um desconhecido.
O fator humano é o elo mais fraco da segurança (Mitnick 2003). Uma empresa ou órgão
público pode criar uma falsa sensação de segurança ao adquirir as melhores tecnologias
de segurança disponíveis no mercado e oferecer treinamentos reconhecidos aos seus empregados. A empresa ou órgão, ainda assim, estará vulnerável, porque, mesmo com tudo
isso os indivíduos ainda são vulneráveis. Os ataques de engenharia social obtêm sucesso
quando as pessoas não conhecem as boas práticas de segurança ou quando são ingênuas
e tentam ser o mais prestativas possível, pensando que estão ajudando o próximo.
É errôneo acreditar que a maneira mais ecaz de proporcionar segurança ao seu ambiente de trabalho é usando somente as ferramentas de segurança padrão tais como rewalls,
identicações biométricas, antivírus, etc. Todos que coordenam seus atos baseados nessa
idéia equivocada correm sério risco de serem vítimas de um ataque bem-sucedido. Os funcionários podem acreditar que não precisam se preocupar tanto com a segurança uma vez
que dispõem de ferramentas que fazem isso por eles. Essa ilusão é extremamente perigosa,
pois pode levar a um relaxamento e descuido com procedimentos padrões de segurança,
uma vulnerabilidade que será prontamente aproveitada por alguém mal intencionado.
A engenharia social enfatiza como criar o ambiente psicológico perfeito para um ataque.
Os métodos básicos de persuasão são: personicação, insinuação, conformidade, difusão
de responsabilidade e a velha amizade (Popper and Brignoli 2008).
Independente do
método usado, o objetivo principal é convencer a pessoa que dará a informação, de que o
engenheiro social é, de fato, uma pessoa a quem ela pode conar as informações prestadas.
Diversos ataques levam o usuário a pensar que estão se comunicando com uma entidade conável, quando, na verdade, o real propósito é o de roubar informações de conta,
credenciais de login e informações de identidade em geral.
Este método de ataque de
Engenharia Social é denominado Phishing, e é usualmente feito por meio de emails que
contenham links para sites ilegítimos que façam a coleta das informações em questão(Fette
and Tomasic 2007).
No que diz respeito aos emails, não se pode deixar de abordar a modalidade de ataque
denominada Spam, email não solicitado, geralmente enviado para um grande número de
pessoas em forma de golpes bem elaborados (Eiras 2004). Normalmente, são mensagens
semelhantes às originais enviadas pelas empresas, e possuem links para sites que são cópias
dos verdadeiros.
2
1.1 Objetivo
Este trabalho possui dois objetivos principais. O primeiro consiste em fazer um estudo
do problema de Phishing, incluindo um levantamento das soluções existentes na literatura
de forma a sumarizá-las, algo que não foi encontrado na língua portuguesa. O segundo
objetivo é propor, implementar e analisar uma ferramenta para noticação de casos de
Phishing e Spam em emails no ambiente de uma organização pública federal.
1.2 Justicativa
Durante o estudo para elaboração deste trabalho, não foi encontrado material na língua
vernácula dos desenvolvedores que explicasse as ferramentas e soluções existentes no que
tange a embustes de phishing e spam, para tanto justica-se a proposta da tradução e
sumarização das soluções mais relevantes.
Apesar da existência de uma série de ferramentas e estratégias que visam prevenção ou
combate direto tanto a phishing quanto a spam, a ecácia dessas soluções, mesmo quando
combinadas, mostrou-se baixa para o grupo de usuários. Mitigar esses ataques constitui
uma tarefa difícil, dando margem a erros, além da necessidade de serem constantemente
atualizadas para acompanhar o progresso dos ataques. Tendo em vista esses fatos, neste
trabalho, a ferramenta apresentada, após constatação humana de phishing ou spam, auxiliará no tratamento do incidente, quando do momento de noticação, e não na mitigação
direta dos ataques.
1.3 Metodologia
Este trabalho tem caráter exploratório e de desenvolvimento.
A parte exploratória
será fundamentada por meio do levantamento do estado da arte, compondo pesquisas
em artigos, periódicos, jornais cientícos e livros relativos à Segurança da Informação,
presentes nos melhores veículos existentes como o banco da CAPES, IEEE e ACM.
O texto será produzido inicialmente em capítulos com base na revisão bibliográca.
Posteriormente, os capítulos conterão detalhamento do desenvolvimento e da implantação
da ferramenta PhiNo.
Finalmente, o trabalho apresentará os resultados obtidos com a ferramenta, por meio
da comparação da rotina de tratamento de incidentes antes e após o uso do PhiNo.
1.4 Organização dos Capítulos
Este capítulo apresenta uma sumarização do que é abordado em cada capítulo deste
trabalho.
1.4.1 Capítulo 1 - Introdução
Capítulo de cunho introdutório que abrange os conceitos de Engenharia Social, Phishing e Spam, apresenta os objetivos e justicativa da monograa e a metodologia utilizada.
3
1.4.2 Capítulo 2 - Outras propostas de combate a Phishing
Capítulo que contém descrição das soluções relacionadas a Phishing encontradas na
literatura, e apontando pontos fortes e fracos de cada uma.
1.4.3 Capítulo 3 - Preliminares
Capítulo que abrange os conceitos básicos necessários ao entendimento da proposta
do trabalho.
1.4.4 Capítulo 4 - Processo de desenvolvimento da ferramenta
PhiNo
Capítulo de caráter descritivo do processo de desenvolvimento da ferramenta proposta,
desde a idealização, passando pelo levantamento de requisitos e posterior desenvolvimento.
1.4.5 Capítulo 5 - Resultados e Análise
Capítulo que apresenta a descrição da fase de testes bem como dos resultados advindos
deste processo, com posterior análise deles.
1.4.6 Capítulo 6 - Conclusão
Capítulo nal do trabalho, concludente, que apresenta os resultados obtidos e sugestão
de trabalhos futuros.
4
Capítulo 2
Outras propostas de combate a
Phishing
As tentativas para resolver os problemas relativos a Phishing podem ser divididas em
três categorias, segundo (Dhamija and Tygar 2005): certicação por terceiros, autenticação direta e ferramentas especícas.
Abaixo, há a descrição de algumas soluções já
categorizadas por (Dhamija and Tygar 2005).
2.1 Certicação por terceiros
2.1.1 Modelos de conança hierárquicos e distribuídos
Certicação por terceiros inclui modelos de segurança hierárquicos, como Infraestrutura de Chave Pública ( PKI Public Key Infrastructure), a qual já foi extensivamente
proposta como uma solução para usuários autenticarem servidores e vice-versa. Na PKI,
as Autoridades Certicadoras atestam a identidade ligando uma chave pública a uma
entidade por meio de um certicado digital. Ambos os protocolos, SSL (Secure Sockets
Layer) e TSL (Transport Layer Security), seu sucessor, baseiam-se na PKI.
No uso típico do SSL atualmente, somente o servidor é autenticado, entretanto ele
suporta autenticação mútua. Teoricamente, é possível que servidores e usuários possuam
certicados assinados por uma Autoridade Certicadora. Apesar de ser uma área ativa
de pesquisa, inexiste hoje em dia esquema prático para implantação de certicados. Um
desao posterior consiste em como lidar com a revogação de credenciais. O uso de certicados em larga escala pode aumentar as preocupações com a privacidade pessoal devido
às informações contidas nos certicados.
Mesmo com o amplo uso unilateral de SSL hoje ( na forma de certicados digitais
assinados por Autoridades Certicadoras ), ainda há problemas. Certicados podem ser
emitidos falsamente por um site de Phishing para ganhar credibilidade, e a maioria dos
usuários não possui conhecimento necessário ou capacidade para entender certicados
digitais.
5
2.1.2 Trustbar
A proposta da Barra de Segurança (Trustbar) é uma solução de certicação por terceiros na qual as logomarcas dos sítios são certicadas (Herzberg and Gbara 2004).
A
meta desta solução é incluir nos browsers uma interface gráca altamente visível que estabeleça a identidade segura da página web visitada. Os autores da solução sugerem a
criação de uma área de credenciais conáveis na janela do browser. Esta área deve ser
usada para apresentar credenciais do sítio como logomarcas, ícones e selos da marca, que
tiverem sido certicados por Autoridade Certicadoras conáveis. Na gura abaixo em
(a) e (b), mostra-se a página de login do Gmail; em (a), o sítio e a autoridade certicadora
são identicadas pelo nome, enquanto em (b), eles são identicados pelas logomarcas. Em
(c), o formulário inicial do processo de login no UBS bank(Herzberg and Gbara 2004):
Figura 2.1: Screenshot da Trustbar em funcionamento
Um ponto forte desta solução é que não se baseia em indicadores de segurança complexos. Entretanto, como as logos não mudam, elas podem facilmente ser copiadas e a
área de credenciais do browser pode ser atacada e disfarçada. Mesmo assim, ainda não
está claro como as logos serão certicadas, nem como disputas serão resolvidas para o
caso de logomarcas similares.
2.2 Autenticação direta
A autenticação é um aspecto fundamental da segurança do sistema. Ela conrma a
identidade de qualquer usuário que esteja tentando fazer logon em um domínio ou acessar
recursos da rede. Desta forma, determinar que um usuário ou servidor é legítimo, é fator
crucial para fugir aos ataques de personicação de Phishing.
2.2.1 Autenticação do usuário por múltiplos fatores
Essa estratégia usa uma combinação de fatores para atuenticar o usuário. Os fatores
podem ser algo que se conheça, como uma senha ou PIN, algo que se possui, como um
token ou chave, ou algo que se é, no caso de biometria.
6
Senha AOL
O código de acesso ou senha da AOL foi proposto como uma defesa contra phishing.
Esta estratégia distribui dispositivos RSA SecurID para seus usuários. O dispositivo gera
e exibe um único código numérico de seis dígitos a cada 60 segundos, o qual pode ser usado
como senha secundária durante o login na página AOL. Isto reduz signicativamente a
motivação dos atacantes em coletar senhas, visto que as senhas secundárias só podem
ser usadas uma vez. No entanto, a estratégia não previne quanto a ataques man-in-themiddle, no qual os atacantes direcionam o usuário a um sítio falsicado da AOL e consegue
coletar tanto a senha primária quanto a secundária, estas podem ser imediatamente usadas
pelo atacante no real site da AOL. Como essa estratégia não fornece meios para que o
usuário verique a autenticidade do servidor, ela ignora o fator de limitação humana.
Senhas secundárias por SMS
Outra estratégia de autenticação por múltiplos fatores consiste no envio de senhas
secundárias aos usuários por SMS. É, entretanto, uma estratégia que permanece vulnerável
a ataques man-in-the-middle. Geralmente, autenticação com dois fatores serve mais para
proteger o servidor de alguma fraude, do que prevenir que o usuário seja vítima de embuste
relacionado a phishing ou spam pois não há fornecimento de modos para que o usuário
verique a autenticidade do servidor.
2.2.2 Autenticação de servidor usando segredos compartilhados
Passmark and Veried by Visa
Estratégias de segredo compartilhado têm sido propostas como uma abordagem simples de ajudar usuários a identicar servidores conhecidos. Como na proposta de Passmark
e Veried da Visa, na qual o usuário recebe do servidor um segredo compartilhado, e é
solicitado ao usuário que reconheça o servidor antes de fornecer a ele seu segredo.
A
vulnerabilidade mais evidente dessa estratégia é que, se o segredo fornecido do servidor
ao usuário for visto e capturado, a imagem pode ser replicada antes que o usuário note alguma coisa. Na abordagem Passmark, o servidor do banco coloca um cookie de segurança
na máquina do usuário, o qual é apresentado no momento de login. Isto previne o ataque
clássico do tipo man-in-the-middle. Contudo, não previne ataques nos quais um servidor
trapaceiro instrui o browser a exibir duas janelas. A primeira janela exibe a página legítima do banco, que contém indicadores conáveis. A segunda janela mostra uma página
do servidor trapaceiro.
Se as janelas forem posicionadas com cuidado pelo atacante, o
usuário pode ser levado a fornecer a senha dele.
Outra maneira de enganar o usuário
fazendo com que ele forneça sua passmark e senha se baseia na possibilidade de falsicar
o processo de re-registro. Se o usuário deseja fazer login usando um novo computador,
ou se o cookie de segurança tiver sido deletado, o usuário deve re-registrar sua passmark.
Neste caso, é mostrado ao usuário uma tela na qual existe uma passmark previamente não
apresentada e ele deverá fornecer sua senha, para novo registro. Portanto, um atacante
pode direcionar o usuário à uma tela que alega que o cookie foi deletado ou não existe e
fazer com que ele re-registre-se em uma página falsa.
7
2.2.3 Autenticação de servidor usando segredos compartilhados
entre usuário e seu próprio dispositivo
SRD
Synchronized Random Dynamic Boundaries
, Fronteiras Dinâmicas Sincronizadas Di-
namicamente é uma proposta que visa assegurar o caminho que vai do usuário ao browser.
Esta estratégia faz uso de um gerador de números aleatórios para ligar um bit que determina se a frontreira do browser está dentro ou fora da conguração. A borda do browser
se alterna dinamicamente entre dois tipos de conguração com base em uma janela de
referência.
Figura 2.2: Ilustra um exemplo de alternância da borda do Browser.
Nessa abordagem, servidores trapaceiros não conseguem prever o número randômico
escolhido pelo browser, logo é difícil criar janelas falsas que se adequem ao padrão correto
de alternância das bordas. Uma fraqueza da abordagem é que ela ignora as habilidades
humanas limitadas, os limites intermitentes de uma janela podem não ser percebidos pelo
usuário, e as mudanças frequentes nas bordas podem ser distrativas. A segurança então irá
depender da quantidade de frequência de bordas disponíveis e da quantidade de usuários
que conseguem diferenciá-las.
YURL Petnames
Na proposta YURL, o browser do usuário mantém um mapeamento de um hash de
chave pública para o nome do animal de estimação.
Quando um usuário visita uma
página identicada pela YURL, o navegador exibe o nome do animal de estimação que o
usuário associou previamente ao hash de chave pública. Um site não conável pode ser
reconhecido quando notada a ausência do nome do animal de estimação correspondente
no navegador. Esta é uma estratégia relativamente simples e que exige um grau pequeno
de personalização para cada sítio.
O problema aqui reside, principalmente, no usuário
desmotivado, que pode não customizar os nomes de animais de estimação para sites
conáveis; além da possibilidade do usuário esquecer os nomes escolhidos, ou escolher um
mesmo nome para diferentes sítios, o que facilitaria para o atacante caso ele descobrisse
o de uma página conável.
8
2.3 Ferramentas Anti-Phishing
2.3.1 Barra de ferramentas do eBay
A barra de ferramentas do eBay é um plugin oferecido pelo eBay para o browser com o
intuito de ajudar a manter o controle de seus sítios de leilões. A barra de ferramentas tem
um recurso, chamado AccountGuard, que monitora páginas web que o usuário visita e
provê alarmes em forma de abas coloridas na própria barra de ferramentas. A aba é cinza,
geralmente, mas ca verde se o usuário está no sítio do eBay ou do PayPal, e vermelha se
o usuário está num sítio reconhecidamente falso pelo eBay. A barra também permite que
o usuário reporte suspeitas de sítios falsos ao eBay. Uma desvantagem dessa abordagem
é que ela só se aplica aos sítios do eBay e do PayPal. Os usuários não desejam ter de usar
várias barras de ferramentas para diferentes tipos de sítios. A principal fraqueza é que
haverá sempre um período de tempo entre o tempo de detecção de um embuste e quando
a barra de ferramentas comece a detectar embustes para os usuários.
Se os embustes
não forem cuidadosamente conrmados, ataques de negação de serviço se tornam uma
possibilidade. Isso signica que uma porcentagem dos usuários estará vulnerável.
2.3.2 Spoofguard
SpoofGuard
é um plugin do Internet Explorer que examina páginas web e adverte os
usuários quando uma página possui alta probabilidade de ser falsa. Este cálculo é feito com
base no exame do nome do domíno, imagens e links, e comparando-os aos armazenados
no histórico e detectando características comuns de sítios falsos. Se adotado, irá forçar os
atacantes a demandar maior esforço para criar páginas falsas. Entretanto, o SpoofGuard
necessita estar sempre um passo à frente dos atacantes, que podem testar suas páginas
no SpoofGuard. Novos testes de detecção deverão ser desenvolvidos continuamente para
acompanhar a crescente sosticação dos atacantes.
2.3.3 Spoofstick
Spoofstick
é uma barra de segurança fornecida como plugin para o Internet Explorer
e o Mozilla Firefox. Ela provê informações básicas sobre o nome do domínio do sítio. Por
exemplo, se o usuário está visitando o eBay, a barra irá exibir Você está no ebay.com.
Se, por outro lado, o usuário estiver em um site falso, ela exibirá Você está no 10.19.32.4.
Esta barra de ferramentas ajuda o usuário a detectar ataques nos quais um sítio falsicado
tem um nome de domínio sintaticamente ou semanticamente similar ao site legítimo.
Infelizmente, a implementação mais atual do Spoofstick pode ser trapaceada por meio
do uso esperto de quadros, quando sítios diferentes são abertos em múltiplos quadros na
janela do browser. Para funcionar, os usuários deveriam estar cientes do uso de quadros
escondidos numa página web, o que não é o caso na maior parte do tempo, devido às
habilidades humanas limitadas.
9
2.4 Conclusão do capítulo
Estudos direcionam à conclusão de que, até no melhor cenário, quando os usuários
esperam a presença de embustes e são motivados a descobri-los, muitos desses indivíduos
não são capazes de distinguir um email que contenha phishing ou spam, de um email
legítimo. Em um levantamento realizado por (Dhamija et al. 2006), no qual uma série
de testes foram realizados, constatou-se que o melhor site de phishing modelado por eles
ludibriou mais de 90% dos participantes.
Indicadores desenvolvidos para indicar conabilidade, muitas vezes, não são compreendidos ou percebidos.
A maioria das pessoas se preocupa apenas com o conteúdo das
mensagens para considerar sua autenticidade, sem sequer olhar qualquer outra parte do
browser. O ícone do cadeado (padlock icon) se mostrou mais relevante aos usuários quando
mostrado na própria página que quando exibido em áreas especícas do browser. O design
da página foi mais efetivo que indicadores SSL quando as pessoas vão atestar legitimidade
do site.
Esse conjunto de fatores evidencia a diculdade em prevenir e combater embustes
como phishing e spam por meio das soluções já levantadas. Haja vista imenso esforço demandado por outros colegas também preocupados com tais questões e a baixa efetividade
e ecácia das soluções, quando postas em funcionamento com a maioria dos usuários, este
trabalho possui uma abordagem que visa facilitar o tratamento de incidentes por meio do
auxílio na detecção de atacantes e noticação aos responsáveis. Sendo assim, foi então
desenvolvido o Phino Phishing Notier.
10
Capítulo 3
Preliminares
Neste capítulo estão descritos os conceitos básicos necessários ao entendimento da
solução proposta pelos pesquisadores.
3.1 Artifícios usados em emails de Phishing
Emails fraudulentos que contém Phishing ou Spam estão no topo da pilha de embustes
virtuais que variam dos mais simples aos mais sosticados, capazes de enganar até o mais
precavido dos usuários de internet(Drake et al. 2004).
Emails fraudulentos prejudicam
suas vítimas por meio da perda monetária ou roubo de identidade. Eles também atingem
negócios da Internet, no sentido de que as pessoas perdem a conança em transações online
por medo de se tornarem vítimas de fraude. Por exemplo, muitas pessoas crêem que o uso
de internet baking aumenta a probabilidade de que elas se tornem vítimas de roubo de
identidade, mesmo que o banco provenha mais segurança relacionada à identidade que os
sistemas de correio. Como meta principal as ações de phishing ou spam tentam defraudar
informações pessoais das vítimas, tais como número de cartão de crédito, dados da conta
bancária e etc. (Leyden 2004).
3.1.1 Técnicas conhecidas de ataque
De acordo com levantamento feito por (Drake et al. 2004) existe uma série de mecanismos enganosos usados em sites fraudulentos que são acessados através de links nos emails
originais. A lista mais signicativa desses mecanismos está apresentada a seguir:
Imitação de empresas de boa reputação
Em embustes de phishing ou spam, os atacantes que remetem os emails maliciosos devem fazer com que os usuários sintam-se seguros o suciente para convencê-los a fornecer
suas informações pessoais. De forma a simular um ambiente seguro e, por conseguinte,
obter a conança dos usuários, os atacantes devem falsicar ou imitar, a aparência de
um email de uma organização de boa reputação, como Citibank, eBay, Banco do Brasil,
PayPal e etc. Os alvos principais são as organizações que provêm serviços nanceiros, contudo provedores de Internet e outras instituições detentoras de informações consideradas
valiosas também são alvos.
11
Esses emails fraudulentos são massivamente enviados: em abril de 2004 (Warner 2004),
estimou-se que 3.1 billões de mensagens de phishing foram enviadas em todo o mundo.
Muitos dos destinatários não são clientes da organização que foi clonada, de forma que
podem rapidamente perceber que o email é, na verdade, uma fraude ou acreditar que se
trata de um equívoco e simplesmente ignorá-lo. Entretanto, os atacantes enviam milhares
de emails contando com uma espécie de sorte; eles esperam resposta dos destinatários
que são de fato clientes da organização em questão. Os fraudadores usam os seguintes
artifícios para clonar a aparência de uma organização de boa reputação:
•
Uso da imagem da organização: os atacantes não apenas alegam ser da organização,
como também se esforçam consideravelmente para simular a marca da empresa. Os
emails contêm a logomarca da organização e fontes e temas similares aos do site
legítimo. Muitas dessas fraudes simplesmente referenciam imagens do sítio original.
•
Links para o site legítimo da organização: o link principal em um email fraudulento
direciona a vítima a um sítio de phishing, mas muitos emails incluem outros links
para o sítio real da organização de forma a conferir mais credibilidade ainda àquela
mensagem.
•
O email parece ser da organização imitada: para posterior convencimento do destinatário de que o email origina de uma companhia de boa reputação, os atacantes
usam emails que parecem ser da organização por meio do domínio da empresa, por
exemplo @paypal.com.
Exemplo:
Figura 3.1: Exemplo de email de phishing que faz uso da imagem de uma organização de
boa reputação
12
Endereço de resposta díspare do email remetente
Em alguns emails fraudulentos, o email atesta ser de uma empresa legítima, mas
a resposta é congurada para ser enviada a um email ilegítimo.
Como, por exemplo,
ilustrado já com o uso da ferramenta PhiNo:
Figura 3.2: Conteúdo de email malicioso cujo endereço de resposta difere do email remetente.
A seguir, a expansão do cabeçalho que permite averiguar a disparidade entre os endereços de email remetente e de resposta:
13
Figura 3.3: Cabeçalho expandido para evidenciar a disparidade entre o email remetente
e o de resposta.
Criação de premissa plausível
Após o convencimento do destinatário de que o email veio de uma organização legítima, o email deve conter uma premissa plausível capaz de persuadir o usuário a fornecer
a informação pessoal. O email pode alegar que as informações inerentes ao usuário estão
desatualizadas, que o cartão de crédito expirou ou que a conta foi randomicamente selecionada para vericação. Além de oferecer até mesmo prêmios ou informar que o usuário
foi o ganhador de alguma promoção. Exemplo:
14
Figura 3.4: Exemplo de email malicioso que faz uso de premissa plausível para ludibriar
o usuário.
Ironicamente, as mensagens de email freqüentemente usam o medo das pessoas por
fraude para defraudá-las: os emails podem alegar que a organização instalou um novo
software de segurança e que o usuário deve atualizar as informações da conta ou o email
pode dizer que a conta foi comprometida por algum tipo de atividade fraudulenta e os
dados devem ser conrmados. Há inúmeras abordagens e cada uma delas tenta criar o
cenário que convencerá o usuário destinatário de que ele deve fornecer as informações
solicitadas.
Exigência de resposta rápida
Como a perseguição aos phishers é grande, os atacantes dispõem de um curto período
de tempo para efetuar a coleta de informações e dados desejados antes que sejam descobertos e seus sites sejam tirados do ar.
Esses embustes utilizam inúmeros mecanismos de
persuasão para inspirar sentimento de urgência nos usuários para que então eles respondam rapidamente às requisições presentes no email, como pode-se perceber no exemplo a
seguir:
15
Figura 3.5: Embuste que exige resposta rápida do usuário.
Promessa de segurança
Emails fraudulentos também tentam assegurar aos usuários que a transação é segura
de forma a obter sua conança. Os atacantes usam réplicas de uma variedade de selos
web que denotam a visualização de um email seguro. Como o usuário comum dicilmente
possui conhecimento sobre o funcionamento dos sítios, seu julgamento ca prejudicado ao
ver um símbolo que inspira conança. Então, ao encontrar selos como o do Site Blindado,
Figura 3.6: Selo Site Blindado
o selo de vericação da Verisign,
Figura 3.7: Selo de Vericação da Verisign
o selo da CertiSign,
Figura 3.8: Selo da Certisign
16
Ambos os selos têm por essência a função de garantir proteção contra ataques de
hacker, infecção por malware, roubo ou clonagem de informações pessoais, e que o domínio
que está sendo accesado é de propriedade ou se encontra registrado por organizações
autorizadas a exercer atividades lícitas.
O usuário, portanto, possuirá a falsa sensação
de estar realizando um transação segura e fornecendo suas informações pessoais à uma
entidade legítima.
Links a sítios para coletar informação
Hoje em dia, os atacantes não precisam mais de um vírus que capture cada caractere
de senha digitado pelo usuário, quando tal atacante invadir o computador de uma vítima a
m de usurpar senhas, por exemplo. Demanda menos tempo e pode ser aplicado em larga
escala mais facilmente, se apenas for criada uma página que exerça as funcionalinalidades
maliciosas pretendidas.
A maioria dos emails fraudulentos direciona o usuário a um sítio inteiramente falso
que faz uso de um servidor proxy malicioso e capaz de coletar todas a informações desejadas. Alguns fraudadores registram domínios muito similares aos domínios legítimos
das organizações.
Outros atacantes tentam esconder o destino verdadeiro por meio de
artifícios HTML. Um exemplo de artifício deste tipo está ilustrado nas guras abaixo:
Figura 3.9: Embuste que simula um email do Banco Itaú contendo link para uma página
que deveria servir para atualizar os dados do usuário.
17
Figura 3.10: Endereço da real página que coletaria as informações.
O texto do link no email difere do destino do link
Em mensagens fraudulentas, geralmente, o texto do link é diferente da real destinação do link.
No exemplo a seguir, o email parece que vai mandar o usuário para
https://www.santander.com.br/comunicado, mas, na verdade, trata-se de uma forma de
redirecionamento que o manda para http://cadastrosfacil.com.br/page/ .
Figura
3.11:
Email
contendo
link
que,
https://www.santander.com.br/comunicado
18
aparentemente,
levará
o
usuário
a
Figura 3.12: Evidencia o redirecionamento com o auxílio do PhiNo. O link, na verdade,
vai para http://cadastrosfacil.com.br/page/
Uso de onMouseOver para esconder link
Alguns fraudadores usam o manipulador de evento JavaScript onMouseOver para
exibir uma URL falsa na barra de status do aplicativo de email do usuário.
O código
seguinte foi tirado de um email fraudulento simulando o PayPal. Quando o usuário passa
o mouse sobre o link, a barra de status irá mostrar
https : //www.paypal.com/cgi − bin/webscr?cmd =l ogin − run
.
Entretanto o link na verdade direciona o usuário a http://leasurelanscapes.com/snow/webscr.dll.
0
< Aonmouseover = ”window.status = https : //www.paypal.com/cgi−bin/webscr?cmd =
0
0
_login−run ; returntrue”onmouseout = ”window.status = https : //www.paypal.com/cgi−
0
bin/webscr?cmd = _loginrun ”href = ”http : //leasurelandscapes.com/snow/webscr.dllhttps :
//www.paypal.com/cgibin/webscr?cmd = _login − run < /A >
Uso do endereço IP
No exemplo do item acima, o código mostra claramente a real destinação do link:
www.memberupdating.com. Freqüentemente, os fraudadores tentam ocultar o endereço
de destino obscurecendo a URL. Um método de fazer isso é usar o endereço de IP do
sítio, ao invés de um nome de servidor.
Um exemplo de endereço de email usado em
mensagem de email fraudulenta é HTTP://210.14.228.66/sr/ . Um endereço de IP pode
ser obscurecido posteriormente se expressado em formato Octal ou Hexadecimal.
Uso do símbolo @ para confundir
Quando o símbolo @ é usado em uma URL HTTP:// ou HTTPS://, todo o texto
anterior ao símbolo @ é ignorado e o navegador referencia apenas a informação seguinte
ao @. Em outras palavras, se o formato
< userinf o > @ < host > for usado, o navegador
19
é direcionado ao sítio de
< host >
e a parte
< userinf o >
é ignorada. Este artifício é
usado por atacantes na esperança de ludibriar a visão do usuário de modo que este pense
que o link está indo para o endereço anterior ao @, quando na verdade está indo para o
site fraudulento contido no link após o símbolo @.
Ocultação da informação do servidor
Links que usam o formato
< userinf o > @ < host >
em emails, algumas vezes dão
um passo adiante no artifício ao adicionar um caractere nulo ou não imprimível antes do
símbolo @, o que impede que o browser exiba na barra de endereços a informação contida
em
< host >.
Os navegadores web geralmente mostram as informações da URL da página
atual na barra de endereços. Contudo, se o formato
< userinf o >< null > @ < host >
for usado em um link, algumas versões do Internet Explorer não irão mostrar a parte
referente ao
< host >,
ela será ocultada. Como se pode observar, no caso abaixo:
http://cgi1.ebay.com.aw-cgiebayISAPI.dll%[email protected]/my/index.htm
O caractere representado por %00 faz com que apenas a <userinfo>
http://cgi1.ebay.com.aw-cgiebayISAPI.dll% seja exibida na barra de endereços do browser,
mas a página acessada, na verdade, é a respectiva à informação contida em <host>, ou
seja, 210.93.131.250/my/index.htm.
Uso de códigos de caracteres hexadecimais
Fraudadores também podem esconder as URLs por meio do uso de códigos de caracteres hexadecimais para representar os números do endereço de IP que eles quiserem.
Cada código de caractere hexadecimal começa com um %. Este exemplo seguinte combina alguns dos artifícios mencionados anteriormente:
http://www.visa.com%00@%32%32%30%2E%36%38%2E%32%31%34%2E%32%31%33
A URL foi posta no formato <userinfo><null>@<host>.
Caso o navegador que
estiver sendo utilizado não possua mecanismo de prevenção à esse tipo de formato, somente
www.visa.com será exibido na barra de endereços, todavia a janela do navegador irá exibir
a página contida em 32%32%30%2E%36%38%2E%32%31%34%2E%32%31%33 , que é
o endereço de IP fraudulento escondido pelo código hexadecimal. O código converte para:
http://220.68.214.213 .
Redirecionamento de URL
Uma URL pode ser posteriormente obscurecida por meio de um serviço de redirecionamento. Por exemplo, cbj.net e tinyurl.com fornecem serviços de redirecionamento
que atribui um pseudônimo à URL especicada pelo usuário.
Por exemplo, uma URL
como http://tinyurl.com/3 é fornecida pelo tinyurl.com quando o usuário fornece uma
URL ao site. Quando um serviço de redirecionamento é usado, o link fornecido direciona
o usuário ao sítio que está provendo o serviço ( tinyurl por exemplo) e tal sítio o redireciona ao site pretendido. Esse serviço é útil para substituir longos endereços de URL,
mas infelizmente, ele pode ser usado por fraudadores, porque ele esconde o destino real
do link.
Alguns atacantes inclusive fazem o esforço de redirecionar uma url duas ou mais vezes.
20
Mudança de portas
Páginas web são acessadas nos servidores por meio de portas. Sabe-se da existência
de mais ou menos 65.536 portas TCP. As portas são usadas por programas ou serviços
especícos, de forma que se pode ter vários serviços diferentes ativos simultaneamente em
um mesmo servidor. Uma porta pode ser especicada pelo sinal de dois pontos `:' e o
número da porta, logo após a URL. Se nenhuma porta é especicada, o navegador usa a
porta 80, que é a porta padrão para páginas web. Atacantes ocasionalmente usam outras
portas para esconder suas localidades reais. No exemplo a seguir, o endereço de IP após
o símbolo @ é seguido de `:8034', que representa a porta 8034 especicada.
http://www.citibankonline.com:[email protected]:8034/
Alguns atacantes podem até invadir um servidor legítimo de uma organização de
reputação e hospedar seu sítio no servidor usando um número de porta mais alto.
A
organização pode permanecer, durante um bom tempo, completamente desavisada do
site fraudulento.
Coleta de informações no email
Os primeiros emails contendo phishing usavam formulários HTML no email para capturar as informações. Este método, hoje em dia, não é tão popular e, portanto, pouco
usado nos embustes.
Ele funciona da seguinte forma:
uma vez que a informação foi
submetida, o email deve fornecer um método de enviar a informação ao fraudador. Geralmente, o botão `Enviar' no nal do formulário faz com que a informação seja enviada até
onde o fraudador deseja.
3.2 Resposta a incidentes
Haja vista que o PhiNo é uma ferramenta que visa auxílio no que tange à Resposta
a Incidentes de Segurança, esta seção está destinado a contemplar o tema 'Resposta a
Incidentes' e 'Grupo de Resposta a Incidente de Segurança em Computador - CSIRT'.
A m de dar mais clareza ao capítulo, um Grupo de Resposta a Incidente de Segurança
em Computador - CSIRT é um grupo que executa, coordena e dá suporte, respondendo
a incidentes de segurança que envolvam sites e equipamentos de usuários, entidades e
empresas comerciais ou não que ele represente (Grupo de Trabalho em Segurança de
Redes 1999).
É notável o crescimento de incidentes de segurança envolvendo spam e phishing. A
velocidade com que as tecnologias e estratégias embutidas em tais ataques também cresce
de tal forma que o desenvolvimento de contra medidas e de tratamento destes incidentes
deve se manter em passo acelerado, a m de não se desatualizar para que o lido com os
ataques seja efetivo e ecaz. Segundo estatísticas do CERT.br, de janeiro a maio de 2011,
foram reportados quase 2 milhões de incidentes envolvendo spam. Sabendo que spam é
um canal massivamente usado por atacantes de modo a realizar embustes de phishing,
vale a pena direcionar atenção a esses dados. A seguir um gráco retirado da página de
Estatísticas de Noticações de Spam Reportadas ao CERT.br mostra a quantidade de
incidentes deste tipo de 2003 a 2011:
21
Figura 3.13: Gráco com a quantidade de spams reportados ao CERT.br por ano(CERT
2011).
Só em 2010 foram mais de 40 milhões de casos dentro desse escopo. Os números, sem
dúvida, são alarmantes, ainda mais se levar-se em conta que nem todos os incidentes são
devidamente reportados.
3.2.1 A resposta ao incidente
A resposta ao incidente é uma reação expedida a uma questão ou ocorrência de segurança. O incidente é uma infração de segurança (John Ha 2005).
Qualquer pessoa ou organização que está de alguma forma conectada a um sistema
computacional ligado a redes estará automaticamente sujeita a ataques que incorrerão em
infrações de segurança. As tentativas de invadir um sistema ou de descobrir vulnerabilidades aumentam numa frequência altíssima. Tendo esse fato em foco, é necessário que se
saiba como responder aos incidentes. A forma como essa resposta será feita, obviamente,
variará de acordo com a disposição de recursos da organização.
Dentre as formas de preparo para responder aos ataques, estão a criação de honeypots,
redes que funcionam como iscas para atrair atacantes a m de angariar informações e
provas incriminatórias e de blacklists, lista contendo endereços de sites maliciosos cujo
acesso será vetado dentro da organização.
Um aspecto de extrema importância na resposta a incidentes é a manutenção dos logs
relevantes do que aconteceu na rede, de forma a não acumular dados desnecessários. Esse
material permitirá a análise de elementos que permitem reconstituir acontecimentos e
ter uma visão da utilização que é dada a determinado sistema. Segundo (Torres 2003),
22
deve existir na organização, uma política de retenção de logs que dena não só a duração,
volume e nível de detalhe desses logs, mas que também estabeleça igualmente sua remoção
dos sistemas para locais seguros; visto que atacantes sempre tentam apagar seu rastro ao
invadir um sistema.
Os logs, ainda de acordo com (Torres 2003), constituem a última
arma na linha de defesa e de resposta a incidentes.
Para melhor efetividade e eciência da resposta a incidentes, é importante que se
prepare um plano. O plano de resposta ao incidente pode ser dividido em quatro partes
(John Ha 2005):
•
ação imediata para interromper ou minimizar o incidente;
•
investigação do Incidente;
•
restauração dos recursos afetados;
•
reportando o indicente aos canais apropriados.
A resposta ao incidente deve ser decisiva.
Há pouco espaço para erros.
Deve ser
desenvolvida uma metodologia que deve ser executada por uma equipe Grupo de Resposta
a Incidentes de Segurança em Computadores, geralmente conhecido como CSIRT (do
inglês "Computer Security Incident Response Team") (CERT a) .
3.2.2 Grupo de Resposta a Incidentes de Segurança em Computadores
A criação de um Grupo de Resposta a Incidentes de Segurança em Computadores tem
sido incluída cada vez mais nas estratégias de segurança das organizações.
Motivações para o estabelecimento de CSIRTs
Segundo (CERT a), as motivações para que se dê a criação de um Grupo de Resposta
a Incidentes de Segurança em Computadores são:
•
um aumento generalizado na quantidade de incidentes de segurança sendo reportados;
•
um aumento generalizado na quantidade e na variedade de organizações sendo afetadas por incidentes de segurança em computadores;
•
uma maior consciência, por parte das organizações, da necessidade de políticas e
práticas de segurança como parte das suas estratégias globais de gerenciamento de
riscos;
•
novas leis e regulamentos que afetam a maneira como as organizações precisam
proteger as suas informações;
•
a percepção de que administradores de redes e sistemas não podem proteger sozinhos
os sistemas e as informações da organização.
23
Importância da criação de um CSIRT
A existência de um CSIRT caracteriza a presença de um grupo apto a conduzir uma
resposta rápida para conter o incidente de segurança e para recuperar-se dele. CSIRTs
também podem estar familiarizados com os sistemas comprometidos e, portanto, melhor
preparados para coordenar a recuperação e propor estratégias de erradicação e de resposta
aos problemas (CERT b).
Tendo em vista o requisito básico 'rapidez' na ação de um Grupo de Respostas, a
ferramenta PhiNo traz a proposta de acelerar a parte referente ao processo de vários
passos da noticação de incidentes que incorrem em casos de spam ou phishing.
3.3 Cabeçalhos de mensagens eletrônicas
Para identicar possíveis mensagens maliciosas, foram utilizadas informações contidas
nos campos dos cabeçalhos de e-mail. Portanto, essa seção se dedica a fornecer uma breve
explicação a respeito dos campos e de sua formatação padrão.
Figura 3.14:
Ilustra um exemplo de cabeçalho de mensagem eletrônica encontrado na
Internet.
3.3.1 Campos do Cabeçalho
Campos do cabeçalho são linhas que começam com o nome do campo seguidas de dois
pontos : e do corpo do campo. Cada campo termina com um CRLF
1
(Resnick 2008).
Por questões de implementação dos protocolos de transporte de mensagens eletrônicas,
que fogem ao escopo deste trabalho, o máximo de caracteres que podem estar presentes
1 CR
corresponde a Carriage Return, ou seja, o cursor volta ao início da linha e LF corresponde a
LineFeed, ou seja, o cursor vai para a próxima linha. Os dois caracteres especiais juntos correspondem a
tecla ENTER em um editor de texto como o Notepad ou o BrOce Writer em um ambiente Windows
por exemplo.
24
em cada linha é 998 e o recomendado é que não passe de 78.
Tendo isso em vista, a
quebra de linha ou CRLF pode ser usada no lugar de espaços em branco em campos
indiscriminadamente, essa prática é conhecida como folding.
O nome do campo deve ser composto por uma string contendo caracteres na formatação US-ASCII e com valores entre 33 e 126. Já o corpo do campo pode incluir além
desses, o espaço (US-ASCII de valor 32) e o caractere de valor 9, conhecido como aba
horizontal. Não há nenhuma padronização no que diz respeito a ordem em que os campos
aparecem nas mensagens.
Campos obrigatórios (Resnick 2008)
Descrição dos campos obrigatórios em uma mensagem eletrônica e o que cada um
contém.
From
• Date
•
: O endereço de e-mail e o nome do autor, sendo este último opcional.
: O horário local e a data em que a mensagem foi escrita. Pode haver uma
conversão de horários entre o remetente e o destinatário.
Campos recomendados (Resnick 2008)
• Message-ID
• In-Reply-To
: Campo gerado automaticamente e usado para prevenir múltiplas en-
tregas da mesma mensagem e para referência do campo In-Reply-To.
: O Message-ID da mensagem que tem um endereço especíco para
que as respostas sejam encaminhadas. O campo somente se aplica para mensagens
de resposta.
Campos comumente utilizados
• To
• Subject
• Bcc
• Cc
:
O endereço de e-mail dos destinatários das mensagens.
O nome pode ser
incluído também, mas é opcional.
: Traz uma breve descrição do assunto da mensagem. Algumas abreviações
são amplamente utilizadas como RE
4
2
e FW
3
.
: Endereços de e-mail adicionadas à lista de envio do SMTP mas que per-
manece invisível aos outros destinatários.
5
: Não há diferença de funcionalidade em relação ao campo To, porém alguns
provedores de e-mail diferenciam as mensagens dependendo se o usuário estiver na
lista To ou na lista Cc.
•
Content-Type
: Informação a respeito de como a mensagem deve ser exibida. Al-
guns exemplos são text/html ou image/jpeg.
2 RE
indica um 'reply' ou uma resposta ao email anterior.
(Forward) indica que uma cópia da mensagem original foi encaminhada para o destinatário em
questão.
4 Bcc: Blind Carbon Copy (Cópia de Carbono Oculta).
5 Cc: Carbon Copy (com cópia).
3 FW
25
•
Received
:
Informação de rastreamento gerada pelos servidores de e-mail pelos
quais passou a mensagem. Essa informação é gerada na ordem inversa, ou seja, o
último servidor pelo qual passou a mensagem aparece primeiro.
References
• Reply-To
• Sender
•
: O Message-ID da mensagem que é uma resposta e o Message-ID da
mensagem que foi respondida.
: Endereço de e-mail que deverá ser usado para a resposta da mensagem.
: Endereço de quem efetivamente enviou o e-mail em nome do autor listado
no campo From. Utilizado para identicar secretárias, gerentes de listas de e-mail,
etc.
Para registrar um novo campo nos cabeçalhos das mensagens na IANA
6
deve-se seguir
as recomendações propostas no RFC 3864 (Mogul et al. 2004).
3.4 WHOIS
WHOIS é um protocolo de pesquisa e resposta baseado em TCP e muito utilizado
para prover um serviço de informação aos usuários da Internet. Entre as informações que
podem ser obtidas com esse protocolo estão o responsável pelo IP ou endereço, e-mail
para contato, em que país está hospedado o site, etc.(Daigle 2004).
6 Internet
Assigned Numbers Authority: entidade responsável pelo serviço de DNS, endereçamento de
IP e outros protocolos de Internet (IANA 2011).
26
Figura 3.15: Ilustra um exemplo de pesquisa WHOIS utilizando o cliente WHOIS instalado no ambiente linux.
3.4.1 Utilização
O protocolo WHOIS foi originalmente desenvolvido com o propósito de fornecer aos administradores de sistema informações acerca de um endereço de IP ou dos administradores
de um certo domínio.
Os usuários do protocolo podem usar as informações obtidas para uma gama muito
maior de possibilidades. Alguns exemplos mais claros são: determinar se um domínio na
Internet continua ativo, prover contatos para administradores de redes (no caso de um
servidor cair é importante saber a quem noticar).
O exemplo mais relevante para a presente pesquisa é: fornecer um meio pelo qual
empresas, usuários e organizações podem combater fraudes eletrônicas. Isso é feito, pois
os responsáveis por um servidor que esteja hospedando um site malicioso, de phishing
ou spam por exemplo, podem ser rapidamente encontrados e informados do ocorrido.
A facilidade e a rapidez da noticação são peças fundamentais para que medidas sejam
tomadas.
3.4.2 Protocolo
Um servidor WHOIS recebe requisições de clientes na porta TCP 43.
Funciona da
seguinte maneira: um cliente envia uma requisição no formato texto, e o servidor responde
27
com um conteúdo também na forma de texto. A conexão TCP é encerrada assim que a
resposta é enviada.
O presente estudo não objetiva abordar profundamente as especicações técnicas desse
protocolo, para maiores informações consultar em RFCS 3912 (Daigle 2004) e RFC 954
(Harrenstien et al. 1985).
3.4.3 Segurança
É crucial ressaltar que, apesar de ser um protocolo amplamente utilizado para auxílio
em Segurança da Informação na Internet, o WHOIS não possui medidas de segurança
efetivas em si mesmo. Faltam mecanismos de controle de acesso, integridade e condencialidade. O serviço WHOIS, portanto, somente deve ser utilizado para informações não
cruciais e a que todos possam ter acesso (Daigle 2004).
3.4.4 Implementações de servidores
Uma base de dados WHOIS consiste de arquivos de texto para cada endereço.
Os
arquivos de texto consistem basicamente de várias informações a respeito do endereço e
de muitas informações administrativas, como a data de criação por exemplo.
A ideia principal, quando surgiu o protocolo, era que apenas uma agência mantivesse
todos os registros a respeito dos domínios. A agência em questão era a DARPA (Defense
Advanced Research Projects Agency).
Pesquisas WHOIS eram feitas nessa época de
maneira simples, com apenas um servidor centralizado.
Isso ocorria concomitantemente ao surgimento da Internet a partir da antiga ARPANET
(Advanced Research Projects Agency Network). O processo de registro dos nomes dos
domínios foi estabelecido no RFC 920 (Postel and Reynolds 1984).
O crescimento acelerado da Internet tornou inviável que apenas uma agência con-
registrar
registrar
seguisse controlar todos os registros.
Atualmente, temos uma rede muito complexa de
de nomes de domínios similarmente à infraestrutura da Internet que também se
tornou cada vez mais internacionalizada.
Um
de nome de domínio é uma organização ou entidade comercial que tem
o intuito de gerenciar a reserva de nomes de domínio da Internet e disponibilizá-las ao
público(M. Srivastava and Hollenbeck 2000) e (Veeramachaneni et al. 2003). Tem como
guia os registros de nomes de domínio banco de dados responsável pelas informações
daquele TLD (Top-Level Domain).
7
Tendo em vista todo o ocorrido, fazer pesquisas de WHOIS tem como requisito saber
o servidor responsável por aquele domínio.
Não se trata de uma tarefa simples e, por
vezes, algumas ferramentas facilitam o trabalho. Uma consequência dessa complexidade
foi a especialização no tipo de servidores WHOIS em duas categorias de armazenamento
de informações: o modelo Thick e o modelo Thin.
7 TLD é basicamente a terminação de um endereço da Internet, por exemplo www.google.com o TLD
desse endereço é .com.
28
Modelo Thick
Um servidor guarda todas as informações WHOIS de todos os
registrars
8
para um
tipo de terminação especíco. Um servidor pode guardar todas as informações a respeito
Vantagens
dos domínios .com.br por exemplo.
: Dados mais consistentes e consultas mais rápidas, pois só passam por
um servidor.
Modelo Thin
Um servidor guarda apenas o nome dos servidores de modelo Thick responsáveis pelas
informações daqueles registrars.
Um servidor recebe uma requisição para um endereço
Vantagens
.com e repassa para o WHOIS que saiba resolver.
: Gasta menos memória e poupa o usuário de conhecer cada servidor de
WHOIS responsável por qualquer endereço.
3.4.5 Métodos de acesso aos servidores
Os servidores podem ser acessados basicamente por duas maneiras: acesso direto por
meio da porta 43 ou acesso por meio de gateways. Gateways são máquinas intermediárias
que possibilitam a tradução de protocolos. Um gateway na Internet pega uma requisição
na porta 80 padrão, transforma-a em uma requisição WHOIS na porta 43, recebe a
resposta e a devolve na porta 80 novamente, abstraindo todo esse processo do usuário
nal.
3.4.6 Crítica
Não há privacidade de domínio. Detalhes de contatos dos responsáveis, como endereço
e número de telefone, são acessíveis ao público para muitos domínios da Internet. Alguns
registrars oferecem uma possibilidade de se fazer o registro com alguns campos privados
nos quais os campos mostrados são do Registrar ao invés da pessoa física.
Nesses casos porém, é mais difícil para o responsável conrmar o status de seus registros
e as regras da ICANN (Internet Corporation for Assigned Names and Numbers) passam
a responsabilidade desses domínios para o próprio Registrar.
Spammers
9
frequentemente colhem endereços de email por meio de pesquisas WHOIS.
Isso obrigou os sítios que utilizam pesquisas WHOIS a utilizar ferramentas como o CAPTCHA.
10
.
O protocolo WHOIS não levou em consideração a internacionalização da Internet e
utiliza somente caracteres US-ASCII. Não é possível para um cliente WHOIS e até mesmo
para um servidor determinar a codicação do texto da pesquisa, isso pode afetar o uso do
protocolo em alguns países. A aplicação do cliente é a encarregada de fazer a tradução
das codicações para domínios internacionalizados.
8 Registrar
é uma empresa responsável por manter registros nos quais transações de uma natureza
especíca são guardados para conhecimento público.
9 Spammer, dentro do contexto do presente trabalho, pode ser entendido como pessoa que manda
emails padronizados e não esperados em massa
10 Tipos de testes nos quais a maioria dos humanos passa com facilidade, mas os programas de computadores atuais não conseguem passar. (Von Ahn et al. 2003)
29
Figura 3.16: Exemplo de CAPTCHA utilizado atualmente por muitos sítios que disponibilizam consultas WHOIS para limitar a atuação de Spammers.
Figura 3.17: Exemplo de CAPTCHA utilizado pelo sítio usado como fonte de pesquisa
para o desenvolvimento do sistema PhiNo.
30
Capítulo 4
Processo de desenvolvimento da
ferramenta PhiNo
Neste capítulo está descrito todo o processo que culminou no sistema PhiNo, desde o
levantamento de requisitos até os testes de vericação e validação.
4.1 Levantamento de requisitos
Uma reunião inicial foi feita para a etapa de levantamento dos requisitos entre os desenvolvedores e o usuário. Durante essa reunião, o usuário explicou um problema enfrentado
em uma organização pública com relação a e-mails contendo mensagens maliciosas e também todo o esforço e o tempo que eram perdidos no tratamento manual de cada email.
O usuário forneceu os procedimentos adotados por e-mail.
Isso corresponde aos requisitos funcionais do sistema segundo (Sommerville 2007) que
escreve Os requisitos funcionais de um sistema descrevem o que o sistema deve fazer. e
Os requisitos funcionais descrevem a função do sistema detalhadamente, suas entradas e
saídas, exceções, etc.
Torna-se muito importante ressaltar que a metodologia de desenvolvimento utilizada
foi a Prototipação de Software e, portanto, os requisitos foram sendo discutidos e esclarecidos ao longo de todo o desenvolvimento, uma vez que, segundo (Pressman 2006) na
apresentação de protótipos é possível ao usuário acrescentar requisitos e apresentar novas
ideias para os requisitos.
4.2 Projeto
A equipe de desenvolvedores pediu uma semana de prazo para voltar com uma arquitetura do projeto que fosse validada pelo usuário. Uma das vantagens que (Bass 2003)
deixa explícito de projetar e documentar explicitamente uma arquitetura de software é a
comunicação entre as partes interessadas do projeto (Stakeholders), pois a arquitetura é
uma apresentação em alto nível do sistema.
A partir de então, a equipe empregou muito esforço e tempo para a elaboração de uma
arquitetura de projeto de qualidade. A elaboração foi um processo gradual e incremental
que se iniciou como a ilustração a seguir:
31
Figura 4.1: Descrição do comportamento básico com alto nível de abstração
que descrevia basicamente o comportamento do sistema em alto nível tal qual foi
descrito verbalmente pelo usuário.
Após essa etapa, os desenvolvedores apresentaram algumas ideias para aprofundar um
pouco mais o sistema e tirar um pouco da abstração que dicultava a projeção de um
sistema real. O resultado foi esse que se pode observar na gura a seguir:
32
from
Figura 4.2: Descrição do sistema com um nível de abstração menor. *: Campo
do cabeçalho da mensagem.
**: whois.geektools.com.
received
***: emails de noticação
que vem junto com a resposta WHOIS.
que serviu aos seus propósitos e facilitou bastante a formulação do terceiro incremento.
O terceiro incremento já contava com um ambiente sugerido para testes e ferramentas
que precisariam ser utilizadas para o desenvolvimento.
A diminuição da abstração da
primeira para a segunda etapa motivou bastante os programadores e tornou o software
mais palpável segundo um deles.
33
Figura 4.3: Descrição do comportamento real do sistema junto a uma fábrica de emails
received from
maliciosos para facilitar os testes. * Mostrar original no caso de Gmail ou campo Headers
das mensagens em formato .msg. **: Campo
do cabeçalho da mensagem
ou campo X-Originating IP quando presente. ***: whois.geektools.com. ****: emails de
noticação que vem junto com a resposta WHOIS, geralmente algo como [email protected]
ou [email protected].
Tanto esforço e tempo despendidos se justicam, pois, segundo (Hofmeister 1999), o
estágio de projeto de arquitetura força os projetistas de software a considerar aspectos
principais do projeto logo no início.
Os diagramas simples de caixas e linhas foram utilizados por serem ecientes na comunicação entre os stakeholders, uma vez que todos estão envolvidos no projeto e podem
compartilhar esse tipo de visão não abarrotada de detalhes do sistema (Sommerville 2007).
Os diagramas cumpriram seu papel e foram aprovados pelo usuário que representava
a organização pública.
Foi formulada então uma arquitetura de Controle Centralizado
da classe chamada-retorno como a gura a seguir.
A natureza rígida e restritiva desse
módulo traz uma maior facilidade para analisar os uxos de controle e testar como o
sistema responderá a entradas especícas e serviu como justicativa para a sua adoção.
34
Essa característica é bastante desejável em sistemas de desenvolvimento incremental e que
possuem protótipos.
Figura 4.4: Modelo de controle chamada-retorno (Sommerville 2007)
Após a arquitetura estar formulada e os diagramas aprovados, os desenvolvedores
propuseram um novo diagrama para sua aplicação. Esse novo diagrama tinha a nalidade
de criar um ambiente de testes propício para ampará-los no decorrer do desenvolvimento
e, portanto, não era estritamente necessário que os outros stakeholders o conhecessem.
Figura 4.5: Diagrama proposto pelos desenvolvedores com a nalidade de padronizar os
esforços. Ninguém de fora da equipe teve acesso a esse diagrama, pois este deveria ser
tratado como assunto interno e exclusivo de quem codicaria o sistema.
Esse último diagrama continha detalhes de implementação como por exemplo, o uso
de parâmetros para se utilizar a Phishing Factory (fábrica de emails maliciosos). O último
35
desenho se mostrou bastante satisfatório e esclarecedor, porém, ainda assim, ocorreram
modicações no decorrer do desenvolvimento.
A ideia inicial de um Listener foi abandonada no decorrer do projeto por se apresentar
muito dispendiosa em termos computacionais e de desenvolvimento. Assim como o Banco
de Dados de regras foi substituído por regras inclusas dentro do código pois não havia a
necessidade de tanta exibilidade. Os casos de uso e de noticação do sistema são escassos
e não há grandes modicações envolvendo-os.
Isso serve para exemplicar como as etapas de projeto e desenvolvimento estão intimamente ligadas e entrelaçadas. Em um sistema real é difícil determinar onde termina
uma e começa a outra.
4.3 Desenvolvimento
Um processo de desenvolvimento com entregas incrementais foi cogitado pela equipe
porém foi descartado uma vez que os servidores já se utilizavam de estratégias de mediação para a realização manual daquela tarefa extremamente monótona.
Estratégias de
mediação são segundo (de Fátima Rodrigues Colaço et al. 2007) o modo como as pessoas
utilizam meios (instrumentais ou simbólicos) para intermediar suas atividades e a relação entre estados internos, meios disponíveis e resultados esperados segundo (de Aragão
2004). Tendo isso em vista, seria necessário uma motivação para que os servidores públicos do órgão federal participante começassem a usar o sistema e a probabilidade de nem
sequer testarem os releases seria muito grande.
Dessa forma, o método de desenvolvimento escolhido foi o método ágil de Prototipação
de Software.
Um protótipo é uma versão inicial do sistema de software usado para
demonstrar conceitos, experimentar opções de projeto e, geralmente, conhecer mais sobre
o problema e suas possíveis soluções. (Sommerville 2007).
Reuniões quinzenais foram marcadas entre a equipe e o usuário responsável pelo contato entre o órgão público e os desenvolvedores. Durante essas reuniões, versões sem a
funcionalidade completa do software eram apresentadas e discutidas. As reuniões tiveram
extrema importância para a entrega de um produto nal que atendesse as expectativas
do usuário e que tivesse uma qualidade satisfatória do ponto do projeto.
As reuniões esclareceram muitos dos requisitos inciais e acrescentou outros à medida
que a compreensão de todos os stakeholders aumentava em relação ao projeto.
Além
disso, algumas soluções alternativas foram propostas e debatidas, mostrando por vezes
pontos de vista até então inexplorados.
4.3.1 Codicação
A codicação não obedeceu a somente um padrão de desenvolvimento. Foram agregados elementos de diferentes abordagens, principalmente de XP e SCRUM. Reuniões
iniciais e breves, durando cerca de 10 minutos cada, a cada dia de codicação conjunta,
eram regra. Durante essas reuniões, discutia-se o que cada um estava fazendo, as diculdades que se estava encontrando e como planejava superá-las. Tal elemento foi emprestado
do (Schwaber 1997). Um dos elementos importados do XP foi a programação em pares
que foi utilizada durante todo o processo de codicação.
Nesse tipo de programação,
os programadores trabalham em pares, um ajuda o outro e verica o trabalho que está
36
sendo feito também. O uso da programação em pares se justica por ser um modo de
programar mais agradável à maioria dos desenvolvedores além de obter maior qualidade e
precisar de menos tempo em testes, uma vez que a maioria dos erros é detectada enquanto
está sendo digitado(Cockburn and Williams 2001). Outro aspecto importado do XP foi
a propriedade coletiva em que os programadores se revezavam nas diferentes áreas do
código para que não houvesse focos de conhecimento especícos do código que não fossem
comuns a todos da equipe.
4.3.2 Testes
Os testes não foram realizados somente após a codicação terminada e não constituíram uma etapa isolada. Durante toda a codicação, a equipe de desenvolvedores estava
sempre atenta aos possíveis erros e pensando nas melhores maneiras de testar o sistema.
O foco seguido para a realização de testes foi principalmente os processos de Vericação
e de Validação. Explicando melhor, (Boehm 1979) explicitou a diferença entre Validação
e Vericação da seguinte maneira: Validação: Estamos construindo o produto correto?
e Vericação: Estamos construindo o produto corretamente?
Dessa maneira, testes de validação foram usados para mostrar que o PhiNo realmente
obedecia a seus requisitos.
Os desenvolvedores tiveram acesso a quarenta e-mails ma-
liciosos reais que haviam sido noticados pelo órgão público federal e que haviam sido
salvos em um Banco de Dados. De posse disso, cada um dos requisitos foi testado, pelo
menos uma vez, juntamente com o usuário e, ao nal, obteve sucesso em todos os casos
previstos nos testes.
Outro tipo de teste também foi utilizado. O chamado teste de defeitos visa descobrir
falhas ou defeitos no software que apresenta comportamento incorreto ou não desejável.
Alguns dos testes utilizados pelos desenvolvedores foram por exemplo: um ambiente com
o servidor de banco de dados o-line ou sem conexão com a Internet (pressupostos básicos
e especicados no Leia-me anexo ao software).
Como declarou (Dijkstra 1972) Os testes podem somente demonstrar a presença de
erros, não a sua ausência. Os testes não podem demonstrar que um software é livre de
defeitos ou testar todos os casos de uso possíveis. Os testes devem ser feitos de maneira
a abranger uma boa gama de opções e ter sucesso em todas elas.
Para exemplicar melhor que nem tudo pode ser testado à exaustão, um problema bem
simples e corriqueiro: Como testar se os fósforos vão funcionar? Uma vez testados, eles
não poderão mais ser utilizados. As empresas fabricantes de fósforos testam uma amostra
do total e obtém a porcentagem de sucesso, se o resultado for considerado satisfatório, o
produto pode ser comercializado.
De maneira similar, isso ocorreu com o sistema PhiNo, a equipe testou muitos casos
de uso e obteve resultados positivos em todos os testados.
Assim, o software pôde ser
entregue para testes em um ambiente real com uma maior probabilidade de sucesso.
4.3.3 Phishing Notier
O sistema Phishing NotierPhiNo foi desenvolvido com o propósito de facilitar e
agilizar o processo de noticação das autoridades competentes à respeito de emails de
37
Phishing ou Spam. O esperado é que, facilitado esse trabalho que costuma ser maçante e
tomar um tempo razoável dos usuários, eles passem a fazê-lo com maior frequência.
Trata-se de uma etapa fundamental e, por muitas, vezes subestimada por todos. Basta
vericar a quantidade de artigos e de trabalhos cientícos que focam na prevenção de
ataques e a quantidade (bem menor) de trabalhos que focam na área de resposta e tratamento.
Uma mudança de mentalidade precisa ser feita. O sistema, ao agilizar o trabalho de
noticação, pode ter papel crucial nessa mudança.
Espera-se que diminua bastante a
inadimplência com relação a esse aspecto devido as facilidades trazidas pelo PhiNo.
O sistema PhiNo foi desenvolvido usando a tecnologia Java.
Isso foi feito com o
objetivo primário de ser portável para virtualmente quase todos ambientes de execução.
Um dos poucos requisitos necessários para que isso ocorra é que o ambiente possua uma
Java Runtime Enviroment instalada.
O outro requisito principal se refere à necessidade de um servidor de banco de dados
MySQL estar instalado na máquina.
É crucial ressaltar que todos os requisitos estão
explícitos no documento Leia-me fornecido juntamente com o software.
A interface gráca foi desenvolvida com o auxílio do pacote java.swing.
A gura a
seguir mostra o exemplo de uma tela inicial:
Figura 4.6: Exemplo de um email aberto com o auxílio do sistema PhiNo
O programa recebe emails potencialmente maliciosos e os salva automaticamente no
Banco de Dados à espera da triagem feita pelos usuários. Para facilitar e para aumentar
a eciência dessa triagem, uma tela com os emails salvos no Banco de Dados é exibida aos
usuários e os cabeçalhos, conteúdo e potenciais servidores a serem pesquisados no serviço
Whois.
Whois 3.4 é um protocolo de pesquisa/resposta orientado a transação e baseado em
TCP que é muito usado para prover um serviço de informações aos usuários da Internet.
A pesquisa no Whois tem o intuito de obter quem é o responsável por aquela rede e
38
informá-lo que estão usando alguns de seus endereços com o propósito de aplicar golpes
em pessoas.
Esclarecendo, com base no cabeçalho de cada email, o PhiNo identica os servidores
que potencialmente precisam ser pesquisados usando o serviço Whois, para que isso seja
possível exclui os servidores que aparecem no cabeçalho devido a redirecionamentos para
a caixa de noticação.
Assim sendo, o usuário pode escolher quais dos servidores possíveis ele deseja realmente
investigar e se necessário noticar. Outra possibilidade aberta pelo PhiNo é que o usuário
selecione qualquer link contido dentro do conteúdo do email possivelmente malicioso e o
investigue, novamente tornando o trabalho menos dispendioso e mais rápido.
Uma vez que um servidor é investigado por Whois abre-se a seguinte tela do Phishing
Notier :
Figura 4.7: Exemplo do comportamento do sistema PhiNo ao receber a resposta de um
servidor WHOIS e montar automaticamente uma sugestão de email de noticação para
os responsáveis.
Todas as informações de Whois são expostas ao usuário para que, se julgar necessário,
tome providências diferentes das previstas pelo sistema.
Além disso, o sistema auto-
maticamente cria um email sugerido contendo os endereços de email obtidos no Whois e
o cabeçalho da mensagem potencialmente maliciosa com o assunto Suspected phishing
attempt.
O usuário ainda pode acrescentar informações que julgar imprescindíveis ao
conteúdo do email ou até mesmo incluir outros emails a serem noticados.
Uma vez que o usuário enviar o email, automaticamente este vai para a caixa de
processados do programa.
Para ns de histórico, são salvos todos os emails que foram
noticados e exibidos sempre que o usuário desejar.
A triagem feita pelo usuário é parte crucial no proposto por esse sistema. Ao ler um
email, um usuário pode julgar que não se trata de um email malicioso e, rapidamente,
encaminhá-lo à lixeira do programa.
39
Capítulo 5
Resultados e Análise
Este capítulo descreve os resultados obtidos tanto nas simulações quanto no ambiente
real da organização. Descreve também a análise feita de posse desses dados.
5.1 Resultados
Após o desenvolvimento do sistema e a vericação das funcionalidades existentes para
atender aos requisitos, foram realizados testes para aferir o desempenho e usabilidade do
sistema. Os testes foram divididos em duas partes: a primeira, uma simulação de noticação de Phishing realizada pelos próprios desenvolvedores da ferramenta, e, a segunda,
testes com o grupo de usuários que deniu as funcionalidades necessárias para noticação
em uma organização pública federal.
5.1.1 Simulação
Nesta etapa, os desenvolvedores seguiram os passos descritos nos procedimentos adotados pelo grupo de usuários que deniu as funcionalidades na organização pública federal.
Um total de 12 emails foram noticados e tiveram seus tempos precisamente cronometrados. Seguem abaixo os passos descritos nos procedimentos:
1. Se o remetente for o Gmail, reportar o problema em
http : //mail.google.com/support/bin/request.py?contactt ype = abuse_phishing
2. Obter Cabeçalhos de Internet da mensagem (válido para o Outlook):
(a) Dar duplo clique na mensagem.
(b) Na barra de menu de arquivo, clicar em "Exibir"e selecionar "Opções".
(c) Copiar Cabeçalhos de Internet.
(d) Identicar o IP do último servidor de email que entregou a mensagem aos relays
da Organização.
(e) No caso de webmail, identicar o IP da máquina de origem.
3. Fazer pesquisa no protocolo WHOIS pelo responsável do IP remetente da mensagem
e, no caso de webmail, do responsável pela rede do cliente.
40
4. No caso de phishing scam, executar passos adicionais de acordo com a política de
cada organização.
5. Criar novo email.
(a) Se o campo "De..."não estiver sendo exibido, na barra de menu de arquivo,
clicar em "Exibir"e marcar opção "Campo De".
(b) No campo "De...", digitar email da organização responsável pela noticação.
(c) No campo "Para...", inserir email dos responsáveis pelo servidor de email e, se
for o caso, da estação que fez a conexão ao webmail.
(d) No campo Cc, incluir [email protected].
i. No caso de phishing, incluir [email protected].
(e) No campo Cco, incluir o email da Symantec de análise de emails, [email protected].
(f ) No corpo do email, colar as informações do "Cabeçalhos de Internet".
(g) Anexar o email original para comprovar reclamação quando o tamanho da
mensagem não for grande.
6. Responder ao usuário que as ações pertinentes foram executadas.
7. Enviar todas as mensagens enviadas e recebidas para o arquivo responsável por
manter casos de spam e phishing na organização.
A equipe de pesquisadores anotou os tempos cronometrados e, em seguida, utilizou o
sistema PhiNo para noticar os mesmos emails. É crucial ressaltar que os fatores críticos,
nesses últimos testes, foram a usabilidade e o tempo. De posse de todos os dados, a equipe
montou a tabela comparativa:
Tabela 5.1:
Comparação entre os passos executados manualmente e com o auxílio do
PhiNo
Teste de desempenho do procedimento de noticação (minutos:segundos)
Passos executados manualmente
Noticação com PhiNo
05:26
00:37
05:01
00:32
04:43
00:27
04:18
00:25
04:16
00:24
03:55
00:24
03:51
00:23
03:42
00:20
03:02
00:19
03:01
00:18
02:54
00:17
02:52
00:16
A média de tempo com os passos executados manualmente foi de aproximadamente 3
minutos e 54 segundos, para a execução com o PhiNo foi de aproximadamente 24 segundos.
41
5.1.2 Resultados no ambiente real da organização
O sistema está em utilização na organização pública federal desde o dia 21/06/2011.
Até o momento, foram obtidos poucos resultados, porém satisfatórios.
São necessárias
mais amostras de forma a se obter a evidência concreta da boa performance da ferramenta proposta. De modo a certicar a performance dessa ferramenta foi proposto um
questionário de avaliação. O formulário está anexo a essa monograa e fornecerá resultados vitais para a análise da performance do PhiNo.
Constantemente, membros do grupo de usuários que utilizam a ferramenta PhiNo reportam a facilidade de utilização do sistema e a rapidez na noticação de emails com
códigos maliciosos que utilizam técnicas de Phishing e Spam. Atribuem essas características ao projeto do sistema que inova o método de trabalho do grupo ao adotar uma única
interface para os diversos passos a serem seguidos nas suas rotinas diárias.
5.2 Análise dos resultados
Os resultados obtidos foram considerados satisfatórios pelos desenvolvedores. Os resultados indicam que, utilizando o sistema PhiNo para noticar um Phishing ou Spam,
um usuário gastaria em média pouco mais de 10% do tempo que levaria para noticar o
mesmo email manualmente.
A segurança das atividades eletrônicas quase sempre está em segundo plano para o
usuário (Wu et al. 2006).
O tempo gasto para noticar as autoridades responsáveis é
considerado muito alto pelos mesmos e, por isso, o número de noticações está longe de
ser o ideal. Um ganho tão signicativo como o que foi obtido pelo sistema PhiNo pode
motivar os usuários a incluir as atividades de noticação ao seu cotidiano, pois o tempo
gasto não seria considerado elevado.
42
Capítulo 6
Conclusão
O primeiro objetivo deste trabalho era realizar um estudo do problema relacionado a
e-mails maliciosos de Phishing e Spam, bem como fazer um levantamento das ferramentas
e das soluções presentes na literatura para mitigar esse problema.
O segundo objetivo consistia em propor, implementar e analisar uma ferramenta cujo
propósito é noticar casos de Phishing e Spam em e-mails, congurando assim uma situação de resposta a incidentes.
De modo a atingir o primeiro objetivo, foi estudado um conjunto de publicações cientícas que propunha formas de prevenção desses tipos especícos de embuste. Nessa fase,
constatou-se a escassez de literatura em língua portuguesa acerca do tema em questão. A
escassez é ainda maior no que tange à questão de resposta a incidentes, tanto no idioma
Português quanto em outros idiomas. Espera-se que esse trabalho possa suprir um pouco
dessa lacuna.
Tendo em vista a escassez de soluções propostas no contexto de resposta a incidentes,
os pesquisadores propuseram a criação da ferramenta PhiNo Phishing Notier - ferramenta esta que adveio do estudo das ações a serem executadas em casos de Phishing e
Spam em uma organização pública federal notavelmente consciente em relação à segurança da informação. A ferramenta foi construída de forma a unir todas as ações em uma
única interface, visando, principalmente, usabilidade e ganho de tempo no processo de
noticação de incidentes de segurança.
Os testes da ferramenta, além de serem parte integrante e fundamental no processo de
desenvolvimento da mesma, foram divididos em duas partes após o término da codicação.
A primeira parte consistiu em uma simulação feita pelos próprios desenvolvedores a m de
comparar o tempo gasto no processo de noticação com e sem o uso do PhiNo. A segunda
parte, iniciada na data 21/06/2011, consistiu em implantar o PhiNo no contexto de uma
organização pública federal e avaliá-lo por meio de um questionário a ser respondido pelos
usuários nais.
Os testes de simulação indicaram que uma noticação feita com o auxílio do PhiNo
demora cerca de 10,25% do tempo total gasto em uma noticação feita da forma descrita
pela organização.
Em termos de usabilidade, a avaliação dos usuários foi positiva no
sentido de que agrega todos os passos necessários da ação de noticar em uma única
interface.
Com este trabalho, foi possível conhecer as diversas ferramentas de cunho preventivo
no que tange a Phishing e Spam, e também constatar a lacuna existente no que concerne à
43
resposta a incidentes. Conclui-se então que o PhiNo, proposto para diminuir essa lacuna,
cumpre bem o seu papel e apresenta resultados satisfatórios.
Como trabalhos futuros, para aprimoramento do PhiNo, cogita-se melhorias na interface da ferramenta bem como a adição de funcionalidades conforme forem surgindo
provenientes do uso continuado.
44
Referências
Creating a Computer Security Incident Response Team: A Process for Getting Started
.
CERT. 23
Csirt faq. 24
(1972).
(1999).
(2003).
(2003).
(2003).
(2006).
(2007).
(2007).
Structured Programming
Applied Software Architecture
A arte de enganar
Segurança dos Sistemas de Informação
Software architecture in practice
Engenharia de Software
Engenharia de Software
Segurança de Redes em Ambientes Cooperativos
. Academic Press. 37
. Addison-Wesley Professional. 34
. Pearson Makron Books. 2
. Centro Atlantico PT. 22, 23
. Addison-Wesley Professional. 31
. McGraw-Hill. 31
. Addison Wesley Editora. x, 31, 34, 35, 36
. Novatec. 2
(2010). Engenharia social. 1
(2011). Engenharia social. 1
(2011). Engenharia social (segurança da informação). 1
(2011). Estatísticas de noticações de spam reportadas ao cert.br. ix, 22
(2011). Iana - internet assigned numbers authority. 26
MIT Press
Boehm, B. W. (1979). Software engineering; r&d trends and defense needs. in research
directions in software technology (p. wegner, ed.).
University of Utah Computer Science Journal
Cockburn, A. and Williams, L. (2001).
, pages 19. 37
The costs and benets of pair programming.
. 37
Daigle, L. (2004). Rfc 3912: Whois protocol specication. 26, 28
de Aragão, J. P. (2004). Exigências cognitivas e estratégias de mediação em auditoriascal da previdência social no distrito federal: Errar é preocupante, rescalizar é pior.
Master's thesis, Universidade de Brasília, Instituto de Psicologia. 36
45
de Fátima Rodrigues Colaço, V., Pereira, E., Neto, F. E. P., Chaves, H. V., and de Sá,
Estudos de Psicologia (Natal)[online]. 2007, vol.12, n.1
T. S. (2007). Estratégias de mediação em situação de interação entre crianças em sala
de aula.
, pages 4756. 36
Proceeding SOUPS '05 Proceedings of the 2005 symposium on Usable privacy and security
Proceedings of
the SIGCHI conference on Human factors in computing systems
Dhamija, R. and Tygar, J. (2005). The battle against phishing: Dynamic security skins.
. 5
Dhamija, R., Tygar, J., and Hearst, M. (2006). Why phishing works. In
, pages 581590. ACM.
10
Conference on Email and Anti-Spam 2004
Drake, C. E., Oliver, J. J., and Koontz, E. J. (2004).
Anatomy of a phishing email.
. 11
Eiras, M. C. (2004). Engenharia social e estelionato eletrônico.
16th international conference on World Wide Web
IBPI
. 1, 2
Fette, I. and Tomasic, A. (2007). Learning to detect phishing emails.
Proceedings of the
, pages 649656. 2
Jus Navigandi
Filho, D. R. (2006). A responsabilidades dos bancos pelos prejuízos resultantes do phishing.
. 1
Grupo de Trabalho em Segurança de Redes, G. (1999).
de resposta a incidente de segurança em computador.
Expectativas quanto a grupos
Technical report, Núcleo de
Informação e Coordenação do Ponto BR - NIC.br. 21
Harrenstien, K., Stahl, M., and Feinler, E. (1985). Rfc 954: Nicname/whois. 28
Computer Science Department Bar Ilan University
Herzberg, A. and Gbara, A. (2004). Trustbar: Protecting (even naive) web users from
spoong and phishing attacks.
. 6
John Ha, A. B. (2005). Guia de segurança. Technical report, Red Hat Enterprise Linux
4. 22, 23
Leyden, J. (2004). Fear of phishing hits e-commerce. 11
M. Srivastava, S. and Hollenbeck (2000). Rfc 2832: Nsi registry registrar protocol (rrp)
version 1.1.0. 28
Microsoft (2007). Engenharia social, phishing e mensagens de correio eletrônicas fraudulentas. Technical report, Microsoft Corporation. 1
Mogul, J., Nottingham, M., and Klyne, G. (2004). Rfc 3864: Registration procedures for
message header elds. 26
Popper, M. A. and Brignoli, J. T. (2008). Egenharia social - um perigo eminente. Master's
thesis, Instituto Catarinense de Pós-Graduação - ICPG. 2
Postel, J. and Reynolds, J. (1984). Rfc 920: Domain requirements. 28
Resnick, P. (2008). Rfc 5322: Internet message format. 24, 25
46
Schwaber, K. (1997). Scrum development process.
Advanced Development Methods
. 36
Veeramachaneni, S., Hollenbeck, S., and Yalamanchilli, S. (2003).
rfc 3632:
Verisign
registry registrar protocol (rrp) version 2.0. 0. 28
Advances in CryptologyEUROCRYPT 2003
Von Ahn, L., Blum, M., Hopper, N., and Langford, J. (2003). Captcha: Using hard ai
problems for security.
29
, pages 646646.
Warner, B. (2004). Billions of `phishing' e-mails sent monthly.
phishing attacks?
In
. 12
Proceedings of the SIGCHI conference on Human Factors in
Wu, M., Miller, R., and Garnkel, S. (2006).
computing systems
Reuters
, pages 601610. ACM. 42
47
Do security toolbars actually prevent

ver/abrir - Repositório do Departamento de Ciência da Computação

Transcrição

Documentos relacionados

Inscrição Newsletter

Ataque Phishing Scam

Baixar PDF da Autorização

Email Phishing e Scam - Securing The Human

Informações da Organização Informações do Representante

Criar a Conta - CEFET

Criar a Conta Única - cefet-mg

Email Marketing

PRESS RELEASE

formulário para cotação de lunetas dados da empresa