DNS hijacking

Перехоплення DNS — підрив дозволу DNS-запитів. Це може бути досягнуто з допомогою шкідливих програм, які перекривають TCP/IP конфігурації комп'ютера, щоб запити направлялися на DNS сервер зловмисника, або через зміну поведінки довіреного DNS сервера так, щоб воно не відповідало стандартам Інтернету. Ці зміни можуть бути зроблені у зловмисних цілях, таких як фішинг, або в корисливих цілях Інтернет-провайдерами (ISP), які перенаправляють вебтрафік користувачів на власні вебсервери для показу реклами, збору статистики або інших цілей; і постачальниками послуг DNS для блокування доступу до певних доменів як форма цензури.

Однією з функцій DNS сервера є конвертування доменних імен у IP-адреси, які потрібні для підключення до інтернет-ресурсу, такому як вебсайт. Ця функціональність визначена в різних офіційних інтернет-стандартах, що визначають протокол досить докладно. Комп'ютери з виходом в Інтернет довіряють DNS-серверам в коректній відповідності імен фактичними адресами, зареєстрованими власниками доменів в Інтернеті.

Сервер-шахрай DNS переводить доменні імена популярних вебсайтів (пошукових систем, банків і т. д.) в IP-адреси сайтів з непередбачуваним вмістом, навіть шкідливих вебсайтів. Більшості користувачів DNS-сервери призначаються автоматично їх провайдерами. Комп'ютери-зомбі запускають трояни, непомітно змінюють адресу автоматично присвоєну провайдером DNS-сервера на DNS-сервер шахрая. Коли користувачі намагаються відвідати вебсайти, вони потрапляють на підроблений сайт. Така атака називається фармінг. Якщо шкідливий сайт, на який перенаправляються запити, маскуючись під легальний вебсайт, який намагається обманним шляхом отримати доступ до конфіденційної інформації, то це називається фішингом.

Деякі провайдери, такі як OpenDNS, Cablevision's Optimum Online, Comcast, Time Warner, Cox Communications, RCN, Rogers, Charter Communications, Verizon, Virgin Media, Frontier Communications, Bell Sympatico, UPC, T-Online, Optus, Mediacom, ONO, TalkTalk і Bigpond (Telstra) використовують перенаправлення DNS в своїх цілях, наприклад для відображення реклами або збору статистики. Це порушує RFC стандарти для DNS (NXDOMAIN)-відповідей і може відкрити користувачам можливість міжсайтового скриптингу.

Перенаправлення DNS включає зміну відповіді NXDOMAIN. Інтернет- і інтранет-додатки покладаються на відповідь NXDOMAIN для опису стану, коли DNS не має запису для зазначеного вузла. Якщо ми запросили неіснуюче доменне ім'я (fakeexample.com), у відповідь ми повинні отримати NXDOMAIN-відповідь, яка інформує додаток про те, що ім'я неприпустимо і викликає відповідні заходи (наприклад, відображення помилки або відмова від підключення до сервера).

Так, якщо доменне ім'я запитується на одному з цих неіснуючих провайдерів, можна отримувати підроблену IP-адресу, що належить провайдеру. У веббраузері така поведінка може бути дратівливою або образливою, коли з'єднання з цією IP-адресою відображають провайдерські сторінки перенаправлення, іноді з рекламою, замість належного повідомлення про помилку. Однак, інші програми, які покладаються на помилку NXDOMAIN, замість цього будуть намагатися ініціювати з'єднання з цією підробленою IP-адресою, потенційно піддаючи ризику конфіденційну інформацію.

Приклади функціональності, яка пропадає, якщо провайдери перенаправляють DNS:

