Группа исследователей из Калифорнийского университета в Риверсайде опубликовала новый вариант атаки SAD DNS (CVE-2021-20322), работающий несмотря на защиту, добавленную в прошлом году для блокирования уязвимости CVE-2020-25705. Новый метод в целом аналогичен прошлогодней уязвимости и отличается лишь использованием другого типа ICMP-пакетов для проверки активных UDP-портов. Предложенная атака позволяет осуществить подстановку фиктивных данных в кэш DNS-сервера, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника.
Предложенный метод работоспособен только в сетевом стеке Linux из-за привязки к особенности работы механизма обработки ICMP-пакетов в Linux, который выступает источником утечки данных, упрощающих определения номера UDP-порта, использованного сервером для отправки внешнего запроса. Изменения, блокирующие утечку информации, приняты в состав ядра Linux в конце августа (исправление вошло в состав ядра 5.15 и сентябрьских обновлений LTS-веток ядра). Исправление сводится к переходу на использование в сетевых кэшах алгоритма хеширования SipHash вместо Jenkins Hash. Статус устранения уязвимости в дистрибутивах можно оценить на данных страницах: Debian, RHEL, Fedora, SUSE, Ubuntu.
По данным выявивших проблему исследователей уязвимости подвержено около 38% находящихся в сети открытых резолверов, включая популярные DNS-сервисы, такие как OpenDNS и Quad9 (9.9.9.9). Что касается серверного ПО, то атака может быть проведена при использовании на Linux-сервере таких пакетов, как BIND, Unbound и dnsmasq. На DNS-серверах, запущенных с использованием Windows и BSD-систем, проблема не проявляется. Для успешного совершения атаки необходимо использовать спуфинг IP, т.е. требуется чтобы провайдер атакующего не блокировал пакеты с поддельным исходным IP-адресом.
Напомним, что атака SAD DNS позволяет обойти защиту, добавленную в DNS-серверы для блокирования классического метода отравления кэша DNS, предложенного в 2008 году Дэном Камински (Dan Kaminsky). Метод Каминского манипулирует незначительным размером поля с идентификационным номером запроса DNS, который составляет всего 16 бит. Для подбора корректного идентификатора DNS-транзакции, необходимого для спуфинга имени хоста, достаточно отправить примерно 7000 запросов и симулировать около 140 тысяч фиктивных ответов. Атака сводится к отправке на DNS-резолвер большого числа пакетов с фиктивной привязкой к IP и с разными идентификаторами DNS-транзакции. Для предотвращения кэширования первого ответа в каждом фиктивном ответе указывается немного изменённое имя домена (1.example.com, 2.example.com, 3.example.com и т.п.).
Для защиты от данного вида атаки производители DNS-серверов реализовали случайное распределение номеров исходных сетевых портов, с которых отправляются запросы резолвинга, что компенсировало недостаточно большой размер идентификатора. После реализации защиты для отправки фиктивного ответа кроме подбора 16 битного идентификатора стало необходимо подобрать и один из 64 тысяч портов, что увеличило число вариантов для подбора до 2^32.
Метод SAD DNS позволяет кардинально упростить определение номера сетевого порта и свести атаку к классическому методу Каминского. Атакующий может определить обращение к неиспользуемым и активным UDP-портам, воспользовавшись утечкой сведений об активности сетевых портов при обработке ответных ICMP-пакетов. Метод позволяет на 4 порядка сократить число вариантов перебора - 2^16+2^16 вместо 2^32 (131_072 вместо 4_294_967_296). Утечка сведений, позволяющих быстро определить активные UDP-порты, вызвана недоработкой в коде обработки ICMP-пакетов с запросами фрагментации (флаг ICMP Fragmentation Needed) или перенаправления (флаг ICMP Redirect). Отправка подобных пакетов изменяет состояние кэша в сетевом стеке, что позволяет на основе реакции сервера определить какой из UDP-портов активен, а какой нет.
Сценарий атаки: когда DNS-резолвер пытается определить доменное имя, он отправляет UDP-запрос на обслуживающий домен DNS-сервер. В момент, когда резолвер ожидает ответа, атакующий может быстро определить номер исходного порта, который использовался для отправки запроса, и отправить на него поддельный ответ, выдав себя за обслуживающий домен DNS-сервер, используя спуфинг IP-адреса. DNS-резолвер поместит в кэш переданные в поддельном ответе данные и какое-то время на все другие DNS-запросы доменного имени будет возвращать подставленный атакующим IP-адрес.
Предложенный метод работоспособен только в сетевом стеке Linux из-за привязки к особенности работы механизма обработки ICMP-пакетов в Linux, который выступает источником утечки данных, упрощающих определения номера UDP-порта, использованного сервером для отправки внешнего запроса. Изменения, блокирующие утечку информации, приняты в состав ядра Linux в конце августа (исправление вошло в состав ядра 5.15 и сентябрьских обновлений LTS-веток ядра). Исправление сводится к переходу на использование в сетевых кэшах алгоритма хеширования SipHash вместо Jenkins Hash. Статус устранения уязвимости в дистрибутивах можно оценить на данных страницах: Debian, RHEL, Fedora, SUSE, Ubuntu.
По данным выявивших проблему исследователей уязвимости подвержено около 38% находящихся в сети открытых резолверов, включая популярные DNS-сервисы, такие как OpenDNS и Quad9 (9.9.9.9). Что касается серверного ПО, то атака может быть проведена при использовании на Linux-сервере таких пакетов, как BIND, Unbound и dnsmasq. На DNS-серверах, запущенных с использованием Windows и BSD-систем, проблема не проявляется. Для успешного совершения атаки необходимо использовать спуфинг IP, т.е. требуется чтобы провайдер атакующего не блокировал пакеты с поддельным исходным IP-адресом.
Напомним, что атака SAD DNS позволяет обойти защиту, добавленную в DNS-серверы для блокирования классического метода отравления кэша DNS, предложенного в 2008 году Дэном Камински (Dan Kaminsky). Метод Каминского манипулирует незначительным размером поля с идентификационным номером запроса DNS, который составляет всего 16 бит. Для подбора корректного идентификатора DNS-транзакции, необходимого для спуфинга имени хоста, достаточно отправить примерно 7000 запросов и симулировать около 140 тысяч фиктивных ответов. Атака сводится к отправке на DNS-резолвер большого числа пакетов с фиктивной привязкой к IP и с разными идентификаторами DNS-транзакции. Для предотвращения кэширования первого ответа в каждом фиктивном ответе указывается немного изменённое имя домена (1.example.com, 2.example.com, 3.example.com и т.п.).
Для защиты от данного вида атаки производители DNS-серверов реализовали случайное распределение номеров исходных сетевых портов, с которых отправляются запросы резолвинга, что компенсировало недостаточно большой размер идентификатора. После реализации защиты для отправки фиктивного ответа кроме подбора 16 битного идентификатора стало необходимо подобрать и один из 64 тысяч портов, что увеличило число вариантов для подбора до 2^32.
Метод SAD DNS позволяет кардинально упростить определение номера сетевого порта и свести атаку к классическому методу Каминского. Атакующий может определить обращение к неиспользуемым и активным UDP-портам, воспользовавшись утечкой сведений об активности сетевых портов при обработке ответных ICMP-пакетов. Метод позволяет на 4 порядка сократить число вариантов перебора - 2^16+2^16 вместо 2^32 (131_072 вместо 4_294_967_296). Утечка сведений, позволяющих быстро определить активные UDP-порты, вызвана недоработкой в коде обработки ICMP-пакетов с запросами фрагментации (флаг ICMP Fragmentation Needed) или перенаправления (флаг ICMP Redirect). Отправка подобных пакетов изменяет состояние кэша в сетевом стеке, что позволяет на основе реакции сервера определить какой из UDP-портов активен, а какой нет.
Сценарий атаки: когда DNS-резолвер пытается определить доменное имя, он отправляет UDP-запрос на обслуживающий домен DNS-сервер. В момент, когда резолвер ожидает ответа, атакующий может быстро определить номер исходного порта, который использовался для отправки запроса, и отправить на него поддельный ответ, выдав себя за обслуживающий домен DNS-сервер, используя спуфинг IP-адреса. DNS-резолвер поместит в кэш переданные в поддельном ответе данные и какое-то время на все другие DNS-запросы доменного имени будет возвращать подставленный атакующим IP-адрес.
