Оригінал: Cyber ​​Attacks Explained: DNS Invasions
Автор: Prashant Phatak
Дата публікації: 22 лютого 2012 р.
Переклад: А.Панін
Дата перекладу: 8 грудня 2012 р.

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

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

Малюнок 1 відбиває фундаментальні принципи роботи служби дозволу мережних імен. Коли програма (така, як браузер) хоче встановити з'єднання з віддаленою службою, воно здійснює запит IP-адреси у DNS-сервера. Цей запит у вигляді пакета відправляється через порт UDP номер 53, після чого сервер повертає відповідь у формі пакета. (Слід пам'ятати про те, що через обмеження розміру даних в UDP-дейтаграмі 512 байтами, стек протоколів автоматично використовує протокол TCP для здійснення запитів та прийому відповідей.) Коли клієнт приймає відповідь, він додає дані у свій локальний кеш, що дозволяє прискорити наступні звернення до цього домену. Елементи локального кешу автоматично знищуються після закінчення часу життя (параметр TTL (Time to Live)).

Рисунок 1: Дозвіл доменних імен

Система DNS використовує такі типи записів, як A, CNAME, SOA, MX та інші. Хоча опис цих типів записів і виходить за межі цієї статті, системним адміністраторам важливо знати про те, коли і як їх слід використовувати, а перед їх використанням має проводитись дослідження з точки зору майбутньої безпеки системи. Перед тим, як розглянути атаки на систему DNS, нам необхідно розглянути два типи запитів – ітераційні та рекурсивні.

• Ітераційні запити DNS: У той час, як клієнт відправляє запит DNS-серверу, бажаючи отримати інформацію про домен, DNS-сервер може розташовувати, так і не мати інформацію про цей домен. Якщо DNS-сервер не має відповіді, замість завершення запиту, він відправляє ім'я вищого DNS-сервера, у якого може бути необхідна інформація, клієнту. Зазвичай цей процес називають перенаправленням DNS-запитів (DNS referral). Клієнт надсилає запит наступному (вказаному) серверу; якщо він не має відповіді, він відправляє клієнту ім'я вищого сервера. Цей процес триває доти, доки клієнт отримує або IP-адресу, або повідомлення про помилку про неможливість виконання запиту.
• Рекурсивні запити DNS: У цьому випадку процес починається з того, що клієнт запит запиту на ім'я домену безпосередньо до DNS-сервера. Якщо DNS-сервер не має відповіді, передбачається, що він виконає роботу з обміну даними з вищими серверами замість того, щоб просто надати їхні імена клієнту. Знову, якщо вищий сервер не має інформації для відповіді на запит, він переадресує запит вищому серверу. Цей процес триває доти, доки запит не доходить до кореневого DNS-сервера, який повинен мати необхідною інформацієюі клієнту повертається відповідь, а у випадку, якщо запитаного імені не існує, клієнту повертається повідомлення про помилку ланцюжком серверів. На відміну від ітераційного методу, рекурсивний запит вважається агресивнішим у отриманні результату.

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

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

Атаки на системи DNS

Було помічено, що системні адміністраторивитрачають багато часу на розробку систем безпеки для програм, серверів та інших компонентів інфраструктури, але, на жаль, мають схильність забувати про системи безпеки для DNS-серверів. Розгляньте малюнок 2, на якому показані можливі слабкі місця DNS-серверів, які роблять їх вразливими до атак. Система DNS спроектована таким чином, що більша частина обміну даними відбувається за протоколом UDP, в ній не передбачено вбудованої системи безпеки і немає вбудованої підтримки автентифікації - все це робить її більш уразливою до атак, ніж інші мережеві служби. Давайте розглянемо кілька типів найпоширеніших атак на DNS.

Малюнок 2: Можливі слабкі місця DNS-серверів

Модифікація кешу DNS (DNS cache poisoning)

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

Наприклад, якщо браузер намагається отримати доступ до сайту з адресою http://www.cnn.com/, замість IP-адреси CNN він отримує адресу, встановлену програмним забезпеченням зломщика, який зазвичай веде на сайт, розташований на сервері, що належить зломщику, та містить шкідливе програмне забезпечення або повідомлення, що ображає користувача.

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

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

