Неправильне керування інфраструктурою DNS може наражати вас на ризик руйнівних кібератак – особливо в міру розширення зони атак на хмарні сервіси. Читайте статтю, щоб дізнатися про вразливості DNS, вплив атак із захопленням DNS і найкращі методи забезпечення безпеки DNS, у тому числі про те, як нові плагіни Tenable можуть вам допомогти.
Багато організацій не приділяють належної уваги безпеці своєї інфраструктури системи доменних імен (DNS), що є серйозною помилкою, особливо у випадку зростання впровадження хмарних технологій. Неправильне керування записами DNS може дозволити зловмисникам захопити будь-який з ваших піддоменів, які неактивні та забуті. Отримавши контроль над одним із піддоменів, хакери можуть організувати безліч руйнівних кібератак.
У цьому блозі детально розглядається, як працює протокол DNS, поширені вразливості DNS та їх наслідки, а також передові методи виявлення, запобігання та усунення наслідків. Також ви дізнаєтесь, як нещодавно випущені плагіни Tenable Vulnerability Management, Tenable Web App Scanning і Tenable Attack Surface Management можуть допомогти захистити інфраструктуру DNS.
Чому зростання хмарних технологій підвищує важливість безпеки DNS
Організації все частіше хочуть інтегрувати нові хмарні сервіси та SaaS-додатки до своєї ІТ-інфраструктури, щоб надавати їх своїм користувачам та клієнтам. В рамках цього процесу організації часто створюють користувацькі піддомени для своїх користувачів або клієнтів, щоб отримати доступ до цих сторонніх хмарних програм.
Для цього організаціям необхідно створити новий DNS-запис. Для організацій дуже важливо відстежувати ці DNS-записи, щоб зловмисники не змогли захопити користувацькі піддомени. На жаль, управлінню інфраструктурою DNS часто не приділяється належної уваги, що створює мертву зону для служби безпеки організації.
Основи дозволу DNS
Протокол DNS, історично важливий компонент інтернет-інфраструктури, переводить цифрові IP-адреси в імена, що легко читаються.
Протокол DNS надає різні типи записів, включаючи ці чотири:
- Записи “A”, які є базовим перекладом між піддоменом і IPv4-адресою.
- Записи канонічних імен (CNAME), які дозволяють організаціям мати більше одного доменного псевдоніма, що вказує на одне доменне ім’я, пов’язане з однією IP-адресою. Наприклад, п’ять доменних псевдонімів можуть вказувати на example.com. Якщо IP-адреса, прив’язана до example.com, коли-небудь зміниться, його DNS-запис буде єдиним, який потрібно буде оновити. Псевдоніми CNAME, які вказують на example.com, можуть залишатися без змін. Записи CNAME ніколи не вказують безпосередньо на IP-адресу лише на інші доменні імена. Цільове доменне ім’я може перебувати як у тому самому доменному імені псевдонімів, так і в іншому.
- Записи Mail Exchange (MX), які надсилають поштовий трафік, вказуючи, які поштові сервери відповідають за отримання вхідних повідомлень електронної пошти для домену.
- Записи сервера імен (NS), які визначають, які DNS-сервери є авторитетними для цієї зони DNS. Авторитетний DNS-сервер містить зону DNS із усіма записами.
Щоб зіставити сторонню службу з доменом користувача, сторонній постачальник зробить запит налаштування одного з цих чотирьох типів записів. Після завершення процесу трафік організації правильно маршрутизуватиметься через домен користувача.
На наступній схемі показаний базовий приклад того, як працює механізм дозволу DNS для запису CNAME, який ще не знаходиться в жодному кеші ланцюжка дозволу DNS:
Схема, яка показує, як працює механізм дозволу DNS для запису CNAME, який ще не знаходиться в жодному кеші ланцюжка дозволу DNS
Загальний процес аналогічний іншим типам записів, таких як записи MX або NS.
Розуміння вразливостей захоплення DNS
Ризик захоплення DNS виникає, коли запис DNS залишається неактивним, тобто запис DNS вказує на піддомен, який неактивний або видалено. Це дозволить будь-якій людині заявити права на цей запис DNS із стороннього хмарного сервісу.
Звичайний сценарій в основі таких вразливостей:
- Підрозділ організації встановлює сторонній хмарний сервіс для своїх внутрішніх користувачів.
- Потім цей підрозділ просить ІТ-відділ створити запис DNS CNAME для цієї служби, щоб вона виглядала легітимнішою по відношенню до домену, що належить «організації».
- Пізніше підрозділ вирішує припинити використання цієї сторонньої хмарної служби, але не просить ІТ-відділ видалити запис DNS CNAME із зони DNS.
- Будь-який користувач, включаючи зловмисника, може отримати від постачальника хмарних послуг піддомен користувача і налаштувати його для розміщення шкідливого вмісту в домені організації-жертви.
Як приклад візьмемо організацію, яка хоче розмістити базовий статичний веб-сайт на контейнері зберігання AWS S3 для заходу, наприклад дводенної конференції, і зіставимо піддомен, що належить їй, наприклад mysuperstaticwebsite.acme.corp. Дотримуючись офіційної документації AWS, сервіс надається та доступний всім передбачуваним користувачам.
Після завершення події організація переводить веб-сайт, розміщений на S3, в автономний режим, але забуває видалити DNS-запис піддомену користувача.
Тепер веб-сайт відображає загальну помилку, яка показує, що контейнер S3 не існує:
Однак зловмисник, який переглядає DNS-запис для mysuperstaticwebsite.acme.corp, побачить таку конфігурацію:
Цей ризикований сценарій не обмежується записами CNAME. Записи MX, NS або A також вразливі. Наприклад, близько 5 років помилка DNS Mastercard залишалася непоміченою лише через проблему з типографікою в одному із записів NS, встановлених на його az.mastercard.com. Запис, що використовує akam.me, дійсно був націлений на неіснуючий домен, доступний для реєстрації.
DNS-захоплення також можуть відбуватися, коли доменне ім’я закінчується та не продовжується у відведений час організацією, якій воно належало. Доменне ім’я потім може бути куплено будь-ким, включаючи хакерів, залишаючи попереднього власника відкритим для безлічі сценаріїв атак.
Одне захоплення, безліч наслідків
Організації часто не знають про потенційні наслідки атаки із захопленням DNS, крім шкоди для репутації бренду та довіри клієнтів.
Залежно від типу скомпрометованого DNS-запису та використання цього запису організацією, на безпеку організації може вплинути безліч векторів експлуатації, включаючи:
- Фішинг: Зловмисники можуть створювати реалістичні фішингові веб-сайти, розміщені на законному доменні URL, щоб атакувати внутрішніх або зовнішніх користувачів організації.
Перехоплення електронної пошти: Записи MX є найважливішою частиною інфраструктури електронної пошти. Коли один або кілька записів MX залишаються невикористаними, а записи цільових DNS стають недоступними, зловмисник може захопити записи DNS та отримувати електронні листи, призначені для попередніх користувачів цієї служби. Це може мати величезні наслідки. Це може дозволити зловмисникам, наприклад, виконувати операції зі скидання пароля та входити до активних служб з організації. - Підкидання файлів cookie: Взяття під контроль піддомену може дозволити зловмиснику встановлювати файли cookie для батьківських доменів та застосовувати їх до інших піддоменів. Залежно від того, як файли cookie обробляються в інших програмах, це може допомогти зловмисникові проводити подальші атаки.
- Обхід безпеки на стороні клієнта:
– Політика безпеки контенту (CSP) дає змогу адміністраторам веб-сайтів контролювати, які ресурси може завантажувати браузер. Якщо скомпрометований піддомен знаходиться в списку дозволених CSP, зловмисник може скористатися цією вразливістю, щоб обійти засоби безпеки CSP і запустити атаки на стороні клієнта, наприклад, міжсайтовий скриптинг (XSS).
– Політика Cross-Origin Resource Sharing (CORS) визначає вразливий піддомен у дозволених джерелах. Джерело – це комбінація схеми URI, імені хоста та номера порту, а додавання його до політики CORS визначає джерела, яким дозволено виконувати міжсайтові запити в даному веб-додатку. Зловмисник може розмістити шкідливий JavaScript та використовувати конфігурацію CORS для доступу до конфіденційної інформації або виконання операцій від імені законних користувачів. - Компрометація хмарних ресурсів: Коли скомпрометованою метою є, наприклад, хмарний ресурс, такий як сховище або база даних, це може мати ширший вплив на іншу інфраструктуру. Наприклад, якщо веб-додаток все ще посилається на статичні файли JavaScript у захопленому сховищі, зловмисник може завантажити шкідливий контент JavaScript та провести збережені атаки XSS на інші внутрішні або зовнішні веб-програми.
Ризики ще вищі, коли вразливий запис – це запис NS. Цей тип запису дозволяє адміністраторам делегувати все керування зоною DNS сторонньому серверу. Якщо його скомпрометовано, зловмисники можуть створити кілька інших записів у делегованій зоні.
Як виявити, запобігти та зменшити наслідки
Усунення вразливостей, пов’язаних із захопленням DNS, не є складним завданням, і в основному вимагає дотримання передових методів керування життєвим циклом записів DNS.
Для початку необхідно мати добре налагоджений та документований процес залучення зовнішніх служб, щоб уникнути подібних помилок:
- Запис DNS створено, але ви ще не розгорнули сторонній хмарний сервіс.
- Запис DNS створено, і ви підписалися на сторонній хмарний сервіс, але ви не завершили налаштування користувача DNS.
- Сторонній хмарний сервіс завершено, але запис DNS не видалено із зони DNS вашої організації.
Натомість ви повинні переконатися, що запис DNS створюється лише після створення та налаштування стороннього хмарного сервісу. Після того, як сторонній хмарний сервіс більше не потрібен, запис DNS має бути видалено до того, як буде видалено конфігурацію зовнішнього сервісу.
Якщо ви розробляєте SaaS-додаток як постачальник послуг, вам слід попросити клієнтів підтвердити право власності на своє доменне ім’я, перш ніж призначати йому запис DNS і маршрутизувати його у вашу інфраструктуру. Звичайний захист безпеки вимагає, щоб організації додавали записи TXT DNS в зону піддомену DNS, щоб підтвердити, що вони володіють піддоменом. Також можна згенерувати випадковий та унікальний запис CNAME для використання кожним клієнтом, не дозволяючи зловмиснику повторно використовувати попередній запис CNAME та перехоплювати піддомен.
Коли зловмисники аналізують поверхню атаки організації, вони перераховують DNS-записи, що належать до цієї організації, і перевіряють, чи існують будь-які висячі записи (dangling records). Для цього вони шукатимуть три різні проблеми:
- Висячі сервіси, що надають HTTP-відповідь. Вони матимуть дійсний і дозволений запис DNS, але також надаватимуть HTTP-відповідь за замовчуванням, яку можна використовувати для ідентифікації вразливих сервісів.
- Висячі сервіси з помилкою дозволу DNS, які в більшості випадків містять записи CNAME, націлені на записи DNS, які не можуть бути дозволені, і змушує перетворювач DNS повертати помилку NXDOMAIN.
- Висячі послуги, націлені на невиділену IP-адресу.Зловмисники можуть претендувати, наприклад, на еластичні IP-адреси у публічних хмарних інфраструктурах.
Функції управління поверхнею атак і сканування веб-застосунків Tenable Vulnerability Management дозволяють вам всебічно оцінювати та усувати проблеми безпеки DNS. Використовуючи плагіни 114146 (захоплення піддомена) та 114572 (небезпечний запис DNS) на додаток до можливостей керування поверхнею атак, користувачі сканування веб-додатків можуть швидко перевірити, чи націлений їхній піддомен на висячі записи на основі HTTP, і спробувати виправити ці проблеми до того, як ними скористається зловмисник.
Висновок
Керування поверхнею атак організації вимагає надійного керування інфраструктурою DNS. Хоча записи DNS можуть здатися реліктами раннього впровадження хмари, складність сучасних архітектур і швидка еволюція хмарних сервісів, що зростають, роблять управління інфраструктурою DNS більш актуальним, ніж будь-коли.
Коли зловмисники використовують вразливості DNS, вони можуть побудувати ланцюжок атак, який може скомпрометувати сеанси користувачів, викрасти конфіденційні дані або видати себе за застарілі сервіси. Ось чому організації повинні використовувати проактивний підхід та впровадити надійний процес надання та управління DNS.
Джерело: How To Reduce DNS Infrastructure Risk To Secure Your Cloud Attack Surface
