Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação PhiNo - Phishing Notier Ferramenta para noticar s 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

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação 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 s com códigos maliciosos que utilizam técnicas de Phishing e Spam / Gabriel Velasco Braga, Isabella Pinheiro Tavares. Brasília : UnB, p. : il. ; 29,5 cm. Monograa (Graduação) Universidade de Brasília, Brasília, Phishing, 2. Spam, 3. , 4. Incidentes, 5. Tratamento, 6. Resposta a Incidentes CDU Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP BrasíliaDF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação PhiNo - Phishing Notier Ferramenta para noticar s 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 Prof. Dr. Anderson Nascimento (Orientador) ENE/UnB Prof. MSc. Lucas Ferreira CIC/UnB Prof. MSc. João Gondim CIC/UnB Prof. Dr. Marcus Vinicius Lamar Coordenador do Bacharelado em Ciência da Computação Brasília, 13 de julho de 2011

4 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. Isabella Pinheiro Tavares i

5 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. Gabriel Velasco Braga ii

6 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. Isabella Pinheiro Tavares iii

7 Agradecimentos Registro meus sinceros agradecimentos: a Deus, fonte inesgotável de amor e alento, por absolutamente tudo. Aos professores 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. Gabriel Velasco Braga iv

8 Resumo Este trabalho apresenta um estudo do crescente número de ataques por s 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 s cujos conteúdos são previamente reportados como Phishing ou Spam. Palavras-chave: Phishing, Spam, , Incidentes, Tratamento, Resposta a Incidentes v

9 Abstract This undergraduate dissertation presents a study about the growing number of attacks by malicious s 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 s whose content are previously reported as Phishing or Spam. Keywords: Phishing, Spam, , Incidents, Treatment, Incident Response vi

10 Sumário 1 Introdução Objetivo Justicativa Metodologia Organização dos Capítulos Capítulo 1 - Introdução Capítulo 2 - Outras propostas de combate a Phishing Capítulo 3 - Preliminares Capítulo 4 - Processo de desenvolvimento da ferramenta PhiNo Capítulo 5 - Resultados e Análise Capítulo 6 - Conclusão Outras propostas de combate a Phishing Certicação por terceiros Modelos de conança hierárquicos e distribuídos Trustbar Autenticação direta Autenticação do usuário por múltiplos fatores Autenticação de servidor usando segredos compartilhados Autenticação de servidor usando segredos compartilhados entre usuário e seu próprio dispositivo Ferramentas Anti-Phishing Barra de ferramentas do ebay Spoofguard Spoofstick Conclusão do capítulo Preliminares Artifícios usados em s de Phishing Técnicas conhecidas de ataque Resposta a incidentes A resposta ao incidente Grupo de Resposta a Incidentes de Segurança em Computadores Cabeçalhos de mensagens eletrônicas Campos do Cabeçalho WHOIS vii

11 3.4.1 Utilização Protocolo Segurança Implementações de servidores Métodos de acesso aos servidores Crítica Processo de desenvolvimento da ferramenta PhiNo Levantamento de requisitos Projeto Desenvolvimento Codicação Testes Phishing Notier Resultados e Análise Resultados Simulação Resultados no ambiente real da organização Análise dos resultados Conclusão 43 Referências 45 viii

12 Lista de Figuras 2.1 Screenshot da Trustbar em funcionamento Ilustra um exemplo de alternância da borda do Browser contendo link que, aparentemente, levará o usuário a Exemplo de de phishing que faz uso da imagem de uma organização de boa reputação Conteúdo de malicioso cujo endereço de resposta difere do remetente Cabeçalho expandido para evidenciar a disparidade entre o remetente e o de resposta Exemplo de malicioso que faz uso de premissa plausível para ludibriar o usuário Embuste que exige resposta rápida do usuário Selo Site Blindado Selo de Vericação da Verisign Selo da Certisign Embuste que simula um do Banco Itaú contendo link para uma página que deveria servir para atualizar os dados do usuário Endereço da real página que coletaria as informações Evidencia o redirecionamento com o auxílio do PhiNo. O link, na verdade, vai para Gráco com a quantidade de spams reportados ao CERT.br por ano(cert 2011) Ilustra um exemplo de cabeçalho de mensagem eletrônica encontrado na Internet Ilustra um exemplo de pesquisa WHOIS utilizando o cliente WHOIS instalado no ambiente linux Exemplo de CAPTCHA utilizado atualmente por muitos sítios que disponibilizam consultas WHOIS para limitar a atuação de Spammers Exemplo de CAPTCHA utilizado pelo sítio usado como fonte de pesquisa para o desenvolvimento do sistema PhiNo Descrição do comportamento básico com alto nível de abstração Descrição do sistema com um nível de abstração menor. *: Campo received from do cabeçalho da mensagem. **: whois.geektools.com. ***: s de noticação que vem junto com a resposta WHOIS ix