Підміна DNS-сервера (DNS hijacking)

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

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

Спуфінг DNS-запитів (DNS spoofing)

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

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

Існує альтернативний спосібцієї атаки, що називається спуфінгом ідентифікаторів DNS-запитів (DNS ID spoofing). Кожен DNS-запит та відповідь мають унікальні ідентифікатори, призначені для того, щоб розділити між собою запити, спрямовані на DNS-сервер в один і той же час. Ці унікальні ідентифікатори часто формуються з MAC-адреси, дати та часу здійснення запиту та створюються стеком протоколів автоматично.

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

Перезакріплення DNS (DNS rebinding)

Ця атака також має назву "закріплення DNS" ("DNS pinnig") та є особливо складною атакою. Під час неї зломщик спочатку реєструє своє власне доменне ім'я, потім встановлює мінімальне значення часу життя записів, яке запобігає попаданню інформації про це доменне ім'я в кеш.

Атаки відмови в обслуговуванні щодо DNS (DNS denial of service)

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

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

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

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

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

Захист систем на основі вільного програмного забезпечення

У світі вільних систем існує реалізація служби дозволу доменних імен, відома у всьому світі через найвищу швидкість роботи в порівнянні з аналогами. Цим найбільш широко використовуваним та відомим рішенням є служба Bind. Проте, оскільки більшість атак на служби DNS використовують недоробки протоколу, завдання захисту вільних систем зі службами дозволу доменних імен ускладнюється.

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

Наступним важливим кроком є ​​контроль того, щоб на сервер не встановлювалося програмне забезпечення, крім служби дозволу доменних імен. Цей запобіжний захід повинен виконуватися особливо в тому випадку, коли проводиться робота з корпоративним кореневим сервером роздільної здатності імен, що підтримує дозвіл всіх внутрішніх імен доменів і обслуговує всі запити щодо дозволу імен до зовнішніх серверів для локальної мережі.

Часто трапляється таке, що вразливість у сторонній програмідозволяє здійснити проникнення на сервер дозволу імен. Хоча найбільш важливі частини мережної інфраструктури і захищені міжмережевим екраном, уніфікованими пристроями контролю (Unified Threat Management) та потужними антивірусними програмами, часто необхідно посилити захист системою виявлення проникнень (Intrusion Detection System). Вона дозволяє відображати атаки 2 і 3 рівнів OSI, такі як ARP-спуфінг, IP-спуфінг, атаки з використанням сніфера та інші типи атак.

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

Для цього існують програми з відкритим вихідним кодом, але за їх використанні слід пам'ятати, що вони вносять невелику тимчасову затримку процес обробки запиту. Щодо нової та популярної технології захисту є DNSSEC (Розширення безпеки DNS (DNS Security Extensions)). Вона захищає клієнти та сервери від атак, при яких модифікується кеш DNS, підписуючи записи з використанням шифрування з відкритим ключем. Працюючи аналогічно SSL, запитує дані і сторони, що відповідає, встановлюють довірене з'єднання один з одним, а як тільки воно встановлено, починається процес дозволу імен.

Як тільки процес вирішення імен завершується, сесія скидається і таким чином підтримується безпека обох сторін. Технологія DNSSEC реалізована на більшості серверів інтернет-провайдерів у світі.

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

Ця стаття входить до серії статей про кібератаки, написані тим самим автором (Prashant Phatak). Інші статті цієї серії.

Підміна DNS (DNS Spoofing)

Система DNS ( Domain Name System) перетворює доменне ім'я (наприклад, www.test.com) на його IP-адресу (наприклад, 192.168.0.1) і навпаки. Ця атака використовує технологію надсилання фальшивих відповідей на DNS-запити жертви. Атака ґрунтується на двох основних методах.

Підміна DNS ID (DNS ID Spoofing)

Заголовок пакета DNS-протоколу містить ідентифікаційне поле для відповідності запитів та відповідей. Метою підміни DNS ID є надсилання своєї відповіді на DNS-запит до того, як відповість справжній DNS-сервер. Для цього потрібно спрогнозувати ідентифікатор запиту. Локально це реалізується простим прослуховуванням трафіку мережі. Однак, віддалено виконати це завдання набагато складніше. Існують різні методи:

