Distributed Denial of Service Attack (DDoS) with MPTCP, artigo escrito pelo Especialista Carlos Rodrigues
Hoje em dia a importância que se dá a um tipo de ataque deste tipo em segurança da informação é pouca ou nenhuma, até parece conversa de “Script Kids”, mais conhecidos como “Lammers” à uns anos atrás, mas eu prometo que até ao fim deste artigo você vai ficar com a ciência que novos e poderosos ataques estão por florescer (é uma questão de tempo), e no final você vai-me dizer se esta foi uma conversa de Lammer ou não....combinado?!
DDoS significa "Distributed Denial of Service". Um ataque DDoS é uma tentativa maliciosa de tornar um serviço online indisponível para os usuários, geralmente interrompendo temporariamente ou suspendendo os serviços de um servidor de hospedagem.
Ao contrário de um ataque de Negação de Serviço (DoS), no qual um único dispositivo conectado à Internet (uma conexão de rede) é usado para inundar recursos segmentados com pacotes, um ataque DDoS é lançado a partir de vários dispositivos comprometidos, geralmente distribuídos globalmente no que é referido como uma botnet.
Existem vários tipos de ataques de distribuição de serviço, mas o que pretendemos aqui apresentar é um novo “New Kids on the Block” que ainda está para sair, em uma rede perto de si, brevemente!
O seu nome pode ser “batizado” de DDoS over MPTCP, mas porquê?
É isso que vamos já explicar em seguida...
Um dos ataques mais conhecidos por sua eficiência de negação de serviço é o da Figura 1, de nome, inundação SYN, que explora uma fraqueza conhecida na sequência de conexão TCP (o "handshake de três vias"), em que uma solicitação SYN para iniciar uma conexão TCP com um host deve ser respondida por uma resposta SYN-ACK desse host e depois confirmada por uma resposta ACK do solicitante.
Em um cenário de inundação SYN, o solicitante envia várias solicitações SYN, mas não responde ao pacote SYN-ACK do host ou envia as solicitações SYN de um endereço IP falsificado.
De qualquer forma, o sistema host continua a aguardar o reconhecimento de cada uma das solicitações, vinculando recursos até que não haja novas conexões e em última análise, resultando em uma negação de serviço.
Mas isto pode levar algum tempo até acontecer, certo?
-Resposta simples, SIM, pode!
-Resposta Complexa, DEPENDE...vamos por partes.
Vamos analisar primeiramente o que é o MPTCP, para esta análise vamos utilizar um artigo acadêmico Cross-Path Inference Attacks on Multipath TCP que explica bastante bem esta nova tecnologia e alguns vetores de ataque.
Multipath TCP (MPTCP) permite o uso simultâneo de múltiplos caminhos entre dois pontos finais e, como tal, tem como promessa melhorar o desempenho das aplicações. Sabemos que o TCP representa um único caminho, isso significa que pode haver apenas um caminho entre dois dispositivos que têm uma sessão TCP aberta.
Esse caminho é estabelecido como uma sessão de comunicação definida pelo endereço IP de origem e destino dos dispositivos finais do canal de comunicação.
Já no MPTCP, vários caminhos são estabelecidos entre a origem e o destino, utilizando para o efeito redes de meios guiados e não guiados, conforme se pode observar pela Figura 2.
Este tipo de tecnologia é tão poderosa que permite revolucionar muitos datacenters e ISPs em todo o mundo, visando a melhoria das telecomunicações e o desempenho das redes de dados, voz e video.
Pórem, esta tecnologia também permite a introdução de novos vetores de ataque referenciando os ataques DOS e em 4 de Abril de 2014 o Internet Engineering Task Force (IETF) criou um novo grupo de trabalho com o nome de Analysis of MPTCP residual threats and possible fixes draft-bagnulo-mptcp-attacks-01 que tem como objetivo
realizar uma análise das ameaças residuais para o MPTCP, explorando possíveis soluções para eles.
Por meio deste grupo de trabalho, foram levantadas as potenciais ameaças que têm sido estudadas desde 2014, originando em Julho de 2015 um Request for Comment (RFC) 7430 com o nome MPTCP Residual Threats, que pode ser visualizado pelo link em baixo.
Com isto, surgiram 5 potenciais novos ataques que descriminamos brevemente, pela sua complexidade, aconselhamos o estudo detalhado de cada um pelo próprio RFC 7430.
Ataques:
- ADD_ADDR Attack
- DoS Attack on MP_JOIN
- SYN Flooding Amplification
- Eavesdropper in the Initial Handshake
- SYN/JOIN Attack
Descrição dos ataques:
- Sequestro de sessão MPTCP permitindo um ataque do tipo man-in-the-middle (MitM), neste ataque, o atacante usa a opção ADD_ADDR definida no RFC 6824 para seqüestrar uma sessão MPTCP em andamento e se capacitar para executar um ataque man-in-the-middle na sessão MPTCP.
- Ataque de negação de serviço do MPTCP, impedindo Hosts de criar novos subfluxos. Conforme especificado atualmente, a mensagem SYN + MP_JOIN inicial do Handshake para subfluxos adicionais cria o estado no host recebendo a mensagem. Isso ocorre porque o SYN + MP_JOIN contém o token de 32-bit que permite ao receptor identificar a sessão MPTCP e o random nonce de 32-bit usado no cálculo HMAC. Como esta informação não é reenviada no terceiro ACK do handshake de 3 vias, um Host deve criar estado após a recepção de um SYN + MP_JOIN.
- O atacante usa mensagens SYN + MP_JOIN para amplificar o ataque de inundação SYN. Ataques de SYN Flood [RFC4987] usam mensagens SYN para esgotar os recursos do servidor e evitar novas conexões TCP. Um comum mitigação é o uso de cookies SYN [RFC4987] que permitem processamento stateless da mensagem SYN inicial. Com o MPTCP, o SYN inicial pode ser processado de uma forma sem estado utilizando os cookies SYN acima mencionados. No entanto, conforme descrito anteriormente, conforme especificado atualmente, as mensagens SYN + MP_JOIN não são processadas de forma stateless. Isso abre um novo vetor de ataque. O atacante agora pode abrir uma sessão MPTCP enviando um SYN regular e criar o estado associado, mas depois enviar tantas mensagens SYN + MP_JOIN suportadas pelo servidor com combinações de endereço de origem e porta de origem, consumindo sem ter que criar um estado no atacante. Este é um ataque de amplificação, onde o custo no lado do atacante é apenas o custo do estado associado ao SYN inicial, enquanto o custo no lado do servidor é o estado para o SYN inicial mais todos os estados associados com todos os seguintes SYN + MP_JOINs.
- Um espião presente no handshake inicial onde as chaves são trocadas pode seqüestrar a sessão MPTCP a qualquer momento no futuro. Neste caso, o atacante está presente ao longo do caminho quando o 3-way handshake ocorre e, portanto, é capaz de aprender as chaves usadas na sessão MPTCP. Isso permite que o atacante se afaste do caminho da sessão MPTCP e ainda ser capaz de seqüestrar a sessão MPTCP no futuro. Esta vulnerabilidade foi prontamente identificada ao projetar a solução de segurança MPTCP [RFC6181], e a ameaça foi considerada aceitável.
- Um invasor que pode interceptar a mensagem SYN / JOIN pode alterar o endereço de origem que está sendo adicionado. O atacante está presente ao longo do caminho quando a troca SYN / JOIN acontece. Isso permite que o invasor adicione qualquer novo endereço simplesmente substituindo o endereço de origem do SYN / JOIN. Esta vulnerabilidade foi prontamente identificada ao projetar a solução de segurança MPTCP [RFC6181], e a ameaça foi considerada aceitável.
Como considerações finais, podemos observar que estamos presente de novos desafios nas redes convencionais, mas acima de tudo nos novos serviços que são disponibilizados na Cloud, não só pela sua própria natureza, mas porque potencializa em muito este tipo de ataque, contando com poderosos processadores e redes de comunicação sofisticadas de fibra óptica produzindo um throughput bem acima de 40Gbps e 100Gbps, com isto, técnicas antigas de instalação de equipamentos IDS/IPS, firewalls e mesmo técnicas mais avançadas de Route Filtering Techniques (RTBH) e Unicast Reverse Path Forwarding (uRPF) deixam de funcionar e os ISPs utilizando engenharia de tráfego de roteamento Multipath em redes do tipo Multiprotocol Label Switching (MPLS), podem não ser o suficiente para redirecionar/desviar o tráfego para outros canais de comunicação, precisamente porque o MPTCP utiliza essas técnicas para trafegar os seus pacotes na rede.
Pois se imaginarmos que os ataques futuramente vão partir de várias Clouds ao mesmo tempo, infetadas com Botnets conforme Figura 3, como de resto já acontece hoje em dia, quem se lembra da botnet Mirai?
Segundo especialistas o Mirai foi o maior ataque DDoS da história que interrompeu a internet, ele teve contornos ligeiramente diferentes pois se apoiou nos dispositivos da Internet das coisas (IoT) para lançar o seu ataque, estes equipamentos podem ser câmeras digitais de vigilância, leitores DVD, SmartTVs, Frigoríficos inteligentes, APs, etc..., mas este é um outro assunto a ser abordado em futuros artigos.
Como essas clouds vão estar utilizando a multipla diversidade de rotas para alcançar os seus alvos de destino, como se poderá fazer parar um ataque desta magnitude, sem que o alvo seja severamente afetado e que os clientes legitímos continuem a acessar aos serviços da empresa?
Termino este artigo com esta pergunta, pois sei que será tema de muitos debate nos próximos tempos, esperando que a comunidade acadêmica e de pesquisa crie mais debates sobre estas novas tecnologias emergentes, que de uma prespectiva de segurança computacional não são observadas em uma primeira fase de projeto, acabando por ser implementadas nas redes de internet e provedores de serviço, gerando um problema imenso às comunicações de telecomunicações e redes de computadores.
Agora que acabou de ler, ainda acha que ataques de DDoS é conversa de lammer?
Referências:
Comentários
Postar um comentário