Назад | Перейти на главную страницу

Поврежденные DNS-запросы

Иногда в некоторых сетевых захватах, которые включают мой DNS-сервер, я обнаруживаю, что поиск недопустимых запросов не выполняется.

При просмотре в Wireshark они выглядят как экранированные байты вне диапазона ASCII.

Пример из Wireshark query.name> Copy> Bytes> Hex Stream:

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

Вы можете увидеть, что там есть часть обычного формата DNS-запроса:

Я не могу понять, что такое средний бит.

Я знаком с Punycode для международных символов и достаточно уверен, что это не так.

У меня нет доступа к хостам, которые делают запросы. я знаю, некоторые вредоносное ПО пытается разрешить подобные вещи, поэтому мне любопытно, может ли это указывать на присутствие вредоносного ПО.

Отредактировано для добавления:

Вот скриншот ответа DNS, увиденный Wireshark:

Punycode - это кодировка ASCII, так что вы правы, что это мусор. Нам нужно увидеть весь пакет, чтобы указать больше. Я разбил эту строку на ASCII и шестнадцатеричные байтовые границы ниже, чтобы было легче воспринимать структуру пакета.

(если кто-то заметит ошибку, просто отредактируйте ее напрямую)

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

  • Punycode не использует байты выше 7-битной границы ASCII, которая заканчивается шестнадцатеричным числом. 7F.
  • Даже если мы предположим незаконную попытку встроить байты UTF-8 в эту строку, они начинаются с начального байта в диапазоне шестнадцатеричных C2 через F4. Байт, следующий сразу за начальным www, является шестнадцатеричным. 12 (подача формы), за которым следует 8B, который является байтом продолжения. Определенно недействительный UTF-8.

На данный момент у нас остается три возможности:

  1. Повреждение данных
  2. Пакеты, предназначенные для использования уязвимости
  3. Попытка кодировать данные, не относящиеся к DNS, по протоколу DNS, чтобы обойти брандмауэры, такие как программное обеспечение VPN. Я не потратил много времени на изучение реализаций this, поэтому не могу комментировать вероятность того, что это так. Если это то, что происходит, я бы предположил, что начальные «www» и конечные «com» ​​являются слабой попыткой обмануть элементарную глубокую проверку пакетов.