Что такое DNS rebinding и почему это важно

Большинство проверок безопасности, связанных с доменом, исходят из того, что его IP-адрес достаточно стабилен, чтобы проверить его один раз и дальше доверять. DNS rebinding использует именно это допущение. Злоумышленник контролирует DNS домена и настраивает его так, чтобы сначала он разрешался в обычный публичный IP-адрес и проходил любую проверку целевой системы, а затем подменяет ответ на внутренний адрес (например, 127.0.0.1 или внутренний диапазон 10.x.x.x) для последующего запроса, когда проверка уже пройдена.

Почему это не просто теоретический трюк

Очень короткий TTL делает атаку практичной: злоумышленник задаёт запись, срок жизни которой истекает через несколько секунд, поэтому проверка и следующий за ней настоящий запрос могут увидеть два разных ответа с разницей в миллисекунды, а система-жертва даже не заметит, что почва ушла из-под ног. Потенциально уязвима любая система, которая разрешает домен один раз и использует этот IP в нескольких операциях или, что ещё хуже, разрешает его один раз для проверки и позволяет чему-то другому разрешить его заново для настоящего запроса.

Единственная надёжная защита

Одной проверки строки с именем хоста недостаточно, и однократной проверки IP тоже недостаточно. Единственная надёжная защита — сверять фактически полученный адрес со списком блокировки частных и внутренних диапазонов в момент, когда соединение действительно устанавливается, причём каждый раз, а не только при первичной проверке. Это закрывает временной разрыв, на котором держится rebinding: между «проверено» и «использовано» больше нет окна, в котором ответ мог бы измениться.

• Блокируйте частные диапазоны (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16) и конечные точки облачных метаданных, как для IPv4, так и для IPv6.
• Перепроверяйте при каждом использовании, а не только один раз при проверке введённых данных.
• Считайте IPv4-mapped IPv6-адрес (например, ::ffff:127.0.0.1) эквивалентным встроенному в него IPv4-адресу: попытки rebinding порой используют именно такую запись, чтобы обойти наивную проверку только IPv6.

Где это имело значение на практике

DNS rebinding — не нишевая академическая проблема: его неоднократно использовали против домашних роутеров, хабов умного дома и других устройств, которые открывают локальный административный интерфейс без аутентификации, исходя из того, что до него может добраться только доверенный локальный трафик. Вредоносная веб-страница, открытая в обычной вкладке браузера в той же сети, может с помощью rebinding заставить собственный браузер жертвы, которому роутер уже доверяет только потому, что он находится в локальной сети, отправлять запросы прямо к этому административному интерфейсу от имени злоумышленника. Браузер всё время считает, что общается с исходным публичным доменом; изменился лишь DNS-ответ под ним.

Более тонкий вариант: rebinding с несколькими ответами

Более изощрённая версия вообще не ждёт истечения TTL. Один DNS-ответ может законно содержать несколько записей A, а некоторое клиентское ПО просто пробует их по порядку или даже чередует между разными запросами по кругу. Злоумышленник может вернуть в одном и том же ответе и легитимный публичный адрес, и внутренний, рассчитывая, что клиент в итоге попробует вторую запись: без ожидания и без временного окна, лишь используя то, что DNS никогда не проектировали так, чтобы гарантировать одинаковую надёжность каждого адреса в ответе с несколькими записями. Это хорошее напоминание, что принцип «проверить первый возвращённый адрес» никогда не бывает достаточным: каждый адрес в ответе заслуживает одинакового внимания.