Події 0
Ua
En
Події 0
Результат пошуку:
Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth- image 1

Зловмисники можуть “Log in with 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, nOAuth описує вразливість у довірі між постачальником ідентифікаційних даних (в цьому випадку Azure AD) і стороною, що довіряє (додатком). Назва “nOAuth” є натяком на протокол авторизації “OAuth”, згідно з яким постачальник ідентифікаційних даних видає додатку токен, що містить інформацію про користувача та дані, якими він бажає поділитися з додатком. Ці дані називаються “запити”.

Незалежно від того, знайомі ви з OAuth чи ні, існує велика ймовірність того, що ви використовували його раніше! Згадайте всі випадки, коли ви реєструвалися на сервісі, де у вас була можливість “Увійдіть за допомогою Google”, “Увійдіть за допомогою Microsoft” або “Увійдіть за допомогою Facebook”. Чи виглядає такий екран знайомим?

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 21

Після натискання однієї з цих опцій ви автентифікуєтесь у постачальника ідентифікаційних даних, а потім вас запитують, чим ви хочете поділитися з додатком: ім’ям, адресою, статтю тощо. Після вибору налаштувань постачальник ідентифікаційних даних видає токен, який додаток зчитує та отримує ваші дані:

  • Хто ви є, що важливо для створення профілю в додатку. Наприклад, якщо ви створюєте обліковий запис у продуктовому магазині, ви хочете, щоб він запам’ятав ваші улюблені товари, щоб створювати рекомендації тощо.
  • Які дані програма може запитувати у постачальника ідентифікаційних даних. Наприклад, ви можете захотіти, щоб продуктовий магазин знав вашу адресу (щоб він знав, куди відправляти ваші покупки), але ви не хочете, щоб він знав вашу дату народження.

Повертаючись до nOAuth, саме запитом “хто ви є” маніпулюють зловмисники. Багато додатків, які реалізують OAuth, некоректно використовують “email” як ідентифікатор користувача, на противагу незмінному значенню, такому як ідентифікатор об’єкта (OID). Це означає, що якщо зловмисник може згенерувати запит з адресою електронної пошти жертви, він отримує повний доступ до її облікового запису, не знаючи пароля або не проходячи багатофакторну автентифікацію (MFA).

У сценарії Azure AD це набагато важливіше, оскільки будь-хто може створити такий запит:

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 23

Команда Descope створила потужну демонстрацію того, наскільки це дієвий метод.

Давайте чітко визначимо, в чому полягає проблема з nOAuth та 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 і прив’язати будь-яку адресу електронної пошти до облікового запису користувача без підтвердження права власності на домен. Тому, поки розробники не оновлять свій код, щоб використовувати незмінні значення в якості основного ідентифікатора користувача, все, що можуть зробити організації, – це зменшити ризик.

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 25

Етап пом’якшення наслідків, який передбачає використання бета-версії Microsoft Graph API, вразливий до модифікації зловмисником з Azure AD.

Тому розв’язанням цієї проблеми є безпечне переведення додатків з ідентифікатора на основі електронної пошти, що вимагає від розробників оновлення коду у власних додатках. Те саме стосується розробників, які працюють на третіх осіб, що надають критичні для бізнесу сучасні програми. Внести ці зміни також не так просто, як здається – вони можуть мати вплив на подальшу роботу додатків, що може збільшити час, необхідний для впровадження змін.

Тепер постає питання: “Які контрзаходи ви можете вжити тимчасово, щоб зменшити ризик неавторизованого адміністратора та проактивно захиститися від майбутніх вразливостей у вашій екосистемі гібридних ідентифікаторів?”.

Заходи протидії атакам на основі ідентифікаційних даних в AD і Azure AD

CrowdStrike Falcon Identity Threat Protection, повністю інтегрований з платформою CrowdStrike Falcon, надає організаціям комплексний захист від атак на основі ідентифікаційних даних. Він виявляє атаки і запобігає бічному переміщенню, зупиняючи порушення, пов’язані з вразливостями в Active Directory і Azure AD. У контексті nOAuth це дозволяє виявляти дії неавторизованих адміністраторів, які можуть свідчити про наміри використати nOAuth.

Проактивне виявлення додатків AzureAD, які допускають неперевірені запити на електронну пошту

Microsoft пропонує вирішити цю проблему, встановивши значення “removeUnverifiedEmailClaim” на true за допомогою GraphAPI. Falcon Cloud Security має сотні індикаторів неправильних конфігурацій (IOM), в тому числі один, який може проактивно виявляти програми зі значенням false, що дозволяє клієнтам швидко виявляти та зменшувати ризик експлуатації.

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 27

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 29