перевірка всіх доступних значеньідентифікаційного поля. Не дуже практично, оскільки загальна кількість можливих значень становить 65 535 (розмір поля 16 біт);

надсилання кількох сотень DNS-запитів у правильному порядку. Очевидно, що цей метод не надто надійний;

знаходження сервера, що генерує прогнозовані ідентифікатори (наприклад, що збільшуються на 1). Цей тип уразливості притаманний деяким версіям Bind та системам Windows 9x.

У будь-якому випадку необхідно відповісти до цього DNS-сервера. Цього можна досягти, наприклад, виконавши проти сервера атаку типу "відмова в обслуговуванні".

Для проведення успішної атаки зловмисник повинен контролювати DNS-сервер (ns.attaquant.com), авторитетний для зони attaquant.com. Цільовий DNS-сервер (ns.cible.com) імовірно генерує прогнозовані ідентифікаційні номери(що збільшуються на 1 при кожному запиті).

Атака вимагає виконання чотирьох кроків:

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

Зміна DNS Cache Poisoning

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

Використовуємо ті ж дані, що й у попередньому прикладі. Ось ключові моменти цього варіанта атаки:

надіслати DNS-запит на дозвіл імені www.attaquant.com DNS-серверу домену cible.com;

цільовий DNS-сервер надсилає запит на дозвіл імені www.attaquant.com DNS-серверу зловмисника;

DNS spoofing - це простий метод обману dns системи, блок перетворення імен dns, що використовує неправдиву інформацію, отриману від хоста, який не відповідає за ту інформацію. Кожен пакет dns має 16 бітний id номер, id номер це частина dns пакету, яка дозволяє ідентифікувати кожен dns пакет, який йде через порт 53 і так само запит може бути більше одного разу. id це єдиний спосіб розрізнити різні запити dns, пов'язані з цим, яке сервери dns використовують, щоб визначити, який початковий був запит. У разі BIND цей номер збільшується на 1 рівень для кожного запиту. Напад, подібний до TCP seq id може бути зроблено, хоча це важче. Навіть якщо BIND не може кешувати інформацію, яку ви надсилаєте, він передасть відповідь до оригінального хоста. У випадку ircd зробить запит на PTR у відповідь до хоста, що з'єднується з ним, пакет відповіді може бути сформульований, щоб містити додаткову інформацію, з якої ircd робитиме внутрішнє кешування. Для цієї атаки потрібен доступ root'a на сервері dns, відповідальному за in-addr. arpa блок інформації dns. Також, ircd може кешувати тільки один домен. перебрати весь idspace. Для того щоб підробити свій dns допустимо на DALNet'e, потрібно надіслати 65000 згенерованих запитів на ns сервер, як тільки комп'ютер отримує відповідь на запит, потрібно буде прочитати пакет, і в ньому буде написано правильний id. Як тільки отримаєте id, потрібно знайти який-небудь "packet" creation toolщоб зробити dns пакет. Залишається тільки підробити dns пакети, послати на ns. dal. net і отримуєте spoofing TCP з'єднання.

Загальна постановка проблеми У зв'язку з бурхливим зростанням мережі Internet проблема захисту інформаційних ресурсівставитися дедалі значимішою. Якщо ви підключені до Інтернету, ваша система може бути атакована. Розглянемо роботу DNS. Зовнішньосегментна адресація здійснюється за IP-адресами, але звернення до серверів, як правило, здійснюється за доменними іменами. У цьому була створена система перетворення (порівняння) доменних імен в IP адреси – DNS-серверів (Domain Name System). Ця система відповідає за знаходження IP-адреси віддаленого хоста на його ім'я. Принцип функціонування DNS системи наступний – віддалений хост посилає на IP-адресу найближчого DNS-сервера спеціальний запит, в якому вказує ім'я сервера, IP-адресу якого необхідно знайти. Отримавши запит, DNS-сервер переглядає свою базу даних на наявність доменного імені, що запитується. Якщо ім'я знайдено, DNS-сервер повертає відповідь, в якій вказує IP-адресу. Якщо вказане в запиті ім'я DNS-сервер не виявив у своїй базі імен, то DNS-запит надсилається DNS-сервером на один із кореневих DNS-серверів і описана в цьому пункті процедура повторюється, доки ім'я не буде знайдено. Розглянемо узагальнену схему роботи помилкового DNS-сервера: очікування DNS-запиту; отримавши DNS-запит, вилучення з нього необхідних відомостей і передача по мережі на хост, що запитав помилкового DNS-відповіді, від імені (з IP-адреси) справжнього DNS-сервера, в якому вказується IP-адреса помилкового DNS-сервера; у разі отримання пакета від хоста, зміна в IP-заголовку пакета його IP-адреси на IP-адресу помилкового DNS-сервера та передача пакета на сервер (тобто, помилковий DNS-сервер веде роботу з сервером від свого імені); у разі отримання пакета від сервера, зміна в IP-заголовку пакета його IP-адреси на IP-адресу помилкового DNS-сервера та передача пакета на хост (для хоста помилковий DNS-сервер і є справжнім сервером).

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