13 4.3 Descrição do comportamento real do sistema junto a uma fábrica de s maliciosos para facilitar os testes. * Mostrar original no caso de Gmail ou campo Headers das mensagens em formato.msg. **: Campo received from do cabeçalho da mensagem ou campo X-Originating IP quando presente. ***: whois.geektools.com. ****: s de noticação que vem junto com a resposta WHOIS, geralmente algo como abuse@mail.com ou report@mail.com Modelo de controle chamada-retorno (Sommerville 2007) 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 Exemplo de um aberto com o auxílio do sistema PhiNo Exemplo do comportamento do sistema PhiNo ao receber a resposta de um servidor WHOIS e montar automaticamente uma sugestão de de noticação para os responsáveis x

14 Lista de Tabelas 5.1 Comparação entre os passos executados manualmente e com o auxílio do PhiNo xi

15 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 , 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

16 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 s 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 s, não se pode deixar de abordar a modalidade de ataque denominada Spam, 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

17 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 s 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 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

18 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 Capítulo 3 - Preliminares Capítulo que abrange os conceitos básicos necessários ao entendimento da proposta do trabalho 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 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 Capítulo 6 - Conclusão Capítulo nal do trabalho, concludente, que apresenta os resultados obtidos e sugestão de trabalhos futuros. 4

19 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 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

20 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 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

21 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 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

22 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 Dinamicamente é 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

23 2.3 Ferramentas Anti-Phishing 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 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 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 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

24 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 que contenha phishing ou spam, de um 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

25 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 s de Phishing s 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). s 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) 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 s 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 s 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 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

26 Esses s 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 é, na verdade, uma fraude ou acreditar que se trata de um equívoco e simplesmente ignorá-lo. Entretanto, os atacantes enviam milhares de s 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 s 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 fraudulento direciona a vítima a um sítio de phishing, mas muitos s incluem outros links para o sítio real da organização de forma a conferir mais credibilidade ainda àquela mensagem. O parece ser da organização imitada: para posterior convencimento do destinatário de que o origina de uma companhia de boa reputação, os atacantes usam s que parecem ser da organização por meio do domínio da empresa, por Exemplo: Figura 3.1: Exemplo de de phishing que faz uso da imagem de uma organização de boa reputação 12

27 Endereço de resposta díspare do remetente Em alguns s fraudulentos, o atesta ser de uma empresa legítima, mas a resposta é congurada para ser enviada a um ilegítimo. Como, por exemplo, ilustrado já com o uso da ferramenta PhiNo: Figura 3.2: Conteúdo de malicioso cujo endereço de resposta difere do remetente. A seguir, a expansão do cabeçalho que permite averiguar a disparidade entre os endereços de remetente e de resposta: 13

28 Figura 3.3: Cabeçalho expandido para evidenciar a disparidade entre o remetente e o de resposta. Criação de premissa plausível Após o convencimento do destinatário de que o veio de uma organização legítima, o deve conter uma premissa plausível capaz de persuadir o usuário a fornecer a informação pessoal. O 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

29 Figura 3.4: Exemplo de malicioso que faz uso de premissa plausível para ludibriar o usuário. Ironicamente, as mensagens de freqüentemente usam o medo das pessoas por fraude para defraudá-las: os s 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 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 , como pode-se perceber no exemplo a seguir: 15

30 Figura 3.5: Embuste que exige resposta rápida do usuário. Promessa de segurança s 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 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, o selo de vericação da Verisign, Figura 3.6: Selo Site Blindado o selo da CertiSign, Figura 3.7: Selo de Vericação da Verisign Figura 3.8: Selo da Certisign 16

31 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 s 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 do Banco Itaú contendo link para uma página que deveria servir para atualizar os dados do usuário. 17

32 Figura 3.10: Endereço da real página que coletaria as informações. O texto do link no 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 parece que vai mandar o usuário para mas, na verdade, trata-se de uma forma de redirecionamento que o manda para Figura 3.11: contendo link que, aparentemente, levará o usuário a 18

