DESENVOLVIMENTODEUMFRAMEWORKPARA ... · samente para minha formação acadêmica e pessoal e os sacrifícios realizados para que ... 4.1.4 Sniffer ... IEEE 802.15.4, IEEE 802.11,

RICARDO AUGUSTO MARTINS

DESENVOLVIMENTO DE UM FRAMEWORK PARAINVESTIGAÇÃO DE VULNERABILIDADES EM

DISPOSITIVOS DE INTERNET DAS COISAS

LONDRINA–PR

2018




Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

Orientador: Profo Dro Bruno Bogaz Zarpelão

LONDRINA–PR

2018

Ricardo Augusto MartinsDesenvolvimento de um framework para investigação de vulnerabilidades em

dispositivos de Internet das Coisas/ Ricardo Augusto Martins. – Londrina–PR,2018-

74 p. : il. (algumas color.) ; 30 cm.

Orientador: Profo Dro Bruno Bogaz Zarpelão

– Universidade Estadual de Londrina, 2018.

1. Internet das Coisas. 2. Contiki OS. I. Profo Dro Bruno Bogaz Zarpelão. II.Universidade Estatual de Londrina. III. Faculdade de Ciência da Computação.IV. Estudo sobre vulnerabilidades em dispositivos IoTCDU 02:141:005.7




Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

BANCA EXAMINADORA

Profo Dro Bruno Bogaz ZarpelãoUniversidade Estadual de Londrina

Orientador

Profo Dro Elieser Botelho Manhas Jr.Universidade Estadual de Londrina

Profo Dro Adilson Luiz BonifácioUniversidade Estadual de Londrina

Londrina–PR, 7 de Fevereiro de 2018

Para todos que tiveram um momento de fraqueza. Não vai doer para sempre, então nãodeixe isso afetar o que há de melhor em você

AGRADECIMENTOS

Gostaria de agradecer inicialmente aos meus pais, por sempre contribuírem imen-samente para minha formação acadêmica e pessoal e os sacrifícios realizados para queisso fosse possível. Também aos meus irmãos e avó pelo constante aprendizado que nossaconvivência trouxe.

Em sequêcia, gostaria agradecer imensamente ao meu namorado David, por todosos momentos de apoio. A todos os professores inspiradores que tive ao longo de minhaformação. Ao meu orientador Prof. Dr. Bruno Bogaz Zarpelão, por toda a orientaçãorealizada nesse e em outros trabalhos e me guiar e apoiar nessa reta final. Também aUniversidade Estadual de Londrina e o Departamento de Computação por me proporci-onarem esse ótimo ambiente de estudo.

“Fora Temer“

MARTINS, R. M.. Desenvolvimento de um framework para investigação de vul-nerabilidades em dispositivos de Internet das Coisas. 74 p. Trabalho de Conclusãode Curso (Bacharelado em Ciência da Computação) – Universidade Estadual de Londrina,Londrina–PR, 2018.

RESUMO

Durante os últimos anos, a tecnologia evoluiu de maneira exponencial. Juntamente comisso, ocorreu uma necessidade de miniaturização dos dispositivos conectados à rede, atri-buindo a eles funções específicas para melhorar nosso cotidiano, contribuindo com o sur-gimento de um novo paradigma chamado de Internet das Coisas (Internet of Things -IoT). Conjuntamente com esse paradigma, um novo conceito de rede foi definido, o qualé denomidado de rede LLN (Low-Power and Lossy Networks), as quais são construídaspor dispositivos de IoT de baixa capacidade de processamento. Essa menor capacidadede processamento trouxe inúmeros problemas relacionados a segurança, integridade e pri-vacidade dos dados trafegados. Este trabalho visa a construção de uma framework pararealizar a investigação de vulnerabilidades para analisar o nível de segurança de uma redeLLN.

Palavras-chave: Vulnerabilidades. Segurança da Informação. Redes LLN.

MARTINS, R. M.. Development of a framework for investigation of vulnera-bilities in Internet of Things devices. 74 p. Final Project (Bachelor of Science inComputer Science) – State University of Londrina, Londrina–PR, 2018.

ABSTRACT

Recently, technology has evolved exponentially. Along with this, there was a need forminiaturization of the devices connected to the network, giving them specific functions toimprove our daily life, contributing to the emergence of a new paradigm called the Internetof Things (IoT). Together with this paradigm, a new concept of network, referred to asLLN (Low-Power and Lossy Networks), has been defined, consisting of low-capacity IoTdevices. This lower processing capacity has brought numerous problems related to thesecurity, integrity and privacy of the data transmitted. This work aims to construct aframework to perform the investigation of vulnerabilities to analyze the level of securityof an LLN.

Keywords: Vulnerabilities. Information security. LLN Networks.

LISTA DE ILUSTRAÇÕES

Figura 1 – Arquitetura-Modelo de Hardware de dispositivos IoT [1] . . . . . . . . 25Figura 2 – Arquitetura-Modelo de Conectividade de dispositivos IoT . . . . . . . . 25Figura 3 – Espectro de classificação de modelos de conectividade (I) Rede autô-