Як показує аналіз існуючих прийомів захисту, протидія атак може здійснюватися наступними методами. Шляхом переведення роботи DNS на роботу за протоколом TCP Перехід від UDP до TCP дещо уповільнить систему. При використанні ТСР потрібно створення віртуального з'єднання, а так само варто врахувати, що кінцеві мережеві ОС спочатку посилають DNS-запит з використанням протоколу UDP і в тому випадку, якщо їм прийде спеціальна відповідь від DNS-сервера, тоді мережна ОС надішле DNS-запит з використанням ТСР . Використання протоколу ТСР ускладнить атаку шляхом заміни пакетів, але сповільнить роботу. Шляхом аналізу трафіку DNS. Протидіяти атакам можна шляхом аналізу трафіку. На DNS-сервер постійно надсилаються помилкові пакети з помилковими IP адресами. Якщо отриманий хибний пакет збігся за значеннями із запитом, то хибний IP приймається як істинний. Якщо перехоплення пакета від сервера не відбулося, то атака характеризується великою кількістю DNS пакетів з тим самим ім'ям. Це пов'язано з необхідністю підбору деяких параметрів обміну DNS. Аналізуючи DNS трафік можна ігнорувати такі пакети, щоб уникнути заміни IP адреси.

Висновки Вивчивши роботу DNS-сервера можна побачити, що поточна версія є досить неоптимальною та вразливою для різноманітних атак. Протидіяти атак можна шляхом аналізу DNS трафіку або перекладом роботи DNS з UPD на TCP. Жоден з методів не дає повного захисту від атак, обидва методи лише ускладнюють можливість твору атаки. Обидва методи потребують додаткових ресурсів від сервера. Що стосується перекладу роботи DNS-сервера на TCP, збільшується час обміну між серверами, т. к. протокол UDP швидший, ніж TCP протокол. на даний момент, запропоновані моделі протидії є найбільш ефективними та їх доцільно використовувати у комплексі для досягнення максимально можливої ​​захищеності.

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

Як працює спуфінг?

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

Як розпізнати спуфінг?

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

Як усунути спуфінг?

Спуфінг полягає в маскування справжнього джерела, тому його не так просто "усунути". Убезпечити себе можна лише за здоровим глуздом і дотримуючись базові правилабезпечної роботи в мережі, наприклад, не за яких умов не повідомляючи свої персональні дані ел. поштою, навіть якщо репутація відправника не викликає сумніву.

Як запобігти спуфінгу

• Не відповідайте на повідомлення, в яких вас просять надіслати свої персональні чи облікові дані
• Уважно перевіряйте адресу відправника
• Звертайте увагу на дива у поведінці чи відмінності в деталях звичних вам сайтів

Убезпечте себе від спуфінгу

З одного боку, захист від спуфінгу може полягати у дотриманні базових принципів безпечної роботи в Інтернеті. Однак ви можете зробити значно більше з метою власної безпеки. Перш за все, ви можете довірити захист свого ПК і даних, що зберігаються на ньому, потужному антивірусному рішенню, наприклад, одному з розроблюваних компанією Avast, які надійно захищають від шахрайських сайтів і блокують віруси, які намагаються проникнути у вашу мережу.

