Você está na página 1de 77

Universidade de Braslia

Instituto de Cincias Exatas


Departamento de Cincia da Computao

Webspy: uma aplicao de monitoramento Web em


tempo real

Andr Figueira Loureno

Monograa apresentada como requisito parcial


para concluso do Bacharelado em Cincia da Computao

Orientador
Prof. MSc. Joo Jos Costa Gondim

Braslia
2013

Universidade de Braslia  UnB


Instituto de Cincias Exatas
Departamento de Cincia da Computao
Bacharelado em Cincia da Computao

Coordenador: Prof. Dr. Dbio Leandro Borges

Banca examinadora composta por:


Prof. MSc. Joo Jos Costa Gondim (Orientador)  CIC/UnB
Prof. Dr. Diego de Freitas Aranha  CIC/UnB
Prof. Dr. Robson Albuquerque  ENE/UnB

CIP  Catalogao Internacional na Publicao


Loureno, Andr Figueira.

Webspy: uma aplicao de monitoramento Web em tempo real / Andr


Figueira Loureno. Braslia : UnB, 2013.
147 p. : il. ; 29,5 cm.

Monograa (Graduao)  Universidade de Braslia, Braslia, 2013.

1. monitoramento
4. SSL

Stripping

Web , 2. ARP Spoong , 3. man-in-the-middle ,

CDU 004.4

Endereo:

Universidade de Braslia
Campus Universitrio Darcy Ribeiro  Asa Norte
CEP 70910-900
BrasliaDF  Brasil

Universidade de Braslia
Instituto de Cincias Exatas
Departamento de Cincia da Computao

Webspy: uma aplicao de monitoramento Web em


tempo real

Andr Figueira Loureno

Monograa apresentada como requisito parcial


para concluso do Bacharelado em Cincia da Computao

Prof. MSc. Joo Jos Costa Gondim (Orientador)


CIC/UnB

Prof. Dr. Diego de Freitas Aranha

Prof. Dr. Robson Albuquerque

CIC/UnB

ENE/UnB

Prof. Dr. Dbio Leandro Borges


Coordenador do Bacharelado em Cincia da Computao

Braslia, 25 de julho de 2013

Agradecimentos
Agradeo a todos parentes e amigos que acreditaram e conaram na minha capacidade
e que compreenderam os esforos necessrios para a concluso deste trabalho.

Resumo
Web permitiu a criao de diversas aplicaes, entre elas as
domsticas, comerciais e mveis. Dessa forma, o uso da Web atravs da Internet tornouO surgimento e difuso da

se uma ferramenta muito verstil e poderosa. Porm, como no possvel garantir que
todos que a utilizam so bem intencionados, discute-se cada vez mais a necessidade de
ferramentas de monitoramento de seu uso. Este trabalho busca apresentar uma aplicao
para monitoramento do uso da
uma rede:

Webspy.

Web

em tempo real com foco em um

host

especco de

Essa aplicao foi desenvolvida como prova de conceito de que

Web atravs de tcnicas de ataque do


man-in-the-middle, em especial a tcnica de ARP Spoong. Dentre as funcionalidades
propostas destacam-se a ltragem e visualizao de trfego relativo a pginas da Web em

possvel realizar o monitoramento de trfego da


tipo

tempo real e a reproduo da visualizao das pginas interceptadas na ordem em que


foram acessadas pelo

host

monitorado. Todos os conceitos e tcnicas que possibilitam o

desenvolvimento da aplicao so apresentados e discutidos. A implementao nal da


aplicao apresentou resultados muito positivos quanto visualizao de pginas HTTP,
conseguindo cumprir os objetivos propostos com pequenas limitaes. A verso nal da
aplicao incluiu tambm a funcionalidade de visualizao de pginas HTTPS utilizando
a tcnica de SSL

Stripping.

Palavras-chave: monitoramento Web, ARP Spoong, man-in-the-middle, SSL Stripping

ii

Abstract
The rise and diusion of the Web has enabled the development of several applications:
domestic, commercial and mobile. Like so, the use of the Web through the Internet has
become a powerful and versatile tool. However, since it's not possible to guarantee that
everyone who use this tool is well intentioned, the need for monitoring tools is a topic
being discussed more and more often. This work presents an application called Webspy
that is capable of monitoring the use of the Web associated with a specic host in a computer network. This application was developed as a proof of concept that it is possible to
accomplish Web monitoring through man-in-the-middle atack techniques, namely ARP
Spoong. The following features are emphasized: ltering and visualization of trac related to Web pages in real time and the replay of the visualizations of intercepted pages
in the order they were viewed by the monitored host. All concepts and techniques that
make this approach possible are presented and discussed in this work. The nal implementation of the application revealed impressive results in regards to the visualization of
HTTP pages, fullling the proposed objectives with litle limitations.

The nal version

also included the feature of viewing HTTPS pages through the use of the technique known
as SSL Stripping.

Keywords: Web monitoring, ARP Spoong, man-in-the-middle

iii

Sumrio
1 Introduo

1.1

Objetivos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Organizao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Rede e dispositivos de rede


2.1
2.2

Software de Rede .
Hardware de Rede

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Descoberta de Rede e ARP Spoong

10

3.1

Protocolo ARP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.2

Protocolo ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Ping

. . . . . . . . . . . . . . . . . . . . . . . . . . .

16

. . . . . . . . . . . . . . . . . . . . . . . . . . .

16

. . . . . . . . . . . . . . . . . . . . . . . . . . .

19

. . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.3
3.4

sweep X ARP sweep


ARP Spoong . . . . . . .
3.4.1
ARP poisoning . .
3.4.2
Relay . . . . . . .

4 Filtragem e visualizao do trfego Web


4.1

Protocolo HTTP

22

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.1.1

Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.1.2

Transaes e Mensagens

. . . . . . . . . . . . . . . . . . . . . . . .

23

4.1.3

Conexo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.1.4

Servidores

Proxy

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.2

Filtragem de mensagens HTTP

. . . . . . . . . . . . . . . . . . . . . . . .

4.3

Visualizao de pginas HTML

. . . . . . . . . . . . . . . . . . . . . . . .

28

4.4

Melhorando a ltragem e visualizao . . . . . . . . . . . . . . . . . . . . .

29

4.5

Protocolo HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

5 Desenvolvimento do Webspy
5.1

5.2

5.3

27

36

Mdulo de Varredura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.1.1

Desenvolvimento

5.1.2

Resultado

Mdulo de ARP

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

. . . . . . . . . . . . . . . . . . . . . . . . . . .

37

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

Spoong .

5.2.1

Desenvolvimento

5.2.2

Resultado

Mdulo de visualizao de pginas HTML


5.3.1

. . . . . . . . . . . . . . . . . .

41

Primeira verso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

iv

5.3.2
5.4

5.5

Segunda verso

Mdulo de

Playback

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.4.1

Desenvolvimento

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.4.2

Resultado

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Integrao e resultados obtidos

. . . . . . . . . . . . . . . . . . . . . . . .

49

6 Concluso

52

Referncias

54

A Criptograa e protocolo SSL

58

A.1

Conceitos de Criptograa . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

A.2

Certicados e assinatura digital

. . . . . . . . . . . . . . . . . . . . . . . .

59

A.3

Protocolo SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

A.3.1

. . . . . . . . . . . . . . . . . . .

61

. . . . . . . . . . . . . . . . . . .

62

. . . . . . . . . . . . . . . . . . .

65

. . . . . . . . . . . . . . . . . . .

65

. . . . . . . . . . . . . . . . . . .

65

A.3.2
A.3.3
A.3.4
A.3.5

SSL Record Protocol . . . . . . .


SSL Handshake Protocol . . . . .
SSL Change Cipher Spec Protocol
SSL Alert Protocol . . . . . . . .
SSL Application Data Protocol .

Lista de Figuras
Webspy

1.1

Congurao de rede na qual o

1.2

Trfego de rede do

2.1

Camadas do modelo TCP/IP e protocolos correspondentes

2.2

Camadas do modelo OSI comparadas com as camadas do modelo TCP/IP.

2.3

Topologias de congurao de rede

2.4

Funcionamento de um

2.5

Funcionamento de um

3.1
3.2
3.3

Divises de

Frame

bits

host

B antes e durante a utilizao do

hub [16] . .
switch [16]

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

para cada classe de endereamento

host

Webspy

. . . . . . . . . . . . . . . . . . . . . .

Ethernet como denido em [20]

Dilogo ARP para que um

host

poderia ser utilizado . . . . . . . .

. . . . . . . . . . . . .

11

. . . . . . . . . . . . . . . . . . . .

11

A encontre o endereo de mquina de um

B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .

12

3.4

Campos do cabealho IPv4 como denido em [21]

3.5

Varredura ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.6

Varredura Ping

18

3.7

Exemplo de ataque

. . . . . . . . . . . . . . . . . . . .

19

3.8

Exemplo de envenenamento ARP. . . . . . . . . . . . . . . . . . . . . . . .

20

4.1

Ilustrao do modelo cliente/servidor

4.2

Informaes contidas em uma URL

4.3

Mensagens de uma transao HTTP

4.4
4.5

Recursos que compem uma pgina HTML - adaptada de [39]

. . . . . . .

26

4.6

Etapas do processo de NAT

. . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.7

Redirecionamento da requisio de um recurso que exige uma conexo segura 33

4.8

Redirecionamento intermediado por um servidor

malicioso . . . . . .

34

5.1

Menu de seleo de interface . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.2

Sadas dos prottipos que implementam ARP e Ping

. . . . . . . . .

38

. . . . . . . . . . .

40

. . . . . . . . . . .

40

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

man-in-the-middle

13

. . . . . . . . . . . . . . . . . . . . .

22

. . . . . . . . . . . . . . . . . . . . . .

23

. . . . . . . . . . . . . . . . . . . . .

24

Conexo e visualizao de uma pgina HTML - adaptada de [39] . . . . . .

26

proxy

sweep

5.4

Poison Engine ) . . . . . . . . .
Prtipo implementado que realiza ARP Poison e Relay

5.5

Arquitetura da implementao da primeira abordagem de ltragem

. . . .

42

5.6

Arquitetura da implementao da segunda abordagem de ltragem

. . . .

46

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.3

5.7

