Ataque Distribuído de Negação de Serviço por Reflexão Amplificada usando Simple Network Management Protocol

Transcrição

1 Ataque Distribuído de Negação de Serviço por Reflexão Amplificada usando Simple Network Management Protocol Tiago Fonseca Medeiros 1, João José Costa Gondim 1 1 Departamento de Ciência da Computação Universidade de Brasília (UnB) Brasília, DF Brazil tiagofmedeiros@aluno.unb.br, gondim@cic.unb. Abstract. This paper presents a study about the Simple Network Management Protocol (SNMP) amplified reflection distributed denial-of-service attack. The SNMP version studied was SNMPv2c. This version combines weak security, used in version one, with the GetBulkRequest command, added in version two, which is able to provide significant amplification. To better understand the attack a software was developed. It was able to detect possible reflectors and to perform the attack with different intensities. Two types of tests were performed. The first one was a functionality test that examined the attack properties. The second, a performance test, verified the capacity of the software and the saturation point of all devices involved. Resumo. Este trabalho apresenta um estudo do ataque distribuído de negação de serviço por reflexão amplificada usando o Simple Network Management Protocol (SNMP). A versão do SNMP estudada foi a SNMPv2c, por combinar a fraca segurança, utilizada na versão um, com o comando GetBulkRequest, adicionado a partir da versão dois e que é capaz de proporcionar uma amplificação significativa. Para o estudo foi desenvolvida uma ferramenta capaz de detectar possíveis refletores e de realizar o ataque em diferentes intensidades. Foram realizados dois tipos de teste. O primeiro foi um teste de funcionalidade, que analisa as propriedades do ataque. O segundo teste, de performance, verificou a capacidade da ferramenta além da saturação dos dispositivos envolvidos. 1. Introdução É notável o crescimento da importância da Internet, para a sociedade, durante os últimos anos. Diariamente pessoas têm acesso a diversos serviços, como redes sociais, bancos e compras, que estão disponíveis na Internet. Entretanto, a disponibilidade desses serviços pode ser ameaçada por vários tipos de ataques como, por exemplo, a negação de serviço. Um ataque de negação de serviço (DoS - Denial of Service) tem por objetivo esgotar os recursos de um equipamento ou infraestrutura, que fornece ou utiliza um serviço, visando sua indisponibilidade. Os ataques consistem no envio de um número de requisições que não conseguem ser processadas ou que esgotam o limite de tráfego [McDowell 2009]. Outro tipo de negação de serviço é a negação distribuída (DDoS - Distributed Denial of Service). Esse tipo de ataque utiliza os mesmos princípios da negação de serviço, mas com um número de máquinas executando o ataque de forma coordenada para aumentar consideravelmente sua eficiência e ofuscar sua origem.

2 Assim, o objetivo do trabalho foi estudar um tipo de ataque específico, o ataque de negação de serviço por reflexão amplificada usando o Simple Network Management Protocol (SNMP) devido a sua execução frequente desde 2014 [Prolexic 2015]. Para isso, uma ferramenta capaz de realizar o ataque foi desenvolvida. Em seguida, uma série de testes foram realizados, em ambientes controlados, avaliando assim as propriedades do ataque. Este trabalho está organizado em seções. Na próxima seção, aborda-se ataques de negação de serviço por reflexão amplificada e o protocolo SNMP; na seguinte, apresentase a implementação da ferramenta desenvolvida; na Seção 4, são discutidos os resultados e a análise de todos os testes realizados; por fim, as conclusões e propostas para trabalhos futuros são abordadas na Seção 5. Enfatizamos que este trabalho foi desenvolvido com fins acadêmicos para efeito de demonstração das vulnerabilidades estudadas. Os autores não se responsabilizam por qualquer uso inapropriado, inadequado ou ilegal que venha a extrapolar tais objetivos. 2. Quadro conceitual 2.1. Negação de serviço distribuída por reflexão amplificada Existe uma variedade muito grande de ataques de negação de serviço distribuídos. Entretanto, podemos organizá-los em duas grandes categorias: abuso de protocolo e volumétricos. A primeira categoria diz respeito aos ataques que, com a ajuda de características específicas de protocolos e suas implementações, esgotam os recursos da vítima de modo que ela não consegue mais disponibilizar seus serviços. A segunda compreende os ataques que enviam uma quantidade muito grande de tráfego para a vítima exaurindo algum recurso, como banda, ou impedindo que tráfego legítimo passe. Em ataques de negação por abuso de protocolo um atacante se utiliza maliciosamente de alguma característica do protocolo de comunicação usado ou de sua implementação. Dessa forma, pode-se classificá-los em exploração de protocolo e exploração de vulnerabilidade. Como exemplo, o Slowloris, que consiste em enviar GETs em vários segmentos cujo path do recurso não se completa, é um ataque que abusa o HTTP. Por outro lado, o Ping-of-Death é um ataque de exploração de vulnerabilidade [Kenney 1996]. Mais próximos do nosso interesse, os ataques de negação de serviço volumétricos podem ser divididos em ataques de inundação (flooding) e ataques de reflexão amplificada. Ambos os ataques visam sobrecarregar algum recurso da vítima, geralmente a banda disponível, pelo envio de grandes quantidades de tráfego, sendo que os ataques de negação por inundação utilizam computadores comprometidos para enviar altas quantidades de tráfego para uma vítima, a fim de esgotar sua banda, e os ataques de reflexão amplificada usam os refletores para isso. Refletor é qualquer dispositivo que ao receber um datagrama IP retorna outro como resposta, se tornando mais interessantes quando possuem um fator de amplificação. Esse fator indica quanto de tráfego o refletor gera em relação ao que recebe. Com a amplificação, o tráfego gerado pelo atacante será potencializado no refletor [Paxson 2001]. Uma característica que vários ataques de negação compartilham, em especial os de reflexão amplificada, é o IP spoofing. O IP spoofing é realizado modificando o campo

