Como funcionam as ligações TCP/IP
Transmission Control Protocol/Internet Protocol (TCP/IP) é uma tecnologia linchpin para redes informáticas modernas. É como (na grande maioria das vezes) o seu computador solicita e recebe frequentemente informações através de uma rede e da Internet. Vem completo com verificação de erros, retransmissão de dados em falta/corrupção, e várias outras características importantes que literalmente tornam a Internet tal como a conhecemos fiável e funcional. No entanto, para compreender como está a ser utilizada abusivamente, temos primeiro de compreender como funciona.
Por uma questão de brevidade, não entraremos no processo completo de ligação TCP/IP. Concentrar-nos-emos apenas no processo inicial de aperto de mão TCP de três vias, pois é tudo o que é relevante para o assunto desta escrita.
Anfitriões de uma rede que queiram trocar dados utilizando TCP devem primeiro negociar uma ligação. É aqui que entra em jogo o aperto de mão TCP de três vias. O processo de aperto de mão permite a ambos os anfitriões reconhecer o sucesso do envio e recepção de comunicações em rede, bem como configurar a sua respectiva sessão em antecipação à troca de dados de aplicação.
br>>>/div>
Fig. 1) Aperto de mão TCP de três vias
Na Figura 1, vemos um Cliente estabelecer uma ligação TCP a um Servidor. O primeiro passo é o Cliente enviar um pacote de Sincronização ou SYN. Este pacote tem duas funções principais, a primeira é testar a capacidade de alcançar o recurso remoto. Se este pacote for encaminhado com sucesso, também diz ao Servidor que um Cliente remoto deseja iniciar o processo de negociação da ligação para troca de dados. O Servidor responde emitindo um pacote de Sincronização e Reconhecimento, ou SYN-ACK, dirigido de volta ao Cliente que está a iniciar a ligação. A parte final do aperto de mão de três vias é para o cliente responder ao SYN-ACK com um Reconhecimento final, ou pacote ACK. Uma vez concluído este aperto de mão, a ligação está pronta para ser utilizada pela aplicação para a transmissão bidireccional de dados.
O método mais comum para o transporte de comunicações TCP é através do Protocolo Internet ou IP. Isto significa que os pacotes TCP são comunicados entre o cliente e o servidor usando datagramas IP, endereçados usando endereços IP para cada um dos dispositivos.
Como este ataque funciona
Ataqueiros armam este processo de aperto de mão através de spoofing dos endereços IP de origem dos pacotes SYN. Esta falsificação faz com que o Servidor envie o pacote SYN-ACK para o IP da vítima, que o servidor acredita ter solicitado a inicialização da sessão, actuando como um reflector.
br>>
Fig. 2) Reflexão SYN-ACK
Na Figura 2, é possível ver uma visualização muito simples deste ataque. No entanto, isto não mostra como é um cenário de ataque real. A realidade é que o TCP foi concebido para operar em redes não fiáveis, o que significa que um único SYN falso pode desencadear um servidor para enviar múltiplos SYN-ACKs em sucessão rápida se não receber o ACK final do aperto de mão. O número de SYN-ACKs a enviar e a rapidez de envio é uma métrica configurável, por isso é difícil estimar exactamente quantos SYN-ACKs uma vítima alvo pode receber em relação ao volume de pacotes SYN-ACK falsificados que foram enviados pelos atacantes.
Baixa largura de banda vs alta PPS
SYN-ACK ataques não são os seus típicos ataques de reflexão. Uma das principais atracções dos ataques de reflexão baseados em UDP é o seu factor de amplificação, ou o tamanho do pacote que chega à vítima versus o tamanho do pacote que um atacante deve enviar. Em muitos casos, o factor de amplificação é muitas vezes superior ao do pedido original. No caso da reflexão CLDAP, por exemplo, o pacote resultante é cerca de 50-70x maior do que o pacote que o agressor deve enviar para desencadear a reflexão. Os ataques de amplificação são frequentemente considerados volumétricos, tipicamente com o objectivo de saturar as ligações de rede utilizadas pelos servidores e aplicações alvo.
No caso de reflexos SYN-ACK, o tamanho do pacote entregue à vítima é quase do mesmo tamanho que o pacote enviado pelo atacante. Dizemos “quase do mesmo tamanho” porque é possível, e muito provável, que enquanto o atacante envia um pacote SYN de comprimento mínimo alguns routers na rede entre o atacante e a vítima possam também modificar o pacote TCP para adicionar informação adicional de ligação, como a opção TCP de Tamanho Máximo do Segmento (MSS), aumentando o tamanho absoluto do tráfego observado pela vítima. Esta opção representa 4 bytes adicionais por pacote, em comparação com o que o atacante enviou.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) SYN-ACK 4 byte amplification
Isto não significa que este ataque não seja uma ameaça. Durante vários ataques coordenados contra clientes Akamai, foram observados múltiplos casos de inundações de pacotes elevados por segundo (PPS) usando tráfego SYN-ACK reflectido. Embora o tráfego de baixa largura de banda seja menos susceptível de saturar as ligações, o PPS elevado pode causar problemas para os equipamentos de rede que tentam processar e encaminhar o dilúvio de SYN-ACKS a correr através das redes.
O que um atacante pode e não pode controlar
Atacantes SYN-ACK dependem das configurações TCP dos seus reflectores e da forma como lidam com as suas ligações TCP. Isto significa que os agressores estão limitados no que podem reflectir para a vítima. Os investigadores da Akamai passaram algum tempo a testar vários serviços TCP expostos em máquinas através da Internet para ver que combinação de bandeiras TCP & opções poderiam resultar nos cenários de ataque mais impactantes. Cobriremos alguns cenários de ataque, como eles diferem, e como os atacantes podem alavancar ataques SYN-ACK no futuro.
TCP Options e SYN-ACKS acolchoados
Attackers não podem controlar o conteúdo de um pacote SYN-ACK. Embora tenhamos visto inundações de SYN-ACK acolchoadas durante anos, a ideia de um SYN-ACK acolchoado não é algo que se espere. No mundo real, quando os ataques SYN-ACK foram lançados, os pacotes que chegaram às redes das vítimas tinham um comprimento previsível de 44 bytes. Como discutido anteriormente, isto informa-nos que os atacantes estavam muito provavelmente a empurrar para fora pacotes SYN sem opção de 40 bytes, com as opções MSS muito provavelmente a serem definidas por equipamentos de rede em trânsito no caminho. Isto resulta num pequeno factor de amplificação, mas queríamos testar quão grandes poderíamos obter SYN-ACKs a partir de servidores reais.
Teste foi conduzido utilizando diferentes variações de opções TCP. O objectivo do teste era poder identificar as opções que poderiam ser utilizadas de forma fiável e resultar numa resposta SYN-ACK maior a partir de servidores escolhidos aleatoriamente em torno da Internet. As opções que poderiam ser utilizadas por um atacante resultando em SYN-ACKs maiores são: Maximum Segment Size (MSS), Timestamp (TS) , Selective ACK (SAckOK), Window Scale (WScale), & TCP Fast Open (TFO) cookies.
Simplesmente, utilizando opções válidas, um atacante poderia consumir aproximadamente 62% mais largura de banda do que com um pacote SYN mínimo (72 bytes vs. 44 bytes). Utilizando estas opções, os cabeçalhos diminuem a taxa de amplificação (10% de amplificação torna-se 6-7%); no entanto, ainda é possível conseguir a amplificação simplesmente omitindo a opção MSS, uma vez que esta será colocada em trânsito independentemente do atacante que a envia ou não.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Fig. 4) SYN-ACK padding com TFO
Teste, foi possível aproveitar o TS, SAckOK, WSCale, & opções TFO TCP (e NOP padding) para emitir um pacote SYN de 68 bytes que resultou numa resposta SYN-ACK de 72 bytes que foi entregue à vítima, como se vê na figura 4. Se um hospedeiro não suportar TFO, um atacante ainda pode empurrar um pacote SYN-ACK de 56 bytes, o que resulta num encaminhamento de 60 bytes SYN-ACK para a rede da vítima, como se vê abaixo na figura 5.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
Fig. 5) SYN-ACK padding menos TFO
SYN-ACK Amplificação
É possível uma pequena quantidade de amplificação usando ataques SYN-ACK, mas é possível aumentar este factor de amplificação visando o espaço IP que é atribuído mas desocupado (o que significa que o IP é encaminhável mas nenhuma máquina está actualmente implantada e/ou tratando o tráfego de rede). Este cenário permite aos atacantes alavancar totalmente os esforços de retransmissão TCP, o que por sua vez aumenta os factores de amplificação e o consumo de largura de banda.
Quando uma máquina normal recebe um SYN-ACK fora de estado de um reflector, responderá com um pacote RST, como mostra a Figura 6. Este pacote RST será recebido pelo reflector, e a sessão TCP no reflector será morta.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) fora do estado SYN-ACK desencadeia uma resposta RST
Se este pacote SYN-ACK for destinado a um endereço IP atribuído mas desocupado, o SYN-ACK será encaminhado (impactando o equipamento de rede pelo caminho) mas nunca chegará a uma máquina real que emitiria um RST. Esta falta de pacote RST fará com que o reflector assuma a entrega falhada do SYN-ACK e inicie tentativas de retransmissão.
Em testes, o número de tentativas de retransmissão é tipicamente entre 5 e 7 pacotes SYN-ACK enviados à vítima para cada SYN enviado. Se assumirmos que um atacante envia um SYN de 40 bytes, podemos esperar que 5-7 44 bytes SYN-ACKs atravessem a rede de vítimas. No pior cenário de 7 pacotes recebidos, isto resulta num pedido de 40 bytes gerando 308 bytes de pacotes que chegam às fronteiras da vítima, um factor de amplificação de 770%. Utilizando cabeçalhos de opções TCP para gerar SYN-ACKs maiores, um atacante poderia empurrar esses números para 56 bytes, resultando em 420 bytes de tráfego reflectido, um factor de amplificação de 750%.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN resulta em 6 SYN-ACKS
TFO, acolchoamento, e amplificação
TCP Fast Open (TFO) está aqui a ser discutido com mais detalhe para cobrir alguns casos interessantes observados nos testes. Usando os cookies TFO, é possível desencadear respostas maiores (12 bytes adicionais por SYN-ACK); contudo, devido a excessos na implementação do TFO, estas medidas podem alterar factores de amplificação e, em diferentes cenários, os ataques activados pelo TFO podem ser mais desejáveis.
Attackers que tentam alavancar os reflectores activados pelo TFO só podem achar que o fazem frutífero em determinadas circunstâncias. Estas circunstâncias seriam casos em que não há espaço IP que não esteja a ser tratado por uma máquina viva, se um atacante tiver de dirigir pacotes SYN-ACK reflectidos em máquinas reais que irão responder com pacotes RST, a amplificação de retransmissão TCP é essencialmente discutível uma vez que o reflector deixará de enviar SYN-ACKs ao receber a resposta RST das máquinas da vítima.
Para tornar esta proposta ainda menos desejável, os anfitriões habilitados para TFO não incluirão a opção de cabeçalho de 12 bytes para o cookie TFO em pacotes SYN-ACK adicionais para além do primeiro pacote emitido. Em suma, o que isto significa é que a amplificação neste cenário não é uma série de pacotes de 72 bytes que atingem a vítima. Em testes reais, observou-se que o primeiro SYN-ACK será de 72 bytes, mas as seguintes 5-6 tentativas de retransmissão omitirão esta opção TCP e resultarão num pacote de 60 bytes. Neste caso, um pacote de 72 bytes resulta numa reflexão de 432 bytes; essencialmente, o único benefício são os 12 bytes adicionais do primeiro pacote versus uma reflexão menos a opção cookie TFO.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Omissão de cookie TFO após a primeira resposta
hospedeiros habilitados para TFO reiniciam as suas medidas de cookie de aperto de mão ao receberem um RST da(s) máquina(s) vítima(s) que está(ão) a ser visada(s). O que isto significa é que um atacante que vise máquinas reais utilizando reflectores TFO activados poderia fazer com que uma série de pacotes de 72 bytes SYN-ACK chegassem aos pontos finais das vítimas.
O factor de amplificação é de apenas 4 bytes, assumindo que um pedido de 68 bytes do atacante resulta num 72 bytes SYN-ACK chegando à vítima seguido de um pacote RST da vítima para o reflector. Se isto acontecer continuamente, então as sessões TCP iniciadas no reflector através do atacante resultarão sempre num pacote SYN-ACK que inclui os bytes adicionais que são a opção cookie TFO.
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) A inclusão de biscoitos TFO após RST
Problemas de mitigação
Mitigar uma reflexão SYN-ACK pode ser complicado e deve ser feito com cuidado. É muito fácil mitigar demasiado este tipo de ataque e causar danos auto-infligidos a clientes reais e sessões TCP através de redes de produção. Estas sessões impactadas traduzir-se-iam em problemas de conectividade, desempenho degradado e bloqueio de hosts/utilizadores legítimos através das suas redes. Estas medidas de sobre-mitigação podem ter efeitos mais longos e de maior impacto do que o próprio ataque.
Em muitos casos, a sobre-mitigação de ataques de impacto TCP também pode ter resultados inesperados para as vítimas. Durante as inundações SYN, por exemplo, é comum que à medida que os serviços reais começam a ter problemas de conectividade, uma onda de ataque secundária parece inchar em toda a rede. Nestes casos, a “segunda onda” é tudo menos um resultado de clientes/utilizadores reais que tentam estabelecer ligações legítimas sem sucesso; isto traduz-se numa ondulação de pacotes SYN superiores aos pacotes SYN normais, uma vez que os clientes afectados continuam a tentar retransmitir os pacotes SYN não-conhecidos.
A atenuação de um ataque SYN-ACK pode provavelmente causar problemas e resultados semelhantes, especialmente se a atenuação estiver a acontecer num ponto da rede onde clientes reais estão a fazer pedidos legítimos de saída.
A verdadeira correcção para ataques de reflexão
Como a maioria dos ataques de falsificação, a verdadeira correcção não é algo dentro de qualquer controlo de uma única organização. Para resolver realmente este e outros problemas associados às capacidades de spoofing precisamos de olhar para a IETF e operadores de rede. A IETF publicou o BCP38, que descreve como os operadores de rede podem identificar e prevenir o encaminhamento de tráfego falsificado. No fim de contas, é algo que os operadores de rede devem implementar e aplicar se realmente esperamos ver estes tipos de ataques de spoofed/reflected desaparecerem, ou pelo menos tornarem-se significativamente mais difíceis de orquestrar.
Síntese de encerramento
Ataques SYN-ACK redireccionados não são algo novo; são na realidade algo tão antigo como o próprio TCP. A sua falta de popularidade tem mais a ver com outros ataques reflectidos baseados em UDP sendo muito mais preocupantes e impactantes e geralmente um melhor conjunto de ferramentas para os atacantes. Não são um efeito secundário de uma implementação deficiente, não são uma exploração, são um sintoma de spoofing IP através da Internet ainda sendo possível quase 20 anos após a solução proposta para proprietários e operadores de rede ter sido elaborada e finalizada.
P>Dito isto, ataques antigos ainda podem ser dolorosos, e os SYN-ACKs reflectidos não são excepção. As organizações devem considerar a possibilidade de analisar as suas capacidades e opções de mitigação, uma vez que o equipamento de rede pode lutar para lidar com grandes inundações de tráfego PPS através de fronteiras e redes.
É importante salientar a possibilidade real de mitigação excessiva de ataques desta natureza e assegurar que as tentativas de combater este tipo de ataques não resultem em interrupções auto impostas… uma tarefa que é muito mais fácil de dizer do que de fazer.