Ferramenta APE (ARP

Exemplo do esquema de armazenamento dos arquivos


e

PlaybackRequests.wsy

5.8

Arquivo de congurao do

5.9

Opes do

menu

do

Webspy

Webspy

PlaybackCache.wsy

. . . . . . . . . . . . . . . . . . . . . .

50

. . . . . . . . . . . . . . . . . . . . . . . . . .

50

vi

5.10

Webspy

em funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.11 Comparao entre uma pgina antes e aps a realizao do SSL


pelo
6.1

Webspy

Stripping

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Visualizao dos dados de uma captura pela ferramenta

Xplico

50
51

- retirada

de [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

A.1

Esquema simtrico aplicado cifragem de mensagens

. . . . . . . . . . . .

59

A.2

Esquema assimtrico aplicado cifragem de mensagens . . . . . . . . . . .

59

A.3

Viso geral sobre a estrutura do protocolo SSL . . . . . . . . . . . . . . . .

61

A.4

Etapas do processo realizado pelo

63

A.5

Campos do cabealho que encapsula a estrutura

SSL Record Protocol

vii

. . . . . . . . . . .

SSLCiphertext

. . . .

63

Lista de Tabelas
2.1

Redes classicadas por sua abrangncia.

. . . . . . . . . . . . . . . . . . .

3.1

Classes de endereamento IPv4

. . . . . . . . . . . . . . . . . . . . . . . .

11

3.2

Descrio dos campos do cabealho IPv4 . . . . . . . . . . . . . . . . . . .

14

3.3

Mensagens ICMP - adaptada de [35]

15

4.1

. . . . . . . . . . . . . . . . . . . . .

Principais mtodos do protocolo HTTP . . . . . . . . . . . . . . . . . . . .

4.2

Status codes

4.3

Possveis valores do cabealho

4.4

Resultado do tratamento de URLs relativas relacionadas ao recurso

A.1

Cipher suites do protocolo SSL e os algoritmos correspondentes - adaptada

A.2

denidos pelo protocolo HTTP

Cache-Control

24

. . . . . . . . . . . . . . . . .

24

. . . . . . . . . . . . . . . . .

30

https://paypal.com/main

de [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

Mensagens de alerta do

66

SSL Alert Protocol

viii

- adaptada de [28]

. . . . . . .

35

Captulo 1
Introduo
Desde os primrdios, algumas das principais atividades do homem so: gerao, armazenamento e transmisso de informao. O surgimento dos computadores e sua constante
evoluo possibilitou produzir, armazenar e processar um grande volume de informaes
de maneira rpida e fcil. Essa capacidade tornou os computadores cada vez mais populares, fazendo com que ocupassem um papel essencial na vida de qualquer pessoa.
Apesar de tantas funcionalidades proporcionadas com a criao dos computadores,
eventualmente surgiu a necessidade de transmitir as informaes manipuladas por eles.
Nesse contexto, surgiram as redes de computadores, sendo a

Internet

Internet

a maior delas. A

, na verdade, um sistema global e interconectado de redes de computadores

que permite a comunicao entre quaisquer computadores que estejam conectados a ela,
tambm chamados de

hosts

ou hospedeiros, como denido por [23].

O novo ambiente criado pela

Internet

propiciou o desenvolvimento de servios capazes

de distribuir e propagar informao como a

Web (World Wide Web ), e-mail, transferncia

de arquivos, entre outros, sendo o primeiro o foco deste trabalho. importante distinguir a

Internet

da

Web :

a primeira um sistema de redes interligadas, enquanto que a segunda

um sistema de documentos de hipertexto interligados que, por sua vez, podem ser
acessados pela

Internet.

Web permitiram a criao de diversas aplicaes, entre elas


comerciais e mveis [38]. Dessa forma, o uso da Web atravs da Internet

O surgimento e difuso da
as domsticas,

tornou-se uma ferramenta muito verstil e poderosa. Porm, como no possvel garantir
que todos que a utilizam so bem intencionados, discute-se cada vez mais a necessidade
de ferramentas de monitoramento de seu uso.

1.1 Objetivos
Este trabalho busca apresentar uma aplicao para monitoramento do uso da
tempo real com foco em um

Webspy

host

especco de uma rede.

A aplicao foi denominada

em homenagem a uma aplicao homnima presente no pacote

volvido por

Dug Song

para plataformas

Linux

[34].

Webspy

dsni

desen-

foi desenvolvido para

desempenhar as seguintes funes:


1. Vericar quais mquinas esto conectadas a uma rede e seus endereos.

Web em

Figura 1.1: Congurao de rede na qual o

Webspy

poderia ser utilizado

2. Analisar o trfego de rede que chega e sai de um determinado host da rede (

host

alvo).
3. Interceptar/encaminhar o trfego destinado ao

host

alvo sem que ele perceba.

4. Filtrar o trfego destinado ao acesso/utilizao de pginas


5. Exibir as pginas da

Web

acessadas pelo navegador

Web

Web.

da mquina alvo no nave-

gador da mquina atacante em tempo real.


A Figura 1.1 demonstra o contexto de aplicao do
ou roteador com conexo para a

Internet

Webspy :

uma rede com um

switch

e um conjunto de mquinas conectadas a esse

dispositivo por meio de cabos. A Figura 1.2a, por sua vez, representa como ocorre o trfego

host B (que ser o dispositivo alvo) antes da insero da mquina que


Webspy, enquanto que a Figura 1.2b apresenta como o trfego ser interceptado

de rede para o
executa o

e redirecionado durante a execuo da aplicao.


As tcnicas aqui apresentadas, discutidas e implementadas tm nalidade exclusivamente acadmica e buscam demonstrar, como prova de conceito, vulnerabilidades j
conhecidas. Acredita-se que este trabalho possa estimular e orientar a criao de novas (e
mais ecazes) formas de proteo. O autor e seu orientador no se responsabilizam por
qualquer uso indevido, inadvertido ou inadequado resultantes da aplicao dos conceitos,
tcnicas e resultados aqui expostos, em especial qualquer uso que no se enquadre no
aceitvel da prtica acadmica. Os artefatos de

software

produzidos neste trabalho cam

sob a guarda exclusiva do autor e de seu orientador.

1.2 Metodologia
Para o desenvolvimento deste trabalho foram realizadas diversas atividades.

A pri-

meira consistiu na reviso terica dos conceitos bsicos de rede e tcnicas de ataque do
tipo

man-in-the-middle

[17, 22] tambm conhecidas como

intruder-in-the-middle.

Uma

(a) Trfego normal (antes da insero

(b) Trfego redirecionado pela aplica-

da mquina atacante)

Figura 1.2: Trfego de rede do

host

B antes e durante a utilizao do

Webspy

vez consolidados os conhecimentos, dividiu-se cada uma das funcionalidades da aplicao


em mdulos e foram implementados prottipos relativos a cada mdulo. Aps a realizao de testes individuais nos prottipos, eles foram reunidos em uma nica aplicao que
foi testada em um ambiente de rede controlado.

1.3 Organizao do trabalho


No captulo 2, so apresentados os principais conceitos das redes de computadores,
bem como a evoluo dos dispositivos que permitiram cri-las, ressaltando que medida
que caram mais desenvolvidos, tornaram o monitoramento uma tarefa cada vez mais
difcil.
Os dois captulos seguintes abordam conceitos tericos que fundamentam a imple-

Webspy. O captulo 3 apresenta tcnicas de


descoberta de rede e discute os conceitos de ARP Spoong e man-in-the-middle. Por sua
vez, o captulo 4 explica como feita a ltragem e visualizao do trfego da Web.

mentao das principais funcionalidades do

O captulo 5 discute decises e detalhes de implementao, apresentando a arquitetura

do

Webspy

e os resultados obtidos.

Por m, o captulo 6 expe consideraes nais e

discute trabalhos futuros.

Captulo 2
Rede e dispositivos de rede
Uma rede de computadores pode ser denida como uma infraestrutura de

software

hardware

que permite o compartilhamento de recursos e a troca de informaes entre os

dispositivos que a compem (chamados de hospedeiros,

hosts

ou ns). As redes podem

ser classicadas quanto ao seu tamanho e abrangncia como mostra a Tabela 2.1.

Local Area Network )

Uma rede local tambm chamada de LAN (

uma rede que se

Uma MAN (Metropolitan Area


Network ) consiste em uma rede que interconecta diversas LANs que se encontram numa
mesma regio geogrca como, por exemplo, uma cidade. Uma WAN (Metropolitan Area
Network ), por sua vez, refere-se a uma rede que abrange pases ou continentes e a Internet,
estende em mdia a um andar ou um nico edicio.

por m, representa a rede que tem a capacidade de abragncia mxima, ou seja, o planeta
inteiro.

2.1 Software de Rede


Uma rede deve possibilitar a comunicao entre todos os ns que fazem parte dela. Do
ponto de vista de

software, foi preciso estabelecer padres que denem como cada n ser

identicado na rede, como sero divididas as informaes transmitidas, qual e quando cada
n poder iniciar uma transmisso. Esses padres constituem um

protocolo de rede

que, conforme [38], dene o formato e a ordem das mensagens trocadas entre duas ou mais
entidades comunicantes, bem como as aes realizadas na transmisso e/ou recebimento
de uma mensagem ou outro evento.

Tabela 2.1: Redes classicadas por sua abrangncia.

Tipo de Rede

Abrangncia Mdia (distncia de


processadores interconectados)

LAN

10 m a 1 km

MAN

10 km

WAN

100 km a 1000 km

Internet

10000 km

Para reduzir a complexidade do projeto, o

software de rede foi dividido em diversos

protocolos de rede que so organizados como uma pilha de camadas ou nveis.

Essa

organizao permite que cada camada tenha um propsito especco e somente precise
saber lidar com as camadas diretamente abaixo e acima. Vrios modelos foram criados

Open

para padronizar como deveria ser a estrutura de camadas, sendo o modelo OSI (

Systems Interconnection ) e o TCP/IP os dois modelos mais conhecidos.


O modelo OSI possui 7 camadas como denido em [45]:
1. Fsica:

camada de mais baixo nvel do modelo.

Dene especicaes eltricas e

fsicas dos dispositivos de rede para que possa ser realizada a transmisso de

bits

brutos atravs de um canal de comunicao (isto , possibilita a transformao dos


dados digitais em sinais que podem ser transmitidos por um canal).
2. Enlace:

o principal papel dessa camada transformar um canal de transmisso

bruta em um meio livre de erros de transmisso detectando e corrigindo-os. Esta


camada tambm se responsabiliza pelo endereamento fsico, controle de acesso e
controle de uxo.
3. Rede: prov transferncia de sequncias de dados de tamanho varivel entre

hosts

de diferentes redes. Nessa camada, denido um novo esquema de endereamento


(desta vez lgico ao invs de fsico), tendo em vista que o esquema elaborado na
camada de enlace permite apenas a transferncia de dados entre

hosts de uma mesma

rede.
4. Transporte:

prov transferncia de dados transparente e convel entre usurios

nais para as camadas superiores. O modelo OSI dene 5 classes que podem ser
implementadas por uma camada de transporte. Cada classe apresenta um conjunto
diferente de papis e servios disponibilizados, como controle de uxo, mecanismo
de retransmisso em

timeout, recuperao de erros entre outros.

5. Sesso: controla as sesses que so estabelecidas entre os computadores. Uma sesso


oferece diversos servios, como sincronizao da transmisso, controle de dilogo e
gerenciamento de smbolos.
6. Apresentao:

torna possvel a comunicao entre computadores com diferentes

estruturas de representao de dados denindo uma maneira de intercambiar estruturas para chegar a uma estrutura comum que possa ser entendida por ambos
participantes do dilogo.
7. Aplicao: prov a principal interface para que programas possam utilizar os servios
de comunicao oferecidos pelas demais camadas.
J o modelo TCP/IP (tambm chamado de pilha TCP/IP) divido em 4 camadas
como denido em [31]:
1. Interface de rede (tambm chamada de camada de enlace): lida com a transmisso de
informao (codicada em

bits

e organizada em estruturas denominadas

pacotes)

entre diferentes ns de um mesmo enlace.


2. Inter-rede ou

Internet :

tem o objetivo de possibilitar o envio de pacotes entre ns

de diferentes redes, isto , ns que no se encontram no mesmo enlace.

Figura 2.1: Camadas do modelo TCP/IP e protocolos correspondentes

Figura 2.2: Camadas do modelo OSI comparadas com as camadas do modelo TCP/IP.

3. Transporte: prov a transferncia de dados ponto a ponto, dessa forma, dois ns


podem estabelecer uma conexo entre si.
4. Aplicao: corresponde implementao do programa que deseja se comunicar com
outro

host

da rede. Nessa camada so processados os dados recebidos/enviados.

A Figura 2.1 apresenta as camadas do modelo TCP/IP e os protocolos que so utilizados em cada uma delas, enquanto que a Figura 2.2 mostra como o modelo TCP/IP
poderia ser mapeado no modelo OSI.
O modelo OSI muito importante por seu valor terico e didtico, pois foi elaborado

International Standards

com base em diversos princpios aprovados e validados pela ISO (

Organization ).

No entanto, a criao do modelo TCP/IP e o surgimento de suas primei-

ras implementaes mostraram que um modelo simplicado teria uma implantao mais
simples e, portanto, maior alcance.

2.2 Hardware de Rede


Do ponto de vista de

hardware, os computadores que compem uma rede podem estar

organizados de diversas maneiras, representando assim diferentes topologias que possuem

(a) Barramento

(b) Estrela

Figura 2.3: Topologias de congurao de rede

vantagens e desvantagens entre si como exemplicado em [43].


Duas das topologias mais conhecidas so barramento e estrela. Em uma rede de bar-

hosts da rede esto interconectados por um grande cabo (tambm


chamado de cabo de backbone ) como mostra a Figura 2.3a. Dessa forma, preciso controlar como ocorrer o envio de informao entre hosts tendo em vista que todos eles
ramento, todos os

compartilham o mesmo canal para transferncia de dados (pacotes). Para isso dene-se
um padro sendo que, para esta topologia, o mais conhecido o

Ethernet [26] que dene

uma rede de difuso de barramento com controle descentralizado.

hosts transmitam informaes sempre que desejem,


entre pacotes, os host envolvidos aguardam um tempo

Uma rede Ethernet permite que os


porm caso ocorra uma coliso

aleatrio e tentam novamente. Esta topologia apresenta diversas vantagens: a instalao

hardware da rede consiste apenas em uma pequena


um host da rede no produz nenhuma consequncia

facilitada pois a infraestrutura de


quantidade de cabos e a falha de

para os outros dispositivos conectados a ela. Como desvantagens pode-se citar: o limite

hosts conectados na rede e a possibilidade de ocorrncia de problemas com


backbone, que resultaria na interrupo do servio de rede.

do nmero de
o cabo

Uma rede com topologia em estrela tambm opera de acordo com o padro Ethernet.
Nesse esquema de rede, cada

hosts

se conecta a um dispositivo centralizador por meio

de um cabo, formando assim uma estrutura em estrela como mostra a Figura 2.3b. O
dispositivo centralizador recebe as mensagens de todos outros dispositivos da rede e se
encarrega de encaminh-las aos destinatrios pretendidos. Essa estrutura uma das mais
utilizadas, principalmente em redes domsticas, pois a instalao e congurao fcil e
conveniente. No entanto, assim como na topologia em barramento, ainda existe um ponto
nico de falha: o dispositivo centralizador, tambm chamado de
Um dos primeiros dispositivos de rede criados foi o

hub.

dispositivo de rede.

Esse aparelho tem a capaci-

dade de conectar mltiplos dispositivos Ethernet fazendo com que eles formem um nico
segmento de rede.
O

hub

possui um conjunto de portas Ethernet (de entrada e sada) e funciona como

um repetidor de sinal, isto , tudo que chega entrada de uma porta enviado sada
de todas as outras portas como mostra a Figura 2.4.

A diferena entre um

hub

e um

repetidor de sinal que o repetidor, por denio, possui somente duas conexes, ou seja,
conecta dois dispositivos apenas.
A simplicidade e ecincia (para redes pequenas) deste dispositivo o tornou muito
barato e consequentemente muito difundido.

Alm disso, seu uso limitava as possveis

hub

Figura 2.4: Funcionamento de um

Figura 2.5: Funcionamento de um

[16]

switch

[16]

colises de pacotes a um segmento, isto , uma seo da rede cujos dispositivos podem se
comunicar utilizando endereos de enlace.
Para o propsito visado por este trabalho (monitoramento de uso da

host

Internet

de um

especco de uma rede), esse dispositivo de rede perfeito, pois bastaria conectar

a mquina que deseja realizar o monitoramento no

hub

para que ela pudesse escutar o

trfego da mquina alvo.


No entanto, o

hub

no um dispositivo de rede escalvel, isto , medida que a

rede cresce, o desempenho gravemente impactado (pois aumenta-se a probabilidade de


ocorrncia de colises), alm de que atualmente so considerados obsoletos.
Isso porque o

hub

replica e transmite o trfego de uma porta para todas as outras

mesmo quando necessrio transmitir mensagens para um nico

host.

Com intuito de re-

hub, o dispositivo conhecido


switch.
O switch um dispositivo de rede capaz de dividir uma rede em pequenos pedaos l-

solver esse e outros problemas, foi desenvolvida a evoluo do


como

gicos tambm chamados de segmentos, como denido em [14]. Esse dispositivo possui um
esquema de portas parecido com o do
O funcionamento do

hub, porm seu funcionamento muito diferenciado.

switch est descrito em detalhes em [33].

Basicamente, ele analisa

o trfego que chega em uma porta de entrada e determina para qual porta de sada
ele dever ser transmitido, portanto opera sobre a camada 2 (enlace). Alm disso, esse
aparelho registra quais dispositivos esto conectados em cada porta, o que permite realizar
um processamento muito mais ecaz.
A Figura 2.5 exemplica o funcionamento de um

switch

considerando a transmisso

de dados do dispositivo conectado na porta 1 para o conectado na porta 7 (bem como a


transmisso do dispositivo da porta 4 para o da porta 6).

Outra distino que deve ser realizada entre um

hub

e um

switch

que o primeiro

atua somente no nvel de hardware (camada 1), enquanto que o ltimo opera em conjunto
com um software, uma implementao do protocolo Ethernet, o que caracteriza-o como
um dispositivo de camada 2 (enlace), conforme explicitado anteriormente.
Apesar de apresentar uma circuitaria muito mais avanada que a dos

ches

hubs,

os

swit-

rapidamente tomaram seu lugar como principal dispositivo de rede tanto para redes

domsticas quanto para redes de maior porte.

Hubs e switches

so dispositivos muito teis para conectar

enlace ou sub-rede, porm no permitem conectar

hosts

hosts

dentro de um mesmo

que esto em sub-redes distintas.

Para que ocorra uma conexo desse tipo, preciso adotar uma forma de identicao
para cada n, de maneira que ela seja vlida entre sub-redes e no mais somente em uma
nica sub-rede. Para suprir essa necessidade foi criado o roteador, um dispositivo de rede

Internet Protocol ), operando assim como um

capaz de entender e utilizar o protocolo IP (


dispositivo de camada 3 (rede).

Um roteador pode ser descrito como um dispositivo de rede que encaminha pacotes
de dados entre redes de computadores, criando assim uma interconexo entre sub-redes.
Para isso, esse dispositivo gerencia endereos e rotas, isto , caminhos para se chegar a
um determinado endereo.

Captulo 3
Descoberta de Rede e ARP Spoong
A expresso descoberta de rede refere-se atividade de descoberta de quais dispositivos
esto conectados a uma rede e onde eles esto, isto , a partir de qual endereo eles podem
ser encontrados.

A descoberta (tambm chamada de varredura) pode ser realizada em

diferentes nveis devendo-se basear no protocolo correspondente ao nvel escolhido.


No nvel da camada de enlace, possvel realizar a varredura ARP (

Protocol ) tambm chamada de ARP sweep.

Address Resolution

Cada dispositivo conectado a uma sub-rede

deve possuir uma placa de rede que contm um endereo denominado endereo MAC

Media Access Control ).

Esse endereo tambm chamado de endereo de mquina ou de

hardware

nico e

responsvel por identicar cada mquina dentro de uma mesma sub-rede. Um endereo
MAC possui 48

bits

(tipicamente representados por 6 pares de nmeros hexadecimais

separados por dois pontos, por exemplo: AA:AA:AA:AA:AA:AA), o que permite gerar
48
aproximadamente 2
combinaes diferentes. Esse nmero mais que suciente para
suportar a quantidade de dispositivos que necessitam acessar uma rede (e/ou a

Internet )

considerando que esse endereo utilizado apenas para identicao em uma sub-rede.
Cada dispositivo conectado a uma rede possui tambm um endereo cuja funo
identicar
32

bits

hosts de diferentes redes, como denido pelo protocolo IP. Esse endereo possui

(considerando a verso IPv4) geralmente representado como um conjunto de 4

nmeros de 0 a 255 separados por pontos, como por exemplo 192.168.1.1.

netid, poro que identica uma rede e hostid,


poro que identica um host. O nmero de bits alocados para cada diviso permite uma
O endereo de rede dividido em

distribuio de endereos adequada para o tamanho de cada rede.


Com este intuito, os endereos foram divididos em classes.
nmero de combinaes possveis de redes e

hosts

A Tabela 3.1 exibe o

para 3 das classes de endereamento

mais utilizadas em LANs e a Figura 3.1 mostra como esto divididas cada classe.
Durante os clculos de nmero de redes e hosts, importante lembrar que devem ser
subtrados dois endereos que so reservados: o endereo rede/sub-rede (todos os

hostid

em 0) e o endereo de

broadcast

(todos os

bits

do

hostid

bits

do

em 1).

3.1 Protocolo ARP


O protocolo ARP prov um mtodo de mapeamento dinmico capaz de traduzir um
endereo de rede em um endereo de mquina correspondente.

10

De acordo com [35], o

Tabela 3.1: Classes de endereamento IPv4

Classe

N de Redes
8

N de hosts
24

2 2 = 126
216 2 = 126
28 2 = 126

A
B
C

Figura 3.1: Divises de

Notao

2 2 = 16777214
216 2 = 65534
28 2 = 254

bits

/8
/16
/24

para cada classe de endereamento

termo dinmico refere-se ao fato de que essa traduo ocorre automaticamente sem que
o usurio nal ou o administrador do sistema precise tomar alguma atitude especca.
Este protocolo executado sob a camada 2 (enlace) e, portanto, os dados transmitidos devem apresentar o cabealho Ethernet, constituindo assim um

frame

como mostra

a Figura 3.2. Existem diversos formatos para o cabealho Ethernet, portanto ser considerado, neste trabalho, o padro proposto em [20].
Dessa forma, o cabealho deve possuir 18
de origem e destino, 2

bytes

bytes

bytes :

12

bytes para os endereos de mquina

para o tipo de protocolo correspondente aos dados, 46 a 1500

para os dados a serem transmitidos e 4

bytes

para o CRC, campo que possibilita a

vericao de integridade.
Todo dispositivo conectado rede possui uma tabela que contm uma lista de mapeamentos de endereos denominada

cache

ARP. Essa lista, contm apenas os mapeamentos

mais recentes e cada entrada possui um tempo de expirao (normalmente 20 minutos)


aps o qual ela removida.
Para que um

host

A envie uma mensagem para um

host

B, preciso que o primeiro

saiba o endereo de rede do segundo. Para isso, ele procura em seu

cache

ARP por uma

entrada com o endereo de rede de B. Se houver, ele recupera o endereo de mquina


correspondente e envia a mensagem encapsulando-a em um

frame

Ethernet.

Caso no exista, ele envia uma mensagem de requisio ARP (ARP

Figura 3.2:

Frame

Ethernet como denido em [20]

11

request )

para

(a) Envio de requisio ARP

(b) Envio de resposta ARP

(c) Atualizao de
Figura 3.3: Dilogo ARP para que um

host

host

cache

ARP

A encontre o endereo de mquina de um

todos os

hosts

de sua sub-rede (utilizando o endereo de mquina de

mensagem, tambm conhecida como

who-has,

broadcast ).

Essa

contm duas informaes: o endereo de

rede para o qual se quer saber o endereo de mquina e o endereo de rede da mquina
que faz a requisio.

como endereo de origem).

reply ) para
frame da requisio ARP
Esta mensagem, por sua vez, conhecida como is-at e tambm

