📖
📖
📖
📖
Introducao à segurança digital
Search…
📖
📖
📖
📖
Introducao à segurança digital
Introdução à Segurança Digital
Introdução a Linux
Criptografia
Redes
Ataques
Ferramentas
Pacote & Protocolo
Camada de Rede
Camada de Transporte
IANA
Three-way Handshake
DHCP
DNS
NAT
Pentest
Avançado
Web
CTF
Engenharia Reversa
Pwning
Hardware
Powered By GitBook
Avançado

Aulas Ganesh Redes 2019

Sumário

Ficando Atualizado (ou "Sempre na Crista da Onda")

MISC

  • Diferença entre Roteador e Access Point

ATAQUES

  • MITM
  • Spoofing
    • Mac changer
    • IP spoofing
    • ARP spoofing
    • DNS spoofing/poisoning
  • DoS
    • SYN flood
    • ICMP flood
    • DHCP starvation
    • Rogue DHCP
  • Botnet
    • Malwares
    • LOIC
    • HOIC
  • Wifi
    • WPS PIN brute forcing
    • Deauth
  • Website cloning

FERRAMENTAS

  • Nmap
  • Bettercap
  • Wifi Pumpkin
  • Reaver, Wash, Pixie Dust
  • Linset
  • Fake ap
  • Wi-filax

Aula 1: Introdução -- Protocolos, TCP/IP, NAT, Endereçamento

  • Protocolos
  • IP: Internet Protocol
    • Host to Host (máquina a máquina)
    • Semântico (!= do MAC) e hierárquico (País > Estado > Cidade > Rua > Número)
    • Semântica ajuda nos protocolos de roteamento
    • Octeto
    • Máscaras de Sub-rede
      • Classes
      • Historinha dos IPs perdidos
      • Ex: calcular máscara
      • Ex: calcular número de hosts/redes
      • Dúvida: Por que preciso de mais bits pra rede?
    • Endereço de Rede (192.168.32.2/24 => 192.168.32.0)
      • Bits de host zerados
      • Dúvida: Pra que serve isso?
    • Endereço de Broadcast (192.168.32.2/24 => 192.168.32.255)
      • Bits de host settados
      • Dúvida: Pra que serve isso? Fazer Broadcast!
      • Ex: Ping broadcast
    • IP não garante que o destino recebeu o pacote!!
    • IPv5
    • DHCP
    • Alternativas ao IP
    • Tooling: nmap (network scan => descobrir hosts ativos na rede), IP spoofing
192 .168 .254 .128 /24 11000000 10101000 11111110 11111110 RRRRRRRR RRRRRRRR RRRRRRRR HHHHHHHH (24) 11111111 11111111 11111111 00000000 255 .255 .255 .0 /??
  • TCP
    • Processo a processo/Inter-process communication (programa a programa)
    • Portas
    • Conexão (definida por um par de sockets)
    • Socket (???)
    • Número de série (garantir recebimento do pacote)
    • Dúvida: o que é um socket 'listening'? (netcat)
    • Three-way handshake (limite de conexões, hping3)
      • Todo pacote do TCP deve ter um ACK correspondente (INCLUSIVE O SYN)
      • SYN, SYN/ACK, ACK
      • Outros tipos de pacotes: FIN, RES, etc.
      • Curiosidade: Four-way handshake
    • NAT (Network Address Translation)
      • Várias máquinas atrás do mesmo endereço
      • Diferenciação pela porta
      • Ex: Call of Duty
    • Tooling: nmap (portscan), hping3 (connection flood), netcat (nc, ncat,...)

Segurança

  • IP spoofing
  • MITM/MITMA/MIM (Man in the Middle Attack)
  • Connection flood
  • Portscanning

