Несколько лет назад мне удалось захватить поддомены на сайтах компании Microsoft и получить доступ к почте и файлам пользователей Outlook и OneDrive, а также к данным профилей на Xbox.com. Я расскажу о том, что конкретно для этого потребовалось, а заодно посмотрим, как такая атака может выглядеть сейчас, в 2020 году.
 

Захват через забытый CNAME

Современные компании используют большое количество облачных сервисов. Для простоты подключения используются поддомены основного домена организации, а контент обслуживается облачным сервисом напрямую. В таком случае администраторам компании достаточно добавить DNS-запись вида CNAME (canonical name или, проще говоря, алиас) со ссылкой на облачный сервис.

Например, настройка GitHub Pages для домена wiki.company.com может выглядеть следующим образом:

$ dig wiki.company.com +nostats +nocomments +nocmd
wiki.company.com 1728 IN CNAME company-wiki.github.io.
company-wiki.github.io. 3529 IN A 185.199.110.153

Но что будет, если репозиторий удалят вместе с настройкой привязки к домену wiki.company.com? Вполне вероятно, что DNS-запись при этом останется, — добавляет эти записи обычно админ, а следить, чтобы их оперативно удаляли, чаще всего некому. Тут играет человеческий фактор.

В таком случае злоумышленник может создать репозиторий и привязать его к wiki.company.com. Поскольку CNAME wiki.company.com уже указывает на company-wiki.github.io, с этого момента содержимое wiki.company.com будет контролировать злоумышленник.

Угнанный поддомен компании может использоваться для похищения сессионных кук, фишинговых атак, обхода CORS и CSP.

 

Захват доменов на внешних ссылках

Возможен также вариант захвата доменов, которые не принадлежат организации, но ссылки на которые используются для загрузки внешних скриптов. Представим, что страница приложения выглядит так:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>app.company.com Application</title>
  <link rel="stylesheet" href="css/application.css">
</head>
<body>
  <script src="https://subdomain.3rdparty.com/script.js"></script>
  ...
</body>
</html>

Если будет возможен захват поддомена subdomain.3rdparty.com по схеме CNAME, злоумышленник сможет контролировать содержимое и выполнить произвольный код в контексте app.company.com. А если домен 3rdparty.com истек и удален — злоумышленник может вновь зарегистрировать его и контролировать все его поддомены.

 

Угоняем сессии Outlook и OneDrive

Несколько лет назад мне удалось захватить множество поддоменов Microsoft, в том числе для Live.com. Это дало возможность беспрепятственно перехватывать сессии пользователей Outlook и OneDrive. Как это было? Сейчас расскажу.

При регистрации любого сервиса Azure (например, виртуального сервера или виртуального хостинга) указывается имя, по которому можно потом можно обращаться напрямую либо через CNAME. Например, веб-приложение будет доступно по адресу XYZ.azurewebsites.net, где XYZ — имя приложения.

Для различных сервисов Azure использует набор разных доменов, они также могут немного отличаться и иметь префикс региона размещения ресурса:

*.cloudapp.net
*.cloudapp.azure.com
*.azurewebsites.net
*.blob.core.windows.net
*.cloudapp.azure.com
*.azure-api.net
*.azurehdinsight.net
*.azureedge.net
*.azurecontainer.io
*.database.windows.net
*.azuredatalakestore.net
*.search.windows.net
*.azurecr.io
*.redis.cache.windows.net
*.azurehdinsight.net
*.servicebus.windows.net
*.visualstudio.com

В Microsoft этот механизм применяют и для своих приложений, в тех же пространствах имен, что и остальные пользователи. При анализе легко увидеть, что множество поддоменов Microsoft.com используют сервисы Azure и указывают на набор доменов, приведенный выше.

Что происходит после того, как сервис перестает использоваться Microsoft и удаляется? Мы можем зарегистрировать сервис Azure на нашей учетной записи, но с тем же именем. Таким образом, существующая запись CNAME будет указывать уже на созданный нами сервис, который мы можем полностью контролировать.

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

4 комментария

  1. Аватар

    Владиславище

    03.04.2020 at 17:34

    Не зависимо от размера компании, админы везде ленивые…

  2. Аватар

    karpulix

    04.04.2020 at 20:49

    Насколько знаю, HttpOnly куку вряд ли удастся стащить скриптом с угнанного домена. А сессионная кука обычно HttpOnly.

    • Аватар

      Александр Сидуков

      05.04.2020 at 20:54

      Но сессионная кука доступна серверу под нашим контролем. В примере из статьи она отображалась через var_dump($_COOKIE) на сервере.

Оставить мнение