Співвідношення подій аудиту та доступу

Зміна адреси електронної пошти є цілком законною операцією. Однак, якщо вона співвідноситься з іншими телеметричними даними, що відбуваються в той самий час, такими як підвищення привілеїв і аномальний доступ до ресурсів, це може вказувати на дії неавторизованого адміністратора. CrowdStrike надає вам таку видимість, трансформуючи досвід полювання на загрози для команд SOC і IAM, пов’язуючи всі події в ланцюжку атак в єдине уявлення про інцидент:

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 31

Виявляйте та запобігайте гібридному бічному переміщенню

Хоча багато організацій використовують Azure AD для умовного доступу та єдиного входу (SSO), Active Directory часто є “справжнім” постачальником ідентифікаційних даних. Об’єкти користувачів створюються та змінюються в локальній Active Directory, а потім синхронізуються з хмарою через Azure AD Connect. Таким чином, зловмисник у вашій мережі з достатніми дозволами в Active Directory може створювати облікові записи та змінювати адреси електронної пошти, які реплікуються в Azure AD, і все це без адміністративного доступу до порталу Azure AD. Вони також можуть використовувати відомі вразливості в AD, такі як атаки Overpass-the-Hash, щоб переміщатися в Azure AD без перевірки автентичності.

Відстежуйте незвичну активність

Побудова базових ліній поведінки для всіх ваших облікових записів є критично важливою, але аналіз цих окремих подій ізольовано часто призводить до помилкових спрацьовувань. Наприклад, якщо користувач, який тривалий час працює в організації, отримує доступ до застосунку через зміну ролі, як ви можете визначити різницю між аномальною та зловмисною активністю?

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 33

Тому важливо поєднувати аномальні події з іншою телеметрією, яку ви маєте про користувача, щоб визначити, чи є дія зловмисною, а не просто аномальною. У цьому прикладі ми показуємо географічні аномалії, що відбуваються разом з аномальним доступом до додатків:

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 35

Визначення та моніторинг привілейованих облікових записів

Привілейовані облікові записи часто визначають як ті, що мають адміністративні привілеї в сховищі облікових даних – наприклад, адміністратор домену в Active Directory або глобальний адміністратор в Azure AD. Однак користувач, який є глобальним адміністратором у вашій CRM, також є привілейованим, і вплив на ваш бізнес, якщо цей обліковий запис буде скомпрометовано, може бути руйнівним. CrowdStrike дозволяє вам зіставити бізнес-привілеї з потенційним впливом на бізнес, якщо певний обліковий запис буде скомпрометовано. Це підвищує оцінку ризику, пов’язану з цими обліковими записами, що означає, що виявлення отримують вищий пріоритет, спонукаючи команди SOC та IAM визначати черговість перевірки та усунення порушень.

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 37

Співставлення логів аудиту програми та сховища облікових даних

Співставлення журналів аудиту між постачальником ідентифікаційних даних і додатком може бути ефективним способом виявлення зловмисної активності. Наприклад, подія автентифікації у постачальника ідентифікаційних даних, яка не збігається з подією доступу в журналах додатка, може свідчити про те, що обліковий запис користувача було скомпрометовано.

Поєднуючи можливості CrowdStrike Falcon Identity Threat Protection і Falcon LogScale, ви можете створити запланований запит, який буде співвідносити події входу між постачальником ідентифікаційних даних і логами аудиту додатків, щоб виявити аномалії.

Зловмисники можуть “Log in with Microsoft” в Azure Active Directory через вразливість nOAuth - зображення 39

Проактивне виявлення вразливих програм

Виявлення слабких місць та активів, які потрібно захистити, є критично важливим кроком у захисті вашої організації. Однак процес виявлення вразливих програм може бути складним. Зовнішні інструменти моніторингу поверхні атаки, такі як CrowdStrike Falcon® Surface, мають можливість ідентифікувати програми, наприклад, ті, що використовують OAuth або OIDC, щоб ви знали, які програми потрібно перевірити.

Дізнатися більше про CrowdStrike

Рішення Falcon Identity Protection від CrowdStrike ідентифікує ризики, а також виявляє та запобігає бічному переміщенню зловмисників з Active Directory до Azure AD.

Впровадження надійних та комплексних рішень для безпеки ІТ-інфраструктури сприятиме ефективному захисту від відомих та невідомих вразливостей у програмному забезпеченні. iIT Distribution є офіційним дистриб’ютором рішень компанії CrowdStrike та забезпечує кваліфіковану підтримку й надійний супровід під час впровадження рішень у інфраструктуру замовників.

НОВИНИ

Актуальні новини на вашу тему

Усі новини
Усі новини