3 Source IP Address do cabeçalho IP. Nos ataques de reflexão amplificada, esse campo é alterado com o valor do IP da vítima. Desse modo, quando o refletor recebe o pacote ele irá enviar a resposta amplificada para a vítima, caracterizando o ataque [Ali 2007]. Os mais conhecidos protocolos para negação de serviço por reflexão amplificada são o Domain Name System (DNS) e o Netwrok Time Protocol (NTP). Ambos possibilitam que pequenas mensagens gerem respostas muitas vezes maiores. Entretanto, o SNMP também tem essas características [Rossow 2014] O Simple Network Management Protocol O SNMP é um protocolo para gerenciamento de redes que define uma maneira universal para que informações de controle possam ser definidas para algum dispositivo e como transferir essas informações entre esse dispositivo e o dispositivo de gerenciamento [Case et al. 1990]. Em sua primeira versão, o SNMP usava community strings como mecanismo de segurança. Todas as mensagens trocadas deveriam conter esse nome de comunidade e as que continham nomes errados eram simplesmente descartadas. Essa estratégia, embora sirva como um tipo de proteção, é bem limitada. Os nomes de comunidade são passados em claro na rede e podem ser capturados por todos que vierem a observá-lo. Além disso, muitos dispositivos que utilizam SNMP são configurados com os nomes padrões de comunidade: public para leitura e private para escrita, abrindo caminho para que usuários não autorizados alterem o funcionamento dos dispositivos vulneráveis. Na segunda versão do SNMP foi introduzida a operação GetBulkRequest para facilitar e agilizar o pedido de informações pelas estações de gerenciamento, gerando respostas bem maiores que as consultas. Assim, o GetBulkRequest também pode ser usado como um comando de amplificação, pois uma mensagem pequena pode gerar uma outra, substancialmente maior, em resposta. Como essa operação só existe nas versões 2 e 3, o ataque só pode ser realizado nessas versões e precisaria burlar as respectivas seguranças. Entretanto, na versão SNMPv2c [Case et al. 1996] existe o GetBulkRequest e a segurança implementada é a mesma da versão 1, sendo ainda muito usada. Portanto, a combinação da operação GetBulkRequest e da fraca segurança da versão SNMPv2c fazem com que o protocolo SNMP seja explorável em ataques de negação de serviço por reflexão amplificada. 3. Ferramenta - SNMP Striker Para o melhor entendimento do ataque foi desenvolvida uma ferramenta capaz de detectar possíveis refletores, utilizando a operação GetNextRequest que pede apenas uma informação para o dispositivo gerenciado, e realizar o ataque pelo GetBulkRequest, com os melhores argumentos para potencializar a amplificação. A ferramenta foi implementada na linguagem de programação Java integrada com a linguagem C. Java foi utilizada devido a sua portabilidade e facilidade de criação de interfaces gráficas. Por outro lado, a linguagem C provê rápida execução e total controle de todas os bits do pacote enviado pela rede.

