Новый вариант атаки SAD DNS для подстановки фиктивных данных в кэш DNS
Автор
Сообщение
news_bot ®
Стаж: 6 лет 2 месяца
Сообщений: 27286
Группа исследователей из Калифорнийского университета в Риверсайде опубликовала новый вариант атаки 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-адрес.
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://arstechnica.com/gadget...)
- OpenNews: Атака SAD DNS для подстановки фиктивных данных в кэш DNS
- OpenNews: Атака NXNSAttack, затрагивающая все DNS-резолверы
- OpenNews: Фундаментальная уязвимость в DNS. Рекомендуется срочно обновить BIND
- OpenNews: Опубликован код эксплоита для атаки на DNS серверы
- OpenNews: Уязвимости в Dnsmasq, позволяющие подменить содержимое в кэше DNS
Похожие новости:
- Захват контроля над уязвимыми серверами GitLab для вовлечения в проведение DDoS-атак
- Атака Trojan Source для внедрения изменений в код, незаметных для разработчика
- Некорректные манипуляции с BGP привели к 6-часовой недоступности Facebook, Instagram и WhatsApp
- Новая атака на системы фронтэнд-бэкенд, позволяющая вклиниться в запросы
- Выпуск PowerDNS Authoritative Server 4.5
- DNS-over-HTTPS будет включён по умолчанию в Firefox для пользователей из Канады
- [Информационная безопасность] Атака через поставщика или подрядчика глазами пентестера
- В клиентском ПО удостоверяющего центра MonPass выявлен бэкдор
- [Информационная безопасность, DNS, Разработка под Windows, Софт] В превью Windows 11 появился DNS-over-HTTPS
- [Высокая производительность, Серверное администрирование, Тестирование веб-сервисов, Облачные сервисы] Смертельное переполнение стека. Почему мы потеряли свой DNS и как предотвратить такое в будущем (перевод)
Теги для поиска: #_dns, #_attack
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Апр 05:44
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 2 месяца |
|
|
Группа исследователей из Калифорнийского университета в Риверсайде опубликовала новый вариант атаки 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-адрес. =========== Источник: OpenNet.RU =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Апр 05:44
Часовой пояс: UTC + 5