Захват поддоменов: Основы

Отправная точка

Захват поддомена - это процесс регистрации несуществующего доменного имени для получения контроля над другим доменом. Наиболее распространенный сценарий этого процесса следующий:

1. Доменное имя (например, sub.example.com) использует запись CNAME в другом домене (например, sub.example.com CNAME anotherdomain.com).
2. В какой-то момент времени срок действия anotherdomain.com истекает, и он доступен для регистрации любым пользователем.
3. Поскольку CNAME запись не удаляется из DNS-зоны example.com, любой, кто зарегистрирует anotherdomain.com, будет имеет полный контроль над sub.example.com до тех пор, пока не появится DNS-запись.

Последствия захвата могут быть довольно значительными. Используя захват поддомена, злоумышленники могут отправлять ******овые сообщения с легитимного домена, выполнять межсайтовые скрипты (XSS) или наносить ущерб репутации бренда, который ассоциируется с доменом.

Приобретение поддомена не ограничивается CNAME записями. Также затрагиваются записи NS, MX и даже A (которые мы не будем затрагивать в этой статье). Этот пост касается в первую очередь CNAME записей. Но тем не менее, случаи использования NS и MX записей представлены там, где это необходимо.

Обычные домены

Делегирование DNS с использованием CNAME записи абсолютно невидимо для пользователя, т.е. происходит в фоновом режиме при DNS разрешении. На рисунке ниже показано поведение веб-браузера для доменного имени, в котором установлена CNAME запись.




Обратите внимание, что веб-браузер слепо доверяет всему, что возвращает DNS преобразователь. Такое доверие означает, что когда злоумышленник получает контроль над DNS записями, все измерения безопасности веб-браузера (например, same-origin policy, или правило ограничения домена) обходятся. Это представляет собой значительную угрозу безопасности, поскольку захват поддоменов нарушает аутентичность самого домена, которая может быть использована злоумышленником несколькими способами. Как показано ниже, TLS/SSL не исправляет эту проблему, поскольку захват поддомена не является обычной атакой в стиле man-in-the-middle.

Захват CNAME поддомена. Одним из основных типов захватов CNAME поддоменов является сценарий, когда каноническое доменное имя является обычным доменом в Интернете (а не доменом, принадлежащим провайдерам облачных серверов, как будет объяснено ниже). Процесс определения того, является ли какое-либо исходное доменное имя уязвимым для захвата CNAME поддоменов, довольно прост:

Учитывая пару исходных и канонических доменных имен, если базовый домен канонического доменного имени доступен для регистрации, то исходное доменное имя уязвимо к поглощению поддомена.




В этом процессе, «базовый домен канонического доменного имени» заслуживает особого внимания. Это связано с тем, что каноническое доменное имя может быть в виде домена более высокого уровня. Если базовый домен доступен для регистрации, то впоследствии доменные имена верхнего уровня можно легко воссоздать в зоне DNS.

Проверку доступности базовых доменных имен можно выполнить с помощью таких регистраторов доменов, как Namecheap. Можно подумать, что проверка статуса ответа DNS для NXDOMAIN является достаточным показателем того, что доменное имя доступно для регистрации. Однако обратите внимание, что это не так, поскольку бывают случаи, когда доменное имя отвечает NXDOMAIN, но не может быть зарегистрировано. Причинами этого являются домены верхнего уровня с ограниченным доступом (например, .GOV, .MIL) или, зарезервированные TLD регистраторами, доменные имена.

Захват NS поддомена. Понятие "захват поддомена" можно естественным образом использовать и с NS записями: Если базовый домен канонического доменного имени хотя бы одной NS записи доступен для регистрации, то исходное доменное имя уязвимо для захвата.

Одной из проблем, при захвате поддоменов с использованием NS-записи, является то, что исходное доменное имя обычно имеет несколько NS-записей. Несколько NS записей используются для избыточности и балансировки нагрузки. Сервер имен выбирается случайным образом перед DNS разрешением. Предположим, что домен sub.example.com имеет две NS записи: ns.vulnerable.com и ns.nonvulnerable.com. Если злоумышленник захватит ns.vulnerable.com, то ситуация с точки зрения пользователя, запрашивающего sub.example.com, выглядит следующим образом:

• Так как существует два сервера имен, один выбирается случайным образом. Это означает, что вероятность запроса сервера имён, контролируемого злоумышленником, составляет 50%.
• Если DNS преобразователь пользователя выбирает ns.nonvulnerable.com (легитимный сервер имён), то возвращается корректный результат и, скорее всего, кэшируется где-то между 6 и 24 часами.
• Если DNS преобразователь пользователя выбирает ns.vulnerable.com (сервер имен, принадлежащий злоумышленнику), злоумышленник может выдать ложный результат, который также будет кэшироваться. Поскольку злоумышленник контролирует сервер имён, он может установить TTL для конкретно этого результата, например, на одну неделю.

Захват MX поддоменов. По сравнению с NS и CNAME поддоменов, захват MX поддоменов имеет наименьшее влияние. Поскольку MX записи используются только для получения электронной почты, получение контроля над каноническим доменным именем в MX записи позволяет злоумышленнику получать электронную почту, адресованную исходному доменному имени. Несмотря на то, что воздействие не столь значительно, как в случае с CNAME или NS поддоменами, захват MX может сыграть роль в "******овых" атаках и краже интеллектуальной собственности.


Поставщики облачных услуг

Облачные сервисы набирают популярность в последние годы. Одной из основных предпосылок облака является разгрузка пользователей от создания их инфраструктуры. Организации переходят от локальной установки к таким альтернативам, как облачное хранение данных, облачные онлайн магазины, PaaS и т. д.

После того как пользователь создает новый облачный сервис, облачный провайдер в большинстве случаев генерирует уникальное доменное имя, которое используется для доступа к созданному ресурсу. Поскольку регистрация доменного имени через TLD регистраторы не очень удобна из-за большого количества клиентов облачных служб, провайдеры облачные серверов предпочитают использовать поддомены. Поддомен, идентифицирующий уникальный облачный ресурс, часто бывает в формате nameof-customer.cloudprovider.com, где cloudprovider.com является базовым доменом, принадлежащим конкретному провайдеру.

Если облачный сервис, зарегистрированный организацией, должен быть публичным (например, онлайн магазин), то конкретная организация может вставить название организации в их домен. Основной причиной этого является брендинг: shop.organization.com выглядит лучше, чем organization.ecommerceprovider.com. В этом случае у организации есть два варианта:

• HTTP 301/302 перенаправление - 301 и 302 - это коды ответа HTTP, которые запускают веб-браузер для перенаправления текущего URL на другой. В контексте облачных сервисов первый запрос делается на доменное имя организации (например, shop.organization.com), а затем перенаправляется на доменное имя облачного провайдера (например, organization.ecommerceprovider.com).
• CNAME запись - при использовании этого метода, перенаправление происходит при DNS разрешении. Организация устанавливает CNAME запись, и весь трафик автоматически делегируется облачному провайдеру. При использовании данного метода URL-адрес в браузере пользователя остается неизменным. Однако, стоит отметить, что конкретный облачный сервис должен поддерживать делегирование с использованием CNAME записей.

При использовании метода CNAME-записи, появляется возможность поддоменного поглощения. Даже несмотря на то, что провайдер облака владеет базовым доменом канонического доменного имени, захват поддоменов все равно возможен, о чем мы поговорим в следующих разделах.

Поставщики облачных услуг в последующих разделах были выбраны на основе трех основных причин:

• Распространенность - Исходя из статистики по CNAME записям, приоритет отдавался доменам облачных провайдеров с наибольшим использованием в CNAME записях.
• Поддержка CNAME записей - Как объяснялось выше, поставщик облачных услуг должен поддерживать делегирование CNAME. Облачные провайдеры понимают, что клиенты требует это, и наиболее популярные провайдеры его уже поддерживают.
• Проверка прав собственности на домен - Выбранные облачные провайдеры не проверяют права собственности на исходное доменное имя. Так как владелец не нуждается в проверке, любой может использовать конфигурацию облака с истекшим сроком действия для реализации поддоменного захвата.

Amazon CloudFront

Amazon CloudFront – это Content Delivery Network, или Сеть Доставки Контента (CDN) в веб-службах Amazon Web Services (AWS). CDN распространяет копии веб-контента на серверах, расположенных в различных географических точках (называемых точками присутствия). Когда пользователь делает запрос на CDN, ближайшая точка присутствия выбирается исходя из местоположения посетителей, чтобы снизить задержку. Организации используют CDN в основном для распространения мультимедийных файлов, таких как видео, аудио и изображения. К другим преимуществам CDN относятся защита от атак типа Denial of Service, уменьшение пропускной способности и балансировка нагрузки в случае больших скачков трафика.

CloudFront использует Amazon S3 в качестве основного источника веб-контента. Amazon S3 - это еще одна услуга, предлагаемая AWS. Это сервис облачного хранения (S3 - аббревиатура от Simple Storage Service), который позволяет пользователям загружать файлы в так называемые бакеты, что является названием для логических групп внутри S3.