contm duas informaes:

o endereo de rede procurado e seu endereo de mquina

Quando o

host

B recebe a requisio, ele envia uma resposta ARP (ARP

A (B sabe o endereo de mquina de A, pois ele est presente no

correspondente. Ao receber a resposta, o

host

B em seu

cache

host

A adiciona uma entrada correspondente ao

ARP. A Figura 3.3 ilustra esse processo.

Uma caracterstica fundamental e necessria para a realizao do ataque discutido


neste trabalho a volatilidade do protocolo ARP. Sempre que um

host

recebe uma res-

cache, portanto, um host malicioso pode facilmente injetar


cache de um determinado host.
O protocolo ARP permite tambm a realizao do ARP sweep. Para realizar este tipo

posta ARP, ele atualiza seu


informaes arbitrrias no

de varredura, consideram-se todos os endereos vlidos de uma rede. Por exemplo, caso
a rede na qual ser feita a varredura seja uma rede de classe C, sabe-se que ela possuir
no mximo 254 dispositivos conectados.
A varredura consiste em injetar, na rede, requisies ARP para cada endereo de rede
disponvel. Dessa forma, se, ao se conectar em uma rede de classe C, o dispositivo que

12

Figura 3.4: Campos do cabealho IPv4 como denido em [21]

deseja realizar a varredura recebe o endereo IP 192.168.1.101, ele ir enviar requisies


ARP para os endereos de 192.168.1.1 a 192.168.1.254.
Em seguida, ele ir receber as respostas ARP dos dispositivos que esto de fato conectados rede. Uma vantagem desse mtodo que, ao receber as respostas, o dispositivo
que realizou a varredura saber tanto o endereo de rede quanto o endereo de mquina
de cada dispositivo.

3.2 Protocolo ICMP


O protocolo ICMP pode ser considerado uma parte do protocolo IP, portanto, refere-se
camada 3 (rede). Este protocolo tem por objetivo permitir que

hosts

gateways

(roteadores) e

possam trocar mensagens de erro e controle.

As mensagens ICMP so transmitidas utilizando o protocolo IP, isto , so encapsuladas em um datagrama IP. Para isso, preciso adicionar o cabealho IP s mensagens.
Este, por sua vez, constitudo pelos campos mostrados na Figura 3.4 e explicados na
Tabela 3.2.
Uma mensagem ICMP possui tamanho varivel de acordo com o tipo de mensagem,

bytes possuem o mesmo formato para todos tipos: 1 byte para o tipo
da mensagem, 1 byte para o cdigo e 2 bytes para o checksum (que permite a vericao
porm os primeiros 4

de integridade da mensagem).
A Tabela 3.3 mostra algumas das diferentes mensagens ICMP e classica-as em mensagens de consulta (mensagens que pedem/apresentam alguma informao) e mensagens
de erro (mensagens que indicam alguma condio na qual foi vericada um erro).

13

Tabela 3.2: Descrio dos campos do cabealho IPv4

Campo

Version
Header Length
Type of Service

Tamanho

Descrio

verso do protocolo IP (ex: IPv4 ou IPv6).

bits
4 bits
8

bits

tamanho do cabealho incluindo os campos de


opes.
especica caractersticas desejadas durante a
transmisso do pacote (ex: mximo

Total Length
Id
Flags

bits
16 bits
3 bits
16

Fragment Oset

13

bits

throughput,

mxima conabilidade).
tamanho total do datagrama.
nmero de identicao do datagrama.
indicam condies especiais (ex:

More fragments ).

Don't Fragment,

indica qual parte da mensagem completa corresponde aquele datagrama (caso tenha ocorrido

Time to Live

(TTL)

Protocol Id

8
8

bits
bits

fragmentao).
limite superior de roteadores pelos quais o
datagrama deve poder passar.
identica o protocolo de camada imediatamente
superior que passou dados que sero encapsula-

Checksum
Source IP Address
Destination IP Address
Option

16

bits

bits
32 bits
32

varivel

dos pelo IP.


permite realizar vericaes de integridade do datagrama.
endereo de origem do datagrama.
endereo de destino do datagrama.
armazena informaes opcionais do datagrama.

14

Tabela 3.3: Mensagens ICMP - adaptada de [35]

Tipo

Cdigo

Descrio

echo reply
destination unreachable :
network unreachable
host unreachable
protocol unreachable
port unreachable
fragmentation needed but don't fragment bit set
source route failed

3
0
1
2
3
4
5
.
.
.

.
.
.

10

.
.
.

echo request
router advertisement
router solicitation
time exceeded
time to live equals 0 during transit
time to live equals 0 during reassembly

0
1
.
.
.

.
.
.

Uma das preocupaes do protocolo ICMP a ocorrncia de

broadcast

.
.
.

.
.
.

a gerao de um grande nmero de mensagens de

Erro

.
.
.

11

.
.
.

Consulta

.
.
.

broadcast storms, isto ,

causando a saturao da rede

e consumo de toda a banda disponvel. Para evitar essa condio, o protocolo adota um
conjunto de regras que impedem a gerao de mensagens de erro ICMP em resposta a:
1. Uma outra mensagem de erro ICMP.
2. Um datagrama encapsulado por um
(isto ,

brodcast

frame

com endereo de destino de

de camada 2).

3. Um datagrama cujo endereo de destino no identique um nico


loopback,

broadcast

multicast

ou

broadcast ).

host

(endereo de

4. No caso de um datagrama fragmentado, qualquer fragmento que no seja o primeiro.


Alm disso, quando uma mensagem de erro gerada, ela sempre carrega o cabealho
IP e os primeiros 8

bytes

do datagrama IP que ocasionou o erro, carregando assim mais

informaes que possam ser utilizadas para vericar a causa do erro. O funcionamento do
protocolo ICMP permitiu a criao do programa Ping, uma ferramenta capaz de fornecer
informaes sobre

hosts

presentes em uma rede.

Basicamente, o Ping injeta, em uma rede, uma mensagem ICMP do tipo


destinada a um

host

echo request

da rede (um endereo de IP) e aguarda um tempo denido para

receber uma mensagem de resposta ICMP. A mquina de destino envia uma mensagem
ICMP do tipo

echo reply

assim que recebe uma mensagem

15

echo request.

Dessa forma, caso receba a mensagem de resposta, a mquina que executou o programa
Ping consegue determinar se a mquina de destino est ativa, bem como o

round-trip time,

que pode ser utilizado para estimar a distncia relativa entre as duas mquinas.

3.3 Ping sweep X ARP sweep


Como visto nas sees anteriores, tanto o protocolo ARP quanto o ICMP provem
ferramentas para realizar descoberta de rede.

As Figuras 3.5 e 3.6 ilustram como so

realizadas cada uma das varreduras.


Pode-se perceber, que a varredura ARP sobrecarrega mais a rede, pois cada mensagem
ARP request enviada em

broadcast,

hosts da rede. A
mensagem echo request

isto , enviada para todos os

varredura Ping, por sua vez, menos barulhenta, pois cada

host, tornando esta varredura mais discreta.


Alm disso, o Ping pode ser utilizado para vericar hosts ativos e realizar varreduras

enviada para apenas um

de outras sub-redes que no a subrede na qual a mquina que executa o programa est
conectada.
Isto no pode ser feito com o ARP, pois ele um protocolo de camada 2 e, portanto,
no rotevel.

No entanto, muitos roteadores e servidores so congurados para no

enviar mensagens

echo reply, o que inutilizaria a varredura Ping.


rewall para ltrar mensagens echo request.

Pode-se tambm, congurar um

Quanto

a essas medidas, a varredura ARP mais eciente, tendo em vista que a maioria dos

rewalls

operam apenas em mensagens a partir da camada 3 (rede).

3.4 ARP Spoong


Uma vez realizada a descoberta de rede, sabe-se quais

hosts

esto conectados a uma

sub-rede e assim pode-se escolher uma vtima. O prximo passo interceptar o trfego
de rede da vtima e repass-lo a ela sem que ela perceba qualquer alterao.

spoof refere-se atividade de falsicar ou forjar alguma informao. Dessa


forma, o ARP Spoong consiste na falsicao de mensagens ARP com o objetivo de
realizar um ataque do tipo man-in-the-middle (MitM) como denido em [40, 24, 11, 12].
O termo

Um ataque MitM ocorre sobre um meio de comunicao e tem como alvo duas entidades
que mantm uma comunicao.
A Figura 3.7 ilustra uma conversa entre Alice e Bob antes e durante a realizao de
um ataque MitM. Uma vez estabelecida a conversa, o atacante, denomidado John, inicia
o ataque. John consegue tanto o acesso ao contedo da conversa de Alice e Bob, quanto a
capacidade de adulterar os dados que passam por ele em qualquer direo. Sendo assim,
a realizao de um ataque MitM requer que o atacante:
1. Saiba como realizada a autenticao entre os alvos: caso Alice e Bob possuam um
protocolo para garantir que Alice fala realmente com Bob e vice-versa, preciso que
o atacante John seja capaz de forjar informaes de maneira a explorar vulnerabilidades desse protocolo - convencendo que Alice est falando com Bob ao falar com
John e que Bob est falando com Alice ao falar com John.

16

(a) Envio de requisies ARP

(b) Envio de respostas ARP


Figura 3.5: Varredura ARP

17

(a) Envio de mensagens

echo request

(b) Envio de mensagens

echo reply

Figura 3.6: Varredura Ping

18

(a) Conversa entre Alice e Bob antes do ataque

(b) Conversa entre Alice e Bob (por meio de John) aps o ataque
Figura 3.7: Exemplo de ataque

man-in-the-middle

2. Tenha acesso ao canal: o atacante John deve conseguir entrar no meio do canal
(como sugere o nome do ataque) de forma que o uxo de dados que ui de Alice
para Bob e vice-versa no tenha como chegar a seu destinatrio pretendido sem
antes passar por ele.
3. Encaminhe as mensagens: como o atacante entra no meio do canal, passa a ser sua
responsabilidade o encaminhamento (ou no, conforme o objetivo do ataque) das
mensagens de Alice para Bob e vice-versa.
O ARP spoong
poisoning ) e o relay

3.4.1

ARP

tipicamente consiste em duas etapas: o envenenamento ARP (ARP


que sero discutidas nas prximas sees.

poisoning
switch

Seja R um roteador/

e H um

host conectado subrede de R, a etapa de envespoong de mensagens ARP com o intuito de

nenamento ARP consiste na realizao de

redirecionar, para uma mquina atacante A, o trfego que iria de R para H e de H para
R.
Inicialmente, a subrede possui apenas os

hosts

R e H. Em seguida, o

host

A se conecta rede e recebe um endereo IP como ilustra a Figura 3.8a.


vai ento realizar um mtodo de varredura de

hosts

atacante

O atacante

(como discutido no captulo 3) na

subrede para encontrar uma vtima e seus endereos MAC e IP.


Uma vez conhecidos os endereos da vtima, o atacante envia uma mensagem de
resposta ARP para R informando que o IP 192.168.1.102 (IP de R) est associado ao
MAC 0:c2:ee:a1:92:33 (MAC de A). Dessa forma, o cache ARP de R atualizado e todo
trfego com o IP de destino de H vai ser direcionado para A. De forma anloga, o uxo
de H com destino R redirecionado para A. A Figura 3.8b, ilustra o resultado nal.
Por m, para que o envenenamento ARP seja de fato ecaz, preciso repetir o processo
de acordo com a taxa de expirao das entradas do cache ARP. Isso porque, caso a
entrada de um

host

expirasse, aquele

host

iria enviar uma mensagem de requisio ARP

e receberia uma resposta legtima, o que reestabeleceria o trfego normal. Essa repetio,

19

(a) Cenrio anterior ao envenenamento ARP.

(b) Cenrio aps envenenamento ARP.


Figura 3.8: Exemplo de envenenamento ARP.

20

acaba facilitando a deteco deste tipo de ataque, pois gerado um uxo peridico de
respostas ARP como abordado em [41, 29, 12].

3.4.2

Relay

Esta etapa, consiste no encaminhamento das mensagens que chegam ao

host

atacante.

H duas maneiras de fazer isso: de forma automtica ou de forma manual. Para realizar
o processo de forma automtica basta habilitar o roteamento de pacotes IP, uma congurao da implementao da pilha TCP/IP que vem desabilitada por padro nos sistemas
operacionais de propsito geral (

Windows

e distribuies

Linux ).

Apesar de prtica, essa

maneira oferece menos poder sobre os pacotes que esto sendo roteados, pois a pilha
TCP/IP se encarrega de tudo.
A outra maneira consiste em realizar manualmente a escuta dos pacotes e o encaminhamento injetando-os de volta na rede (desta vez com o endereo MAC de destino
correto). Dessa forma, a aplicao que realiza o ARP

spoong

deve lidar com a escuta

e injeo de pacotes, porm ganha mais exibilidade quanto aos pacotes encaminhados
(pode-se adulter-los ou simplesmente deixar de enviar algum).

21

Captulo 4
Filtragem e visualizao do trfego Web
Utilizando o ARP

spoong

consegue-se acesso ao trfego de rede entre dois

hosts

de

uma sub-rede. O prximo passo identicar e separar a parte desse uxo de dados que
refere-se navegao de pginas da

Web.

Para isso, preciso primeiramente entender um

pouco mais sobre o protocolo de aplicao que permite a comunicao entre dispositivos
e a

Web.

4.1 Protocolo HTTP


Hypertext Transfer Protocol ) o protocolo de aplicao responWeb. Ele
popularizou a transmisso de dados formatados na linguagem HTML (Hypertext Markup
Language ), alm de diversos outros formatos como denido em [15].
O contedo da Web est distribudo em diversos servidores Web que operam de acordo
O protocolo HTTP (

svel por denir como se d a transmisso de dados entre os usurios da

com o protocolo HTTP. Dessa maneira, esses dados podem ser obtidos pelos clientes por
meio de requisies HTTP. Esse tipo de arquitetura conhecido como cliente/servidor,
como ilustra a Figura 4.1. O tipo mais comum de cliente HTTP so os navegadores

browsers ).

Figura 4.1: Ilustrao do modelo cliente/servidor

22

Web

Figura 4.2: Informaes contidas em uma URL

4.1.1

Recursos

Cada servidor

Web

possui um conjunto de recursos, que podem ser qualquer tipo

de arquivo esttico ou dinmicamente gerado, como pginas HTML, imagens, arquivos


de texto, etc. Os servidores possuem tambm um nome associado que pode ser utilizado
pelos clientes para referenciar os recursos pelos quais se interessam. Esse nome conhecido

Uniform Resource Identier ).

