- PVSM.RU - https://www.pvsm.ru -
SkyShip Dusk [1] by SeerLight
Построение любого сервиса обязательно включает в себя постоянную работу над безопасностью. Безопасность — это непрерывный процесс, который включает в себя постоянный анализ и улучшение защищенности продукта, мониторинг новостей про уязвимости и многое другое. В том числе — аудиты. Аудиты проводят как собственными силами, так и силами внешних экспертов, которые могут кардинально помочь с безопасностью, поскольку не погружены в проект и имеют незамыленный взгляд.
Статья — про этот самый незамыленный взгляд внешних экспертов, которые помогли команде Mail.ru Cloud Solutions (MCS) протестировать облачный сервис, и про то, что они нашли. В качестве «внешних сил» MCS выбрали компанию Digital Security, известную своей высокой экспертизой в кругах ИБ. И в данной статье мы разберем некоторые интересные уязвимости, найденные в рамках внешнего аудита — чтобы вас минули такие же грабли, когда вы будете делать свой облачный сервис.
Mail.ru Cloud Solutions (MCS) [2] — это платформа для построения виртуальной инфраструктуры в облаке. Она включает IaaS-ы, PaaS-ы, маркетплейс готовых образов приложений для разработчиков. С учётом архитектуры MCS нужно было проверить безопасность продукта по следующим направлениям:
Пожалуй, из существенного для дальнейшей истории — всё.
Аудит безопасности направлен на выявление уязвимостей и ошибок конфигурации, которые могут привести к утечке персональных данных, модификации чувствительной информации или же к нарушению доступности сервисов.
В ходе работ, которые длятся в среднем 1-2 месяца, аудиторы повторяют действия потенциальных злоумышленников и ищут уязвимости в клиентской и серверной части выбранного сервиса. В контексте аудита облачной платформы MCS были обозначены следующие цели:
В данном проекте работы проводились по модели «Gray-box»: аудиторы взаимодействовали с сервисом с привилегиями обычных пользователей, но частично обладали исходными текстами API и имели возможность уточнять детали у разработчиков. Обычно это самая удобная, и при этом достаточно реалистичная модель работы: внутренняя информация все равно может быть собрана злоумышленником, это только вопрос времени.
Прежде чем аудитор начинает отправлять различные payload’ы (полезную нагрузку, с помощью которой проводится атака) в случайные места, необходимо разобраться, как что работает, какой функционал представлен. Может показаться, что это бесполезное занятие, ведь в большинстве изученных мест никаких уязвимостей не окажется. Но только понимание структуры приложения и логики его работы даст возможность отыскать самые сложные векторы атак.
Важно найти места, которые кажутся подозрительными или чем-то сильно отличаются от других. И первая опасная уязвимость была найдена именно таким образом.
IDOR-уязвимости (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — один из самых частых вариантов уязвимостей в бизнес-логике, который позволяет тем или иным способом получить доступ к объектам, к которым в действительности доступ не разрешён. IDOR-уязвимости создают возможность получения сведений о пользователе разной степени критичности.
Один из вариантов IDOR — выполнение действий с объектами системы (пользователями, банковскими счетами, товарами в корзине) за счёт манипуляций с идентификаторами доступа к этим объектам. Это приводит к самым непредсказуемым последствиям. Например, к возможности подмены аккаунта отправителя денежных средств, за счёт которой можно красть их у других пользователей.
В случае MCS аудиторы как раз обнаружили IDOR-уязвимость, связанную с несекьюрными идентификаторами. В личном кабинете пользователя для доступа к любым объектам использовались идентификаторы UUID, которые казались, как говорят безопасники, внушающе небрутабельными (то есть защищёнными от атаки перебора). Но для определённых сущностей было обнаружено, что для получения информации о пользователях приложения используются обычные предсказуемые номера. Думаю, вы догадываетесь, что можно было изменить ID пользователя на единицу, отправить запрос заново и получить таким образом информацию в обход ACL (access control list, правил доступа к данным для процессов и пользователей).
OpenSource-продукты хороши тем, что по ним есть огромное количество форумов с подробным техническим описанием возникающих проблем и, если вам повезло, с описанием решения. Но у этой медали есть обратная сторона: так же подробно расписаны и известные уязвимости. Например, на форуме OpenStack есть замечательные описания уязвимостей [XSS] [3] и [SSRF] [4], которые почему-то никто не спешит исправлять.
Частая функциональность приложений — возможность для пользователя отправить на сервер ссылку, по которой сервер переходит (например, чтобы загрузить изображение из указанного источника). При недостаточной фильтрации средствами безопасности самих ссылок или ответов, возвращаемых от сервера пользователям такой функционал легко используют злоумышленники.
SSRF-уязвимости могут сильно продвинуть развитие атаки вперёд. Злоумышленник может получить:
В OpenStack давно известна SSRF-уязвимость, носящая «слепой» характер: при обращении к серверу ты не получаешь от него ответ, но зато получаешь разные типы ошибок/задержек, в зависимости от результата запроса. На основании этого можно выполнить сканирование портов на хостах во внутренней сети, со всеми вытекающими последствиями, которые не стоит недооценивать. К примеру, у продукта может присутствовать API для бэк-офиса, доступный только из корпоративной сети. Обладая документацией (не забываем об инсайдерах), злоумышленник может с помощью SSRF обратиться к внутренним методам. К примеру, если удалось каким-то образом получить приблизительный список полезных URL, то с помощью SSRF можно по ним пройти и выполнить запрос — условно говоря, перевести деньги со счета на счет или поменять лимиты.
Это не первый случай обнаружения SSRF-уязвимости в OpenStack. В прошлом существовала возможность загружать ISO-образы ВМ по прямой ссылке, что тоже приводило к похожим последствиям. На данный момент эта функция удалена из OpenStack. Видимо, сообщество посчитало это самым простым и надежным решением проблемы.
А в этом [5] публично доступном отчете с сервиса HackerOne (h1) эксплуатация уже не слепой SSRF с возможностью чтения метаданных инстанса приводит к получению Root-доступа ко всей инфраструктуре Shopify.
В MCS в двух местах с похожей функциональностью обнаружились SSRF-уязвимости, но их практически невозможно было эксплуатировать из-за файерволов и других защит. Так или иначе, команда MCS всё равно пофиксила эту проблему, не дожидаясь сообщества.
Несмотря на сотни написанных исследований, из года в год XSS (атака межсайтового скриптинга) все еще самая часто встречаемая [6] веб-уязвимость (или атака [7]?).
Загрузка файлов — любимое место для любого исследователя безопасности. Часто оказывается можно загрузить произвольный скрипт (asp/jsp/php) и выполнить команды ОС, в терминологии пентестеров — «загрузить шелл». Но популярность таких уязвимостей работает в обе стороны: про них помнят и разрабатывают средства против них, так что в последнее время вероятность «загрузить шелл» стремится к нулю.
Атакующей команде (в лице Digital Security) повезло. ОК, в MCS на стороне сервера проверялось содержимое загружаемых файлов, разрешены были лишь изображения. Но SVG — это тоже картинка. А чем могут быть опасны SVG картинки? Тем, что в них можно встраивать фрагменты JavaScript!
Оказалось, что загружаемые файлы доступны всем пользователям сервиса MCS — значит можно атаковать других пользователей облака, а именно — администраторов.
Пример внедрения с помощью XSS-атаки фишинговой формы логина
Примеры эксплуатации XSS-атаки:
Рассмотрим пример еще одной выявленной XSS, в этот раз с более хитрой эксплуатацией. Сервис MCS позволяет объединять настройки файервола в группы. В имени группы и была обнаруженная XSS. Её особенность заключалась в том, что срабатывал вектор не сразу, не при просмотре списка правил, а при удалении группы:
То есть, сценарий получался следующий: злоумышленник создает правило файервола с «нагрузкой» в имени, администратор через некоторое время его замечает, инициирует процесс удаления. И тут-то вредоносный JS и отрабатывает.
Разработчикам MCS для защиты от XSS в загружаемых SVG-изображениях (если от них нельзя отказаться) команда Digital Security рекомендовала:
Кроме того, сейчас для разработчиков доступно много способов смягчения рисков эксплуатации XSS:
Для повышения безопасности аккаунтов пользователям всегда рекомендуется включить 2FA (двухфакторную аутентификацию). Действительно, это эффективный способ помешать злоумышленнику получить доступ к сервису, если учётные данные пользователя были скомпрометированы.
Но всегда ли использование второго фактора аутентификации дает гарантию сохранности аккаунта? В реализации 2FA бывают такие проблемы безопасности:
В случае MCS 2FA реализована на основе Google Authenticator и Duo [13]. Сам протокол уже проверен временем, а вот реализацию проверки кода на стороне приложения стоит проверить.
В MCS 2FA используется в нескольких местах:
Учитывая, что backup-коды располагались в том же диапазоне значений строк, что и сгенерированные приложением OTP, шанс подобрать код за короткое время был сильно выше.
Процесс подбора OTP для отключения 2FA c помощью инструмента «Burp: Intruder»
В целом, MCS как продукт оказался безопасным. За время аудита команде пентестеров не удалось получить доступ к клиентским ВМ и их данным, а найденные уязвимости быстро исправлены командой MCS.
Но тут важно отметить, что безопасность — это непрерывная работа. Сервисы не являются статичными, они постоянно развиваются. А разработать продукт полностью без уязвимостей невозможно. Но можно вовремя их находить и минимизировать шанс их повтора.
Сейчас все упомянутые уязвимости в MCS уже исправлены. А чтобы сделать количество новых минимальным и сократить время их существования, команда платформы продолжает делать это:
Автор: gmorfy
Источник [15]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/327527
Ссылки в тексте:
[1] SkyShip Dusk: https://www.deviantart.com/seerlight/art/SkyShip-Dusk-644440350
[2] Mail.ru Cloud Solutions (MCS): https://mcs.mail.ru/
[3] [XSS]: https://bugs.launchpad.net/horizon/+bug/1417762
[4] [SSRF]: https://bugs.launchpad.net/heat-dashboard/+bug/1765402
[5] этом: https://hackerone.com/reports/341876
[6] часто встречаемая: https://speakerdeck.com/lweichselbaum/o-securing-web-apps-with-modern-platform-features
[7] атака: https://habr.com/ru/company/pt/blog/149152
[8] клиентский DoS: http://homakov.blogspot.com/2014/01/cookie-bomb-or-lets-break-internet.html
[9] правильно внедренная CSP-политика: https://developers.google.com/web/fundamentals/security/csp/
[10] кейс Slack: https://hackerone.com/reports/121696
[11] кейс Facebook: http://www.anandpraka.sh/2016/03/how-i-could-have-hacked-your-facebook.html
[12] было: https://hackerone.com/reports/124845
[13] Duo: https://duo.com/product/trusted-users/two-factor-authentication/duo-mobile
[14] в Bug Bounty-программе Mail.ru Group: http://hackerone.com/mailru
[15] Источник: https://habr.com/ru/post/463897/?utm_campaign=463897&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.