Exercícios

  • Nmap: Descobrir hosts conectados em alguma rede (https://resources.infosecinstitute.com/nmap/) e fazer um SYN flood nele com hping3
  • Echo Server (python, socket.socket)/Client
  • Xtra2: Ip spoofing
  • Xtra3: Traceroute (o que é, como fazer)

Aula 2: Bettercap, MITM e Spoofing

  • What is monitor mode? How do I read packets of networks I don't have access to?
  • Interactive vs Non-interactive
    • '-eval'
    • '-caplets'
  • Ticker: deamonizing commands
    • ticker.
    • ticker.period
  • ARP spoofing
    • Spoofs gateway by default (can be deactivated)
    • ​
  • Sniffer
    • ​
  • HTTP proxy (redirect http traffic)
  • SSLStrip

MITM (Man in the middle)

Um ataque man in the middle (lit. homem no meio) é feito visando a enganar o computador da vítima a pensar que o atacante é o roteador (ou outro dispositivo / serviço pelo qual passem informações sensíveis) e também enganar o roteador (ou dispositivo / serviço... sensíveis) e fazê-lo pensar que o atacante é a vítima. Desse modo, todo o tráfego de dados passará pelo computador do atacante, e a conexão não será rompida. Portanto, o ataque é transparente ao uso cotidiano.

Aula 3: DoS, DDoS, ADoS e Slow Lorris

DoS (Denial of Service)

Um ataque DoS visa impedir o acesso a determinado recurso ou serviço.
  • Exemplos: excluir um arquivo (negação de acesso ao arquivo); impedir conexões em um servidor
No caso de impedir conexões em um servidor alvo, deve-se inundar ("floodar") o tráfico de Internet dele. Normalmente, isso é feito por meio do envio de muitas requisições ao servidor, superando sua capacidade de receber novas conexões. Nesse sentido, podemos pensar que o servidor é uma grande avenida que se encontra com um trânsito de carros muito grande. Esse excesso de tráfego torna a entrada de outro veículo na avenida praticamente impossível.
Um jeito simples de fazer tal ataque é mandar uma requisição de conexão ou um ping com frequência superior a capacidade de processamento dessas requisições por parte do servidor.
  • Resolver esse ataque é simples: basta fazer blacklist do IP do atacante.

DDoS (Distributed DoS)

Enquanto o ataque DoS parte de uma única máquina, o DDoS faz uso de múltiplos dispositivos conectados à Internet (computadores, dispositivos IoT, celulares etc.). Dessa forma, o ataque torna-se mais eficiente. Os dispositivos utilizados no ataque podem estar participando por boa vontade ou podem ser parte de uma botnet.
  • Os dispositivos que formam uma botnet foram infectados por algum malware que dá ao atacante ("dono" do malware) controle remoto sobre cada um deles.
Resolver um DDoS já bem mais difícil, pois as requisições estão vindo de diversos dispositivos (IPs diferentes), fazendo com que o ataque pareça tráfego normal.

(D)DoS Refletido (Reflection DoS)

O atacante envia pacotes (ping ou alguma outra requisição) para um servidor (chamado de refletor) pedindo que o pacote seja repassado para outro IP, o do verdadeiro alvo.
  • Esse ataque spoofa o IP do atacante, pois passa pelos servidores refletores.
Caso o ataque parta de uma máquina, resolvê-lo é simples, pois a banda de um servidor tende a ser muito maior do que a de um computador pessoal. Entretanto, esse ataque também pode ser um DDoS.

ADoS (Amplified DoS)

Nesse ataque, faz-se uso de requisições spoofadas para servidores mal-configurados. Uma certa quantidade de pequenas requisições com o IP spoofado do servidor alvo é enviada para servidores acessíveis. Os servidores respondem para o IP do alvo com pacotes muito maiores (amplificados), floodando o serviço de forma muito mais fácil.
Pode-se amplificar o ataque usando um comando de EDNS0, que aumenta o tamanho do pacote de resposta (até 70 vezes maior), ou usando o comando mullist do protocolo NTP, que aumenta o tamanho do pacote de 20 a 200 vezes.
ADoS não são triviais de serem resolvidos, o melhor jeito é blacklist todos os servidores envolvidos no ataque e esperar passar.

Memcached DDoS

O sistema memcached:
Memcached é um cache "in-memory" bem veloz usado para acelerar aplicações web dinâmicas, aliviando o carregando a partir de bases de dados. Por exemplo, uma aplicação manda uma requisição para o servidor memcached antes de mandar para um bando de dados. O servidor memcached armazena respostas de requisiões comuns, portanto, se ele tem a resposta para a requisição feita, o banco de dados sequer é acessado. Do contrário, o memcached responde que não tem o conteúdo e uma requisição é enviada ao banco de dados. Além disso, a memória "sobrando" em certas partes do sistema Memcached é disponibilizada para áreas nas quais falta memória (isso aumenta virtualmente a quantidade de cache disponível)
O ataque:
O ataque funciona da mesma forma que um ADoS. Ele só é possível pois os servidores memcached, por padrão, operam usando o protocolo UDP. Logo, como não há handshake, dados podem ser enviados ao servidor alvo sem o real consentimento dele.
São enviadas requisições spoofadas (com o IP do servidor alvo) para o servidor memcached, que responderá com pacotes de tamanhos muito maiores ao alvo, floodando-o e impedindo que ele processe outras requisições.
Para defender-se: desabilite UDP no servidor memcached e use firewall.

Slow Lorris e R.U.D.Y.

Outra maneira de atacar servidores é usando ataques de protocolo (camadas 3 e 4 do modelo OSI), como o Slow Lorris e o R.U.D.Y.
Ambos esses ataques consistem no estabelecimento de conexões com o servidor e no envio extremamente lento (e constante) dos bytes de cada pacote, utilizando pouca banda e mantendo todas as conexões abertas.
  • Slow Lorris faz uso de requisições do tipo HTTP GET
  • R.U.D.Y. faz uso de requisições do tipo HTTP POST
Se feito corretamente, um computador "caseiro" pode parar um servidor comercial sozinho.

SYN Flood

É o ataque explora o funcionamento do TCP para estabelecer conexões(o three-way handshake).
No handshake, o servidor fica esperando um pacote de confirmação (ACK packet) para estabelecer a conexão. Portanto, o atacante envia muitos pacotes SYN (e nenhum pacote ACK!), fazendo com que o servidor fique esperando a confirmação de cada conexão (que nunca chega). Assim, o servidor torna-se incapaz de abrir uma conexão real pelo número de requisições em aberto.
Uma possível solução é realizar uma filtragem dos pacotes.

ICMP (Ping) Flood

É o ataque que utiliza ping (echo) requests. Use-se o protocolo ICMP, que exige um consumo de banda para envio e para resposta. O objetivo é sobrecarregar o alvo por meio do envio de muitas requisições ICMP - obrigando o servidor a responder a todas -, superando sua capacidade de responder a conexões.
Para evitar esse ataque, é possível desativar a funcionalidade ICMP do servidor, impedindo o envio de requisições ping ou traceroute.

DNS Flood

Esse ataque visa floodar servidores DNS (os "DNS resolvers"), impedindo que haja resoluções DNS - comprometendo, portanto, a capacidade do servidor alvo de responder à tráfego legítimo (a não ser que a pessoa utilize IPs para conectar-se a algum endereço).
Esse ataque requer muita banda para ser efetivo.

Materiais Adicionais

Aula 4: SSL/TLS, HTTP/HTTPS e HSTS

HTTP: HyperText Transfer Protocol

  • Protocolo usando para transmitir HTML via internet
  • Não usa criptografia alguma (tudo em texto plano)
  • HTTPS: HTTP uasndo criptografia (SSL/TLS)

Certificados e Unidades Certificadoras (CAs)

HTTPS funciona primariamente baseado em confiança, ou seja, é preciso confiar no servidor com o qual você está falando. Para isso, SSL/TLS são equipados com certificados.
Certificados são documentos assinados por instituições em quem o cliente confia a priori: as Autoridades Certificadoras (CAs). Esses documentos garantem que o servidor com o qual um determinado cliente está falando é confiável e, mais, que é ele mesmo (não uma cópia feita por um atacante).
Para ilustrar isso melhor imagine que Merindrola é o site que quer "provar" para o cliente Marcelo (popularmente conhecido como 'Batatinha') que ela é um site leígitimo e não uma cópia. Batatinha é grande amigo do Carlos (a Autoridade Certificadora), e confia 100% nele. O que acontece quando uma Autoridade Certificadora assina um certificado de um servidor é equivalente a Carlos dizendo a Batatinha que Merindrola é parça (morô?).
CSR (Certificate Signing Request): Requisição feita do servidor para a CA para que seja emitido um certificado para o a aplicação.
Self-Signed Certificate: Certificado assinado por uma "Autoridade Certificadora" criada pelo próprio site/app (nada seguro, deve ser usado somente para testes)
Obs.: Veja o vídeo nos materiais adicionais sobre Certificados e Autoridades Certificadoras.

HSTS: HTTP Strict Transport Security

  • Política de segurança para garantir obrigatoriedade no uso de HTTPS
  • Na prática, HSTS é nada mais que um header contido na resposta do servidor ao cliente
  • Quando um cliente recebe alguma resposta do servidor com o header Strict-Transport-Security significa que todos os requests feitos para o servidor após aquele deverão usar HTTPS (nunca HTTP) por um certo período de tempo
  • Header Strict-Transport-Security
    • max-age: tempo em segundos da validade do HSTS (em segundos)
    • includeSubDomains: todos os subdomínios também só poderão ser acessados por HTTPS

Vulnerabilidades no HSTS

  • O primeiro pacote mandado pelo cliente ainda usa HTTP, pois é o servidor que deve especificar, através do header HSTS, a obrigatoriedade do HTTPS. Portanto, é ainda possível estabelecer o SSL Stripping, mas somente na interceptação do primeiro request feito em HTTP pelo cliente.
  • "Because HSTS is time limited, it is sensitive to attacks involving shifting the victim's computer time e.g. using false NTP packets." (Wikipedia)

Atacando HSTS

Materiais Adicionais:

Aula 5: Coisas importantes que você precisa saber sobre a Internet

Internet vs Web

A primeira coisa que precisamos entender é que Internet e Web são coisas diferentes. Acredite se quiser, existiu um tempo em que a Internet existia mas a Web não -- mais precisamente, de 1969 até 1989.
Internet é a rede mundial de computadores, trata-se da infraestrutura: cabos, roteadores, protocolo IP (Internet Protocol). Tudo isso forma a internet.
A Web, ou World Wide Web, é uma aplicação distribuída que usa a infraestrutura da internet. É o conjunto de servidores web (servidores HTTP/HTTPS) e clientes web (browsers, curl, etc.) que trocam páginas HTML. Quando ouvir falar de Web, pense em páginas HTML (hoje em dia vêm acompanhadas de JavaScript e CSS), protocolos HTTP e HTTPS.

Protocolos na prática

  • sockets
  • portas TCP
  • portas UDP

APIs (Application Programming Interfaces)

São interfaces, conjuntos de padrões de ações, entradas e saídas, para interação de clientes com servidores. A grande vantagem das APIs é que elas abstraem chamadas de funções em um servidor.
Por exemplo, imagine que a Merindrola quer fazer um site para mostrar informações sobre o clima na cidade dela: São Carlos (SP). Ela então vai no site do INPE e descobre como funciona a API deles. A API do INPE é razoavelmente simples, vamos pegar como exemplo a previsão do tempo dos próximos 4 dias: 1. Você manda para eles uma requisição com o código da localidade (encontrado aqui):
1
http://servicos.cptec.inpe.br/XML/cidade/codigo_da_localidade/previsao.xml
Copied!
  1. 1.
    Achado o código, que no caso da Merindrola é 4774, fazemos uma requisição GET na url (aqui, vamos usar o wget para exemplificar):
    1
    $ wget http://servicos.cptec.inpe.br/XML/cidade/4774/previsao.xml
    Copied!
  2. 2.
    Temos como retorno um arquivo, nesse caso é XML, mas poderia ser JSON, que é mais comum atualmente:
    1
    <?xml version='1.0' encoding='ISO-8859-1'?><cidade><nome>S�o Carlos</nome><uf>SP</uf><atualizacao>2019-10-02</atualizacao><previsao><dia>2019-10-02</dia><tempo>ps</tempo><maxima>33</maxima><minima>17</minima><iuv>11.0</iuv></previsao><previsao><dia>2019-10-03</dia><tempo>ps</tempo><maxima>32</maxima><minima>20</minima><iuv>10.0</iuv></previsao><previsao><dia>2019-10-04</dia><tempo>ps</tempo><maxima>32</maxima><minima>17</minima><iuv>11.0</iuv></previsao><previsao><dia>2019-10-05</dia><tempo>ps</tempo><maxima>33</maxima><minima>20</minima><iuv>11.0</iuv></previsao></cidade>
    Copied!
  3. 3.
    O arquivo pode parecer confuso, mas como tudo relacionado a APIs, ele segue um padrão e, claro, esse padrão está especificado também na página do INPE.
  4. 4.
    Finalmente, Merindrola pode parsear esses dados e fazer seu site lindamente.
Existem vários jeitos de se fazer uma API, vamos falar sobre dois padrões famosos de APIs: SOAP e REST.

SOAP vs REST

  • SOAP (Simple Object Access Protocol) é um protocolo de troca de informações para serviços web. APIs que fazem uso desse protocolo utilizam XML para se comunicar. Uma característica do SOAP é que ele pode ser utilizado com a maioria dos protocolos de transporte, como HTTP, SMTP, TCP etc.
  • REST (Representational State Transfer) é uma estilo de arquitetura para serviços web. APIs que fazem o uso dessa arquitetura são chamados APIs RESTful. Seu protocolo de transporte é necessariamente HTTP/HTTPS e APIs RESTful podem utilizar diferentes formas de transferncia de dados, como JSON, XML e YAML. Ela segue 6 princípios:
    • Arquitetura cliente-servidor
    • Sem monitoramento de estado
    • Capacidade de cache
    • Sistema em camadas
    • Código sob demanda (opcional)
    • Interface uniforme

Materiais adicionais

Aula 6: Deauthentication Attack em Redes Wi-Fi

Protocolo 802.11

O protocolo 802.11 é o que se conhece por wifi. Ele especifica como a informação deve ser organizada ao ser transmitida de uma placa de rede para outra.
Esse ataque se utiliza de uma falha de segurança (ou feature ?) nos pacotes 802.11 onde os pacotes do tipo "Deauthenticate"

Informações importantes

É importante estar familiarizadx com a maneira pela qual as interfaces de rede, bem como os modos de operação de placas de rede sem fio (managed e monitor).

O ataque

Primeiramente devemos iniciar uma interface em modo monitor.
1
# iw list
Copied!
O comando
1
# iw dev wlan0 interface add mon0 type monitor
Copied!
irá adicionar uma interface virtual funcionando em modo monitor. Podemos comprovar isso com
1
# ifconfig
Copied!
que agora deve listar a nova interface.
Agora utilizaremos alguns programas da suite -ng.
1
# airodump-ng mon0
Copied!
faz uma varredura dos canais suportados atualmente pela placa de rede (de acordo com a configuração de país ???), e mostra um sumário de cada BSS e suas respectivas estações conectadas. É possível utilizar argumentos de filtro caso necessário.
Com nosso alvo escolhido, isto é, seu BSS ou BSS + MAC encontrados, podemos começar o ataque. O seguinte comando irá enviar pacotes de desautenticação como se fosse o BSSID especificado. É possível passar o MAC da estação de destino também, com a flag -c
1
# aireplay-ng -0 0 -a xx:xx:xx:xx:xx:xx -c xx:xx:xx:xx:xx:xx
Copied!

Troubleshooting

  • "Meu aireplay não vai"
    Verifique se o canal da interface é o mesmo do BSS
  • "Device is busy ou algo do tipo"
    Se você adicionou uma interface virtualmente, ela funciona de modo mutex com a interface real. Desative a wlan0 da vida com
    1
    # ifconfig wlan0 down
    Copied!

Materiais adicionais

Aula 7: WPS, PIN codes, Reaver e Pixie Dust

Um mecanismo ainda razoavelmente comum em redes wi-fi é a presença de Wi-fi Protected Setup (WPS). No entanto, essa técnica permite fazer ataques muito simples para se quebrar a senha de uma rede Wi-fi.

WPS: Wi-fi Protected Setup

O WPS foi criado com o intuito de facilitar configuração e conexão de hosts em redes wi-fi usando apenas um código numérico de 8 dígitos: o PIN code. Cada rede wi-fi com WPS habilitado (WPS-enabled wi-fi) possui um único PIN code, e é possível se conectar nela ou pela senha (normalmente), ou passando o PIN code para o Access Point.
Existem três agentes importantes no WPS, são eles: o Access Point (ou AP), o Enrollee (quem quer se conectar), e o Registrar (a entidade responsável por dar ou revogar acesso à rede). Em geral, o Registrar nada mais é do que um software rodando no AP, mas é importante salientar que ele pode estar em um outro dispositivo.
Obs: WPS independe do método de autenticação da rede wi-fi. Por exemplo, é possível ter uma rede WPA cujo método de autenticação é Pre-Shared Key (PSK), ou seja, uma rede WPA/PSK, que mesmo assim utilize WPS para facilitar a configuração e futuras conexões na rede.

O problema com WPS

O PIN code é composto por 8 dígitos numéricos, sendo que o último desses dígitos é um checksum dos 7 anteriores. Quando um Enrollee quer se conectar na rede usando um PIN code, ele precisa seguir todo o protocolo WPS, que em geral envolve 7 mensagens (de M1 a M7):
Se, apos enviarmos a mensagem M4, a primeira metade do PIN code estiver incorreta, recebemos um NACK. Da mesma maneira, se enviarmos a primeira metade do PIN correta mas a segunda incorreta, recebemos um NACK após M6. Isso torna possível fazer um ataque de força bruta em que enviamos todas as possibilidades da primeira metade do PIN (de 0000 até 9999). Depois de acertarmos a primeira metade do PIN, repetimos o processo para a segunda metade. No entanto, como o último dígito do PIN é um checksum (ou seja, apenas uma conta feita com os primeiros 7), basta chutarmos 3 dígitos nessa parte (de 000[checksum] até 999[checksum]).

Primeiro ataque: Reaver

O reaver é uma ferramenta que vem por padrão junto com o Kali e serve justamente para realizar o brute force (online) descrito acima. No pacote do reaver do Arch vem também o wash, que nos permite listar todas as redes wi-fi próximas com WPS habilitado.
1
$ sudo wash -i <sua interface wireless>
2
$ sudo wash -i wlan0
3
​
4
BSSID Ch dBm WPS Lck Vendor ESSID
5
--------------------------------------------------------------------------------
6
7C:05:07:F6:EE:84 1 -90 2.0 No Broadcom HAL_9000
7
D4:B9:2F:2B:9D:2A 1 -92 2.0 No Broadcom 2.4G_gobbs
Copied!
Nesse exemplo, encontramos duas redes: HAL_9000 e 2.4G_gobbs. Vamos agora atacar a primeira delas (HAL_9000) usando o reaver:
1
$ sudo reaver -i <sua interface wireless> -b <BSSID do alvo> -vv
2
$ sudo reaver -i wlan0 -b 7C:05:07:F6:EE:84 -vv
Copied!

Segundo ataque: Pixie Dust

A implementação desse ataque se baseia em uma falha de implementação da geração de números pseudo aleatórios (PRNG) em vários APs, gerando PRN inseguros.
Na mensagem M1, que o Enrolee envia para o quem quer se conectar, um número (Nonce) é passado. E na mensagem M3, é enviado E-Hash1 (hash para a primeira mensagem do pin) e a E-Hash2 (hash para segunda metade do pin).
O problema nessa implementação é que Nonce, e as chaves que geram E-Hash1 e E-Hash2 (chamadas, E-S1 e E-S2) são geradas em sequência. Nesse sentido, se usarmos força bruta para descobrir o state do PRNG, poderemos gerar E-S1 e E-S2 a partir de Nonce. Em seguida, chutamos Pin1 e Pin2.
Utilizaremos o reaver novamente para o Pixie Dust. Para isso, basta usar o comando anterior, mas com a flag -K 1 (note o espaço entre -K e 1.
1
$ sudo reaver -i wlan0 -b 7C:05:07:F6:EE:84 -vv -K 1
Copied!

Materiais adicionais

Aula 8: DHCP Exhaustion/Starvation

Imagine que nossa heroína, Merindrola, acabou de chegar na sua casa e quer conectar o celular dela na rede Wi-Fi. Você então ajuda a nossa nobre salvadora dos exemplos didáticos e dá a senha da rede, ela digita no celular e...
E daí? O que acontece depois?
Você deve saber que a grande maioria das redes atualmente usam o protocolo IP, seja ele v4 ou v6, e que para que dois hosts consigam conversar usando esse protocolo cada um deles dever ter um endereço IP, mesmo que privado (tipo 192.168...). Então, o que acontece quando a Merindrola se conecta na sua rede é que ela precisa saber (1) qual o IP do roteador, que chamaremos de gateway, para o qual ela vai encaminhar pacotes para redes externas, (2) qual o endereço do servidor DNS que ela deve usar quando quiser resolver nomes e, finalmente, (3) qual o endereço IP que o celular dela deve usar, de maneira que seja único e respeite as restrições da rede (máscara, bits de rede e de host, etc.).

DHCP: Dynamic Host Configuration Protocol

O DHCP é o protocolo que facilita tudo isso, de forma que não seja preciso que cada um dos usuários da rede configurem manualmente todas essas variáveis. Se houver um servidor DHCP na rede, qualquer host conseguirá informações básicas de configuração automaticamente.
A figura abaixo, retirada do RFC da especificação do DHCP, ilustra o processo de descoberta do servidor DHCP e aquisição das configurações de um cliente em uma rede onde há dois servidores DHCP.
1. DHCP DISCOVER: O cliente recentemente conectado na rede envia um pacote no endereço de broadcast procurando algum servidor DHCP.
2. DHCP OFFER: Dois servidores localizados na rede geram configurações para o cliente e as enviam diretamente para ele. Daqui em diante mais nenhuma mensagem é trocada no endereço de broadcast.
3. DHCP REQUEST: Cliente responde para apenas um dos servidores, indicando que ele escolheu as configurações daquele servidor.
4. DHCP ACK: Servidor escolhido responde ao DHCP REQUEST, indicando que ele o recebeu e reservou as configurações para aquele cliente.
5. DHCP RELEASE: Finalmente, ao se desconectar, o cliente responde com uma mensagem liberando aquelas configurações, para que outro host consiga usá-las no futuro.

DHCP Pools

Nos servidores DHCP existem pools, ou piscinas, de endereços IP. Estas contêm todos os IPs da faixa de endereços que o servidor pode distribuir para os clientes.
A vantagem de se ter diferentes pools é que é possível reservar faixas de IPs para determinados tipos de dispositivos. Por exemplo, todos os celulares ocuparão uma determinada faixa, ou todos os dispositivos da gerência ocuparão uma faixa específica.

O ataque

Como vimos, a faixa de IPs de uma DHCP pool é limitada. O ataque que faremos, o DHCP Starvation/Exhaustion/Depletion, busca fazer com que o computador do atacante se passe por diversos clientes distintos e, dessa forma, faz com que ele seja capaz de reservar toda a faixa de IPs disponíveis na DHCP pool. Os demais clientes ficarão sem conseguir obter um endereço IP e não conseguirão se comunicar na rede.
Se você está pensando que esse ataque é muito parecido com o DoS (Denial of Service), é porque ele é, de fato, um tipo de DoS.
Se não sabe o que é um DoS, leia a Aula 4: DoS, DDos, ADoS e Slow Lorris.

Motivação

Em sequência a esse ataque, geralmente o atacante fará outro ataque, e esse sim pode causar danos reais.
Um ataque que comumente segue após o DHCP Starvation é um do tipo MITM (Man In The Middle) chamado Rogue DHCP (Se não sabe o que é MITM, leia a aula Aula 2: Bettercap, MITM e Spoofing).
O ataque Rogue DHCP (DHCP intruso) consiste em, após esgotar todos os IPs livres no servidor DHCP legítimo, subir outro servidor DHCP, dessa vez controlado pelo atacante.
Como o servidor legítimo não possui IPs livres, pode ser que a implementação dele não responda com DHCP OFFER os DHCP DISCOVERs enviados, deixando o caminho livre para o atacante oferecer o "serviço de DHCP" dele.
Nesse cenário, o servidor malicioso pode oferecer uma configuração em que o endereço do gateway seja o computador do atacante. Desse modo, o ataque segue justamente como um MITM tradicional visto na Aula 2 (usando ARP Spoof).
A fins de ilustração, uma das possíveis consequências é a leitura de pacotes sem protocolo de criptografia, de modo a expor dados como nomes de usuário, senhas, números de cartão de crédito, etc... (por exemplo, uma conexão com um site por HTTP em vez de HTTPS não possui criptografia e pode ser lida por um MITM).
OBS: Se você quiser saber mais sobre HTTP ou HTTPS, leia a Aula 4: SSL/TLS, HTTP/HTTPS e HSTS.

Na prática

Para realizar o ataque, vamos usar o DHCPig. Para rodar o DHCPig é preciso ter instalado o Python 2, Pip e a biblioteca Scapy para o Python 2. Um problema conhecido é que a versão mais recente do Scapy para o Python 2 não funciona com o DHCPig. Então, é preciso instalar a versão 2.3.3:
1
$ pip2 install scapy==2.3.3
Copied!
Clonamos o respositório do GitHub do DHCPig e entramos nele:
1
$ git clone https://github.com/kamorin/DHCPig.git
2
$ cd DHCPig
Copied!
Finalmente, rodamos o programa:
1
$ sudo python2 pig.py <IP do servidor DHCP>
Copied!

Materiais adicionais

Aula 9: IPv6 Neighbor Cache Exhaustion

Aula 10: IPv6 Neighbor Cache Exhaustion

IPv6 Subnetting

NDP: Neighbor Discovery Protocol

Neighbor Cache

1
sudo atk6-ndpexhaust6 <dev> <link-address>
Copied!

Referências

Aula ?: Packet capturing, APs e servidores -- Montando ambientes de teste

  • Hostapd
  • Nginx
  • goloris
  • Wireshark

Aula ?: Redes Peer-to-Peer (Matrix, BitTorrent, Kademlia, IPFS)

Aula ?: Virtual Private Network: Conceitos básicos, funcionamento, segurança e exemplos com Wireguard

Previous
VPN
Next
Web
Last modified 2yr ago
Copy link
Contents
Aulas Ganesh Redes 2019
Sumário
Aula 1: Introdução -- Protocolos, TCP/IP, NAT, Endereçamento
Aula 2: Bettercap, MITM e Spoofing
MITM (Man in the middle)
Aula 3: DoS, DDoS, ADoS e Slow Lorris
Aula 4: SSL/TLS, HTTP/HTTPS e HSTS
Aula 5: Coisas importantes que você precisa saber sobre a Internet
Aula 6: Deauthentication Attack em Redes Wi-Fi
Aula 7: WPS, PIN codes, Reaver e Pixie Dust
Aula 8: DHCP Exhaustion/Starvation
O ataque
Aula 9: IPv6 Neighbor Cache Exhaustion
Aula 10: IPv6 Neighbor Cache Exhaustion
IPv6 Subnetting
NDP: Neighbor Discovery Protocol
Neighbor Cache
Aula ?: Packet capturing, APs e servidores -- Montando ambientes de teste
Aula ?: Redes Peer-to-Peer (Matrix, BitTorrent, Kademlia, IPFS)
Aula ?: Virtual Private Network: Conceitos básicos, funcionamento, segurança e exemplos com Wireguard