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:
  1. ADD_ADDR Attack
  2. DoS Attack on MP_JOIN
  3. SYN Flooding Amplification
  4. Eavesdropper in the Initial Handshake
  5. SYN/JOIN Attack
Descrição dos ataques:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:
Enviar esta postagem

ComentĂĄrios

Postar um comentĂĄrio

Ebook

Postagens mais visitadas