Хабрахабр

Аудит безопасности облачной платформы MCS


SkyShip Dusk by SeerLight

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

В качестве «внешних сил» MCS выбрали компанию Digital Security, известную своей высокой экспертизой в кругах ИБ. Статья — про этот самый незамыленный взгляд внешних экспертов, которые помогли команде Mail.ru Cloud Solutions (MCS) протестировать облачный сервис, и про то, что они нашли. И в данной статье мы разберем некоторые интересные уязвимости, найденные в рамках внешнего аудита — чтобы вас минули такие же грабли, когда вы будете делать свой облачный сервис.

Описание продукта

Mail.ru Cloud Solutions (MCS) — это платформа для построения виртуальной инфраструктуры в облаке. Она включает IaaS-ы, PaaS-ы, маркетплейс готовых образов приложений для разработчиков. С учётом архитектуры MCS нужно было проверить безопасность продукта по следующим направлениям:

  • защита инфраструктуры среды виртуализации: гипервизоры, маршрутизация, файерволы;
  • защита виртуальной инфраструктуры заказчиков: изоляция друг от друга, включая сетевую, приватные сети в SDN;
  • OpenStack и его открытые компоненты;
  • S3 собственной разработки;
  • IAM: мультитенантные проекты с ролевой моделью;
  • Vision (машинное зрение): API и уязвимости при работе с изображениями;
  • веб-интерфейс и классические веб-атаки;
  • уязвимости PaaS-компонентов;
  • API всех компонентов.

Пожалуй, из существенного для дальнейшей истории — всё.

Что за работы проводились и зачем они нужны?

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

В контексте аудита облачной платформы MCS были обозначены следующие цели: В ходе работ, которые длятся в среднем 1-2 месяца, аудиторы повторяют действия потенциальных злоумышленников и ищут уязвимости в клиентской и серверной части выбранного сервиса.

  1. Анализ аутентификации в сервисе. Уязвимости в данном компоненте помогли бы сразу попасть в чужие аккаунты.
  2. Изучение ролевой модели и разграничения доступа между разными аккаунтами. Для злоумышленника возможность получить доступ к чужой виртуальной машине – желанная цель.
  3. Уязвимости клиентской части. XSS/CSRF/CRLF/etc. Может, существует возможность атаковать других пользователей через вредоносные ссылки?
  4. Уязвимости серверной части: RCE и всевозможные инъекции (SQL/XXE/SSRF и так далее). Серверные уязвимости, как правило, сложнее найти, но они приводят к компрометации сразу множества пользователей.
  5. Анализ изоляции пользовательских сегментов на уровне сети. Для злоумышленника отсутствие изоляции значительно увеличивает поверхность атаки на других пользователей.
  6. Анализ бизнес-логики. Можно ли обмануть бизнес и создавать виртуальные машины бесплатно?

В данном проекте работы проводились по модели «Gray-box»: аудиторы взаимодействовали с сервисом с привилегиями обычных пользователей, но частично обладали исходными текстами API и имели возможность уточнять детали у разработчиков. Обычно это самая удобная, и при этом достаточно реалистичная модель работы: внутренняя информация все равно может быть собрана злоумышленником, это только вопрос времени.

Найденные уязвимости

Прежде чем аудитор начинает отправлять различные payload’ы (полезную нагрузку, с помощью которой проводится атака) в случайные места, необходимо разобраться, как что работает, какой функционал представлен. Может показаться, что это бесполезное занятие, ведь в большинстве изученных мест никаких уязвимостей не окажется. Но только понимание структуры приложения и логики его работы даст возможность отыскать самые сложные векторы атак.

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

IDOR