Спуфінг досить цікавий метод атак, яким багато професіоналів в області ІБ нехтують. А даремно, дуже навіть дарма. З цієї статті ти зрозумієш, наскільки оманливим може бути цей різноманітний світ. Не вір своїм очам!

WARNING

Вся інформація надана виключно для ознайомлення. Ні редакція, ні автор не несуть відповідальності за будь-яку можливу шкоду, заподіяну матеріалами цієї статті.

Intro

Найчастіше від колег по цеху мені доводиться чути, що спуфінг як вектор атаки не варто навіть розглядати. Однак смію тебе запевнити: якщо методи спуфінгу ретельно продумані, то використовувати їх можна для дуже багато чого. Причому масштаби та результати таких атак часом бувають катастрофічними. Адже, обдуривши твої очі один раз, я обманюватиму тебе і далі. Найголовніший аргумент на користь того, що spoof-атаки становлять реальну небезпеку - від них не застрахована жодна людина, включаючи і професіоналів. Тут слід зауважити, що сам собою спуфінг нічого не дає: для проведення дійсно хакерської атаки необхідно використовувати постексплуатацію (post-exploitation). У більшості випадків цілі постексплуатації полягають у стандартному захопленні управління, підвищенні привілеїв, масовому поширенні шкідливих програмі, як наслідок, крадіжці персональних даних та електронно-цифрових ключів банківських систем з подальшим відмиванням грошей. У цій статті я, по-перше, хочу розповісти про те, які взагалі бувають методи спуфінгу, і, по-друге, докладно розповісти про деякі сучасні підходи. Звісно, ​​вся інформація надається тобі лише з метою допомоги у захисті від таких атак.

Минуле та сьогодення спуфінгу

Спочатку термін «spoofing» використовувався як термін мережевої безпеки, що передбачає успішну фальсифікацію певних даних з метою отримання несанкціонованого доступу до того чи іншого ресурсу мережі. Згодом цей термін почав вживатися і в інших сферах інфобезпеки, хоча більшість так званих old school фахівців і сьогодні продовжують використовувати слово «spoofing» лише для уточнення типу мережевих атак.

Перші IDN-клони

Атаку з використанням IDN-омографів вперше описали у 2001 році Євген Габрилович та Алекс Гонтмахер із ізраїльського технологічного інституту Техніон. Перший відомий випадок успішної атаки, що використовує даний метод, був оприлюднений у 2005 році на хакерській конференції ShmooCon. Хакерам вдалося зареєструвати підставний домен pаypal.com (xn-pypal-4ve.com в Punycode), де перша літера а - кирилична. Завдяки публікації на Slashdot.org до проблеми було привернуто увагу громадськості, після чого як браузери, так і адміністратори багатьох доменів. верхнього рівнявиробили та реалізували контрзаходи.

