biblioteca digital de teses e dissertações da usp - seguranÇa … · 2006. 9. 13. · • de...

ARTHUR WONGTSCHOWSKI

SEGURANÇA EM APLICAÇÕES TRANSACIONAISNA INTERNET: O ELO MAIS FRACO

Dissertação apresentada à Escola Politécnica

da Universidade de São Paulo para obtenção

do Título de Mestre em Engenharia.

São Paulo2005

ARTHUR WONGTSCHOWSKI

SEGURANÇA EM APLICAÇÕES TRANSACIONAISNA INTERNET: O ELO MAIS FRACO

Dissertação apresentada à Escola Politécnica

da Universidade de São Paulo para obtenção

do Título de Mestre em Engenharia.

Área de Concentração:

Sistemas Digitais

Orientador:

Wilson V. Ruggiero

São Paulo2005

Este exemplar foi revisado e alterado em relação à versão original, sobresponsabilidade única do autor e com a anuência de seu orientador.

São Paulo, 16 de maio de 2006.

Assinatura do autor

Assinatura do orientador

FICHA CATALOGRÁFICA

Wongtschowski, ArthurSegurança em aplicações transacionais na Internet: o elo mais

fraco/ A. Wongtschowski. – ed. rev. – São Paulo, 2005.108 p.

Dissertação (Mestrado) — Escola Politécnica da Universidadede São Paulo. Departamento de Engenharia de Computação e Sis-temas Digitais.

1. Redes de computadores (Segurança). 2. INTERNET. I.Universidade de São Paulo. Escola Politécnica. Departamento deEngenharia de Computação e Sistemas Digitais. II. t.

AGRADECIMENTOS

Agradeço ao meu orientador, Wilson Ruggiero, pelos conselhos valiosos que sem-pre me direcionaram para o melhor caminho. Agradeço também ao amigo e mestrePaulo Barreto, um exemplo de pessoa e de profissional a ser seguido.

RESUMO

O problema das fraudes virtuais em serviços deInternet Bankinge comércio ele-trônico vem crescendo a cada dia. Em 2005, as fraudes virtuais representaram, noBrasil, uma perda de 300 milhões de reais. Neste trabalho, apresentamos inicialmenteo cenário atual das fraudes, especificando quais ataques elas utilizam, como são hojeexecutadas e quais vulnerabilidades exploram. Cada ataque éclassificado conformeuma nova taxonomia criada. São também apresentadas possíveis defesas contra essesataques, indicando a efetividade de cada uma. Analisamos também o ponto de vistada privacidade do usuário para cada uma dessas soluções. Comocontribuição original,esse trabalho apresenta uma solução de curto prazo, que opera sobre a infra-estrutura jáexistente, que visa reduzir o problema das fraudes. São feitas também consideraçõessobre possíveis soluções de longo prazo de maior efetividade e que promovam umadefesa mais estrutural.

ABSTRACT

The problem of virtual frauds in Internet Banking and electronic commerce ser-vices is growing each day. In 2005, the virtual frauds represented a damage of 300million reais in Brazil. In this work, we present initially the current scenario of virtualfrauds, specifying what attacks are used, how they are executed and which vulnerabi-lities they exploit. Each attack will be classified in accordance to a new methodology.We also present defenses against these attacks, indicatingthe effectiveness and intru-sion of each one of them. In the end, a short term and defensivesolution is presented toreduce the problem of virtual frauds. We also consider long term solutions that couldbe used in the future to accomplish structural defenses.

SUMÁRIO

Lista de Figuras

Lista de Tabelas

1 Introdução 13

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Motivação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3 Contribuições. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4 Estrutura do trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Definição do problema 19

2.1 Resumo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Especificação dos Ataques. . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Tipos de ataque. . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.1.1 Roubo de dados. . . . . . . . . . . . . . . . . . . 20

2.2.1.2 Roubo de sessão. . . . . . . . . . . . . . . . . . . 20

2.2.1.3 Modificação de transações. . . . . . . . . . . . . . 20

2.2.1.4 Man-in-the-middle. . . . . . . . . . . . . . . . . . 21

2.3 Proteção. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Tipos de proteção. . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1.1 Prevenir contra captura de dados. . . . . . . . . . 22

2.3.1.2 Modificar os dados da autenticação. . . . . . . . . 23

2.3.1.3 Assinatura individual de transações. . . . . . . . . 23

2.4 Foco do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5 Trabalhos relacionados. . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6 Taxonomia dos ataques. . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6.1 Tipo do ataque. . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6.2 Objetivo imediato do ataque. . . . . . . . . . . . . . . . . . 27

2.6.3 Local do ataque. . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6.4 Vulnerabilidade explorada pelo ataque. . . . . . . . . . . . . 28

2.6.5 Complexidade técnica do ataque. . . . . . . . . . . . . . . . 29

2.6.6 Transparência do ataque. . . . . . . . . . . . . . . . . . . . 30

2.7 Ataques mais relevantes. . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Cenário Cliente/Servidor 33

3.1 Preocupações atuais com segurança: Servidor. . . . . . . . . . . . . 33

3.1.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.2 IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.3 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.4 Atualizações de segurança. . . . . . . . . . . . . . . . . . . 35

3.2 Preocupações atuais com segurança: Cliente. . . . . . . . . . . . . . 36

4 Métodos de ataque ao cliente 37

4.1 Resumo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Advertência ética. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Modo de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3.1 Trojans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.2 Vulnerabilidades. . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Modo de captura. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4.1 Linksfalsos . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.2 Keyloggers . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.2.1 Hooks . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.2.2 Funções estáticas do teclado. . . . . . . . . . . . . 44

4.4.2.3 Captura de campos de texto. . . . . . . . . . . . . 46

4.4.2.4 Drivers . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.2.5 DLL Injection . . . . . . . . . . . . . . . . . . . . 50

4.4.3 Telas falsas. . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.4 Ataque de redirecionamento. . . . . . . . . . . . . . . . . . 55

4.4.5 Ataque à máquina virtualJava . . . . . . . . . . . . . . . . . 58

4.5 Considerações finais. . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 Métodos de proteção ao cliente 62

5.1 Resumo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2 Considerações iniciais. . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.1 Batalhas em uma guerra injusta. . . . . . . . . . . . . . . . 63

5.2.2 Prevenindo a desinstalação. . . . . . . . . . . . . . . . . . . 66

5.3 Modos de proteção. . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3.1 Sistemas que operam como antivírus. . . . . . . . . . . . . . 68

5.3.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.3 Atualizações de segurança. . . . . . . . . . . . . . . . . . . 72

5.3.4 Antikeylogger. . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3.4.1 Hooks . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3.4.2 Captura de campos. . . . . . . . . . . . . . . . . 75

5.3.4.3 Drivers . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3.4.4 DLL Injection . . . . . . . . . . . . . . . . . . . . 79

5.3.5 BHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3.6 Proteção contra redirecionamento. . . . . . . . . . . . . . . 81

5.3.7 Detecção de janelas suspeitas. . . . . . . . . . . . . . . . . 83

5.3.8 Proteção da máquina virtualJava . . . . . . . . . . . . . . . 86

5.4 Sugestão de uma solução de curto prazo. . . . . . . . . . . . . . . . 88

5.5 A questão da privacidade. . . . . . . . . . . . . . . . . . . . . . . . 91

6 Considerações sobre soluções estruturais 94

7 Conclusões 97

Referências 99

Apêndice A -- Exemplo dee-mails 103

Glossário 107

LISTA DE FIGURAS

1.1 CERT: incidentes reportados.. . . . . . . . . . . . . . . . . . . . . . 15

4.1 Exemplo de e-mail contendotrojan. . . . . . . . . . . . . . . . . . . 39

4.2 Hooks: caminho percorrido por uma tecla.. . . . . . . . . . . . . . . 43

4.3 Exemplo de captura de clique demouseutilizandohooks . . . . . . . 44

4.4 Funções estáticas: caminho percorrido por uma tecla.. . . . . . . . . 45

4.5 Tela para entrada de senha. . . . . . . . . . . . . . . . . . . . . . . 46

4.6 Captura da senha do usuário. . . . . . . . . . . . . . . . . . . . . . 47

4.7 Relação entre os vários tipos dedrivers. . . . . . . . . . . . . . . . . 48

4.8 Drivers: caminho percorrido por uma tecla.. . . . . . . . . . . . . . 51

4.9 Siteoficial do banco teste. . . . . . . . . . . . . . . . . . . . . . . . 53

4.10 Tela falsa simples atacando um banco teste.. . . . . . . . . . . . . . 53

4.11 Tela falsa de média complexidade atacando o banco teste. . . . . . . . 54

4.12 Tela falsa de maior complexidade atacando o banco teste. . . . . . . . 54

5.1 Validação do módulo de segurança.. . . . . . . . . . . . . . . . . . . 67

5.2 Proteção contra captura utilizandohooks. . . . . . . . . . . . . . . . 74

5.3 Proteção contra captura utilizandodriver. . . . . . . . . . . . . . . . 77

5.4 Página oficial da instituição.. . . . . . . . . . . . . . . . . . . . . . 85

5.5 Tela falsa atacando ositeoficial da instituição.. . . . . . . . . . . . . 86

A.1 Exemplo dee-mailcontendotrojan. . . . . . . . . . . . . . . . . . . 103

LISTA DE TABELAS

4.1 Classificação do ataquetrojans. . . . . . . . . . . . . . . . . . . . . . 38

4.2 Classificação do ataque vulnerabilidades.. . . . . . . . . . . . . . . 40

4.3 Classificação do ataquelinks falsos. . . . . . . . . . . . . . . . . . . 41

4.4 Classificação do ataquekeyloggers. . . . . . . . . . . . . . . . . . . . 42

4.5 Classificação do ataque telas falsas.. . . . . . . . . . . . . . . . . . 52

4.6 Classificação do ataque de redirecionamento.. . . . . . . . . . . . . 55

4.7 Classificação do ataque à máquina virtualJava. . . . . . . . . . . . . 58

5.1 Ataques propostos e melhores defesas.. . . . . . . . . . . . . . . . . 88

13

1 INTRODUÇÃO

“Only the Paranoid Survive”

Andrew S. Grove

Segurança é um tópico que vem sendo considerado mais importante a cada dia. Bi-

lhões de dólares são gastos todo ano em sistemas que visam garantir o perfeito funcio-

namento de sistemason-line, como páginas de comércio eletrônico,Internet Bankinge

muitos outros serviços. Servidores mais robustos e confiáveis são comprados, sistemas

defirewall são instalados, certificados digitais e dados criptografados são transmitidos

incessantemente para garantir a completa proteção do sistema. Mas aparentemente, até

agora, um ponto importante foi esquecido e deixado de lado: ocliente.

A relevância desse problema se torna simples de ser entendida se pensarmos na

metáfora de uma corrente constituída de inúmeros elos. Um sistema de segurança

completo é composto por vários desses elos. Exemplificando,podemos pensar em

um sistema deInternet Bankingapresentando os seguintes elos: servidor de base de

dados, servidorweb, firewall, sistema deIDS (Intrusion Detection System), canal de

comunicação,Internet, e na ponta, a máquina do cliente. Imagine que nesse exemplo

todo o sistema do servidor (desde a base de dados até o canal decomunicação) esteja

muito bem configurado, sendo a segurança desse considerada perfeita (até utópica).

Mesmo com todos esses aparatos de segurança funcionando corretamente, se, na ponta,

na máquina do cliente, o elo estiver fraco, a corrente inteira poderá ser rompida. Pode

1.1 Objetivos 14

parecer exagero, mas no decorrer deste trabalho serão apresentadas diversas maneiras

reais e efetivas de ataque à máquina do cliente. Algumas exploram a ignorância e

desconhecimento do cliente, outras utilizam técnicas maisavançadas de invasão, mas

todas têm o intuito de capturar informações críticas e secretas na própria máquina do

cliente.

Como podemos então fortalecer o elo mais fraco, o do cliente? Já existem hoje

alguns métodos para realizar essa tarefa, que serão expostos durante o decorrer deste

trabalho. Mas, para fins de entendimento, imaginemos um casoextremo: para evitar a

fraude em seu serviço deInternet Banking, um banco qualquer instala um certosoft-

warena máquina de seus clientes que passa a monitorar tudo o que por lá ocorre. Para

o banco, esse pode parecer um excelente método, já que provavelmente seu número de

fraudes irá reduzir consideravelmente. Mas, e quanto à privacidade do cliente? O que

ele irá pensar ao verificar que agora umsoftwareem sua máquina pode ter acesso a

todos os seus dados pessoais?

Esse é basicamente o problema que estamos tentando resolver: encontrar um meio-

termo entre proteção e privacidade relativo à segurança na máquina do cliente.

1.1 Objetivos

Este trabalho tem como objetivo principal identificar, analisar e propor soluções

para vulnerabilidades de segurança no ambiente cliente de um sistema Cliente-Servidor

para evitar fraudes em instituições que operam sistemas transacionais naInternet, pro-

curando preservar a privacidade do usuário final.

O termo “instituição transacional” será empregado neste trabalho para referenciar

qualquer instituição que realize operações utilizando informações sigilosas de usuá-

rios.

1.2 Motivação 15

1.2 Motivação

A importância de mecanismos de proteção ao cliente vem crescendo a cada dia.

Podemos observar pela Figura1.1que o número de incidentes reportados praticamente

dobra a cada ano (CERT, 2005). Sendo assim, é altamente provável que a ameaça de

malwares(trojans, worms, vírus espywares) continuará a crescer.

Figura 1.1: CERT: incidentes reportados.

De acordo com a Figura1.1, podemos verificar um crescimento exponencial nas

fraudes ocorridas. Sendo assim, fica claro que uma solução decurto prazo para esse

problema deve ser rapidamente implementada.

Para ilustrar bem o fato, seguem abaixo algumas estatísticas extraídas de notícias

publicadas em jornais e revistas do Brasil nos meses de março até julho de 2005 (IDG-

NOW, 2005; FOLHA, 2005).

• As fraudes virtuais cresceram 1313% no Brasil no segundo trimestre de 2005, se

comparadas com o mesmo período de 2004.

1.2 Motivação 16

• Os golpes pore-mail cresceram 226% em maio de 2005 em relação ao mês

anterior.

• De cada 10e-mailsenviados no mês de maio de 2005, mais de 3 continham

vírus.

• Em março de 2005, policiais prenderam pirata brasileiro queteria desviado até

US$ 37 mi.

• Osscamscresceram 26% por mês entre julho de 2004 e fevereiro de 2005.

• Em março de 2005, o Brasil era o quinto país em ranking dephishing scam.

Além disso, novas vulnerabilidades e falhas de segurança vêm sendo encontradas

freqüentemente em todos os tipos de aplicativos. Também estão sendo criadas a cada

dia novas maneiras de ataque aos clientes.

O conjunto de todos esses fatores tem levado pessoas de todo omundo a ficarem

preocupadas e receosas ao utilizar sistemas críticos a partir da Internet, como mostra a

notícia abaixo:

IDG Now, 30 março de 2005:Temor com segurança afasta europeu de e-banking

A preocupação com ameaças de segurança como phishing, captura de

teclado ( keystroke logging) e outros tipos de scams está crescendo

de maneira notável entre os usuários de internet banking na

Europa ...Apenas 30% dos 22.907 usuários europeus entrevis tados

...declararam confiar na segurança de suas informações fin anceiras

pessoais quando fazem transações via internet ...

Como se pode verificar, os ataques específicos a clientes deInternet Bankingvêm

crescendo de forma assustadora. Com os dados apresentados acima, podemos conjec-

turar os seguintes pontos:

1.3 Contribuições 17

• Em nossos dias, ataques específicos ao cliente ocorrem em larga escala, pois a

dificuldade técnica de sua execução é pequena (como será mostrado mais adi-

ante), e o retorno financeiro é muito grande.

• Esses tipos de ataque continuarão a existir enquanto proverem bom retorno fi-

nanceiro, mesmo que a dificuldade técnica em sua implementação aumente.

• Atualmente não é possível garantir a integridade da máquinado cliente.

• Se nada for feito, o número de fraudes tenderá a aumentar e o prejuízo das em-

presas e possoas tenderá a crescer.

• Existe também a propensão de os clientes abandonarem os serviços viaInternet

por preocupação com segurança.

Baseado nos pontos colocados acima, deve ficar claro que algo deve ser feito para

a tentativa de preservação da segurança na máquina do cliente.

1.3 Contribuições

As contribuições apresentadas neste trabalho são as seguintes:

• Estudo de segurança de sistemas sob uma nova perspectiva: a máquina do cli-

ente.

• Exposição de novos métodos de ataque baseados em técnicas deintrusão e seus

riscos pouco conhecidos para o público em geral.

• Apresentação de métodos de proteção capazes de detectar e prevenir tais situa-

ções, minimizando o risco associado.

• Avaliação do balanceamento entre proteção e privacidade naperspectiva do cli-

ente.

1.4 Estrutura do trabalho 18

• Criação de uma nova taxonomia para os ataques direcionados aocliente.

1.4 Estrutura do trabalho

No Capítulo2, iremos definir uma métrica de classificação para ataques aqui ex-

plicados. O objetivo é ajudar a classificar e organizar os ataques para posteriormente

facilitar a sua análise.

Já no Capítulo3, apresentaremos as funcionalidades de segurança atuais com as

quais a maioria dos sistemas se preocupa. Iremos descrever brevemente cada uma

dessas funções em termos do que cada uma pretende proteger.

No Capítulo4, serão apresentados uma variedade de métodos conhecidos para

ataque direto ao cliente. Para cada um dos métodos, será citada sua complexidade

técnica e efetividade de ataque.

Em seguida, no Capítulo5, serão expostas as diferentes maneiras de proteção do

cliente. Para cada uma dessas maneiras, será apresentada sua eficiência em relação

aos ataques propostos, além de sua dificuldade de implementação. Além disso, será

mostrado o nível de intrusão que cada um desses métodos preventivos pode vir a causar.

Ao final desse Capítulo, na seção5.4, será apresentado um esboço de solução que

englobe os melhores métodos de proteção apresentados e que possa ser implantado

rapidamente.

Será, então, discutido no Capítulo6 quais as medidas futuras que podem ser toma-

das para garantir, a longo prazo, a segurança dos clientes.

19

2 DEFINIÇÃO DO PROBLEMA

“Only two things are infinite, the universe and human stupidity, and I’m

not sure about the former. ”

Albert Einstein

2.1 Resumo

Neste capítulo, iremos definir exatamente o problema a ser tratado neste traba-

lho. Vamos definir também a abordagem utilizada no estudo do problema, além de

estabelecer o foco mais preciso dos ataques e defesas estudados.

2.2 Especificação dos Ataques

