Servidor de ataque PoC para a vulnerabilidade CVE-2015-7547 no resolvedor DNS stub do glibc

Para testar em uma máquina local com uma versão vulnerável do glibc:

user@localhost:/$ echo 'nameserver 127.0.0.127' | sudo tee /etc/resolv.conf
user@localhost:/$ echo 'nameserver 127.0.0.127' | sudo tee -a /etc/resolv.conf
user@localhost:/$ sudo python3 attack-server.py 127.0.0.127
Starting UDP server on 127.0.0.127:53...
Starting TCP server on 127.0.0.127:53...

Em seguida, em outra sessão de terminal, execute os ataques conforme mostrado nos exemplos abaixo.

Ataque 1 (UDP+TCP)

Requer capacidade de enviar respostas > 2048 bytes via UDP e TCP.

Sequência do ataque:

1. Resposta UDP, > 2048 bytes, cabeçalho/pergunta válidos, flag TC definida (aciona má gestão de buffer e nova tentativa TCP)
2. Resposta TCP, cabeçalho/pergunta válidos (força a próxima resposta a ser armazenada em um buffer alocado na pilha)
3. Resposta TCP, > 2048 bytes (estoura o buffer alocado na pilha)

Exemplo:

user@localhost:/$ curl http://attack1
*** stack smashing detected ***: curl terminated
Segmentation fault (core dumped)

Ataque 2 (somente UDP)

Requer capacidade de enviar respostas > 2048 bytes via UDP.

Sequência do ataque:

1. Resposta UDP, > 2048 bytes, cabeçalho inválido (aciona má gestão de buffer, não é contada como resposta válida)
2. Ignorar a próxima solicitação (aciona nova tentativa UDP devido ao tempo limite de polling)
3. Resposta UDP, cabeçalho/pergunta válidos (força a próxima resposta a ser armazenada em um buffer alocado na pilha)
4. Resposta UDP, > 2048 bytes (estoura o buffer alocado na pilha)

Exemplo:

user@localhost:/$ curl http://attack2
*** stack smashing detected ***: curl terminated
Segmentation fault (core dumped)

Ataque 3 (UDP+TCP)

Requer capacidade de enviar respostas > 1024 bytes via UDP e > 2048 bytes via TCP.

Sequência do ataque:

1. Resposta UDP, 1024 bytes, cabeçalho/pergunta válidos (preenche metade do buffer alocado na pilha)
2. Resposta UDP, > 1024 bytes, cabeçalho/pergunta válidos, flag TC definida (aciona má gestão de buffer e nova tentativa TCP)
3. Resposta TCP, cabeçalho/pergunta válidos (força a próxima resposta a ser armazenada em um buffer alocado na pilha)
4. Resposta TCP, > 2048 bytes (estoura o buffer alocado na pilha)

Exemplo:

user@localhost:/$ curl http://attack3
*** stack smashing detected ***: curl terminated
Segmentation fault (core dumped)

Ataque 4 (somente UDP)

Requer capacidade de enviar respostas > 2048 bytes via UDP.

Sequência do ataque:

1. Resposta UDP, 2048 bytes, cabeçalho/pergunta válidos (preenche o buffer alocado na pilha)
2. Resposta UDP (aciona má gestão de buffer e nova tentativa UDP devido ao recebimento de socket de 0 bytes)
3. Resposta UDP, cabeçalho/pergunta válidos (força a próxima resposta a ser armazenada em um buffer alocado na pilha)
4. Resposta UDP, > 2048 bytes (estoura o buffer alocado na pilha)

Exemplo:

user@localhost:/$ curl http://attack4
*** stack smashing detected ***: curl terminated
Segmentation fault (core dumped)

Ataque 5 (somente TCP)

Requer capacidade de enviar respostas > 2048 bytes via TCP e pelo menos duas entradas de servidor de nomes em /etc/resolv.conf.

Sequência do ataque:

0. Resposta UDP, cabeçalho/pergunta válidos, flag TC definida (opcional, aciona nova tentativa TCP se a consulta inicial for via UDP)
1. Resposta TCP, > 2048 bytes (aciona má gestão de buffer)
2. Resposta TCP, vazia (aciona nova tentativa TCP devido ao recebimento de socket de 0 bytes)
3. Resposta TCP, cabeçalho/pergunta válidos (força a próxima resposta a ser armazenada em um buffer alocado na pilha)
4. Resposta TCP, > 2048 bytes (estoura o buffer alocado na pilha)

Exemplo:

user@localhost:/$ curl http://attack5
*** stack smashing detected ***: curl terminated
Segmentation fault (core dumped)

Testes de Carga

Para acionar uma resposta válida do tipo A/AAAA de um determinado tamanho a partir do servidor, envie uma solicitação para um dos seguintes:

• payload1 (> 64 bytes)
• payload2 (> 128 bytes)
• payload3 (> 256 bytes)
• payload4 (> 512 bytes)
• payload5 (> 1024 bytes)
• payload6 (> 2048 bytes)
• payload7 (> 4096 bytes)
• payload8 (> 8192 bytes)

As solicitações podem ser feitas via UDP ou TCP, e as respostas conterão o número apropriado de respostas A ou AAAA válidas para preencher a resposta até o tamanho solicitado. Quando o servidor PoC é configurado como servidor de nomes autoritativo para um domínio de teste, isso permite explorar o comportamento das hierarquias de cache DNS quando confrontadas com respostas muito grandes.

Exemplo:

user@localhost:/$ curl http://payload1.somedomain.com