• Маршрутизовані ноутбуки, є членами домену Windows Server, помилково припускають, що вони повернулися в корпоративну мережу, тому що ресурси, такі як контролери домену, поштові сервери та інші об'єкти інфраструктури, стають доступні. Програми намагаються ініціювати з'єднання з цими корпоративними серверами, але зазнають невдачі, що призводить до погіршення продуктивності, непотрібного трафіку в Інтернеті і тайм-аутам.
• Багато малих офісів і більшість домашніх мереж не мають власного сервера DNS, покладаючись натомість на широкомовний дозвіл імен. Оскільки DNS-запити є більш пріоритетними, ніж локальне широкомовлення, всі імена будуть помилково відправлятись на сервери, що належать провайдеру, і локальна мережа працювати не буде.
• Браузери, такі як Firefox, не зможуть виконувати «пошук по імені» (коли ключові слова, набрані в адресному рядку, перенаправляють вас на найближчий знайдений сайт).
• Локальний DNS-клієнт, вбудований в сучасні операційні системи, буде кешувати результати DNS-пошуку для підвищення продуктивності. Якщо клієнт перемикається між домашньою мережею і VPN, помилкові записи можуть залишитися закешованими, тим самим створюючи перерви в обслуговуванні з'єднання VPN.
• Анти-спам рішення DNSBL засновані на DNS; тому помилкові результати DNS заважають правильній роботі DNSBL.
• Конфіденційні дані користувача можуть бути розкриті додатком, який ввів в оману провайдер, вдаючи, що сервіс, до якого він намагається підключиться, доступний.
• Пошукова система не зможе виправляти неправильно надруковані URL, спираючись на попередні вибори користувача, так як провайдер визначає, які результати пошуку відобразити користувачеві; додатки, такі як панель інструментів Google, не зможуть працювати коректно.
• Комп'ютери, налаштовані на використання роздільного тунелювання  перестануть працювати з VPN-підключенням, тому що імена інтрамережі, які не повинні дозволятися поза тунелем в публічній мережі Інтернет, стануть дозволятися фіктивні адреси, замість того, щоб коректно дозволятися через VPN-тунель на приватному DNS-сервері при отриманні запису NXDOMAIN з Інтернету. Наприклад, поштовий клієнт, який намагається дозволити DNS запис типу А для внутрішнього поштового сервера, може отримати помилкову DNS-відповідь, яка направляє на платний вебсервер з чергою повідомлень на доставку у разі, якщо повторна передача була невдалою.
• Це порушує роботу WPAP (протоколу автоматичного налаштування проксі), змушуючи веббраузери помилково вважати, що провайдер має конфігурацію проксі-сервера.
• Це порушує роботу програмного забезпечення для контролю. Наприклад, якщо ми періодично звертаємося до сервера для перевірки працездатності, монітор не помітить підробки, поки не спробує перевірити криптографічний ключ сервера.

У деяких випадках провайдери надають конфігуровані абонентом налаштування для запобігання зміни NXDOMAIN-відповідей. Правильно реалізовані, такі налаштування повертають DNS до стандартної поведінки. Інші провайдери, однак, замість цього використовують куки браузера для зберігання вподобань. У цьому випадку проблема коректної поведінки не буде вирішена: DNS-запити продовжать перенаправлятися, а провайдерська сторінка перенаправлення замінюватися підробленими повідомленнями про помилку DNS. Інші програми, крім веббраузерів, можуть бути виключені зі схеми використання куки, схема фактично реалізована на нейтральній до протоколів DNS-системі.

Деякі реєстратори доменних імен, зокрема Name.com, виробляють перенаправлення DNS при невдалому пошуку доменних імен, незважаючи на заперечення проти цього ICANN і їх споживачів.

У Великій Британії Інформаційний Офіс Комісарів встановив, що практика недобровільного DNS-перенаправлення суперечить PECR та Директиві ЄС 95/46 щодо захисту даних, які вимагають явної згоди для обробки комунікаційного трафіку. Однак, він відмовився втручатися, стверджуючи, що не було б розумно проводити закон, тому що це не буде завдавати істотної (або будь-якої) очевидної шкоди фізичним особам.

ICANN, міжнародна організація, що відповідає за управління доменними іменами верхнього рівня, опублікувала меморандум, підкресливши свою стурбованість і підтверджуючи: «ICANN суворо перешкоджає використанню перенаправлення DNS, символів підстановки, синтезованих відповідей і інших форм заміни NXDOMAIN в існуючих gTLD, ccTLD і на будь-якому іншому рівні в дереві DNS реєстрації класу доменних імен».

• DHCP
• PPP (мережевий протокол)
• Атака TCP Reset

• http://blog.trendmicro.com/trendlabs-security-intelligence/rogue-domain-name-system-servers-5breposted5d/ [Архівовано 10 квітня 2018 у Wayback Machine.]
• https://web.archive.org/web/20130730034331/http://forums.opendns.com/comments.php?DiscussionID=8061
• https://www.theregister.co.uk/2009/07/28/comcast_dns_hijacker/ [Архівовано 2 квітня 2018 у Wayback Machine.]
• http://infiniteedge.blogspot.ru/2009/10/who-stole-my-web-browser.html [Архівовано 10 квітня 2018 у Wayback Machine.]
• http://www.dslreports.com/shownews/Rogers-Uses-Deep-Packet-Inspection-for-DNS-Redirection-96239 [Архівовано 12 червня 2018 у Wayback Machine.]
• https://nodpi.org/forum/index.php/topic,2390.msg25643/topicseen.html^{[недоступне посилання з лютого 2019]}
• https://nodpi.org/wp-content/uploads/2010/01/virgin_anes.pdf^{[недоступне посилання з лютого 2019]}
• http://tech.slashdot.org/story/09/08/04/1512248/Bell-Starts-Hijacking-NX-Domain-Queries [Архівовано 12 червня 2018 у Wayback Machine.]
• https://www.reddit.com/r/programming/comments/9o3as/want_a_real_world_example_of_why_we_need_network/ [Архівовано 17 серпня 2015 у Wayback Machine.]
• https://host4geeks.com/blog/how-to-fix-dns_probe_finished_nxdomain-error-in-google-chrome/ [Архівовано 24 жовтня 2019 у Wayback Machine.]