Злоумышленники все чаще используют методы "бессетевых" атак, нацеленных на облачные приложения и удостоверения личности. Вот как злоумышленники могут (и компрометируют) организации - без необходимости прикасаться к конечной точке или обычным сетевым системам и службам.
Прежде чем углубляться в детали используемых методов атаки, давайте обсудим, почему эти атаки становятся все более распространенными.
Сегодня большинство организаций используют от десятков до сотен приложений SaaS для различных бизнес-функций. Некоторые из них полностью основаны на SaaS, без каких-либо традиционных сетей, о которых можно говорить, но большинство приняли гибридную модель со смесью локальных, облачных и SaaS-сервисов, составляющих основу используемых бизнес-приложений.
Основная часть внедрения SaaS ориентирована на пользователей, в отличие от централизованного управления ИТ, поскольку внедрение снизу вверх неотъемлемо от роста, ориентированного на продукт. Последние данные Push Security указывают на то, что только 1 из 5 приложений SaaS были санкционированы бизнесом. Большинство из них просто неизвестны и, следовательно, вообще не проверялись.
Облачные приложения и SaaS спроектированы так, чтобы быть взаимосвязанными, функционируя подобно закрытым сетям внутренних бизнес-приложений, которые вы, возможно, использовали в прошлом. Средством обеспечения такой взаимосвязи является идентификация.
Конкретный состав идентификатора может сильно различаться. В зависимости от приложения для одной учетной записи может быть задействовано несколько механизмов аутентификации – например, через SAML, учетные записи в социальных сетях (OIDC), а также имя пользователя и пароль. Хотя SAML требует, чтобы администраторы заранее настроили его для данного клиента приложения, пользователи могут зарегистрироваться в приложении с помощью OIDC, просто воспользовавшись функцией "войти с помощью Google".
Фактически это создает несколько удостоверений, привязанных к одной учетной записи, что может внести много путаницы и сложности – например, то, что администратор IdP удаляет эту учетную запись, не означает, что к приложению / учетной записи нельзя получить доступ с помощью одного из других созданных методов входа. Это может затруднить определение того, какие приложения используются и какие удостоверения существуют в организации.
Итак, на практике в конечном итоге можно получить комбинацию следующих действий:
Затем, в зависимости от областей OAuth, утвержденных для данного приложения, разрешения и рабочие процессы в одном приложении могут влиять на другие приложения, где им разрешено взаимодействовать друг с другом.
Идентификация - это клей, который скрепляет эту экосистему. Однако средства контроля, существующие для защиты идентификации, имеют серьезные ограничения. Компании часто думают, что на всех их приложениях и удостоверениях внедрен MFA или все приложения поддерживают единый вход. Но реальность такова, что только 1/3 приложений на самом деле поддерживают единый вход (и многие из них только премиум-уровня со значительным повышением цен). Более того, около 60% уникальных идентификаторов (т. Е. Не использующих единый вход) не имеют зарегистрированного MFA.
Таким образом, в реальности существуют значительные пробелы в средствах контроля безопасности, защищающих облачные идентификаторы, в то время как идентификаторы и облачные приложения становятся все более распространенными.
Хотя в этом нет ничего нового (некоторые описания идентификационных атак / фишинга были основным направлением атак, по крайней мере, с 2013 года), последний отчет Crowdstrike о глобальных угрозах идет дальше, отмечая, что 75% атак с целью получения доступа были без вредоносного ПО, и что "облачные" атаки (преднамеренное, а не оппортунистическое нацеливание на облачные сервисы для компрометации определенной функциональности) увеличилось на 110%. Microsoft также отмечает, что около 4000 атак с использованием паролей в секунду нацелены конкретно на облачные идентификаторы, в то время как есть предположения сотрудников Google, что атаки с целью кражи сеансовых файлов cookie (и, следовательно, в обход MFA) происходят примерно с той же частотой, что и атаки с использованием паролей.
Если не обращать внимания на цифры, свидетельства взломов в глазах общественности говорят о том же. Такие группы угроз, как APT29 / Cozy Bear / The Dukes и Scattered Spider / 0ktapus, показывают, как злоумышленники активно нацеливаются на сервисы IdP, SaaS-приложения и SSO / OAuth для проведения громких атак против таких компаний, как Microsoft и Okta.
Облачные приложения и удостоверения - это новые возможности для злоумышленников. Из-за перехода к облачным сервисам они предлагают ту же ценность, что и традиционная атака, направленная на нарушение сетевого периметра через конечную точку. Во многих отношениях идентификация сама по себе является новым средством атаки. В отличие от других границ безопасности, таких как сеть или конечная точка, она также представляет собой гораздо меньшее препятствие с точки зрения существующих в настоящее время средств контроля для защиты этого нового периметра.
Атаки на основе идентификации раньше локализовывались на конечной точке или смежных "системах идентификации", таких как Active Directory. Целью злоумышленника было прорвать этот периметр и проникнуть внутрь организации. Теперь идентификация стала гораздо более рассредоточенной – это шлюз к экосистеме взаимосвязанных облачных приложений и сервисов, доступ к которым осуществляется через Интернет. Это значительно изменило масштаб задач, стоящих перед командами безопасности. В конце концов, гораздо сложнее остановить атаки с использованием учетных данных против 100 приложений SaaS, чем с помощью единой централизованной внешней конечной точки VPN / веб-почты прошлых лет.
В прошлом году Push Security выпустила матрицу методов SaaS-атак на GitHub (вдохновленную фреймворком MITRE ATT & CK, ориентированным в большей степени на конечные точки), которая демонстрирует, как злоумышленники могут атаковать бизнес, не затрагивая традиционные поверхности, такие как сеть или конечные точки.
Объединенные в цепочку эти методы позволяют злоумышленнику осуществить сквозную атаку в облаке.
Компания Push также опубликовала ряд сообщений в блоге, в которых рассказывается о том, как можно использовать эти методы – ниже приведены наиболее популярные методы:
Точно так же эти атаки в значительной степени обходят средства контроля, в которые вложены средства организаций. Инструменты EDR, используемые для защиты базовых операционных систем, здесь представлены минимально, поскольку доступ к этим приложениям осуществляется через браузер – все чаще рекламируемый как новая операционная система. Как обсуждалось здесь, защита идентификационных данных абсолютно необходима для защиты облачных сервисов. И значительную часть цепочки атак – например, попытки фишинга в целом, включая методы AiTM и BitB, предназначенные для обхода MFA, или совместное использование паролей между приложениями и сервисами, просто не покрываются средствами защиты конечных точек, журналами IdP или журналами SaaS отдельных приложений и сервисов.
Эти типы атак являются реальной проблемой для многих организаций прямо сейчас, потому что они проходят через трещины в существующих инструментах и службах безопасности.
Прежде чем углубляться в детали используемых методов атаки, давайте обсудим, почему эти атаки становятся все более распространенными.
Внедрение SaaS меняет структуру ИТ компании
Революция SaaS и рост, основанный на продуктах, оказали огромное влияние на структуру сетей компаний и на то, где находятся основные бизнес-системы и данные.Сегодня большинство организаций используют от десятков до сотен приложений SaaS для различных бизнес-функций. Некоторые из них полностью основаны на SaaS, без каких-либо традиционных сетей, о которых можно говорить, но большинство приняли гибридную модель со смесью локальных, облачных и SaaS-сервисов, составляющих основу используемых бизнес-приложений.
Основная часть внедрения SaaS ориентирована на пользователей, в отличие от централизованного управления ИТ, поскольку внедрение снизу вверх неотъемлемо от роста, ориентированного на продукт. Последние данные Push Security указывают на то, что только 1 из 5 приложений SaaS были санкционированы бизнесом. Большинство из них просто неизвестны и, следовательно, вообще не проверялись.
Облачные приложения и SaaS спроектированы так, чтобы быть взаимосвязанными, функционируя подобно закрытым сетям внутренних бизнес-приложений, которые вы, возможно, использовали в прошлом. Средством обеспечения такой взаимосвязи является идентификация.
Цифровые удостоверения становятся все более сложными, и их трудно защитить
Самая базовая форма идентификации - это учетная запись пользователя, созданная для сервисов, на которые вы подписываетесь, с именем пользователя / электронной почтой и паролем. Чтобы снизить риск захвата учетной записи и сложность управления постоянно растущим количеством учетных записей, организации используют услуги поставщиков удостоверений личности (IDPL) для централизации доступа к приложениям в рамках единой платформы и идентификации, используя такие протоколы, как единый вход (SSO) и OAuth для управления аутентификацией и авторизацией соответственно.Конкретный состав идентификатора может сильно различаться. В зависимости от приложения для одной учетной записи может быть задействовано несколько механизмов аутентификации – например, через SAML, учетные записи в социальных сетях (OIDC), а также имя пользователя и пароль. Хотя SAML требует, чтобы администраторы заранее настроили его для данного клиента приложения, пользователи могут зарегистрироваться в приложении с помощью OIDC, просто воспользовавшись функцией "войти с помощью Google".
Фактически это создает несколько удостоверений, привязанных к одной учетной записи, что может внести много путаницы и сложности – например, то, что администратор IdP удаляет эту учетную запись, не означает, что к приложению / учетной записи нельзя получить доступ с помощью одного из других созданных методов входа. Это может затруднить определение того, какие приложения используются и какие удостоверения существуют в организации.
Итак, на практике в конечном итоге можно получить комбинацию следующих действий:
- Поставщики идентификационных данных (в среднем по 3 на организацию) (например, Okta, Entra / Microsoft, Google)
- Приложения, действующие как платформа единого входа для подключенных приложений (например, Atlassian Access, Adobe Creative Cloud)
- Приложения SaaS, использующие различные протоколы аутентификации (SAML, OIDC) и авторизации (OAuth)
- Приложения SaaS с локальным именем пользователя и паролем
- Учетные данные и секреты хранятся в приложениях password manager и authenticator (которые могут находиться в браузерах, локальной ОС и приложениях сторонних производителей)
Затем, в зависимости от областей OAuth, утвержденных для данного приложения, разрешения и рабочие процессы в одном приложении могут влиять на другие приложения, где им разрешено взаимодействовать друг с другом.
Идентификация - это клей, который скрепляет эту экосистему. Однако средства контроля, существующие для защиты идентификации, имеют серьезные ограничения. Компании часто думают, что на всех их приложениях и удостоверениях внедрен MFA или все приложения поддерживают единый вход. Но реальность такова, что только 1/3 приложений на самом деле поддерживают единый вход (и многие из них только премиум-уровня со значительным повышением цен). Более того, около 60% уникальных идентификаторов (т. Е. Не использующих единый вход) не имеют зарегистрированного MFA.
Таким образом, в реальности существуют значительные пробелы в средствах контроля безопасности, защищающих облачные идентификаторы, в то время как идентификаторы и облачные приложения становятся все более распространенными.
Злоумышленники нацелены на уязвимости облачной идентификации
Злоумышленники принимают это к сведению. Согласно DBIR Verizon за 2024 год, 74% всех нарушений связаны с человеческим фактором, нацелены на скомпрометированные учетные записи пользователей из-за человеческой ошибки, злоупотребления привилегиями, использования скомпрометированных учетных данных или социальной инженерии.Хотя в этом нет ничего нового (некоторые описания идентификационных атак / фишинга были основным направлением атак, по крайней мере, с 2013 года), последний отчет Crowdstrike о глобальных угрозах идет дальше, отмечая, что 75% атак с целью получения доступа были без вредоносного ПО, и что "облачные" атаки (преднамеренное, а не оппортунистическое нацеливание на облачные сервисы для компрометации определенной функциональности) увеличилось на 110%. Microsoft также отмечает, что около 4000 атак с использованием паролей в секунду нацелены конкретно на облачные идентификаторы, в то время как есть предположения сотрудников Google, что атаки с целью кражи сеансовых файлов cookie (и, следовательно, в обход MFA) происходят примерно с той же частотой, что и атаки с использованием паролей.
Если не обращать внимания на цифры, свидетельства взломов в глазах общественности говорят о том же. Такие группы угроз, как APT29 / Cozy Bear / The Dukes и Scattered Spider / 0ktapus, показывают, как злоумышленники активно нацеливаются на сервисы IdP, SaaS-приложения и SSO / OAuth для проведения громких атак против таких компаний, как Microsoft и Okta.
Облачные приложения и удостоверения - это новые возможности для злоумышленников. Из-за перехода к облачным сервисам они предлагают ту же ценность, что и традиционная атака, направленная на нарушение сетевого периметра через конечную точку. Во многих отношениях идентификация сама по себе является новым средством атаки. В отличие от других границ безопасности, таких как сеть или конечная точка, она также представляет собой гораздо меньшее препятствие с точки зрения существующих в настоящее время средств контроля для защиты этого нового периметра.
Атаки на основе идентификации раньше локализовывались на конечной точке или смежных "системах идентификации", таких как Active Directory. Целью злоумышленника было прорвать этот периметр и проникнуть внутрь организации. Теперь идентификация стала гораздо более рассредоточенной – это шлюз к экосистеме взаимосвязанных облачных приложений и сервисов, доступ к которым осуществляется через Интернет. Это значительно изменило масштаб задач, стоящих перед командами безопасности. В конце концов, гораздо сложнее остановить атаки с использованием учетных данных против 100 приложений SaaS, чем с помощью единой централизованной внешней конечной точки VPN / веб-почты прошлых лет.
Облачные идентификаторы - это новый периметр
Кажется довольно очевидным, что облачные идентификаторы - это новый цифровой периметр. Это не будущее, это сейчас. Единственное, что еще предстоит определить, - это какие появятся наступательные методы и уловки и какой будет реакция отрасли, чтобы остановить их.| Эпоха безопасности | Современные методы | Реакция отрасли |
| Традиционный взлом периметра | Сканеры портов, vuln-сканеры, переполнение буфера, атаки на веб-приложения, взлом Wi-Fi, бэкдоры клиент / сервер | Брандмауэры, DMZ, управление исправлениями, безопасное кодирование, WPA, тестирование на проникновение |
| 2010-е Конечная точка - это новый периметр | Фишинг, макросы Office, ошибки формата файлов, эксплойты браузера, резидентные имплантаты памяти, фреймворки C2 | Защита конечных точек, EDR, SIEMS, объединение red teaming, поиск угроз |
| Облачные идентификаторы 2020-х годов - это новый периметр | ??? | ??? |
В прошлом году Push Security выпустила матрицу методов SaaS-атак на GitHub (вдохновленную фреймворком MITRE ATT & CK, ориентированным в большей степени на конечные точки), которая демонстрирует, как злоумышленники могут атаковать бизнес, не затрагивая традиционные поверхности, такие как сеть или конечные точки.
Объединенные в цепочку эти методы позволяют злоумышленнику осуществить сквозную атаку в облаке.
Компания Push также опубликовала ряд сообщений в блоге, в которых рассказывается о том, как можно использовать эти методы – ниже приведены наиболее популярные методы:
| Техника | Обзор |
| AiTM-фишинг | AiTM-фишинг использует специальный инструментарий для выполнения функций веб-прокси между жертвой и законным порталом входа в приложение, к которому у жертвы есть доступ, главным образом для того, чтобы упростить прохождение защиты MFA. Подключаясь в режиме реального времени к целевому порталу входа, злоумышленник получает доступ как к действительному паролю, так и к действительным сессионным файлам cookie, которые они могут украсть и использовать для взлома сеанса. После входа в систему пользователь-жертва увидит все реальные данные, которые он ожидал бы увидеть обычно (например, свои собственные электронные письма / файлы и т.д.), Поскольку это прокси-сервер реального приложения. Это снижает их шансы понять, что они были скомпрометированы, из-за аутентичного характера работы прокси-приложения. |
| IM фишинг | Приложения для обмена мгновенными сообщениями, такие как Teams и Slack, являются отличным способом для злоумышленников обойти более строгие меры защиты от фишинга по электронной почте в отношении вредоносных ссылок и вложений. Оперативность обмена мгновенными сообщениями в режиме реального времени делает его полезным средством для фишинговых атак, поскольку пользователи менее знакомы с этими приложениями в качестве средств доставки фишинговых атак. Используя мгновенные сообщения, можно подделывать пользователей / выдавать себя за других, использовать учетные записи ботов для создания правдоподобного диалога, злоупотреблять функцией предварительного просмотра ссылок и ретроспективно редактировать сообщения и учетные записи для удаления ваших следов. |
| SAMLjacking | SAMLjacking - это когда злоумышленник использует параметры конфигурации единого входа SAML для клиента SaaS, которым он управляет, чтобы перенаправлять пользователей на вредоносную ссылку по своему выбору в процессе аутентификации. Это может быть очень эффективным средством фишинга, поскольку исходный URL-адрес будет законным URL-адресом SaaS, и пользователи ожидают предоставления учетных данных. Его также можно использовать для перемещения в другую сторону, если учетная запись администратора SaaS-приложения скомпрометирована, путем изменения или включения SAML, указывая URL-адрес на фишинговую страницу с учетными данными, которая выглядит как законная служба аутентификации (например, Google или Microsoft) или использует прокси-сервер. Затем злоумышленник может нацеливаться на пользователей, отправляя арендатору кажущиеся законными ссылки на страницу входа в приложение, которая затем функционирует как атака через водопой. |
| Oktajacking | Злоумышленник может настроить свой собственный клиент Okta для использования в очень убедительных фишинговых атаках. Эта атака работает, потому что Okta пересылает учетные данные из учетных записей, привязанных к AD, своему собственному рекламному агенту, который работает в целевой сети. Затем Okta позволяет агенту сообщать им об успешном входе в систему или нет. Это позволяет злоумышленнику, скомпрометировавшему рекламного агента или способному эмулировать его, отслеживать учетные данные для входа пользователей Okta и предоставлять функциональность, подобную skeleton key, для аутентификации в Okta под именем любого пользователя, который им нравится. Это также можно использовать аналогично SAMLjacking для бокового перемещения - за исключением того, что вам не нужно перенаправлять на отдельный вредоносный домен. |
| Теневые рабочие процессы | Теневой рабочий процесс - это метод использования приложений автоматизации SaaS для обеспечения метода, подобного выполнению кода, для выполнения вредоносных действий из законного источника с использованием интеграции OAuth. Это может быть ежедневный экспорт файлов с общих облачных дисков, автоматическая пересылка и удаление электронных писем, клонирование мгновенных сообщений, экспорт пользовательских каталогов — в общем, все, что возможно с помощью API целевого приложения. |
Методы бессетевых атак в действии
Но нет ничего лучше, чем увидеть их в действии, чтобы понять, насколько эффективными могут быть эти методы. Итак, посмотрите клип ниже от Люка Дженнингса, вице-президента по исследованиям и разработкам в Push. В этом видео он рассказывает:- Первоначальный доступ с помощью фишинга AiTM с использованием EvilNoVNC, браузера в фишинг-фреймворке браузера (BitB), для взлома сеанса Okta пользователя
- Кража учетных данных из сеанса браузера и доступ к другим приложениям через единый вход Okta, настройка этих приложений для создания постоянного доступа и создание бэкдора для приложений
- Дальнейшая кража учетных данных других пользователей этих приложений в корпоративном клиенте путем злоупотребления логинами SAML и SWA
- Прямой доступ к конфиденциальным данным и функциям в скомпрометированных приложениях
Могли бы вы обнаружить эту атаку и отреагировать на нее?
После просмотра того, что возможно, важно спросить – могли бы вы обнаружить этот сценарий атаки и отреагировать на него?- Смогли бы вы обнаружить первоначальный фишинг AiTM?
- Сколько пользователей будет скомпрометировано в результате атаки SAMLjacking?
- Нашли бы вы все разные бэкдоры в нескольких приложениях SaaS?
- ... или просто сбросить пароль и токены MFA для учетной записи Okta?
- ... а как насчет паролей для всех приложений, отличных от SAML?
Точно так же эти атаки в значительной степени обходят средства контроля, в которые вложены средства организаций. Инструменты EDR, используемые для защиты базовых операционных систем, здесь представлены минимально, поскольку доступ к этим приложениям осуществляется через браузер – все чаще рекламируемый как новая операционная система. Как обсуждалось здесь, защита идентификационных данных абсолютно необходима для защиты облачных сервисов. И значительную часть цепочки атак – например, попытки фишинга в целом, включая методы AiTM и BitB, предназначенные для обхода MFA, или совместное использование паролей между приложениями и сервисами, просто не покрываются средствами защиты конечных точек, журналами IdP или журналами SaaS отдельных приложений и сервисов.
Эти типы атак являются реальной проблемой для многих организаций прямо сейчас, потому что они проходят через трещины в существующих инструментах и службах безопасности.
