2013 AndreFigueiraLourenco

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

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:
Campus Universitrio Darcy Ribeiro Asa Norte
CEP 70910-900
BrasliaDF Brasil
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/,
[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/,
[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
[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
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-

2013 AndreFigueiraLourenco

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

2013 AndreFigueiraLourenco

Caricato da

Copyright:

Formati disponibili

Universidade de Braslia

Instituto de Cincias Exatas

Webspy: uma aplicao de monitoramento Web em

Andr Figueira Loureno

Monograa apresentada como requisito parcial

Universidade de Braslia  UnB

Coordenador: Prof. Dr. Dbio Leandro Borges

Banca examinadora composta por:

CIP  Catalogao Internacional na Publicao

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

Monograa (Graduao)  Universidade de Braslia, Braslia, 2013.

Web , 2. ARP Spoong , 3. man-in-the-middle ,

Webspy: uma aplicao de monitoramento Web em

Andr Figueira Loureno

Monograa apresentada como requisito parcial

Prof. MSc. Joo Jos Costa Gondim (Orientador)

Prof. Dr. Diego de Freitas Aranha

Prof. Dr. Robson Albuquerque

Prof. Dr. Dbio Leandro Borges

Braslia, 25 de julho de 2013

em tempo real com foco em um

Essa aplicao foi desenvolvida como prova de conceito de que

Web atravs de tcnicas de ataque do

possvel realizar o monitoramento de trfego da

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

monitorado. Todos os conceitos e tcnicas que possibilitam o

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

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

The nal version

Keywords: Web monitoring, ARP Spoong, man-in-the-middle

2 Rede e dispositivos de rede

3 Descoberta de Rede e ARP Spoong

sweep X ARP sweep

4 Filtragem e visualizao do trfego Web

Filtragem de mensagens HTTP

Visualizao de pginas HTML

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

Mdulo de visualizao de pginas HTML

Integrao e resultados obtidos

A Criptograa e protocolo SSL

Certicados e assinatura digital

SSL Record Protocol . . . . . . .

Congurao de rede na qual o

Camadas do modelo TCP/IP e protocolos correspondentes

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

Topologias de congurao de rede

B antes e durante a utilizao do

para cada classe de endereamento

Ethernet como denido em [20]

Dilogo ARP para que um

poderia ser utilizado . . . . . . . .

A encontre o endereo de mquina de um

Campos do cabealho IPv4 como denido em [21]

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

Ilustrao do modelo cliente/servidor

Informaes contidas em uma URL

Mensagens de uma transao HTTP

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

Etapas do processo de NAT

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

Redirecionamento intermediado por um servidor

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

Sadas dos prottipos que implementam ARP e Ping

Monograa apresentada como requisito parcial

Universidade de Braslia UnB

CIP Catalogao Internacional na Publicao

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

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

Monograa apresentada como requisito parcial

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

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

The nal version

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

3 Descoberta de Rede e ARP Spoong

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

A Criptograa e protocolo SSL

Certicados e assinatura digital

Congurao de rede na qual o

Topologias de congurao de rede

Ethernet como denido em [20]

Campos do cabealho IPv4 como denido em [21]

Arquitetura da implementao da primeira abordagem de ltragem

Arquitetura da implementao da segunda abordagem de ltragem

Redes classicadas por sua abrangncia.

denidos pelo protocolo HTTP

ou hospedeiros, como denido por [23].

especco de uma rede.

Figura 1.1: Congurao de rede na qual o

produzidos neste trabalho cam

Por m, o captulo 6 expe consideraes nais e