SkyShip Dusk by SeerLight
Построение любого сервиса обязательно включает в себя постоянную работу над безопасностью. Безопасность — это непрерывный процесс, который включает в себя постоянный анализ и улучшение защищенности продукта, мониторинг новостей про уязвимости и многое другое. В том числе — аудиты. Аудиты проводят как собственными силами, так и силами внешних экспертов, которые могут кардинально помочь с безопасностью, поскольку не погружены в проект и имеют незамыленный взгляд.
Статья — про этот самый незамыленный взгляд внешних экспертов, которые помогли команде Mail.ru Cloud Solutions (MCS) протестировать облачный сервис, и про то, что они нашли. В качестве «внешних сил» MCS выбрали компанию Digital Security, известную своей высокой экспертизой в кругах ИБ. И в данной статье мы разберем некоторые интересные уязвимости, найденные в рамках внешнего аудита — чтобы вас минули такие же грабли, когда вы будете делать свой облачный сервис.
Описание продукта
Mail.ru Cloud Solutions (MCS) — это платформа для построения виртуальной инфраструктуры в облаке. Она включает IaaS-ы, PaaS-ы, маркетплейс готовых образов приложений для разработчиков. С учётом архитектуры MCS нужно было проверить безопасность продукта по следующим направлениям:
- защита инфраструктуры среды виртуализации: гипервизоры, маршрутизация, файерволы;
- защита виртуальной инфраструктуры заказчиков: изоляция друг от друга, включая сетевую, приватные сети в SDN;
- OpenStack и его открытые компоненты;
- S3 собственной разработки;
- IAM: мультитенантные проекты с ролевой моделью;
- Vision (машинное зрение): API и уязвимости при работе с изображениями;
- веб-интерфейс и классические веб-атаки;
- уязвимости PaaS-компонентов;
- API всех компонентов.
Пожалуй, из существенного для дальнейшей истории — всё.
Что за работы проводились и зачем они нужны?
Аудит безопасности направлен на выявление уязвимостей и ошибок конфигурации, которые могут привести к утечке персональных данных, модификации чувствительной информации или же к нарушению доступности сервисов.
В ходе работ, которые длятся в среднем 1-2 месяца, аудиторы повторяют действия потенциальных злоумышленников и ищут уязвимости в клиентской и серверной части выбранного сервиса. В контексте аудита облачной платформы MCS были обозначены следующие цели:
- Анализ аутентификации в сервисе. Уязвимости в данном компоненте помогли бы сразу попасть в чужие аккаунты.
- Изучение ролевой модели и разграничения доступа между разными аккаунтами. Для злоумышленника возможность получить доступ к чужой виртуальной машине – желанная цель.
- Уязвимости клиентской части. XSS/CSRF/CRLF/etc. Может, существует возможность атаковать других пользователей через вредоносные ссылки?
- Уязвимости серверной части: всевозможные инъекции (RCE/SQL/XXE/SSRF и т.д.). Серверные уязвимости, как правило, сложнее найти, но они приводят к компрометации сразу множества пользователей.
- Анализ изоляции пользовательских сегментов на уровне сети. Для злоумышленника отсутствие изоляции значительно увеличивает поверхность атаки на других пользователей.
- Анализ бизнес-логики. Можно ли обмануть бизнес и создавать виртуальные машины бесплатно?
В данном проекте работы проводились по модели «Gray-box»: аудиторы взаимодействовали с сервисом с привилегиями обычных пользователей, но частично обладали исходными текстами API и имели возможность уточнять детали у разработчиков. Обычно это самая удобная, и при этом достаточно реалистичная модель работы: внутренняя информация все равно может быть собрана злоумышленником, это только вопрос времени.
Найденные уязвимости
Прежде чем аудитор начинает отправлять различные payload’ы (полезную нагрузку, с помощью которой проводится атака) в случайные места, необходимо разобраться, как что работает, какой функционал представлен. Может показаться, что это бесполезное занятие, ведь в большинстве изученных мест никаких уязвимостей не окажется. Но только понимание структуры приложения и логики его работы даст возможность отыскать самые сложные векторы атак.
Важно найти места, которые кажутся подозрительными или чем-то сильно отличаются от других. И первая опасная уязвимость была найдена именно таким образом.
IDOR
IDOR-уязвимости (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — один из самых частых вариантов уязвимостей в бизнес-логике, который позволяет тем или иным способом получить доступ к объектам, к которым в действительности доступ не разрешён. IDOR-уязвимости создают возможность получения сведений о пользователе разной степени критичности.
Один из вариантов IDOR — выполнение действий с объектами системы (пользователями, банковскими счетами, товарами в корзине) за счёт манипуляций с идентификаторами доступа к этим объектам. Это приводит к самым непредсказуемым последствиям. Например, к возможности подмены аккаунта отправителя денежных средств, за счёт которой можно красть их у других пользователей.
В случае MCS аудиторы как раз обнаружили IDOR-уязвимость, связанную с несекьюрными идентификаторами. В личном кабинете пользователя для доступа к любым объектам использовались идентификаторы UUID, которые казались, как говорят безопасники, внушающе небрутабельными (то есть защищёнными от атаки перебора). Но для определённых сущностей было обнаружено, что для получения информации о пользователях приложения используются обычные предсказуемые номера. Думаю, вы догадываетесь, что можно было изменить ID пользователя на единицу, отправить запрос заново и получить таким образом информацию в обход ACL (access control list, правил доступа к данным для процессов и пользователей).
Server Side Request Forgery (SSRF)
OpenSource-продукты хороши тем, что по ним есть огромное количество форумов с подробным техническим описанием возникающих проблем и, если вам повезло, с описанием решения. Но у этой медали есть обратная сторона: так же подробно расписаны и известные уязвимости. Например, на форуме OpenStack есть замечательные описания уязвимостей [XSS] и [SSRF], которые почему-то никто не спешит исправлять.
Частая функциональность приложений — возможность для пользователя отправить на сервер ссылку, по которой сервер переходит (например, чтобы загрузить изображение из указанного источника). При недостаточной фильтрации средствами безопасности самих ссылок или ответов, возвращаемых от сервера пользователям такой функционал легко используют злоумышленники.
SSRF-уязвимости могут сильно продвинуть развитие атаки вперёд. Злоумышленник может получить:
- ограниченный доступ к атакованной локальной сети, например только по определённым сегментам сети и по определённому протоколу;
- полный доступ локальной сети, если возможен даунгрейд с уровня приложений до транспортного уровня и, как следствие, полное управление нагрузкой на уровне приложений;
- доступ к чтению локальных файлов на сервере (если поддерживается схема file:///);
- и многое другое.
В OpenStack давно известна SSRF-уязвимость, носящая «слепой» характер: при обращении к серверу ты не получаешь от него ответ, но зато получаешь разные типы ошибок/задержек, в зависимости от результата запроса. На основании этого можно выполнить сканирование портов на хостах во внутренней сети, со всеми вытекающими последствиями, которые не стоит недооценивать. К примеру, у продукта может присутствовать API для бэк-офиса, доступный только из корпоративной сети. Обладая документацией (не забываем об инсайдерах), злоумышленник может с помощью SSRF обратиться к внутренним методам. К примеру, если удалось каким-то образом получить приблизительный список полезных URL, то с помощью SSRF можно по ним пройти и выполнить запрос — условно говоря, перевести деньги со счета на счет или поменять лимиты.
Это не первый случай обнаружения SSRF-уязвимости в OpenStack. В прошлом существовала возможность загружать ISO-образы ВМ по прямой ссылке, что тоже приводило к похожим последствиям. На данный момент эта функция удалена из OpenStack. Видимо, сообщество посчитало это самым простым и надежным решением проблемы.
А в этом публично доступном отчете с сервиса HackerOne (h1) эксплуатация уже не слепой SSRF с возможностью чтения метаданных инстанса приводит к получению Root-доступа ко всей инфраструктуре Shopify.
В MCS в двух местах с похожей функциональностью обнаружились SSRF-уязвимости, но их практически невозможно было эксплуатировать из-за файерволов и других защит. Так или иначе, команда MCS всё равно пофиксила эту проблему, не дожидаясь сообщества.
XSS вместо загрузки «шеллов»
Несмотря на сотни написанных исследований, из года в год XSS (атака межсайтового скриптинга) все еще самая часто встречаемая веб-уязвимость (или атака?).
Загрузка файлов — любимое место для любого исследователя безопасности. Часто оказывается можно загрузить произвольный скрипт (asp/jsp/php) и выполнить команды ОС, в терминологии пентестеров — «загрузить шелл». Но популярность таких уязвимостей работает в обе стороны: про них помнят и разрабатывают средства против них, так что в последнее время вероятность «загрузить шелл» стремится к нулю.
Атакующей команде (в лице Digital Security) повезло. ОК, в MCS на стороне сервера проверялось содержимое загружаемых файлов, разрешены были лишь изображения. Но 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;
- заниматься безопасностью. :)
