Будучи одним із основних елементів інфраструктури IP-мереж, служба доменних імен (DNS) в той же час далеко неідеальна з точки зору інформаційної безпеки. Застосування транспортного протоколу без встановлення віртуального каналу (UDP), відсутність вбудованих засобів ідентифікації, аутентифікації і розмежування доступу роблять її вразливою для віддалених атак різних типів.
У даній статті розглядається межсегментная віддалена атака на DNS-сервер, що не вимагає виконання будь-яких жорстких умов і допускає ефективну практичну реалізацію.
1. DNS з висоти пташиного польоту
Служба доменних імен являє собою розподілену базу даних, основним змістом якої є інформація про відповідність символічних імен мережевих об’єктів їх IP-адресами. DNS організована за ієрархічним принципом. Структурною одиницею цієї бази є домен (domain), який в свою чергу може містити інші домени (піддомени).
Первинним джерелом інформації про кожному домені є відповідальний за даний домен DNS-сервер (насправді їх може бути декілька). Відповідальність за частину доменної інформації (піддомени) може бути делегована іншим серверам.
Клієнтська частина DNS називається резолвером (resolver), доступ до якого прикладні програми отримують через API операційної системи. При взаємодії резолвера з сервером в якості транспортного протоколу UDP використовується, не передбачає формування віртуального каналу. Запити, що генеруються резолвером, є рекурсивними, тобто в якості відповіді на такий запит повертається або шукана інформація, або повідомлення про її відсутність.
Отримавши запит від резолвера, сервер або відразу ж повертає відповідь (за умови наявності бажаної інформації в локальній базі), або формує запит до іншого сервера. Цей запит зазвичай є ітеративним і, на відміну від рекурсивного, допускає відповідь у вигляді посилання на інший сервер, який краще обізнаний про місце розташування шуканої інформації.
У загальному випадку пошук починається з кореневого сервера, який повертає інформацію про сервери, відповідальних за домени верхнього рівня, після чого формується новий ітеративний запит до одного з цих серверів і т. д. Результатом такої ланцюжка питань-відповідей є або отримання шуканої інформації, або висновок про її відсутність, після чого отриманий відповідь повертається резолверу. Вся накопичена сервером в процесі роботи інформація кешується з метою прискорення обслуговування наступних запитів та мінімізації мережевого трафіку.
2. Межсегментная віддалена атака на DNS-сервер
Можливість атаки на DNS шляхом фальсифікації відповіді DNS-сервера відома досить давно (див., наприклад, Медведовський І. Д., Сем’янів П. В., Платонов Ст. Ст. Атака через Internet. — СПб.: «Світ і сім’я-95», 1997.). Об’єктом атаки може бути як резолвер, так і DNS-сервер. Причини успіху подібних атак криються в легкості підробки відповіді сервера. Протоколи DNS, використовувані в даний час, не передбачають будь-яких засобів перевірки автентичності отриманих даних та їх джерела, повністю покладаючись у цьому на нижележащие протоколи транспортного рівня. Використовується транспортний протокол (UDP) з метою підвищення ефективності не передбачає встановлення віртуального каналу і використовує в якості ідентифікатора джерела повідомлення IP-адресу, який може бути елементарно підроблений.
При наявності у атакуючого можливості перехоплення повідомлень, якими обмінюються клієнт і сервер (внутрисегментная атака) реалізація атаки не становить жодних труднощів. Проте цей варіант не представляє і значного практичного інтересу, оскільки можливість внутрисегментной атаки припускає наявність певного взаємного розташування клієнта, сервера та назву атакуючого (наприклад, атакуючий і цільової DNS-сервер поділяють загальну фізичне середовище передачі), що на практиці реалізується досить рідко.
Значно більш загальним випадком є межсегментная атака, яка не потребує для своєї реалізації таких жорстких умов. З цієї причини ми зупинимося на розгляді саме цього класу віддалених атак, що представляють як академічну, так і практичний інтерес.
Межсегментная атака на DNS-сервер виглядає наступним чином. Припустимо для визначеності, що метою атаки є «підміна» IP-адреси web-сервера www.coolsite.com на IP-адресу сервера www.badsite.com для користувачів деякої підмережі, яку обслуговує DNS-сервер ns.victim.com. У першій фазі атаки ns.victim.com провокується на пошук інформації про IP-адресу www.coolsite.com шляхом надсилання йому відповідного рекурсивного запиту. У другій фазі атакуючий посилає серверу ns.victim.com помилковий відповідь від імені ns.coolsite.com, який є відповідальним за домен coolsite.com. У неправдивому відповіді замість реального IP-адреси www.coolsite.com вказується IP-адресу www.badsite.com. Сервер ns.victim.com кешує отриману інформацію, в результаті чого протягом певного проміжку часу (величина цього проміжку вказується в полі TTL помилкового відповіді і може вибиратися довільно атакуючим) нічого не підозрюючи, користувачі замість сервера www.coolsite.com потрапляють на www.badsite.com.
Для того, щоб помилковий відповідь був сприйнятий сервером ns.victim.com як істинний, досить виконання чотирьох умов:
IP-адреса відправника відповіді повинен відповідати IP-адресою запитуваного сервера (в нашому випадку ns.coolsite.com);
UDP-порт, на який надсилається відповідь, повинен збігатися з портом, з якого був надісланий запит;
ідентифікатор відповіді повинен збігатися з ідентифікатором запиту;
відповідь повинна містити запитувану інформацію (у нашому випадку IP-адреса web-сервера www.coolsite.com).
Очевидно, що виконання першого і четвертого умов не представляє для атакуючого особливих труднощів. З другим і третім умовами ситуація набагато складніше, оскільки у разі межсегментной атаки у атакуючого немає можливості перехопити вихідний запит і «підглянути» необхідні параметри.
Більшість використовуваних в даний час реалізацій DNS-сервера (BIND4, MS DNS) використовують для вихідних запитів 53 порт, так що можна «на удачу» послати помилковий відповідь на цей порт. Однак даний метод буде спрацьовувати не завжди, оскільки, наприклад, BIND8 може використовувати для вихідних запитів будь випадково обраний непривилегированный порт.
Ідентифікатор (id) запиту являє собою двобайтове число, визначене сервером в запиті з метою однозначної ідентифікації відповіді на цей запит. Це число инкрементируется з кожним новим запитом. Незнання поточного значення ідентифікатора призводить до необхідності посилки безлічі помилкових відповідей з різними значеннями id.
Саме ця обставина робить практичну реалізацію даної атаки дуже трудноосуществимой. Дійсно, помилковий відповідь має бути отриманий цільовим сервером в проміжок часу з моменту надсилання запиту і до моменту приходу відповіді від цього сервера, що на практиці складає не більше декількох секунд. За цей інтервал часу атакуючому необхідно надіслати 216 помилкових відповідей з усіма можливими значеннями id, а в разі незнання порту ця цифра збільшується ще в кілька десятків разів. Оскільки розмір IP-пакета, що містить неправдиву відповідь, становить близько 100 байт, то перед атакуючим ставиться завдання пересилання декількох мегабайт інформації за кілька секунд, що в переважній більшості випадків нездійсненно.
3. Метод визначення номера порту і поточного ідентифікатора запиту
При виконанні додаткового умови навіть у разі межсегментной атаки у атакуючого є можливість визначення поточного id запиту і номера порту. Такою умовою є наявність контрольованого атакуючим DNS-сервера, відповідального за будь домен. Контроль над сервером в даному контексті означає можливість перехоплення всіх запитів, адресованих цього сервера. Це можливо або якщо атакуючий безпосередньо володіє сервером (є його адміністратором), або поділяє з ним спільну фізичне середовище передачі (у випадку ethernet це означає знаходження в одному колізійному домені). Очевидно, що ця умова не є надто жорстким, оскільки перебування в одному колізійному домені з DNS-сервером досить типово для багатьох користувачів корпоративних мереж.
При наявності контрольованого сервера описана атака може бути модифікована таким чином. Припустимо для визначеності, що атакуючий контролює сервер ns.hacker.com відповідальний за домен hacker.com. У першій фазі атаки ми провокуємо сервер ns.victim.com на звернення до ns.hacker.com шляхом посилки рекурсивного запиту на пошук інформації про будь імені (не обов’язково реальному) в домені hacker.com. Оскільки ns.hacker.com знаходиться під контролем атакуючого, він може перехопити цей запит і отримати з нього інформацію про номер порту і поточному id.
Наступні дві фази атаки не відрізняються від описаних, з тією лише різницею, що тепер атакуючому досить послати лише кілька помилкових відповідей, оскільки він точно знає номер порту і може з високим ступенем точності передбачити значення ідентифікатора запиту до ns.coolsite.com.
4. Метод непрямої провокації
Очевидно, що необхідною умовою успішності описаної атаки є можливість посилки рекурсивних запитів цільовим сервера, що провокують його на звернення до інших серверів з метою пошуку необхідної інформації. В принципі, існує можливість настроїти DNS-сервер таким чином, що він буде приймати рекурсивні запити тільки від «своїх» клієнтів (хостів, резолверы яких налаштовані на використання даного сервера). В цьому випадку здійснення атаки стає неможливим.
З метою обходу цього обмеження можна запропонувати простий метод, який умовно назвемо «непрямої провокацією». Основна ідея цього методу полягає у використанні будь-якого загальнодоступного сервісу, що є клієнтом цільового DNS-сервера, для формування необхідного провокуючого запиту. Найбільш підходящим кандидатом представляється загальнодоступний сервер електронної пошти, який за визначенням повинен приймати з’єднання з будь-якого комп’ютера Internet. Припустимо, що резолвер комп’ютера mail.victim.com налаштований на використання сервера ns.victim.com, причому останній приймає рекурсивні запити тільки від домену victim.com. Наведений нижче SMTP-діалог провокує ns.victim.com на пошук інформації про імені any-name.any-domain.com:
$ telnet mail.victim.com 25
Trying…
Connected to mail.victim.com.
Escape character is ‘^]’.
220 mail.victim.com ESMTP Sendmail 8.8.0/8.8.0; Wed, 5 May 1999 21:30:42
helo I. am.cracker
250 mail.victim.com Hello crack.hacker.com [1.1.1.1], pleased to meet you
mail from: [email protected]
250 [email protected] Sender ok
quit
221 mail.victim.com closing connection
Connection closed.