O objetivo principal dos realizadores de ataques estudadosneste trabalho é co-

meter fraudes virtuais. Isso significa basicamente tentar roubar dinheiro dos clientes

de um serviço deInternet Bankingou comércio eletrônico. Além disso, os ataques

a serem apresentados aqui são os realizados apenas na máquina do cliente, ou seja,

não requerem nenhum tipo de atuação fraudulenta no servidorlegítimo da instituição

atacada.

2.2 Especificação dos Ataques 20

2.2.1 Tipos de ataque

Existem vários tipos de ataque direcionados ao cliente. Abaixo encontra-se uma

classificação geral de cada um desse tipos.

2.2.1.1 Roubo de dados

Esse ataque tem como objetivo roubar os dados críticos de autenticação do cliente.

Com essas informações, o atacante pode, de formaoff-line, reproduzir o processo de

autenticação, passando-se, então, pelo cliente. Isso também é chamado de ataque de

personificação. O roubo dos dados pode ocorrer de vários modos, como captura de

teclado, telas falsas,e-mailsfalsos, e muitos outros, como será explicado nos capítulos

seguintes.

2.2.1.2 Roubo de sessão

Algumas vezes, o roubo dos dados de autenticação do cliente não é suficiente para

reproduzir sua autenticação. Por exemplo, sistemas que utilizam senhas diferentes a

cada autenticação impedem que o atacante possa realizar a fraude apenas com a sim-

ples captura dos dados digitados. Nesse caso, pode ser utilizado um outro método de

ataque chamado roubo de sessão. Aqui o atacante espera o cliente realizar a autentica-

ção e após isso utiliza o número de sessão do usuário para realizar transaçõeson-line.

Caso cada transação também exija uma senha diferente a cada vez, o atacante pode

esperar o cliente realizar uma transação para então capturar a senha daquele momento

e utilizá-la na hora para realizar a fraude.

2.2.1.3 Modificação de transações

Semelhante ao ataque acima, o ataque de modificação de transações ocorreon-line

na máquina do cliente. Nesse ataque, um aplicativo malicioso localmente instalado fi-

caria esperando o cliente realizar alguma transação. Nessemomento, após o cliente ter

2.3 Proteção 21

digitado todos os dados da transação mais os seus dados de autenticação, o aplicativo

malicioso poderia modificar os dados da transação e enviar esse pacote modificado.

Assim, o atacante estaria apenas adulterando os dados da transação que o cliente esti-

vesse realizando.

2.2.1.4 Man-in-the-middle

Os ataques deman-in-the-middle(ou homem-no-meio) se baseiam na idéia de in-

terceptação dos dados durante seu tráfego entre o cliente e oservidor. Nesse tipo de

ataque, o atacante consegue ler, inserir e modificar à vontade as mensagens trocadas.

Esse ataque é muito importante no meio criptográfico, pois implica em grandes cuida-

dos, principalmente em protocolos de troca de chaves. Aplicado a fraudes naInternet,

esse ataque poderia ser utilizado para interceptar ou modificar os dados críticos trafe-

gados entre o cliente e o servidor da instituição.

2.3 Proteção

O objetivo da proteção apresentada neste trabalho é prevenir ou ao menos reduzir

a fraude. Como os ataques estudados são referentes ao lado cliente, a proteção também

será apresentada na perspectiva do cliente. Nesse ponto encontramos dificuldades que

não existiam no ambiente servidor, tais como:

• Como garantir a segurança em um sistema quando não se tem o controle absoluto

do mesmo?

Como a máquina do cliente não faz parte do sistema sob controleda instituição,

é extremamente complexo responder à pergunta acima. Um banco, por exemplo, tem

total controle sobre seus servidores. Assim, é possível instalar atualizações de seguran-

ças, aplicativos de antivírus,firewalls e muitas outras ferramentas de segurança para

proteger esse servidor. Contudo, essa instituição não tem controle sobre a situação

2.3 Proteção 22

das máquinas de seus clientes. Alguns clientes podem possuir antivírus, outros não.

Alguns clientes têm conhecimento sobre navegação segura naInternet, outros não, e

assim por diante.

Mesmo se a instituição instalar umsoftwareproprietário de segurança em cada um

de seus clientes, essesoftwaretem que levar em conta os diversos ambientes hetero-

gêneos dos clientes e os diversos perfis de usuários caso participem das decisões de

segurança a serem tomadas.

• Como interagir com o usuário de forma segura, ou seja, essa interação não pode

ser utilizada para violar o ambiente do próprio cliente?

A instalação de umsoftwarede segurança pela instituição muitas vezes pode ser

usada como porta de entrada por atacantes. Da mesma maneira que a instituição oficial

explica aos usuários os problemas de segurança e pede então sua autorização para a

instalação dessesoftware, o atacante pode usar o mesmo método para tentar persuadir

o usuário a instalar aplicativos maliciosos. A criação dessa interação de instalação pela

instituição pode criar no usuário o hábito de permitir instalações de outrossoftwares

possivelmente ilícitos.

2.3.1 Tipos de proteção

Mesmo com os problemas apresentados acima, algumas proteções ainda são pos-

síveis e muitas vezes necessárias na máquina do cliente. Abaixo encontra-se uma

classificação dos tipos gerais de proteção aos quais uma instituição pode recorrer com

o objetivo de tentar reduzir as fraudes:

2.3.1.1 Prevenir contra captura de dados

O primeiro método é relativamente simples de ser entendido:prevenindo que o

atacante roube as senhas do cliente, esse não poderá reproduzir o processo de autenti-

2.3 Proteção 23

cação. Note que esse método de proteção só previne os ataquesdo tipo roubo de dados,

sendo que os outros ataques apresentados (roubo de sessão, modificação de transações

eman-in-the-middle) não estão cobertos por essa proteção.

2.3.1.2 Modificar os dados da autenticação

O segundo tipo de proteção requer algum tipo de senha que mudede forma impre-

visível a cada operação de autenticação. Isso também é chamado deOTP (One Time

Password). Nesse caso, mesmo que o atacante capture os dados críticosdo cliente, esse

não poderá repetir o processo de autenticação, pois no próximo processo de autentica-

ção será requisitada outra senha. Esse método de proteção cobre somente os ataques

do tipo roubo de dados, não protegendo contra os outros tiposde ataque apresentados.

2.3.1.3 Assinatura individual de transações

Nesse método de proteção, o cliente assina digitalmente os dados da transação

sendo efetivada. A instituição então verifica a assinatura dos dados e só então libera a

transação. Esse método de proteção é muito interessante e eficiente, porém muitos cui-

dados devem ser tomados durante sua implementação, como porexemplo, assinatura

às cegas, validação visual dos dados assinados, local onde será realizada a assinatura,

e muitos outros. Esse tópico é extremamente extenso e seria provavelmente fruto de

outro trabalho completo. Esse tipo de proteção não será discutida em profundidade

aqui.

É interessante notar que normalmente nenhuma das proteçõescitadas acima pro-

tegem totalmente o cliente contra a chamada engenharia social. O atacante sempre

pode encontrar algum modo de tentar convencer o cliente a fazer o que ele deseja. Por

exemplo, para um sistema que utilize uma tabela contendo diversas senhas diferentes

a serem usadas na autenticação, ele poderia pedir ao clientesua tabela completa de

senhas. Neste caso, a segurança ficaria toda a cargo do cliente.

2.4 Foco do trabalho 24

2.4 Foco do trabalho

Neste trabalho será estudado a fundo apenas um tipo de ataquee um tipo de defesa:

roubo de dados e prevenção de captura, respectivamente. Os motivos para essa escolha

são os seguintes:

• Atualmente, os ataques mais freqüentes são os de roubo de dados.

• O método de prevenção de captura, apesar de não ser o mais eficiente, é o mais

prático e simples de ser implantado. Distribuir milhões de senhas ou dispositivos

externos para cada cliente nem sempre é uma alternativa viável, principalmente

pelo custo e logística envolvida. Além disso, nem todos os clientes possuem

dispositivos como celulares ouhandheldsque poderiam ser utilizados como fer-

ramentas de autenticação.

• O cliente muitas vezes não está interessado nem disposto a complicar seu mé-

todo de autenticação para melhorar sua segurança. Muitas vezes, clientes de

instituições transacionais consideram que segurança é problema da instituição,

não do cliente. Nem sempre é possível obrigar um cliente a carregar uma tabela

de senhas ou umtoken OTP.

• Muitos clientes de instituições transacionais são leigos em relação à informá-

tica e segurança. O uso de dispositivos complexos ou métodosde autenticação

complicados nem sempre é aplicável a todos os clientes. Usuários já estão acos-

tumados com o seu esquema atual de autenticação e normalmente não vêem

razão para que isso complique, atrapalhando seu uso do sistema.

Por esses motivos, a maioria dos sistemas de autenticação atual ainda se baseia na

entrada de um simples par usuário/senha. Além disso, por experiência pode ser consta-

tado que a grande maioria dos ataques atuais só se baseia na técnica de roubo de dados.

Sendo assim, este trabalho será focado no estudo dos ataquesde roubo de dados e nas

2.5 Trabalhos relacionados 25

possíveis proteções que impeçam esse roubo. Isso obviamente não descarta a impor-

tância ou eficiência dos outros tipos de ataques e proteções anteriormente citados, mas

isso seria assunto para outro trabalho.

Iremos também focar esse trabalho no sistema operacionalWindows, pois sua uti-

lização hoje é maioria absoluta, tornando-se assim o principal alvo de ataques.

2.5 Trabalhos relacionados

Alguns outros trabalhos já foram escritos sobre classificação e taxonomia de ata-

ques. Em (LANDWEHR ALAN R. BULL; CHOI , 1994), os autores descrevem uma taxono-

mia completa para falhas de segurança de computadores. Em (HOWARD, 1997), é des-

crita uma taxonomia de ataques a redes de computadores. Em (WARKENTIN XIN LUO ,

2005), é descrito um arcabolço para classificação despywares.

Existem muitas publicações sobre o tópico de fraudes em sistemas transacionais

na Internet. Recentemente, várias publicações tem abordado esse assunto de formas

diferentes. Alguns exemplos: em (DHAMIJA , 2005), os autores propõem uma solução

para dificultar os ataques dephishing. Em (GIBSON, 2005), o autor apresenta o pro-

blema atual dosspywarese o porque do seu grande crescimento. Em (LEE, 2005), os

autores expõe os fatores mais relevantes na escolha de um sistema de proteção contra

spywares.

Vários outros trabalhos citados no texto explicam o problema de segurança envol-

vido nesse ambiente transacional e tentam identificar algumas soluções mais estrutu-

rais.

Apesar disso, a área de publicações ainda é vaga quanto à parte mais técnica de

descrição dos ataques e proteções aqui apresentadas. Muitas referências mais abran-

gentes sobre codificação existem espalhadas pelaInternet ou em documentações da

própria Microsoft, mas em nenhum ponto foi encontrada a apresentação do perigo

2.6 Taxonomia dos ataques 26

na utilização maliciosa de certas técnicas de programação,nem na utilização dessas

mesmas técnicas com o intuito de prevenção. O conhecimento ea utilização dessas

técnicas existem mais pela necessidade de atacantes e instituições. O conhecimento

empírico de alguns profissionais, obtido através de experiência nessa área, é normal-

mente a única fonte de informação acessível.

2.6 Taxonomia dos ataques

Como já foi dito, o objetivo final dos realizadores dos ataquesaqui apresentados é

cometer uma fraude virtual. No caso mais específico dos ataques de roubo de dados,

seu objetivo é capturar de alguma maneira os dados críticos do cliente (como suas

senhas) para poder num futuro replicar o processo de autenticação.

Os ataques de captura normalmente devem seguir os seguintespassos para serem

bem-sucedidos:

1. Instalação - O atacante deve de alguma maneira instalar umsoftwaremalicioso

ou modificar de alguma forma a máquina do cliente.

2. Captura - Com acesso à maquina do cliente, o atacante deve agoracapturar os

dados críticos da vítima.

3. Envio dos dados roubados - O atacante deve então enviar os dados capturados

para conseguir ter acesso aos mesmos.

4. Fraude - O atacante utiliza os dados capturados para realizar a fraude.

Nem todos os ataques aqui descritos seguem todos os passos citados cima. Alguns

não precisam de instalação local desoftware, outros não precisam enviar os dados para

o atacante. Mas, de forma genérica, a maioria dos ataques realiza os passos acima.

Neste trabalho não serão descritos o terceiro e o quarto passos citados acima, por sua

relativa simplicidade.


A seguir apresentaremos uma proposta de taxonomia para classificação desses ata-

ques ao cliente. Cada ataque será classificado quanto às suas características principais

e mecanismos de ação.

2.6.1 Tipo do ataque

Inicialmente, definiremos qual o tipo do ataque. Conforme explicado acima, um

atacante deve normalmente seguir alguns passos para conseguir realizar a fraude. Al-

guns ataques estão focados em apenas um dos passos citados. Outros podem ser ata-

ques completos, que sozinhos já conseguem realizar totalmente seu objetivo.

Os ataques deste trabalho terão seus tipos classificados da seguinte maneira:

• Ataque completo: ataque que, sozinho, já realiza por completo seu objetivo. Não

requer o auxílio de nenhum outro ataque.

• Ataque parcial: ataque que realiza apenas um ou alguns dos passos necessários

para completar totalmente o objetivo do atacante. Sozinho,não realiza a fraude,

mas pode ser utilizado em conjunto com outros ataques.

Um ataque completo de captura pode ser constituído de váriosataques parciais que

somados resultam na fraude.

2.6.2 Objetivo imediato do ataque

O objetivo final dos ataques aqui descritos é sempre o de propiciar aos realizadores

de ataques a chance de realizar uma fraude. Contudo, cada ataque parcial possui seu

objetivo individual. O objetivo imediato dos ataques parciais aqui apresentados serão

classificados da seguinte maneira:

• Instalação: ataque cujo objetivo é instalar algo na máquinado cliente.

• Captura de dados: ataque cujo objetivo é obter os dados críticos do cliente.


2.6.3 Local do ataque

Nessa etapa, especificaremos o local onde o ataque ocorre, ouseja, o módulo uti-

lizado para a realização do ataque apresentado. Esses locais podem ser os seguintes:

• Aplicativos gerais: aplicativos de terceiros, não fundamentais ao sistema, utiliza-

dos pelo usuário (exemplos: aplicativo de gerenciamento financeiro, aplicativo

de edição de texto).

• Aplicativos de sistema: aplicativos do próprio sistema, fundamentais para o dia-

a-dia (exemplos:e-mail, navegadorweb).

• Sistema operacional: código do próprio sistema operacional, obrigatório para

o correto funcionamento do sistema (exemplos: serviços do sistema,DLLs do

sistema);

• Núcleo do sistema: parte central do sistema operacional também conhecida

comokernel(exemplo:driversde periféricos).

Quanto mais baixo o nível do ataque, normalmente mais complicada é sua imple-

mentação.

2.6.4 Vulnerabilidade explorada pelo ataque

Aqui classificaremos qual vulnerabilidade específica é utilizada pelo atacante para

realizar o ataque, ou seja, qual falha está sendo explorada pelo atacante para que o

ataque seja bem sucedido. As vulnerabilidades podem ser classificadas conforme a

lista abaixo:

• Falha de implementação: o sistema atacado possui umbug, ou seja, a imple-

mentação do sistema possui um defeito que pode ser exploradopara a execução


do ataque. Exemplo: vulnerabilidades do sistema operacional exploradas pelos

worms SassereBlaster(apresentados mais a frente).

• Defeito de especificação: o sistema foi especificado de maneira a deixar uma

brecha de segurança que pode ser explorada por atacantes. Isso não quer ne-

cessariamente dizer que o sistema foi mal implementado ou que possui umbug.

Isso simplesmente quer dizer que o sistema foi mal arquitetado. Exemplo: fun-

ções desnecessárias disponibilizadas pelo sistema operacional que auxiliam na

captura de dados.

• Inexperiência do usuário: fator humano, vítima da engenharia social. Um usuá-

rio inexperiente tem maior chance de ser vítima de um ataque que um usuário

mais experiente. Exemplo:e-mailsfalsos comlinks contendo programas mali-

ciosos.

2.6.5 Complexidade técnica do ataque

Como normalmente o ataque apresentado envolve codificação (programação), ou

pelo menos algum conhecimento técnico sobre a área, podemosclassificar os ataques

pela sua dificuldade de implementação. Esse ítem é de extremaimportância, pois

está ligado diretamente à escolha do ataque a ser utilizado pelo atacante. Inicialmente,

atacantes procurarão ataques de menor complexidade técnica, pois sua execução é mais

simples. Conforme as proteções e dificuldades para os ataquesforem aumentando,

atacantes começarão a migrar para ataques mais complexos.

Neste trabalho iremos classificar os ataques conforme sua dificuldade técnica, uti-

lizando a seguinte escala:

• Ataque simples: não requer conhecimento técnico profundo nem grandes tra-

balhos de programação. Esses ataques muitas vezes podem serrealizados sem


programação nenhuma, pois o atacante procura naInternetprogramas já prontos

e apenas os modifica superficialmente.

• Ataque mediano: requer razoável conhecimento técnico sobre o assunto, in-

cluindo os mecanismos internos do sistema operacional. Nãorequer necessa-

riamente grandes quantidades de programação e muitas vezespode ser realizado

apenas com linguagens de alto nível.

• Ataque complexo: requer conhecimento técnico profundo e extenso trabalho de

programação. É necessário conhecer detalhes do sistema operacional, incluindo

funcionalidades raramente utilizadas ou até não documentadas. Pode inclusive

requisitar programação em linguagem de máquina.

De uma maneira geral, ataques mais técnicos que exijam conhecimento profundo

sobre o funcionamento do sistema operacional serão mais complexos do que ataques

que possam ser realizados apenas com linguagens visuais de programação. Ataques

que exijam modificação no núcleo do sistema também serão maiscomplicados. Códi-

gos disponíveis naInternete facilmente adaptáveis serão mais simples.

2.6.6 Transparência do ataque

Para o cliente, alguns ataques ocorrem de forma mais transparente que outros.

Ataques que utilizam programas escondidos que capturam as informações digitadas

de forma furtiva são mais transparentes que aqueles que mostram janelas na tela do

usuário pedindo todos os seus dados. Usuários mais leigos podem ser vítimas dos dois

ataques citados, mas provavelmente usuários mais experientes perceberiam a presença

do segundo ataque. Nesse sentido, apresentamos a classificação da transparência dos

ataques conforme abaixo:

• Baixa transparência: o ataque modifica bastante a forma normal esperada da

aplicação original.

2.7 Ataques mais relevantes 31

• Média transparência: o ataque modifica pouco a forma normal esperada da apli-

cação original.

