АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Отравление кэша DNS

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Отравление кэша DNS (англ. DNS cache poisoning, также захват DNS, отравление DNS, перенаправление DNS) — это практика подмены результатов запросов к системе доменных имён (DNS) злоумышленником[1]. Такая атака может осуществляться вредоносным программным обеспечением, которое переопределяет сетевые настройки (TCP/IP) компьютера и направляет его запросы на управляемый злоумышленником DNS-сервер, либо изменяет поведение доверенного DNS-сервера так, чтобы он не соответствовал действующим интернет-стандартам.

Подмена может использоваться в злонамеренных целях, например для фишинга, а также провайдерами интернет-услуг (ISP), Великим китайским файрволом или публичными/маршрутизаторными провайдерами DNS для перенаправления трафика пользователей на серверы провайдера с целью показа рекламы, сбора статистики и иных задач; и DNS-провайдерами для блокировки доступа к определённым доменам как разновидность цензуры.

Технические основы

Одна из функций DNS-сервера — преобразование доменного имени в IP-адрес, необходимый приложениям для подключения к ресурсу в Интернете, таким как веб-сайты. Эта функциональность детально регламентируется формальными интернет-стандартами, описывающими протокол работы DNS. DNS-серверам доверяют корректное отображение доменных имён в IP-адреса, зарегистрированные владельцами доменов.

Злонамеренный DNS-сервер

Злонамеренный DNS-сервер преобразует доменные имена популярных и ценных сайтов (поисковиков, банков, брокеров и др.) в IP-адреса сайтов с нежелательным или вредоносным содержимым. Большинство пользователей автоматически полагаются на DNS-серверы, выданные их интернет-провайдером. Заданные на роутере DNS-серверы могут быть изменены путём удалённой эксплуатации уязвимости в программном обеспечении роутера[2]. В результате пользователь при попытке зайти на сайт попадает на поддельную страницу с тем же доменным именем. Такой тип атаки называется фарминг. Если перенаправление происходит на вредоносный сайт, маскирующийся под легитимный для кражи конфиденциальной информации, это уже фишинг[3].

Манипуляция со стороны провайдеров

Ряд потребительских провайдеров, таких как AT&T[4], Cablevision (англ. Optimum Online)[5], CenturyLink[6], Cox Communications, RCN[7], Rogers[8], Charter Communications (Spectrum), Plusnet[9], Verizon[10], Sprint[11], T-Mobile US[12], Virgin Media,[13][14] Frontier Communications, Bell Internet[15], Deutsche Telekom AG[16], Optus[17], Mediacom[18], ONO[19], TalkTalk[20], Bigpond (Telstra),[21][22][23][24] TTNET, Türksat и все индонезийские потребительские провайдеры используют либо использовали захват DNS для собственных нужд, например, для показа рекламы[25] или сбора статистики. Голландские провайдеры XS4ALL и Ziggo делали это по решению суда — для блокировки доступа к Pirate Bay и показа предупреждающей страницы[26], а все легальные потребительские провайдеры в Индонезии реализуют захват DNS по национальному закону о DNS[27], требующему редиректа порт 53 на сервер провайдера для блокировки сайтов из списка Trustpositif по программе Kominfo Internet Sehat. Эти практики нарушают стандарт RFC (NXDOMAIN) для ответа DNS[28] и могут привести к атакам с межсайтовым скриптингом[25].

Опасность захвата DNS связана с подменой ответа NXDOMAIN. Интернет- и интранет-приложения опираются на ответ NXDOMAIN для определения ситуации, когда DNS не содержит информации о хосте. Например, при запросе несуществующего домена (например www.example.invalid) должен вернуться NXDOMAIN, информирующий о невалидности имени. Но на инфраструктуре таких провайдеров всегда возвращается поддельный IP-адрес провайдера. В веб-браузере это раздражает из-за отображения рекламной страницы провайдера, а другие приложения, полагаясь на NXDOMAIN, могут ошибочно подключаться к ложному серверу, что грозит уязвимостью конфиденциальных данных.