CloudFront работает с понятием дистрибутивов. Каждый дистрибутив представляет собой ссылку на конкретный Amazon S3 бакет для обслуживания объектов (файлов). При создании нового CloudFront дистрибутива, генерируется уникальный поддомен для обеспечения доступа. Формат этого поддомена - SUBDOMAIN.cloudfront.net. Часть SUBDOMAIN производится CloudFront и не может быть указана пользователем.

В дополнение к случайно сгенерированному поддомену, в CloudFront можно указать альтернативное доменное имя для доступа к дистрибутиву. Это работает путем создания CNAME записи из альтернативного доменного имени в поддомен, генерируемого CloudFront. Хотя Amazon не предоставляет документацию о внутренних концепциях CloudFront, из его поведения можно понять об использовании архитектуры высокого уровня. В зависимости от географического расположения, DNS-запрос к любому поддомену cloudfront.net приводит к одной и той же записи A (в том же регионе). Это указывает на то, что CloudFront использует настройку виртуального хостинга в бэкэнде. После поступления HTTP-запроса, пограничный сервер CloudFront определяет правильное распределение на основе заголовка HTTP-хоста. Документация также поддерживает эту теорию в том виде, в каком она изложена: ,,Вы не можете добавить альтернативное доменное имя в CloudFront дистрибутив, если альтернативное доменное имя уже существует в другом CloudFront дистрибутиве, даже если ваш AWS аккаунт владеет другим дистрибутивом". Наличие нескольких альтернативных доменов, указывающих на один дистрибутив, определенно правильно, однако наличие одного и того же альтернативного доменного имени в нескольких дистрибутивах - ошибочно.




Поэтому для правильной работы с альтернативными доменными именами CloudFront, вы должны заранее знать, к какому распределению прикреплено альтернативное доменное имя. Другими словами, недостаточно настроить CNAME запись, альтернативное доменное имя должно быть явно задано в настройках дистрибутива.

Проблема с альтернативными доменными именами в CloudFront аналогична проблеме, описанной в разделе Обычные домены. Предположим, что sub.example.com имеет CNAME запись, установленную на d1231731281.cloudfront.net. Когда в каком-либо CloudFront дистрибутиве в качестве альтернативного доменного имени не зарегистрирован sub.example.com, возможно захватить поддомен. Любой человек может создать новый дистрибутив и установить sub.example.com в качестве альтернативного доменного имени в его настройках. Обратите внимание, что вновь созданный CloudFront поддомен не обязательно должен совпадать с доменом, указанным в CNAME записи (d1231731281.cloudfront.net). Поскольку CloudFront использует настройку виртуального хостинга, правильное распределение определяется с помощью заголовка HTTP-хоста, а не DNS-записи.

На рисунке ниже показано сообщение об ошибке, которое появляется после HTTP-запроса к альтернативному доменному имени, которое имеет DNS CNAME записи в CloudFront, но не зарегистрировано ни в одном из CloudFront дистрибутивов.



Это сообщение об ошибке является убедительным доказательством возможности захвата поддоменов. Тем не менее, эти два исключения необходимо учитывать:

• HTTP / HTTPS-only дистрибутивы - CloudFront позволяет указать, является ли дистрибутив HTTP-only или HTTPS-only. Переключение HTTP на HTTPS может дать правильные ответы для некоторых дистрибутивов.
• Отключенные дистрибутивы - Некоторые дистрибутивы могут быть отключены. Отключенный дистрибутив перестает предоставлять и обрабатывать контент, сохраняя при этом свои настройки. Это означает, что некоторое альтернативное доменное имя может выдавать сообщение об ошибке после HTTP-запроса. Однако, он даже зарегистрирован внутри отключенного дистрибутива и, таким образом, не подвергается захвату поддоменов. Правильным способом определения того, зарегистрирован ли альтернативный домен внутри некоторого дистрибутива, является создание нового дистрибутива и установка альтернативного доменного имени. Если процесс регистрации не приводит к ошибке, пользовательский домен подвержен риску захвата. На скриншоте ниже показана ошибка, которая появляется после того, как пользователь пытается зарегистрировать альтернативное доменное имя, которое уже присутствует в каком-либо другом CloudFront дистрибутиве.

Прочее

Как показано в примере CloudFront, захват поддоменов возможно даже на облачных сервисах, у которых нет доступного для регистрации базового домена. Однако, поскольку облачные сервисы предоставляют возможность указать альтернативные доменные имена (CNAME записи), возможность подбдоменного захвата все еще присутствует. В этом разделе дается краткий обзор других облачных сервисов, которые работают очень похожим образом на CloudFront (архитектура виртуального хостинга).

