От same-site до главного site
Last updated
Last updated
В предыдущем посте о сценариях атак на Grafana упоминалось, что злоумышленники должны сначала получить контроль над сайтом того же происхождения, чтобы выполнить последующие атаки. В этом посте давайте рассмотрим другую перспективу: "Если у вас есть контроль над сайтом того же происхождения, какие атаки вы можете выполнить?" Например, CSRF — это возможный метод атаки.
Существуют основные и неосновные веб-сайты. Например, уязвимости, найденные на сервере API api.example.com, стоят больше, чем уязвимости, найденные на странице одноразового события 2023.campaign.example.com, потому что первые могут вызвать больший ущерб.
Поэтому, когда багхантер обнаруживает уязвимость на 2023.campaign.example.com, он может попытаться дополнительно исследовать, есть ли способ расширить область этой уязвимости, например, затронуть api.example.com, чтобы заработать больше вознаграждений.
Помимо поиска XSS на сайтах того же происхождения, есть еще один способ контролировать поддомены.
Как следует из названия, эта уязвимость позволяет злоумышленникам захватить целый поддомен и получить контроль над ним.
Звучит сложно, не так ли? Нужно ли получить контроль над их DNS или проникнуть в внутренние системы компании, чтобы захватить поддомен? На самом деле, это не всегда необходимо. В эпоху различных облачных сервисов есть более простой способ попробовать.
Amazon S3 — это облачный сервис хранения, где вы можете загружать файлы и устанавливать разрешения для их совместного использования. Многие люди используют Amazon S3 для хранения изображений или даже для хостинга целых веб-сайтов, потому что он предоставляет функциональность хостинга веб-сайтов. Каждое хранилище в S3 называется "бакет" и имеет имя, которое также соответствует поддомену, предоставляемому S3.
Например, если мой бакет называется xsstest, поддомен будет: https://xsstest.s3.us-east-1.amazonaws.com. Поскольку S3 удобен и прост в использовании, это хороший выбор для хостинга статических веб-сайтов. Например, если архитектура компании полностью разделяет фронтенд и бэкенд и не требует серверного рендеринга, чисто статический веб-сайт можно разместить на S3, что устраняет необходимость управления инфраструктурой фронтенда.
Единственная проблема в том, что домен https://xsstest.s3.us-east-1.amazonaws.com выглядит не очень привлекательно. Компании обычно имеют свои собственные доменные имена, и S3 предоставляет функциональность для настройки домена, что также довольно просто.
Сначала измените имя бакета на желаемый домен, например, campaign.xss.test.
Затем добавьте запись CNAME в DNS, указывающую campaign.xss.test на xsstest.s3.us-east-1.amazonaws.com. Таким образом, вы можете использовать https://campaign.xss.test как свой собственный домен.
Весь процесс кажется нормальным и удобным, но что делать, когда вам больше не нужна эта веб-страница? Например, может быть страница рождественского события, размещенная на S3 с использованием пользовательского домена xmas.xss.test. После Рождества и окончания события бакет S3 удаляется, так как пространство для хранения и трафик все еще несут затраты.
Однако часть DNS может обрабатываться другим отделом, и если их не уведомить о необходимости удалить запись, она может остаться.
В результате возникает ситуация, когда запись DNS все еще существует, но назначение, на которое она указывает, было удалено.
В случае S3, пока имя бакета не занято кем-то другим, вы можете заявить это имя. Теперь, когда бакет xmas.xss.test был удален, я могу создать новый с тем же именем, xmas.xss.test. Таким образом, домен xmas.xss.test будет указывать на бакет S3, и поскольку бакет S3 содержит мой контент, я фактически контролирую содержимое xmas.xss.test, достигая захвата поддомена.
Помимо S3, существует множество других сервисов, которые предоставляют аналогичную функциональность и имеют эту проблему. Вы можете ознакомиться с подробным списком здесь: . Azure также создала страницу, специально объясняющую, как защититься от этого: . Проще говоря, просто удалите запись DNS, и проблем не будет.
Давайте рассмотрим несколько примеров!
Hacktus обнаружил, что один из поддоменов, test.example.com, указывает на azurewebsites.net и не был зарегистрирован никем. Поэтому Hacktus зарегистрировал сервис и успешно захватил домен. После захвата, когда пользователь посещает test.example.com, браузер отправляет куки, хранящиеся на example.com, на сервер, позволяя Hacktus получить куки пользователя.
NPM означает Node Package Manager, сервис, используемый для управления пакетами JavaScript. Если злоумышленник получает контроль над assets.npmjs.com, он может загружать вредоносные пакеты и обманывать разработчиков, заставляя их думать, что они безопасны. Поскольку разработчики знакомы с этим доменом и он выглядит очень надежным, вероятность успешного фишинга также высока.
Злоумышленник может создать свой собственный блог на Medium и запросить ссылку на platform.medium.engineering. Хотя в этом случае они не могут полностью контролировать содержимое веб-страницы, они все равно могут проводить атаки социальной инженерии, такие как размещение поддельных объявлений о работе, которые выглядят очень правдоподобно.
Помимо методов применения, упомянутых в этих практических примерах, на самом деле существует еще больше возможностей.
Многие сервера делают неверные предположения о безопасности и предоставляют чрезмерные разрешения сущностям, которые не должны их иметь.
Например, давайте рассмотрим случай динамического Origin в CORS. Некоторые серверы реализуют следующую проверку:
Если происхождение — example.com или заканчивается на .example.com, проверка проходит. Хотя это может не казаться большой проблемой, безопасность этой проверки основана на предположении, что "злоумышленники не могут контролировать поддомены example.com".
Однако, я думаю, что теперь все знают, что получить контроль над поддоменом может быть не так сложно, как предполагалось, и риск все еще существует. Если злоумышленник может контролировать поддомен, он может использовать это неверное предположение для запуска атак с поддомена.
Таким образом, эта, казалось бы, безопасная проверка на самом деле недостаточно безопасна. Наиболее безопасная проверка должна выглядеть так:
Подготовьте список, и только происхождения из списка могут пройти проверку. Хотя это может быть более громоздким, поскольку каждый новый домен нужно добавлять вручную, это также увеличивает безопасность, не доверяя слепо любому поддомену.
Еще одно, что вы можете сделать после получения контроля над поддоменом, называется Cookie Tossing.
Предположим, есть веб-сайт с API-сервером на api.example.com, и аутентификационный куки хранятся под этим доменом. Кроме того, на бэкенде реализована защита от CSRF, добавлен атрибут SameSite=Lax и проверяется токен CSRF, чтобы убедиться, что csrf_token в теле запроса совпадает с тем, что в куки.
Теперь предположим, что у нас есть контроль над поддоменом s3.example.com и мы можем выполнять XSS-атаки на нем. Что нам делать дальше?
При записи куки мы можем записывать их в домены более высокого уровня. Например, a.b.example.com может записывать куки в:
a.b.example.com
b.example.com
example.com
Таким образом, когда мы находимся на s3.example.com, мы можем записать куки в example.com, что позволяет нам записать куки с именем csrf_token.
В сценарии, где и api.example.com, и example.com имеют куки с одинаковым именем, что будет делать браузер? Он отправит обе куки вместе, и в зависимости от атрибута пути куки более специфичный будет отправлен первым.
Например, если куки на api.example.com не имеют установленного пути, а куки на example.com имеют установленный path=/users, когда браузер отправляет запрос на https://api.example.com/users, отправленные куки будут: csrf_token={value_of_example_com}&csrf_token={value_of_api_example_com}.
Обычно, при получении значений куки на бэкенде, по умолчанию берется только первое. Поэтому мы получим куки, которые мы записали на s3.example.com.
Таким образом, злоумышленник может перезаписать куки из других доменов того же происхождения, как будто он "бросает" куки с одного поддомена на другой. Это называется Cookie Tossing.
Перезаписывая куки csrf_token, мы фактически знаем его значение и можем выполнить атаку CSRF. Поэтому в этой ситуации, даже с настройками куки того же происхождения и проверками токена CSRF, мы не можем избежать судьбы быть атакованными.
Эта статья продолжает тему сайтов того же происхождения, упомянутую раннее. При проектировании систем мы должны придерживаться принципа наименьших привилегий и избегать ненужных предположений о безопасности. Вместо того чтобы доверять всем доменам того же происхождения, более безопасным подходом будет доверять фиксированному списку доменов и убедиться, что каждый доверенный домен включен в этот список.
Кроме того, из этой статьи видно, что сайт того же происхождения по своей природе имеет больше привилегий (например, игнорирование куки того же происхождения). Поэтому многие компании на самом деле размещают менее доверенные файлы (например, файлы, загруженные пользователями) или менее важные веб-сайты на совершенно новом домене.
Например, основной сайт может находиться по адресу www.example.com, в то время как страница кампании называется campaign.example.app. Таким образом, даже если страница кампании будет скомпрометирована, ущерб можно минимизировать, и это не повлияет на основной сайт.
Первый пример — это статья, опубликованная Hacktus в 2023 году: . В ней упоминается, что на сайте example.com куки записываются непосредственно на корневом домене example.com, что делает их доступными для других поддоменов.
Второй случай — это статья, опубликованная кибербезопасной компанией Shockwave:. Упомянутый в статье случай похож на проблему с бакетом S3, о которой мы говорили ранее, но на этот раз захваченный домен — assets.npmjs.com.
Третий случай касается уязвимости, обнаруженной Смараном Чандом в конце 2022 года: . Один из поддоменов платформы для блогов Medium, platform.medium.engineering, указывает на Medium, но не существует как блог.
Решение состоит в том, чтобы изменить имя куки токена CSRF с csrf_token на __Host-csrf_token. С этим префиксом куки не могут иметь атрибуты пути и домена при его установке. Поэтому другие поддомены не могут записывать и перезаписывать его. Для получения дополнительных примеров вы можете обратиться к странице .
Для конкретных примеров и других приложений вы можете ознакомиться с докладом @filedescriptor на HITCON CMT в 2019 году: , или просмотреть .