Примеры некорректной работы при захвате DNS провайдером:

  • Ноутбуки вне корпоративной сети, являющиеся членами домена Windows Server, ошибочно «видят» корпоративную инфраструктуру (контроллеры домена, почтовые серверы и др.), пытаются подключиться и терпят неудачу, что приводит к избыточному трафику, задержкам и деградации производительности.
  • Многие домашние и малые сети не имеют собственного DNS, полагаясь на широковещательное разрешение имён. В ряде версий Microsoft Windows по умолчанию DNS приоритетнее NetBIOS: при ложном IP от DNS соединиться не удаётся. Варианты решения: использовать IP напрямую или изменить параметр DhcpNodeType для настройки порядка разрешения имён[29].
  • В браузере Firefox утрачивается функция «Browse By Name», когда ключевые слова в адресной строке приводят к сайтам благодаря поиску, а не прямому переходу[30].
  • Локальный DNS-клиент современных ОС кэширует DNS-результаты. При смене домашней сети на VPN ложные записи могут сохраниться и вызвать сбои VPN-соединения.
  • DNSBL антиспам-системы используют DNS; ложные ответы делают их бесполезными.
  • Конфиденциальные данные пользователя могут быть раскрыты, если приложение обмануто ложным DNS и «видит» нужные серверы в сети.
  • Пользователь теряет выбор поисковой системы для обработки ошибочного URL, поскольку провайдер показывает свою страницу.
  • При использовании VPN с раздельным туннелем (split tunnel) разрешение корпоративных адресов вне туннеля ведёт к поддельным IP, что ломает функционал почты и других сервисов. Например, почтовый клиент, пытающийся получить записи A для корпоративного сервера, попадает на рекламный сервер, что приводит к простоям и повторным попыткам доставки[31].
  • Ломается автообнаружение прокси (WPAD): браузер ошибочно считает, что провайдер настроил прокси-сервер.
  • Не работают системы мониторинга: например, инструмент для проверки живости сервера может не распознать сбой, если возвращается ложный IP.

В некоторых случаях провайдеры предлагают настройки для отказа от перехвата NXDOMAIN, но часто это реализовано некорректно: например, отключение через cookie приводит лишь к показу не рекламной, а поддельной страницы ошибки через HTTP, но не воздействует на остальные приложения (опция работает только для веб-протокола, а само вмешательство осуществляется на уровне DNS).

Реакция

В Великобритании офис комиссара по информации признал, что практика принудительного захвата DNS противоречит регламенту PECR и Директиве ЕС 95/46 о защите данных, требующих явного согласия на обработку коммуникационного трафика[13]. В Германии в 2019 году выяснилось, что компания Deutsche Telekom AG не только манипулировала своими DNS-серверами, но и передавала сетевой трафик (например, незашифрованные cookie, если пользователь не использовал HTTPS) сторонней компании через портал T-Online, который больше не принадлежал самой Telekom. После подачи пользователем уголовной жалобы Telekom прекратила данную практику[32].

Международная организация ICANN, ответственная за администрирование доменных имён верхнего уровня, опубликовала меморандум с критикой подобных практик:[31]

ICANN настоятельно не рекомендует использовать перенаправление DNS, шаблоны, синтетические ответы и любые другие формы подмены ответа NXDOMAIN на любом уровне DNS-иерархии для доменов класса реестра.

Защита и обход

Пользователи, не удовлетворённые убогими настройками «отказа» вроде cookie, самостоятельно ищут пути обхода фальшивых ответов NXDOMAIN. Программное обеспечение типа BIND и Dnsmasq позволяет фильтровать результаты запросов и может запускаться на шлюзе или роутере для защиты всей сети. Google, как и некоторые другие компании, предоставляет открытые DNS-серверы, которые не возвращают ложные результаты. Пользователь может настроить использование Google Public DNS вместо DNS-провайдера, если согласен с политикой обработки данных Google и возможностью отслеживания запросов со стороны Google. Ограничение этого подхода: некоторые провайдеры блокируют или подменяют внешний трафик DNS. Сходную услугу предоставляет OpenDNS (Cisco), возвращающая стандартные NXDOMAIN-ответы.

В апреле 2016 года Google запустила сервис DNS-over-HTTPS[33]. Эта технология преодолевает ограничения классического DNS: используется защищённый HTTPS-туннель, а проверка DNSSEC происходит удалённо.

Для отдельных приложений существуют обходные решения, например расширение NoRedirect для Mozilla Firefox[34], уменьшающее часть рисков. Но такие подходы устраняют лишь одну из проблем и не решают вопросы остальные протекания. Владельцы сайтов иногда могут сбивать с толка злоумышленников с помощью специальных DNS-настроек: например, установив TXT-запись «unused» на подстановочный адрес (*.example.com) или перенаправив его на CNAME «example.invalid» (домен «.invalid» гарантированно не существует по RFC). Этот метод защищает только определённые домены и помогает лишь от отдельных проблем безопасности в VPN, вызванных захватом DNS.