• Alta transparência: o ataque modifica muito pouco ou nada da forma normal

esperada da aplicação original.

Essa classificação indica basicamente quão simples (ou quãocomplicado) é a de-

tecção pelo usuário de que este está sendo atacado num dado instante. Quanto mais

transparente um ataque, mais complexa é sua detecção pelo usuário.

Esse item é utilizado apenas para ataques de captura de dados, não sendo relevante

para os ataques com o objetivo de instalação.

2.7 Ataques mais relevantes

O estudo de todos os tipos de ataques a clientes é extremamente extenso e foge

do escopo deste trabalho. Aqui, decidimos estudar a fundo alguns dos mais relevantes

ataques, a saber:

• Trojans

• Links falsos

• Exploração de vulnerabilidades

• Keyloggers

• Telas falsas

• Ataque de redirecionamento

• Ataque à máquina virtualJava

2.7 Ataques mais relevantes 32

O motivo principal da escolha desses ataques é que, com exceção do último, esses

são hoje os ataques mais freqüentes realizados a sistemas deInternet Banking(CERT,

2005). Além disso, esses ataques são também muito efetivos hoje na captura dos da-

dos do cliente. Também é relevante o fato de esses ataques serem tecnicamente mais

simples, o que aumenta bastante sua atratividade para os atacantes.

O ataque à máquina virtualJava foi também selecionado, pois utiliza uma nova

técnica de captura que será explicada mais à frente. Essa nova técnica é extremamente

poderosa e pode potencialmente ser utilizada para investircontra outros tipos de má-

quinas virtuais. Além disso, o ambienteJavaé muito utilizado hoje por instituições

durante o processo de autenticação de seus usuários, e é exatamente nesse ponto que

os atacantes irão atacar para capturar os dados do cliente.

33

3 CENÁRIO CLIENTE/SERVIDOR

3.1 Preocupações atuais com segurança: Servidor

Neste capítulo apresentaremos resumidamente algumas preocupações atuais com

segurança no ambiente cliente-servidor. Citaremos algumasproteções usadas princi-

palmente no lado servidor e especificaremos em que ponto se encontra a proteção dos

clientes.

3.1.1 SSL

As preocupações com a confidencialidade das informações trafegadas pelaInter-

net vem de velha data. OSSL(Secure Sockets Layer) é um protocolo desenvolvido

pelaNetscapepara transmissão de documentos pelaInternet. Esse protocolo utiliza

em conjunto criptografia de chave simétrica e criptografia dechave assimétrica para

garantir a integridade e confidencialidade, fim a fim, dos dados transportados.

O SSLé muito utilizado por páginas que obtêm informações confidenciais de cli-

entes, como número de cartões de crédito ou senhas deInternet Banking. Atualmente

a utilização deSSLé quase obrigatória em todos os serviços que exijam confidenciali-

dade nas informações transmitidas.

Como já foi dito, oSSLgarante a comunicação fim a fim. Apesar disso, na versão

2.0 doSSL(a mais amplamente utilizada atualmente) não existe identificação do cliente

perante o servidor, ou seja, apesar de o cliente conseguir validar a autenticidade do

3.1 Preocupações atuais com segurança: Servidor 34

servidor, o contrário não é verdade. Além disso, oSSLsó protege os dados a partir

do momento em que são enviados pelo navegador através da rede, sendo que entre a

digitação e o momento do envio, os dados permanecem em claro.

3.1.2 IDS

Para evitar ataques ou invasões de sistemas, foram criados os chamadosIDS (In-

trusion Detection System). O trabalho desse sistema é inspecionar toda a atividade da

rede (tanto os dados de entrada quanto os dados de saída) e identificar padrões sus-

peitos que possam indicar a ocorrência de um ataque. Os sistemas deIDS podem ser

classificados como:

• Detecção por ataques conhecidos ou por anomalia: No primeiro caso, oIDS

possui uma base de dados de ataques conhecidos, e portanto consegue procurar

dentro do tráfego de rede ataques semelhantes aos cadastrados, representando

um sistema semelhante a um antivírus. No segundo caso (detecção por anoma-

lia), o sistema passa um tempo em modo aprendizado, em que deve aprender

qual o comportamento normal daquela rede. Depois de um certotempo, o sis-

tema consegue detectar anomalias na rede a partir da base de dados criada.

• Baseado em rede ou emhost: IDS baseados em rede monitoram cada pacote de

comunicação individualmente.IDSbaseados emhostmonitoram a atividade em

cada máquina individualmente.

• Passivo ou reativo:IDSpassivos, ao detectar um possível ataque, gravam a infor-

mação e ativam algum tipo de alerta. Em um sistema reativo, o sistema deIDS

exerce uma ação no caso de uma anomalia, como, por exemplo, derrubar algum

usuário ou passar a bloquear todos os pacotes vindos do endereço suspeito.

Sistemas de detecção de intrusão são muito importantes parao ambiente servidor,

pois evitam ataques que poderiam provavelmente derrubar umsistema inteiro. Mesmo

3.1 Preocupações atuais com segurança: Servidor 35

assim, esses sistemas só são interessantes para o ambiente servidor, sendo inviável a

sua instalação em clientes individuais.

3.1.3 Firewall

O objetivo de umafirewall é prevenir acesso não autorizado a uma rede privada.

Firewallspodem ser implementadas tanto emsoftwarequanto emhardware, ou mesmo

em uma combinação dos dois. O objetivo mais comum de umafirewall é impedir

que usuários não autorizados daInternet acessem redes privadas (intranets). Uma

firewall pode, por exemplo, filtrar os pacotes de uma rede, examinandopacote por

pacote entrando ou saindo, podendo então aceitar ou rejeitar o tráfego baseado em

regras definidas pelo usuário. Os sistemas defirewall são considerados a primeira

linha de defesa na proteção de redes privadas.

Apesar de relacionados com segurança de redes, umIDSdifere de umafirewall no

sentido que afirewall limita o acesso de usuários para prevenir intrusões, além denão

proteger contra ataques internos da rede. UmIDS, por sua vez, verifica uma possível

intrusão depois que ela já ocorreu, e sinaliza algum alarme.Um IDS também pode

detectar ataques oriundos da rede interna.

3.1.4 Atualizações de segurança

Novas vulnerabilidades de segurança são encontradas em todos os tipos de produ-

tos a cada dia. Só em abril de 2005, foram lançados vinte atualizações de segurança

pelaMicrosoftpara corrigir falhas encontradas em seus produtos. Apesar de o número

de falhas de segurança em produtos tender a diminuir, elas sempre existirão e portanto

serão exploradas por atacantes.

A instalação de atualizações críticas de segurança deveriaocorrer com freqüência,

mas para a maioria dos clientes isso não ocorre. Seja por meroesquecimento, seja

pelo número elevado de atualizações de segurança ou qualquer outro motivo, usuários

3.2 Preocupações atuais com segurança: Cliente 36

comuns normalmente não aplicam essas correções em suas máquinas, ficando assim

vulneráveis a ataques já conhecidos e corrigidos.

Dois exemplos impressionantes podem ser dados para ilustrar essa situação: o

worm Sassere oworm Blaster. OBlasterexplora a vulnerabilidade deDCOMdoRPC

no Windows 2000. A Microsoft estima que pelo menos 8 milhões de computadores

comWindowsforam infectados peloBlaster. Já oSasserexplora uma vulnerabilidade

mais recente noWindows, espalhando-se de máquina em máquina sem a intervenção

do usuário. AMicrosoft reportou que mais de 1.5 milhões de clientes baixaram o

programa de remoção doSassernos primeiros dois dias após sua disponibilização.

Até hoje, mesmo após meses da liberação dopatch de correção pelaMicrosoft, se

um usuário conectar um micro semfirewall e sem as atualizações críticas naInternet,

é quase certo que após alguns minutos sua máquina será infectada por algum desses

wormscitados.

3.2 Preocupações atuais com segurança: Cliente

Atualmente, a preocupação de segurança com o cliente ainda émuito pequena.

Apesar de a segurança dos servidores daInternetnormalmente já estar bem evoluída

e consolidada, o lado cliente permanece esquecido. De qualquer maneira, já existem

algumas poucas investidas na tentativa de proteção ao cliente, principalmente em pá-

ginas deInternet Banking.

37

4 MÉTODOS DE ATAQUE AO CLIENTE

4.1 Resumo

Neste capítulo serão apresentados os ataques mais relevantes realizados contra a

máquina do cliente. Cada ataque será classificado conforme a metodologia estabe-

lecida em capítulos anteriores. Também será apresentada uma explicação técnica da

implementação de cada um dos ataques. As propostas de defesapara esses ataques

serão apresentadas no Capítulo5.

4.2 Advertência ética

As informações sobre os métodos de ataque estão aqui apresentadas somente para

fins didáticos. Não é o intuito deste trabalho ensinar como sepode atacar um sistema

transacional. O objetivo aqui é apresentar de forma resumida os ataques mais conhe-

cidos, tornando mais simples a implementação de suas respectivas defesas. É sempre

necessário entender como podemos ser atacados antes de tentarmos nos defender.

4.3 Modo de instalação

Nesta seção são apresentados alguns exemplos de ataques quetêm como objetivo

a instalação de um programa malicioso na máquina do cliente sem que este perceba.

4.3 Modo de instalação 38

4.3.1 Trojans

Na tabela4.1, apresentamos a classificação do ataquetrojansconforme a taxono-

mia criada. Nesse caso, o item “transparência” não foi apresentado, pois só se aplica

para métodos diretos de ataque (e não para métodos de instalação).

TrojansTipo parcialObjetivo instalaçãoLocal aplicativo de sistema (e-mail)Vulnerabilidade inexperiênciaComplexidade simples

Tabela 4.1: Classificação do ataquetrojans.

Inicialmente, vamos definir o que é umtrojan (ou cavalo de Tróia).Trojanssão

programas malignos disfarçados de programas benignos. Otrojan se utiliza da igno-

rância, curiosidade ou falta de informação do cliente para conseguir se instalar em sua

máquina (AARONSON, 2005). A partir do momento em que otrojan consegue se ins-

talar no sistema, ele passa a ter total controle sobre a máquina e pode então monitorar

todas as atividades do usuário.1

Atualmente, o modo mais comum de instalação de umtrojan é a partir dee-mails.

O método é o seguinte: o atacante monta ume-mailque incita a curiosidade ou atenção

do cliente. Essee-mail é fabricado de forma a induzir o cliente a, inadvertidamente,

instalar otrojan em sua máquina.

Na Figura4.1, o atacante tenta se utilizar da curiosidade do usuário paraque este

clique nolink esperando fotos interessantes, quando na verdade olink leva a um exe-

cutável que instalará umtrojan na máquina desse usuário.

1Para simplificação da terminologia, o nometrojan será também utilizado neste trabalho para refe-renciar genericamente qualquersoftwaremalicioso instalado localmente na máquina do cliente

4.3 Modo de instalação 39

Figura 4.1: Exemplo de e-mail contendotrojan.

Outros exemplos dee-mailscontendotrojanspodem ser vistos no Apêndice, nas

FigurasA.1, A.2, A.3 e A.4. Todos essese-mailslá apresentados são reais e foram

recebidos sem nenhuma autorização prévia. Pode não parecer, mas todos eles são

falsos e levam à baixa de umtrojan.

Depois de instalado, otrojan utilizará uma das técnicas descritas na seção4.4para

capturar as informações do usuário. Após isso, os dados capturados serão enviados

a algum servidor, provavelmente porFTP (File Transfer Protocol), HTTP (Hypertext

Transfer Protocol) ou SMTP(Simple Mail Transfer Protocol), onde o atacante poderá

coletá-los.

Além do uso doe-mail como veículo de transmissão dotrojan, outros métodos

4.4 Modo de captura 40

ainda podem ser usados. Um exemplo seria anexar otrojan a algum programa lícito,

como jogos ou aplicativos de transmissão de arquivos (pear to pear).

4.3.2 Vulnerabilidades

Na tabela4.2, apresentamos a classificação do ataque vulnerabilidades conforme

a taxonomia criada. Nesse caso, o item “transparência” não foi apresentado, pois só se

aplica para métodos diretos de ataque (e não para métodos de instalação).

VulnerabilidadesTipo parcialObjetivo instalaçãoLocal sistema operacionalVulnerabilidade erros de implementaçãoComplexidade média

Tabela 4.2: Classificação do ataque vulnerabilidades.

Como já foi citado em seções anteriores (3.1.4), a exploração de vulnerabilidades

do sistema operacional e aplicativos é um modo comum para instalação desoftwarede

forma ilícita na máquina do cliente. Como explicado para osworms Sassere Blaster,

um aplicativo malicioso pode explorar essas vulnerabilidades para instalar um remota-

mentetrojan na máquina da vítima.

Atualmente, esse método ainda não é muito utilizado para a instalação detrojans

específicos para ataques, provavelmente pela complexidadetécnica em sua execução.

4.4 Modo de captura

Nesta seção serão apresentados algum métodos mais comuns para executar a cap-

tura das informações críticas de clientes. As possíveis defesas contra esses ataques

serão apresentadas no Capítulo5.


4.4.1 Links falsos

Na tabela4.3, apresentamos a classificação do ataqueLinks falsos conforme a

taxonomia criada.

Links falsosTipo completoObjetivo fraudeLocal aplicativo de sistema (e-mail)Vulnerabilidade vulnerabilidade de especificação e inexperiência do usuárioComplexidade simplesTransparência baixa

Tabela 4.3: Classificação do ataquelinks falsos.

Outra maneira muito comum de ataque ao cliente é o envio dee-mailsem nome de

alguma instituição transacional, contendo umlink para umsitefalso muito semelhante

ao da instituição real. Oe-mailnormalmente contém alguma informação sobre débitos

a sanar, ou mesmo sobre promoções mirabolantes da instituição. Ao clicar nolink den-

tro doe-mail, o usuário é levado a umsitefalso onde serão pedidos seus dados críticos,

como agência, conta e senhas. Ao final, osite falso pode simplesmente apresentar um

erro ou mesmo redirecionar o usuário aositeverdadeiro, tornando assim o ataque mais

transparente.

4.4.2 Keyloggers

Na tabela4.4, apresentamos a classificação do ataqueKeyloggersconforme a ta-

xonomia criada.

Keyloggerssão programas que capturam os dados provindos do teclado,mousee

tela. A maioria doskeyloggerscapturam tudo o que é digitado pelo cliente durante

seu acesso a algumsite de Internet Banking. Além disso, com o número crescente

de bancos utilizando teclados virtuais para realizar a autenticação de seus usuários, os

keyloggerstambém são projetados para capturar pedaços de tela ao redordo cursor do


KeyloggersTipo parcialObjetivo capturaLocal sistema operacionalVulnerabilidade vulnerabilidade de especificação

Complexidade

Hooks médiaFunções estáticas média

Captura de campos médiaDrivers alta

DLL injection altaTransparência alta

Tabela 4.4: Classificação do ataquekeyloggers.

mousedurante oscliques, sendo assim possível a recuperação da senha do cliente.

A seguir são expostos alguns possíveis métodos de captura deteclas ecliques,

focando em sistema operacionalWindows.

4.4.2.1 Hooks

Hooks(ganchos) do sistema operacional podem ser utilizados tanto para a cap-

tura demousequanto para a captura de teclado. Em termos técnicos, oshookssão

pontos dentro do sistema de tratamento de mensagens doWindows(MSDN, 2005) em

que um aplicativo pode instalar uma sub-rotina para monitorar o tráfego de mensagens

no sistema ou processar certos tipos de mensagens antes de estas chegarem à sua ja-

nela destino. Em termos mais simples: a comunicação de eventos entre processos do

sistema operacionalWindows(por exemplo, um clique em um botão, a digitação de

uma tecla, o fechamento de uma janela) funciona por meio de troca de mensagens.

Quando um usuário clica no botãoOK de uma aplicação, o sistema operacional envia

uma mensagem para aquela aplicação avisando o evento do clique. A aplicação recebe

então essa mensagem e a trata conforme necessário.Hookssão pontos intermediários

que um aplicativo pode registrar junto ao sistema operacional para receber algum tipo

de mensagem antes que ela seja entregue à janela correta.


O mesmo tipo dehookpode ser registrado por várias aplicações diferentes. Nesse

caso, o sistema operacional passa a mensagem para o primeirohookna fila, que, por

sua vez, deve repassá-lo para o segundohook, e assim por diante, conforme a Fi-

gura4.2, onde se pode verificar também que ohookfica alojado entre o sistema ope-

racional e a aplicação final que receberá a tecla.

Figura 4.2: Hooks: caminho percorrido por uma tecla.

Dentro de uma rotina dehook, o sistema operacional repassa alguns parâmetros

importantes, como as coordenadas do clique domouse. Nesse instante, fica simples

realizar a captura desse clique. Por exemplo, caso o usuárioesteja clicando em um

teclado virtual para a entrada de sua senha no banco, a rotinadehookpoderia utilizar

as coordenadas do clique para tirar uma foto do pedaço da telaonde ocorreu o clique,

roubando assim a senha do usuário, conforme Figura4.3 (teclado virtual extraído de

(SMARTLINK , 2005)).

É interessante notar que nesse momento a janela final que efetivamente recebeu


(a) Teclado virtual para entrada de dados (b) Tela capturada ao clicar na letrai

Figura 4.3: Exemplo de captura de clique demouseutilizandohooks

o clique domouseainda não está a par desse clique, pois a rotina dehook recebe a

mensagem antes de essa ser processada. Portanto, métodos deproteção amplamente

utilizados, como, por exemplo, sumir com os números do teclado virtual no momento

do clique, não protegem contra esse método de captura.

Existem vários tipos dehookque podem ser utilizados para captura de teclas digi-

tadas ou para captura decliquesdemouse, todos baseados no processo descrito anteri-

ormente: monitoração de mensagens enviadas e recebidas porjanelas.

A disponibilização de uma ferramenta como oshookspode ser considerada uma

grave falha na especificação do próprio sistema operacional. Apesar de o mecanismo

dehooksser bastante utilizado por aplicações lícitas, sua concepção leva a crer que o

quesito segurança foi deixado de lado durante seu desenvolvimento. Oshookstornam

extremamente simples a monitoração completa de todas as mensagens trocadas na má-

quina do usuário, e não existe nenhuma maneira de desabilitar esse comportamento.

A simples existência de um mecanismo com essa funcionalidade já pode colocar em

risco a segurança do sistema.

4.4.2.2 Funções estáticas do teclado

Existem noWindowsfunções estáticas que podem ser usadas de forma assíncrona

para o obtenção do estado atual do teclado. Nessas funções deve-se passar um parâme-

tro que especifique o código virtual da tecla que está sendo consultada. Analisando o

retorno dessas funções, é possível saber se a tecla consultada está ou não pressionada