Отже, коли Мережа лише зароджувалася, більшість зусиль програмістів і розробників було спрямовано переважно оптимізацію алгоритмів роботи мережевих протоколів. Безпека не була настільки критичним завданням, як сьогодні, і їй, як це часто буває, приділяли дуже мало уваги. Як результат, отримуємо банальні та фундаментальні помилки в мережевих протоколах, які продовжують існувати і сьогодні, незважаючи на різноманітні латки (бо ніякою латкою не залатати логічну помилку протоколу). Тут потрібні тотальні зміни, які Мережа у існуючому уявленні просто не переживе. Наприклад, у статті "Атаки на DNS: вчора, сьогодні, завтра" (][ #5 2012) я розповідав про фундаментальні вразливості, що призводять до катастрофічних наслідків у DNS-системах - використання протоколу UDP (який, на відміну від TCP/IP, є небезпечним, тому що в ньому відсутній вбудований механізм для запобігання спуфінгу) і локального кешу.

Вектори

Залежно від цілей та завдань вектори спуфінгу можна розділити за напрямками на локальні (local) та мережеві (net). Саме їх ми й розглянемо у цій статті. Як об'єкт атак при локальному векторі найчастіше розглядається безпосередньо сама ОС, встановлена ​​на комп'ютері жертви, а також певні програми, які часто вимагають додаткового аналізу в залежності від ситуації. Об'єкти атак при мережному векторі, навпаки, абстрагованіші. Основними є компоненти інформаційних систем, представлених як локальними, і глобальними мережами. Розглянемо основні види спуфінгу.

1. Spoofing TCP/IP & UDP – атаки на рівні транспорту. Через фундаментальні помилки реалізації транспорту протоколів TCP і UDP можливі такі типи атак:
   • IP spoofing - ідея полягає у підміні IP-адреси через зміну значення поля source у тілі IP-пакета. Застосовується з метою заміни адреси атакуючого, наприклад, для того, щоб викликати пакет у відповідь на потрібну адресу;
   • ARP spoofing – техніка атаки в Ethernet-мережах, що дозволяє перехоплювати трафік між хостами. Заснована на використанні протоколу ARP;
   • DNS Cache Poisoning – отруєння DNS-кешу сервера;
   • NetBIOS/NBNS spoofing - заснована на особливостях резолва імен локальних машин усередині мереж Microsoft.
2. Referrer spoofing – підміна реферера.
3. Poisoning of file-sharing networks - фішинг у файлообмінних мережах.
4. Caller ID spoofing - підміна номера телефону в VoIP-мережах
5. E-mail address spoofing – підміна адреси e-mail відправника.
6. GPS Spoofing - підміна пакетів із супутника з метою спантеличити GPS-пристрій.
7. Voice Mail spoofing – підміна номерів голосової поштиз метою фішингу паролів жертви.
8. SMS spoofing - метод спуфінгу, заснований на заміні номерів відправника SMS-повідомлення.

Найновіші напрацювання в галузі спуфінгу

Найбільш поширені техніки вже досить старі та побиті. Глобальна мережабуквально кишить інформацією про можливі варіації їх експлуатації та захисту від них. Сьогодні ми розглянемо кілька нових методів спуфінгу, застосування яких лише набирає обертів, починаючи з локальних векторів і закінчуючи мережевими. Отже, все по черзі.

Flamer та скандальний спуфінг сертифікатів Microsoft

Microsoft Security Advisory (2718704) - Unauthorized Digital Certificates Could Allow Spoofing. Досить цікава річ була знайдена в екземплярах гучного шпигунського бота Flamer: за результатами реверс-інжинірингу компонентів цього шкідника було виявлено ділянку коду, що відповідає за проведення спуфінг-атак типу фішинг. Імітуючи надання оригінальних сертифікатів великих компаній, бот проводив MITM-атаку, метою якої було перехоплення персональних даних користувачів корпоративної мережіз наступним надсиланням на сервер розробників. Цей спуфінг-інцидент отримав Security Advisory #2718704 із рангом небезпеки High.

Спуфінг в ОС

1. Extension Spoofing – спуфінг розширення файлу

Техніка, що побачила світ завдяки напрацюванням китайського дослідника в області інформаційної безпеки Zhitao Zhou. Суть даної техніки полягає у використанні керуючого символу 0x202E (RLO) в імені файлу, що дозволяє змінити порядок символів при відображенні назви файлу провіднику Windows(Explorer.exe). Наведу приклад використання цієї простої техніки:

Super music uploaded by 3pm.SCR

Файл 3pm.SCR є нічим іншим, як виконуваний файл, реалізує певні функції (троянська програма. - Прим. редактора). Якщо на початку імені файлу "3pm.SRC" вставити керуючий символ 0x202E (див. рис. 1), то порядок символів змінюється на зворотний і ім'я файлу відображається у провіднику Windows вжеінакше:

Super music uploaded by RCS.mp3

Для зміни іконки файлу слід використовувати будь-який редактор ресурсів (Restorator, Resource Hacker). Ця техніка розрахована на необережного користувача, який може прийняти цей файл за пісню та відкрити подвійним клацанням, тим самим запустивши шкідливу програму. На жаль, ця техніка не працюватиме в програмах - аналогах провідника, які підтримують Юнікод. Нижче наведено код на C#, який змінює ім'я файлу, додаючи на початок керуючий символ 0x202E:

Public Sub U_202E(file As String, extension As String) Dim d As Integer = file.Length - 4 Dim u As Char = ChrW(823) Dim t As Char() = extension.ToCharArray() Array.Reverse(t) Dim dest As String = file.Substring(0, d) & u & New String(t) & file.Substring(d) System.IO.File.Move(file, dest) End Sub

2. File Name Spoofing – клонування імені файлу

Ця техніка була представлена ​​японським дослідником Yosuke Hasegawa на конференції Security-Momiji. Вона заснована на використанні символів нульової довжини (ZERO WIDTH Characters), які не впливають на відображення назви файлу (див. рис. 2). Нижче наведено всі символи з цієї категорії:

U+200B (ZERO WIDTH SPACE) - U+200C (ZERO WIDTH NON-JOINER) - U+200D (ZERO WIDTH JOINER) - U+FEFF (ZERO WIDTH NO-BREAK SPACE) - U+202A (LEFT-TO-RIGHT EMBEDDING)

Крім цього, можна використовувати кодування UTF для фальсифікації імен існуючих файлів. Цю техніку часто застосовує сучасний мальвар. У полі мого зору траплялися зразки шкідливих даних, які проводили такого роду атаки. Наприклад, зловред TrojanDropper:Win32/Vundo.L (використовувався для фішингу сайтів vk.com, vkontakte.ru, *odnoklassniki.ru) залучає саме цю техніку.

Файл %SystemRoot%\system32\drivers\etc\hosts копіювався у файл-«клон» hosts з UTF-символом «о» (0х043E), після чого оригінальному файлу hostsнадавався атрибут прихованого файлута його вміст перезаписувався з додаванням наступних записів:

92.38.66.111 odnoklassniki.ru 92.38.66.111 vk.com 92.38.66.111 vkontakte.ru

Спуфінг веб-браузерів

1. Status bar / Link spoof

Принцип цієї атаки полягає в динамічній заміні адреси гіпертекстового посилання ( ). Наприклад, жертва наводить курсор миші на посилання, після чого в статусбарі браузера відображається адреса, за якою веде це посилання. Після натискання на посилання хитрий JavaScript-код підміняє в динаміці адресу переходу. Мій знайомий дослідник, відомий під ніком iamjuza, займався вивченням та розробкою PoC для експлуатації даної техніки на практиці, але його розробки не були універсальними та діяли тільки на конкретних браузерах. Провівши аналогічне дослідження, я отримав більш вдалі результати, зумівши досягти універсальності експлуатації цієї техніки спуфера для всіх браузерних двигунів. Proof-of-Concept опубліковано на ресурсі 1337day.com. Технічна реалізація виглядає так:

Method this.href=" :
Method location.replace(""):
Methon location.assign("") :
Method window.location.assign("") :
Method window.location.replace("") :
Method window.location.href="" :

Наведений HTML-код робить динамічну заміну вказаної адреси ( www.google.com) на адресу сайту ][ () за допомогою різноманітних методів, заснованих на JavaScript-події onclick="".

2. URL Bar Spoofing – підміна посилання в адресному рядку браузера

На перший погляд це здається неможливим, але повір мені - це лише завдання для розвитку кмітливості. Розглянемо вразливість CVE-2011-1452, яка спуфіт адресний рядок у непереможному Google Chrome до версії 11.0.696.57:

Click Me

• відкривається нове вікно (spoofing.php) з присвоєнням змінної «a»;
• після закінчення 4500 мікросекунд (4,5 секунди) (функція window.setTimeout) провадиться повернення з історії переходів назад, за що відповідає функція a.history.back(), присвоєної змінною «а»;
• Через 5000 мікросекунд змінної "а" виставляється новий location до spoofing.php, що знаходиться в тій же директорії.

Таким чином відбувається перезапис адресного рядка на нову URL-адресу в контексті першої сторінки «батька».

Наступна вразливість CVE-2010-4045 (Opera<= 10.62):

Proof of Concept - OPERA High Location Bar Spoofing

При натисканні на кнопку, яка представлена ​​картинкою (), автоматично перезавантажується сторінка (location.reload()), при цьому можна перезаписати адресний рядок у контексті поточної вкладки.

Кілька платіж/банківський веб-сайт включали його.

1. start poc click the button to run the poc.Demo

"); myWindow.focus(); return false; }

Після натискання кнопки «Demo» одночасно змінної та об'єкту myWindow присвоюється значення функції, яка відкриває сайт apple.com з розмірами 200×100, що відповідає області розширення браузера Safari для мобільних пристроїв. Далі myWindow впроваджує додатковий HTML (JavaScript/VB/etc) код за допомогою функції document.write(). Заключним етапом є наведення фокусу Safari браузера на об'єкт myWindow.

Нічого складного в спуфінгу адреси в адресному рядку браузера немає, єдине - потрібно правильно застосовувати кмітливість там, де це потрібно;-).