como URI (

Uma URI, por sua vez, pode ser uma URL (Uniform Resource Locator ) ou uma URN
Uniform Resource Name ). Uma URL descreve a localizao especca de um recurso em
um servidor Web, denindo: o protocolo a ser utilizado, o endereo do servidor (tambm
conhecido como hostname ) e o nome do recurso a ser buscado, como mostra a Figura 4.2.
(

Uma URN, por conseguinte, dene um nome nico para um recurso, independentemente
de onde ele se encontre. As URNs so pouco adotadas e ainda esto em fase experimental,
segundo [39].

4.1.2

Transaes e Mensagens

O processo de interao entre clientes HTTP e servidores denominado


Uma transao consiste em duas mensagens:
resposta.

transao.

uma mensagem de requisio e uma de

Mensagens HTTP so compostas de sequncias de caracteres separadas por

linhas e possuem trs regies:


1. Linha inicial: primeira linha da mensagem. Caso a mensagem seja uma requisio,
indica o que deve ser feito pelo servidor, caso seja uma resposta, indica o resultado
da resposta.
2. Cabealho: coleo de campos que fornecem informaes adicionais sobre a mensagem. Cada campo possui um nome e valor separados pelo caractere :. O cabealho
sempre termina com uma linha vazia.
3. Corpo: aps a ltima linha do cabealho, uma mensagem pode conter qualquer tipo
de dado (texto ou binrio) constituindo assim o corpo da mensagem.
A Figura 4.3 ilustra as mensagens de uma transao simples. Toda requisio HTTP
possui um mtodo que indica ao servidor qual ao ele deve realizar.

A Tabela 4.1

apresenta os principais mtodos e suas funes. Cada resposta HTTP, por sua vez, possui
um

status code :

cdigo numrico de 3 dgitos que indica ao cliente qual foi o resultado da

ao requisitada. A Tabela 4.2 descreve os cdigos mais comuns.

23

Figura 4.3: Mensagens de uma transao HTTP

Tabela 4.1: Principais mtodos do protocolo HTTP

Mtodo

Descrio

GET

solicita um recurso.

HEAD

solicita apenas o cabealho associado a um recurso.

PUT

envia dados a serem adicionados a um recurso.

POST

acrescenta um recurso.

DELETE

remove um recurso.

Tabela 4.2:

Cdigo
200
302
404

Status codes

denidos pelo protocolo HTTP

Descrio

OK. Recurso retornado com sucesso.


Redirect. O recurso se encontra em outra localizao.
Not found. O recurso no pde ser encontrado.

24

4.1.3

Conexo

O protocolo HTTP um protocolo de aplicao e, portanto, depende dos protocolos


TCP e IP para que possa efetivamente trocar mensagens com os dispositivos espalhados
pela

Internet.

O protocolo TCP foi escolhido por apresentar as seguintes caractersticas:

1. Transporte de dados livre de erros.


2. Entrega ordenada, isto , os dados chegam aplicao na mesma ordem em que
foram enviados.
3.

Full-duplex,

isto , permite a transferncia simultnea de

stream

bytes )

de dados (

nas duas direes da comunicao cliente/servidor.


Sendo assim, para que duas aplicaes HTTP possam se comunicar, preciso que elas
estabeleam uma conexo TCP. Para estabelecer uma conexo com um servidor, preciso
antes conhecer seu endereo IP e o nmero da porta da aplicao com a qual deseja-se
conectar. Servidores

Web

assumem a porta de nmero 80 como padro para o protocolo

Domain Name System ).

HTTP e o endereo IP pode ser obtido atravs do DNS (

DNS um banco de dados distribudo que pode ser utilizado por aplicaes TCP/IP para
estabelecer um mapeamento entre

hostnames

(presentes em uma URL) e endereos IP

como denido em [35].


A Figura 4.4 descreve o processo de conexo e visualizao de uma pgina HTML por
meio de um navegador

Web :

1. O usurio digita a URL ftp.arl.mil/mike/ping.html no navegador.


2. O navegador identica qual parte da URL refere-se ao
3. O navegador utiliza o DNS para traduzir o

hostname

hostname.

em um endereo IP.

:8080).

4. O navegador verica se a URL contm um nmero de porta (exemplo: www.website.com


Caso no haja, ele assume a porta de nmero 80.
5. O navegador estabelece uma conexo TCP com o servidor

Web

correspondente.

6. Uma vez estabelecida a conexo, o navegador envia uma requisio HTTP ao servidor.
7. O servidor envia uma resposta HTTP ao navegador.
8. A conexo encerrada.
9. O navegador exibe a pgina recebida.
Apesar de aparentar um nico recurso, deve-se perceber que uma pgina HTML pode
ser na verdade um conjunto de recursos.

Atualmente, a maioria das pginas possuem

diversos recursos associados (arquivos Javascript, CSS, imagens, etc) que podem ou no
estar espalhados por diferentes servidores.

Nesse caso, os navegadores executam uma

transao para recuperar o recurso base (aquele que referencia outros recursos) e, em
seguida, realizam uma srie de transaes para obter os recursos adicionais como ilustra
a Figura 4.5.

25

Figura 4.4: Conexo e visualizao de uma pgina HTML - adaptada de [39]

Figura 4.5: Recursos que compem uma pgina HTML - adaptada de [39]

26

4.1.4

Proxy

Servidores

Um servidor

proxy,

ou simplesmente

proxy,

um servidor

Web

cuja funo inter-

mediar as requisies e respostas de um cliente durante sua conexo com outro servidor

Web.

Dessa forma, as requisies vo do cliente para o

proxy e do proxy para o servidor de

destino nal. As respostas, por sua vez, seguem o caminho inverso. necessrio destacar
que os

proxies tm acesso total s requisies e respostas do cliente, podendo alter-las de

acordo com seus prprios objetivos. Por isso, recomenda-se utilizar apenas os servidores
que possam ser considerados conveis.

Servidores

proxy

possuem diversas utilidades,

dentre elas destacam-se:


1. Navegao annima:
da

Web,

servidor

como discutido na seo anterior, ao acessar uma pgina

preciso estabelecer uma conexo TCP. Essa conexo ca registrada no

Web que se est acessando e esse registro pode ser utilizado para identicar

quem e de onde essa pgina foi requisitada.


O mesmo acontece quando se tenta acessar uma pgina atravs de um servidor
porm, nesse caso, os dados registrados sero os do
Muitos

hackers

proxy

e no mais os do cliente.

utilizam essa tcnica (cascateando um grande nmero de

para diminuir o risco de serem rastreados ao navegar na

proxy,

Web.

proxies )

Vale notar que ainda

sim possvel rastre-los, basta ter tempo e recursos sucientes para analisar os
registros de todos servidores utilizados.
2. Restrio de contedo: fcil perceber como os servidores

proxy

podem ser uti-

lizados para ltrar ou registringir contedo, basta denir uma lista de URLs ou

hostnames

cujo acesso se quer proibir. Dessa forma, quando uma requisio com

um destino que se encontra na lista for recebida, retorna-se uma pgina de erro ou

forbidden

at mesmo uma resposta com cdigo 403 (


3. Aumento de desempenho: servidores

proxy

- recurso proibido).

podem realizar o

caching

de determina-

das transaes HTTP (isto , salvar as respostas das requisies) para melhorar o
desempenho de acesso

Internet.

Dessa maneira, ao receber uma requisio, o

verica se possui uma resposta correspondente em seu

cache.

proxy

Se possuir, ele retorna

a resposta armazenada (que mais rpido que consultar o servidor de destino se o

proxy

estiver perto do usurio que solicitou o recurso). Caso contrrio, ele realiza

uma conexo com o servidor de destino e decide se deve ou no armazenar essa


resposta no

cache.

4.2 Filtragem de mensagens HTTP


Uma vez obtido o trfego de rede de um determinado

host,

como demonstrado no

captulo 3.4, necessrio ltrar o trfego HTTP. Analisando o trfego a nvel de pacotes, a ltragem pode ser realizada selecionando apenas aqueles nos quais vericam-se as
seguintes condies:
1. IP de origem ou de destino o IP do

host

2. Contm dados relativos ao protocolo TCP.

27

monitorado.

3. Nmero da porta de origem ou de destino TCP 80.


Utilizando uma ferramenta de captura de pacotes como a

libpcap

[4] possvel con-

gurar um ltro que realiza as vericaes listadas. No entanto, preciso lembrar que,
tipicamente, ferramentas de captura de pacotes escutam tanto os pacotes que chegam a
uma interface quanto os pacotes que saem dela.

Como o dispositivo que realiza o monitoramento (por meio do ataque man-in-themiddle ) utiliza a mesma interface para receber e encaminhar o trfego do roteador ao
host monitorado e vice-versa, a ferramenta de captura ir exibir pacotes duplicados. Para
remover as duplicatas, basta ltrar os pacotes pelo endereo MAC do host que realiza o
monitoramento.
Essa abordagem de ltragem, apesar de simples, acaba se tornando um tanto trabalhosa.

Um pacote possui seu tamanho limitado pelo MTU da rede que para o padro

Ethernet 1500 bytes. As mensagens HTTP so na prtica mensagens de texto e excedem com facilidade esse limite. Isso ocasiona a segmentao de pacotes TCP que deve ser
lidada pelo programa caso ele trabalhe a nvel de pacotes. Dessa forma, preciso coletar
e juntar todos os segmentos para ento extrair as mensagens HTTP enviadas.
Aps a ltragem, preciso ainda distinguir as requisies das respostas. Isso pode ser
feito vericando o IP de destino de cada pacote.

Se o IP for igual ao do

host

monito-

rado, sabe-se que esse pacote contm uma resposta HTTP, caso contrrio, contm uma
requisio.

4.3 Visualizao de pginas HTML


Alm da ltragem, este trabalho prope uma abordagem de visualizao dos dados
capturados em tempo real, que, at onde o autor saiba, inovadora. medida que pginas
da

Web

forem requisitadas pelo

host

monitorado, as pginas retornadas so exibidas no

navegador da mquina que realiza o monitoramento.

proxy local. Durante a ltragem,


armazena-se as transaes HTTP interceptadas em um cache que pode ser acessado por
esse proxy. O prximo passo consiste em identicar quais requisies buscam recuperar
Para isso, antes da ltragem inicia-se um servidor

pginas HTML. Essa tarefa um pouco mais complicada, pois no possvel extrair essa
informao analisando apenas a requisio HTTP. A abordagem adotada, neste trabalho,
consiste em analisar a resposta de cada transao de acordo com os seguintes passos:
1. Se o cabealho da resposta possuir o valor text/html para o campo Content-type,
sabe-se que aquela resposta possui contedo HTML (porm no garante ainda que
contm uma pgina HTML).
2. Se a resposta estiver codicada em

chunks, mecanismo introduzido pela verso 1.1

do protocolo HTTP, decodica-se a mensagem como denido em [19].


3. Se a mensagem decodicada estiver comprimida (pginas HTML tipicamente so
comprimidas no formato

gzip ), os dados so descompactados.

4. Por m, realiza-se uma busca textual sobre os dados descompactados pelas sequncias de caracteres <html e </html>.

Se a busca retornar resultado positivo,

ento considera-se que essa resposta contm uma pgina HTML.

28

Ao identicar uma resposta que contm uma pgina HTML, recupera-se a requisio
associada e reconstri-se a URL que a originou. O ltimo passo consiste em acessar essa
URL utilizando um navegador local congurado para acessar o

proxy

que foi iniciado

anteriormente.

Web, que
proxy recebe

Isso pode ser feito utilizando ferramentas de automao de navegadores


permitem controlar a grande maioria dos navegadores.

cache

a requisio, localiza em seu

Dessa forma, o

uma resposta correspondente URL requisitada e

retorna os dados capturados ao navegador local, permitindo assim a visualizao do trfego


capturado.

4.4 Melhorando a ltragem e visualizao


A visualizao correta das pginas

Web

est diretamente relacionada aos dados l-

trados que, por sua vez, correspondem aos dados que so enviados/recebidos pelo

host

monitorado.
Porm, muitas vezes, nem todos os dados necessrios para a visualizao so transmitidos, pois o protocolo HTTP prev diversos mecanismos de

caching

de recursos, como

detalhado em [39]. Essa prtica normalmente est associada aos servidores

proxy, porm

realizada tambm pela maioria dos navegadores atuais da seguinte forma:


1. Ao receber uma resposta do servidor, o navegador a armazena de acordo com informaes contidas em cabealhos especiais que conguram como deve ser feito o

caching.

2. Quando o navegador realiza uma requisio ele primeiro verica se a verso que tem
armazenada vlida (recente o suciente). Se for, ele responde a requisio com os
dados armazenados sem transmit-la ao servidor pretendido.
3. Caso o navegador no tenha condies de determinar com certeza se sua verso
vlida, ele transmite a requisio ao servidor incluindo cabealhos que caracterizam
a verso que est no

cache.

4. O servidor, por sua vez, realiza suas prprias vericaes analisando os cabealhos
enviados na requisio e retransmite a resposta se conseguir determinar que a cpia
armazenada do recurso no vlida ou caso no consiga determinar sua validade.
Os cabealhos que tornam possvel o

caching

podem ser agrupados em cabealhos que

so enviados em mensagens de requisio e aqueles enviados em mensagens de resposta.

Cabealhos de requisio:

 If-Modied-Since :

especica uma data que ser utilizada para vericar se a

verso de um recurso a mais recente. Se existir, no servidor, uma verso com


data de modicao mais recente que a data especicada, sabe-se que o recurso
armazenado est desatualizado.

 If-None-Match :

permite vericar se um recurso recente de acordo com

especiais denidas pelo servidor. A resposta do servidor contm uma


ca armazenada no
valor da

tag

cache.

tag

tags
que

Dessa maneira, ao realizar uma nova requisio o

recuperado e enviado como valor deste cabealho.

29

Tabela 4.3: Possveis valores do cabealho

Valor

no-store
no-cache

Cache-Control

Descrio
indica que uma cpia da resposta no dever ser armazenada.
indica ao gerenciador do

cache

que ele no deve servir uma cpia desta

resposta sem antes vericar com o servidor de origem se existe uma verso
mais recente. (este cabealho com esse valor pode ser usado tambm em

max-age

requisies).
dene um perodo como um nmero de segundos a partir da data de envio
da resposta dentro do qual o documento ainda ser considerado vlido.

Cabealhos de resposta:

 Expires :

dene uma data a partir da qual aquela resposta estar desatualizada

cache.
caching

e portanto no pode mais ser servida do

 Cache-control :

especica a poltica de

determinada pelo servidor. A

Tabela 4.3 apresenta os possveis valores.

 Pragma :

este cabealho denido no protocolo HTTP/1.0 e utilizado nas

verses mais novas para permitir


valor

no-cache

backwards compatibility. Normalmente tem o


Cache-control: no-cache.

cuja funo a mesma do cabealho

Apesar de melhorar o tempo de resposta de pginas

Web

tornando a interao com

usurio mais uida, esse esquema constitui um obstculo para a realizao do monitoramento proposto por esse trabalho, pois arquivos presentes no
provavelmente no estaro no

host

cache

do

host

monitorado

que monitora.

Levando isso em considerao, percebeu-se que seria preciso alterar as requisies e


respostas enviadas/recebidas pela mquina monitorada para contornar esse problema, da
seguinte maneira:
1. Remover todos os cabealhos

If-Modied-Since

If-None-Match

presentes nas re-

quisies enviadas.
2. Adicionar/alterar os cabealhos

no-cache

Cache-Control e Pragma

com os valores

no-store

respectivamente.

Expires congurando a data de expirao para uma


 Fri, 01 Jan 1990 00:00:00 GMT .

3. Adicionar/alterar o cabealho
data antiga:

Para isso, foi preciso mudar a abordagem de ltragem, tendo em vista que apesar de
simples ela torna muito difcil a realizao das manipulaes necessrias.
A soluo encontrada foi adicionar outro servidor

proxy

com o objetivo de intermediar

todas as conexes do navegador da mquina sendo monitorada.


redirecionar o trfego da mquina alvo para o

proxy

Para tal seria preciso

local da mquina que a monitora.

No entanto, a ferramenta utilizada at ento para analisar/ltrar o trfego era uma


ferramenta de captura de pacotes apenas, e esse tipo de ferramenta normalmente apenas
copia os dados dos pacotes sem alterar seu contedo nem sua direo.

30

(a) Alterao de um pacote com destino a um

host

externo

(b) Alterao de um pacote com destino ao roteador


Figura 4.6: Etapas do processo de NAT

Portanto foi preciso encontrar uma ferramenta que possibilitasse esse tipo de manipulao e elaborar um esquema de redirecionamento.

O esquema elaborado teve como

Network Address Translation ) [18].