no momento da chamada. Umtrojan pode utilizar esse método para capturar todas


as teclas digitadas pelo usuário, utilizando essas funçõesestáticas dentro de um laço,

passando por todas as teclas que interessarem. A Figura4.4apresenta de forma gráfica

o funcionamento assíncrono dessas funções.

Figura 4.4: Funções estáticas: caminho percorrido por uma tecla.

A grande vantagem da utilização de funções estáticas em vez das funções dehooké

a maneira assíncrona em que essas funções trabalham. Nas funções dehook, o processo

que recebia o clique domouseou a tecla digitada tinha que esperar a rotina dehook

executar para então poder receber a tecla. Isso podia afetara performance em sistemas

lentos ou carregados. Além disso, era necessário escrever uma rotina dehookexterna

para que essa pudesse funcionar de forma global para todos osprocessos. No caso das

funções estáticas, um simples executável com 15 linhas de código já é suficiente para

realizar a captura. Por outro lado, pela sua natureza assíncrona de captura, não se pode

garantir que otrojan que utiliza essa técnica não perca algumas teclas caso o usuário


as digite muito rapidamente ou mesmo capture algumas teclasrepetidas caso o usuário

as pressione por muito tempo.

4.4.2.3 Captura de campos de texto

Apesar de não ser tecnicamente umkeylogger, a captura de campos de texto é

muito prática e difundida naInternet. Nesse caso, a idéia não é capturar o que o usuário

digita no momento em que está pressionando o teclado, mas simcapturar os dados

digitados quando já estiverem contidos num campo de texto doaplicativo destino. O

exemplo da Figura4.5mostra uma tela simples de um sistema qualquer que requisita

que o usuário digite sua senha:

Figura 4.5: Tela para entrada de senha

Durante a digitação, os caracteres não aparecem na tela, evidentemente para tentar

proteger a senha. Assim, caso umtrojan tire uma foto da tela nesse momento, ele não

conseguirá descobrir nada a não ser talvez o tamanho da senhado usuário.

Para esconder a senha, o sistema operacionalWindowsutiliza um truque simples

que nada mais é do que trocar o caractere digitado por um caractere fixo, chamado

dePASSWORDCHAR. Por padrão, oPASSWORDCHARutilizado é o asterisco. Caso

um outro aplicativo mande uma mensagem para essa janela pedindo o texto digitado

num campo do tipo senha, o sistema operacional sabe que não deve repassar nada e só

retorna uma mensagem em branco.

Para passar essa proteção, os aplicativos de captura de campos de texto enviam

uma mensagem para a janela-alvo pedindo para que essa troqueseuPASSWORDCHAR

para zero (o número 0). Ao receber essa mensagem, o comportamento-padrão de qual-


quer janela é verificar que o parâmetro passado é zero e então desabilitar a proteção

da senha. Nesse momento, se o usuário digitar mais alguma coisa no campo, tudo

aparecerá em claro. Para evitar esse problema, os aplicativos de captura mandam logo

em seguida uma mensagem para o campo da senha pedindo o seu valor. Como agora

o PASSWORDCHARé zero, o sistema operacional não acha mais que aquele campo

é restrito, portanto ele repassa a senha completa para quem apedir. Para terminar, o

aplicativo de captura manda uma mensagem final para a janela-alvo pedindo para que

ela retorne seuPASSWORDCHARpara o asterisco. Assim, o usuário não percebe que

o aplicativo de captura conseguiu roubar a senha.

Existe um software muito conhecido e gratuito naInternet, chamadoSnad-

Boy (SNADBOY, 2000), que realiza o processo descrito para a captura de senhas. A

Figura4.6mostra a tela doSnadBoycapturando a senha de um aplicativo de teste.

Figura 4.6: Captura da senha do usuário

4.4.2.4 Drivers

Drivers fazem parte da camada mais baixa que liga ohardwareda máquina com o

sistema operacional. Numa instalação-padrão doWindows, driversde teclado emouse

já vêm instalados e configurados para que possamos utilizar de forma transparente es-

ses periféricos. Mas, internamente, existe uma complexa cadeia de eventos que ocor-

rem entre o bater de uma tecla e a chegada dessa tecla no aplicativo de destino.

O desenvolvimento dedrivers para Windows segue um modelo chamadoWDM


(Windows Driver Model). Dentro desse modelo, umdriver pode ser construído con-

forme três tipos distintos:Bus drivers, Function Driverse Filter Drivers (ver Fi-

gura4.7)

Figura 4.7: Relação entre os vários tipos dedrivers.

• Bus Drivers: controlam uma via de entrada e saída e provêm funcionalidade para

cada placa conectada a essa via de forma transparente ao dispositivo conectado.

Exemplos:PCI, ISA, AGP

• Function Drivers: controlam um dispositivo específico. Exemplos:driver de

teclado ou demouse.

• Filter Drivers: filtram as requisições pendentes de entrada e saída para um dis-

positivo, uma classe de dispositivos ou mesmo uma via.

Como indicado na Figura4.7, o caminho normal que uma requisição de entrada


e saída percorre desde sua geração até sua recepção pelo sistema operacional é o se-

guinte:

Bus Drivers→ Bus Filter Drivers→ Lower-level device filter drivers→ Lower-

level class filter drivers→ Function Driver→ Upper-level device filter drivers→

Upper-level class filter driver.

Todos osFilter drivers são opcionais nesse processo. A diferença entre umclass

filter driverse umdevice filter driveré que o primeiro filtra requisições de uma classe

de dispositivos (por exemplo, todos os discos rígidos da máquina) enquanto o segundo

filtra apenas requisições específicas para um dispositivo (por exemplo, um tecladoMi-

crosoftproprietário).

Um teclado normal possui internamente um micro controlador8042 que fica cons-

tantemente varrendo a matriz de linhas e colunas do teclado para verificar se alguma

tecla está pressionada (HYDE, 2003). Quando o usuário aperta uma tecla, o micro con-

trolador detecta e envia o chamadoscan codedessa tecla para o computador. Cada

scan coderepresenta uma tecla diferente do teclado. Também é gerado um scan code

diferente quando a tecla é liberada.

Quando osscan codeschegam ao computador, outro micro controlador realiza a

conversão dessesscan codespara a tecla respectiva, coloca o resultado na porta de

entrada e saída número 60h e então gera uma interrupção, deixando a cargo doISR

(Interrupt Service Request) tratar a tecla a partir desse momento.

Olhando num nível mais alto, o que chega para odriver instalado na máquina já

é o scan codecorretamente convertido. A partir desse momento, é função do driver

tratar essescan codee convertê-lo corretamente para a tecla sendo digitada. Esse

driver deve, por exemplo, verificar o tempo que uma tecla fica pressionada e gerar

a seqüência corretamente; verificar o pressionamento de teclas comoshift, caps-lock,

num-locke tratar o conjunto dessas teclas com o resto do teclado.


Voltando agora à perspectiva de captura de teclado utilizandodrivers, um atacante

teria as seguintes alternativas:

• Reescrever odevice driver: seria teoricamente possível reescrever odevice dri-

ver de um teclado e substituí-lo na máquina atacada. Mas como a complexi-

dade técnica de umdriver de teclado é razoavelmente grande e como existe uma

grande variedade de layouts e tipos diferentes de teclados,essa opção acaba

sendo pouco prática.

• Escrever umfilter driver: aqui temos várias alternativas defilter drivers: lower-

level, upper-level, class filteroudevice filter. Em qualquer um dos casos, ofilter

driver espião poderia armazenar todas as teclas que passam por seu processa-

mento, e depois apenas repassa-las para o filtro de cima na cadeia, permitindo o

funcionamento correto do teclado da vítima.

O driver mais simples de ser escrito seria umupper-filter class driver. Ou seja, um

driver que é apenas um filtro (não há necessidade de tratar a mensagem), que ficaria

alocado acima dodriver de teclado da máquina (assim as teclas passando pelo filtro já

estariam corretamente tratadas) e que seria genérico para qualquer tipo de teclado (daí

o nomeclass driver).

A implementação de umdriver desse tipo não é de maneira nenhuma trivial. É

necessário trabalhar no nível dokernel (núcleo do sistema operacional) e é preciso

verificar todos os possíveis casos de erro, pois qualquer problema em umdriver pode

causar o travamento total da máquina. A Figura4.8mostra a localização de um possí-

vel filter driver espião dentro do caminho percorrido por uma tecla.

4.4.2.5 DLL Injection

A técnica deDLL injectionpode ser utilizada para diversos fins, benignos ou ma-

lignos. Vamos inicialmente tentar descrever tecnicamenteo queremos dizer porDLL


Figura 4.8:Drivers: caminho percorrido por uma tecla.

Injection.

A idéia dessa técnica, como o nome já diz, é conseguir carregar umaDLL (Dyna-

mic Link Library) dentro de um processo-alvo. O objetivo é conseguir obter acesso à

memória do processo vítima, algo que um programa externo nãoconseguiria. Caso,

por exemplo, umtrojan tentasse ler algum valor residente na memória de um outro

processo, o sistema operacional detectaria uma violação dememória e finalizaria o

trojan. Por essa razão se faz necessário carregar aDLL atacante dentro da memória

do próprio processo vítima. Se isso for realizado com sucesso, essaDLL terá acesso a

toda a memória daquele processo.

A partir do ponto em que otrojan tenha conseguido injetar umaDLL dentro de um

processo-alvo, ele pode agora ler toda a memória do processo, pode acessar variáveis

internas, sobrescrever funções e muito mais. Otrojan pode, por exemplo, sobrescrever


a rotina de tratamento de mensagens do aplicativo. Ele poderia assim monitorar todos

os eventos de teclado oumouseque chegam para a janela vítima. Para manter o fun-

cionamento da janela intacto, otrojan pode ainda repassar as mensagens para a rotina

de tratamento original após o seu processamento.

4.4.3 Telas falsas

Na tabela4.5, apresentamos a classificação do ataque Telas falsas conforme a ta-

xonomia criada.

Telas falsasTipo parcialObjetivo capturaLocal aplicativo de sistemaVulnerabilidade inexperiência do usuárioComplexidade simplesTransparência baixa

Tabela 4.5: Classificação do ataque telas falsas.

Um ataque muito comum que não envolve a captura de teclado é o de telas falsas.

O ataque basicamente tenta enganar o usuário mostrando uma tela muito semelhante

à dositeoficial, normalmente no momento em que o cliente está acessando o serviço

correto. Essas telas normalmente se sobrepõem à tela do navegador de forma a parecer

que fazem parte dositeoficial.

Essas telas falsas são altamente disseminadas principalmente pelo fato de sua im-

plementação ser bem mais simples que a implementação de umkeylogger. Apesar de

não ser totalmente transparente, esse tipo de ataque acaba sendo muito efetivo ou pela

pura ignorância do cliente, ou pela refinada implementação da tela falsa.

Nas Figuras4.10, 4.11e 4.12, apresentamos uma simulação de um ataque desse

tipo. A Figura4.9 apresenta osite oficial de um banco de teste, sem nenhuma mo-

dificação. Na Figura4.10, apresentamos um exemplo de tela falsa bem rudimentar


Figura 4.9:Siteoficial do banco teste.

Figura 4.10: Tela falsa simples atacando um banco teste.

atacando diretamente osite do banco. Na Figura4.11, apresentamos uma tela falsa

um pouco mais refinada que tenta colocar sua tela exatamente em cima da tela origi-

nal, dando a impressão de que nada mudou. Na Figura4.12, apresentamos então uma

tela falsa mais sofisticada que se coloca de forma estratégica exatamente em cima do

campo de senha. Notamos que, mesmo sabendo da existência da tela falsa, é difícil


descobrir exatamente em qual dos campos de senha a tela se colocou.

Figura 4.11: Tela falsa de média complexidade atacando o banco teste.

Figura 4.12: Tela falsa de maior complexidade atacando o banco teste.

Os ataques de telas falsas estão hoje extremamente disseminados. A complexi-

dade desse tipo de tela vem crescendo a cada dia. Até mesmo um usuário experiente

operando a máquina pode ter dúvidas quanto à legitimidade dosite. Sua detecção é

complexa, pois esse tipo de tela se assemelha muito a aplicativos comuns que a maioria


dos usuários possui em suas máquinas.

4.4.4 Ataque de redirecionamento

Na tabela4.6, apresentamos a classificação do ataque de redirecionamento con-

forme a taxonomia criada.

Ataque de redirecionamentoAtaque ao servidorDNS Ataque local

Tipo completo parcialObjetivo captura capturaLocal sistema operacional (do servidor deDNS) sistema operacionalVulnerabilidade vulnerabilidade de implementação vulnerabilidade de especificaçãoComplexidade complexa simplesTransparência média média

Tabela 4.6: Classificação do ataque de redirecionamento.

Toda a comunicação na Internet se baseia no protocolo de redeIP (Internet Pro-

tocol). Esse protocolo estabelece um endereço único para cada máquina ligada à rede.

Sendo assim, quando um computador deseja se comunicar com outro, basta saber oIP

do destino e a mensagem será entregue corretamente.

Mas, como endereçosIP não são muito amigáveis para os olhos humanos, foi in-

ventada a técnica de resolução de nomes. Nessa técnica, o usuário final apresenta como

endereço não mais oIP do destino, mas sim o seu nome. Um servidor centralizado fica

responsável por manter uma tabela indicando qualIP pertence a qual nome. Assim,

para o usuário, a tradução entre nome eIP ocorre de forma transparente.

Na Internet, esse servidor de resolução de nomes (chamadosDNS- Domain Name

System) não é uma única máquina. Existem milhares de servidoresDNSespalhados

pela rede, cada um responsável por resolver o nome de alguns servidores específicos.

Por exemplo, um provedor de acesso àInternetpossui um servidorDNSpróprio que

será utilizado apenas por seus clientes.


Como também é impossível um único servidor deDNSarmazenar todos os no-

mes eIPsexistentes naInternet, esses servidores funcionam dentro de uma hierarquia

vertical. Caso um servidor não conheça um nome específico, elepode perguntar ao

servidorDNSpai se este o conhece, e assim por diante, até que alguém consiga resol-

ver o nome. Por exemplo, quando o usuário digita em seu navegador aURL (Uniform

Resource Locator) www.bancoXXXX.com.br, inicialmente essa requisição será enca-

minhada para oDNS do provedor de acesso desse usuário. Caso esse servidor não

consiga resolver esse nome, ele poderá encaminhar a pergunta para o servidorDNSdo

Banco XXXX.

Aplicando esses conhecimentos, podemos enumerar três possíveis ataques:

1. Ataque direto ao servidor deDNS: caso um atacante consiga acesso privilegiado

a um servidorDNS (provavelmente através da exploração de vulnerabilidades

desse servidor), esse pode modificar as tabelas de resoluçãode nome do próprio

servidor para modificar oIP resolvido para um nome específico. Ou seja, o

atacante pode modificar oIP para qual o nomewww.bancoXXXX.com.brserá

resolvido. EsseIP poderia conter umsite falso, idêntico aositeoficial. Assim

o atacante conseguiria capturar os dados do cliente de formaquase transparente.

Note que esse ataque afetaria todos os clientes que utilizamo servidorDNS

atacado. Além disso, não é necessária a instalação de nenhumtipo detrojan no

cliente atacado. Ou seja, mesmo clientes com sua segurança local intacta podem

estar suscetíveis a esse tipo de ataque.

2. Ataque ao sistema de resolução de nomes da própria máquina dousuário: exis-

tem, dentro do sistema operacionalWindows, alguns módulos e arquivos de con-

figuração que podem armazenar localmente tabelas de resolução de nomes. Du-

rante uma requisição de resolução de nome, o sistema operacional verifica dentro

desses arquivos de configuração se esse nome já não se encontra resolvido. Isso

é feito antes da requisição ser encaminhada para o servidorDNS. Um desses ar-


quivos de configuração se chamahosts, e nada mais é do que um arquivo texto

contendoIPse respectivos nomes. Segue abaixo um exemplo desse arquivo:

127.0.0.1 localhost

192.168.1.2 www.acme.com.br

Dado que o atacante conseguiu instalar umtrojan localmente na máquina da

vítima, esse poderia inserir uma linha nesse arquivo, impedindo assim que o

sistema consulte o servidorDNSpara a obtenção doIP correto.

127.0.0.1 localhost

192.168.1.2 www.acme.com.br

1.2.3.4 www.bancoXXXX.com.br

Com o arquivohostsconfigurado conforme o código acima, no momento em

que o cliente digitarwww.bancoXXXX.com.br, o sistema automaticamente o re-

direcionará para oIP 1.2.3.4sem nem mesmo consultar o servidorDNS. O lugar

referente a esse endereçoIP poderia conter umsitefalso, semelhante aositeofi-

cial, onde o atacante capturaria as informações criticas docliente. Novamente,

esse ataque pode ser realizado de forma quase transparente para o usuário.

3. Troca deURL no navegador do cliente: esse método de ataque é semelhante

ao anterior, no sentido de que otrojan deve primeiro conseguir se instalar na

máquina do cliente antes de continuar com o ataque. Mas, nesse ataque, não há

modificação nenhuma nos arquivos de configuração do sistema operacional. O

ataque ocorre da seguinte forma:

• O trojan fica escondido, monitorando todas asURLsque o navegador do

usuário acessa.

• Quando o usuário acessar aURL a ser atacada (por exemplo,

www.bancoXXXX.com.br), o trojan redireciona o navegador para uma pá-

gina localmente instalada na própria máquina do cliente. Essa página, que


provavelmente foi trazida junto com otrojan, é bem semelhante à do banco

sendo atacado.

• Depois que o usuário digita seus dados críticos dentro da página falsa, o

trojan redireciona o cliente novamente para ositeoriginal, tornando assim

o ataque quase transparente.

4.4.5 Ataque à máquina virtualJava

Na tabela4.7, apresentamos a classificação do ataque à máquina virtualJavacon-

forme a taxonomia criada.

Ataque à máquina virtual JavaTipo parcialObjetivo capturaLocal aplicativo geraisVulnerabilidade vulnerabilidade de especificaçãoComplexidade médiaTransparência alta

Tabela 4.7: Classificação do ataque à máquina virtualJava.

A máquina virtualJavaatua como uma camada entre o sistema operacional e os

aplicativosJava. A utilização da máquina virtualJavaé especialmente útil por dois

motivos:

1. O mesmo códigoJavapode ser executado em diferentes plataformas, desde que

exista uma máquina virtualJavacompatível naquele ambiente.

2. A máquina virtualJava tem o poder de controlar completamente o código que

ela executa.

Em termos de segurança, o segundo item citado é o mais importante. Essa funcio-

nalidade de isolamento e restrição de aplicativos em execução é chamada desandbox.