3. Source Code Spoofing - підміна вмісту сторінки та вихідного коду

Експлуатація реалізується завдяки відомому нам керуючому UTF-8 символу 0x202E (RLO). Метод був виявлений студентом Virginia Tech Джоном Курлаком (John Kurlak). Для демонстрації техніки він використовував функцію JavaScript History.replaceState(), яка дозволяє динаміці змінити адресу сторінки в адресному рядку. Proof-of-Concept (source.html):

Can you view my source від Chrome?

Вміст файлу source.html[%20%2E] Ви можете, але не можна...

Суть цього методу полягає у заміні вмісту вихідного коду сторінки за допомогою трюка з керуючим символом RLO в кінці файлу (див. рис. 4). При спробі переглянути вихідний код сторінки source.html ми отримуємо вміст другого файлу source.html%20%2E. Досить цікавий та екзотичний метод спуфінгу, з дуже дивним профітом, як тобі може здатися на перший погляд. Що найцікавіше - цей сценарій дозволяє «заховати» вихідний код сторінки, маскуючи його не лише в контексті адреси, а й у контексті імені хоста.

4. IDN Clones - техніка, заснована на зовнішній схожості відображення доменних імен

Нічого інноваційного тут немає, техніка практикувалася із самого зародження системи DNS, але саме використання IDN (Internationalized Domain Names – інтернаціоналізовані доменні імена) дозволило реалізувати створення майже невідмінних «клонів» доменних імен. Технічна реалізація фішинг-атаки виглядає так:

