Какие ошибки допускают пользователи в популярных SaaS-решениях, как это помогает хакерам и как перестать это делать раз и навсегда
С развитием рынка облачных провайдеров IaaS/PaaS и Machine Learning сервисов, предоставляющих вычислительные ресурсы, хранение данных в облаке, мониторинг, развертывание облачных сред для разработки, команде аудита и консалтинга Group-IB все чаще приходится иметь дело с облачной инфраструктурой.
Без сомнения, удобные для бизнеса и технических специалистов облака являются довольно сложным объектом защиты. Непродолжительный анализ покажет, что информации на этот счет мало, сервисов и провайдеров много, облака все разные, а принадлежность конкретной находки к компании-заказчику пентеста — ещё пойди определи.
В нашем новом блоге речь пойдет про распространенные ошибки пользователей публичных облаков — мы подробно поговорим о публичных бакетах и репозиториях пользователей и покажем как и почему эти недостатки стоит устранять.
Исследуя киберпреступность более 19 лет, мы хорошо понимаем как именно действует злоумышленник, с помощью чего исследует интересующий его объект атак и на что именно будет обращать внимание, проводя первичную разведку. В том числе эти знания мы использовали при разработке и запуске первой на российском рынке услуги Red Teaming. Данный материал подготовлен Захаром Корняковым, пентестером департамента аудита и консалтинга Group-IB, на базе реальных кейсов.
Мы надеемся, что он поможет компаниям лучше понимать логику действий атакующих и, соответственно, более качественно выстроить свою защиту. Ниже мы разберем распространенные недостатки со стороны пользователей облаков и дадим рекомендации, как их избежать.
Дисклеймер
В этом блоге мы преследуем цель помочь специалистам по кибербезопасности выстроить надежную защиту своих информационных систем за счет лучшего понимания техник и тактик злоумышленников на этапе осуществления внешней сетевой разведки. По этой причине статья написана с точки зрения специалиста, который осуществляет данную разведку. В статье не приводятся уязвимости, эксплуатация которых позволит навредить компаниям.
В фокусе нашего внимания — SaaS-решения, которые специфичны для каждого региона использования. Если вы зададитесь целью поискать что-либо об облачной разведке, то довольно быстро столкнетесь с тем, что, в основном в информационном пространстве затрагиваются технологии и методы разведки только крупных международных провайдеров (Amazon, Google, etc), а материалов о локальных провайдерах почти нет. Основываясь на наших знаниях, мы хотели бы восполнить этот пробел применительного к региону СНГ, и тем самым помочь специалистам по кибербезопасности с защищающейся стороны иметь представление о том, какие сервисы может использовать их компания, как они могут оказаться под угрозой, и главное — как их защитить.
Что они ищут:
При упоминании облаков зачастую приходят мысли о различных сервисах относящихся к CI/CD, оркестрации, пользовательским бакетам и CDN.
Бакет — от англ. Bucket (ведро сущ., складывать в ведро гл.) логическая сущность, которая помогает организовать хранение объектов.
Но помимо этого, существует множество сервисов, которые упускаются из виду, а именно системы CRM, почтовые сервисы, корпоративные мессенджеры, вики-платформы и так далее. В них может храниться много информации, которой можно воспользоваться во вредоносных целях. Для того, чтобы этого не произошло нужно знать, как будет действовать атакующий. Для начала предлагаем всем компаниям-клиентам облачных сервисов ответить на три простых вопроса:
Включена ли у всех пользователей двухфакторная аутентификация?
Реализована ли строгая парольная политика?
Обезличены ли эти страницы для более сложного определения принадлежности ресурса компании?
Если вам кажется, что это слишком очевидно, давайте разберемся так ли это. Итак, что же за сервисы можно встретить в облаке и самое главное, как их ищут.
Slack
Slack является популярным корпоративным мессенджером и его особенность заключается в том, что в нем происходит обсуждение рабочих задач и процессов, сотрудники зачастую добавлены во все существующие чаты. А еще это неплохой инструмент для интеграции с системой управления доступом, так как в Slack можно создавать ботов, которые могут выдавать, например, учетные данные для VPN.
Сам воркспейс (workspace) Slack имеет следующий адрес: <название компании>.slack.com. Явным маркером может являться логотип воркспейса, который может добавить сама компания, тогда вопрос принадлежности воркспейса можно закрывать.
Workspace — зарезервированное за компанией рабочее пространство, которое состоит из различных каналов, в которых общаются сотрудники.
В Slack присутствует SSO через Google или Apple. Для регистрации достаточно иметь корпоративную почту, поэтому существует потенциальный вектор для самостоятельной регистрации в воркспейсе через получение учетных данных низкопривилегированного пользователя (например, аккаунт для рассылки уведомлений). Такой или любой другой аккаунт злоумышленник может получить через, к примеру, различные публичные утечки учетных данных.
SSO (Single sign-on) — это схема аутентификации, которая позволяет пользователю входить с одним идентификатором из одного раздела портала в другой, либо из одной системы в другую, не связанную с первой системой, без повторной аутентификации.
Если же найти Slack с использованием названия компании проводящему разведку не удалось или не получается понять, относится ли найденный воркспейс к компании или нет, то можно прибегнуть к гугл доркингу или же поискать на github, так как разработчики иногда выкладывают своих ботов.
Google Dorking — использование специфического для конкретного поисковика команд и синтаксиса запросов для более точного поиска.
Также, как правило, обычно собирают сначала основные домены компании, а затем пробуют получить воркспейс через ffuf.
ffuf — утилита, предназначенная для быстрого подбора директорий, значений заголовков и автоматического ввода непредвиденных данных в веб-приложении (фаззинг).
ignore-body — позволяет не получать тело ответа
mc 200 — (match code) Показывать только запросы, на которые был получен ответ с кодом 200 (ОК).
Кейс: Далеко не всегда ИБ и IT-службы компаний в курсе про все SaaS-решения, которые используются, а значит не могут проконтролировать пароли, которые выставляют пользователи при создании аккаунта. Это значительно повышает уровень риска, если в SaaS-решении сотрудники выдают VPN-конфиги, пароли от учетных записей, обмениваются чувствительной информацией. Что и произошло во время одного проекта по Red Teaming, который делала команда аудита Group-IB для крупной образовательной платформы. Нами был найден Slack-воркспейс, в котором не была реализована строгая парольная политика, и пользователи выставляли пароли от своих личных аккаунтов. Потратив время на разведку по сотрудникам и сбору их паролей через публичные утечки, был получен доступ в профиль Slack одного из разработчиков. Затем в одном из чатов был найден VPN-конфиг и так незамысловато открылся доступ во внутреннюю сеть компании.
Atlassian
Проводя свое исследование для усиления защиты облачного сервиса, необходимо знать, что организация может разместить в облаке Atlassian такие сервисы, как Jira, Confluence, Bitbucket и т.д. Попав в них, можно получить кладезь информации, так как, увы, зачастую компании не разграничивают в том же Confluence воркспейсы (рабочее пространство, которое представляет собой сборник статей и материалов) и могут использовать его как onboarding инструмент для новых сотрудников, разрешив доступ во все разделы Wiki. Для избежания подобной ситуации необходимо корректно настроить права доступа различных пользователей к только необходимым для бизнес процессов разделов, а также контролировать наличие двухфакторной аутентификации и реализацию строгой парольной политики. Мы еще вернемся к этому в наших рекомендациях по защите.
Помимо этого, просто попав в Confluence, можно получить список всех существующих пользователей, а в Jira помимо пользователей еще и их почты.
Для перебора и валидации также можно воспользоваться ffuf, предварительно собрав основные домены компании:
ffuf -u https://FUZZ.atlassian.net/login.jsp -ignore-body -w domains.txt
Если организация не использует облачные сервисы Atlassian, то проводящий разведку увидит такую картинку:
Если же использует, то произойдет редирект на адрес https://<поддомен>.atlassian.net/login?application=jira. Стоит отметить, что значение параметра “application” можно перебирать (Confluence, Trello, Jira, etc, см. пример ниже).
Salesforce
Salesforce это CRM-система, из которой можно получить информацию об операциях, продажах и клиентах компании. Примечательным является то, что всем новым пользователям присваивается временный пароль, который пользователь впоследствии меняет. Это может помочь злоумышленнику в подборе пароля, так как пользователи склонны менять пароль на легкий для запоминания, а также дублировать пароли, которые уже используются для других сервисов, в том числе и для личных. Именем пользователя по умолчанию в Salesforce служит его почта.
Адресом компании в облаке Salesforce является <название компании>.my.salesforce.com, соответственно здесь придется искать поддомены, например при помощи утилиты zdns:
zdns alookup –name-servers=8.8.8.8 -input-file domains.txt -output-file resolved.json
Также можно поискать по ключевым словам существующие поддомены по различным базам DNS записей, например, rapiddns.io, omnisint.io, etc.
MS Office365
MS Office365 включает в себя широкий перечень сервисов — почта, Azure, Sharepoint, OneNote, Microsoft Teams, Skype, OneDrive и т.д. Примечательно, что для входа в любой из сервисов Office365 используется SSO, из которого можно получить определенную информацию, как минимум, перебирать пользователей компании.
Понять, что организация использует Azure AD довольно просто:
Если при запросе:
NameSpaceType тег возвращает значение Managed, то доменное имя компании действительно для платформы Office365.
Eсли возвращается значение Unknown, то нет.
Знать при этом валидную почту не обязательно, часто достаточно ввести домен компании, например wwdwdwdwd@company.com
Если говорить про Office365 более подробно, то рамками одной статьи не обойтись, поэтому рекомендуем самостоятельно ознакомиться с релевантными материалами, например, O365Enum и инструментом.
Zendesk
Еще одна CRM\ITSM система, которая, как вы уже могли догадаться, использует облако для хостинга своих сервисов. С ней все почти так же просто, как и с Salesforce — сервисы размещаются по адресу <company_name>.zendesk.com, однако, если домена нет, то не будет ответа NXDOMAIN, а будет выдан адрес серверов CloudFlare.
Для определения существования используется значение заголовка Location в ответе на запрос.
При существующем домене пользователя перенаправят на него, а если такого домена нет, то произойдет перенаправление на страницу zendesk.com или по адресу: https://www.zendesk.com/app/help-center-closed/.
Такой компании не существует:
Компания существует:
Также в определении “свой/чужой” сильно помогают фирменные логотипы, которые компания размещает на странице авторизации. Догадываетесь, что делать этого не стоит? Мы еще напишем об этом в рекомендациях ниже.
Для определения существования компании при помощи утилиты ffuf можно воспользоваться следующей командой:
ffuf -u https://FUZZ.zendesk.com/ -w domains.txt -r -H “User-Agent: User-Agent: Mozilla/5.0(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36”
r (redirects) опция позволяет ffuf запрашивать страницу при перенаправлении (302,301)
H (header) опция позволяет вставлять заголовок, например, User-Agent. По умолчанию ffuf использует в качестве юзер агента значение Fuzz Faster U Fool <версия>, что детектит Cloudflare и блокирует запрос
Proofhub
Proofhub — это платформа для управления проектами и командами. Аналогами являются Wrike, Trello, Jira и т.д. Как и в случае с Zendesk, компанию можно определить по поддомену. Проверку существования компании осуществляют следующей командой:
ffuf -u https://FUZZ.proofhub.com/api/v4/authenticate/company -w domains.txt -fs 60-70
fs (filter size) — опция позволяет фильтровать ответы по размеру (от 60 до 70 это размер ответа, если компании не существует).
При существовании будет отрендерена следующая страница:
Если же компании не существует, то получим сообщение об ошибке:
Yandex Cloud. Managed Service for GitLab
Yandex Cloud предлагает в качестве облачной услуги Managed Service for GitLab, который можно найти по маске <company_name>.gitlab.yandexcloud.net. Конечно, если компания-клиент облачного сервиса не уделила нужное внимание сокрытию своих данных.
Кейс: В качестве примера можем привести случай, когда нами был обнаружен инстанс Gitlab, в котором были публичные репозитории (для доступа к которым не нужна аутентификация). Исследовав данные репозиториев, нами были найдены учетки от “боевых” систем искомой компании, а дальше дело техники — первичный доступ и продвижение в сети.*
*Комментарий Yandex Cloud: создать репозитории без авторизации нельзя, если кто-то умышленно не открыл публичный доступ.
Yandex Cloud. Website Hosting
Yandex Cloud предлагает облачный сервис по хостингу сайтов. Данные сайты тоже достаточно просто найти, если компанией, владеющей сайтом, не предпринято никаких шагов по защите. В этом случае их A-запись выглядит, как <company_name>.website.yandexcloud.net.
В следующей части нашего блога будут рассмотрены возможности разведки S3-решений.
Разведка S3-решений
S3-хранилище — это сервис хранения объектов, предлагаемый поставщиками облачных услуг.
Yandex Cloud S3
В Yandex Cloud присутствует реализация S3-сервиса. Найти его можно двумя способами, либо в пути https://storage.yandexcloud.net/bucket/, либо по хосту <bucket>.storage.yandexcloud.net. Где опять же <bucket> = <company_name>. На этом моменте вы уже должны понимать, что называть бакет “в честь” своей компании, используя решения облачного провайдера, не стоит. Но, как обычно, мы пройдемся по этой части более подробно и вынесем рекомендации по ней отдельным пунктом в конце материала.
Ниже приведен пример несуществующего бакета:
VK cloud S3
VK Cloud предлагает множество сервисов, одним из которых является S3-сервис, его бакеты представляют собой следующий адрес <bucket_name>.hb.bizmrg.com или <bucket_name>.ib.bizmrg.com в зависимости от тарифного плана. Предположим, специалист, проводящий разведку, вновь использует уже хорошо вам известную утилиту ffuf:
ffuf -u https://FUZZ.ib.bizmrg.com/ -w buckets.txt
Croc Cloud S3
В Croc Cloud используется Amazon S3-совместимое API для реализации своего S3-сервиса. В данном сервисе можно перебирать бакеты следующим образом: если бакет открытый для всех, то при некорректной защите есть возможность получить даже некоторую метаинформацию, а именно, почту владельца бакета. Показываем ниже пример использования утилиты ffuf:
ffuf -u https://storage.cloud.croc.ru/FUZZ -w buckets.txt
MTS Cloud S3
Если говорить про S3-хранилища в облаке MTS, то, в отличие от Amazon, Yandex Cloud и других поставщиков S3-сервисов, тут все сделано достаточно интересно. Глобальный namespace для хостинга бакетов не используется, что является положительной историей для компаний, решивших воспользоваться этим S3-хранилищем.
Это значит, что можно создавать бакеты с уже существующими именами в своем namespace. Таким образом, полный путь до бакета будет выглядеть следующим образом:
http(s)://NAMESPACE.s3mts.ru/BUCKET/file/
где:
NAMESPACE — имя вашего неймспейса
BUCKET — имя вашего бакета
File — имя файла
Таким образом, для получения валидного имени бакета нужно будет сначала угадать namespace (именно угадать, потому что нельзя четко определить существует ли namespace или нет), а потом уже и имя бакета.
Ниже пример, когда удалось узнать и namespace и валидное имя бакета:
ffuf -w namespaces.txt:NAMESPACES -w buckets.txt:BUCKETS -u https://NAMESPACES.s3mts.ru/BUCKETS
Cloud (до 2022 года — SberCloud) S3
Здесь обращение может быть сделано на определенный публичный эндпоинт хранилища в зависимости от зоны доступности, что отличается от того же Yandex Cloud, где используется глобальная зона доступности, то есть можно делать запросы на один глобальный эндпоинт.
Зоны доступности зависят от географической позиции хранилища и имеют свои эндпоинты для обработки запросов. Подробнее про эндпоинты можно прочитать в самой документации Cloud.
Эндпоинты для публичного доступа выглядят следующим образом:
https://NAMESPACE.ZONE.sbercloud.ru/BUCKETNAME
NAMESPACE — пространство имен, которое создает администратор хранилища компании (обычно совпадает с ее названием)
ZONE — упомянутые выше зоны доступности (s3pd01, s3pd02, s3pd11, s3pd12, s3pdgeob)
BUCKETNAME — имя бакета
Выяснить достоверно существует ли namespace нельзя, что безусловно хорошо для защиты. Здесь можно только угадать комбинацию namespace, zone и bucketname.
ffuf -w namespaces.txt:NAMESPACE -w buckets.txt:BUCKET -w zones.txt:ZONE -u https://NAMESPACE.ZONE.sbercloud.ru/BUCKET
Selectel S3
До объектного хранилища от провайдера Selectel можно достучаться различными способами:
https://s3.storage.selcloud.ru/bucketname, но преимущество встроенной защиты здесь в том, что здесь сложно понять существует ли бакет вообще, так как на все запросы, даже несуществующих бакетов, бэкенд отдает 403. Это происходит, потому что по данному эндпоинту возможен только авторизованный доступ.
https://<domain>.selcdn.ru. Персональный домен аккаунта (*****.selcdn.ru) используется для раздачи файлов из публичных контейнеров. На аккаунт выдается один персональный домен. Если будет попытка обращения к несуществующему персональному домену аккаунта, то сервер отдаст HTTP код 434 Requested Host Unavailable
Также у Selectel существует персональный домен аккаунта, который представляет собой порядковый номер, по типу 123456.selcdn.ru, который присваивается каждому аккаунту. Ниже приведен пример найденных в открытых источниках (rappiddns.io) список данных персональных доменов. При обращении к данному эндпоинту возможен неавторизованный доступ к элементам внутри хранилища, но листинга директорий и файлов нет (при обращении в корень выдается ошибка unauthorized), поэтому придется перебирать значения имен возможных файлов.
Ниже приведен пример найденного файла, к которому открыт доступ.
Демонстрация ошибки 434 при не существующем домене:
Как проверить — все ли хорошо с неймингом бакетов и защитой SaaS-решений?
В нашем блоге перечислены далеко не все подобные сервисы, их количество слишком велико, и в них присутствует специфика региона (в том или ином регионе отдают предпочтения определенным провайдерам и сервисам). Для поиска сервисов, упомянутых в этой статье нами был написан инструмент. Вы можете использовать данный инструмент для проверки предсказуемости названия ваших бакетов и персональных доменов компаний в SaaS-решениях , а также проверить, не ушел ли какой-то сервис за горизонт взгляда IT-службы.
Возможно, какие-то описанные методы поиска перечисленных решений со временем потеряют актуальность, но в данном блоге мы ставим себе цель продемонстрировать, на безопасность каких сервисов стоит обратить внимание ИТ-службам компании.
Итак, в целях совершенствования защиты для компаний, использующих облачные сервисы SaaS или S3-хранилища, мы перечислили основные способы получения “разведданных”. Мы рекомендуем устранить эти недостатки, поскольку найденные домены и пользовательские бакеты позволяют расширить поверхность атак, а также могут раскрывать различную чувствительную информацию или вовсе быть доступными для неавторизованного доступа. Данный тип разведки также может помочь выйти на так называемую зону Shadow IТ — ИТ-устройства, софт и сервисы, которые присутствуют в организации, но не обслуживаются ИТ-отделом. Как бороться с этим — а делать это необходимо — мы также опишем в финальном разделе блога.
Gartner ежегодно прогнозирует, что одна треть успешных атак, с которыми сталкиваются предприятия, направлена на их теневые ИТ-ресурсы.
Check-list из 7 основных шагов, чтобы защитить свои данные в публичном облаке прямо сейчас
Шаг 1. Максимально обезличьте компанию, если используете SaaS-решение, чтобы не давать подсказки потенциальным злоумышленникам. А именно — несмотря на протесты маркетологов (безопасность — приоритет) уберите логотип, сведите к минимуму использование фирменного стиля в выпадающих окнах/плашках/заглушках. Идеально, если вы придумаете название, не соответствующее названию компании, чтобы у атакующего было больше сомнений в релевантности атаки.
Шаг 2. Сделайте строгой парольную политику к аккаунтам в SaaS и контролируйте ее выполнение. Да, мы знаем, что зачастую в SaaS-решения сложно внедрить использующуюся в компании парольную политику и проконтролировать ее исполнение. Сотрудники склонны ставить легкие пароли или те, которые они используют для личных аккаунтов, а эти пароли, как известно, часто мелькают в публичных утечках. Но если вы не хотите стать простой мишенью для атаки — лучше сфокусироваться на этом и сделать невозможным применение легких паролей. В этом может помочь подключение федерации удостоверений (возможно в Yandex Cloud, Cloud (ранее SberCloud), Croc Cloud, Zendesk, Atlassian, Slack, Salesforce).
Шаг 3. Еще лучше — перейдите на двухфакторную аутентификацию на аккаунтах в SaaS-решениях. С этим также может помочь федерация удостоверений.
Шаг 4. Обеспечьте корректную авторизацию своих бакетов и уберите их из публичного доступа, так как в них может содержаться чувствительная информация. С корректным выставлением прав могут помочь решения класса CSPM. Более того можно включить шифрование данных в бакетах при помощи KMS или AWS SDK (возможно в Yandex Cloud, Cloud (ранее SberCloud), Selectel).
Шаг 5. Регулярно проверяйте все, что может оказаться в теневой зоне — Shadow IT. Приобретите решение для управления поверхностью атаки (Attack Surface Management) и проверяйте с его помощью все, что может “торчать наружу” — ИТ-устройства, ПО и сервисы, которые присутствуют в организации, но не обслуживаются ИТ-отделом. Они не стоят на балансе ИТ-отдела, их состояние и работа не контролируются, более того, ИТ-департамент может вообще ничего о них не знать. Но именно они могут представлять дополнительные лазейки для злоумышленников.
Шаг 6. Проводите тестирование на проникновение, а лучше — воспользуйтесь сервисом Red Team с максимально широким охватом возможных векторов компрометации. Это не отменяет всех предыдущих шагов и позволит выявить уже совсем неочевидные возможности для развития атаки, а значит — минимизировать вероятность ее успеха.
Шаг 7. Используйте решения класса Threat Intelligence — регулярно проверяйте наличие логинов, email адресов и паролей сотрудников вашей компании в утечках и публичных Git-репозиториях. Настройте свою платформу Threat Intelligence исключительно под нужды своей компании и ландшафт угроз, характерный только для вашей индустрии в том регионе, в котором работаете.