• Amazon S3 - Amazon S3 кратко упоминался ранее. Базовый домен по умолчанию, используемый для доступа к бакету, не всегда один и тот же и зависит от используемого региона AWS. Полный список базовых доменов Amazon S3 доступен в документации по AWS. Как и CloudFront, Amazon S3 позволяет указать альтернативное (пользовательское) доменное имя для доступа к содержимому бакета.
• Heroku - Heroku является провайдером PaaS услуг, который позволяет развернуть приложение, используя простую последовательность действий. Так как доступ к приложению необходим, Heroku предоставляет приложение, используя поддомен, сформированный на herokuapp.com, из-за необходимости доступа к приложению. Однако, можно также указать пользовательское доменное имя для доступа к развернутому приложению.
• Shopify - Shopify предоставляет способ создания и настройки онлайн магазинов в облаке. Поддомен по умолчанию для доступа к магазину построен на myshopify.com. Как и описанные выше сервисы, Shopify позволяет указывать альтернативные доменные имена. Примечательно, что Shopify проверяет правильность настройки CNAME записи. Однако эта проверка не является проверкой права собственности на домен. Shopify проверяет только правильно настроенную CNAME запись, которая присутствует в DNS зоне альтернативного домена. Таким образом, данная проверка не препятствует захвату поддоменов.
• GitHub - GitHub - репозиторий с контролем версий для Git'а. GitHub также предоставляет возможность бесплатного веб-хостинга с помощью своего проекта GitHub Pages. Этот веб-хостинг обычно используется для проектной документации, технических блогов или поддержки веб-страниц проектов с открытым исходным кодом. GitHub Pages поддерживает пользовательское доменное имя в дополнение к доменному имени по умолчанию под github.io.
• Microsoft Azure - Microsoft Azure более известен, и похож на AWS. Он отличается от упомянутых выше облачных сервисов тем, что не предоставляет архитектуры виртуального хостинга. Проще говоря, для каждой облачной службы Azure создает собственную виртуальную машину с собственным IP-адресом. Поэтому сопоставление между доменным именем и IP-адресом является однозначным. Примечательно то, что поскольку это не является обычной настройкой виртуального хостинга, настройка CNAME записи не обязательно должна быть явно определена в настройках ресурса. Azure предоставляет множество облачных сервисов, но те, которые обсуждаются в этом тезисе, имеют домены по умолчанию cloudapp.net и azurewebsites.net. В документации описывается установка связи между доменным именем и ресурсом Azure с помощью A или CNAME записей (указывающих на один из двух вышеупомянутых доменов). Интересное наблюдение заключается в том, что для A записей компания Azure проводит проверку владения доменом с использованием TXT записей. Однако этого не наблюдается для CNAME записей, и поэтому захват поддомена возможно даже в случае с Microsoft Azure.

Сканирование глобальной сети

Проект Sonar можно использовать для демонстрации распространенности захвата поддоменов в Интернете. Так как проект уже содержит разрешенные CNAME записи, довольно просто автоматизировать сканирование на предмет захвата поддоменов в Интернете. В этом разделе я объясню его результаты.

Цепочка CNAME записей. В некоторых случаях CNAME записи могут образовывать цепочки CNAME записей. Давайте рассмотрим домен sub.example.com, который имеет CNAME запись на sub.example1.com. Если, в свою очередь, sub.example1.com имеет CNAME запись на sub.example2.com, то формируется следующая цепочка:

sub.example.com -> sub.example1.com -> sub.example2.com


В таких случаях, когда базовый домен последнего домена в цепочке (example2.com) доступен для регистрации, затрагиваются sub.example1.com и sub.example.com. К счастью, проект Sonar косвенно содержит все ссылки CNAME в цепочке. Для вышеприведённой цепочки, даже если нет прямой CNAME записи с sub.example.com на sub.example2.com, проект Sonar содержит эту запись. Поэтому нет необходимости вносить прямые изменения в инструмент автоматизации для поддержки цепочек CNAME записей в проект.

Сканирование было выполнено с использованием пользовательского инструмента автоматизации, который я пока не планирую выпускать. Утилита смогла сканировать домены облачных провайдеров и обнаружила 12 888 исходных доменных имен, уязвимых к захвату поддоменов (ноябрь 2017 г.). Далее следует распределение провайдеров "облака":

Статья взята с другого форума.​