inspirao o princpio de funcionamento do NAT (

O NAT um processo comumente implementado por roteadores cujo objetivo permitir que diferentes mquinas de uma mesma sub-rede conectem-se internet utilizando
um nico endereo IP. O processo consiste em alterar os dados de pacotes TCP/IP que
trafegam em duas direes como mostram as Figuras 4.6a e 4.6b:
1. De um

host

interno a um

host

externo: como todos pacotes com destino fora de

uma sub-rede so encaminhados ao roteador, ao receber um pacote desse tipo, o


roteador altera o endereo de IP e o nmero da porta de origem, trocando essas
duas informaes pelo seu prprio endereo e uma porta arbitrria.
Em seguida, ele armazena, em uma tabela, o IP de origem e nmero de porta
originais, associando esses dados ao nmero de porta escolhido e o IP de destino.
Por m ele encaminha o pacote ao destinatrio pretendido.
2. De um

host

externo ao roteador: ao receber um pacote de um

ador verica se ele deve ser encaminhado a um

host

host

externo, o rote-

interno consultando o endereo

IP de origem do pacote e o nmero de porta de destino em sua tabela.


Dessa maneira, se existir uma entrada correspondente na tabela ele sabe que o
pacote recebido deve ser encaminhado. Nesse caso, ele desfaz as alteraes feitas na
primeira etapa, isto troca o IP e nmero de porta de origem por aqueles presentes
na tabela.
A tcnica implementada consiste, primeiramente, em ltrar todos os pacotes que tenham nmero de porta de destino 80 e IP de destino fora da sub-rede local. Esses pacotes
tm o IP de destino trocados para o IP da mquina que realiza o monitoramento e o
nmero de porta de destino trocada pelo nmero da porta na qual o servidor

proxy

foi

congurado.
Assim como no NAT, os dados alterados foram colocados em uma tabela para permitir
a alterao dos pacotes que seguem o caminho inverso. Esse processo por sua vez consiste

31

em trocar o nmero da porta de origem para 80 e o IP de origem para o IP externo


sub-rede local.
Dessa maneira, o

proxy

passou a ter controle sobre todas as requisies que so envi-

host alvo. Assim tornou-se possvel desabilitar


cache indesejadas, melhorando a visualizao dos dados interceptados
pelo navegador Web da host que realiza o monitoramento.

adas e todas as respostas recebidas pelo


as conguraes de

4.5 Protocolo HTTPS


Como mostrado at esse ponto, o protocolo HTTP est vulnervel a ataques do tipo

man-in-the-middle, o que permite capturar, visualizar e alterar todos os dados transmitidos em transaes HTTP.

Hypertext Transfer Protocol Secure ) tornar o pro-