33 Figura 3.12: Evidencia o redirecionamento com o auxílio do PhiNo. O link, na verdade, vai para 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 do usuário. O código seguinte foi tirado de um fraudulento simulando o PayPal. Quando o usuário passa o mouse sobre o link, a barra de status irá mostrar https : // bin/webscr?cmd = l ogin run. Entretanto o link na verdade direciona o usuário a < Aonmouseover = window.status = https : // bin/webscr?cmd = _login run ; returntrue onmouseout = window.status = https : // bin/webscr?cmd = _loginrun href = http : //leasurelandscapes.com/snow/webscr.dllhttps : // = _login run < /A > Uso do endereço IP No exemplo do item acima, o código mostra claramente a real destinação do link: 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 usado em mensagem de fraudulenta é Um endereço de IP pode ser obscurecido posteriormente se expressado em formato Octal ou Hexadecimal. Uso do para confundir Quando o é usado em uma URL ou todo o texto anterior ao é ignorado e o navegador referencia apenas a informação seguinte Em outras palavras, se o formato < userinf o < host > for usado, o navegador 19

34 é direcionado ao sítio de < host > e a parte < userinfo > é 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 quando na verdade está indo para o site fraudulento contido no link após o Ocultação da informação do servidor Links que usam o formato < userinfo < host > em s, algumas vezes dão um passo adiante no artifício ao adicionar um caractere nulo ou não imprimível antes do 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 < userinfo >< 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: O caractere representado por %00 faz com que apenas a <userinfo> 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, /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: 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 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: 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 é 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

35 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 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 é seguido de `:8034', que representa a porta 8034 especicada. 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 Os primeiros s contendo phishing usavam formulários HTML no 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 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

36 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 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

37 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) 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

38 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 . 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 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

39 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: O endereço de e o nome do autor, sendo este último opcional. Date: 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: Campo gerado automaticamente e usado para prevenir múltiplas entregas da mesma mensagem e para referência do campo In-Reply-To. 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: O endereço de dos destinatários das mensagens. incluído também, mas é opcional. O nome pode ser Subject: Traz uma breve descrição do assunto da mensagem. Algumas abreviações são amplamente utilizadas como RE 2 e FW 3. Bcc 4 : Endereços de adicionadas à lista de envio do SMTP mas que permanece invisível aos outros destinatários. Cc 5 : Não há diferença de funcionalidade em relação ao campo To, porém alguns provedores de 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. Alguns exemplos são text/html ou image/jpeg. 2 RE indica um 'reply' ou uma resposta ao anterior. 3 FW (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). 25

40 Received: Informação de rastreamento gerada pelos servidores de 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: O Message-ID da mensagem que é uma resposta e o Message-ID da mensagem que foi respondida. Reply-To: Endereço de que deverá ser usado para a resposta da mensagem. Sender: Endereço de quem efetivamente enviou o em nome do autor listado no campo From. Utilizado para identicar secretárias, gerentes de listas de , 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, 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

41 Figura 3.15: Ilustra um exemplo de pesquisa WHOIS utilizando o cliente WHOIS instalado no ambiente linux 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 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

42 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) 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) 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 conseguisse controlar todos os registros. Atualmente, temos uma rede muito complexa de registrar de nomes de domínios similarmente à infraestrutura da Internet que também se tornou cada vez mais internacionalizada. Um registrar 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 o TLD desse endereço é.com. 28

43 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 dos domínios.com.br por exemplo. Vantagens: 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.com e repassa para o WHOIS que saiba resolver. Vantagens: Gasta menos memória e poupa o usuário de conhecer cada servidor de WHOIS responsável por qualquer endereço 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 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 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 s 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

44 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

45 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 s contendo mensagens maliciosas e também todo o esforço e o tempo que eram perdidos no tratamento manual de cada . O usuário forneceu os procedimentos adotados por . 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

46 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

47 Figura 4.2: Descrição do sistema com um nível de abstração menor. *: Campo received from do cabeçalho da mensagem. **: whois.geektools.com. ***: s 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

48 Figura 4.3: Descrição do comportamento real do sistema junto a uma fábrica de s maliciosos para facilitar os testes. * Mostrar original no caso de Gmail ou campo Headers das mensagens em formato.msg. **: Campo received from do cabeçalho da mensagem ou campo X-Originating IP quando presente. ***: whois.geektools.com. ****: s de noticação que vem junto com a resposta WHOIS, geralmente algo como abuse@mail.com ou report@mail.com. 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

49 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 s maliciosos). O último 35

50 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 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

51 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 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 s maliciosos 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 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 s de 37

52 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 aberto com o auxílio do sistema PhiNo O programa recebe s 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 s 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

53 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 , 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 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 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 automaticamente cria um sugerido contendo os endereços de 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 ou até mesmo incluir outros s a serem noticados. Uma vez que o usuário enviar o , automaticamente este vai para a caixa de processados do programa. Para ns de histórico, são salvos todos os s 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 , um usuário pode julgar que não se trata de um malicioso e, rapidamente, encaminhá-lo à lixeira do programa. 39