DNS spoofing

DNS-спуфінг, є однією з форм злому комп'ютерних мереж, в якому дані DNS-відповіді змінюються зловмисником, з метою повернення помилкової IP-адреси. Це призводить до атаки посередника з метою перенаправлення даних на комп'ютер зловмисника (або будь-який інший комп'ютер). Є одним з способів фармінгу.

Огляд системи доменних імен[ред. | ред. код]

DNS-сервери зіставляють зручні для читання доменні імена (наприклад, example.com) з IP-адресою, яка використовується для маршрутизації повідомлень між вузлами. Зазвичай, якщо сервер не знає даної IP-адреси, він виконує запит до іншого сервера, і процес триває рекурсивно. Для збільшення продуктивності, сервер, як правило, зберігає (кешує) значення IP-адреси і доменного імені на певний проміжок часу. Це означає, що якщо він отримує ще один запит на той самий запис, він зможе відповісти без необхідності запитувати інші сервери, до закінчення терміну дії кешу.

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

Отруєння кешу[ред. | ред. код]

Як правило, мережевий комп'ютер використовує DNS-сервери, що надаються Інтернет-провайдером (ISP) або власний сервер організації. DNS-сервери використовуються в організації мережі, щоб поліпшити продуктивність за рахунок кешування раніше отриманих результатів. Отруєння кешу на одному DNS-сервері може вплинути на користувачів, що обслуговуються безпосередньо на віддаленому сервері або тих, хто обслуговується даним сервером.

Щоб виконати отруєння кешу, зловмисник експлуатує недоліки програмного забезпечення сервера DNS. Сервер повинен правильно перевірити DNS відповіді, щоб переконатися, що вони належать надійному джерелу (наприклад, з допомогою DNSSEC); у противному випадку сервер може кешувати невірні записи локально і надавати іншим користувачам, які здійснюють запит.

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

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

Варіанти[ред. | ред. код]

Наприклад запис для сервера ns.target.example може бути отруєна і перенаправляти всі запити на IP-адресу зловмисника w.x.y.z. Ці атаки припускають, що сервер імен для target.example є ns.target.example.

Щоб виконати атаки, зловмисник повинен змусити цільовий DNS-сервер зробити запит на домен, контрольований одним з серверів імен зловмисників

Перенаправлення цілі DNS[ред. | ред. код]

Перший варіант отруєння кешу DNS включає перенаправлення сервера імен домену зловмисника на сервер імен цільового домену, а потім присвоєння цьому серверу імен IP-адреси, вказаної зловмисником.

Запит DNS сервера: яка IP-адреса для subdomain.attacker.example?

subdomain.attacker.example. IN A 

Відповідь атакуючого:

Answer: (no response)  Authority section: attacker.example. 3600 IN NS ns.target.example.  Additional section: ns.target.example. IN A w.x.y.z 

Уразливий сервер буде кешувати додаткові записи (IP-адреса) для ns.target.example, який дозволить йому відповідати на запити для всієї групи доменів target.example.

Перенаправлення запису в інший домен[ред. | ред. код]

Другий варіант отруєння кешу DNS включає перенаправлення сервера імен домену, не пов'язаного з вихідним запитом, на IP-адресу, вказану зловмисником.

Запит DNS сервера: яка IP-адреса для subdomain.attacker.example?

subdomain.attacker.example. IN A 

Відповідь атакуючого:

Answer: (no response)  Authority section: target.example. 3600 IN NS ns.attacker.example.  Additional section: ns.attacker.example. IN A w.x.y.z 

Уразливий сервер буде кешувати незв'язані дані про повноваження для NS-запис target.example (запис сервера імен), що дозволяє зловмисникові відповідати на запити у всьому домені target.example.

Попередження атаки і пом'якшення наслідків[ред. | ред. код]

Більшість атак, пов'язаних з отруєнням кешу на DNS-серверах, можуть бути відвернені, оскільки вони не довіряють інформації, переданої їм іншими DNS-серверами, і ігнорують будь-які передані назад записи DNS, які не мають прямого відношення до запиту. Наприклад, версії BIND 9.5.0-P1 і вище виконують ці перевірки. Рандомізація порту джерела для DNS-запитів в поєднанні з використанням криптографічно безпечних випадкових чисел для вибору як вихідного порту, так і 16-розрядного криптографічного числа може значно знизити ймовірність успішних DNS-атак.

Однак, коли маршрутизатори, брандмауери, проксі і інші аварійні пристрої виконують трансляцію мережевих адрес (NAT) або, більш конкретно, перетворення адрес порту (PAT), вони можуть переписувати вихідні порти, щоб відслідковувати стан з'єднання. При зміні портів джерела, пристрої PAT можуть видаляти випадкову випадковість порту, реалізовану серверами імен і захисними заглушками.

Secure DNS (DNSSEC) використовує криптографічні цифрові підписи, підписані довіреним сертифікатом відкритого ключа, для визначення достовірності даних. DNSSEC може протидіяти атакам отруєння кешу, але з 2008 року ще не отримала широкого застосування. У 2010 році DNSSEC була реалізована на серверах кореневої зони Інтернету.[2]

Така атака може бути зменшена на транспортному рівні або на рівні програми шляхом виконання наскрізної перевірки після встановлення з'єднання. Загальним прикладом цього є використання безпеки транспортного рівня і цифрових підписів.

Наприклад, використовуючи HTTPS (безпечну версію HTTP), користувачі можуть перевірити, чи є цифровий сертифікат сервера дійсним і належить очікуваному власнику вебсайту. Аналогічним чином, програма віддаленого входу в безпечний сервер перевіряє цифрові сертифікати на кінцевих точках (якщо вони відомі) перед продовженням сеансу. Для додатків, які завантажують оновлення автоматично, програма може вставляти копію сертифіката підпису локально і перевіряти підпис, що зберігається в оновленні програмного забезпечення, по вбудованому сертифікату.

Дивись також[ред. | ред. код]

Примітки[ред. | ред. код]

  1. Son, Sooel. The Hitchhiker’s Guide to DNS Cache Poisoning (PDF). Cornell University. Архів оригіналу (PDF) за 14 серпня 2017. Процитовано 3 квітня 2017.
  2. Root DNSSEC. ICANN/Verisign. с. 1. Архів оригіналу за 10 вересня 2017. Процитовано 5 січня 2012.