O objetivo do protocolo HTTPS (

tocolo HTTP seguro, de maneira que ele possa ser utilizado para realizar transaes
importantes como operaes bancrias ou armazenamento de arquivos condenciais.
Para alcanar esse objetivo, ele prev a adico de uma camada de transporte segura
acima do protocolo TCP, encapsulando assim o protocolo HTTP. Essa camada faz uso
de tcnicas de criptograa que buscam garantir que as mensagens enviadas so abertas
apenas pelos destinatrios pretendidos, bem como prover mecanismos para comprovar a
autenticidade de servidores.
Essas tcnicas so denidas pelo protocolos SSL/TLS (

Layer Security ).

Secure Sockets Layer/Transport

Apesar de no ser o foco deste trabalho, um estudo geral sobre cripto-

graa e SSL foi realizado, conforme apresentado no apndice A.


A idia central do protocolo HTTPS simples:

primeiramente, cliente e servidor

trocam mensagens para estabelecer parmetros do protocolo SSL. Uma vez estabelecida
uma conexo SSL (comumente chamada de conexo segura), ambas as partes podem
enviar mensagens HTTP normalmente.
O uso do protocolo HTTPS opcional e determinado pelo prexo da URL de um
recurso.

Como explicado na seo 4.1.3, para transmitir mensagens HTTP preciso

primeiro estabelecer uma conexo TCP utilizando a porta 80 como padro.


anloga, o protocolo HTTPS est associado porta 443.

De forma

Essa distino de portas

feita para evitar que os servidores HTTP tentassem interpretar mensagens SSL como
mensagens HTTP, ocasionando assim um comportamento errneo.
Uma prtica muito utilizada que vem perdendo sua popularidade consiste em utilizar o
protocolo HTTPS apenas para transaes que envolvem recursos que exigem uma conexo
segura. Esse modelo faz sentido, pois estabelecer uma conexo SSL um processo muito
mais oneroso que estabelecer uma conexo TCP comum.
No entanto, essa prtica aliada ampla utilizao do protocolo HTTP acabam contribuindo para a exposio dos servidores
SSL

Stripping

Web

e seus usurios tcnica conhecida como

[25, 13]. Para entender essa tcnica, primeiro preciso entender o compor-

tamento dos servidores

Web

quando um cliente solicita, atravs de uma conexo comum,

um recurso que exige uma conexo segura:


1. O cliente conecta-se ao servidor na porta 80 e envia uma requisio HTTP ao servidor.

32

Figura 4.7: Redirecionamento da requisio de um recurso que exige uma conexo segura

2. O servidor verica que o recurso solicitado s pode ser transmitido por meio de uma
conexo segura. Dessa forma, ele envia uma mensagem de redirecionamento (cdigo
de

status

301 ou 302) adicionando a URL que o cliente dever acessar para obter o

recurso no cabealho denominado

Location.

3. O cliente recebe a resposta, analisa a URL presente no cabealho

Location

e com

base nela inicia uma conexo SSL.


A Figura 4.7 ilustra o processo, enquanto a Figura 4.8 apresenta como esse comportamento pode ser reconhecido e explorado por um servidor
1. O cliente conecta-se ao
2. A requisio chega ao

proxy

malicioso:

proxy na porta 80 e envia uma requisio HTTP ao servidor.

proxy, que a encaminha para o servidor pretendido.

3. O servidor verica que o recurso solicitado requer uma conexo segura e envia a
mensagem de redirecionamento ao
4. O

proxy

proxy.

detecta que recebeu uma mensagem de redirecionamento para uma URL

cujo protocolo HTTPS. Em seguida, ele estabelece uma conexo SSL legtima com
o servidor e reenvia a requisio HTTP.
5. O servidor agora recebe uma requisio por meio de uma conexo SSL e envia uma
resposta com o recurso solicitado.
6. O

proxy

repassa a resposta com o recurso ao cliente.

7. O cliente recebe a resposta.


importante notar que o
parmetros

host

proxy

somente deve estabelecer a conexo SSL quando os

e URI da URL da requisio e do redirecionamento do servidor forem

iguais, caso contrrio o

proxy

deve repassar a mensagem de direcionamento. Isso deve ser

feito para que o cliente exiba a URL mais prxima da URL relacionada ao recurso sendo
retornado.

http://mail.google.com gera um redirecionahttps://accounts.google.com. Supondo que o cliente nessa situao

Por exemplo: a requisio para a URL


mento para a URL

seja um navegador, caso o redirecionamento no seja transmitido, navegador ir exibir o


contedo relacionado segunda URL, porm a URL que constar na barra de endereos
ser a primeira, o que pode levar um usurio perceptivo a desconar que algo est errado.

33

(a) Envio da requisio original do cliente e obteno de uma resposta de redirecionamento

(b) Estabelecimento de uma conexo SSL e repasse da resposta obtida ao cliente


Figura 4.8: Redirecionamento intermediado por um servidor

proxy

malicioso

Conforme dito anteriormente, esta tcnica est centrada no fato de que a navegao de um usurio na

Internet

normalmente comea com pginas HTTP, at mesmo

porque a maioria dos usurios escrevem site.com na barra de endereos, ao invs de


http://site.com ou https://site.com.
Alm disso, para que ela seja bem sucedida, preciso tambm alterar o contedo das
pginas HTML servidas pelo

proxy,

pois elas podem conter

links

com URLs de destino

que possuem o protocolo HTTPS especicado.


Por m, caso a pgina servida tenha sido originada de uma conexo SSL, preciso
vericar as URLs de todos os recursos referenciados por ela, pois elas podem ser relativas
URL do recurso pricipal.

Como a URL do recurso principal se encontra alterada do

ponto de vista do cliente, esses recursos somente sero carregados corretamente caso suas
URLs sejam transformadas de relativas em absolutas levando em considerao a URL
original (cujo prexo

https:// ).

relativas relacionadas ao recurso


O SSL

Stripping

A Tabela 4.4 apresenta como devem ser tratadas URLs

https://paypal.com/main.

consegue burlar o propsito do protocolo HTTPS de uma maneira

simples e elegante. Apesar de existirem outras tcnicas que cumprem o mesmo objetivo, o
SSL

Stripping

uma das tcnicas que possui maior ndice de sucesso, conforme mostrado

em [13]. No entanto, como todas as outras tcnicas, possui um conjunto de limitaes:


1. Um usurio perspicaz pode perceber que o seu navegador no apresenta os sinais de
que foi estabelecida uma conexo segura ao acessar um site que frequenta periodicamente, percebendo, assim, que est sendo vtima de um ataque.

34

Tabela

4.4:

Resultado

https://paypal.com/main

do

tratamento

URL

de

URLs

relativas

relacionadas

ao

recurso

Resultado

//paypal2.com/main https://paypal2.com/main
/menu/options
https://paypal.com/menu/options
video.wmv
https://paypal.com/video.wmv

2. A quantidade de pessoas que digitam o endereo dos sites vem diminuindo pois os
navegadores buscam cada vez mais facilitar o acesso e congurao de atalhos para
abrir as URLs mais frequentadas.
3. Alguns navegadores

Web

esto programados para preferir a verso que especica

o protocolo HTTPS de URLs presentes no histrico.

Dessa forma, se a URL

https://site.com estiver presente no histrico, quando o usurio tentar acessar site.com


o navegador automaticamente assume o protocolo HTTPS no o HTTP.
4. Diversas formas de deteco e preveno do SSL
descrito em [30, 27, 44].

35

Stripping j foram elaboradas como

Captulo 5
Desenvolvimento do Webspy
O

Webspy

foi concebido e desenvolvido utilizando as linguagens de programao C

e C# com foco voltado exclusivamente para o Sistema Operacional


testado em sua maior parte nas verses

Windows

7 e 8.

Windows.

Ele foi

O modelo de interface com o

usurio adotado foi o de linha de comando devido simplicidade de implementao.


Desde o princpio, sabia-se que o

Webspy

iria precisar de diversas ferramentas para

cumprir seus objetivos e que nem todas estariam disponveis em uma linguagem de programao apenas. Por isso foi adotado um modelo de desenvolvimento em mdulos composto
de 5 etapas:
1. Diviso das funcionalidades propostas em mdulos.
2. Implementao de cada mdulo utilizando a linguagem mais conveniente.
3. Realizao de testes em cada um dos mdulos separadamente.
4. Integrao dos mdulos.
5. Realizao de testes de integrao.
Dessa forma, foram denidos 4 mdulos:
1. Mdulo de Varredura.
2. Mdulo de ARP

Spoong.

3. Mdulo de Visualizao de pginas HTML.


4. Mdulo de

Playback.

As Sees de 5.1 a 5.4 apresentam as funcionalidades de cada mdulo, bem como


detalhes e decises de implementao, enquanto que a Seo 5.5 discute a integrao
entre os mdulos e os resultados obtidos.

5.1 Mdulo de Varredura


O mdulo de varredura tem o objetivo de exibir ao usurio todos os dispositivos que
se encontram em uma rede, utilizando as tcnicas de Ping

sweep e ARP

sweep descritas

no captulo 3. Esse mdulo foi desenvolvido com a linguagem C utilizando as bibliotecas

WinPcap

[9] e

libnet

[5] para captura e injeo de pacotes respectivamente.

36

5.1.1

Desenvolvimento

A inspirao inicial veio do programa Ping, que consiste em enviar uma requisio
ICMP, escutar um determinado tempo por uma uma resposta e repetir o processo 4
vezes.
O primeiro prottipo desenvolvido implementava o Ping

sweep.

Ele identicava pri-

meiramente seu prprio endereo IP e, assumindo que se encontra em uma rede de classe
C, iniciava o processo de envio de requisies para endereos IP com

hostid

de 1 a 254.

Esse processo consistia em enviar uma requisio ICMP e esperar 3 segundos por uma
resposta. Caso a resposta fosse detectada, o endereo IP de origem era exibido o IP era
marcado como conectado.
Essa abordagem, apesar de ecaz, era muito ineciente, tendo em vista que era preciso
esperar por um determinado tempo uma resposta e s ento enviar uma requisio para
o prximo IP.
Dessa forma, na segunda verso do prottipo, vericou-se que era possvel melhorar o

threads : uma thread que injetava


pacotes ICMP para todos os possveis hosts da rede e outra thread que apenas escutava
desempenho fazendo com que o programa tivesse duas

as respostas. Assim foi possvel tornar a varredura muito mais eciente.


Inicialmente pensou-se em exibir apenas os endereos IP e MAC dos

hosts descobertos,

porm percebeu-se que essa informao somente no era de muita ajuda, pois nem sempre
conhecido o IP do dispositivo que se quer monitorar.
Para resolver esse problema foi utilizada a API de

Sockets

do

Windows, que permite

recuperar um nome associado a um IP. Normalmente esse nome o nome dado ao dispositivo durante a instalao de seu Sistema Operacional (que costuma seguir o padro
NomeDono-PC ou NomeDono-Note).

No entanto, essa informao no est disponvel

para todos os dispositivos (nesse caso o endereo IP exibido novamente).


O prottipo que implementa o ARP
do Ping

5.1.2

Sweep

seguiu a mesma arquitetura do prottipo

Sweep, porm utilizando mensagens do protocolo ARP.


Resultado

Ambos prottipos possuem apenas um parmetro de entrada: o nome da interface


na qual deve ser realizada a varredura. Caso esse parmetro no seja informado (ou se
no for encontrada nenhuma interface com nome correspondente) ele exibe um menu que
lista as interfaces encontradas, permitindo assim que o usurio escolha uma, como mostra
a Figura 5.1. As Figuras 5.2a e 5.2b apresentam a sada da ltima verso dos prtipos
implementados.

5.2 Mdulo de ARP Spoong


O mdulo de Arp

Spoong

tem o objetivo de implementar a tcnica descrita na Se-

o 3.4 de forma que o trfego de rede um determinado

host

de uma rede possa ser

interceptado. Ele foi desenvolvido utilizando as mesmas ferramentas de captura e injeo


de pacotes utilizadas no mdulo de varredura.

37

Figura 5.1: Menu de seleo de interface

(a) Sada do Ping

Sweeper

(b) Sada do ARP

Sweeper

Figura 5.2: Sadas dos prottipos que implementam ARP e Ping

38

sweep

5.2.1

Desenvolvimento

O prottipo inicial consistia em uma aplicao com duas


encarregada de fazer o ARP

Poison

threads :

a primeira era

com um intervalo xo de 1 segundo, e a segunda, de

escutar os pacotes e realizar o encaminhamento (

Relay ).

Os testes deste mdulo consistiam em conectar duas mquinas a um roteador por


meio de cabos. Em seguida iniciava-se o prottipo em uma das mquinas enquanto, na
outra, abria-se um navegador

Web.

Por m, vericava-se o tempo de resposta para que o

navegador visualizasse determinadas pginas da

Web.

O desempenho do primeiro prottipo foi muito baixo, e, durante os testes, percebeu-se


que a velocidade da conexo da vtima caa drasticamente: a visualizao de uma pgina

Google demorava cerca


timeout de conexo.

simples como a do
apresentavam um

de 10 segundos e pginas mais complexas

Dessa maneira, decidiu-se fazer uma segunda verso do prottipo, na qual cada

thread

foi separada em um nico processo, porm o desempenho nao melhorou. O ltimo prottipo criado adotou outra abordagem: ele concetrava-se em realizar apenas o ARP
e, para realizar o

Poison

Relay, foi congurada a opo IPEnableRouter do Windows.


Windows roteie pacotes recebidos por ele cujo IP de

Essa congurao permite que o

destino no o seu. Esta verso apresentou desempenho satisfatrio de maneira que no


era perceptvel nenhuma alterao drstica na conexo da vtima.
Esse resultado levou a acreditar que havia algo errado na implementao do

Relay

das

verses anteriores ou ento que as ferramentas utilizadas tinham baixo desempenho.


Enquanto pensava-se sobre o assunto, decidiu-se experimentar ferramentas prontas de
ARP

Spoong

disponveis na

Internet.

Algumas ferramentas foram testadas sem muito

sucesso (vrias delas dispararam o alerta de vrus do anti-vrus


trada uma denominada APE (ARP

Poison Engine ) [42].

Avira ) at que foi encon-

Essa ferramenta, alm de ter o melhor desempenho observado, apresentava um sistema

log organizado, o que permitiu acompanhar todos os passos realizados pela ferramenta,
Dessa maneira vericou-se que o Relay era feito utilizando
uma ferramenta de administrao do Windows chamada netsh.
Esse ferramenta era utilizada para o congurar o uso do NDP (Neighbor Discovery
Protocol ) [37]. Esse protocolo est, na verdade, associado verso 6 do protocolo IP
(porm funciona tambm com a verso 4) e permite que hosts se comuniquem e troquem
de

como mostra a Figura 5.3.

pacotes a nvel de camada 2 (o que justica o desempenho observado).


Mais tarde descobriu-se que o problema de desempenho dos primeiros prottipos estava
associada a um parmetro de

timeout de leitura da biblioteca WinPcap.

Uma vez reduzido

o valor desse parmetro ao mnimo, o desempenho equiparou-se do prottipo que usava


a opo

5.2.2

IPEnableRouter

para realizar o

Relay.

Resultado

Todos os prottipos implementados recebem, como entrada, o nome da interface (parmetro opcional) e o IP da vtima e, como sada, exibem o nmero de iteraes do ARP

Poison

a cada segundo. O prottipo que faz

Relay

exibe tambm a direo dos pacotes

encaminhados utilizando a letra R para representar o roteador e V, para a vtima como


mostra a Figura 5.4.
duas

threads.

A verso nal implementada adotou o modelo inicial que utiliza

39

Figura 5.3: Ferramenta APE (ARP

Poison Engine )

Figura 5.4: Prtipo implementado que realiza ARP

40

Poison e Relay

5.3 Mdulo de visualizao de pginas HTML


O mdulo de visualizao tem o objetivo de permitir que o usurio possa visualizar,
em seu navegador local, as pginas

Web

presentes no trfego de rede interceptado. Esse

mdulo foi desenvolvido em C# e constituiu o maior desao de implementao. Foram


construdas duas verses que correspondem s duas abordagens de ltragem e visualizao
apresentadas no captulo 4. A diviso foi necessria pois as verses exigiam arquiteturas
diferentes.

5.3.1

Primeira verso

A primeira verso implementa a idia mais simples de ltragem de trfego

Web.

Ape-

sar da idia ser simples, a implementao foi muito trabalhosa por tratar a questo da
ltragem a nvel de pacotes. Essa verso utilizou as seguintes bibliotecas:
1.

PcapDotNet

[2]:

wrapper

WinPcap

para C# da biblioteca

que permitiu a captura

dos pacotes interceptados.


2.

TrotiNet

[6]:

permitiu implementar servidores

proxy

HTTP com simplicidade e

exibilidade.
3.

Selenium

[3]: permitiu controlar navegadores

Web

atuais.

Desenvolvimento
Inicialmente deniu-se uma arquitetura que permitesse a implementao da abordagem proposta, como mostra a Figura 5.5. O primeiro passo consistiu em inicializar um
servidor

proxy

che local.

programado para responder requisies com respostas contidas em um

ca-

proxy foi implementado de maneira que, caso a resposta de uma requisio


no estivesse presente no cache ele transmitiria a requisio ao servidor pretendido e, em
Esse

seguida, retornaria a resposta obtida.


Uma vez congurado o

proxy (Browser Proxy ), os pacotes foram capturados e ltraram-

se aqueles que possuam: a porta de nmero 80 do protocolo TCP especicada, o endereo


IP da vtima do

ARP Spoong

e o endereo MAC de destino do

host

que faz o

Spoong

(para remover duplicatas como discutido na seo 4.2).


Em seguida, os pacotes foram separados em uxos, que representam uma conexo
TCP e, portanto, so diferenciados por um endereo IP e um nmero de porta TCP.
Um uxo contm todos os pacotes relativos a uma transao HTTP, sendo que um uxo
pode ter diversas transaes. Os uxos e suas transaes foram construdos ltrando-se
primeiramente apenas os pacotes cujo

payload

TCP era maior que zero.

Em seguida,

seguiu-se o seguinte processo:


1. Se for detectado um pacote com o endereo IP de destino diferente do IP da vtima:
(a) Converte-se os

bytes

do

payload

TCP em uma

string

e verica-se se ela pode

ser dividida em linhas.


(b) Se puder, verica-se se a primeira linha uma linha de requisio HTTP vlida.

41

Figura 5.5: Arquitetura da implementao da primeira abordagem de ltragem

42

(c) Se for, verica-se se j existe um uxo com o endereo IP de destino e nmero


de porta de origem correspondente aos do pacote.
(d) Se existir, cria-se uma nova transao adicionando a requisio HTTP encontrada.
(e) Se no existir, cria-se um novo uxo e, em seguida, a nova transao com a
requisio encontrada.
(f ) Por m, marca-se a transao adicionada como a transao atual para aquele
uxo.
2. Se for detectado um pacote com o endereo IP de destino igual ao da vtima:
(a) Procura-se um uxo que tenha IP e nmero de porta iguais ao endereo IP de
origem e nmero da porta de destino do pacote respectivamente.
(b) Se existir, adiciona-se o pacote transao atual do uxo.
(c) Se no existir uxo ou se o uxo encontrado no possuir uma transao marcada como atual, o pacote descartado.
O prximo passo (implementado pelo componente chamado

Reassembler )

consistiu

em analisar cada transao de cada um dos uxos para vercar se foram coletados todos
os pacotes que continham uma resposta HTTP. Esses pacotes continham segmentos TCP
cuja ordem foi vericada para que fossem remontados. Isso foi feito porque a ferramenta
de captura no garante que a ordem de entrega ser mantida.
Uma vez remontada uma resposta HTTP, a transao considerada completa e
enviada ao

cache

do servidor

proxy.

cache

foi implementado como uma tabela

hash

de

transaes, que so indexadas pela URL relativa requisio da transao.

Alm disso, a resposta HTTP enviada tambm ao gerenciador do navegador Web


Browser Manager ). Esse componente mantm uma tabela hash de instncias de um
navegador Web conguradas para utilizar o Browser Proxy e indexada pelo host da

URL sendo visualizada. Cada instncia corresponde a uma janela do navegador.


Dessa forma, ao receber uma resposta HTTP, o

Browser Manager

a analisava para

vericar se continha uma pgina HTML. Se essa condio fosse vericada, era recuperada
a URL da requisio correspondente resposta. Em seguida, o componente vericava se j
existia uma instncia do navegador

Web escolhido associada ao host

da URL recuperada.

Se existisse, a instncia era recuperada, caso contrrio era criada uma nova. Por m,
era transmitido um comando para que a instncia acessasse a URL.

Chrome e Firefox. Foi escolhido o Firefox, pois para


Chrome era preciso utilizar um aplicativo denominado

Foram testados dois navegadores:


estabelecer uma conexo com o

ChromeDriver

que apresentava um comportamento instvel quando as janelas do navega-

dor era fechadas pelo usurio. Por sua vez, o

Firefox

no necessitava de nenhum recurso

adicional e mostrou-se mais estvel.


Para que fosse possvel desempenhar todas as funes descritas de maneira eciente, foi
preciso tornar o prottipo
1.

Thread

multi-thread.

de escuta de pacotes:

Sendo assim, foram denidas 3

threads principais:

responsvel por escutar os pacotes e construir os

uxos.

43

2.

Thread

de remontagem: responsvel pela remontagem dos segmentos TCP das res-

postas, organizao das transaes HTTP, armazenamento de transaes no


e envio de respostas ao
3.

Thread

Browser Manager.

proxy : responsvel
servidor proxy que, por

do servidor

manuteno do

cache

por realizar as funes de organizao e


sua vez, gera uma nova

thread

para cada

requisio recebida.
Alm disso, para melhorar o tempo de resposta do prottipo, o

Browser Manager

foi

implementado de maneira a gerar uma nova thread a cada resposta HTTP recebida.
Os testes utilizaram a ferramenta APE (pois ela tinha o melhor desempenho observado
at ento) e foram conduzidos da mesma maneira que no mdulo de ARP
Testes inciais revelaram a necessidade de implementar mecanismos de
envolvia um processo com muitas etapas e o fato de ser

log, pois o prottipo

multi-thread tornava-o muito difcil

de depurar utilizando depuradores convencionais.


A implementao de um sistema de

log

Spoong.

permitiu detectar erros e

bugs

com mais

facilidade, alm de tornar possvel a identicao de pontos de melhoria, como a utilizao


de

timeouts

cache.
logs percebeu-se

ao acessar o

Analisando-se os

que o navegador local podia realizar requisies

HTTP com maior velocidade que a velocidade de remontagem das respostas correspondentes.

Para resolver o problema: elaborou-se um esquema de

no fosse encontrada uma resposta no

cache, o proxy

timeouts

no qual, caso

aguardava um tempo determinado

e tentava novamente, repetindo o processo um determinado nmero de vezes.

Resultado
Finalizada a implementao, foram detectadas as limitaes dessa verso: algumas
pginas HTML apresentaram problemas de visualizao em funo do

caching de recursos

pelo navegador da vtima. Alm disso, pginas transmitidas com o protocolo HTTPS no
foram exibidas no navegador da mquina que realizou o monitoramento.

5.3.2

Segunda verso

A motivao para a implementao da segunda verso veio das limitaes encontradas


na verso anterior.

Dessa forma, esta verso foi elaborada desde o comeo com o foco

em resolver os problemas levantados, implementando assim, a segunda abordagem de

Web. Foram reutilizadas


PcapDotNet foi substituda pela

TrotiNet e Selenium, ao
WinpkFilter [8] que permitiu

ltragem de trfego

as ferramentas

passo que a

biblioteca

redirecionamento e manipualao de pacotes.

HtmlAgilityPack

Alm disso foi adicionada a biblioteca

[1] para anlise e formatao de contedo HTML.

Desenvolvimento
O primeiro passo consistiu em trocar a abordagem de captura de pacotes pela abordagem de redirecionamento de pacotes. Inicialmente imaginou-se que uma ferramenta que
zesse NAT poderia ser congurada para realizar as manipulaes propostas na seo 4.4.

44

Sendo assim, iniciou-se uma busca por ferramentas capazes de realizar NAT, porm foram encontrados poucas alternativas que fossem compatveis com o

Windows.

Alm disso,

nenhuma das ferramentas encontradas apresentava as opes de congurao necessrias.


Chegou-se a considerar a utilizao de simuladores de roteadores, porm essa hiptese
foi descartada porque seria muito difcil fazer isso de maneira automatizada, alm de
complicar demasiadamente as conguraes necessrias para instalao e uso do

Webspy.

Em seguida, buscou-se bibliotecas que se especializassem no redirecionamento de pacotes e estivessem disponveis para
e a

WinpkFilter.

Windows.

Primeiramente testou-se a biblioteca

Foram encontradas duas: a

WinDivert.

WinDivert

[7]

Foi construdo um prottipo para

vericar se a biblioteca era capaz de alterar e encaminhar pacotes como esperado. Esse
prottipo foi inicialmente programado para redirecionar quaisquer pacotes recebidos em
uma interface. Os testes desse prottipo foram bem sucedidos e o prottipo funcionou
como esperado. Em seguida, alterou-se o prottipo para encaminhar os pacotes obtidos
pelo ARP

Spoong.

No entanto, quando testado com o trfego interceptado, o prottipo no foi capaz


de encaminhar os pacotes alterados. O autor da biblioteca foi contatado, porm ele no
conseguiu descobrir porque o prottipo no funcionava, pois, aparentemente, o cdigo
desenvolvido estava correto.
Sendo assim, decidiu-se inciar os testes com a segunda biblioteca descoberta. O

Winpk-

Filter, diferentemente da ferramenta anterior, possua bibliotecas desenvolvidas para C#


o que facilitou o processo de desenvolvimento de um prottipo inicial.
Esse prottipo reaproveitou muito do cdigo desenvolvido para a biblioteca

WinDivert,

porm, como as bibliotecas possuam APIs muito distintas, ainda foi preciso escrever uma
quantidade signicativa de cdigo adicional. O perodo de testes e desenvolvimento desse
prottipo foi muito maior que o da

WinDivert, pois a documentao era muito supercial.

Quando o prottipo cou pronto, vericou-se que o ele somente funcionava na verso
8 do

Windows.

da biblioteca, o

As causas ainda no foram descobertas, pois, de acordo com o fabricante

WinpkFilter

compatvel tambm com a verso 7 do

Windows.

Uma vez que terminado o prottipo de redirecionamento, inciaram-se as mudanas


sobre a verso anterior do mdulo de visualizao. A Figura 5.6 ilustra a arquitetura da
nova verso proposta.
As mudanas concebidas nessa verso esto baseada na introduo do componente

Redirect

WinpkFilter.
Esse componente permitiu que o trfego interceptado pelo ARP spoong pudesse ser
redirecionado a um novo um servidor proxy (denominado Man-in-the-Middle Proxy ) cuja
que corresponde ao prottipo implementado com a biblioteca

funo intermediar todas as conexes do dispositivo monitorado.


Esse

proxy tambm foi implementado com a biblioteca TrotiNet e centraliza as funes

principais dessa verso:

host
cache

1. Remover/alterar os cabealhos das mensagens HTTP recebidas e enviadas pelo


monitorado, de forma a tentar impedir que os recursos sejam armazenados no
de seu navegador.
2. Realizar o SSL

Stripping.

3. Armazenar transaes HTTP interceptadas no


es.

45

cache

e envi-las Pilha de Transa-

Figura 5.6: Arquitetura da implementao da segunda abordagem de ltragem

46

Para implementar o SSL Stripping, foram criados dois componentes: o SSL Client e o
Response Stripper.
O SSL Client responsvel por estabelecer uma conexo utilizando o protocolo SSL.
O processo de estabelecimento de uma conexo SSL no precisou ser implementados, pois
o framework .NET j disponibilizava classes que encapsulam essa funcionalidade.

No

entanto, foi preciso lidar com todo o processo de envio e recepo de mensagens HTTP
que, apesar de trabalhoso, no difcil.
Durante o processo de desenvolvimento desse componente, foi preciso realizar algumas
mudanas na biblioteca

TrotiNet.

Isso foi feito porque foi vericado que a biblioteca

no disponibilizava formas de acessar o corpo de mensagens de requisio HTTP (o que


impediu inicialmente o SSL

Client

de transmitir requisies com o mtodo POST). Alm

disso, foi detectado que, por uma falha de implementao, a biblioteca era capaz de alterar
apenas um pequeno conjunto cabealhos das mensagens HTTP. Uma vez resolvidas essas
questes o desenvolvimento do componente seguiu normalmente.
O

Response Stripper, por sua vez, responsvel por realizar modicaes em mensa-

gens HTTP, conforme descrito na seo 4.5. A abordagem elaborada inicialmente utilizava
expresses regulares para identicar e realizar alteraes de maneira eciente.
No entanto, durante a realizao de testes com pginas HTML variadas, vericou-se
que muitas apresentam contedo HTML mal formatado (porm vlido), o que dicultava
a construo de expresses regulares que funcionassem em todos os casos possveis.
Para resolver esse problema, foi utilizada a biblioteca
alizar o

parse

HtmlAgilityPack

capaz de re-

de documentos HTML e format-los corretamente. Uma fez formatados,

vericou-se que as expresses regulares eram aplicadas com sucesso.


Por m, a nova verso adicionou tambm o componente denominado Pilha de Transaes. Esse componente constituido por uma pilha que recebe todas as transaes cujas
respostas possuem um corpo e, portanto, podem conter uma pgina HTML. Os compo-

Browser Manager e Browser Proxy foram reutilizados sem alteraes signicativas.


multi-thread elaborado na verso anterior,
porm duas threads foram dedicadas aos servidores proxy enquanto a thread restante
cou responsvel por remover transaes da Pilha de Transaes e envi-las ao Browser
Manager.
nentes

Essa verso continuou seguindo o modelo

Resultado
O problema gerado pelo

caching

de recursos realizado pelo navegador do alvo do

monitoramento foi resolvido com sucesso por esta verso e no foi detectado nos testes
realizados. No entanto, a visualizao de pginas que utilizam o protocolo HTTPS no
funcionou em todos os testes, pois no houve muito tempo para o desenvolvimento do
SSL

Stripping

e, portanto, sua implementao foi bem bsica. Alm disso, essa tcnica

possui um conjunto de limitaes, conforme discutido na Seo 4.5.

5.4 Mdulo de Playback


O mdulo de

Playback

tem o objetivo de reproduzir a visualizao das pginas mo-

nitoradas de acordo com a ordem em que foram acessadas pelo alvo do monitoramento.
Esse foi o mdulo mais simples de ser implementado e tambm foi desenvolvido em C#.

47

Figura 5.7: Exemplo do esquema de armazenamento dos arquivos

PlaybackRequests.wsy
5.4.1

PlaybackCache.wsy

Desenvolvimento

Como o contedo das pginas monitoradas proveniente, em sua maior parte, do

cache

implementado no Mdulo de Visualizao, foi preciso apenas implementar uma maneira


de armazenar o

cache

em um arquivo e posteriormente reconstru-lo partir do arquivo

armazenado.
Alm de armazenar o

cache,

foi necessrio armazenar tambm as URLs enviadas ao

Web local pelo componente Browser Manager. Os arquivos foram armazenados


utilizando o padro de codicao em chunks denido na verso 1.1 do protocolo HTTP,

navegador

pois as rotinas de codicao e decodicao desse esquema j haviam sido implementadas.


A Figura 5.7 ilustra um exemplo que utiliza a estrutura proposta para o arquivo que armazena o

cache (PlaybackCache.wsy ) e o que armazena as URLs (PlaybackRequests.wsy ).


host e URI para facilitar

As URLs foram armazenadas em ambos os casos divididas em


o processo de reconstruo.

Uma vez implementado o esquema de armazenamento/reconstruo dos arquivos, foi


implementada uma rotina que recuperava o

cache

e as URLs, montava uma lista com as

URLs recuperadas e por m percorria a lista enviando cada URL ao navegador local de
acordo com um intervalo informado pelo usurio.

5.4.2

Resultado

O mdulo de

Playback

foi testado em conjunto com o mdulo de visualizao e no

apresentou nenhuma limitao. Nos testes realizados, todas as pginas


foram reproduzidas com sucesso.

48

Web

capturadas

5.5 Integrao e resultados obtidos


A ltima etapa consistiu em integrar os mdulos desenvolvidos e realizar testes de
integrao para que fosse alcanado o resultado nal: a aplicao

Webspy.

A integrao foi iniciada pelo mdulo mais complexo: o Mdulo de Visualizao. Em


seguida, adicionou-se o mdulo de ARP
o de

Playback.

Spoong,

o o mdulo de Varredura e, por m,

A integrao do mdulo de Varredura e de ARP

pois eles foram desenvolvidos como aplicaes

standalone

Spoong

foi facilitada

e no era necessrio que se

comunicassem obrigatoriamente com os demais mdulos.


Naturalmente surgiram diversos erros de integrao, porm eles foram identicados
com facilidade graas ao sistema de

log

adicionado no mdulo de Visualizao.

Em funo da segunda verso do mdulo de Visualizao somente funcionar na verso


8 do

Windows, decidiu-se separar o Webspy

em duas verses:

0.1 Realiza captura de pacotes, armazena os dados interceptados em um arquivo de

Windows

captura (.pcap) e compatvel com o

7.

Pr-requisitos: preciso ter instalado os componentes: NET Framework 4.0, o


da biblioteca

WinPcap

e o navegador

Firefox.

driver

Adicionalmente, a porta de nmero

12345 deve estar desbloqueada.


Limitaes: incapaz de monitorar/exibir pginas HTTPS e a visualizao de pginas
interceptadas pode ser afetada pelo

caching

de recursos.

0.2 Realiza redirecionamento e manipulao de pacotes, capaz de visualizar a maioria


das pginas HTTP e implementa o SSL
Pr-requisitos:

Windows

stripping.

8 com os seguintes componentes instalados:

mework 4.0, o driver da biblioteca

WinpkFilter

e o navegador

Firefox.

NET FraAdicional-

mente, as porta de nmero 12345 e 12346 devem estar desbloqueadas.


Limitaes: a implementao do SSL
o tratamento de

cookies

Stripping

realizada bsica e no abrangeu

adequado. Sendo assim, pginas que dependem de

cookies

no foram visualizadas corretamente.


Em ambas verses, os parmetros de entrada do

Webspy

podem ser congurados por

meio um arquivo de congurao que utiliza a linguagem XML como mostra a Figura 5.8.
Caso o arquivo no esteja presente, o programa exibe mensagens que coletam os dados
necessrios.
A Figura 5.9 mostra o menu da ltima verso do

Webspy na qual so exibidas 5 opes:

Sweep : inicia uma varredura de rede utilizando a tcnica ARP Sweep.


Ping Sweep : inicia uma varredura de rede utilizando a tcnica Ping Sweep.
Start Webspy : inicia o processo de ltragem e visualizao de trfego Web.
Replay saved session : inicia o processo de playback.
Exit : fecha a aplicao.

1. ARP
2.
3.
4.
5.

Por m, a Figura 5.10 apresenta o

Webspy

em funcionamento no momento que exibe

uma pgina HTTP interceptada e a Figura 5.11 exibe a comparao entre uma pgina
HTTPS e sua verso HTTP gerada aps a realizao do SSL

49

Stripping.

Figura 5.8: Arquivo de congurao do

Figura 5.9: Opes do

Figura 5.10:

Webspy
50

menu

do

Webspy

Webspy

em funcionamento

(a) Verso legtima da pgina inicial do

(b) Verso da pgina inicial do

PayPal

PayPal

aps o SSL

Stripping

Figura 5.11: Comparao entre uma pgina antes e aps a realizao do SSL
pelo

Webspy

51

Stripping

Captulo 6
Concluso
O objetivo deste trabalho discutir conceitos e teorias que permitem a construo
de uma ferramenta que utiliza a tcnica de ataque conhecida como ARP

Spoong

com

o objetivo de monitorar um dispositivo especco de uma rede, alm de implementar e


apresentar uma aplicao como prova de conceito.
Nesse aspecto, acredita-se que os objetivos foram alcanados: a ferramenta denominada

Webspy

foi implementada com sucesso e foram geradas duas verses cujas funciona-

lidades e limitaes esto descritas na seo 5.5.


Este trabalho mostra que, apesar do ARP

Spoong

ser uma tcnica amplamente co-

nhecida, continua sendo vivel utiliz-la para realizar monitoramento (assim como ataques
extremamente invasivos). Isso reete uma despreocupao e desinformao por parte dos
fabricantes de

switches

e roteadores, pois diversos mtodos de conteno e deteco desse

ataque j foram apresentados, como pode ser visto em [12, 29, 24].
A idia de utilizar ferramentas de captura de pacotes para a realizao de monitoramento tambm j foi explorada em diversas aplicaes, sendo uma das mais notveis o

Xplico [10].
O Xplico uma ferramenta Open Source

com o foco voltado anlise forense de rede,

que possui a funcionalidade de reconstruo de uma pgina

Web a partir de um arquivo de

captura de pacotes. A Figura 6.1 ilustra como essa ferramenta organiza os dados obtidos
de uma captura.
O

Xplico

Webspy

complementa as funcionalidades apresentadas por ferramentas como o

e inova pela sua forma de visualizao do trfego monitorado em tempo real e

pelo uso de uma ferramenta de automao de navegadores

Web, que permite prover uma

experincia de monitoramento que se assemelha experincia real do usurio monitorado.


Como trabalhos futuros, pode-se citar: desenvolvimento de uma verso da aplicao
voltada para sistemas

Linux, a realizao de um estudo aprofundado do SSL Stripping

a implementao de outras tcnicas que permitem contornar o protocolo HTTPS.

52

Figura 6.1:

Visualizao dos dados de uma captura pela ferramenta

de [10]

53

Xplico

- retirada

Referncias
[1] Html Agility Pack. Disponvel em http://htmlagilitypack.codeplex.com/, Acessado
em: julho de 2013. 44
[2] Pcap.Net. Disponvel em http://pcapdotnet.codeplex.com/, Acessado em: julho de
2013. 41
[3] Selenium - Web Browser Automation. Disponvel em http://docs.seleniumhq.org/,
Acessado em: julho de 2013. 41
[4] TCPDUMP/LIBPCAP public repository. Disponvel em http://www.tcpdump.org/,
Acessado em: julho de 2013. 28
[5] The

Libnet

Packet

Construction

Library.

Disponvel

em

http://packetfactory.openwall.net/projects/libnet/, Acessado em: julho de 2013. 36


[6] TrotiNet: a C# HTTP proxy library. Disponvel em http://trotinet.sourceforge.net/,
Acessado em: julho de 2013. 41
[7] WinDivert

1.0:

Windows

Packet

Divert.

Disponvel

em

http://reqrypt.org/windivert.html, Acessado em: julho de 2013. 45


[8] Windows Packet Filter Kit. Disponvel em http://www.ntkernel.com/, Acessado em:
julho de 2013. 44
[9] WinPcap:

The

industry-standard

windows

packet

library.

Disponvel

em

http://www.winpcap.org/, Acessado em: julho de 2013. 36


[10] Xplico - Open Source Network Forensic Analysis Tool (NFAT).

Disponvel em

http://www.xplico.org/, Acessado em: julho de 2013. vii, 52, 53


[11] Hayriye Altunbasak, Sven Krasser, Henry Owen, Joachim Sokol, and Jochen Grimminger.

Addressing the weak link between layer 2 and layer 3 in the Internet ar-

chitecture. In Local Computer Networks, 2004. 29th Annual IEEE International


Conference on, pages 417  418, nov. 2004. 16
[12] M. Carnut and J. Gondim. ARP spoong detection on switched Ethernet networks:
A feasibility study. In

Proceedings of the 5th Symposium on Security in Informatics,

2003. 16, 21, 52

54

[13] Kefei Cheng, Meng Gao, and Ruijie Guo. Analysis and Research on HTTPS Hijacking

Proceedings of the 2010 Second International Conference on Networks


Security, Wireless Communications and Trusted Computing - Volume 02, NSWCTC

Attacks. In

'10, pages 223226, Washington, DC, USA, 2010. IEEE Computer Society. 32, 34
[14] Tamara Dean.

Network+ Guide to Networks. Course Technology Press, Boston, MA,

United States, 5th edition, 2009. 8


[15] University of Delaware Dept. of Electrical Engineering. Standard for the format of
Arpa Internet Text Messages, August 1982. RFC 822. 22
[16] Gary Donahue.

Network Warrior.

O'Reilly Media, Inc., 2007. vi, 8

[17] Jiang Du, Xinghui Li, and Hua Huang. A Study of Man-in-the-Middle Attack Based

Proceedings of the 2011 First International Conference on Instrumentation, Measurement, Computer, Communication and Control,

on SSL Certicate Interaction. In

IMCCC '11, pages 445448, Washington, DC, USA, 2011. IEEE Computer Society.
2
[18] Francis P. Egevang K. The IP Network Address Translator (NAT), May 1994. RFC
1631. 31
[19] Roy Fielding. Hypertext Transfer Protocol  HTTP/1.1, June 1999. RFC 2616. 28
[20] C. Horning.

A Standard for the Transmission of IP Datagrams over Ethernet

Networks, April 1984. RFC 894. vi, 11


[21] University of Southern California Information Sciences Institute. Internet Protocol :
Darpa Internet Program Protocol Specication, September 1981. RFC 791. vi, 13
[22] Yogesh Joshi, Debabrata Das, and Subir Saha. Mitigating man in the middle attack

Proceedings of the 3rd IEEE international conference


on Internet multimedia services architecture and applications, IMSAA'09, pages 188
over secure sockets layer. In

192, Piscataway, NJ, USA, 2009. IEEE Press. 2


[23] James F. Kurose and Keith W. Ross.

Computer Networking: A Top-Down Approach.

Addison-Wesley Publishing Company, USA, 5th edition, 2009. 1


[24] Yang Liu, Kaikun Dong, Lan Dong, and Bin Li.
principle and a defensive algorithm.

Research of the ARP spoong

WTOC, 7(5):413417, May 2008.

[25] M. Marlingspike. New Tricks For Defeating SSL in Practice. In

16, 52

BlackHat Conference,

2009. 32
[26] Robert M. Metcalfe and David R. Boggs. Ethernet: distributed packet switching for
local computer networks.

Commun. ACM, 19(7):395404, July 1976.

[27] Nick Nikiforakis, Yves Younan, and Wouter Joosen. HProxy: client-side detection of

Proceedings of the 7th international conference on Detection


of intrusions and malware, and vulnerability assessment, DIMVA'10, pages 200218,
SSL stripping attacks. In

Berlin, Heidelberg, 2010. Springer-Verlag. 35

55

[28] Rolf Oppliger.

SSL and TLS: Theory and Practice.

Artech House, Inc., Norwood,

MA, USA, 2009. viii, 62, 66


[29] S. Puangpronpitag and N. Masusai. An ecient and feasible solution to ARP Spoof

Electrical Engineering/Electronics, Computer, Telecommunications and


Information Technology, 2009. ECTI-CON 2009. 6th International Conference on,
problem. In

volume 02, pages 910 913, may 2009. 21, 52


[30] Somnuk Puangpronpitag and Nattavut Sriwiboon. Simple and Lightweight HTTPS

Proceedings of the 2012


Fourth International Conference on Computational Intelligence, Communication Systems and Networks, CICSYN '12, pages 229234, Washington, DC, USA, 2012. IEEE
Enforcement to Protect against SSL Striping Attack.

In

Computer Society. 35
[31] Adolfo Rodriguez, John Gatrell, and Roland Peschke.

Overview.

TCP/IP Tutorial and Technical

Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 7th edition, 2001. 5

Schneier's Cryptography Classics Library: Applied Cryptography,


Secrets and Lies, and Practical Cryptography. Wiley Publishing, 2007. 58

[32] Bruce Schneier.

[33] IEEE Computer Society. IEEE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges, 1998. IEEE 802.1D. 8
[34] Dug Song. dsni. Disponvel em http://www.monkey.org/ dugsong/dsni/, Acessado
em: julho de 2013. 1
[35] W. Richard Stevens.

TCP/IP illustrated (vol. 1): the protocols.

Addison-Wesley

Longman Publishing Co., Inc., Boston, MA, USA, 1st edition, 1993. viii, 10, 15, 25
[36] Douglas R. Stinson.

Cryptography: Theory and Practice.

CRC Press, Inc., Boca

Raton, FL, USA, 1st edition, 1995. 58


[37] Narten T. Neighbor Discovery for IP version 6 (IPv6), September 2007. RFC 4861.
39
[38] Andrew Tanenbaum.

Computer Networks.

Prentice Hall Professional Technical Re-

ference, 4th edition, 2002. 1, 4


[39] Brian Totty, David Gourley, Marjorie Sayer, Anshu Aggarwal, and Sailu Reddy.

HTTP: The Denitive Guide.

O'Reilly & Associates, Inc., Sebastopol, CA, USA,

2002. vi, 23, 26, 29


[40] Zouheir Trabelsi and Wassim El-Hajj. ARP spoong: a comparative study for education purposes. In

2009 Information Security Curriculum Development Conference,

InfoSecCD '09, pages 6066, New York, NY, USA, 2009. ACM. 16
[41] Zouheir Trabelsi and Wassim El-Hajj. On investigating ARP spoong security solutions.

Int. J. Internet Protoc. Technol., 5(1/2):92100, April 2010.

[42] Ruben

Unteregger.

APE

The

ARP

Poisoning

Engine.

21
Disponvel

em

http://www.megapanzer.com/2012/04/11/ape-the-arp-poisoning-engine/, Acessado
em: julho de 2013. 39

56

[43] Geon Yoon, Dae Hyun Kwon, Soon Chang Kwon, Yong Oon Park, and Young Joon
Lee. Ring Topology-based Redundancy Ethernet for Industrial Network. In

ICASE, 2006. International Joint Conference, pages 1404 1407, oct. 2006.

SICE-

[44] Sendong Zhao, Ding Wang, Sicheng Zhao, Wu Yang, and Chunguang Ma. Cookie-

Proceedings of the 14th international


conference on Information and Communications Security, ICICS'12, pages 365372,

proxy: a scheme to prevent SSLStrip attack. In


Berlin, Heidelberg, 2012. Springer-Verlag. 35
[45] H. Zimmermann.

OSI Reference ModelThe ISO Model of Architecture for Open

Systems Interconnection.

Communications, IEEE Transactions on, 28(4):425  432,

apr 1980. 5

57

Apndice A
Criptograa e protocolo SSL
As tcnicas descritas no captulo 3.4 permitem interceptar e visualizar de maneira
clara o trfego de rede de um determinado

host

de uma rede. Porm, existe uma premissa

bsica que torna isso possvel: as informaes so transmitidas e recebidas em claro, ou


seja, sem a utilizao de nenhuma tcnica de criptograa.

Este captulo apresenta os

conceitos bsicos de criptograa e do protocolo SSL.

A.1 Conceitos de Criptograa


O objetivo principal da criptograa, de acordo com [36, 32], permitir que duas pessoas ou entidades possam comunicar-se por meio de um canal inseguro de tal forma que
uma terceira pessoa considerada um oponente no consiga compreender as informaes
transmitidas. Uma informao que pode ser compreendida por qualquer pessoa denomidada texto em claro.
A idia da criptograa transformar uma mensagem representada como texto em
claro em um criptograma, isto , um conjunto de caracteres cujo signicado no pode
ser extrado sem alguma informao adicional (tipicamente uma chave). Esse processo
chamado de cifragem e, para que a criptograa seja de fato til, necessrio possibilitar
tambm a realizao do processo contrrio: a decifragem.
De maneira mais formal, considerando
espao de criptogramas e

Uma cifra um conjunto

CM

como o espao de possveis mensagens,

o espao de chaves, podemos denir o conceito de cifra:

de funes simblicas inversveis

e:M C

e1 :

tal que:

 m M codica um texto em uma linguagem L.


 m M, e, e1 K tem-se que e(m) = c e e1 (c) = m com c C .
 e e e1 podem ser parametrizadas por uma chave compartilhada k ou por um
par

kP U B , kP RIV .

Uma vez denida a cifra, pode-se denir um algoritmo de cifra: uma implementao

de uma cifra

tal que

f : K M K C,

cifra uma mensagem

m,

isto , calcula

58

onde:

e(m) = c.

Figura A.1: Esquema simtrico aplicado cifragem de mensagens

Figura A.2: Esquema assimtrico aplicado cifragem de mensagens

decifra um criptograma

c,

isto , calcula

e1 (m) = m.

Uma cifra robusta aquela cujo custo para se obter a mensagem


o conhecimento da chave

a partir de

depende do sigilo do projeto da funo

O restrito aquele cuja robustez da cifra

e das chaves caso existam.

Por sua vez, a

robustez da cifra do algoritmo simtrico no depende do sigilo do projeto de

sem

invivel. Os algoritmos de cifra, por sua vez, so divididos

em trs: restritos, simtricos e assimtricos.

do sigilo da chave

f,

mas sim

utilizada para cifrar e decifrar, da aleatoriedade da escolha da chave

e do espao de chaves

ser grande.

O algoritmo assimtrico, por m, possui duas chaves:

kP U B ,

a chave pblica e

kP RIV ,

a chave privada. Nesse esquema de cifra, a robustez tambm no depende do sigilo do

f nem de kP U B e ele construdo de forma a tornar invivel a deduo de kP RIV


kP U B . A robustez, depende ento do sigilo de kP RIV , da equiprobabilidade da
do par (kP U B ,kP RIV ) no espao de chaves K e desse espao ser sucientemente

projeto de

a partir de
escolha
grande.

As Figuras A.1 e A.2 demonstram como podem ser utilizados os esquemas simtrico e
assimtrico, respectivamente, no processo de cifragem de mensagens. O esquema simtrico
exige o sigilo da chave

entre duas pessoas apenas e a sua integridade durante seu uso,

pois o remetente ir utiliz-la para cifrar uma mensagem e o destinatrio precisar da


mesma chave para decifrar a mensagem.
Por outro lado, o assimtrico exige o sigilo apenas da chave
das duas chaves em sua utilizao.

A chave pblica

kP U B

kP RIV

e a integridade

ser utilizada por qualquer

remetente que necessitar transmitir mensagens para o destinatrio, que, por sua vez, ir
utilizar a chave privada

kP RIV

para decifrar a mensagem. O fato da chave privada ser de

posse exclusiva do destinatrio e ela no poder ser derivada a partir da chave pblica em
tempo vivel garante que uma terceira pessoa que tenha acesso ao criptograma no ter
acesso ao contedo da mensagem que foi transmitida.

A.2 Certicados e assinatura digital


Alm do problema de transmisso sigilosa, o esquema assimtrico utilizado para
implementar um esquema de certicao e assinatura digital.

59

O objetivo principal do

certicado atestar um conjunto de informaes sobre uma pessoa.

Dessa forma, um

certicado assemelha-se muito com um documento de identidade. Um documento desse


tipo possui informaes como nome, nmero de registro, endereo etc. O ponto chave
como determinar que as informaes contidas nesse documento so de fato verdadeiras.
Esses documentos so emitidos por um rgo ou entidade que assume-se convel (porm cada pessoa tem a liberdade de aceitar ou no esta premissa) e possuem mecanismos
que validam sua integridade como, por exemplo, uma marca d'gua. O processo de certicao digital semelhante. As entidades capazes de emitir certicados so chamadas
de Autoridades Certicadoras (ACs).
Uma pessoa que deseja possuir um certicado, aqui denominado como requerente,
deve contatar uma AC, fornecer seus dados e seguir as regras denidas na Poltica de
Certicao da AC. Essas regras denem os procedimentos (ou a ausncia deles) que a AC
utiliza para vericar/validar os dados apresentados por um usurio durante a requisio
de seu certicado.
O prximo passo, de acordo com o esquema de certicao, consiste na gerao de um
par de chaves

kP U B e kP RIV

que sero colocados no certicado juntamente com as informa-

es da AC e uma assinatura digital sobre todo o contedo reunido no certicado. Como


a maioria dos requerentes no possuem o conhecimento tcnico para gerar seu prprio
par de chaves nem entendem as possveis consequncias disto, esta tarefa normalmente
delegada prpria AC.
Este detalhe constitui uma falha grave das premissas do esquema assimtrico, pois
a AC ter acesso chave privada do requerente (podendo assim armazen-la).

Dessa

forma, o sigilo da chave privada no pode ser garantido, o que destri toda a segurana
e conabilidade que o esquema deveria prover. No entanto, supe-se, neste trabalho, que
ocorre o caso ideal no qual o usurio gera seu prprio par de chaves.
O esquema de assinatura digital, por sua vez, busca estabelecer em documentos digitais
as mesmas funes semiolgicas que a assinatura de punho realiza em documentos fsicos.
1. Inforjabilidade: uma entidade vericadora consegue determinar a autoria de uma
assinatura em um documento.
2. Inviolabilidade: conana da entidade vericadora quanto integridade de um documento vinculado a uma assinatura.
3. Irrecuperabilidade: conana na inviabilidade do reuso de uma assinatura de um
documento em outro.
4. Irrefutabilidade:

conana na inviabilidade da negao de autoria da assinatura

pelo autor.
Para assinar digitalmente um documento, necessrio que o signatrio possua um
certicado digital. Com ele, o titular capaz de assinar o documento utilizando sua chave
privada, cuja posse exclusivamente sua e qualquer pessoa que tenha acesso sua chave
pblica pode vericar se a assinatura vlida ou no. importante lembrar, que o que
de fato assinado o

hash

do documento e no o documento em si.

Isso feito para

garantir que no seja possvel alterar o documento aps ele ter sido assinado.

60

Figura A.3: Viso geral sobre a estrutura do protocolo SSL

A.3 Protocolo SSL


O protocolo SSL (

Secure Sockets Layer )

tem o objetivo de prover privacidade, au-

tenticidade e integridade de origem entre duas aplicaes que desejam estabelecer uma
conexo. Ele funciona como uma camada intermediria entre a camada de transporte e
a de aplicao como mostra a Figura A.3.

SSL Record
Protocol no nvel 1 e SSL Handshake Protocol, SSL Change Cipher Spec Protocol, SSL
Alert Protocol e Application Data Protocol no nvel 2.
O SSL na verdade um conjunto de 5 protocolos distribudos em 2 nveis:

A.3.1
O

SSL Record Protocol

SSL Record Protocol

utilizado para encapsulamento dos dados dos protocolos de

nvel 2 do SSL. O primeiro passo realizado consiste na diviso dos dados em blocos de
214
(ou menos) denominadas fragmentos. Cada bloco ento empacotado em uma

bytes

estrutura denominada

SSLPlainText.
SSLPlainText

Em seguida, a estrutura

comprimida de acordo com o mtodo de

compresso especicado no estado da sesso SSL. Na verdade, somente ser realizada


a compresso caso um mtodo tenha sido de fato selecionado, o que geralmente no
acontece.

Aps a compresso, a estrutura

SSLCompressed
denominada

SSLPlainText

convertida na estrutura

que ser encriptada de acordo com uma congurao da sesso SSL

cipher spec.

Essa congurao dene um par de algoritmos que sero utilizados para realizar autenticao (clculo de

hash ) e cifragem dos dados.


61

Juntamente com o algoritmo de troca

Tabela A.1:

Cipher suites

do protocolo SSL e os algoritmos correspondentes - adaptada

de [28]

Nome

Troca de Chaves

SSL_NULL_WITH_NULL_NULL
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40 MD5
SSL_RSA_WITH_IDEA_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_DSS_WITH_DES_CBC_SHA
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_RSA_WITH_DES_CBC_SHA
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_RC4_128_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_FORTEZZA_KEA_WITH_NULL_SHA
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA

de chaves, essas conguraes denem uma

cipher suite

Cifragem

NULL
RSA
RSA
RSA_EXPORT
RSA
RSA
RSA_EXPORT
RSA
RSA
RSA
RSA
DH_DSS_EXPORT
DH_DSS
DH_DSS
DH_RSA_EXPORT
DH_RSA
DH_RSA
DHE_DSS_EXPORT
DHE_DSS
DHE_DSS
DHE_RSA_EXPORT
DHE_RSA
DHE_RSA
DH_anon_EXPORT
DH_anon
DH_anon
DH_anon
DH_anon
FORTEZZA_KEA
FORTEZZA_KEA
FORTEZZA_KEA

cipher suite.

Autenticao

NULL
NULL
NULL
RC4_40
RC4_128
RC4_128
RC2_CBC_40
IDEA_CBC
EXPORT_DES40_CBC
DES_CBC
3DES_EDE_CBC
DES40_CBC
DES_CBC
3DES_EDE_CBC
DES40_CBC
DES_CBC
3DES_EDE_CBC
DES40_CBC
DES_CBC
3DES_EDE_CBC
DES40_CBC
DES_CBC
3DES_EDE_CBC
RC4_40
RC4_128
DES40_CBC
DES_CBC
3DES_EDE_CBC
NULL
FORTEZZA_CBC
RC4_128

NULL
MD5
SHA
MD5
MD5
SHA
MD5
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
SHA
MD5
MD5
SHA
SHA
SHA
SHA
SHA
SHA

So denidas 31 combinaes de

como mostra a tabela A.1.

SSLCompressed, calculado o autenticador

Uma vez obtida a estrutura comprimida


MAC da mensagem utilizando a funo

hash

denida na

cipher suite.

trutura comprimida so ento cifrados gerando a estrutura

O MAC e a es-

SSLCiphertext.

A ltima

etapa consiste na adio de um cabealho estrutura cifrada que contm 3 campos como
mostra a Figura A.5:
1. Tipo: indica a qual protocolo de nvel 2 do SSL se referem os dados da estrutura.
2. Verso: indica qual verso do protocolo SSL est sendo usada.
3. Tamanho: indica o comprimento em
O processo completo realizado pelo

A.3.2
O

bytes

da estrutura

SSL Record Protocol

SSLCiphertext.

ilustrado na Figura A.4.

SSL Handshake Protocol

SSL Handshake Protocol

permite que cliente e servidor possam se autenticar e

negociar conguraes como mtodos de compresso e


se d da seguinte maneira:

62

cipher suites.

Uma nova conexo

Figura A.4: Etapas do processo realizado pelo

SSL Record Protocol

Figura A.5: Campos do cabealho que encapsula a estrutura

63

SSLCiphertext

1. O cliente gera uma cadeia de

bits aleatria de 28 bytes e concatena-a com uma string

que dene a data atual em segundos, formando assim o campo

CLIENTHELLO.random.

Em seguida, adiciona a cadeia gerada e uma lista de opes de


tadas pelo cliente a uma mensagem
2. Aps receber uma mensagem

CLIENTHELLO

CLIENTHELLO,

o servidor envia para o cliente:

SERVERHELLO que contm a string


SERVERHELLO.random (gerada da mesma forma que

cipher suite

supor-

e a envia para o servidor.

(a) Uma mensagem


de

cipher suite

aleatria do servidor
a do cliente), a opo

escolhida pelo servidor e um nmero de ID da sesso.

(b) Caso o servidor deseje autenticar-se (o que geralmente acontece), uma mensagem

CERTIFICATE

que contm o certicado de chave pblica do servidor e

sua cadeia de certicados correspondente.


(c) Caso o servidor exija que o cliente se autentique com um certicado, uma
mensagem

CERTIFICATEREQUEST

que contm os tipos de certicados que

so aceitos e a lista de ACs consideradas vlidas pelo servidor.

SERVERHELLODONE indicando que o servidor j enviou todas


sucedem o SERVERHELLO.

(d) Uma mensagem


mensagens que

3. O cliente envia para o servidor:

CERTIFICATEREQUEST, envia uma menCERTIFICATE semelhante que recebeu do servidor, porm com o seu

(a) Caso tenha recebido uma mensagem


sagem

certicado de chave pblica e sua cadeia.


(b) Uma mensagem

CLIENTKEYEXCHANGE

nmero aleatrio de 46

bytes

que contm o

pre-master secret,

um

cifrado utilizando a chave pblica do servidor.

Esse nmero ser decifrado pelo servidor para gerar o

master secret

que, por

sua vez, ser utilizado para gerar as chaves de sesso.

CERTIFICATE, uma mensagem


CERTIFICATEVERIFY assinada digitalmente com a chave privada correspon-

(c) Caso o cliente tenha enviado uma mensagem

dente chave pblica presente no certicado enviado. Essa mensagem serve


como prova de que o cliente de fato tem posse da chave privada.
(d) Uma mensagem

CHANGECIPHERSPEC

Cipher Spec Protocol.

(e) Uma mensagem

FINISHED para

como especicado pelo

SSL Change

vericar que a troca de chaves e os processos

de autenticao foram bem sucedidos. Esta mensagem a primeira (do lado


do cliente) a ser enviada cifrada de acordo com a

cipher suite

escolhida.

4. O servidor envia o ltimo conjunto de mensagens:


(a) Uma mensagem

CHANGECIPHERSPEC

Cipher Spec Protocol.

(b) Uma mensagem

como especicado pelo

SSL Change

FINISHED. Esta mensagem a primeira (do lado do servidor)

a ser enviada cifrada de acordo com a

64

cipher suite

escolhida.

Uma vez nalizado o

handshake, cliente e servidor podem enviar dados de aplicao.

O processo para retomar uma conexo j existente uma simplicao desse processo:
1. O cliente envia para o servidor uma mensagem

CLIENTHELLO,

porm adiciona a

ela o ID de sesso da conexo.


2. O servidor recebe a mensagem e verica se existe uma sesso com o ID recebido
em seu

cache

de sesso. Se houver e o servidor estiver disposto a reestabelecer a

conexo retomando seu estado, ele envia:


(a) Uma mensagem

SERVERHELLO

(b) Uma mensagem

CHANGECIPHERSPEC.

(c) Uma mensagem

FINISHED.

com o ID da sesso.

Caso contrrio, o servidor gera um novo ID de sesso e o processo de

handshake

completo deve ser realizado novamente.

A.3.3

SSL Change Cipher Spec Protocol

O objetivo desse protocolo sinalizar transies de estratgias de cifragem entre


duas entidades que esto se comunicando.

CHANGECIPHERSPEC

que indica a

Para isso, o protocolo utiliza a mensagem

cipher spec

que ser utilizada nas mensagens subse-

quentes. Esse protocolo permite que o estado da conexo SSL seja alterado sem que seja
necessrio realizar uma renegociao da conexo.

A.3.4
O

SSL Alert Protocol

SSL Alert Protocol permite que as entidades comunicantes possam trocar mensagens

de alerta.

Cada mensagem possui uma descrio e um nvel de alerta como mostra a

tabela A.2:
Essas mensagens so utilizadas para deteco e tratamento de erros durante a conexo
SSL, sendo que alguns deles (os erros fatais) ocasionam o trmino da sesso.

A.3.5

SSL Application Data Protocol

Esse protocolo responsvel pela transmisso de dados de aplicao entre entidades


comunicantes. O protocolo lida com a coleta e envio dos dados de aplicao para o

Record Protocol

e vice-versa.

65

SSL

Tabela A.2: Mensagens de alerta do

Alerta
close_notify

SSL Alert Protocol

- adaptada de [28]

Cdigo

Nvel

Descrio

Aviso

Remente notica o destinatrio que no


enviar mais mensagens durante a conexo.

unexpected_message

10

Fatal

bad_record_mac

20

Fatal

Remente notica o destinatrio que uma


mensagem inesperada foi recebida.
Remente notica o destinatrio que uma
mensagem com MAC incorreto foi recebida.

decompression_failure

30

Fatal

Remente notica o destinatrio que a


funo de descompresso recebeu dados de
entrada imprprios.

handshake_failure

40

Fatal

Remente notica o destinatrio que no


foi possvel negociar um conjunto parmetros de segurana viveis dadas as opes
apresentadas.

no_certicate

41

Aviso

Cliente notica o servidor que no possui


um certicado que possa satisfazer a requisio do servidor.

bad_certicate

42

Aviso

Remente notica o destinatrio que o certicado recebido est corrompido.

unsupported_certicate

43

Aviso

certicate_revoked

44

Aviso

Remente notica o destinatrio que o certicado recebido no suportado.


Remente notica o destinatrio que o certicado recebido foi revogado pela AC que
o emitiu.

certicate_expired

45

Aviso

Remente notica o destinatrio que o certicado recebido expirou.

certicate_unknown

46

Aviso

Remente notica o destinatrio que ocorreu algum problema durante o processamento do certicado recebido.

illegal_parameter

47

Fatal

Remente notica o destinatrio que algum


campo da mensagem de
contra inconsistente.

66

handshake

se en-