Solicitações de DNS corrompidas

Question

Às vezes, em algumas capturas de rede que incluem meu servidor DNS, descubro que existem pesquisas com falha para solicitações inválidas.

Quando visualizados no Wireshark, eles aparecem com o que parece ser um escape de bytes fora do intervalo ASCII.

Um exemplo de query.name > do Wireshark Copiar > Bytes > Hex Stream é:

Raw: 03777777128b68481cc5116ceb53bade651327d982751903636f6d00'
As Python bytes: \x03www\x12\x8bhH\x1c\xc5\x11l\xebS\xba\xdee\x13'\xd9\x82u\x19\x03com\x00

Você pode ver que há parte do formato usual de consulta DNS:

• Sinal para 3 bytes e, em seguida, www
• Sinal para 18 bytes e, em seguida, ... sem sentido.
• Sinal para 3 bytes e, em seguida, com

Eu não consigo descobrir o que o bit do meio deveria ser.

Estou familiarizado com o Punycode para personagens internacionais e tenho certeza de que não é isso.

Eu não tenho acesso aos hosts que estão fazendo as solicitações. Conheço alguns malwares tenta resolver coisas desse tipo, então estou curioso para saber se isso pode indicar a presença de malware.

Editado para adicionar :

Aqui está uma captura de tela da resposta do DNS, como visto pelo Wireshark:

    

Answer 1

Punycode é uma codificação ASCII, portanto, você está certo de que isso parece ser lixo. Precisamos ver todo o pacote para indicar mais do que isso. Eu quebrei essa string em ASCII e limites de bytes hex abaixo para que seja mais fácil perceber a estrutura do pacote.

(se alguém descobrir algum erro, basta editá-lo diretamente)

[03] www em [12][8b] hH em [1c][c5][11] l em [eb] S em [ba][de] e em% co_de [13] % ' [illegal DNS ASCII: byte 0x27] [d9][82]
u [19][03]
com

• O Punycode não usa bytes acima do limite ASCII de 7 bits, que termina em% hexadecimal[terminating null byte 0x00].
• Mesmo se assumíssemos uma tentativa ilegal de incorporar bytes UTF-8 nessa string, eles começam com um byte inicial no intervalo de% hex7F a C2 . O byte imediatamente após o www inicial é hex F4 (feed de formulário) seguido por 12 , que é um byte de continuação. Definitivamente não é válido UTF-8.

Neste ponto, ficamos com três possibilidades:

1. Corrupção de dados
2. Pacotes projetados para explorar uma vulnerabilidade
3. Tentativa de codificar dados não-DNS sobre o protocolo DNS para contornar firewalls, como o software de VPN. Eu não passei muito tempo pesquisando implementações do presente, então não posso comentar sobre a probabilidade de este ser o caso. Se é isso que está acontecendo, eu diria que o principal "www" e o "com" à direita são uma tentativa fraca de enganar a inspeção profunda e rudimentar de pacotes.