Ataque Distribuı́do de Negação de Serviço por Reflexão
Amplificada usando Simple Network Management Protocol
Tiago Fonseca Medeiros1 , João José Costa Gondim1
1
Departamento de Ciência da Computação
Universidade de Brası́lia (UnB) – Brası́lia, DF – Brazil
[email protected], [email protected].
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.
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
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].
2.2. 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.
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 (65.535 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-
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.
4.1. 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 8.1 64 bits, 1.6GHz Intel Core i5, 4GB DDR2, 100Mbps;
• Vı́tima - Windows 7 64 Bits, 3.4GHz Intel Core i7, 8GB DDR2, 100Mbps.
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 47.374 bytes de tamanho total. Logo,
temos uma amplificação de 728.61, 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.
4.3. 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.
4.3.1. 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.
4.3.2. 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.
4.3.3. 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
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
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 8.
4.3.4. 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
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 GetBulkRequest 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. http://www.cisco.com/web/about/ac123/
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).
Introduction to
Kenney, M. (1996). Ping of death.
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.