Таким чином, застосування методу «непрямої провокації» дозволяє здійснити атаку без прямої посилки запитів цільовим DNS-сервера.
5. Як виникають епідемії
У звичайних умови успішна атака призводить до «зараження» кеша конкретного сервера і область поширення неправдивої інформації обмежується тільки його клієнтами. Однак при наявності ситуації «некоректного делегування» (lame delegation), що виникає із-за помилок адміністрування, можливе поширення неправдивої інформації на інші сервера, що призведе до глобальної «зараження».
Під некоректним делегуванням розуміється ситуація, коли відповідальність за домен делегується сервера, що не володіє копією доменної інформації. Це призводить до того, що у відповідь на повторне запити інших серверів замість шуканої інформації він повертає посилання на інші сервера (іноді і на себе), які, з точки зору даного сервера, володіють необхідними відомостями.
Розглянемо ситуацію, коли для домену victim.com існують два відповідальних сервера — ns.victim.com і ns2.victim.com, причому для ns2.victim.com делегування виконано некоректно. Застосовуючи описані методи, атакуючий може «заразити» кеш сервера ns2.victim.com помилковою інформацією про імена в домені victim.com наприклад, підмінити IP-адреса web-сервера www.victim.com на IP-адресу www.very-bad-site.com. Оскільки ns2.victim.com вважається відповідальним за домен victim.com інші сервера в Internet будуть звертатися до нього за інформацією про імена в цьому домені. Не маючи локальною копією доменної інформації про victim.com цей сервер буде повертати у відповідь раніше кешовану неправдиву інформацію, приводячи до «зараження» всіх що звернулися до нього серверів.
Неприємною особливістю даного сценарію є неможливість швидкої ліквідації наслідків атаки, оскільки помилкова інформація буде знаходитися в кешах тисяч серверів до закінчення часу життя, яке атакуючий може вибрати дуже великим.
6. Реалізація та польові випробування
Програма, що реалізує атаку на DNS-сервер з використанням контрольованого сервера, стала доступна в Internet приблизно в лютому 1999 року. На щастя, використання цієї програми не зводиться до введення в віконце IP-адреси цільового сервера і натискання кнопки «Infect It!», а вимагає досить глибокого розуміння принципів роботи DNS, що відразу відсіває 99% потенційних користувачів. Крім того, у відомій автору реалізації зроблено далеко не все для підвищення ймовірності успіху атаки.
З метою забезпечення чистоти експерименту «польові випробування» були проведені на трьох непідконтрольних автору корпоративних мережах. Природно, адміністратори цих мереж були повідомлені і не заперечували проти проведення експерименту. Як це не сумно, у всіх трьох випадках атака була успішною.
Діапазон цілей, які можуть бути досягнуті за допомогою атаки на DNS, простягається від «відмовлення в обслуговуванні» і підміни web-сайтів до перехоплення повідомлень електронної пошти і повного контролю над інформацією, що передається між довільно вибраними хостами Internet. При всьому цьому атакуючий практично не залишає слідів, оскільки йому немає необхідності посилати провокують запити і помилкові відповіді з власного IP-адреси.
7. Погляд з іншого боку барикади
На думку автора, в даний час єдиним надійним засобом протидії описаної атаці є використання стандартизованих RFC2065 додаткових протоколів DNS, що передбачають застосування криптографічних методів аутентифікації доменної інформації та суб’єктів мережевої взаємодії. Базова підтримка цього стандарту вже включена в поточну версію BIND8.
На жаль, бажаний результат може дати тільки широкомасштабне впровадження нових протоколів, яке пов’язане зі значними організаційними труднощами і не може бути проведено за короткий час.
Дещо ускладнити здійснення атаки може заборону на обслуговування DNS-сервером рекурсивних запитів, що надходять не від «своїх» клієнтів. Це може бути зроблено як засобами самого сервера (наприклад, BIND8 володіє такими можливостями), так і засобами міжмережевого екрану. Слід звернути увагу на налаштування «антиспуффинговых» правил фільтрації на брандмауері екрані, оскільки атакуючий як IP-адреси відправника запиту може вказати будь-яку адресу, в тому числі і легального клієнта.
При використанні даного методу не слід забувати, що такий захист може бути досить легко подолана використанням описаного методу непрямої провокації.
Висновок
На відміну від вже набили оскому атак, що використовують «дірки» в конкретних реалізаціях мережевих сервісів, помилки адміністрування або методи «соціальної інженерії», атака на DNS представляється автору дуже витонченою.
У той же час за характером і масштабністю результатів дана атака цілком може бути зарахована до інформаційного зброї масового ураження. Відсутність адекватних засобів захисту, дуже слабо виражені сліди і складність усунення наслідків атаки ще більше погіршують ситуацію.
Дещо дивує той факт, що дана віддалена атака широко не застосовується зломщиками (принаймні, автор не володіє такою інформацією). Цілком можливо, це пояснюється просто недостатньою кваліфікацією переважної кількості людей, які називають себе хакерами. Мережевим адміністраторам залишається тільки сподіватися, що уразливість протоколів DNS до даної атаки буде усунена перш, ніж вони відчують на собі її наслідки.