DNS cache poisoning

DNS cache poisoning (отруєння кешу DNS) — пошкодження цілісності даних у системі DNS шляхом заповнення кешу DNS-сервера даними, що не походять від авторитетного DNS-джерела. Подібна компрометація даних може бути результатом хакерської атаки на сервер імен або несподіваним результатом помилки в конфігурації DNS-кешу. Даний тип атаки був вперше вивчений і описаний у 2008 році експертом з інформаційної безпеки Деном Камінські. Перша відома велика атака такого типу була здійснена Євгеном Кашпуревим у 1997 році.

Коли DNS-сервер отримує неавтентичні дані і кешує їх для оптимізації швидкодії, він стає отруєним і починає надавати неавтентичні дані своїм клієнтам.

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

Атаки на кеш[ред. | ред. код]

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

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

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

Приклади атаки[ред. | ред. код]

У наведених нижче прикладах A-запис для сервера ns.target.example буде замінений (кеш буде отруєний) і стане вказувати на DNS-сервер атакуючого з IP-адресою w.x.y.z. В прикладі припускається, що DNS-сервером target.example є ns.target.example.

Щоб виконати таку атаку, атакуючий повинен змусити DNS-сервер-жертву виконати запит про будь-який домен, для якого DNS-сервер атакуючого є авторитетним.

Підміна IP-адреси DNS-сервера домену жертви[ред. | ред. код]

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

Запит від DNS-сервера жертви: який A-запис для 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 

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

Підміна NS-запису для іншого домену жертви[ред. | ред. код]

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

Запит DNS-сервера: який A-запис для 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-запис, який не відноситься до запиту про NS-запис для target.example в кеші, що дозволить атакуючому відповідати на наступні запити для всього домену target.example.

Запобігання атакам і протидія[ред. | ред. код]

Більшість атак на кеш можуть бути відвернені на стороні DNS-серверів за допомогою зменшення ступеня довіри до інформації, що надходить від інших DNS-серверів, або навіть ігнорування будь-яких DNS-записів, які прямо не належать до запитів. Наприклад, останні версії BIND (версії 9, 10) виконують такі перевірки. Суттєво знизити імовірність успішної атаки на кеш може використання випадкових UDP-портів для виконання DNS-запитів.

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

Протокол DNSSEC використовує електронний цифровий підпис із побудовою ланцюжка довіри для визначення цілісності даних. Застосування DNSSEC може звести результативність атак на кеш до нуля. У 2011 році впровадження DNSSEC йде вже швидкими темпами (більшість доменних зон gTLD: .com, .net, .org — вже підписані DNSSEC). Починаючи з липня 2010 року, кореневі сервери DNS містять кореневу зону DNS, підписану за допомогою стандартів DNSSEC.

Атакам на кеш також можна протиставити транспортний рівень або рівень додатків моделі OSI, оскільки і на цих рівнях можна використати цифрові підписи. Наприклад, у безпечній версії HTTPHTTPS користувач може перевірити, чи має сервер, з яким він з'єднався, сертифікат ЕЦП і кому цей сертифікат належить.

Схожий рівень безпеки має SSH, коли програма-клієнт перевіряє ЕЦП віддаленого сервера при встановленні з'єднання. З'єднання за допомогою IPSEC не встановиться, якщо клієнтом і сервером не будуть пред'явлені заздалегідь відомі ключі ЕЦП. Додатки, які завантажують свої оновлення автоматично, можуть мати вбудовану копію сертифікату ЕЦП і перевіряти справжність оновлень за допомогою порівняння ЕЦП сервера оновлень із вбудованим сертифікатом.

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

Посилання[ред. | ред. код]