ЗЛОУМЫШЛЕННИКИ МОГУТ “ВОЙТИ С ПОМОЩЬЮ MICROSOFT” В AZURE ACTIVE DIRECTORY ИЗ-ЗА УЯЗВИМОСТИ NOAUTH
20 июня 2023 года компания Descope опубликовала исследование, в котором подробно описано, как сочетание недостатков в Azure Active Directory и плохо интегрированных сторонних приложений под названием «nOAuth» может привести к полному захвату учетных записей. nOAuth – это последняя из большого количества уязвимостей и архитектурных недостатков в программном обеспечении и системах Microsoft, таких как Active Directory, которые могут создавать опасность для организаций.
Хотя Microsoft уже отреагировала на уязвимость, пока разработчики не внесут изменений в код своих приложений, единственный способ избежать уязвимости зависит от наличия у организаций мощных средств защиты идентификационных данных и защиты привилегированных учетных записей от злоупотреблений со стороны недобросовестных администраторов.
Архитектурные ограничения экосистемы идентификации Microsoft продолжают существовать
Архитектурные недостатки Active Directory и Azure Active Directory (Azure AD) были хорошо задокументированы на протяжении многих лет. Эти структурные слабости и уязвимости стали современной поверхностью для атак злоумышленников. Тем не менее Active Directory и Azure Active Directory продолжают служить инфраструктурой идентификации для многих организаций. Согласно отчету Frost & Sullivan, 90% компаний из списка Fortune 1000 используют Active Directory.
Azure AD – это возможность для Microsoft начать с чистого листа и создать современное, безопасное решение для управления идентификацией и доступом (IAM). Однако постоянные уязвимости в его инфраструктуре идентификации могут сделать организации уязвимыми для взломов. Несмотря на то, что Microsoft недавно изменила название Azure AD на Entra ID, проблемы с безопасностью остаются.
nOAuth показывает, что обнаруженные недостатки интеграции Azure AD с Active Directory и уязвимости, связанные с кражей сеансов, переносят проблему безопасности идентификационных данных в облако. Следует отметить, что ответ Microsoft на nOAuth от 20 июня был предоставлен более чем через два месяца после того, как компания узнала об уязвимости. Это вызывает два основных вопроса, которые организации должны рассмотреть:
- Сколько еще существует подобных уязвимостей, которые еще предстоит обнаружить?
- Действительно ли вы можете позволить себе ждать два месяца, чтобы уменьшить риск полного захвата учетных записей?
Такое последовательное обнаружение уязвимостей в сочетании с архитектурными ограничениями Active Directory и Azure AD требует комплексной защиты идентификационных данных, которая должна быть:
- Абстрагированной от поставщика идентификационных данных: У человека или рабочей нагрузки может быть много учетных записей, распределенных между различными поставщиками идентификационных данных. Поэтому централизованная видимость, обнаружение и предотвращение – единственный способ остановить атаки на основе учетных данных.
- Корреляция и контекстуализация с остальными событиями в стеке безопасности: Только объединяя данные конечных точек, идентификационных данных и телеметрии третьих сторон, вы сможете понять всю цепочку атак и обнаружить всю активность злоумышленника, снизив при этом сложность и количество инструментов.
- Независимой от обнаружения «известных уязвимостей»: Защита идентификационных данных должна объединять обнаружение уязвимостей на основе CVE с поведенческим анализом в реальном времени для выявления активности злоумышленника.
- Распространять гибридную защиту идентификационных данных от локальной сети до облака: Это включает в себя проверку прав доступа к учетным данным для смягчения последствий нарушения, если оно произойдет.
- Мониторинг приложений на предмет неправильных конфигураций: Типичные подходы к безопасности идентификационных данных сосредоточены на анализе поставщиков идентификационных данных на предмет уязвимостей. Хотя поставщики идентификационных данных должны предоставлять советы по внедрению лучших практик, неправильная настройка приложения может оставить вас уязвимыми.
Что такое nOAuth?
Descope детально описывает уязвимость в доверии между поставщиком идентификационных данных (в данном случае Azure AD) и доверяющей стороной (приложением). Название «nOAuth» намекает на протокол аутентификации «OAuth», в соответствии с которым поставщик идентификационных данных выдает приложению токен, содержащий информацию о пользователе и данные, которые он желает предоставить приложению. Эти данные называются «запросами».
Независимо от того, знакомы ли вы с OAuth или нет, есть большая вероятность, что вы его использовали ранее! Вспомните все случаи, когда вы регистрировались на сервисе, где у вас была возможность «Войти с помощью Google», «Войти с помощью Microsoft» или «Войти с помощью Facebook». Вы видели такой экран?
После нажатия на одну из этих опций вы аутентифицируетесь у поставщика идентификационных данных, а затем вас спрашивают, какие данные вы хотите предоставить приложению: имя, адрес, пол и так далее. После выбора настроек поставщик идентификационных данных выдает токен, который приложение считывает и получает ваши данные:
- Кто вы, что важно для создания профиля в приложении. Например, если вы создаете учетную запись в магазине, вам нужно, чтобы он помнил ваши любимые товары, чтобы предоставлять рекомендации и т. д.
- Какие данные приложение может запросить у поставщика идентификационных данных. Например, вы можете хотеть, чтобы магазин знал ваш адрес (чтобы отправлять ваши покупки), но не знал вашу дату рождения.
Возвращаясь к nOAuth, именно манипуляция запросом «кто вы» используется злоумышленниками. Множество приложений, реализующих OAuth, неправильно используют «email» как идентификатор пользователя, вместо уникального значения, такого как идентификатор объекта (OID). Это означает, что если злоумышленник может создать запрос с email-адресом жертвы, он получает полный доступ к ее учетной записи, не зная пароль или не проходя многофакторную аутентификацию (MFA).
В сценарии Azure AD это гораздо более важно, так как кто угодно может создать такой запрос:
Команда Descope создала мощную демонстрацию эффективности этого метода.
Давайте четко определим, в чем заключается проблема с nOAuth и Microsoft:
- Корпорация Microsoft позволяет любому, у кого есть учетная запись Azure AD, изменять атрибут электронной почты учетной записи на любой адрес электронной почты — независимо от того, подтвердил ли этот пользователь, что он «владеет» доменом или нет. Например, даже если вы являетесь владельцем домена mycompany.com, злоумышленник может изменить учетную запись пользователя в своем клиенте Azure AD на адрес mycompany.com.
- Когда разработчики создавали интеграцию OAuth с Azure AD, они решили использовать электронную почту в качестве идентификатора пользователя, вместо постоянного значения, такого как OID.
Ответ Microsoft на nOAuth
20 июня компания Microsoft выпустила инструкцию о том, как управлять уязвимостью nOAuth:
- Чтобы уменьшить риск для существующих приложений, вы можете модифицировать API authenticationBehaviors (который в настоящее время находится в бета-версии), чтобы отклонять непроверенные запросы на подтверждение электронной почты.
- Когда разработчики будут готовы обновить свой код и перевести пользователей на постоянный идентификатор, например, OID, они могут использовать требование «xms_edov», чтобы убедиться, что адрес электронной почты проверен в Azure AD перед изменением идентификатора пользователя.
Осведомленность разработчиков относительно безопасности
Разработчики должны придерживаться лучших практик и рекомендаций по защите современных протоколов идентификации, таких как OAuth. Это напоминание о том, что обучение по безопасности, проводимое организациями, должно охватывать не только нетехнический персонал. Разработчики, инженеры инфраструктуры, архитекторы и сотрудники службы поддержки несут ответственность за создание и поддержку критически важных для бизнеса приложений следующего поколения. Они должны осознавать последствия того, как слабая реализация маршрута аутентификации в приложении может подорвать значительную часть работы, которую команды IAM, возможно, выполнили для обеспечения защиты самого поставщика идентификационных данных.
Несмотря на ответ, проблема остается
На 13 июля все еще можно создать бесплатную учетную запись Azure AD и привязать любой адрес электронной почты к учетной записи пользователя без подтверждения права собственности на домен. Поэтому, пока разработчики не обновят свой код, чтобы использовать постоянные значения в качестве основного идентификатора пользователя, все, что могут сделать организации, — это снизить риск.
Этап смягчения последствий, который предполагает использование бета-версии Microsoft Graph API, уязвим к модификации злоумышленником из Azure AD.
Поэтому решением этой проблемы является безопасное переключение приложений с идентификатора, основанного на электронной почте, что требует от разработчиков обновления кода в их собственных приложениях. То же самое касается разработчиков, работающих с третьими сторонами, предоставляющими критически важные для бизнеса современные программы. Внести эти изменения также не так просто, как может показаться, — они могут повлиять на дальнейшую работу приложений, что может увеличить время, необходимое для внедрения изменений.
Теперь возникает вопрос: «Какие меры вы можете временно принять, чтобы уменьшить риск несанкционированных администраторов и проактивно защититься от будущих уязвимостей в вашей гибридной экосистеме идентификации?».
Меры по противодействию атакам на основе идентификационных данных в AD и Azure AD
CrowdStrike Falcon Identity Threat Protection, полностью интегрированный с платформой CrowdStrike Falcon, предоставляет организациям комплексную защиту от атак на основе идентификационных данных. Он выявляет атаки и предотвращает боковое перемещение, останавливая нарушения, связанные с уязвимостями в Active Directory и Azure AD. В контексте nOAuth это позволяет выявлять действия несанкционированных администраторов, которые могут свидетельствовать о намерениях использовать nOAuth.
Проактивное выявление приложений Azure AD, допускающих непроверенные запросы на электронную почту
Microsoft предлагает решить эту проблему, установив значение «removeUnverifiedEmailClaim» в true с помощью GraphAPI. Falcon Cloud Security имеет сотни индикаторов неправильных конфигураций (IOM), включая один, который может проактивно выявлять программы с значением false, что позволяет клиентам быстро выявлять и снижать риск эксплуатации.
Соотношение событий аудита и доступа
Изменение адреса электронной почты является совершенно законной операцией. Однако, если оно связано с другими телеметрическими данными, происходящими в то же время, такими как повышение привилегий и аномальный доступ к ресурсам, это может указывать на действия несанкционированного администратора. CrowdStrike предоставляет вам такую видимость, преобразуя опыт охоты на угрозы для команд SOC и IAM, объединяя все события в цепочке атак в единое представление инцидента:
Обнаруживайте и предотвращайте гибридное боковое перемещение
Несмотря на то, что многие организации используют Azure AD для условного доступа и единого входа (SSO), Active Directory часто является «настоящим» поставщиком идентификационных данных. Объекты пользователей создаются и изменяются в локальном Active Directory, а затем синхронизируются с облаком через Azure AD Connect. Таким образом, злоумышленник в вашей сети с достаточными разрешениями в Active Directory может создавать учетные записи и изменять адреса электронной почты, которые реплицируются в Azure AD, и все это без административного доступа к порталу Azure AD. Они также могут использовать известные уязвимости в AD, такие как атаки Overpass-the-Hash, чтобы перемещаться в Azure AD без проверки подлинности.
Отслеживайте необычную активность
Построение базовых линий поведения для всех ваших учетных записей является критически важным, но анализ этих отдельных событий изолированно часто приводит к ложным срабатываниям. Например, если пользователь, который долгое время работает в организации, получает доступ к приложению после изменения роли, как вы можете определить разницу между аномальной и злонамеренной активностью?
Поэтому важно сочетать аномальные события с другой телеметрией, которую вы имеете о пользователе, чтобы определить, является ли действие злонамеренным, а не просто аномальным. В этом примере мы показываем географические аномалии, происходящие параллельно с аномальным доступом к приложениям:
Определение и мониторинг привилегированных учетных записей
Привилегированные учетные записи часто определяются как те, которые имеют административные привилегии в хранилище учетных данных, например, администратор домена в Active Directory или глобальный администратор в Azure AD. Однако пользователь, который является глобальным администратором в вашей CRM, также является привилегированным, и воздействие на ваш бизнес, если эту учетную запись скомпрометировали, может быть разрушительным. CrowdStrike позволяет вам сопоставить бизнес-привилегии с потенциальными последствиями для бизнеса, если определенная учетная запись будет скомпрометирована. Это повышает оценку риска, связанную с этими учетными записями, что означает, что обнаружение получает более высокий приоритет, стимулируя команды SOC и IAM определить порядок проверки и устранения нарушений.
Сопоставление журналов аудита приложения и хранилища учетных данных
Сопоставление журналов аудита между поставщиком идентификационных данных и приложением может быть эффективным способом обнаружения злонамеренной активности. Например, событие аутентификации в поставщике идентификационных данных, которое не совпадает с событием доступа в журналах приложения, может свидетельствовать о том, что учетная запись пользователя была скомпрометирована.
Сочетая возможности CrowdStrike Falcon Identity Threat Protection и Falcon LogScale, вы можете создать запланированный запрос, который будет сопоставлять события входа между поставщиком идентификационных данных и журналами аудита приложений, чтобы выявлять аномалии.
Проактивное обнаружение уязвимых программ
Выявление слабых мест и активов, которые нужно защищать, является критически важным шагом в обеспечении безопасности вашей организации. Однако процесс обнаружения уязвимых программ может быть сложным. Внешние инструменты мониторинга поверхности атаки, такие как CrowdStrike Falcon® Surface, имеют возможность идентифицировать программы, такие как те, которые используют OAuth или OIDC, чтобы вы знали, какие программы нужно проверить.
Решения Falcon Identity Protection от CrowdStrike идентифицирует риски, а также обнаруживает и предотвращает боковое перемещение злоумышленников из Active Directory в Azure AD.
Внедрение надежных и комплексных решений по безопасности IT-инфраструктуры способствует эффективной защите от известных и неизвестных уязвимостей в программном обеспечении. iIT Distribution является официальным дистрибьютором решений компании CrowdStrike и предоставляет квалифицированную поддержку и надежное сопровождение при внедрении решений в инфраструктуру заказчиков.