A máquina virtualJavasempre executa aplicativos não confiáveis dentro dasandbox.


O programa em si pode tentar executar o que bem desejar, mas todas as suas operações

estarão limitadas pelasandbox. AplicativosJavaem execução dentro dasandboxnão

podem realizar as seguintes ações:

• Ler ou escrever arquivos do disco

• Estabelecer conexões através de uma rede

• Criar novos processos

• Carregar dinamicamente novas bibliotecas

• Chamar funções nativas do sistema operacional

Evitando que códigos não confiáveis executem essas operações, o modelo de segu-

rança doJavaprotege o usuário local contra programas maliciosos. Dentro do modelo

de segurança doJava, existe uma classe especialmente importante chamadaSecurity

Manager. O papel doSecurity Manageré controlar quem pode realizar certas opera-

ções. Quando um aplicativoJavatenta utilizar uma função mais perigosa (uma função

que potencialmente poderia levar a um ataque), como por exemplo, uma função de

acesso a disco, a própriaAPI (Application Programming Interface) Javaem execução

pergunta aoSecurity Managerse esse processo pode ou não realizar essa ação. Se

o Security Managerverificar que essa operação não é permitida, ele emite um erroe

a execução dessa função é abortada. Toda a lógica de bloqueiorealizada pelosand-

boxestá implementada dentro da classeSecurity Manager. Essa classe está embutida

dentro das próprias bibliotecas derun-timedoJava.

O ataque descrito a seguir serve como exemplo para demonstrar como é possí-

vel modificar arbitrariamente o comportamento da máquina virtual Java. Os passos

necessários para realizar o ataque são os seguintes:

1. Abrir a biblioteca derun-time do Java (que nada mais é do que um arquivo

compactado) que contém a classeSecurity Manager


2. Descompilar a classeSecurity Manager

3. Modificar a classeSecurity Manager, retirando algumas validações

4. Recompilar a classeSecurity Manager

5. Compactar novamente a biblioteca derun-timedoJava

6. Substituir a biblioteca derun-timedoJavapela adulterada

Durante o passo 3, podemos retirar alguma verificação de proteção doSecurity

Manager, quebrando osandboxe possibilitando assim que aplicativosJavapossam se

comportar de maneiras anteriormente não permitidas.

O ataque descrito acima pode ser aplicado diretamente para captura de dados críti-

cos de clientes. Muitas páginas deInternet Bankinge comércio eletrônico utilizam os

chamadosapplets de autenticação. Essesappletstêm como objetivo melhorar a segu-

rança do cliente durante seu processo de autenticação. Exemplos dessesappletssão:

appletspara entrada de senhas; teclados virtuais;appletsde criptografia;appletsque

implementam autenticação utilizando certificação digital; appletsque implementam

autenticação por biometria; entre muitos outros possíveis.

Utilizando o ataque descrito, umtrojan localmente instalado na máquina do cliente

pode criar uma maneira relativamente simples e multiplataforma para capturar dados

de usuários. Para atacar umapplet de entrada de senha, otrojan poderia substituir

a classe que recebe a senha do cliente. A nova classe poderia armazenar a senha do

cliente em disco e depois repassar a senha para a classe original, mantendo assim o

ataque totalmente transparente. Paraappletsde criptografia, otrojan poderia trocar

a própria classe que implementa a cifra criptográfica, armazenado a senha em aberto

antes de essa ser encriptada. Para agilizar esse processo, otrojan poderia vir já com as

classes a serem trocadas pré-compiladas. Isso tornaria o ataque mais rápido e prático.

4.5 Considerações finais 61

O ponto forte desse ataque é sua forma totalmente transparente de execução.

Mesmo usuários experientes utilizando a máquina infectadaterão dificuldade em notar

alguma diferença no processo de autenticação.

4.5 Considerações finais

Os ataques aqui apresentados não precisam necessariamenteser utilizados de

forma isolada. É sempre possível, e talvez até mais efetivo,juntar dois ou mais ataques

para torná-los mais fortes. Por exemplo, umkeyloggerpode utilizar a técnica dehooks

junto com a técnica deDLL Injection, tornando assim mais efetiva sua captura dos

dados críticos.

62

5 MÉTODOS DE PROTEÇÃO AO CLIENTE

5.1 Resumo

Neste capítulo são apresentadas as possíveis defesas que devem proteger os clien-

tes dos ataques explicados anteriormente. Para cada técnica de proteção descrita, será

explicado exatamente qual ataque está sendo inibido e quaisas vantagens e desvanta-

gens do uso dessa proteção.

5.2 Considerações iniciais

Não é um trabalho simples tentar defender o cliente dos ataques citados nas seções

precedentes. Como a máquina do cliente está fora do controle da instituição que opera

o sistema transacional, é difícil poder contar com qualquertipo de premissa de segu-

rança nesse ambiente. A máquina do cliente é um campo de batalha desconhecido.

Alguns clientes podem cuidar bem de sua segurança, instalando sistemas de antivírus

efirewalls, enquanto outros podem simplesmente usar o computador exatamente como

ele veio de fábrica.

A criação de umsoftwarea ser executado em um ambiente tão inóspito deve ser

feita com extremo cuidado.

Nos próximos capítulos, o nomemódulo de segurançaserá utilizado para referen-

ciar umsoftwareinstalado localmente na máquina do cliente e que tem como objetivo

bloquear a ação dos atacantes. Esse módulo de segurança podeser também um con-

5.2 Considerações iniciais 63

junto desoftwares, incluindo a configuração adequada de cada um deles.

A instalação local de umsoftwarena máquina do cliente traz consigo sérias ques-

tões de segurança e privacidade. Como um usuário pode estar seguro de que esse

módulo de segurança faz somente o que ele se propõe a fazer? Como garantir que esse

módulo seja originário de uma instituição idônea? Como garantir que a privacidade

do cliente não estará sendo invadida com essesoftwareque pode possivelmente estar

realizando qualquer tipo de monitoração em sua máquina?

A instalação local desse módulo de segurança pode acostumaro cliente mais leigo

a aceitar qualquer tipo de instalação desoftwareem sua máquina. A propaganda da

instalação desse módulo de segurança pode até ser usada portrojans como fonte de

material para realizar umspammais direcionado, ou seja, umtrojan poderia vir disfar-

çado tentando se passar pelo módulo de segurança.

Todas essas questões são mais políticas do que técnicas. As respostas para essas

perguntas fazem parte de um escopo mais global de aquisição de conhecimentos e

conscientização dos clientes quanto à navegação segura e segurança naInternet. Neste

capítulo nos limitaremos a tratar dos aspectos mais técnicos referentes aos ataques e

proteções possíveis. Os tópicos referentes às perguntas acima serão tratados em maior

detalhe no Capítulo6.

5.2.1 Batalhas em uma guerra injusta

A batalha que ocorre na máquina do cliente entre atacantes e os programas de

proteção é extremamente injusta. A proteção sempre foi maiscomplexa que o ataque,

mas nesse caso específico a diferença é ainda maior. Abaixo seguem alguns cuidados

que umsoftwarede proteção deve ter, mas com os quais umsoftwaremalicioso não

precisa necessariamente se preocupar.

• Compatibilidade: como o ambiente de máquinas de clientes é normalmente


muito heterogêneo, umsoftwarede proteção deve estar preparado para funci-

onar perfeitamente em todos esses ambientes. Em nenhum momento osoftware

pode apresentar um erro, ou ainda impossibilitar o cliente de exercer alguma

função em sua máquina. Os programas maliciosos não têm necessariamente

essa preocupação. Um atacante pode confeccionar umtrojan que seja efetivo

somente em um sistema operacional especifico. Clientes que possuam outro sis-

tema operacional não serão afetados. Otrojan pode até mostrar um erro na tela

ao ser instalado nesses outros sistemas operacionais, poiso atacante não precisa

se preocupar com possíveis reclamações de clientes. Além disso, se otrojan não

foi muito bem testado e causar um erro grave em algumas situações, novamente

o atacante não precisa se preocupar com isso. Desde que otrojan tenha bons

resultados em um número razoável de máquinas, o ataque já será bem-sucedido.

• Consumo de recursos: muitas vezes, programas maliciosos baixam e enviam

grande quantidade de dados pelaInternet, consomem grande quantidade deCPU

(Central Processing Unit), memória e até espaço em disco. Umtrojan pode

baixar muitosmegabytesdaInternetsem encontrar problemas. O cliente poderá

até notar que sua conexão está mais lenta, mas mesmo assim elenão terá para

quem reclamar. Muitas vezes, para realizar a captura de teclado do cliente, um

keyloggerpode consumir quase toda aCPU da máquina para garantir que não

irá perder nenhuma tecla. Um programa de proteção não pode fazer nada do

gênero. Um programa de proteção não pode esgotar os recursosda máquina do

cliente, não pode deixar a máquina sobrecarregada e não podedeixar a conexão

com aInternetlenta.

• Identificação do oponente: existem hoje milhares de variantes de programas ma-

liciosos naInternet. O crescimento detrojans está cada vez mais se aproxi-

mando do crescimento de vírus: a cada dia surge um novo. Para um programa

de proteção, é difícil identificar na máquina do cliente quais processos são ma-


liciosos e quais não são. Como um antivírus, esse sistema de proteção terá que

ser constantemente atualizado para tentar manter um nível razoável de proteção.

Por outro lado, umtrojan que ataca uma instituição especifica sabe exatamente

qual o programa de proteção que aquela instituição utiliza.Muitas vezes, os ata-

cantes podem até ser clientes dessa instituição. Dessa maneira, o atacante sabe

qual programa estará executando na máquina do cliente que tentará bloquear seu

acesso. Sendo assim, o atacante tentará provavelmente desinstalar osoftwarede

segurança antes de realizar seu ataque.

• Distribuição: realizar a distribuição em larga escala de umsoftwarede prote-

ção não é tarefa fácil. Clientes muitas vezes podem estranharque a instituição

está querendo instalar umsoftwareem sua máquina. Clientes irão reclamar, ligar

para centrais de atendimento, mandare-mails, e muito mais. E a cada atualização

do software(que com certeza será necessária e freqüente), o cliente novamente

será atrapalhado e advertido. Por outro lado, por mais incrível que pareça, a

distribuição de programas maliciosos é extremamente simples. Caso o atacante

queira distribuir um novo tipo detrojan, ele só tem que criar ume-mailchama-

tivo, colocar umlink nessee-mail para otrojan, e enviá-lo para o máximo de

pessoas possível. Obviamente, muitas das pessoas que receberem essee-mail

irão ignorá-lo, mas os poucos que abrirem e executarem otrojans já estarão in-

fectados. Se posteriormente o atacante resolver mudar de alguma maneira o seu

mecanismo de ataque, basta o envio de outroe-mail. O atacante não almeja que

todos os clientes instalem seusoftware. O atacante não se preocupa com os cli-

entes que irão reclamar doe-mail recebido. Para o atacante, basta que alguns

instalem otrojan que o ataque já será bem-sucedido.


5.2.2 Prevenindo a desinstalação

Como dito anteriormente, caso alguma instituição operadorade um sistema tran-

sacional deseje disponibilizar umsoftwarede proteção para seus clientes, um dos pri-

meiros problemas a serem tratados será a prevenção da desinstalação desse módulo.

Da mesma maneira que muitos vírus tentam desabilitar sistemas conhecidos de anti-

vírus, trojans tentarão desinstalar esse novo módulo de proteção. Normalmente, é até

mais fácil desinstalar um sistema de proteção do que tentar ultrapassar suas proteções.

Inicialmente vamos definir o que é uma desinstalação: basicamente, umtrojan será

bem-sucedido em desinstalar um sistema de proteção se conseguir de alguma maneira

fazer que este pare de executar seus mecanismos de proteção,seja imediatamente ou

mesmo numa próxima sessão (como por exemplo, na próxima reinicialização da má-

quina). De maneira prática, para realizar a desinstalação de um módulo de segurança

um trojan poderá tentar:

1. Apagar os arquivos pertencentes ao módulo

2. Apagar as chamadas de inicialização do módulo (como chaves no registry)

3. Desconfigurar o módulo

Prevenir a desinstalação nada mais é do que impedir que umtrojan realize os

passos acima. Mas essa tarefa é mais árdua do que parece.

Do ponto de vista técnico, existem várias maneiras que um programa pode usar

para tentar prevenir sua desinstalação. É inviável listar extensivamente todos esses

métodos, portanto foram escolhidos apenas os mais simples para apresentar somente a

idéia de prevenção de desinstalação. Esses métodos são:

• Manter os arquivos importantes do módulo sempre em uso, fazendo com que o

próprio sistema operacional impeça a sua remoção.


• Utilizar a técnica de injeção deDLL para anexar asDLLs importantes em proces-

sos de sistema, impedindo quetrojans terminem a execução desses aplicativos.

• Monitorar todas as chamadas do sistema de arquivo e filtrar asoperação de ten-

tativa de deleção dos arquivos do módulo.

• Modificar as listas de acesso e permissão do processo protegido, impedindo as-

sim que outros programas consigam terminá-lo.

Essas são apenas algumas maneiras de tentar impedir a desinstalação de um mó-

dulo. Mas como estamos tratando aqui de um ambiente do qual não possuímos controle

(a máquina do cliente), é quase impossível afirmar que a prevenção da desinstalação

será sempre efetiva. Dessa maneira, além de um mecanismo de prevenção de desinsta-

lação, um módulo de segurança deve possuir também um mecanismo de autenticação

e validação com ositede sua instituição transacional. Assim, no momento em que um

usuário acessar osite, este deve conseguir verificar, com confiança, que o módulo de

segurança necessário não foi desinstalado ou modificado, conforme esquema simplifi-

cado apresentado na Figura5.1.

Figura 5.1: Validação do módulo de segurança.

Realizando as validações apresentadas na Figura5.1, o siteda instituição terá uma

boa garantia de que o módulo de segurança não foi desinstalado nem modificado. Esse

método não é à prova de falhas, mas já provê uma boa melhora de segurança.

5.3 Modos de proteção 68

5.3 Modos de proteção

Nessa seção apresentamos alguns dos métodos que o módulo de segurança pode

utilizar para tentar manter um nível de proteção efetivo contra os ataques apresentados

nos capítulos anteriores.

5.3.1 Sistemas que operam como antivírus

A proteção do tipo antivírus é talvez umas das mais utilizadas. Essa proteção se

baseia no conhecimento prévio dos programas atacantes pararealização do bloqueio,

ou seja, um antivírus normalmente só bloqueia os vírus que ele conhece. Por um lado,

essa proteção pode ser muito efetiva, pois um antivírus recém-atualizado pode bloquear

efetivamente vários ataques. Por outro lado, um antivírus está sempre um passo atrás

do vírus, sendo necessário o aparecimento primeiro do víruspara depois ser criada a

chamada vacina. Além disso, sistemas de antivírus requerematualizações constantes

para manter um nível de efetividade elevado.

Um antivírus funciona a base de assinaturas. Ele verifica dentro de arquivos, pos-

sivelmente infectados, a existência dessas assinaturas oumesmo de um conjunto delas.

Assinaturas nada mais são do que cadeias binárias. Caso essascadeias binárias sejam

encontradas dentro de um arquivo, este arquivo é considerado infectado. Um problema

que os antivírus possuem é a detecção de falsos positivos. Falsos positivos são progra-

mas que possuem alguma assinatura da base de dados do antivírus, mas que na verdade

não estão infectados. Assim, o sistema de antivírus detectaerroneamente esse arquivo

como infectado. No momento de geração das assinaturas do antivírus, é necessário

então tomar cuidado com a detecção excessiva de falsos positivos. Assinaturas muito

genéricas, apesar de detectarem uma grande família de vírus, podem vir a trazer mui-

tos falsos positivos. Assinaturas muito específicas podem diminuir muito o número de

falsos positivos, mas também não detectam tantos vírus diferentes.


No caso específico de fraudes em instituições que operam sistemas transacionais,

não estamos falando exatamente de um antivírus, mas sim deantitrojan. Existe uma

grande diferença entre esses dois produtos. Vírus normalmente infectam arquivos exe-

cutáveis, modificando seu comportamento e adulterando seu próprio código binário.

Para remover um vírus, é necessário retirar esse pedaço de código binário de dentro do

executável. Normalmente esse código binário inserido é fixo, e, portanto, simples de

ser encontrado: basta comparar o código inicial com o códigoadulterado. Por outro

lado, a infecção se dá dentro dos próprios arquivos, o que torna necessária a leitura

completa de todos os executáveis da máquina para realizar a desinfecção, o que pode

ser um processo lento e custoso.

Trojansdiferem bastante de vírus.Trojanssão executáveis separados.Trojanstêm

seu próprio código de execução, e normalmente não modificam nenhum aspecto dos

arquivos de sistema. Por um lado, isso os torna simples de serem detectados, pois é

necessário apenas verificar quais processos estão em execução no sistema. Por outro

lado,trojanssão incrivelmente parecidos com aplicativos comuns. A maioria dostro-

jansapenas abre algumas janelas e envia algumas informações pela Internet. Muitos

aplicativos realizam essas tarefas. Portanto, fica difícilencontrar assinaturas que de-

tectem uma grande família detrojans e que não apresentem falsos positivos. Como

novostrojansaparecem a cada dia, assinaturas muito específicas acabam sendo inefi-

cazes. Portanto, é um difícil trabalho achar um meio-termo,encontrando um conjunto

de assinaturas efetivas que detecte uma grande gama detrojanse ao mesmo tempo não

apresente falsos positivos.

Normalmente, umantitrojan atualizado faz parte de qualquer módulo de segu-

rança. Nesse caso, a tarefa do antitrojan é proteger o sistema dostrojansjá conhecidos.

Para isso, ele deve ser constantemente atualizado. Isso requer um trabalho de pesquisa

e evolução contínua, o que pode se tornar custoso do ponto de vista operacional.

Um sistema deantitrojan, dependendo de sua ação, pode ser considerado extre-


mamente intrusivo. Como estamos tratando de clientes, que muitas vezes não têm (e

nem desejam ter) conhecimento sobre os aspectos de segurança envolvidos, o sistema

deantitrojanembutido no módulo de segurança deve ter o mínimo, ou talvez nenhuma

interação com o usuário. Ou seja, o sistema deve detectar ostrojanse realizar a ação

necessária sem o conhecimento do usuário.

Esse sistema deantitrojan, portanto, estará varrendo todos os programas que estão

sendo executados na máquina do cliente. Caso ele encontre algum trojan conhecido

sendo executado, temos aqui duas opções:

1. Apagar o executável referente aotrojan encontrado: esse processo, apesar de

extremamente efetivo no aspecto de proteção, pode trazer grandes problemas

para a instituição que opere o sistema transacional, principalmente quando se