4 A Figura 1 mostra a interface gráfica desenvolvida. A partir dessa interface é possível adicionar e remover refletores, acompanhar os refletores encontrados, importar e exportar os dados dos refletores, escolher o alvo do ataque, selecionar a intensidade e realizar o ataque. Figura 1. Interface gráfica da ferramenta desenvolvida. Para adicionar novos dispositivos o usuário deve clicar no botão Add. Uma nova tela será aberta com as configurações de descoberta. O usuário deve então selecionar: o IP base para a descoberta de novos dispositivos, em qual sub rede deve-se procurar dispositivos (/24 ou /16), quais valores de comunidades a ferramenta deve usar, sendo que o padrão é public e o número de mensagens que devem ser enviadas caso um timeout ocorra e nenhuma resposta seja recebida. Quando um dispositivo responde à mensagem GetNextRequest isso indica que ele é um possível refletor, pois conseguiu-se encontrar o valor correto de comunidade. Depois de encontrar possíveis refletores a ferramenta faz o cálculo da amplificação disponível em cada um. A amplificação é feita por meio da mensagem GetBulkRequest. Pelo GetBulkRequest envia-se uma lista de identificadores de variável e os parâmetros Non Repeaters e Max Repetitions. O dispositivo gerenciado toma o valor das primeiras n variáveis da lista, onde n é o valor de Non Repeaters e para as demais variáveis pega o valor das próximas m iterações a partir delas, onde m é o valor de Max Repetitions. Para gerar uma mensagem com o maior fator de amplificação envia-se o identificador de apenas uma variável, escolhe-se o zero para o Non Repeaters indicando que é para fazer iterações nessa variável com o valor de Max Repetitions. A decisão do valor correto de Max Repetitions é um grande desafio. Quando um nó gerenciado recebe um GetBulkRequest ele coloca em uma única resposta todas as informações que foram pedidas. Entretanto, caso essa mensagem extrapole o tamanho máximo de um datagrama IP ( bytes) nada será retornado. Logo, o melhor valor é aquele que gera uma resposta próxima dos 65 mil bytes em tamanho, mas sem ultrapassar o limite. Um agravante dessa situação é que dispositivos possuem informações diferentes. Desse modo, um mesmo valor de Max Repetitions irá formar dois tamanhos diferentes de reposta. Para contornar essa situação é utilizado um cálculo progressivo. O cálculo progressivo se baseia em enviar mais de uma mensagem de GetBulkRequest e ir aumentando o valor do Max Repetitions progressivamente. Dessa forma, testa-

5 se os limites do dispositivo. Essa abordagem gera mais tráfego do que escolher um único valor mas garante que todos os dispositivos tenham uma melhor amplificação. Esse cálculo é transparente para o usuário que vê apenas o melhor valor de amplificação, isso é um diferencial comparando com outras ferramentas [Prolexic 2015]. Depois do cálculo da amplificação, os refletores encontrados são mostrados na interface gráfica da ferramenta e podem ser selecionados para uso no ataque. Após selecionar um refletor e um alvo basta escolher a potência do ataque e clicar no botão Strike para que o ataque se inicie. A ferramenta foi desenvolvida com 10 níveis de intensidade. A cada nível de intensidade o número de pacotes por segundo enviados pela ferramenta é multiplicado por 10. No primeiro nível é enviado um pacote por segundo e no 10 seriam enviados um bilhão de pacotes por segundo. Essa escala de dez níveis foi criada para que o efeito de saturação pudesse ser melhor observado e para futuras evoluções de hardware e infraestrutura. 4. Testes e Resultados Foram realizados dois conjuntos de testes. O primeiro, de funcionalidade, visava verificar se os princípios do ataque estão sendo observados. O segundo, de performance, exercitou os limites da ferramenta e dos refletores à medida em que o ataque de negação de serviço se intensificava. Não foram encontrados trabalhos ou ferramentas similares a esse para a realização de comparações Configuração de teste Os testes foram realizados em um ambiente controlado, com o analisador de protocolos Wireshark posicionado para a captura e análise do tráfego. A Figura 2 demonstra o posicionamento e a função de cada dispositivo durante o teste. Utilizou-se um refletor nos testes pois o objetivo geral do trabalho é evidenciar a dinâmica da geração de fluxo do ataque. Todos os testes foram executados em três baterias. Figura 2. Disposição de computadores para o teste de funcionalidade. Onde, Switch - Roteador Wireless N 150 Mbps da Multilaser e Switch 48 portas Enterasys C-Series C5G124-48P2 1 Gbps; Atacante - MAC OSX, 2.3GHz Intel Core i7, 16GB DDR3, 100Mbps; Refletor - Windows bits, 1.6GHz Intel Core i5, 4GB DDR2, 100Mbps; Vítima - Windows 7 64 Bits, 3.4GHz Intel Core i7, 8GB DDR2, 100Mbps.

