Неправильное управление инфраструктурой 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