1. Реєструється доменне ім'я, максимально подібне по написанню з доменом, що атакується. Зазвичай використовується схожість літер з цифрами деяких шрифтах (літера l і цифра 1, буква O і цифра 0), подібність поєднань букв (rn і m, cl і d).
2. Створюється фейк сайту-оригіналу, що міститься на створений «клон».
3. Поширюються посилання на фішинговий домен (спам пошти, спам у соцмережах, через популярні сервіси типу Twitter, використання iframe'ів, дорвіїв).
4. Виходить профіт:).

Основна відмінність даної атаки, заснованої на подібності доменних імен, в порівнянні з іншими видами фішингу з використанням підставних веб-сторінок - для неї не потрібне втручання у роботу мережевих протоколів: з технічної точки зору підставний домен є легітимним.

Методи захисту від IDN-атак почали впроваджуватися з середини 2005 року, коли реєстраторами доменних імен було ухвалено угоди, що обмежують можливість реєстрації будь-якого IDN-домену. Так, міжнародний домен.org обмежує кількість дозволених символів тим чи іншим підмножиною розширеної латиниці. Але завдяки деяким несумлінним реєстраторам та кмітливості навіть сьогодні є всі можливості для реєстрації фішингового домену.

Найбільш радикальним варіантом захисту проти омографічної загрози була б повна відмова від декодування IDN при відображенні. Тоді підставне ім'я завжди починалося б з xn і закінчувалося нечитаною послідовністю символів, що різко відрізняло б його від оригіналу. На жаль, цей варіант зводить нанівець практично всі переваги IDN.

Основний захист від IDN-спуфінгу на стороні клієнта – це статус бар браузера. При наведенні курсору на посилання в статусбарі відображається punycode-еквівалент IDN-домену, що відразу наводить на думку про можливий фішинг. Але і це не є панацеєю, проспуфіти можна все, якщо застосувати кмітливість;-). Дивись мій універсальний експлойт для всіх браузерних двигунів.

Висновок

Спуфінг був і буде затребуваний завжди, бо він є основою та гарантією для проведення успішних атак у багатьох напрямках. Сподіваюся, що ти зробив правильні висновки. Будь уважним на просторах Мережі.