trata da detecção de um falso positivo. Apagar um programa erroneamente da

máquina de um cliente pode ser catastrófico.

2. Terminar a execução dotrojan encontrado: esse procedimento é menos intrusivo,

pois estaremos apenas terminando a execução de um processo.Se, por acaso,

esse for um falso positivo, o usuário pode sempre executá-lonovamente num

tempo futuro. De qualquer maneira, se esse processo encontrado for mesmo um

trojan, este poderá ser novamente iniciado na próxima inicialização da máquina,

sendo assim necessária a constante varredura dos processosem execução para

evitar que ostrojansse reiniciem.

Outro aspecto importante quanto a efetividade e intrusão dosistemaantitrojan é

o momento em que essa proteção deve ser ativada. Nesse caso temos novamente duas

alternativas viáveis: iniciar o sistema logo que a máquina for ligada, ou iniciar o sis-

tema somente quando o usuário acessar ositeda instituição transacional. Cada opção

tem suas vantagens e desvantagens. Na primeira opção, a de iniciar o sistema junta-

mente com a máquina, a vantagem é que a proteção estará sempreativa. Não existirá


um momento em que umtrojan poderá atacar e que o sistema não esteja protegido.

As desvantagens são duas: primeiro que o sistema estará protegendo o usuário inde-

pendentemente deste estar acessando osite em que necessita de proteção, ou seja, a

proteção estará ocorrendo em qualquersite que esse usuário possa entrar. Isso nem

sempre é uma característica interessante. A outra desvantagem está ligada aos falsos

positivos; a finalização de falsos positivos durante o acesso aosite transacional é bem

menos problemática que a finalização de falsos positivos a qualquer momento. Um

falso positivo, nesse caso, teria uma repercussão muito grande e poderia causar sérios

problemas à instituição.

A segunda opção, a de ligar a proteção somente nositeda instituição, tem a van-

tagem de interferir no funcionamento da máquina do usuário somente quando esse

acessa ositeda instituição, mas por outro lado, deixa o usuário desprotegido nos ou-

tros momentos. Umtrojan poderia explorar essa vulnerabilidade para atacar o sistema.

5.3.2 Firewall

Sistemas defirewall são extremamente úteis em dois casos: impedir que aplicati-

vos maliciosos se instalem remotamente na máquina do usuário (possivelmente explo-

rando vulnerabilidades do sistema operacional); e impedirque aplicativos maliciosos

já instalados localmente consigam enviar os dados capturados para aInternet. Apesar

disso, sistemas defirewall são normalmente complexos de ser operados, não sendo as-

sim muito aconselhados para usuários leigos em informática. Portanto, como estamos

aqui tratando de um módulo de segurança que deve ter o mínimo possível de interface

com o usuário, o sistema defirewall acaba não sendo tão aconselhável para esse ce-

nário. Sistemas defirewall mais simples (como por exemplo afirewall do Windows

XP Service Pack 2), acabam sendo úteis apenas para evitar invasões remotas, oque

normalmente pode também ser impedido mantendo-se o sistemaatualizado com todas

as correções de segurança.


Além disso, o nível de intrusão que um sistema defirewall pode causar é muito

grande. Umafirewall deve monitorar todo o tráfego de rede, podendo possivelmente

analisar todas as informações que estão sendo transmitidaspela máquina do usuário.

5.3.3 Atualizações de segurança

Uma das maneiras mais rápidas de se espalhar uma nova praga pela Internet é

explorando-se vulnerabilidades conhecidas de sistemas operacionais ou aplicativos.

Os worms Sassere Blaster, citados no capítulo3 são exemplos disso. Mais recente-

mente, a vulnerabilidade do formatoWMF (Windows Metafile) (MICROSOFT, 2005a),

descoberta em 28 de dezembro de 2005, demorou apenas algumashoras para ser uti-

lizada por atacantes para a disseminação deworms, vírus,spywarese trojans (LABS,

2005). Como muitos usuários não instalam as atualizações necessárias de segurança,

essas brechas podem ser exploradas por um bom tempo com grande efetividade.

A instalação dessas atualizações de segurança não é em si umatarefa que o mó-

dulo de segurança possa executar. Essas atualizações devemacontecer utilizando-se

as ferramentas dos próprios fabricantes dos sistemas operacionais. Nesse caso, a fun-

cionalidade do módulo de segurança se limita a talvez avisarao usuário que alguma

atualização crítica ainda não foi instalada em seu sistema.Esse ponto, como dito no

começo deste capítulo, está mais ligado à conscientização einstrução do usuário sobre

navegação segura do que a um aspecto técnico de implementação. De qualquer ma-

neira, a atualização e a correção do ambiente são fatores críticos para a segurança do

sistema e devem ser tratadas com cuidado.

5.3.4 Antikeylogger

No capítulo4, descrevemos diversas maneiras que poderiam ser utilizadas para

realizar a captura das teclas e doscliquesde mouseexecutados pelo usuário. Nesta

seção, apresentaremos algumas contramedidas que podem seradotadas para bloquear


esse tipo de captura.

A utilização deantikeyloggerscomo ferramenta de proteção pode vir a ferir a

privacidade do usuário. Como será apresentado a seguir, umantikeyloggerutiliza a

mesma estratégia para bloquear a captura que umkeyloggerutiliza para roubar os da-

dos. O funcionamento dos dois sistemas são muito semelhantes. Portanto, umantikey-

logger teria a possibilidade de monitorar todas as teclas ecliquesdemouserealizados

pelo usuário, inclusive quando este nem estiver acessando ositeprotegido.

5.3.4.1 Hooks

A técnica de proteção contrahooksé bem semelhante à técnica de captura de teclas

utilizandohooks. Como explicado no capítulo4, o hooké um mecanismo de intercep-

tação que funciona de maneira encadeada: o sistema operacional, ao receber um tecla,

a repassa para o primeirohookda cadeia. Este por sua vez, repassa a mensagem para

o segundohookda cadeia, e assim por diante. Ao final, quanto todos oshooksregis-

trados já receberam a mensagem, o sistema operacional passafinalmente a mensagem

para a janela destino. Esse mecanismo já foi representado naFigura4.2. Uma pos-

sível proteção que o módulo de segurança pode utilizar para prevenir esse método de

captura é o seguinte: o módulo obteria umhookdo sistema operacional. Quando uma

mensagem de teclado ou demousefor enviada para essehook, o módulo não repassa

essa mensagem para os outroshooksinstalados, redirecionando-a diretamente para a

janela destino. Esse mecanismo está exemplificado na Figura5.2.

Utilizando esse método, o módulo de proteção consegue efetivamente enganar os

outroshooksregistrados no sistema. Porém, existem alguns problemas inerentes a esse

tipo de proteção:

1. O módulo de proteção deve garantir que seuhook seja o primeiro na cadeia,

conforme representado na Figura5.2: para realizar essa tarefa, o módulo de


Figura 5.2: Proteção contra captura utilizandohooks.

segurança deve voltar constantemente a se registrar como umhook. Caso ele

faça isso muito lentamente, é possível que algumtrojan consiga se registrar no

meio do caminho e seja então bem-sucedido na captura de algumas teclas; caso

ele realize isso muito rapidamente, esse processo pode vir aconsumir grandes

quantidades de processamento da máquina do usuário, deixando todo o sistema

lento.

2. O módulo de proteção estará bloqueando não apenas ostrojansque tenham ins-

taladohooks, mas também todos os outros aplicativos que porventura possam

utilizar hooks: os hooksforam criados como ferramentas para tornar o desen-

volvimento de alguns tipos de aplicações mais simples. Alguns exemplos de

aplicativos que podem utilizarhookssão: aplicações de auxílio a deficientes vi-

suais ou aplicações de leitores de códigos de barras. Nesse caso, essas aplicações

passariam a não funcionar corretamente enquanto a proteçãodehooksestivesse

ativa.


Os problemas que acabamos de descrever podem causar grande repercussão e de-

vem ser tratados com cuidado.

5.3.4.2 Captura de campos

Conforme explicado no capítulo4, a captura de campos de texto é um outro método

que um atacante pode utilizar para obter uma senha. Recapitulando rapidamente, esse

ataque funciona da seguinte forma:

1. O atacante envia uma mensagem para a janela vítima pedindo para que esta

troque seu caractere de senha (que por padrão é o asterisco) para o número 0.

2. O atacante então envia uma mensagem para a janela vítima pedindo o valor do

campo de senha.

3. Ao final, o atacante envia uma outra mensagem à janela vítima restaurando o

asterisco como o caractere de senha.

A proteção contra esse processo é relativamente simples. Para evitar a captura da

senha, tudo que o aplicativo vítima deve fazer é ignorar as mensagens que requisitem

seu campo de senha. Apesar de intuitivo, esse comportamentonão é padrão para as

janelas doWindows. Ignorando essa mensagem, o aplicativo evita assim que a captura

dos campos de senha seja bem-sucedida.

A solução apresentada, apesar de simples, não é sempre viável. Muitas vezes

os aplicativos que estão sendo utilizados para a digitação da senha não estão sob o

controle da instituição. Um exemplo muito comum disso é a entrada de senha dentro

de um navegadorweb. Esse navegador é desenvolvido por uma empresa terceira e,

portanto, não é possível modificar seu comportamento conforme explicado. Nesse

caso, será necessário utilizar outro método de proteção para evitar a captura da senha.


Dentro de um navegadorweb, existe uma facilidade chamadalinguagens de script.

Essas linguagens possibilitam um comportamento mais dinâmico das páginas, como

a implementação de menus flutuantes ou de validação de formulários. No contexto

desta seção, essas linguagens podem ser utilizadas para ajudar a prevenir a captura

de campos de senha. Para realizar essa tarefa, o desenvolvedor deve implementar a

página de maneira que a senha que será colocada no campo de senha não seja a senha

real, mas sim qualquer outra seqüência aleatória de caracteres. A senha real deverá

ser armazenada em memória e será colocada dentro do formulário apenas na hora do

seu envio ao servidor. Abaixo mostramos passo a passo como seria esse processo de

proteção.

1. Usuário digita um caractere da sua senha no campo de senha

2. Script da página retira esse caractere do campo de senha e o coloca emuma

variável em memória

3. Scriptsubstitui o caractere no campo de senha por um outro caractere aleatório

(um asterisco, por exemplo)

4. Esse processo é repetido até que o usuário digite sua senha completa

5. Ao final, o script coloca a senha digitada pelo usuário dentro de um campo

escondido e a envia junto ao formulário

Seguindo os passos acima, caso um aplicativo malicioso tente enviar uma men-

sagem de captura, ele receberá como resposta uma seqüência qualquer de caracteres

aleatórios, sendo malsucedido assim na captura da senha.

Em termos da privacidade do usuário, não há nenhum problema em utilizar a pro-

teção acima. Como a senha já estaria sendo digitada na aplicação da instituição, nada

foi modificado.


5.3.4.3 Drivers

No capítulo4 apresentamos uma maneira na qual umdriver poderia ser utilizado

para capturar as teclas digitadas pelo usuário. Nesta seçãomostraremos que também é

possível, de forma muito semelhante, utilizar umdriver para proteger o sistema contra

a captura de teclas.

A idéia da proteção segue a mesma idéia utilizada no sistema dehooks. O objetivo

aqui é criar umdriver de baixo nível, do tipoupper-filter driver, que possa bloquear to-

das as teclas digitadas. Essedriver passaria as teclas apenas para a aplicação legitima,

que então as apresentaria na tela. Essa situação está ilustrada na Figura5.3.

Figura 5.3: Proteção contra captura utilizandodriver.

Conforme indicado na figura, as teclas digitadas pelo usuáriosão direcionadas

diretamente para a aplicação destino, sem nem mesmo passar pelo sistema operacional.

Essa proteção, apesar de extremamente efetiva, tem diversos problemas envolvi-

dos. Inicialmente, temos o problema do processo de desenvolvimento de umdriver,

que não é muito simples e deve ser feito com muito cuidado, pois qualquer problema


em sua implementação pode causar a queda completa do sistemaoperacional. Em se-

gundo lugar, temos aqui um problema semelhante ao problema da proteção dehooks:

outros aplicativos lícitos que estejam na máquina não receberão as teclas digitadas e,

portanto, não funcionarão de forma correta. Isso pode ser umgrande problema quando

tratamos, por exemplo, de aplicativos de ajuda a deficientesvisuais que devem capturar

todas as teclas para que funcionem corretamente.

O problema mais grave que ocorre na utilização de umdriver é transmitir as teclas

digitadas dodriver até a aplicação destino de forma segura. Conforme mostrado na

Figura 5.3, o driver deve repassar diretamente as teclas digitadas para a aplicação

final. Mas, de um ponto de vista técnico, a aplicação final não está esperando as

teclas vindas dodriver, e, portanto, não funcionará corretamente. Como conseqüência

desse problema, junto com odriver é necessário então implementar um aplicativo que

execute em modo usuário e que receba as teclas vindas dodriver. Esse aplicativo, que

chamaremos de módulo de suporte, terá então o trabalho de repassar essas teclas para

o aplicativo lícito. Deve-se tomar muito cuidado na comunicação entre odriver e o

módulo de suporte. Umtrojan poderia tentar explorar essa comunicação para obter as

teclas digitadas. É necessário então utilizar métodos criptográficos de autenticação e

sigilo dos dados para garantir a confidencialidade dos dadostrafegados.

Além disso, dado que o aplicativo de suporte recebeu as teclas corretamente, ainda

precisa repassá-las para o aplicativo no qual o usuário estádigitando. Esse processo,

apesar de simples, pode acabar comprometendo toda a segurança do sistema, pois é

nesse ponto que os dados podem ser mais facilmente capturados. É necessário en-

tão criar um método seguro para transmitir as teclas entre o aplicativo de suporte e o

aplicativo final. Esse pode vir a ser um trabalho muito complexo e extenso.

De qualquer maneira, existem soluções para esse problema. Épossível criar uma

maneira segura para transmitir os dados entre o aplicativo de suporte e o aplicativo

final. As possíveis soluções são extremamente técnicas e fogem do escopo deste tra-


balho, e portanto não serão explicadas aqui.

5.3.4.4 DLL Injection

A técnica deDLL Injectionpode também ser utilizada para prevenir a captura de

teclas. A idéia aqui é injetar umaDLL dentro dostrojanse bloquear o uso das funções

do sistema operacional que poderiam ser utilizadas para a captura (como por exemplo

as funções dehookou as funções estáticas de teclado).

Como nem sempre é possível identificar qual processo em execução é otrojan, esse

método acaba tendo que injetar aDLL de proteção em todos os processos na máquina.

Isso acaba sendo muito perigoso, pois estaremos interferindo nos processos de sistema

e poderemos assim estar afetando todo o comportamento da máquina. Além disso, o

processo de injeção deDLL e de redireciomanento deAPI é extremamente agressivo e

pode comprometer a estabilidade da máquina.

De qualquer maneira, esse método pode ser muito eficaz na prevenção da captura

de teclas. Mas é necessário cuidado para utilizá-lo da maneira mais correta possível.

No aspecto de privacidade do usuário, a técnica deDLL Injectioné extremamente

intrusiva. Ao injetar umaDLL em cada processo do sistema, pode-se em teoria moni-

torar o comportamento de todas as aplicações sendo executadas. É possível registrar

de modo completo todas as interações do usuário com o sistema, clique por clique e

tecla por tecla.

5.3.5 BHO

A tecnologia chamadaBHO (Browser Helper Object) prove uma maneira simples

para que um aplicativo monitore todas asURLsnavegadas pelo usuário. Para utilizar

essa tecnologia, um aplicativo deve simplesmente se registrar no sistema operacional

como umBHO. Após esse registro, o sistema operacional informará automaticamente


todos os eventos referente à navegaçãowebdo usuário.

Esse método é muito utilizado porspywarespara monitoração dos acessos das ví-

timas. UmBHO também tem a funcionalidade de modificar essa navegação, podendo

redirecionar o usuário para qualquer endereço desejado. Assim,spywarespodem veri-

ficar o que o usuário está acessando e de tempos em tempos redirecioná-lo para algum

site, ou mesmo abrir janelaspop-upcom propagandas.

No contexto de proteção, a tecnologia de BHO pode ser utilizada pelo módulo de

segurança para verificar qual endereço o usuário está acessando. Como esse módulo

de segurança pertence a uma instituição específica, ele deverá proteger somente as

páginas dessa instituição. Assim, utilizando essa tecnologia, o modulo de segurança

pode verificar aURLacessada e a partir dela decidir se deve ou não realizar a proteção

dessa página específica.

A tecnologia deBHO é interessante também por outro motivo: o sistema ope-

racional carrega umBHO assim que o navegadorweb for aberto. Assim, o módulo

de segurança estará em uso desde cedo, dificultando assim a sua remoção (conforme

explicado na seção5.2.2).

Além disso, a tecnologia deBHO permite também que aplicativos tenham com-

pleto acesso ao conteúdo das páginas navegadas. UmBHO pode, por exemplo, ve-

rificar todo o código fonte de uma página acessada. Isso pode ser especialmente útil

quando estamos lidando comsitesfalsos (acessados possivelmente através delinks fal-

sos). O módulo de proteção poderia possuir umBHOque verifica o código de todas as

páginas sendo acessadas. Se oBHO percebe que a página atual é muito semelhante à

da instituição protegida, mas o endereço navegado pelo usuário não é o da instituição,

existe grande chance desse usuário estar acessando uma página falsa.

Em termos de privacidade, as vantagens da tecnologia deBHO tornam-se suas

piores desvantagens. UmBHOpode monitorar completamente a navegação do usuário,


inclusive gravando códigos-fonte das páginas acessadas. Isso torna oBHO um espião

perfeito, que possivelmente poderia ser utilizado para criar um histórico de navegação

do usuário.

5.3.6 Proteção contra redirecionamento

Conforme apresentado na seção4.4.4, os ataques de redirecionamento têm como

objetivo modificar o sistema de resolução de nomes para que o cliente acesse umsite

falso da forma mais transparente possível. Esses ataques sebaseiam no comprome-

timento do servidor de resolução de nome (DNS) do usuário ou na modificação dos

próprios arquivos de configuração do sistema operacional.

Utilizando a técnica deBHO explicada na seção5.3.5, o módulo de segurança

pode realizar a proteção contra o ataque de redirecionamento da seguinte forma:

1. O módulo de segurança se instala como umBHO, e passa a monitorar todas as

URLsnavegadas pelo usuário.

2. Ao perceber que o usuário está acessando uma página protegida (a página ini-

cial da instituição protegida, por exemplo), o módulo de segurança realiza uma

validação doIP para o qual essaURL está sendo resolvida.

3. A partir de uma lista deIPs pré-cadastrados considerados válidos para essa pá-