6 4.2. Teste de funcionalidade O teste de funcionalidade teve como objetivo comprovar dois princípios do ataque: a reflexão e a amplificação. Na Figura 3 pode-se ver o atacante injetando datagramas destinados ao refletor com IP de origem da vítima. A Figura 4 mostra o tráfego sendo amplificado, no refletor, e redirecionado para a vítima. Por fim, na Figura 5 tem-se o tráfego chegando à vítima. Figura 3. Captura no computador de ataque. Figura 4. Captura no computador refletor. Figura 5. Captura na vítima A reflexão é comprovada pelas capturas, onde é possível ver que o computador de ataque gera mensagens GetBulkRequest com o endereço IP de origem da vítima. Para o cálculo da amplificação, temos que o tamanho do datagrama SNMP enviado é de 79 bytes. A mensagem GetResponse gerada como resposta à operação GetBulkRequest é a junção de vários fragmentos IP e tem bytes de tamanho total. Logo, temos uma amplificação de , desconsiderando o cabeçalho Ethernet. Observa-se que a amplificação não é somente de bits mas também de pacotes devido a fragmentação da resposta. Assim, podemos concluir que a ferramenta obteve todos os resultados esperados durante o teste de funcionalidade e, de fato, observa-se o ataque de reflexão amplificada pelo SNMP Teste de performance O teste de performance foi elaborado com a mesma configuração do teste de funcionalidade. Entretanto, ele foi executado duas vezes. A primeira, a partir de agora denominada teste 1, com o Roteador da Multilaser e outra, teste 2, com o Switch da Enterasys. Essa comparação foi feita para verificar uma possível saturação no switch da Multilaser devido a sua modesta capacidade. Durante o teste, a potência da ferramenta foi aumentada gradualmente passando por todos os níveis. Cada nível de intensidade da ferramenta foi medido durante 30 segundos e depois calculada a média por segundo. Durante todos os testes só foi analisado o fluxo SNMP, ou seja, tráfego ICMP e outros foram desconsiderados.

7 Análise da performance do computador de ataque A performance do computador pode ser observada pelo gráfico da Figura 6, onde tem-se a relação de megabit por segundo e pacotes por segundo enviados pela ferramenta. Pode-se verificar que a ferramenta satura sua capacidade de envio perto dos 200 Mbps. Entretanto, a taxa de envio do computador de ataque é limitada pela interface de saída em 100 Mbps. O valor de 200Mbps é explicado, pois a ferramenta de análise de protocolo, Wireshark, captura os datagramas enviados entre o sistema operacional e o hardware de rede. Figura 6. Bits e datagramas por segundo enviados pelo atacante Análise da performance do switch O switch foi o equipamento responsável por transferir os dados entre os três computadores do teste. O gráfico da Figura 7 representa a quantidade de tráfego enviado pelo atacante que chegou no refletor. Pode-se verificar que, a partir do nível 6, a diferença entre quantos bits o computador de ataque envia e quantos bits o computador refletor recebe é muito grande. Claramente está ocorrendo uma saturação. A saturação pode ser do computador de ataque, que não está conseguindo enviar essa quantidade de bits, ou do switch, que não consegue encaminhar todo esse tráfego para o refletor. A quantidade de bits recebida pelo refletor nos dois testes é muito semelhante. Houve uma diferença de 4,51% entre os switches. Por esse motivo, espera-se uma saturação maior, se não for total, no computador de ataque do que nos switches. O gráfico da Figura 8 mostra a quantidade de bits enviada pelo refletor e recebida pela vítima. Observa-se que a vítima recebe praticamente o que o refletor envia. Isso demonstra que não houve saturação na passagem de tráfego do refletor para a vítima Análise da performance do refletor e da vítima O refletor é o dispositivo que recebe o tráfego gerado pelo atacante, amplificando-o e enviando para a vítima. O gráfico da figura 9 mostra a performance do refletor durante os