Примечания

  1. ↑ What is a DNS Hijacking. Redirection Attacks Explained (англ.). Learning Center. Дата обращения: 13 декабря 2020.
  2. ↑ Constantin, Lucian DNS hijacking flaw affects D-Link DSL router, possibly other devices (англ.) (27 января 2015). Дата обращения: 21 июня 2017.
  3. ↑ Rogue Domain Name System Servers. Trend Micro. Дата обращения: 15 декабря 2007.
  4. ↑ ATT DNS Assist Page (27 марта 2017). Дата обращения: 24 февраля 2018.
  5. ↑ Optimum Online DNS Assistance. Архивировано 13 августа 2009 года.
  6. ↑ Re: [Qwest] Opting out of CenturyLink Web Helper hijacking not w - CenturyLink. DSL Reports. Дата обращения: 12 октября 2016.
  7. ↑ Who Stole My Web Browser? (13 октября 2009).
  8. ↑ Rogers Uses Deep Packet Inspection for DNS Redirection. dslreports.com (20 июня 2008). Дата обращения: 15 июня 2010.
  9. ↑ UK ISP's providing cdn for google. equk.co.uk (7 апреля 2014). Дата обращения: 25 октября 2015.
  10. ↑ Opting out of DNS Assistance. Дата обращения: 12 февраля 2015. Архивировано 12 февраля 2015 года.
  11. ↑ Are Sprint 3G and 4G towers hijacking NXDOMAIN responses? More information in comments... reddit (5 сентября 2014). Дата обращения: 24 февраля 2018.
  12. ↑ How do I turn of NXDOMAIN hijacking? reddit (20 июля 2015). Дата обращения: 24 февраля 2018.
  13. ↑ 1 2 ICO: We won't stop Advanced Network Error Search. Архивировано 17 февраля 2015 года.
  14. ↑ Case Reference Number ENQ0265706. — «"I am not convinced that there is any likelihood of detriment or harm to subscribers or users that would justify taking formal action in this case."».
  15. ↑ Bell Starts Hijacking NS Domain Queries (4 августа 2009).
  16. ↑ Reiko Kaps. Telekom leitet DNS-Fehlermeldungen um (нем.) (17 апреля 2009). Дата обращения: 9 декабря 2019.
  17. ↑ Optus' "About the Search Results Page". Дата обращения: 10 декабря 2009. Архивировано 13 июля 2012 года.
  18. ↑ Want a real world example of why we need network neutrality? I have one here. (25 сентября 2009).
  19. ↑ XSS Reflected dnssearch.Ono.es NXD redirect (10 мая 2010). Дата обращения: 24 февраля 2018. Архивировано 12 июня 2018 года.
  20. ↑ TalkTalk - Search. error.talktalk.co.uk. Дата обращения: 24 февраля 2018.
  21. ↑ BigPond redirects typos to 'unethical' branded search page. CRN Australia. Дата обращения: 24 февраля 2018.
  22. ↑ Charter Corrupting DNS protocol ie hijacking hosts.
  23. ↑ road runner dns hijack causing slow web-pages. Архивировано 10 декабря 2010 года.
  24. ↑ Rogers violates net neutrality by hijacking failed DNS lookups. Архивировано 27 июля 2008 года.
  25. ↑ 1 2 Singel, Ryan ISPs Error Page Ads Let Hackers Hijack Entire Web, Researcher Discloses. Wired (19 апреля 2008).
  26. ↑ Digined XS4ALL blokkeert adressen Pirate Bay voorlopig (нидерл.). blog.xs4all.nl. Дата обращения: 5 октября 2017.
  27. ↑ Tanjung, Tidar. Kominfo Finalisasi DNS Nasional? (en-id). Дата обращения: 11 июня 2018.
  28. ↑ Andrews, M. (1998). “Negative Caching of DNS Queries”. DOI:10.17487/RFC2308.
  29. ↑ NetBIOS and WINS. howtonetworking.com. Дата обращения: 24 февраля 2018.
  30. ↑ Using Firefox + NoRedirect Extension to Avoid DNS Hijacking. Архивировано 3 марта 2011 года.
  31. ↑ 1 2 Harms Caused by NXDOMAIN Substitution in Toplevel and Other Registry-class Domain Names (англ.). ICANN (24 ноября 2009). Дата обращения: 23 сентября 2010.
  32. ↑ Telekom beendet DNS-Hijacking (нем.). Golem.
  33. ↑ DNS-over-HTTPS - Public DNS (англ.). Google Developers (4 сентября 2018). Дата обращения: 12 марта 2019.
  34. ↑ NoRedirect – Add-ons for Firefox. addons.mozilla.org. Дата обращения: 24 февраля 2018. Архивировано 25 февраля 2018 года.

Категории