gina, o módulo de segurança verifica se oIP obtido acima está nessa lista.

4. Caso oIP esteja na lista, ele é considerado válido e o usuário pode continuar

com seu acesso.

5. Caso oIP não seja encontrado na lista, o módulo de segurança toma alguma

providência restritiva.

A providência restritiva tomada pelo módulo de segurança pode variar entre algu-

mas opções, entre elas:


• Redirecionar o usuário para umIP considerado correto.

• Colocar uma entrada no arquivohostsda máquina, obrigando o sistema operaci-

onal a sempre direcionar uma certaURL para umIP fixo.

Cada uma das soluções mencionadas têm suas vantagens e desvantagens. A idéia

de redirecionar o usuário para umIP correto é extremamente transparente para o usuá-

rio e não implica em nenhuma modificação no seu padrão normal de navegação. Por

outro lado, caso a página acessada seja uma página segura queutilize SSL, redirecionar

o usuário porIP causará a apresentação de um erro quanto ao nome do certificado. Na

criação de um certificadoSSL, é necessário especificar para qualURL esse certificado

será utilizado. Por exemplo, para um banco de teste, o certificado poderia ser emitido

para aURL www.bancoTeste.com.br. Quando o usuário acessa essaURL, o navegador

verifica se o nome digitado bate com o nome do certificado digital. Caso esses no-

mes sejam diferentes, uma mensagem de aviso é mostrada pedindo a confirmação do

acesso. No caso do redirecionamento porIP, esse mesmo erro seria apresentado.

A outra solução apresentada, a da colocação de uma entrada noarquivohostsda

máquina do usuário, também é extremamente transparente e mantém o padrão normal

de navegação do usuário. A desvantagem aqui é que aquela entrada colocada no ar-

quivo ficará lá até que o módulo de segurança a remova. Caso o módulo de segurança

seja desinstalado ou pare de funcionar corretamente, é possível que aquela entrada seja

esquecida e deixada no arquivo. Com o tempo, caso a instituição mude oIP de seu

site, esse cliente específico não conseguirá mais acessar as páginas dessa instituição.

Além disso, existem hoje programas que verificam e protegem oarquivohostscon-

tra modificações. Esses programas poderiam afetar diretamente a efetividade dessa

solução.

Existe uma limitação dessa proteção que ocorre quando o usuário utiliza um ser-

vidor proxy. Um servidorproxyé um serviço de rede que permite que clientes façam


conexões de redes indiretas para outros serviços externos.O funcionamento básico de

umproxyé: o cliente conecta no servidorproxypedindo algum serviço de rede especí-

fico (por exemplo, uma páginaweb); o servidor proxy realiza a conexão pedida e então

repassa os dados de resposta para o cliente.

Em um ambiente utilizando um servidorproxy, a resolução de nomes para acessos

a páginas web é realizado pelo próprioproxy. Ou seja, quando um cliente solicita

ao proxy a páginawww.bancoTeste.com.br, é o próprioproxy que obtém oIP dessa

URLe que realiza a conexão. Portanto, um módulo de segurança instalado localmente

na máquina do usuário não consegue saber para qualIP o proxy resolverá o nome,

impedindo assim a proteção local. Nesses casos, a proteção deveria ser colocada no

próprio servidorproxy, o que normalmente não é uma solução prática.

Em relação à privacidade, as técnicas de proteção contra redirecionamento são

muito semelhantes às da tecnologia deBHO, na qual o módulo de segurança pode

teoricamente analisar todas asURLsnavegadas pelo usuário.

5.3.7 Detecção de janelas suspeitas

Na seção4.4.3, mostramos que um dos ataques mais utilizados hoje é o de telas

falsas. Nesse ataque, umtrojan apresenta uma tela semelhante à tela original da insti-

tuição atacada, pedindo os dados críticos do usuário, normalmente durante o acesso ao

siteoficial da instituição.

Uma das formas de realizar a proteção contra esse tipo de ataque é a utilização

de umantitrojan, conforme explicado na seção5.3.1. Nesse caso, o sistema dean-

titrojan detectaria otrojan e finalizaria sua execução antes mesmo de a tela falsa ser

apresentada.

O problema da proteção deantitrojan é o processo contínuo de atualização das

assinaturas. Além disso, a chance de quetrojansnovos (não conhecidos) sejam detec-


tados é relativamente pequena. Portanto, algumas vezes se vê necessária a aplicação

de uma proteção extra, que funcione baseada em análise de comportamento em vez de

assinaturas detrojans.

Para tanto, será necessário analisar qual o comportamento-padrão de uma tela falsa

aberta por uma família detrojans. Como exemplo, umtrojan simples que utilize telas

falsas normalmente executa os seguintes passos:

1. Verifica que o usuário está acessando uma página específica dainstituição a ser

atacada

2. Abre uma janela na frente de todas as outras

3. A janela aberta se assemelha muito à da instituição transacional

O módulo de segurança poderia ser configurado para tentar detectar esse compor-

tamento específico e fechar as janelas que forem detectadas por esse método. Nesse

exemplo, o módulo de segurança ficaria monitorando o acesso àinstituição protegida.

Quando esse acesso ocorrer, o módulo verificaria qual janelaestá atualmente com foco.

Se essa janela não for a do navegador, o módulo realizaria umaanálise nessa janela

(agora considerada suspeita) afim de verificar se ela se assemelha ou não à janela ofi-

cial da instituição. Se isso for verdade, essa janela pode ser considerada uma tela falsa

e será então fechada.

Apesar da simples explicação, o método apresentado não é de simples execução.

O problema mais grave que surge durante o processo de desenvolvimento é o seguinte:

como verificar que a janela suspeita se assemelha à janela da instituição?

Pode-se, por exemplo, analisar as palavras que a janela contém e verificar se elas

se encontram em uma lista pré-definida de palavras-chave. O problema aqui é que

algunstrojanspodem utilizar imagens ao invés de texto. Outro problema é que janelas


não falsas podem ser facilmente detectadas como janelas suspeitas, resultado em casos

de falsos positivos.

É também possível realizar uma análise da estrutura da janela, no sentido de ve-

rificar se os campos que a janela da instituição contém tambémestão na janela que

está sendo analisada. Imaginemos novamente o exemplo da tela original do banco

apresentada na Figura5.4e da tela falsa apresentada na Figura5.5.

Figura 5.4: Página oficial da instituição.

Podem-se notar diversas semelhanças entre a página original e a tela falsa. Al-

gumas semelhanças seriam: as duas telas possuem três caixasde texto; as três caixas

de texto estão alinhadas verticalmente; as duas telas possuem dois campos de entrada

de senha; a imagem do cadeado está sempre alinhada à esquerda. E assim por diante.

Verificando esse tipo de semelhanças entre as duas janelas, podemos tentar identificar

as telas falsas e assim proteger o usuário.

Novamente, deve-se tomar cuidado com o balanceamento entreproteção e faci-

lidade de uso. Se a verificação da estrutura da janela suspeita for muito simples, a

proteção será muito eficiente, mas o número de falsos positivos pode ser grande. No

outro extremo, se a validação da estrutura da janela suspeita for muito complexa, o


Figura 5.5: Tela falsa atacando ositeoficial da instituição.

número de falsos positivos deve ser baixo, mas a efetividadeda proteção também terá

um declínio considerável.

Em termos de privacidade, utilizando essa técnica de verificação de estrutura das

janelas, o módulo de segurança poderia teoricamente verificar todos os aplicativos que

o usuário acessa e armazenar os textos e imagens contidas em cada um deles. Isso

pode ser considerado muito intrusivo pelo usuário final, sendo necessário cuidado ao

realizar a implementação dessa técnica.

5.3.8 Proteção da máquina virtualJava

O ataque descrito na seção4.4.5utiliza a estrutura da máquina virtualJavapara

capturar dados secretos de usuários. No ataque apresentado, as bibliotecas derun-time

do próprioJava eram substituídas, permitindo assim um controle total dosapplets

sendo executados.

O ponto de vulnerabilidade explorado nesse ataque é a falta de validação de inte-

gridade das bibliotecas derun-time. A proteção contra esse ataque então deve basear-se


neste fato: é necessário criar uma maneira pela qual um programa consiga verificar se

a máquina virtualJavaestá íntegra.

Fica claro que nenhum programaJavatem a capacidade de verificar a integridade

da máquina virtual. Como todos os programasJavadependem da própria máquina

virtual para executar qualquer função, o atacante pode adulterar essas funções de veri-

ficação e assim enganar o programa.

Uma idéia que pode à primeira vista parecer simples e atrativa é a criação de um

programa externo, escrito em linguagem nativa da máquina (ou seja, não escrito em

Java), que verificaria a integridade da máquina virtual. Porém, essa solução tem várias

desvantagens: escrevendo um programa em linguagem nativa da máquina, estaremos

perdendo a portabilidade doJava; existem muitas máquinas virtuais no mercado, e

cada uma delas tem diferentes versões e diferentes atualizações, ficando, assim, quase

inviável manter uma lista atualizada de todas essas máquinas.

O trabalho de validação da integridade das bibliotecas derun-time da máquina

virtual Javadeveria ser passado para os próprios executáveis da máquinavirtual. Isso

não bloquearia totalmente o ataque, pois os próprios executáveis da máquina virtual

poderiam ser trocados. Mas como os executáveis são escritosem código nativo da

máquina e têm um tamanho considerável, o ataque se tornaria bem mais complexo.

Portanto, uma solução imediata para minimizar o impacto desse ataque seria passar a

responsabilidade de validação diretamente para a máquina virtual.

Do ponto de vista de uma instituição que opera um sistema transacional, a solu-

ção acima não é facilmente aplicável, pois a máquina virtualJavapertence a empresas

terceiras, não havendo assim a possibilidade de modificar seu código. Pensando que

a instituição só possui um módulo de segurança externo à máquina virtual, hoje ainda

não há muito o que fazer. Provavelmente, o mais recomendado seria não utilizarap-

pletsde autenticação, pelo menos até que as máquinas virtuais passem a verificar a

integridade de suas bibliotecas.

5.4 Sugestão de uma solução de curto prazo 88

5.4 Sugestão de uma solução de curto prazo

Juntando as proteções e recomendações apresentadas anteriormente neste capítulo,

podemos agora montar uma solução completa para proteger os clientes de instituições

que operam sistemas transacionais da maioria dos ataques aqui apresentados.

Os ataques aqui apresentados foram:

1. Sitesfalsos

2. Exploração de vulnerabilidades

3. Keyloggers

4. Telas falsas

5. Ataque de redirecionamento

6. Ataque à máquina virtualJava

O único ataque para o qual uma solução direta de curto prazo não foi apresentada

é o ataque à máquina virtualJava.

Levando em conta as defesas apresentadas neste capítulo, a melhor estratégia para

proteção contra cada um desses ataques está apresentada na Tabela5.1.

Ataque Melhor DefesaSitesfalsos BHOExploração de vulnerabilidades Atualizações de segurançaKeyloggers DriverTelas falsas Antitrojan+ Detecção de janelas suspeitasAtaque de redirecionamento BHOAtaque à máquina virtualJava —

Tabela 5.1: Ataques propostos e melhores defesas.


Os motivos para a seleção das proteções expostas já foram indiretamente apre-

sentados durante as discussões deste capítulo, mas iremos colocá-los aqui novamente,

agora de maneira mais objetiva e resumida.

A proteção contrasitesfalsos é complicada e exige a análise de cada página que

esteja sendo acessada pelo usuário. Para realizar essa tarefa, a tecnologia deBHOapre-

sentada pelo sistema operacional é a mais recomendada. UmBHO possui interfaces-

padrão para acessar o conteúdo da página, e também para redirecionar o usuário para

o sitecorreto caso ocorra algum problema.

A exploração de vulnerabilidades para instalação local desoftwaremalicioso tam-

bém é um problema sério. Um módulo externo de segurança até poderia tentar suprir

as deficiências do sistema operacional e se comprometer a proteger essas falhas conhe-

cidas. Mesmo assim, a maneira mais limpa e efetiva de fechar as vulnerabilidades do

sistema é a instalação das atualizações de segurança do próprio fabricante do sistema

operacional. Nesse caso, o módulo de segurança se limitará talvez a avisar o usuário

de que existem atualizações novas ou mesmo baixar e instalaressas atualizações de

tempos em tempos.

O ataque utilizandokeyloggerspode ser extremamente efetivo na captura dos da-

dos críticos dos usuários. A técnica mais efetiva e completapara proteção contra esse

ataque é a utilização dedrivers. A implementação e integração dodriver com as outras

aplicações não é simples, portanto essa técnica exige grandes cuidados no desenvolvi-

mento e nos testes. Mesmo assim, o resultado final de umdriver bem maduro será o

bloqueio da grande maioria doskeyloggers.

Já o ataque de telas falsas, o mais empregado atualmente, pode ser reprimido com

maior eficiência utilizando-se uma combinação de defesas. Aprimeira parte da defesa

seria umantitrojan que conheça as janelas suspeitas já encontradas e analisadas. Essa

parte ficaria responsável pela proteção da maioria das telasfalsas. Somente algumas

telas novas desconhecidas passariam essa barreira. Para essas novas telas falsas, a pro-


teção de detecção de janelas suspeitas baseada na análise comportamental e estrutural

da janela seria uma segunda linha de defesa. Para evitar o problema de falsos positivos,

essa proteção poderia ser bem restritiva quanto à arquitetura da janela suspeita, já que

essa proteção será utilizada somente nos raros casos em que ajanela não for conhecida.

O ataque de redirecionamento explicado neste capítulo podeser melhor comba-

tido utilizando-se novamente a tecnologia deBHO. A proteção se basearia numa lista

pré-cadastrada deIPs válidos para um certosite. Caso oBHO detecte que o usuá-

rio está sendo direcionado para umIP não cadastrado na lista, sua navegação seria

redirecionada para um dosIPsválidos.

Por fim, o ataque à máquina virtualJava. Como explicado anteriormente, a melhor

proteção contra esse tipo de ataque exige que os próprios desenvolvedores de máqui-

nas virtuais realizem uma validação internamente em seus sistemas. Como isso está

fora do poder da instituição, a melhor solução por enquanto seria não utilizarappletsde

autenticação para a entrada de dados críticos dos usuários.De qualquer maneira, as so-

luções apresentadas para os outros ataques acabam minimizando um pouco o problema

da máquina virtual. A utilização de umantitrojan, por exemplo, acaba dificultando a

instalação de aplicativos maliciosos que possam tentar modificar a máquinaJava.

Ao final, juntando todas essas proteções citadas, teremos ummódulo de segurança

bastante eficaz. Mesmo assim, não podemos afirmar que o sistema estará totalmente

protegido. Algumas dessas técnicas de proteção tem seus problemas, suas falhas e

suas vulnerabilidades. Conforme descrito neste capítulo, nenhuma dessas soluções é

perfeita: sempre há alguma brecha que pode ainda ser explorada por atacantes.

É ilusão pensar que a implantação de um módulo de segurança com todas as carac-

terísticas citadas nesse trabalho irá resolver o problema das fraudes. Contra os ataques

hoje mais difundidos, a solução provavelmente será eficiente. Mas, desde que uma

solução seja implantada, a evolução e adaptação dos atacantes ao novo ambiente será

rápida: ataques mais modernos e eficientes serão criados em pouco tempo.

5.5 A questão da privacidade 91

Portanto, qualquer solução proposta deve estar associada aum processo contínuo

de acompanhamento, investigação e melhorias. Somente operando um processo dessa

natureza podemos atenuar significantemente o problema das fraudes em sistemas tran-

sacionais.

5.5 A questão da privacidade

Explicamos durante este capítulo os diversos problemas de privacidade que podem

vir a ocorrer com as várias técnicas de defesa utilizadas. A privacidade do usuário é

seu direito e portanto deve ser respeitada. Contudo, no cenário apresentado, no qual

clientes estão utilizando serviços de uma instituição transacional conhecida e confiável,

a privacidade toma outra face.

Permitir a instalação de qualquer programa localmente em sua máquina é sempre

uma decisão difícil para qualquer usuário. Como garantir queo softwareinstalado

realize somente aquilo que ele se propõe a fazer?

No cenário de instituições transacionais, já existe uma confiança inerente entre o

cliente e a instituição. Esse cliente já utiliza vários serviços dessa instituição para os

quais um certo nível de confiança mútua é necessário. Normalmente a instituição já

possui vários dados sigilosos desse cliente. O próprio patrimônio financeiro do cliente

muitas vezes está nas mãos da instituição. Por esse motivo, ocliente normalmente não

se preocupará muito com a instalação em sua máquina de umsoftwareque possivel-

mente possa violar sua privacidade, pois ele já confia na instituição e já depende dela

para realizar inúmeros serviços.

De qualquer maneira, é interessante seguir algumas boas práticas no desenvolvi-

mento do módulo de segurança a ser instalado. Com isso, o cliente pode aferir, com

uma confiança razoável, que osoftwareinstalado localmente não está violando sua

privacidade. Abaixo seguem algumas dessas boas práticas que deveriam ser seguidas


para manter a menor intrusão possível na máquina do cliente.

• O módulo de segurança só deve estar ativo durante o acesso às páginas da insti-

tuição: quando o cliente acessa explicitamente, por livre eespontânea vontade,

as páginas da instituição, só então a proteção deve ser ligada. É somente nesse

momento que o módulo poderá verificar a existência detrojans ou programas

maliciosos em geral. Por um lado, isso acaba afetando um pouco a segurança do

sistema, pois seria mais eficiente se o módulo de segurança pudesse estar ativo

desde a inicialização da máquina. Mesmo assim, a perda de segurança envol-

vida é pequena quando comparada à grande vantagem que se tem em termos de

privacidade: o usuário não poderá afirmar que o módulo está capturando suas in-

formações de outras instituições ou que está afetando o desempenho da máquina

fora do acesso à instituição protegida. Toda a atividade do módulo fica limitada

ao tempo em que o cliente está dentro da instituição. E como o foi o próprio

usuário que, por livre arbítrio, digitou no navegador o endereço protegido, fica

também sobre ele o comando da ativação e desativação da proteção.

• O módulo de segurança deve se comunicar apenas com o servidorda instituição

protegida: para evitar problemas de acusações de envio de informações para

destinatários ilícitos, o módulo de segurança deve enviar ereceber informações

apenas do própriositeda instituição protegida.

• O módulo de segurança deve trocar o mínimo de informação possível com o

servidor da instituição: os dados trocados entre os dois lados devem se limi-

tar à baixa de atualizações do módulo e ao envio de incidentesidentificados na

máquina do cliente. Sendo assim, os dados trafegados devem ser bem escas-

sos. Dessa maneira, um cliente poderá verificar que o módulo não está enviando

informações que violem sua privacidade, pois a banda utilizada pelo mesmo é