8 Figura 7. Quantidade de bits enviados pelo computador de ataque e recebidos pelo refletor. Figura 8. Quantidade de bits enviados pelo refletor e recebidos pela vítima. dois testes. Nesse gráfico temos a comparação da quantidade de bits recebidos e enviados pelo refletor. Até o nível 5, a quantidade de bits enviada pelo refletor era maior do que a recebida, caracterizando uma amplificação. A partir do nível 6, o refletor passou a receber mais bits do que envia. O motivo desse fenômeno é que, embora o refletor tenha uma amplificação maior que 1, ele tem um limite para a quantidade de datagramas que consegue amplificar. Isso ocorre porque o processamento do GetBulkRequest não é instantâneo e o refletor perde um determinado tempo coletando todas as informações para enviar o GetResponse. Essa saturação mostra que a amplificação não é o único parâmetro relevante sobre os refletores. Devemos também considerar a capacidade de cada refletor em coletar as informações e responder. O dispositivo utilizado como refletor foi um dispositivo atípico para uso do SNMP. Dispositivos típicos, como roteadores e switches, possuem menos poder computacional, mas possuem uma implementação mais otimizada. Dessa forma, acredita-se que a saturação, devido à busca de informações no refletor, possa demorar mais a ocorrer em dispositivos otimizados para o SNMP. Um dispositivo atípico foi utilizado para mostrar

9 Figura 9. Quantidade de bits recebidos e enviados pelo refletor. que a amplificação por SNMP pode alcançar valores muito altos. O computador vítima apenas recebe as mensagens amplificadas do refletor. O total de bits recebido em cada nível do ataque pode ser visto no gráfico da Figura Análise final Com os testes de funcionalidade e performance, percebe-se que o ataque utilizando o SNMP possui as características de um ataque de reflexão amplificada e pode alcançar altos valores de amplificação. Entretanto, mostrou-se que a amplificação não é sustentável devido à saturação dos refletores ao compilar todos os dados pedidos no GetBulkRequest. O gráfico da Figura 10 apresenta os valores de amplificação alcançados. Esse gráfico mostra como a amplificação não se sustenta à medida que os níveis vão aumentando. Essas informações podem abrir espaço para novas técnicas de mitigação quando sob ataque, sendo um tópico que merece estudo mais aprofundado. Figura 10. Valor da amplificação para bits e datagramas

10 5. Conclusão Apresentou-se, neste trabalho, as principais características para ataques de negação de serviço por reflexão amplificada utilizando o protocolo SNMP. Dois testes foram realizados. O teste de funcionalidade comprovou os princípios de amplificação e reflexão do ataque. O teste de performance verificou que o limite de envio da ferramenta foi de aproximadamente 200 Mbps com saturação devido ao hardware, os switches utilizados tiveram um desempenho semelhante e o refletor não conseguiu amplificar todo o tráfego destinado a ele devido ao tempo de processamento do GetBulkRequest. Assim, se constatou que o ataque, apesar do seu potencial nocivo, não é muito sustentável. Alguns outros possíveis desdobramentos deste tranalho são: a extensão da ferramenta, implementando outros vetores de ataque como o DNS, o NTP e o Simple Service Discovery Protocol (SSDP); testes com diferentes combinações de variáveis para o Get- BulkRequest que possam produzir uma amplificação mais sustentável, embora menor; e testes com dispositivos diferentes verificando como a configuração de hardware do dispositivo e sua implementação do SNMP influenciam na dinâmica do ataque. References Ali, F. (2007). Ip spoofing. ac147/archived_issues/ipj_10-4/104_ip-spoofing.html. Case, J., Fedor, M., Schoffstall, M., and Davin, J. (1990). Simple Network Management Protocol (SNMP). RFC 1157 (Historic). Case, J., McCloghrie, K., Rose, M., and Waldbusser, S. (1996). Community-based SNMPv2. RFC 1901 (Historic). Kenney, M. (1996). Ping of death. Introduction to McDowell, M. (2009). Understanding denial-of-service attacks. Technical report, Department of Homeland Security United States. Paxson, V. (2001). An analysis of using reflectors for distributed denial-of-service attacks. AT&T Center for Internet Research at ICSI Berkeley, CA USA. Prolexic (2015). Threat advisory: Snmp reflection ddos attacks. Rossow, C. (2014). Amplification hell: Revisiting network protocols for ddos abuse. VU University Amsterdam, The Netherlands.