noma (II) Rede de objetos inteligentes limitada (III) IoT autêntica[1] . 27Figura 4 – Paradigmas de comunicaçao . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 5 – Comparação Pilha 6LoWPAN e IPv6 [2] . . . . . . . . . . . . . . . . . 29Figura 6 – Exemplo de um DODAG [3] . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 7 – Ataque HELLO Flood [4] . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 8 – Ataque Sinkhole [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figura 9 – Ataque Wormhole [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 10 – Ataque Interno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 11 – Ataque Externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figura 12 – Cenário de exemplo com um sniffer . . . . . . . . . . . . . . . . . . . . 46Figura 13 – Cenário MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 14 – Cenário Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figura 15 – Cenário utilizado no teste de invasão do HELLO Flood . . . . . . . . . 52Figura 16 – Tráfego HELLO Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Figura 17 – Cenário SinkHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 18 – Execução do ataque SinkHole . . . . . . . . . . . . . . . . . . . . . . . 54Figura 19 – Cenário WormHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 20 – Execução do ataque WormHole . . . . . . . . . . . . . . . . . . . . . . 56Figura 21 – Cenário BlackHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 22 – Execução do ataque BlackHole . . . . . . . . . . . . . . . . . . . . . . 57Figura 23 – Cenário CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figura 24 – Tráfego da rede CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 25 – Cenário Proxy Reverso . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figura 26 – Configuração do arquivo de Proxy . . . . . . . . . . . . . . . . . . . . . 61Figura 27 – Página que gerou pacotes . . . . . . . . . . . . . . . . . . . . . . . . . 63Figura 28 – Pacote seguro com certificado TLS . . . . . . . . . . . . . . . . . . . . 63Figura 29 – Pacotes capturados pelo sniffer . . . . . . . . . . . . . . . . . . . . . . 63Figura 30 – Cenário MQTT, Servidor nó no 1, Clientes nós no 2,3,4 . . . . . . . . 64Figura 31 – Gráfico do tráfego durante o teste de invasão . . . . . . . . . . . . . . . 65Figura 32 – Cenário teste de invasão Telnet . . . . . . . . . . . . . . . . . . . . . . 66Figura 33 – Execução do servidor Telnet . . . . . . . . . . . . . . . . . . . . . . . . 67Figura 34 – Falha na conexão ao Telnet . . . . . . . . . . . . . . . . . . . . . . . . 67Figura 35 – Conexão ao Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

LISTA DE ABREVIATURAS E SIGLAS

IoT Internet of Things

LLN Low-power and Lossy Network

IETF Internet Engineering Task Force

OWASP Open WEB Application Security Project

OSSTMM Open Source Security Testing Methodology Manual

ISSAF Information Systems Security Assessment Framework

DoS Denial of Service

OWASP Open Web Application Security Project

OSSTMM Open Source Security Testing Methodology Manual

ISSAF Information Systems Security Assessment Framework

IDS Intrusion detection System

ECC Elliptic-curve cryptography

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA . . . . . 232.1 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1.1 Modelo da arquitetura de hardware de dispositivos IoT . . . . 242.1.2 Modelo de arquitetura da rede de dispositivos IoT . . . . . . . 252.1.3 Modelos de conectividade de dispositivos IoT . . . . . . . . . . 262.1.4 Paradigmas de comunicação de IoT . . . . . . . . . . . . . . . . 262.1.5 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.6 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.7 Protocolo RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.8 Protocolos de aplicação . . . . . . . . . . . . . . . . . . . . . . . . 302.2 Ataques a redes LLN . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.1 Ataques ao protocolo de roteamento RPL . . . . . . . . . . . . 312.2.2 Ataques DoS direcionados ao protocolo MQTT . . . . . . . . . 352.2.3 Captura não autorizada de pacotes na rede LLN . . . . . . . . 362.3 Testes de Invasão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4 OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4.1 OWASP Testing Guide . . . . . . . . . . . . . . . . . . . . . . . . 382.5 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 FRAMEWORK PARA INVESTIGAÇÃO DE VULNERA-BILIDADES EM DISPOSITIVOS IOT . . . . . . . . . . . . . . 41

3.1 Ataques Internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1.1 Ataques ao protocolo de roteamento RPL . . . . . . . . . . . . 433.1.1.1 Hello FLOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1.1.2 SinkHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.1.1.3 WormHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.1.1.4 BlackHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.1.2 Captura não autorizada de pacotes na rede LLN . . . . . . . . 453.2 Ataques Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.1 Ataque DoS ao protocolo MQTT . . . . . . . . . . . . . . . . . . 473.2.2 Telnet (login remoto) . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 RESULTADOS E DISCUSSÃO . . . . . . . . . . . . . . . . . . 514.1 Ataques Internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.1 Ataque de roteamento RPL . . . . . . . . . . . . . . . . . . . . . 514.1.1.1 HELLO Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.1.1.2 SinkHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.1.2 WormHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.3 BlackHole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.4 Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.1.4.1 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.1.4.2 Proxy Reverso HTTP/HTTPS . . . . . . . . . . . . . . . . . . . . . 604.2 Ataques Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.2.1 Ataque DoS ao protocolo MQTT . . . . . . . . . . . . . . . . . . 644.2.2 Telnet (login remoto) . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

21

1 INTRODUÇÃO

Nos últimos tempos, a Internet passou por um grande crescimento estrutural, alémde seu propósito inicial de descentralizar informações militares. Por conta desse cresci-mento, ela se tornou parte essencial do cotidiano, integrando-se a serviços que não estãoligados com o uso de computadores pessoais e redes tradicionais, mas sim a equipamentosde propósito específico como sensores de temperatura e luminosidade [5].

Com essa evolução, surgiu o paradigma nomeado de Internet das Coisas (Internetof Things - IoT). Esse paradigma refere-se a dispositivos que têm uma função específica eque estão interconectados e trabalhando com um objetivo em comum. Além disso, dentrodeste conjunto de dispositivos, existem os que têm menor capacidade computacional e dearmazenamento de dados, sendo ainda limitados pela necessidade de redução de gastosenergéticos [6] [7].

Os dispositivos que compõe o paradigma de IoT podem utilizar de uma pilha deprotocolos diferente das redes tradicionais. Na camada física, por exemplo, é possível uti-lizar IEEE 802.15.4, ao invés de protocolos IEEE 802.31 ou IEEE 802.112 que são comunsem redes convencionais. O IPv6 é utilizado como padrão na camada de rede em redescompostas por dispositivos de IoT, mas para isso foi necessária a criação de uma camadade adaptação para realizar a compressão do cabeçalho IPv6, denomidada de 6LoWPAN.Segundo a RFC6550, o protocolo RPL é o protocolo padrão para realizar o roteamentonesse tipo de rede. Essas redes, nas quais são adotados os protocolos 6LoWPAN, 802.15.4,protocolo RPL e dispositivos limitados, são chamadas de redes LLN [6] [7] [8].

As redes LLN (Lossy Low-power Network) foram definidas pelo grupo de trabalhoIETF (Internet Engineering Task Force)3 como rede sem fio de sensores e atuadores comrecursos limitados e que estão conectados à Internet por meio de um roteador de borda.Pela menor capacidade desses dispositivos e uma grande preocupação em garantir a se-gurança das redes LLN, é necessário o estudo de vulnerabilidades em diversos cenáriose protocolos. Esse estudo deve abordar uma diversidade de protocolos comumente utili-zados em cenários reais e a verificação dessas vulnerabilidades em sistemas operacionaisdisponíveis para a configuração desse tipo de rede [9].

O teste de invasão é uma abordagem necessária para identificar as vulnerabilida-des existentes em uma rede e seus dispositivos, além de evidenciar o grau de exposiçãode informações e o controle que uma vítima possa sofrer após a exploração de uma vul-nerabilidade por uma ameaça. Além disso, para a realização do teste de invasão, existem

1 Ethernet2 Rede Wi-Fi3 https://www.ietf.org/

22

algumas metodologias que podem ser utilizadas, e.g., OWASP, OSSTMM e ISSAF. [10].

Enquanto alguns trabalham abordam de maneira singular os protocolos e ambi-entes, como nos trabalhos Pongle et al. [11], Tomasi et al. [12] e Bernadini et al. [13], asabordagens utilizadas não se aplicam no escopo total de redes IoT e carecem de diversi-dade de cenários.

Este trabalho propõe a construção de uma framework para a realização de testes deinvasão em dispositivos e redes LLN com a adoção de conceitos da metodologia OWASP.O framework foi testado em diferentes cenários simulados com a ferramenta Cooja eos firmwares dos sensores são baseados em aplicações construídas no sistema operacionalContiki. Os seguintes protocolos são abordados pelo framework: Roteamento RPL, CoAP,HTTPS/HTTP, Telnet e MQTT.

O restante deste trabalho é organizado da seguinte forma. Na Seção 2, são apre-sentadas definições acerca dos conceitos de: IoT, IPv6, 6LoWPAN, ataques a redes LLN eframeworks para investigar as vulnerabilidades existentes em dispositivos IoT. Na Seção3 são apresentados os detalhes do framework proposto. A Seção 4 expõe os resultadosencontrados. A Seção 5 traz as considerações finais do trabalho.

23

2 FUNDAMENTAÇÃO TEÓRICO-METODOLÓGICA

Essa seção tem como finalidade a apresentação de conceitos teóricos para o enten-dimento do trabalho proposto, bem como evidenciar o estado da arte na área abordada.Primeiramente, serão mostrados os conceitos relacionados a Internet das Coisas, além dospadrões adotados pelo IETF para redes LLN e modelos de arquitetura de hardware, soft-ware e conectividade e protocolos para esse tipo de rede. Em seguida, serão abordados osconceitos de Testes de Invasão e técnicas de teste de invasão em redes IoT. Ao término,serão mostradas alguns frameworks propostos em trabalhos relacionados para realizar ainvestigação de vulnerabilidades em dispositivos de IoT.

2.1 Internet das Coisas

Recentemente, a conexão com a Internet começou a fazer parte de dispositivos, queanteriormente não continham conexão com redes de qualquer tipo. Por conta disso, surgiuum novo paradigma chamado de Internet das Coisas. Nesse paradigma estão incluídosdispositivos que tem poder de processamento relativamente diminuído e interagem entresi para cooperar com outros dispositivos e atingirem um objetivo em comum [14] [15] [16].

A miniaturização destes dispositivos e a diminuição dos custos de produção con-tribuíram com a sua presença em diversos locais. Em consequência da minituarizaçãodesses dispositivos, foi necessária a construção de um modelo de arquitetura de hardware,conectividade e paradigmas de comunicação específicos para dispositivos que estão inse-ridos no paradigma de IoT. Segundo previsões, até 2020 existirão em torno de 20 bilhõesde dispositivos IoT conectados à Internet. Porém, a evolução da estrutura de segurançae privacidade não ocorre no mesmo ritmo devido à menor capacidade de processamentopresentes nesses dispositivos, além da produção desenfreada sem preocupações com ainformação dos usuários finais que trafega nestes dispositivos [17] [7].

Esses dispositivos, em geral, utilizam sistemas operacionais específicos para menorcapacidade de processamento e bateria, e.g., Contiki e Tiny OS. Essa família de dispositi-vos IoT é vulnerável a ataques por alguns motivos. Primeiramente, os dispositivos ficamquase todo momento sem supervisão e podem estar ao alcance do público, e.g., sensoresespalhados por uma via pública, onde indivíduos podem facilmente ter acesso a essessensores. Segundo, a comunicação entre eles é realizada por meio de redes sem-fio, logoo acesso ao seu sinal é livre. E, por último, pela miniaturização, mecanismos complexosde segurança se tornam inviáveis, pois causam efeitos indesejáveis aos dispositivos, comoaumento excessivo do consumo de energia e atraso na comunicação [15] [18] [19].

Os protocolos usados nesses dispositivos de IoT de baixa capacidade são diferentes

24

daqueles utilizados em redes convencionais. Logo um novo padrão de comunicação foicriado para atendê-los, chamado de IEEE 802.15.4, que especifica a camada física e efetuao controle de acesso ao meio. Pelo fato da menor capacidade de bateria e processamentodesses dispositivos, a principal característica desse padrão é a baixa taxa de transmissão.O objetivo desse padrão de comunicação é fornecer uma transmissão de dados confiável,com um gasto razoável de energia e maior facilidade de instalação. O IEEE (Instituteof Electrical and Electronics Engineers) apresenta as seguintes características para essepadrão [7] [20]:

∙ Baixo consumo de energia;

∙ Transmissão sem fio de até 250 Kbps;

∙ Endereços de 16 bits (curto) até 64 bits (estendido);

∙ 16 canais na banda de 2450 Mhz;

∙ Protocolo de reconhecimento para transferência confiável.

Existe também um protocolo que permite a utilização do IPv6 sobre o IEEE802.15.4, o qual é denominado 6LoWPAN. O 6LoWPAN é uma camada de adaptação,que tem o objetivo de comprimir os cabeçalhos do IPv6, para agilizar o processo de trans-missão, além de fragmentar e desfragmentar os pacotes de acordo com o MTU (MaximumTransmission Unit - Unidade máxima de transmissão da camada física) da camada física[21].

Outro conceito importante em relação a Internet das Coisas são as redes LLN. Asredes LLN são redes compostas por dispositivos de menor capacidade de hardware e comsinal de baixo alcance. Essas redes são uma forma clara de desenvolver sistemas de IoT,e.g., sensores espalhados em uma plantação colhendo acidez do solo.

2.1.1 Modelo da arquitetura de hardware de dispositivos IoT

O modelo de arquitetura básica de dispositivos IoT é composta pelas seguintesunidades: processamento/memória, comunicação, fonte de energia e sensores/atuadores,como pode ser visto na Figura 1 [1] [22].

∙ A unidade de processamento/memória é composta por uma memória interna, umaCPU que geralmente são as mesmas utilizadas em sistemas embarcados, um con-versor analógico digital e um microcontrolador. A principal característica deve sera redução do consumo de recursos e espaço físico [1];

25

Figura 1 – Arquitetura-Modelo de Hardware de dispositivos IoT [1]

∙ A unidade de comunicação é composta por no mínimo um canal de comunicação,e.g., IEEE 802.15.4, IEEE 802.11, BLE (Bluetooth Low Energy). Por conta de seruma comunicação sem fio, geralmente são utilizados rádios de baixo custo e baixapotência. Logo, a comunicação é de baixo alcance e apresenta perdas frequentes depacotes [23];

∙ A unidade de fonte de energia é responsável por prover energia aos componentes dodispositivo. Usualmente, a fonte de energia é composta por uma bateria (recarregávelou não). Existem outras técnicas para construir fontes de energia, as quais convertemenergia do ambiente para energia elétrica, e.g., energia solar, energia mecânica,conhecidas também como energy harvesting. [24];

∙ A unidade de sensores e atuadores realiza o monitoramento do ambiente no qualo objeto está inserido. Estes sensores capturam dados do ambiente, como pressão,temperatura, acidez do solo. Os atuadores são dispositivos que recebem algum co-mando manual ou automático para produzirem alguma ação [22].

2.1.2 Modelo de arquitetura da rede de dispositivos IoT

Figura 2 – Arquitetura-Modelo de Conectividade de dispositivos IoT

26

O modelo de arquitetura de conectividade de redes LLN é composto por três cama-das, como pode ser visto na Figura 2. A camada de percepção, camada base, representa osdispositivos físicos e os dados que eles capturam e processam, e.g. transmissores/recepto-res IEEE 802.15.4. Na camada de rede, camada intermediária, encontram-se as abstraçõesdas tecnologias de comunicação, roteamento e identificação, e.g., protocolo 6LoWPAN,protocolo RPL. A camada de aplicação, camada topo, é responsável por oferecer os ser-viços para os clientes, e.g., MQTT, CoAP, HTTPS, HTTP [25] [17] [1] [26].

2.1.3 Modelos de conectividade de dispositivos IoT

Os modelos de conectividade de dispositivos IoT são divididos em: rede autônoma,rede de objetos inteligentes limitada e IoT autêntica [27]. A Figura 3 destaca os modelosa serem discutidos a seguir.

∙ O modelo de rede autônoma não tem a presença da conexão com a Internet, logoé inacessível a partir de ambientes externos. Esta rede é composta por objetos comdiferentes finalidades, e.g., usina nuclear e um sistema de climatização de um prédio,sendo o seu uso estritamente interno à uma corporação [27] [1];

∙ O modelo de Internet estendida apresenta os objetos parcialmente ou totalmenteconectados à Internet. Entretanto, este modelo adota medidas de proteção e segu-rança. Aplicações em cidades inteligentes adotam este modelo, no qual o acesso àrede é realizada por meio de proxys e firewalls, os quais possuem as atribuições decontrole de acesso [27] [1];

∙ O modelo de Internet das coisas autêntico é considerado o oposto do modelo derede autônoma de objetos, por conta dos objetos possuirem conectividade diretoà Internet. Consequentemente, os objetos podem prover serviços tais como outrosdispositivos na Internet, e.g., um servidor Web [27] [1].

2.1.4 Paradigmas de comunicação de IoT

Os paradigmas de comunicação de IoT são classificados em quatro categorias: um-para-muitos, muitos-para-um, junção do primeiro e segundo e um-para-um [28] [1]. NaFigura 4 é possível visualizar esses paradigmas.

∙ Muitos-para-um: este paradigma tem como característica a coleta de dados e enviopara um ponto central. O envio dos dados coletados ocorre com a criação de umaárvore de roteamento, sendo a raiz a concentradora dos dados coletados. Contudo,não há garantia do recebimento do dado, pois não há uma rota reversa entre a raize os objetos de origem dos dados [28];

27

Figura 3 – Espectro de classificação de modelos de conectividade (I) Rede autônoma (II)Rede de objetos inteligentes limitada (III) IoT autêntica[1]

∙ Um-para-muitos: este paradigma tem como característica a dispersão dos dados,assim sua operação é reversa à coleta de dados utilizada no paradigma muitos-para-um. Na dispersão de dados, ocorrem as chamadas inundações na rede para amensagem chegar ao destinatário. Porém, não há garantia do recebimento dos dados[28];

∙ Junção de Um-para-muitos e Muitos-para-um: este paradigma combina os paradig-mas do muitos-para-um e um-para-muitos. Assim, os objetos se comunicam com araiz da rede e a raíz com os objetos simultaneamente. Isso possibilita a implementa-ção de protocolos de transportes confiáveis. Contudo, o uso de memória é duplicadopara se manter esta comunicação bi-direcional [28];

∙ Um-para-um: este paradigma permite a comunicação bi-direcional entre todos osobjetos da rede. Por conta disso, requer maior capacidade dos recursos, principal-mente de armazenamento para armazenar todas as rotas possíveis entre todos osoutros objetos alcançáveis na rede [28].

28

Figura 4 – Paradigmas de comunicaçao

2.1.5 IPv6

Pelo grande crescimento no número de dispositivos existentes, o esgotamento dosendereços IPv4 é um problema a ser resolvido, pois o formato de endereço IPv4 comportaaproximadamente 4 bilhões de endereços. O IPv6 foi criado para resolver esse esgotamento.Segundo o documento RFC 3513 [29], o IPv6 é a sexta versão do protocolo IP. Os endereçosIPv6 são compostos por 128 bits para interfaces e conjuntos de interfaces, suportandomais de 3, 4 * 1038 endereços. Além disso, o IPv6 suporta três tipos de endereços em umainterface: multicast, unicast, anycast.

∙ Multicast: O endereço multicast identifica um conjunto de interfaces. O pacote en-viado para um endereço do tipo multicast será entregue a todas as interfaces iden-tificadas por esse endereço;

∙ Anycast: O endereço anycast identifica um conjunto de interfaces. O pacote enviadopara um endereço do tipo anycast será entregue à interface mais próxima identificadapor esse endereço;

∙ Unicast: O endereço unicast identifica somente uma interface. O pacote enviado parao endeço unicast será entregue a somente a interface identificada por esse endereço.

Os endereços IPv6 são atribuídos a interfaces, não em objetos ou dispositivosda rede. Por conta disso, um único dispositivo pode conter uma interface com endereçomulticast,unicast e anycast simultaneamente. Pelo fato de o endereço unicast ser umendereço único do dispositivo, ele é utilizado para identificar um dispositivo ou objetocontido numa rede [29].

29

2.1.6 6LoWPAN

O 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) é uma ca-mada de adaptação para utilização do protocolo IPv6 sobre a camada física que utiliza oIEEE 802.15.4, com a adição de cabeçalhos específicos para adicionar ou remover funçõescomo: encaminhamento multicast e encaminhamento mesh. Esta camada de adaptação éutilizada em dispositivos de IoT com limitações de recursos, assim permitindo a comuni-cação deste tipo de dispositivos com a Internet, além de diminuir o tamanho do cabeçalhopara aproveitar melhor o MTU disponibilizado pelo IEEE 802.15.4 [18] [11].

O 6LoWPAN garante as funções de descompressão/compressão do cabeçalho efragmentação/desfragmentação dos pacotes IPv6. A Figura 5 compara a pilha do IP emdispositivos convencionais e 6LoWPAN [18] [2] .

Figura 5 – Comparação Pilha 6LoWPAN e IPv6 [2]

2.1.7 Protocolo RPL

O protocolo RPL (Routing Protocol for Low-Power and Lossy Networks) é umprotocolo de roteamento para redes LLN, o qual foi projetado e padronizado pelo grupoROLL do IETF. Este protocolo foi projetado basicamente para comunicação muitos-para-um, entretanto suporta os outros paradigmas de comunicação, i.e., um-para-um eum-para-muitos. Logo, todos os nós da rede atuam como roteadores, pois encaminham ospacotes de acordo com o paradigma de comunicação adotado [11] [1].

A topologia do RPL é formada por uma árvore com somente uma raíz, tambémchamada de Grafo Acíclico Direcionado Orientado ao Destino, (DODAG - DestinationOriented Directed Acyclic Graph. Na Figura 6, é possível visualizar um exemplo destetipo de grafo. O nó raíz é responsável em inicializar o DODAG, transmitindo a mensagemDIO (DODAG Object Information). Então, os nós ao receberem o DIO de seus nós pai,selecionam o melhor nó pai, utilizando a função objetivo. A função objetivo pode ter como

30

métrica a qualidade do sinal ou quantidade de bateria no nó pai, por exemplo. Entretanto,o documento RFC 6550, o qual especifica o RPL, não define como essa métrica deve sercalculada [11] [8].

Figura 6 – Exemplo de um DODAG [3]

2.1.8 Protocolos de aplicação

Para realizar a aquisição de dados dos sensores na camada de aplicação de redesLLN, dois protocolos são comumente utilizados: CoAP e MQTT. Esses protocolos tem oobjetivo de realizar a comunicação dos dados coletados em dispositivos de baixa potência.

O protocolo CoAP (Constrained Application Protocol) é direcionado para trans-ferência de dados em nós e redes restritas, além disso, esses dispositivos contém baixacapaidade de memória RAM e alta taxa de perdas de pacotes. O objetivo do CoAP ésubstituir o protocolo HTTP em dispositivos de baixa capacidade e para isso ele se utilizado protocolo UDP na camada de transporte. Este protocolo também trabalha com umaURI para cada função que é suportada pelo dispositivo, além da troca de mensagens demaneira assíncrona. Outra característica é o suporte aos seguintes métodos: GET, POST,PUT e DELETE [30].

O protocolo MQTT (Messaging Queue Telemetry Transport) é direcionado paraa transferência de dados em redes restritas, com alta latência e baixa largura de banda.Esse protocolo utiliza-se do protocolo TCP na camada de transporte. Além disso, utiliza-se do esquema publisher/subscriber, no qual os dispositivos sensores da rede publicamseus dados coletados no broker. Os clientes são avisados de publicações no broker. Outracaracterística desse protocolo é a pequena sobrecarga de transporte e um mecanismo que

31

notifica os dispositivos quando um cliente desconecta-se da rede.

2.2 Ataques a redes LLN

Em consequência do menor poder computacional dos dispositivos presentes emredes LLN, existem vulnerabilidades que podem ser exploradas por dispositivos maliciososinseridos na rede ou por meio de um serviço disponível por padrão. Nesta seção, vamosdiscutir os principais tipos de ataques ao protocolo de roteamento RPL e DoS direcionadosao protocolo MQTT.

2.2.1 Ataques ao protocolo de roteamento RPL

Os nós contidos em redes LLN são limitados, a princípio, para se comunicarem comoutros nós dentro do alcance do seu sinal. Consequentemente, um protocolo de roteamentofoi criado, chamado de protocolo RPL, o qual tem o objetivo de realizar o roteamento dospacotes entre dispositivos. O protocolo RPL assume que os nós são confiáveis, logo oferecevárias oportunidades para nós maliciosos de atacar e romper o mecanismo de roteamento.Além disso, por conta da rede trabalhar com topologia mesh, na qual os nós comunstambém trabalham como roteadores, ela se torna mais exposta a ataques de roteamento.Os ataques podem classificados em passivos e ativos [4].

O ataque do tipo passivo tem o objetivo de espionar e analisar o tráfego de rotea-mento para descobrir informações. Este ataque é praticamente impossível de ser detectadopor não interferir no funcionamento da rede. Por outro lado, o ataque do tipo ativo temo objetivo de pertubar os mecanismos de roteamento, ganhar autorização, escalar privi-légios e até ganhar controle da rede com a geração de falsos pacotes, além de modificarou descartar pacotes legítimos da rede. O ataque do tipo ativo também pode ser classifi-cado entre duas categorias: internos e externos. Os ataques internos são causados por nóslegítimos, porém com seu funcionamento comprometido. Em contrapartida, os ataquesexternos são causados a partir de nós maliciosos que não são legítimos à rede [4].

Alguns ataques de roteamento podem ser efetuados no processo de seleção de rotas,eles são mostrados a seguir:

∙ Ataque HELLO Flood: Quando um nó ingressa em uma rede que utiliza RPL, eleenvia uma mensagem do tipo HELLO para seus vizinhos. O receptor desta mensa-gem assume que o nó remetente é um vizinho próximo. Contudo, um atacante commaior poder de transmissão, pode transmitir esta mensagem para uma região maior,cobrindo uma maior quantidade de sensores. Assim, os nós receptores assumirão queo atacante é o nó vizinho mais próximo. Com isso, a tabela de roteamento dos nóslegítimos que estão no alcance da transmissão será substituída por um tabela naqual as rotas são inviáveis por conta dos nós legítimos não terem o mesmo poder

32

de transmissão [11]. Na Figura 7 este ataque pode ser visualizado, no qual o nómalicioso transmite a mensagem do tipo HELLO com um alcance bem maior queos nós comuns;

∙ Ataque SinkHole: O objetivo do ataque sinkhole é de atrair todos os vizinhos e fazercom que estes vizinhos estabeleçam uma rota passando pelo nó malicioso. Estenó malicioso tende a parecer a melhor rota em relação as rotas criadas pelo RPL.Diferentemente do HELLO Flood, o nó atacante utiliza uma potência de transmissãonormal, com isso este ataque afeta somente parte da rede [11]. Na Figura 8, esteataque pode ser visualizado, no qual existem nós maliciosos , os quais concentramparte das rotas presentes na rede;

∙ Ataque Wormhole: O objetivo deste ataque é a cooperação de dois nós para criar umcaminho (também chamado de túnel ou canal out-of-bound, neste contexto) entreeles. Especificamente, os pacotes transmitidos por este túnel usualmente têm umalatência menor que os outros. Isso resulta em uma falsa aparência que o caminhoentre estes dois nós é a melhor escolha. Portanto, os nós vizinhos aos maliciososirão selecionar os nós maliciosos como os nós intermediários em suas rotas [11]. NaFigura 9 este ataque pode ser visualizado, no qual existem dois nós maliciosos, osquais criam um canal out-of-bound entre eles e concentram as rotas presentes narede.

33

Figura 7 – Ataque HELLO Flood [4]

34

Figura 8 – Ataque Sinkhole [4]

35

Figura 9 – Ataque Wormhole [4]

Normalmente, os três ataques citados são a preparação para outros ataques poste-riores, e.g. BlackHole e Selective Forwarding. Estes outros ataques são abordados a seguir:

∙ BlackHole: Os nós cooperam conjuntamente para encaminhar as mensagems rece-bidas. No entanto, com o ataque BlackHole, nós maliciosos comprometem uma rededescartando os pacotes recebidos, impedindo que mensagens sejam propagadas [31].

∙ Selective Forwarding: Esse ataque é uma versão atualizada do ataque BlackHole. Noataque Selective Forwarding, o nó malicioso descarta pacotes recebidos, impedindoa propagação de mensagens, no entanto, esse descarte é realizado em um pequenonúmero de pacotes. Consequentemente, isto ajuda a não levantar suspeitas dessetipo de ataque, visto que a perda de pacotes já pode ocorrer naturalmente [31].

2.2.2 Ataques DoS direcionados ao protocolo MQTT

O protocolo MQTT é um protocolo de comunicação de dispositivos IoT criadopela IBM para realizar a comunicação entre máquinas, também chamada de comunicação

36

M2M (Machine-to-Machine). Esse protocolo adota como padrão o protocolo TCP paratransporte e o padrão de mensagens (publisher/subscriber), no qual os dados são enviadospara um broker, que é encarregado de concentrar e encaminhar as mensagens aos desti-natários. Além disso, o MQTT não utiliza de criptografia para realizar sua comunicação[32].

Os ataques de negação de serviço (DoS) são eventos que atrapalham ou quebram acomunicação de uma rede. Eles são efetivados com a realização incessante de requisições aum determinado alvo. Outra característica é que estes ataques são realizados por atacantesque estão conectados a endereços IP da rede externa. Para a efetivação desse tipo deataque, é somente necessário conhecimento do endereço IP do alvo [33].

O ataque DoS direcionado ao protocolo MQTT tem como efeito uma grande taxade publicações e inscrições (publisher/subscriber). Logo, o efeito desse ataque é a maiorutilização da CPU e comprometimento da rede no broker [34].

2.2.3 Captura não autorizada de pacotes na rede LLN

A captura não autorizada de pacotes envolve capturar, decodificar e inspecionarinformações contidas em um pacote capturado em uma rede. Essa ação tem como objetivoroubar informações, e.g., senhas, números de cartão de crédito e detalhes da rede [35].

Essa captura acontece de maneira que os atacantes são invisíveis na rede, dificul-tando a detecção, portanto, é um tipo perigoso de ataque. Esse tipo de ataque, tambémconhecido como sniffing, é um evento no qual a privacidade da rede está comprometida[35].

O sniffing pode ocorrer de três maneiras: Interna, Externa e em redes sem fio. Osniffing interno ocorre por meio de um pré-conhecimento da rede, i.e., funcionário de umaempresa, na qual ele tem acesso a rede Interna. Já o sniffing externo ocorre quando nãohá um conhecimento da rede, no entanto, tem acesso a rede da empresa de algum modo,i.e., um atacante disfarça-se de visitante e conecta em uma interface de rede. Por último,o sniffing em redes sem fio ocorre quando uma pessoa captura os pacotes trafegados emuma rede sem fio, podendo esta ter autenticação ou não [35].

2.3 Testes de Invasão

Testes de invasão são realizados para catalogar as vulnerabilidades existentes nosdispositivos, sendo conhecido também como Pentest. Estes testes emulam ataques reaispara a exploração de potenciais vulnerabilidades. Além disso, determinam quais vulnera-bilidades são exploráveis e o grau de exposição da informação ou controle da rede que aorganização poderia esperar que um invasor conseguisse depois de explorar com sucessouma vulnerabilidade. As vulnerabilidades podem ser divididas entre lógicas e físicas. As

37

lógicas são relacionadas à infraestrutura e as físicas são relacionadas ao acesso físico àrede ou dispositivos [36] [10].

Estes testes são divididos entre internos e externos. Quando os testes são realizadosa partir de um computador que está fora do domínio da rede da vítima, direcionado à umservidor Web, por exemplo, é considerado externo. Quando os testes são realizados a partirde um computador que está dentro do domínio de rede da vítima, é considerado interno.Existem variações destes testes, e são definidos como: White-Box, Gray-Box e Black-Box.Esta divisão é dada pela quantidade de informações previamente passadas ao responsávelpelos testes. No White-Box, são passadas informações sobre toda a estrutura da rede e seuscomponentes. O responsável pelos testes tem uma visão da rede similar ao administrador.No Gray-Box são especificadas algumas informações que um usuário comum da rede, (e.g.,um funcionário da organização), tem acesso. E, por fim, no Black-Box, não é passadanenhuma informação sobre a rede ou organização a ser testada, geralmente as informaçõessão capturadas por pesquisas online [36].

O Teste de Invasão é constituído por três fases: fase pré-ataque, fase do ataque efase pós-ataque. Essas fases são definidas a seguir [36]:

∙ Pré-Ataque: Caracteriza-se por reconhecer e buscar. Na fase de reconhecimento élevantado o máximo de informações em relação à rede, desde as atividades da orga-nização, funcionários, localização. Após o reconhecimento, é realizada a varredurada rede para reconhecer os servidores, computadores e dispositivos conectados arede, seus respectivos sistemas operacionais e portas abertas;

∙ Ataque: Caracteriza o passo para comprometer os alvos. Neste momento são explo-radas todas as vulnerabilidades encontradas na pré-ataque, para se testar todas aspossíveis maneiras de um possível atacante invadir e comprometer a rede e disposi-tivos;

∙ Pós-Ataque: Esta fase é única para o teste de invasão, pois têm o objetivo de res-taurar o sistema para o estado no qual o sistema se encontra na fase pré-ataque.

2.4 OWASP

A comunidade OWASP (Open Web Application Security Project) é dedicada aencontrar e eliminar falhas de segurança em aplicações. Os documentos e ferramentasproduzidos por esta comunidade são disponibilizados publicamente. Esta comunidade ésuportada pela fundação OWASP, a qual não tem fins lucrativos. Além disso, projetossão desenvolvidos por eles, os quais têm conteúdo imparcial, pois não estão ligados ainstituições comerciais. Os projetos são dividos entre desenvolvimento e documentação[37].

38

Os seguintes projetos estão em documentação [37]:

∙ Development Guide: Este guia foca no desenvolvimento seguro de uma aplicação;

∙ Testing Guide: Este guia aborda a busca efetiva de vulnerabilidades;

∙ Code Rewiew Guide: Este guia propõe mecanismos de revisão segura de códigos;

∙ Top Ten: Este documento foca nas vulnerabilidades mais críticas;

∙ Application Security FAQ: É um conjunto de perguntas e respostas mais frequentessobre segurança de aplicações;

∙ Legal: Este documento visa garantir a devida atenção e segurança em diferentesestágios do desenvolvimento de um software;

∙ Metric: Este documento contém um conjunto de métricas de segurança de aplicaçõesutilizados pela comunidade OWASP.

Os seguintes projetos estão em desenvolvimento [37]:

∙ WebScarab: É um framework utilizada para a verificação do comportamento deaplicações que utilizam comunicação via HTTPS e HTTP.

∙ WebGoat: É um ambiente realístico projetado para ensinar lições de segurança emaplicações Web.

Para este trabalho, será dada uma atenção maior ao projeto Testing Guide, vistoque este pode ser utilizado para a realização de testes de invasão.

2.4.1 OWASP Testing Guide

O OWASP Testing Guide é um guia que busca por vulnerabilidades em aplicações,o qual reúne opiniões de especialistas em segurança. Com isso auxilia na execução detestes de invasão com rapidez, precisão e eficiência. Os objetivos desse guia são abordaras seguintes questões: o que é testar?, o que testar?, por que testar? e quando testar?.Alguns desses pilares são abordados a seguir [37]:

∙ O que é o teste?: Neste contexto, o teste é um processo de comparação entre o estadode uma aplicação e um conjunto de critérios;

∙ Por que testar?: Este objetivo tem como finalidade ajudar a entender um programade testes, além de auxiliar na identificação de passos que devem ser seguidos paraimplementar e colocar em prática um programa de testes;

39

∙ Quanto testar?: Este objetivo visa melhores práticas para prevenir-se de erros, logoaperfeiçoa o ciclo de desenvolvimento ao adicionar segurança em cada uma dasetapas do desenvolvimento de aplicações;

∙ O que testar? Este objetivo tem como foco o desenvolvimento de uma aplicaçãocomo uma integração de pessoas, processos e tecnologias, logo estes fatores quedeverão ser testados.

2.5 Trabalhos relacionados

Os pesquisadores têm proposto alguns frameworks para investigação de vulnera-bilidades de dispositivos IoT. Porém, essas propostas não abrangem diversos cenários outecnologias comumente utilizadas em dispositivos de redes LLN. Geralmente, as soluçõespropostas são voltadas somente para dispositivos específicos, como Android Yum e Rasp-berry Pi, que inclusive não são dispositivos que utilizam protocolos de redes de baixoalcance, como IEEE 802.15.4, 6LoWPAN, RPL e CoAP.

Tomasi et al. [12] propõem a adição de uma extensão n framework chamado Me-tasploit para esta suportar o 6LoWPAN. O Metasploit é um framework que concentraferramentas para realizar testes de invasão. Esta extensão tem o objetivo de incluir umacamada de tradução dos pacotes entre as redes tradicionais e 6LoWPAN, para então re-alizar ataques às redes IoT. Entretanto, conforme mencionado no próprio trabalho, essaabordagem não é eficiente quando a rede contém alguma contramedida, como criptografia.

Seguindo o mesmo escopo do 6LoWPAN, Reziouk [38] propõe uma ferramenta paraauditoria de segurança de redes baseadas neste protocolo. Essa auditoria ocorre com autilização de um scanner de rede IEEE 802.15.4 e de um roteador de borda capaz de rotearpacotes IPv6 entre redes Ethernet e 6LoWPAN. Consequentemente, essa combinaçãoobteve uma ferramenta de teste de invasão que permite a exploração de vulnerabilidadescom diversas ferramentas em redes 6LoWPAN. Nessa proposta, é necessário que o atacanteesteja no mesmo ambiente físico que a rede e dispositivos.

Alberca et al. [39] seguem uma linha diferente dos trabalhos anteriormente apre-sentados, com a exploração de vulnerabilidades no Arduino Yum com ataques propostospelo autor. Porém, o Arduino Yum utiliza a pilha de protocolos tradicional TCP/IP, tam-bém portas Ethernet e conexão IEEE 802.11, além da capacidade de processamento sermuito maior que os dispositivos de redes LLN. Apesar do Arduino Yum ter uma menorcapacidade de memória e processamento que dispositivos tradicionais, ainda assim é bemmais robusto que dispositivos de IoT que trabalham com redes de curto alcance e sistemaoperacional Contiki.

Na sequência Lahmadi et al. [40] propõem a investigação de potenciais vulnerabili-dades presentes em dispositivos 6LoWPAN por meio de um processo chamado de fuzzying

40

utilizando o Scapy, uma ferramenta escrita em Python. Fuzzying é uma técnica de testede software, que envolve o fornecimento de informações válidas, inválidas, inesperadas oualeatórias como entradas de um aplicativo. Por fim, essa abordagem permite investigar asvulnerabilidades por meio da injeção de pacotes na rede.

Por fim, o estudo proposto neste trabalho abrange diversos protocolos e cenáriosde dispositivos IoT em redes LLN. Um primeiro diferencial deste trabalho, em relaçãoaos existentes na área de identificação de vulnerabilidades nesse tipo de rede, é a maiorabrangência de protocolos de aplicação (MQTT, CoAP, HTTP) e um de roteamento(RPL). Outro ponto importante da solução proposta são as validações dos ataques nosdiversos cenários, por meio da construção de cenários e análise do comportamento darede.

41

3 FRAMEWORK PARA INVESTIGAÇÃO DE VULNERA-BILIDADES EM DISPOSITIVOS IOT

Neste trabalho, é proposto a construção de um framework para investigar vulne-rabilidades existentes em dispositivos IoT e cenários de redes LLN com a utilização dametodologia OWASP. O framework inclui dois tipos principais de ataques: os internos eos externos. Os ataques internos são aqueles que têm origem na área de alcance da rede,um exemplo pode ser visualizado na Figura 10, na qual o atacante tem acesso ao sinaldos nós internos da rede LLN. Os ataques externos são aqueles que têm origem externa àrede, i.e., por meio do roteador de borda. Um exemplo pode ser visualizado na Figura 11,na qual o atacante realiza ataques ao cenário externamente.

O módulo de ataques internos gera firmwares compilados para serem implantadosem dispositivos compatíveis com o Contiki, os quais podem ser físicos ou simulados. Omódulo de ataques internos pode gerar firmwares com as seguintes características:

∙ um firmware que contém um sniffer, o qual captura os pacotes trafegados na redee grava em um arquivo de texto (.txt);

∙ um firmware que implementa um nó malicioso capaz de realizar um ataque aoprotocolo RPL: HELLO Flood, SinkHole, WormHole e BlackHole

O módulo de ataques externos disponibiliza ferramentas para a realização de ata-ques externos direcionados a um endereço IP. O módulo de ataques externos pode realizarataques direcionados aos seguintes protocolos:

Figura 10 – Ataque Interno

42

Figura 11 – Ataque Externo

∙ uma ferramenta para realização de ataques DoS direcionados ao protocolo MQTT;

∙ uma ferramenta para a averiguação de segurança de um serviço Telnet.

Com a construção, simulação e realização dos ataques anteriormente citados, épossível analisar o comportamento da rede diante de diversos cenários, os quais podemser construídos de diferentes formas, desde que abrangendo os protocolos abordados noframework.

Os testes de invasão conduzidos são baseados na metodologia abordada no OWASPTesting Guide, os quais procuram as seguintes vulnerabilidades:

∙ Segurança nas comunicações: Verificar que a rede não tem proteção na comunicação,pois transmite pacotes em plain/text, além de não utilizar protocolos de segurançafim-a-fim como o TLS;

∙ Práticas de criptografia: Não existir uma política de implementação de criptografia;

∙ Controle de Acesso: não utiliza apenas objetos do sistema que sejam confiáveis, comoocorre com os objetos de sessão do servidor, para realizar a tomada de decisões deautorização de acesso; Não restringir o acesso à URL’s, funções, serviços, dados econfigurações do sistema apenas para usuários autorizados;

∙ Autenticação e gerenciamento de senhas: Não requerer autenticação para acessarpáginas e recursos; Não implementar uma estrutura centralizada;

∙ Validação da entrada de dados: Não efetuar controle de validação dos dados deentrada em um sistema confiável; Não identificar fontes de dados confiáveis e não-confiáveis

43

O restante desta seção está dividida da seguinte maneira. Em 3.1, está presentea descrição do módulo de Ataques Internos. Na Seção 3.2, está presente a descrição domódulo de Ataques Externos.

3.1 Ataques Internos

Esta seção tem como objetivo apresentar as funcionalidades presentes no módulode ataques internos contido no framework proposto. Esses ataques têm a característica degerar um arquivo de firmware para ser inserido em um nó real ou em uma simulação. Onó com esse firmware pode ser posicionado na área de alcance de uma rede LLN, podendoentão tentar realizar o seu ataque. Pelo fato dos nós serem inseridos em um local, noentanto, sem nenhum conhecimento sobre essa rede, sendo ainda possível ela não existirou utilizar um protocolo diferente do IEEE 802.15.4, além de não ter conhecimento dosendereços IP dos nós, somente suas respectivas localizações, caracteriza-se um teste deinvasão do tipo Gray-box.

3.1.1 Ataques ao protocolo de roteamento RPL

Os ataques direcionados ao protocolo RPL presentes nesse módulo visam exploraras seguintes características do RPL: assume que os nós são confiáveis, todos os nós atuamcomo roteadores e que o nó com o sinal com potência mais forte é o nó pai, de acordocom a função objetivo adotada. Em geral, as redes são estruturadas por nós com diversasaplicações, os quais funcionam como roteadores e o roteamento é realizado por meio doprotocolo RPL, além de um roteador de borda que é o nó raíz da rede. Os seguintes ataquesestão presentes: HELLO Flood, SinkHole, WormHole e BlackHole. Os ataques podem serexplorados adicionando os nós maliciosos gerados a cenários. Além disso, utilizando-sedos tópicos abordados pela metodologia OWASP, esta funcionalidade busca verificar narede a utilização de uma validação na entrada de dados.

Neste cenário, pode ser inserido um nó malicioso programado para realizar ataquesao roteamento RPL, os quais serão abordados nas seções 3.1.1.1, 3.1.1.2, 3.1.1.3 e 3.1.1.4.

3.1.1.1 Hello FLOOD

Essa funcionalidade disponível no framework está disponível por meio do comando:

$ h e l l o f l o o d [ pasta−de s t i no ]

O qual copia para a pasta escolhida pelo usuário o firmware. Esse código deveser compilado para então ser implantado em um dispositivo que necessariamente temuma capacidade de alcance maior que os nós comuns da rede LLN. Esse dispositivo deveser posicionado na área de alcance da rede LLN. A partir daí, ele vai enviar pacotes do

44

tipo HELLO para os nós. Logo após isso, os nós legítimos passam a acreditar que o nómalicioso é o vizinho mais próximo, no entanto, como eles não tem a força de sinal paraalcançar o nó malicioso, as vítimas enviam mensagens para um nó com uma rota inválida,afetando toda a tabela de roteamento de maneira que o tráfego de toda a rede aumentedrasticamente, no entanto, com rotas inválidas.

3.1.1.2 SinkHole

O nó malicioso configurado para a realização do ataque SinkHole tem como açãoa concentração do tráfego dos nós vizinhos. Isto ocorre com o envio de tabelas de ro-teamento alteradas, as quais apontam como melhor rota a passagem pelo nó malicioso.Consequentemente, as informações trafegadas pela rede poderão ser recebidas, acessadase alteradas por um nó malicioso.

A eficácia deste ataque ocorre de acordo com o posicionamento dos nós maliciososem relação ao restante da rede. Por este ataque ter ação somente sobre seus nós vizinhos,caso esteja localizado em uma posição de fronteira, a qual concentra um número menorde dispositivos, o ataque terá menor eficácia, em relação aos nós que estão posicionadosem regiões que concentram maior número de nós.

Com a inserção de um nó malicioso próximo ao roteador de borda, o ataque passa-se despercebido por um administrador de rede, apesar do maior fluxo de dados pelonó malicioso. Logo, mais informações podem ser extraídas ou alteradas antes de seremencaminhadas ao servidor.

Esta funcionalidade no framework está presente com o comando:

$ s i nkho l e [ pasta−de s t i no ]

O qual copia para um diretório da escolha do usuário o código do firmware queexecuta o ataque SinkHole. Em seguida, o atacante deve compilar o código para entãorealizar um upload para um nó físico ou adicionar em uma simulação. Esse nó maliciosopassará então a enviar tabelas de roteamento adulteradas para seus vizinhos de forma aexecutar o ataque de SinkHole.

3.1.1.3 WormHole

Os nós maliciosos configurados para realizar o ataque WormHole tem como ação acriação de um canal de comunicação entre eles. Isto é realizado com o comprometimentoda tabela de roteamento dos seus nós vizinhos, de tal forma que os pacotes trafeguem poreste canal. Consequentemente, com os pacotes trafegando por este canal, os nós maliciosospodem alterar ou extrair informações, antes de encaminhá-las aos outros nós.

Com a inserção de um nó malicioso próximo ao roteador de borda e outro em umalocalização próxima a uma grande concentração de nós legítimos, a eficácia do ataque

45

aumenta, pois a maior parte das informações que trafegam na rede serão concentradas nocanal criado entre os nós maliciosos, logo as informações encaminhadas para o servidorpoderão ser alteradas ou acessadas antes do envio.


$ wormhole [ pasta−de s t i no ]

O qual copia para um diretório da escolha do usuário o código do firmware queexecuta o ataque WormHole. Em seguida, o atacante deve compilar o código para entãorealizar um upload para dois nós físicos ou adicionar em uma simulação.

3.1.1.4 BlackHole

Os nós configurados para realizar o ataque BlackHole buscam fazer com que asrotas de seus vizinhos passem por eles e, a partir daí, descartam esses pacotes, nãoencaminhando-os para o próximo salto. Este ataque é realizado após o comprometi-mento da tabela de rotamento da rede por outros ataques ao protocolo RPL: SinkHole,WormHole. Consequentemente, informações são perdidas ao serem encaminhadas a essesnós maliciosos.

Com a inserção de nós maliciosos em uma rede LLN, a eficácia do ataque aumentaproporcionalmente ao número desses nós. Outro fator que tem que ser considerado naeficácia é sua localização, pois caso esteja localizado em regiões que concentram menornúmero de nós, a eficácia logicamente será menor. Quanto maior a eficácia, maior será aperda de informações da rede, comprometendo o envio e consistência das informações.


$ b lackho l e [ pasta−de s t i no ]

O qual copia para um diretório da escolha do usuário o código do firmware queexecuta o ataque BlackHole. Em seguida, o atacante deve compilar o firmware desseataque para então realizar um upload para um ou mais nós físicos ou adicioná-lo em umasimulação.

3.1.2 Captura não autorizada de pacotes na rede LLN

O framework permite que seja gerado um firmware que contém um sniffer, capazde capturar pacotes trafegados na rede LLN. Com esse sniffer, é possível verificar se a redeestá transmitindo pacotes em texto plano, que poderiam ser analisados por um atacante.Um dispositivo malicioso pode ser inserido no alcance do sinal da rede para capturar ospacotes trafegados, pois o acesso a rede pode ocorrer livremente, e.g., sensores espalhadosem uma via pública.

46

Com a inserção e posicionamento de um nó malicioso próximo a uma rede LLN,as informações que trafegam na rede serão capturadas e gravadas em um arquivo de texto(.txt). Consequentemente, informações sensíveis que trafegam sem criptografia em redesLLN serão acessadas. O cenário da Figura 12, contêm dispositivos IoT, os quais estão noalcance do sniffer que captura o tráfego desses dispositivos.

Figura 12 – Cenário de exemplo com um sniffer


$ s n i f f e r [ pasta−de s t i no ]

O qual copia para o diretório de escolha do usuário o código da firmware do sniffer.Com isso, o atacante deverá compilar o código, para então realizar o upload para um nófísico ou adicionar em uma simulação. O código-fonte, o qual foi a base da construçãodo sniffer, é o broadcast-example.c disponível nos arquivos de exemplo de aplicações doContiki na pasta " /ipv6/simple-udp-rpl/".

Baseando-se na metodologia OWASP, esta funcionalidade busca validar na redeos seguintes tópicos: Segurança nas comunicações; Práticas de criptografia; Validação daentrada de dados.

47

3.2 Ataques Externos

Esta seção tem como objetivo apresentar as funcionalidades do módulo de ataquesexternos presente no framework proposto. Esses ataques têm a característica de serem re-alizados remotamente, somente com o conhecimento do endereço IP, o qual caracteriza umteste de invasão do tipo Gray-box. Além disso, baseando-se na metodologia OWASP, estafuncionalidade busca validar na rede os seguintes tópicos: Segurança nas comunicações;Práticas de criptografia; Autenticação e gerenciamento de senhas; Controle de acesso.

3.2.1 Ataque DoS ao protocolo MQTT

O protocolo MQTT utiliza como padrão de mensagens o modelo publisher/subscri-ber, no qual as mensagens são concentradas em um broker. Este protocolo utiliza tópicospara encaminhar mensagens aos destinatários corretos. Esses tópicos são concentradosno broker, e.g., uma rede que contém os tópicos temperatura e umidade. Os dispositivosque coletam a temperatura e umidade de um solo publicam estes dados sob esses tópicos.Então, os dispositivos que assinam esses tópicos, são aqueles que recebem suas respectivasmensagens de acordo com o tópico escolhido.

As mensagens do tipo publish tem o objetivo de publicar em um tópico uma men-sagem para todos os outros dispositivos. Ela é enviada ao broker e este tem a função deencaminhar para o restante da rede. As mensagens dos tipos subscribe tem o objetivo deassinar um tópico para receber as mensagens relativas a este tópico.

Outra característica importante em relação a esse protocolo é a não utilização decriptografia para sua comunicação, o que é um grave problema de segurança.

Este ataque está disponível no framework pelo comando:

$ mqtt [ endere ço−IP ]

O qual tem como objetivo a realização de um ataque DoS direcionado ao endereçoIP de um broker MQTT. Esta funcionalidade foi baseada no exploit disponível em [41]e adaptada para ser executada por meio do framework, o qual envia mensagens do tipopublish ou subscribe para um endereço de um broker incessantemente em um curto inter-valo de tempo, buscando causar a sobrecarga do broker e, consequentemente, a negaçãode serviço. Na Figura 13 pode ser visualizado um exemplo de cenário para a realizaçãode um ataque, no qual o atacante conecta com o broker por meio do roteador de borda.

48

Figura 13 – Cenário MQTT

3.2.2 Telnet (login remoto)

O protocolo de comunicação Telnet foi desenvolvido pela RFC 15 [42] em 1969.Este protocolo utiliza como protocolo de transporte o TCP. O objetivo deste protocolo éa criação de um terminal virtual remoto. Este terminal virtual remoto utiliza-se da cria-ção de abstrações no terminal, permitindo que a comunicação entre clientes e servidoresaconteça, sem que ambos conheçam suas características.

Esse teste de invasão tem como objetivo a verificação da segurança de um disposi-tivo no qual está disponível um serviço de Telnet que carece de autenticação. Consequen-temente, se esse dispositivo aceitar uma conexão, um atacante poderia realizar uma sériede ações, comprometendo-o e até mesmo tornando-o um nó malicioso.

Essa funcionalidade está disponível pelo comando:

$ t e l n e t [ endere ço−IP ]

Tem como funcionamento uma conexão ao endereço IP, o qual foi inserido comoargumento. Caso ocorra uma conexão com sucesso a mensagem "Conectado com su-cesso" será exibida. Logo após, por se tratar de um teste de invasão, uma desconexãoé realizada. Um cenário que pode ser construído para conduzir um teste de invasão coma ferramenta disponível no framework pode ser visualizado na Figura 14.

49

Figura 14 – Cenário Telnet

51

4 RESULTADOS E DISCUSSÃO

Nesta seção, serão apresentados os resultados obtidos durante a realização de testesde invasão em cenários de redes LLN. Os testes de invasão tiveram o objetivo de verifi-car o funcionamento do framework mediante as vulnerabilidades existentes nos cenários.As vulnerabilidades foram testadas através de cenários simulados no software Cooja. OCooja é um ambiente de simulação de rede projetados especificamente para redes LLN.Esse ambiente tem o objetivo de simular nós, os quais executam aplicações construídascom a utilização das bibliotecas presentes no sistema operacional Contiki. Esse sistemaoperacional foi construído para ser inserido em dispositivos de baixa capacidade, e.g., TIMSP430, CC2538, Microchip pic32mx795f512l.

4.1 Ataques Internos

4.1.1 Ataque de roteamento RPL

Nesta seção estão documentados os resultados obtidos com a exploração de vulne-rabilidades que afetam o protocolo de roteamento RPL.

4.1.1.1 HELLO Flood

O experimento conduzido com a funcionalidade disponível no framework podeser visualizado na Figura 15, na qual o servidor UDP é representado pelo nó 1, o nó26 representa o nó malicioso configurado para a realização do ataque Hello Flood e osnós restantes são clientes UDP. Os servidores e clientes UDP foram escolhidos com aintenção de gerar tráfego normal. Eles estão disponíveis na pasta do sistema operacionalContiki " pastacontiki/examples/udp-ipv6", com seus respectivos nomes "udp-server.c"e"udp-client.c". O tráfego normal é necessário para comparar o comportamento da redeantes e durante o ataque.

52

Figura 15 – Cenário utilizado no teste de invasão do HELLO Flood

O teste de invasão foi constituído da seguinte maneira:

1. Execução do comando no framework para uma pasta destino, na qual encontrava-seos arquivos das simulações;

2. Compilação do firmware que realiza o ataque HELLO Flood;

3. Construção do cenário proposto;

4. Inserção do nó malicioso contendo o firmware gerado pelo framework configurando-opara alcançar todos os nós da simulação;

5. Execução da simulação e coleta de resultados durante 60 segundos;

6. Análise dos resultados.

Analisando os resultados, foi possível verificar um pico de tráfego na rede algunssegundos após o nó malicioso enviar uma mensagem do tipo HELLO. A Figura 16 exibe ográfico do tráfego da rede coletado durante a condução do ataque HELLO Flood. A linhaalaranjada representa a quantidade de pacotes por segundo que trafegaram em toda a redee a linha cinza representa o tráfego do nó malicioso, do qual provém o ataque. Analisandoo gráfico, o ataque se inicia em 8 segundos. Após isso, o nó malicioso comporta grandeparte dos pacotes da rede e aumenta consideravelmente o tráfego de todo o cenário.

53

Todo o tráfego da rede durante 60 segundos gerou uma quantidade de 995 pacotese o nó malicioso concentrou 21% do tráfego do cenário, ou seja, 209 pacotes. É possívelconcluir que um ataque do tipo HELLO Flood em uma rede IoT causa um grande tráfegoem um nó malicioso. Uma possível medida de proteção contra este ataque é a adoção deuma entidade controladora que limita o número de vizinhos para cada nó, de acordo como proposto por [43].

Figura 16 – Tráfego HELLO Flood

4.1.1.2 SinkHole

O experimento conduzido com a funcionalidade disponível no framework utilizao cenário que pode ser visualizado na Figura 17, ele foi construído com um servidorUDP (representado pelo nó 1), um nó malicioso (representado pelo nó 26) e clientes UDP(representados pelo restante dos nós), os quais estão presentes nos códigos de exemplo doContiki, localizados na pasta " pastacontiki/examples/ipv6/rpl-collect"e são chamados deudp-sender.c e udp-sink.c. Os passos são similares ao teste de invasão realizado para oHello Flood.

54

Figura 17 – Cenário SinkHole

Os resultados encontrados com a realização desse teste de invasão para a vulne-rabilidade em relação ao SinkHole no cenário proposto foram de que ele está suscetível aesse ataque.

Com a execução do ataque SinkHole no cenário foi possível observar que o nómalicioso comporta parte significativa do tráfego da rede como pode ser visto na Figura 18,na qual a linha amarela representa o tráfego no roteador de borda e a linha cinza representao tráfego no nó malicioso.

Figura 18 – Execução do ataque SinkHole

55

A medida de prevenção que poderia ser adotada em relação a vulnerabilidadeao SinkHole é um IDS proposto por [44]. Esse IDS, tem o objetivo de detectar ataquesSinkHole em uma rede de IoT, além de mitigar os efeitos adversos encontrados em IDS,como falsos positivos e negativos.

4.1.2 WormHole

O experimento conduzido com a funcionalidade disponível no framework utilizao cenário que pode ser visualizado na Figura 19. Ele foi construído com um servidorUDP (representado pelo nó 1),dois nós maliciosos (representados pelo nós 28 e 29) eclientes UDP (representados pelo restante dos nós), os quais estão presentes nos códigosde exemplo do Contiki, localizados na pasta " pastacontiki/examples/ipv6/rpl-collect"esão chamados de udp-sender.c e udp-sink.c.

Os resultados encontrados com a realização desse teste de invasão para a vulnera-bilidade em relação ao WormHole no cenário proposto foram de que ele está suscetível aesse ataque.

Figura 19 – Cenário WormHole

56

Com a execução do ataque WormHole, foi possível observar que os nós maliciososcomportam parte do tráfego da rede como pode ser visto na Figura 20, na qual a linhavermelha representa o tráfego do roteador de borda e a linha cinza representa o tráfegonos nós maliciosos.

Figura 20 – Execução do ataque WormHole

Para defender-se do ataque WormHole, também pode recorrer-se a um IDS. OIDS proposto por [11] utiliza informações de localização do nó e de seus vizinhos paraidentificar o ataque, além da força dos sinais recebidos.

4.1.3 BlackHole

O experimento conduzido com a funcionalidade disponível no framework utiliza ocenário que pode ser visualizado na Figura 21. Ele foi construído com um servidor UDP(representados pelo nó 1), um nó malicioso (representados pelo nó 26) e clientes UDP(representados pelo restante dos nós), os quais estão presentes nos códigos de exemplo doContiki, localizados na pasta " pastacontiki/examples/ipv6/rpl-collect"e são chamados deudp-sender.c e udp-sink.c.

Os resultados encontrados com a realização desse teste de invasão para a vulne-rabilidade em relação ao BlackHole no cenário proposto foram de que ele está suscetívelà esse ataque. Consequentemente, essa vulnerabilidade existe em dispositivos, os quaisestão distribuídos por diversas aplicações.

57

Figura 21 – Cenário BlackHole

Com a execução do ataque BlackHole foi possível observar que esse ataque, quandoentra em ação, após o comprometimento da tabela de roteamento, passa a descartar ospacotes que são recebidos por ele como pode ser visto na Figura 22, na qual a linhavermelha representa o tráfego do roteador de borda e a linha cinza representa o tráfegono nó malicioso, que após algum tempo passa a descartar grande parte do tráfego da rede.

Figura 22 – Execução do ataque BlackHole

58

Como medida de segurança contra um ataque BlackHole em uma rede LLN pode-seadotar um protocolo RPL seguro proposto por [45].

4.1.4 Sniffer

Nesta seção, estão documentados os resultados obtidos com a execução da funci-onalidade sniffer presente no framework com a execução nos seguintes cenários: CoAP eProxy Reverso HTTP/HTTPS.

4.1.4.1 CoAP

O primeiro experimento realizado com o sniffer buscou capturar tráfego em umarede com protocolo CoAP. Esse protocolo pode ser usado para que clientes externos, porexemplo, coletem dados nos sensores, que nesse caso atuam como servidores CoAP. Seesse tipo de tráfego é transmitido sem qualquer tipo de proteção, um atacante com umsniffer pode capturá-lo e ver quais dados estão sendo entregues aos clientes.

O cenário utilizado para a realização do experimento pode ser visualizado na Fi-gura 23. Neste cenário, está presente um cliente CoAP (nó 1), um servidor CoAP (nó 2) eum sniffer (nó 3). O firmware do sniffer é gerado pelo framework. O firmware do clientee servidor CoAP são códigos disponíveis nos exemplos incluídos no sistema operacionalContiki na pasta " pastacontiki/examples/rest-example/"como "coap-client-example.c"e"rest-server-example.c".

Figura 23 – Cenário CoAP


59

1. Cópia do firmware para a pasta destino de escolha do usuário por meio do fra-mework;

2. Compilação do firmware do sniffer ;

3. Construção do cenário;

4. Inserção do sniffer no cenário;

5. Execução da simulação e coleta de resultados durante 60 segundos;

6. Análise dos resultados;

Na Figura 24, é possível visualizar os pacotes capturados pelo sniffer durante aexecução do teste de invasão. As informações capturadas são as requisições feitas pelo ser-vidor para o cliente. Logo, é possível visualizar que os pacotes são transmitidos em textoplano. Texto plano é a representação da informação como texto puro. Consequentemente,os dados trafegados em uma rede CoAP, a qual utiliza os firmwares padrões disponibili-zados pelo sistema operacional Contiki, podem ser visualizados, o que evidencia um graveproblema de segurança, pois dados sensíveis podem ser capturados, e.g., senhas.

Figura 24 – Tráfego da rede CoAP

60

Como uma medida de proteção a uma rede, na qual foi adotado o protocolo CoAPpara comunicação, pode-se adotar a abordagem proposta por [46]. Essa abordagem im-plementa um protocolo DTLS com cabeçalho reduzido. O DTLS é um protocolo que temo objetivo de implementar o protocolo TLS sobre datagramas. Segundo a RFC 1594, umdatagrama é uma entidade básica de pacotes, nos quais a entrega, ordem e hora de che-gada não são garantidos. O protocolo DTLS, ao contrário do TLS, é capaz de resolverdois problemas: a perda de pacotes e reordenação. Ele implementa a retransmissão depacotes, atribuição de uma sequência de números dentro de um handshake e a verificaçãode pacotes duplicados [47] [48].

Essa redução do protocolo TLS não compromete a propriedade de segurança fim-a-fim disponibilizada por este protocolo. Em adição, outra medida de segurança que tam-bém pode ser adotada é a de [49]. Nesta abordagem foi implementada uma arquiteturaque suporta de redes de baixa potência, provendo comunicações seguras de camada detransporte com autenticação utilizando criptografia de chave pública ECC.

4.1.4.2 Proxy Reverso HTTP/HTTPS

O segundo experimento realizado com o sniffer buscou capturar tráfego em umarede interna, a qual está protegida por um Proxy Reverso HTTP/HTTPS que mapeiaas requisições HTTPS, feitas para os nós internos, para uma requisição HTTP. O proxypode ser utilizado para proteger a comunicação realizada entre clientes externos e a redede sensores, i.e., quando um cliente externo requisita uma informação de um sensor, arequisição HTTP passa pelo Proxy Reverso, torna-se HTTPS e então é enviada ao cliente.No entanto, como as informações na rede de sensores são transmitidas sem qualquer tipode proteção, um atacante com um sniffer pode capturar informações que estão sendoenviadas aos clientes externos.

O cenário adotado para a condução deste teste de invasão pode ser visualizado naFigura 25, no qual está incluído um roteador de borda, servidores HTTP, um sniffer, oProxy Reverso HTTP/HTTPS. Os firmwares dos servidores HTTP e roteador de borda es-tão disponíveis respectivamente nos firmwares de exemplo do sistema operacional Contiki"/contiki-2.7/examples/rest-example/rest-server-example"e "/contiki-2.7/ipv6/rpl-border-router/border-router.c".

61

Figura 25 – Cenário Proxy Reverso

Para os clientes acessarem a rede, eles realizam requisições do tipo HTTPS eo Proxy Reverso HTTP/HTTPS NGINX1 mapeia a requisição para o link HTTP doroteador de borda. Este mapeamento é configurado por meio de um arquivo que é lido peloNGINX. O arquivo de configuração do Proxy Reverso pode ser visualizado na Figura 26.A configuração do protocolo SSL foi baseada na configuração disponível em [50].

Figura 26 – Configuração do arquivo de Proxy

1 https://nginx.org/en/

62

Então, quando o cliente acessa o endereço do roteador de borda fora da rede, aoinvés de utilizar o protocolo HTTP, ele é encapsulado em um HTTPS com a garantia doprotocolo SSL2. Pelo fato dos nós internos da rede terem baixa capacidade, os administra-dores podem preferir que eles não estabeleçam conexões baseadas em HTTPS/SSL. Logoisso, investem em segurança no roteador de borda para fora, no entanto isso é perigoso.

O roteador de borda cria um túnel entre os nós e o proxy reverso utilizando oprotocolo HTTP. A partir do proxy, é utilizado o protocolo HTTPS. Caso esse cenárioseja em um ambiente confinado, os administradores e clientes externos podem ter umaperceção de que a rede está segura, visto que ocorre a utilização de HTTPS, mas umpossível usuário da empresa, e.g., funcionário, que tenha intenções maliciosas, pode inseriro sniffer na rede e capturar o tráfego dos nós livremente nesse ponto da rede, sem que hajaalguma mudança externa. Os pacotes foram capturados com o sniffer inserido na rede,os quais foram gravados em um arquivo de texto (.txt) com as informações dos pacotesna rede.


1. Cópia do firmware para a pasta destino de escolha do usuário por meio do fra-mework;

2. Compilação do firmware do sniffer ;

3. Construção do cenário no Cooja;

4. Configuração do Proxy Reverso HTTP/HTTPS

5. Inserção do sniffer no cenário;

6. Execução da simulação por meio de requisições no navegador e coleta de resultadosdurante 60 segundos;

7. Análise dos resultados;

Para a execução do experimento, foi realizada uma requisição para o nó número2, o qual é um servidor web. Essa requisição pode ser visualizada na Figura 27. Duranteessa execução foram capturados os pacotes da rede para validar a utilização do certificadoTLS para encriptar a comunicação com um cliente externo, o qual pode ser visualizadona Figura 28. Já na Figura 29 é possível visualizar os pacotes capturados pelo sniffer, osquais são transmitidos em texto plano.2 Ele cria um canal criptografado entre um servidor web e um navegador (browser) para garantir que

todos os dados transmitidos sejam sigilosos e seguros.

63

Figura 27 – Página que gerou pacotes

Figura 28 – Pacote seguro com certificado TLS

Figura 29 – Pacotes capturados pelo sniffer

Consequentemente, os dados trafegados pelas requisições aos nós servidores HTTP,os quais utilizam os firmwares padrões disponibilizados pelo sistema operacional Contiki,podem ser visualizados, o que evidencia um grave problema de segurança, pois dadossensíveis podem ser capturados, e.g., senhas.

64

Este ataque tem como especificidade a menor probabilidade de detecção, pois,pode ocorrer em uma rede industrial confinada, na qual o acesso é restrito a um grupode colaboradores e o HTTPS é adotado para proteger o tráfego de rede. No entanto, essetráfego de rede é protegido após o proxy reverso. Consequentemente, se um nó maliciosofor inserido no raio de alcance dos nós legítimos, os quais se comunicam com o proto-colo HTTP, as informações que deveriam estar protegidas pela camada de segurança noHTTPS com o protocolo SSL podem ser acessadas como texto plano. Logo, a adoção deum Proxy Reverso HTTP/HTTPS como medida de segurança não é adequada.

4.2 Ataques Externos

4.2.1 Ataque DoS ao protocolo MQTT

O experimento buscou efetivar um ataque DoS em uma rede com tráfego do pro-tocolo MQTT. Esse protocolo pode ser utilizado para comunicação da coleta de dados desensores, que nesse caso os clientes MQTT são a origem dos dados.

O cenário utilizado no experimento pode ser visualizado na Figura 30 e foi cons-truído com clientes MQTT3, o roteador de borda em "/contiki-2.7/ipv6/rpl-border-router/border-router.c"e um Broker MQTT. O Broker MQTT utilizado foi o rsmb, o qual é destinadopara utilização em dispositivos de baixa capacidade que utilizam Linux.

Figura 30 – Cenário MQTT, Servidor nó no 1, Clientes nós no 2,3,4

3 Os códigos dos clientes MQTT estão disponíveis no repositório [51]

65

Uma forma de ataque que pode ser executada neste tipo de ambiente é a realizaçãode várias requisições automatizadas, caracterizando um ataque DoS. Consequentemente,o consumo de energia e CPU do nó vítima aumenta drasticamente causando problemasna rede, e.g., bateria acaba rapidamente, rede congestionada.

A ferramenta utilizada para realizar ataque DoS no cenário MQTT está disponívelno framework pelo comando mqtt [endereço-IP], no qual o endereço IP é o do brokerMQTT. O teste de invasão no cenário foi conduzido com a simulação do cenário no Coojae do Broker rsmb no terminal. Os pacotes foram capturados com a extensão do Coojachamada Radio messages, na qual um arquivo de pacotes da rede (.pcap) é criado paraanálise.

Na Figura 31 é possível visualizar o gráfico do tráfego no broker disponível pelo ar-quivo .pcap, no qual existe uma queda no tráfego no tempo igual a 6 segundos após o iníciodo ataque, pois ele parou de responder. Logo, caso ocorra este ataque, o processamentodo dispositivo atacado é comprometido.

Figura 31 – Gráfico do tráfego durante o teste de invasão

4.2.2 Telnet (login remoto)

O experimento realizado buscou verificar se um serviço Telnet em um dispositivoIoT está em execução sem autenticação.

O cenário utilizado no experimento, o qual pode ser visualizado na Figura 32, foiconstruído com um firmware servidor Telnet, disponível como padrão no sistema ope-racional Contiki na pasta " pastacontiki/examples/telnet-server/telnet-server.c". Quando

66

Figura 32 – Cenário teste de invasão Telnet

este firmware é compilado e executado, um endereço IPv4 é atribuído a este serviço, comopode ser visualizado na Figura 33.

Como validação da funcionalidade, o teste de invasão foi conduzido primeiramentecom a utilização de um servidor Telnet configurado com autenticação, disponível em4. Épossível verificar na Figura 34 que não houve sucesso na conexão com autenticação.

Logo após, o teste de invasão foi conduzido em um dispositivo sem autenticação. Épossível verificar na Figura 35 que houve sucesso na conexão. Logo, o firmware disponívelpor padrão pelo sistema operacional Contiki está suscetível a ataques por meio destafuncionalidade.

4 https://github.com/maltempi/telnet-mock

67

Figura 33 – Execução do servidor Telnet

Figura 34 – Falha na conexão ao Telnet

68

Figura 35 – Conexão ao Telnet

69

5 CONCLUSÃO

Este trabalho desenvolveu formas para a validação da segurança de redes LLNpor meio da metodologia OWASP. O framework foi construído para a materialização dasformas de validação da segurança contribuindo com a realização de auditorias em cenáriosde redes LLN. Ela foi dividida em dois módulos: ataques internos e externos.

O primeiro módulo realiza testes de invasão com a geração dos nós maliciosos, paraentão inserí-los dentro do alcance do sinal da rede LLN. Este módulo contém as seguintesaplicações: Ataques ao protocolo RPL (HELLO Flood, SinkHole, WormHole e BlackHole)e um sniffer, o qual tem o objetivo de capturar e gravar informações dos pacotes que foramcapturados e trafegam em uma rede LLN.

O segundo módulo realiza testes de invasão por meio de uma conexão remota, e.g.,roteador de borda. Este módulo contém as seguintes aplicações: Ataques DoS direcionadoao protocolo MQTT e verificação do protocolo Telnet, o qual tem o objetivo de verificar sea porta Telnet de um dispositivo encontra-se disponível para conexão sem autenticação.

Por meio dos experimentos executados nos diversos cenários propostos, foi pos-sível verificar que o método OWASP, de modo geral, foi satisfatório especialmente paraenumerar as vulnerabilidades a serem exploradas pelo framework. No entanto, o fato deque não há um método específico para explorar vulnerabilidades em redes LLN, dificul-tou a decisão dos protocolos a serem avaliados. Além disso, houve uma preocupação emabranger diversos protocolos, para que o framework tenha uma cobertura mais ampla eque sua utilização seja reproduzível em diversos cenários.

Uma proposta de trabalho futuro é a adição de mais tipos de ataque ao framework,além do refinamento dos ataques já existentes.

71

REFERÊNCIAS

[1] SANTOS, B. P. et al. Internet das Coisas: da Teoria à Prática. Homepa-ges.Dcc.Ufmg.Br, p. 52, 2016.

[2] SHELBY, Z.; BORMANN, C. 6LoWPAN: The Wireless Embedded Internet. Wiley,2009. (Wiley Series on Communications Networking & Distributed Systems).ISBN 9780470747995. Disponível em: <https://books.google.com.br/books?id=uvgzlAEACAAJ>.

[3] WALLGREN, L.; RAZA, S.; VOIGT, T. Routing attacks and countermeasuresin the RPL-based internet of things. International Journal of Distributed SensorNetworks, v. 2013, 2013. ISSN 15501329.

[4] XIAO, Y. Security in Sensor Networks. CRC Press, 2016. ISBN 9781420013399.Disponível em: <https://books.google.com.br/books?id=ISkYgg-tUBoC>.

[5] ANGRISHI, K. Turning internet of things (IoT) into internet of vulnerabilities(IoV): IoT botnets. arXiv preprint arXiv:1702.03681, 2017.

[6] SICARI, S. et al. Security, privacy and trust in Internet of Things: The roadahead. Computer Networks, Elsevier B.V., v. 76, p. 146–164, 2015. ISSN 13891286.Disponível em: <http://dx.doi.org/10.1016/j.comnet.2014.11.008>.

[7] MARTINS, S. M. A Internet e a Rede das coisas: desafios e oportunidades. 2013.Monografia (Ciência da Computação), USP (Universidade de São Paulo), São Paulo,Brasil.

[8] WINTER, T. Rpl: IPv6 routing protocol for low-power and lossy networks. 2012.

[9] VASSEUR, J. Terms used in routing for low-power and lossy networks. 2014.

[10] MENEZES, P. M.; ROCHA, F. G.; CARDOSO, L. M. Segurança Em Redes DeComputadores Uma Visão Sobre O Processo De Pentest. Interfaces Científicas -Exatas e Tecnológicas, v. 1, n. 2, p. 85–96, 2015. ISSN 2359-4942.

[11] PONGLE, P.; CHAVAN, G. A survey: Attacks on RPL and 6LoWPAN in IoT.2015 International Conference on Pervasive Computing: Advance CommunicationTechnology and Application for Society, ICPC 2015, v. 00, n. c, p. 0–5, 2015.

[12] TOMASI, R. et al. Meta-exploitation of IPv6-based WSNs. Proceedings of the 3rdInternational Workshop on Security and Communication Networks, IWSCN 2011,p. 39–44, 2011.

[13] BERNARDINI, C.; LAHMADI, A.; FESTOR, O. Development of a fuzzingtool for the 6LoWPAN protocol. n. September, 2011. Disponível em: <http://hal.inria.fr/hal-00645948/>.

[14] SAID, O.; MASUD, M. Towards internet of things: Survey and future vision.International Journal of Computer Networks, v. 5, n. 1, p. 1–17, 2013. ISSN9781479952809. Disponível em: <http://www.cscjournals.org/csc/manuscript/Journals/IJCN/volume5/Issue1/IJCN-265.pdf>.

https://books.google.com.br/books?id=uvgzlAEACAAJ

https://books.google.com.br/books?id=uvgzlAEACAAJ

https://books.google.com.br/books?id=ISkYgg-tUBoC

http://dx.doi.org/10.1016/j.comnet.2014.11.008

http://hal.inria.fr/hal-00645948/

http://hal.inria.fr/hal-00645948/

http://www.cscjournals.org/csc/manuscript/Journals/IJCN/volume5/Issue1/IJCN-265.pdf

http://www.cscjournals.org/csc/manuscript/Journals/IJCN/volume5/Issue1/IJCN-265.pdf

72

[15] ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. Computernetworks, Elsevier, v. 54, n. 15, p. 2787–2805, 2010.

[16] WHITMORE, A.; AGARWAL, A.; Da Xu, L. The Internet of Things—A surveyof topics and trends. Information Systems Frontiers, v. 17, n. 2, p. 261–274, 2015.ISSN 15729419.

[17] GUBBI, J. et al. Internet of Things (IoT): A vision, architectural elements,and future directions. Future Generation Computer Systems, Elsevier B.V.,v. 29, n. 7, p. 1645–1660, 2013. ISSN 0167739X. Disponível em: <http://dx.doi.org/10.1016/j.future.2013.01.010>.

[18] CECÍLIO, M. Segurança em sensores com IPv6. 2013. Estágio (Mestrado emEngenharia Informática), FCTUC (Faculdade de Ciência e Tecnologia de Coimbra),Coimbra, Portugal.

[19] BRUNO, L. Security in Lossy and Low-power Networks- tools for 6LoWPAN. 2010.Monografia (Engenharia em Informática), Istituto Superiore Mario Boella, Torino,Itália.

[20] TANENBAUM, A.; WETHERALL, D.; TRANSLATIONS, O. Redes decomputadores. PRENTICE HALL BRASIL, 2011. ISBN 9788576059240. Disponívelem: <https://books.google.com.br/books?id=fnfwkQEACAAJ>.

[21] IPV6.BR. ZigBee usa agora 6loWPAN! Sua próxima lâmpada terá IPv6? 2013. <http://ipv6.br/post/zigbee-usa-agora-6lowpan-sua-proxima-lampada-tera-ipv6/>.[Online; acessado 23-Junho-2017].

[22] GUBBI, J. et al. Internet of things (IoT): A vision, architectural elements, andfuture directions. Future generation computer systems, Elsevier, v. 29, n. 7, p.1645–1660, 2013.

[23] AL-SARAWI, S. et al. Internet of things (IoT) communication protocols. In: IEEE.Information Technology (ICIT), 2017 8th International Conference on. [S.l.], 2017.p. 685–690.

[24] SUDEVALAYAM, S.; KULKARNI, P. Energy harvesting sensor nodes: Survey andimplications. IEEE Communications Surveys and Tutorials, v. 13, n. 3, p. 443–461,2011. ISSN 1553877X.

[25] VIEIRA, M. A. M. et al. Survey on wireless sensor network devices. EmergingTechnologies and Factory Automation, 2003. Proceedings. ETFA ’03. IEEEConference, p. 537–544, 2003. ISSN 19460759. Disponível em: <http://ieeexplore.ieee.org/xpls/abs\_all.jsp?arnumber=1247>.

[26] MUNOLI, R.; DASIGA, S. Secure Data Transmission for Iot Applications.International Journal of Advanced Research in Computer and CommunicationEngineering ISO, v. 3297, n. 7, 2007. ISSN 2278-1021.

[27] CASTELLANI, A. P. et al. Architecture and protocols for the internet of things:A case study. In: IEEE. Pervasive Computing and Communications Workshops(PERCOM Workshops), 2010 8th IEEE International Conference on. [S.l.], 2010. p.678–683.

http://dx.doi.org/10.1016/j.future.2013.01.010

http://dx.doi.org/10.1016/j.future.2013.01.010

https://books.google.com.br/books?id=fnfwkQEACAAJ

http://ipv6.br/post/zigbee-usa-agora-6lowpan-sua-proxima-lampada-tera-ipv6/

http://ipv6.br/post/zigbee-usa-agora-6lowpan-sua-proxima-lampada-tera-ipv6/

http://ieeexplore.ieee.org/xpls/abs\_all.jsp?arnumber=1247

http://ieeexplore.ieee.org/xpls/abs\_all.jsp?arnumber=1247

73

[28] BELLO, O.; ZEADALLY, S. Intelligent device-to-device communication in theinternet of things. IEEE Systems Journal, IEEE, v. 10, n. 3, p. 1172–1182, 2016.

[29] IETF.ORG. RFC 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture. 2003. <https://tools.ietf.org/html/rfc3513>. [Online; acessado 15-09-2017].

[30] SHELBY, Z.; HARTKE, K.; BORMANN, C. The constrained application protocol(coap). 2014.

[31] MATHUR, A.; NEWE, T.; RAO, M. Defence against black hole and selectiveforwarding attacks for medical WSNs in the IoT. Sensors (Switzerland), v. 16, n. 1,2016. ISSN 14248220.

[32] TORRES, A. B. B.; ROCHA, A. R.; Neuman De Souza, J. Análise de Desempenhode Brokers MQTT em Sistema de Baixo Custo. Anais do XXXVI Congresso daSociedade Brasileira de Computação, p. 2804–2815, 2016.

[33] KASINATHAN, P. et al. Denial-of-service detection in 6lowpan based internetof things. In: 2013 IEEE 9th International Conference on Wireless and MobileComputing, Networking and Communications (WiMob). [S.l.: s.n.], 2013. p. 600–607.ISSN 2160-4886.

[34] WUN, A.; CHEUNG, A.; JACOBSEN, H.-A. A Taxonomy for Denial of ServiceAttacks in Content-based Publish/Subscribe Systems. Proceedings of the 2007inaugural international conference on Distributed event-based systems - DEBS ’07,n. 2, p. 116–127, 2007. Disponível em: <http://portal.acm.org/citation.cfm?doid=1266894.1266917>.

[35] Valency Networks. Network Security: Sniffing Fixation. 2017. <http://www.valencynetworks.com/articles/cyber-security-attacks-network-sniffing.html>.[Online; acessado 19-01-2018].

[36] MALLERY, J. Building a secure organization. Computer and Information SecurityHandbook, p. 527–540, 2009.

[37] OWASP, F. OWASP Testing Guide v3.0. OWASP Foundation, p. 349, 2008. ISSN1098-6596.

[38] REZIOUK, A.; LEBRUN, A.; DEMAY, J.-C. Auditing 6LoWPAN Networks UsingStandard Penetration Testing Tools. [S.l.]: DEFCON, 2016.

[39] ALBERCA, C. et al. Security analysis and exploitation of arduino devices in theinternet of things. In: ACM. Proceedings of the ACM International Conference onComputing Frontiers. [S.l.], 2016. p. 437–442.

[40] LAHMADI, A.; BRANDIN, C.; FESTOR, O. A testing framework for discoveringvulnerabilities in 6LoWPAN networks. Proceedings - IEEE International Conferenceon Distributed Computing in Sensor Systems, DCOSS 2012, n. July 2012, p.335–340, 2012.

[41] OLIVEIRA, E. IOT MQTT Exploit. 2017. <https://github.com/Warflop/IOT-MQTT-Exploit>. [Online; accessed 19-November-2017].

[42] CARR, C. S. Network subsystem for time sharing hosts. [S.l.], 1969.

https://tools.ietf.org/html/rfc3513

http://portal.acm.org/citation.cfm?doid=1266894.1266917

http://portal.acm.org/citation.cfm?doid=1266894.1266917

http://www.valencynetworks.com/articles/cyber-security-attacks-network-sniffing.html

http://www.valencynetworks.com/articles/cyber-security-attacks-network-sniffing.html

https://github.com/Warflop/IOT-MQTT-Exploit

https://github.com/Warflop/IOT-MQTT-Exploit

74

[43] GIRUKA, V. C. et al. Security in wireless sensor networks. Wireless Communicationsand Mobile Computing, v. 8, n. 1, p. 1–24, 2008. ISSN 15308669.

[44] CERVANTES, C. et al. Detection of sinkhole attacks for supporting securerouting on 6LoWPAN for Internet of Things. Proceedings of the 2015 IFIP/IEEEInternational Symposium on Integrated Network Management, IM 2015, p. 606–611,2015.

[45] AIREHROUR, D.; GUTIERREZ, J.; RAY, S. A trust-aware RPL routing protocolto detect blackhole and selective forwarding attacks. Australian Journal ofTelecommunications and the Digital Economy, v. 5, n. 1, p. 50–69, 2017. ISSN22031693.

[46] RAZA, S. et al. Lithe: Lightweight secure CoAP for the internet of things. IEEESensors Journal, v. 13, n. 10, p. 3711–3720, 2013. ISSN 1530437X.

[47] RESCORLA, E.; MODADUGU, N. Datagram transport layer security version 1.2.2012.

[48] WELLS, A. T.; KROL, E.; PLZAK, R. Fyi on questions and answers answers tocommonly askednew internet user questions. 1994.

[49] GRANJAL, J.; MONTEIRO, E.; Sa Silva, J. End-to-end transport-layer security forInternet-integrated sensing applications with mutual and delegated ECC public-keyauthentication. IFIP Networking Conference, 2013, p. 1–9, 2013.

[50] REMAKEELECTRIC. How To Create an SSL Certificate on Nginx forUbuntu 14.04. 2017. <https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04>. [Online; accessed19-November-2017].

[51] SILVA Ânderson Ignacio da. [6LoWPAN] MQTT-SN and Contiki-OS / Part 1. 2017.<https://blog.aignacio.com/2017/06/25/6lowpan-mqtt-and-contiki-os/>. [Online;accessed 19-November-2017].

https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04

https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04

https://blog.aignacio.com/2017/06/25/6lowpan-mqtt-and-contiki-os/

Documents

DESENVOLVIMENTODEUMFRAMEWORKPARA ... · samente para minha formação acadêmica e pessoal e os sacrifícios realizados para que ... 4.1.4 Sniffer ... IEEE 802.15.4, IEEE 802.11,