muito pequena para realizar tal tarefa.


• O módulo de segurança deve possuir um modo simples de desinstalação: um

cliente sempre deve ter o direito de escolher se quer ou não instalar umsoftware

localmente em sua máquina. Caso o cliente decida que quer desinstalar o módulo

de segurança, deve haver uma maneira simples e prática de realizar essa tarefa.

Obviamente, esse método de desinstalação deve ser bem estruturado para que

trojansnão possam usa-lo como um ponto de vulnerabilidade do sistema.

Seguindo essas premissas de funcionamento, a instituição terá mais força no mo-

mento de afirmar que seu módulo de segurança não viola a privacidade de seus clientes.

Assim é possível obter um compromisso razoável entre segurança e privacidade.

94

6 CONSIDERAÇÕES SOBRE SOLUÇÕESESTRUTURAIS

“The human factor is truly security’s weakest link”

Kevin Mitnick

Durante o decorrer deste trabalho, foram explicadas técnicas de ataque e defesa

que visam impedir as fraudes virtuais. Todo essa batalha se deve a um único fator:

a falta de confiança na máquina do cliente. É por esse simples motivo que o módulo

de segurança criado no capítulo5 é necessário. É explorando quase que unicamente

esse fator que os atacantes conseguem realizar os ataques apresentados no capítulo4.

Ou seja, tudo o que foi apresentado aqui gira em torno do ambiente promíscuo e não

confiável que é a máquina do cliente.

Portanto, para que se consiga acabar (ou ao menos diminuir consideravelmente)

com as fraudes virtuais, é necessário lutar contra esse fator importante. Em termos

bem genéricos, existem duas maneiras de se lidar com o problema da não confiança na

máquina do cliente:

1. Realizar o acesso aoInternet Banking(ou ao menos o processo de autenticação)

a partir de outro ambiente confiável.

2. Tornar de alguma maneira a máquina do cliente novamente confiável.

A primeira solução parece ser a mais diretamente acessível,pois podemos utilizar


artifícios tecnológicos para realizá-la. Alguns exemplosinteressantes de ambientes

confiáveis seriam:

• Utilizar dispositivos externos dedicados, sem comunicação com o exterior, para

realizar o processo de autenticação e de assinatura digitalde cada transação efe-

tuada.

• Utilizar um sistema operacional secundário, também dedicado, para acessar o

serviço deInternet Banking(exemplo: utilizar um disco deboottotalmente auto-

suficiente, não alterável, que somente permite que o usuárioutilize o serviço

provido pela instituição).

• Utilizar um sistema de máquinas virtuais totalmente segregado, em que a má-

quina virtual utilizada para acesso aoInternet Bankingesteja isolada e possa

realizar somente essa tarefa.

Esses são alguns exemplos práticos de como se poderia utilizar ambientes confiá-

veis para a redução das fraudes. Note que nenhum desses métodos é prático do ponto

de vista do cliente; há sempre um processo custoso a ser realizado pelo cliente antes

do seu acesso ao serviço. Além disso, alguns desses exemploscitados têm problemas

de logística e custo, pois não é simples nem barato distribuir dispositivos dedicados ou

discos debootpara milhares ou mesmo milhões de clientes. De qualquer maneira, em

termos de segurança, os exemplos acima mantêm sua efetividade independentemente

do estado da máquina do cliente.

A outra alternativa para lidar com o problema das fraudes seria tornar a máquina

do cliente novamente confiável. Nesse ponto, encontramos umproblema de educação

a ser tratado. As máquinas dos clientes hoje estão infectadas pela falta de informação

e ingenuidade das pessoas. Seria então necessário um grandeprocesso de educação e

conscientização dos usuário de serviços deInternet Bankingpara que esses passem a


se preocupar mais com sua própria segurança. Esses usuáriosdeveriam ter conceitos

sobre navegação segura, sobre certificação digital, sobre utilização de aplicativos de

segurança, entre outros. Como muitos dos usuários desses serviços são leigos em

informática, a tarefa de educá-los em segurança não é simples. Apesar disso, esse

parece ser um mal necessário, pois a segurança sempre, em algum ponto, dependerá

da pessoa que está utilizando o sistema, por mais seguro que ele seja.

Parece que uma das alternativas mais eficazes para promover adefesa contra todos

esses ataques seja a criação nativa (direto de fábrica) na máquina do cliente de múlti-

plas máquinas virtuais, sendo que uma delas seria destinadapara execução e navegação

de aplicações sensíveis que exigem alta segurança.

O ambiente normal de uso da máquina do cliente seria totalmente dissociado e

completamente isolado desse ambiente de segurança. A própria implementação do

monitor de máquinas virtuais seria simplificada para que eletivesse pouquíssimo có-

digo, muito menor que os 50 milhões de linhas de código doWindowspara minimizar

a probabilidade de existência de vulnerabilidades.

Infelizmente, a aplicabilidade desse tipo de solução depende dos fornecedores

de máquinas e sistemas operacionais. Aparentemente, certos indícios (MICROSOFT,

2005b) indicam que eles estão trabalhando nessa direção. Se uma solução desse tipo

não for logo disponibilizada, a utilização de computadorespessoais para a execução

de transações sensíveis ficará bastante limitada.

Enquanto isso não ocorre, a solução apresentada neste trabalho, complementada

por um processo contínuo de melhorias, é uma das alternativas viabilizadoras do uso de

computadores pessoais de baixo custo executando transações sensíveis com um nível

de segurança adequado.

97

7 CONCLUSÕES

“. . . what is proved by impossibility proofs is lack of imagination.”

John Bell

Apresentamos neste trabalho uma perspectiva da situação atual das fraudes virtuais

contra instituições que operam sistemas transacionais no Brasil. Foi mostrado que o

problema das fraudes já é muito sério e ainda tende a crescer.Foram apresentados os

ataques mais utilizados hoje para realizar essas fraudes, epara cada um desses ataques

foi explicada uma possível forma de proteção. Demonstrou-se também que, com um

conjunto dessas defesas, pode-se criar um sistema eficientede combate às fraudes.

Mesmo assim, uma solução definitiva para as fraudes requer ainda um trabalho mais

árduo, envolvendo ação que deve ser executada preferencialmente pelos fornecedores

(fabricantes) de máquinas e sistemas operacionais.

A solução de curto prazo aqui apresentada contra as fraudes obviamente não provê

100% de eficácia. Após a leitura deste trabalho, deve ficar claro que não existe uma

solução puramente tecnológica que resolverá esse problema. É necessário aplicar, em

conjunto com a tecnologia, um processo de educação e criaçãode um cultura de segu-

rança nos usuários dos serviços atacados.

A técnica conhecida como “engenharia social” pode quase sempre sobrepassar o

mais seguro dos sistemas. A ignorância e inocência das pessoas continuarão a ser os

grandes pontos de vulnerabilidade de qualquer sistema.

6 Conclusões 98

As técnicas aqui descritas podem ajudar, e muito, uma instituição transacional na

batalha contra as fraudes. Mas a solução definitiva só virá com a conscientização e o

compartilhamento da responsabilidade da segurança do sistema com seus usuários.

99

REFERÊNCIAS

AARONSON, L. For love of money - malicious hacking takes an ominous turn.Spectrum, IEEE, v. 42, p. 17 – 19, Nov. 2005.

AWAD, K. F. N. F. The deceptive behaviors that offend us most about spyware.Communications of the ACM, v. 48, p. 55 – 60, Aug. 2005.

BERTIN, M. The new security threats.Ziff Davis Smart Business, Feb. 2001.

BRUSTOLONI, X.; BRUSTOLONI, J. C. Hardening web browsers against man-in-the-middle and eavesdropping attacks.International World Wide Web Conference, p.489 – 498, 2005.

CASS, S. Anatomy of malice [computer viruses].Spectrum, IEEE, v. 38, p. 56 – 60,Nov. 2001.

CERT. CERT/CC Statistics 1988-2005. 2005. Hipertexto. Disponível em:http://www.cert.org/ . Acesso em: 16 de maio de 2006.

COHEN, F. 50 ways to attack your web systems.Internet Holes, Jan. 1995.

DEAN E. W. FELTEN, D. S. W. D.; BALFANZ, D. Java security: Web browsers andbeyond.Internet Beseiged: Countering Cyberspace Scofflaws, October 1997.

DESCRIPTION, A. R. M.Anti-Spyware Coalition Risk Model Description. 2005.Hipertexto. Disponível em:http://www.antispywarecoalition.org/documents/RiskModelDescription.htm . Acesso em: 16 de maio de 2006.

DHAMIJA, L. D. T. R. The battle against phisihng: Dynamic security skins.Proceedings of the 2005 ACM Symposium on Usable privacy and security, p. 77 – 88,July 2005.

FOLHA. Folha Online. 2005. Hipertexto. Disponível em:http://www.folha.uol.com.br/ . Acesso em: 16 de maio de 2006.

FREEDMAN, D. H.How To Hack A Bank. 2000. Hipertexto. Disponível em:http://www.forbes.com/asap/2000/0403/056.html . Acesso em: 16de maio de 2006.

FREEMAN, A. U. L. A. Why do people hate spyware?Communications of the ACM,v. 48, p. 50 – 53, Aug. 2005.

GIBSON, S. Spyware was inevitable.Communications of the ACM, v. 48, p. 37– 39,Aug. 2005.

Referências 100

GOLDBERG D. WAGNER, R. T. I.; BREWER, E. A. A secure environment foruntrusted helper applications: Confining the wily hacker.Proceedings of the 6thUsenix Security Symposium, 1996.

HOWARD, J. D.An Analysis of Security Incidents on the Internet. Tese (Doutorado)— Pittsburgh, Pennsylvania, 1997.

HU, T. D. Q. Is spyware an internet nuisance or public menace?Communications ofthe ACM, v. 48, p. 61 – 66, Aug. 2005.

HUBERMAN B.A. ADAR, E. F. L. Valuating privacy.Security & Privacy Magazine,IEEE, v. 3, p. 22– 25, Sept.-Oct. 2005.

HYDE, R.The Art of Assembly Language Programming. 1. ed. [S.l.]: No Starch Press,2003.http://courses.ece.uiuc.edu/ece390/books/artofasm/artofasm.html .

IDGNOW. International Data Group (Brasil). 2005. Hipertexto. Disponível em:http://www.idgnow.com.br/ . Acesso em: 16 de maio de 2006.

KOSKOSAS, I. V.; PAUL, R. J. The interrelationship and effectof culture and riskcommunication in setting internet banking security goals.Proceedings of the 6thinternational conference on Electronic commerce, v. 60, p. 341 – 350, 2004.

LABS, K. Trojan programs exploiting the latest Windows vulnerability. 2005.Hipertexto. Disponível em:http://www.kaspersky.com/news?id=176708581 . Acesso em: 16 de maio de 2006.

LANDWEHR ALAN R. BULL, J. P. M. C. E.; CHOI, W. S. A taxonomy of computerprogram security flaws.ACM Computing Surveys (CSUR), v. 26, n. 3, p. 211 – 254,1994.

LEE, K. A. K. Y. Investigating factors affecting the adoption of anti-spyware systems.Communications of the ACM, v. 48, p. 72 – 77, Aug. 2005.

LOBL, T. R. Student papers: Identity theft, spyware and the law. Proceeding of the2nd annual conference on Information security curriculum deevlopment InfoSecCD’05, Sep. 2005.

MADSEN YUZO KOGA, K. T. P. Dim framework: Federated identitymanagementfor protecting users from id theft.Proceeding of the 2005 workshop on Digital identitymanagement, Nov. 2005.

MATAYOSHI, C. M. Modelo de segurança da linguagem java.SBRC, 1998.

MCGRAW, G.; FELTEN, E.Securing Java. [S.l.]: John Wiley & Sons, Inc., 1999.http://www.securingjava.com/ .

MICROSOFT.Microsoft Security Bulletin MS06-001. 2005. Hipertexto. Disponívelem: http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx . Acesso em: 16 de maio de 2006.

Referências 101

. Next-Generation Secure Computing Base. 2005. Hipertexto. Disponível em:http://www.microsoft.com/resources/ngscb/default.mspx .Acesso em: 16 de maio de 2006.

MITTELSDORF, A. W.Uma plataforma para computação com confiança baseadaem monitor de máquinas virtuais e atestamento dinâmico. Tese (Doutorado) — EscolaPolitécnica da Universidade de São Paulo, São Paulo, 2004.

MOORE VERN PAXSON, S. S. C. S. S. S. D.; WEAVER, N.The Spread of theSapphire/Slammer Worm. 2003. Hipertexto. Disponível em:http://www.caida.org/outreach/papers/2003/sapphire/sapphire.html . Acesso em:16 de maio de 2006.

MSDN. Microsoft Corporation - Hooks. 2005. Hipertexto. Disponível em:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks.asp .Acesso em: 16 de maio de 2006.

NILSSON ANNE ADAMS, S. H. M. Building security and trust in online banking.Conference on Human Factors in Computing Systems, p. 1701 – 1704, 2005.

POSTON THOMAS F. STAFFORD, A. H. R. Spyware: a view from the (online)street.Communications of the ACM, v. 48, Aug. 2005.

PUENTE F. GONZALEZ, S. S. J. de la. Virus attack to the pc bank.SecurityTechnology, 1999. Proceedings., p. 304 – 310, Oct. 1999.

PUENTE J.D. SANDOVAL, P. H. F. de la. Personal digital signerfor internet banking.Communications, Computers and signal Processing, 2003. PACRIM, v. 2, p. 700 –703, Aug. 2003.

PUENTE JUAN D. SANDOVAL, P. H. F. D. L. Pocket device for authenticationand data integrity on internet banking applications.Security Technology, 2003.Proceedings, p. 43 – 50, Oct. 2003.

PUENTE SANTIAGO GONZALEZ, J. D. S. Fernando de la; HERNANDEZ,P. Viralattack to internet banking applications.Aerospace and Electronic Systems Magazine,IEEE, v. 15, p. 3 – 8, 2000.

SCHMIDT, K. P. A. M. B. Spyware: a little knowledge is a wonderful thing.Communications of the ACM, v. 48, p. 67 – 70, Aug. 2005.

SEGEV, J. P. A.; ROLDAN, M. Internet security and the case of bank of america.Communications of the ACM, v. 41, n. 10, p. 81 – 87, October 1998.

SLEWE, T.; HOOGENBOOM, M. Who will rob you on the digital highway?Communications of the ACM, v. 47, n. 5, p. 56 – 60, May 2004.

SMARTLINK. Virtual Keabord Example. 2005. Hipertexto. Disponível em:http://www.smartlinkcorp.com/ . Acesso em: 16 de maio de 2006.

Referências 102

SMITH, S. Pretending that systems are secure.Security & Privacy Magazine, IEEE,v. 3, p. 73 – 76, Nov.-Dec. 2005.

SNADBOY. SnadBoy’s Revelation. 2000. Hipertexto. Disponível em:http://www.snadboy.com/ . Acesso em: 16 de maio de 2006.

STYTZ, M. Protecting personal privacy: Hauling down the jolly roger.Security &Privacy Magazine, IEEE, v. 3, p. 72– 74, July-Aug. 2005.

THOMPSON, R. Why spyware poses multiple threads to security.Communicationsof the ACM, v. 48, p. 41 – 43, Aug. 2005.

TIMES eCommerce.Identity Theft Is Fastest-Growing Online Crime. 2003.Hipertexto. Disponível em:http://www.epaynews.com/index.cgi?survey=&keywords=ID%20theft&optional=&subject=&location=&ref=keyword&f=view&id=1056453397622215212&block=1 . Acessoem: 16 de maio de 2006.

VENNERS, B. Java’s security architecture - an overview of the jvm’s security modeland a look at its built-in safety features.Java World, August 1996.

. Security and the class loader architecture - a look at the role played by classloader in the jvm’s overall security model.Java World, September 1997.

. Security and the class verifier - a look at the role played by class verifier in thejvm’s overall security model.Java World, October 1997.

VLIET, H. van. Mocha, the Java Decompiler. 1996. Hipertexto. Disponível em:http://www.brouhaha.com/~eric/software/mocha/ .Acesso em: 16 demaio de 2006.

WARKENTIN XIN LUO, G. F. T. M. A framework for spyware assessment.Communications of the ACM, v. 48, p. 79 – 84, Aug. 2005.

WENUIN GUANGLIN HUANG, L. X. Z. M. X. D. L. Detection of phishingwebpages based on visual similarity.Special interest tracks and posters of the 14thinternational conference on World Wide Web, May 2005.

WHEELER, A. C. D.; LUO, A. X. J. Java security extensions for a java server ina hostile environment.17th Annual Computer Security Applications Conference(ACSAC’01), December 2001.

ZHANG, X. What do consumers really know about spyware?Communications of theACM, v. 48, p. 44 – 48, Aug. 2005.

103

Apêndice A -- EXEMPLO DE E-MAILS

Figura A.1: Exemplo dee-mailcontendotrojan.

Apêndice A -- Exemplo de e-mails 104


107

GLOSSÁRIO

•Engenharia Social: prática para obtenção de informações confidenciais através

da manipulação de usuários legítimos. O atacante normalmente utilizará um

telefone ou aInternetpara enganar as pessoas e fazer com que essas revelem

informações sensíveis ou realizem alguma ação que vai contra sua política de

segurança. Em vez de explorar falhas de segurança do sistema, esse método

explora a tendência natural das pessoas de confiar na palavraalheia.

•Malware: programa com o objetivo de infiltrar ou danificar um computador, sem

o consentimento de seu dono. Inclui as classestrojans, worms, spywarese vírus.

•Spyware: ampla categoria de programas maliciosos criados para interceptar ou

tomar controle parcial das operações de um computador sem o consenso do usuá-

rio legítimo. Táticas comuns utilizadas porspywaressão: mostrar janelas de

propaganda não solicitadas; roubo de informação pessoal (como números de car-

tão de crédito); monitoração das atividades de navegação naInternetpara fins de

marketing; redirecionamento de requisiçõeswebpara páginas com propagandas.

•Trojan: programa malicioso que se apresenta disfarçado como um programa

legítimo. Trojans não possuem a habilidade de se replicar automaticamente,

normalmente dr utilizando da curiosidade ou inocência da vítima para serem

executados.

•Vírus: programas que se replicam automaticamente e se espalham através da

inserção de cópias de si mesmo dentro de outros executáveis ou documentos.

•Worm: programa que se replica automaticamente, similarmente a um vírus. En-

Glossário 108

quanto um vírus deve se anexar a (ou se tornar parte de) um outro executável, os

wormssão totalmente autocontidos e não necessitam de outros programas para

se propagar.

biblioteca digital de teses e dissertações da usp - seguranÇa … · 2006. 9. 13. · • de...

Documents