IDOR-уязвимости (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — один из самых частых вариантов уязвимостей в бизнес-логике, который позволяет тем или иным способом получить доступ к объектам, к которым в действительности доступ не разрешён. IDOR-уязвимости создают возможность получения сведений о пользователе разной степени критичности.

Это приводит к самым непредсказуемым последствиям. Один из вариантов IDOR — выполнение действий с объектами системы (пользователями, банковскими счетами, товарами в корзине) за счёт манипуляций с идентификаторами доступа к этим объектам. Например, к возможности подмены аккаунта отправителя денежных средств, за счёт которой можно красть их у других пользователей.

В личном кабинете пользователя для доступа к любым объектам использовались идентификаторы UUID, которые казались, как говорят безопасники, внушающе небрутабельными (то есть защищёнными от атаки перебора). В случае MCS аудиторы как раз обнаружили IDOR-уязвимость, связанную с несекьюрными идентификаторами. Думаю, вы догадываетесь, что можно было изменить ID пользователя на единицу, отправить запрос заново и получить таким образом информацию в обход ACL (access control list, правил доступа к данным для процессов и пользователей). Но для определённых сущностей было обнаружено, что для получения информации о пользователях приложения используются обычные предсказуемые номера.

Server Side Request Forgery (SSRF)

OpenSource-продукты хороши тем, что по ним есть огромное количество форумов с подробным техническим описанием возникающих проблем и, если вам повезло, с описанием решения. Но у этой медали есть обратная сторона: так же подробно расписаны и известные уязвимости. Например, на форуме OpenStack есть замечательные описания уязвимостей [XSS] и [SSRF], которые почему-то никто не спешит исправлять.

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

Злоумышленник может получить: SSRF-уязвимости могут сильно продвинуть развитие атаки вперёд.

  • ограниченный доступ к атакованной локальной сети, например только по определённым сегментам сети и по определённому протоколу;
  • полный доступ локальной сети, если возможен даунгрейд с уровня приложений до транспортного уровня и, как следствие, полное управление нагрузкой на уровне приложений;
  • доступ к чтению локальных файлов на сервере (если поддерживается схема file:///);
  • и многое другое.

В OpenStack давно известна SSRF-уязвимость, носящая «слепой» характер: при обращении к серверу ты не получаешь от него ответ, но зато получаешь разные типы ошибок/задержек, в зависимости от результата запроса. На основании этого можно выполнить сканирование портов на хостах во внутренней сети, со всеми вытекающими последствиями, которые не стоит недооценивать. К примеру, у продукта может присутствовать API для бэк-офиса, доступный только из корпоративной сети. Обладая документацией (не забываем об инсайдерах), злоумышленник может с помощью SSRF обратиться к внутренним методам. К примеру, если удалось каким-то образом получить приблизительный список полезных URL, то с помощью SSRF можно по ним пройти и выполнить запрос — условно говоря, перевести деньги со счета на счет или поменять лимиты.

В прошлом существовала возможность загружать ISO-образы ВМ по прямой ссылке, что тоже приводило к похожим последствиям. Это не первый случай обнаружения SSRF-уязвимости в OpenStack. Видимо, сообщество посчитало это самым простым и надежным решением проблемы. На данный момент эта функция удалена из OpenStack.

А в этом публично доступном отчете с сервиса HackerOne (h1) эксплуатация уже не слепой SSRF с возможностью чтения метаданных инстанса приводит к получению Root-доступа ко всей инфраструктуре Shopify.

Так или иначе, команда MCS всё равно пофиксила эту проблему, не дожидаясь сообщества. В MCS в двух местах с похожей функциональностью обнаружились SSRF-уязвимости, но их практически невозможно было эксплуатировать из-за файерволов и других защит.

XSS вместо загрузки «шеллов»

Несмотря на сотни написанных исследований, из года в год XSS (атака межсайтового скриптинга) все еще самая часто встречаемая веб-уязвимость (или атака?).

Часто оказывается можно загрузить произвольный скрипт (asp/jsp/php) и выполнить команды ОС, в терминологии пентестеров — «загрузить шелл». Загрузка файлов — любимое место для любого исследователя безопасности. Но популярность таких уязвимостей работает в обе стороны: про них помнят и разрабатывают средства против них, так что в последнее время вероятность «загрузить шелл» стремится к нулю.

ОК, в MCS на стороне сервера проверялось содержимое загружаемых файлов, разрешены были лишь изображения. Атакующей команде (в лице Digital Security) повезло. А чем могут быть опасны SVG картинки? Но SVG — это тоже картинка. Тем, что в них можно встраивать фрагменты JavaScript!

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


Пример внедрения с помощью XSS-атаки фишинговой формы логина

Примеры эксплуатации XSS-атаки:

  • Зачем пытаться украсть сессию (тем более, что сейчас везде HTTP-Only cookies, защищённые от краж с помощью js-скриптов), если загруженный скрипт может сразу обращаться к API ресурса? В этом случае полезная нагрузка может через XHR-запросы поменять конфигурацию сервера, например, добавить открытый SSH-ключ злоумышленника и получить SSH-доступ к серверу.
  • Если CSP-политика (политика защиты контента) запрещает внедрять JavaScript, злоумышленник может обойтись без него. На чистом HTML сверстать фейковую форму входа на сайт и угнать пароль администратора через такой продвинутый фишинг: фишинговая страница для пользователя оказывается на том же URL, и пользователю её сложнее обнаружить.
  • Наконец злоумышленник может устроить клиентский DoS — выставить Cookies размером больше 4 Кбайт. Пользователю достаточно один раз открыть ссылку — и весь сайт становится недоступен, пока не догадаешься специально почистить браузер: в подавляющем большинстве случаев веб-сервер откажется принимать такого клиента.

Рассмотрим пример еще одной выявленной XSS, в этот раз с более хитрой эксплуатацией. Сервис MCS позволяет объединять настройки файервола в группы. В имени группы и была обнаруженная XSS. Её особенность заключалась в том, что срабатывал вектор не сразу, не при просмотре списка правил, а при удалении группы:

И тут-то вредоносный JS и отрабатывает. То есть, сценарий получался следующий: злоумышленник создает правило файервола с «нагрузкой» в имени, администратор через некоторое время его замечает, инициирует процесс удаления.

Разработчикам MCS для защиты от XSS в загружаемых SVG-изображениях (если от них нельзя отказаться) команда Digital Security рекомендовала:

  • Размещать файлы, загружаемые пользователями, на отдельном домене, не имеющем ничего общего с «куковым». Скрипт будет выполняться в контексте другого домена и не будет нести угрозы для MCS.
  • В HTTP-ответе сервера отдавать заголовок «Сontent-disposition: attachment». Тогда файлы будут скачиваться браузером, а не исполняться.

Кроме того, сейчас для разработчиков доступно много способов смягчения рисков эксплуатации XSS:

  • с помощью флага «HTTP Only» можно сделать сессионные заголовки «Cookies» недоступными для вредоносного JavaScript;
  • правильно внедренная CSP-политика значительно усложнит эксплуатацию XSS для злоумышленника;
  • современные шаблонизаторы, такие как Angular или React, автоматически очищают пользовательские данные перед выводом в браузер пользователя.

Уязвимости двухфакторной аутентификации

Для повышения безопасности аккаунтов пользователям всегда рекомендуется включить 2FA (двухфакторную аутентификацию). Действительно, это эффективный способ помешать злоумышленнику получить доступ к сервису, если учётные данные пользователя были скомпрометированы.

В реализации 2FA бывают такие проблемы безопасности: Но всегда ли использование второго фактора аутентификации дает гарантию сохранности аккаунта?

  • Грубый перебор OTP-кода (одноразовых кодов). Несмотря на простоту эксплуатации, такие ошибки, как отсутствие защиты от брута OTP, встречаются и у больших компаний: кейс Slack, кейс Facebook.
  • Слабый алгоритм генерации, например возможность предугадать следующий код.
  • Логические ошибки, например возможность запросить чужой OTP на свой телефон, как это было у Shopify.

В случае MCS 2FA реализована на основе Google Authenticator и Duo. Сам протокол уже проверен временем, а вот реализацию проверки кода на стороне приложения стоит проверить.

В MCS 2FA используется в нескольких местах:

  • При аутентификации пользователя. Тут защита от перебора есть: у пользователя — всего несколько попыток ввода одноразового пароля, потом ввод на некоторое время блокируется. Это блокирует возможность провести подбор OTP перебором.
  • При генерации офлайновых backup-кодов для выполнения 2FA, а также её отключения. Здесь защиты от перебора реализовано не было, что позволяло при наличии пароля от учетной записи и действующей сессии перегенерировать backup-коды или отключить 2FA совсем.

Учитывая, что backup-коды располагались в том же диапазоне значений строк, что и сгенерированные приложением OTP, шанс подобрать код за короткое время был сильно выше.


Процесс подбора OTP для отключения 2FA c помощью инструмента «Burp: Intruder»

Результат

В целом, MCS как продукт оказался безопасным. За время аудита команде пентестеров не удалось получить доступ к клиентским ВМ и их данным, а найденные уязвимости быстро исправлены командой MCS.

Сервисы не являются статичными, они постоянно развиваются. Но тут важно отметить, что безопасность — это непрерывная работа. Но можно вовремя их находить и минимизировать шанс их повтора. А разработать продукт полностью без уязвимостей невозможно.

А чтобы сделать количество новых минимальным и сократить время их существования, команда платформы продолжает делать это: Сейчас все упомянутые уязвимости в MCS уже исправлены.

  • регулярно проводить аудиты внешними компаниями;
  • поддерживать и развивать участие в Bug Bounty-программе Mail.ru Group;
  • заниматься безопасностью. 🙂
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть