Як зламати невиправлений сервер Exchange за допомогою фальшивого коду PowerShell

Трохи менше двох місяців тому з’явилася тривожна новина про помилку: у Microsoft Exchange було оголошено про пару вразливостей нульового дня.

Як ми радив у той час, ці вразливості, офіційно позначені CVE-2022-41040 та CVE-2022-41082:

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

Перша вразливість нагадувала неспокійну та широко поширену вразливість Діра в безпеці ProxyShell ще в серпні 2021 року, оскільки він покладався на небезпечну поведінку в функції автовизначення Exchange, описаний Microsoft як протокол, тобто «використовується клієнтами Outlook і EAS [Exchange ActiveSync] для пошуку та підключення до поштових скриньок в Exchange».

На щастя, помилка Autodiscover, яку міг використати під час атаки ProxyShell будь-який віддалений користувач, незалежно від того, увійшов він чи ні, було виправлено більше року тому.

На жаль, патчі ProxyShell не зробили достатньо, щоб закрити експлойт для автентифікованих користувачів, що призвело до нового CVE-2022-40140 нульового дня, який незабаром було лаконічно, хоча й оманливо, охрестили ProxyNotShell.

Не такий небезпечний, але все ж небезпечний

Очевидно, що ProxyNotShell був далеко не таким небезпечним, як оригінальний ProxyShell, враховуючи те, що він вимагав так званого автентифікованого доступу, тому він не був відкритим для зловживань з боку будь-кого з будь-якого місця.

Але швидко з’ясувалося, що на багатьох серверах Exchange достатньо знати ім’я та пароль для входу будь-якого користувача, щоб пройти автентифікацію та здійснити цю атаку, навіть якщо цьому користувачеві потрібно буде використовувати двофакторну автентифікацію (2FA) для належного входу та доступу їх електронною поштою.

Як експерт Sophos Честер Вишневскі поклади це на час:

Це «проміжна автентифікаційна вразливість», якщо хочете так її назвати. Це змішане благословення. Це означає, що автоматизований сценарій Python не може просто сканувати весь Інтернет і потенційно використовувати кожен сервер Exchange у світі за лічені хвилини чи години, як ми бачили з ProxyLogon і ProxyShell у 2021 році. […]

Вам потрібен пароль, але, на жаль, знайти одну дійсну комбінацію адреси електронної пошти та пароля на будь-якому заданому сервері Exchange, мабуть, неважко. Можливо, досі вас не зловживали, тому що для успішного входу в Outlook Web Access [OWA] потрібен їхній маркер FIDO, або їхній автентифікатор, або будь-який другий фактор, який ви можете використовувати.

Але для цієї атаки не потрібен другий фактор. […] Просто отримання комбінації імені користувача та пароля є досить низьким бар’єром.

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

Але ми були розчаровані, виявивши, що, очевидно, було надійне виправлення складніше, ніж очікувалося, і жовтень прийшов і пішов з ProxyNotShell, усунуто лише обхідними шляхами, а не належними виправленнями.

Навіть листопадовий патч-вівторок безпосередньо не надав необхідних виправлень, хоча патчі все ж таки вийшов у той самий день як частину спеціального оновлення безпеки для Exchange, яке можна отримати та встановити окремо:

Розкрито підтвердження концепції

Тепер, коли пил влягся і всі встигли виправити свої сервери Exchange (принаймні ті, про які вони не забули), дослідники Zero Day Initiative (ZDI), яким ці вразливості спочатку були відповідально розкриті для подання Microsoft, пояснили як можна використовувати помилки.

Погана новина, залежно від вашої думки щодо відкритого розкриття експлойтів, полягає в тому, що команда ZDI тепер фактично надала доказ концепції (PoC), що пояснює, як атакувати сервери Exchange.

Доброю новиною, звичайно, є те, що:

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

Як це працює?

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

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

Пояснення, безумовно, є складним і досить технічним, і веде вас вперед через довгу серію кроків для досягнення дистанційного виконання коду (RCE) наприкінці.

У надії допомогти вам легше стежити за деталями високого рівня, якщо ви вирішите прочитати звіт ZDI, ось, сподіваюся, не надто спрощене резюме з кроками, переліченими в зворотному порядку…

…так що ви заздалегідь знатимете, чому історія має такий напрямок:

• КРОК 4. Дистанційно змусьте Exchange створити екземпляр об’єкта .NET за вашим вибором із параметром ініціалізації за вашим вибором.

У сучасному кодуванні ан екземпляр об'єкта це жаргонне слово для виділеної частини пам’яті, автоматично ініціалізованої даними та ресурсами, які будуть потрібні під час використання, і прив’язана до певного набору функцій, які можуть з нею працювати. (Виконати екземпляр це просто модне слово для створювати.)

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

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

Зазвичай вам потрібно передати один або кілька параметрів як аргументи конструктору, щоб вказати, як ви хочете, щоб об’єкт був налаштований під час його запуску.

Простіше кажучи, якщо ви створюєте екземпляр, скажімо, a TextString об’єкт (ми придумуємо ці назви, але ви зрозуміли), використовуючи параметр, який сам є текстовим рядком, наприклад example.com:8888...

…ймовірно, ви отримаєте буфер пам’яті, виділений для зберігання вашого тексту, ініціалізований таким чином, щоб він містив те саме значення, яке ви передали, а саме необроблений текст example.com:8888.

У цьому контексті текстовий рядок, переданий як дані до конструктора об’єктів, не створює одразу жодної очевидної загрози кібербезпеці, коли ви запускаєте конструктор віддалено, окрім можливої ​​відмови в обслуговуванні (DoS) через неодноразове запитування все більших і більших рядків для спробуйте виснажити пам'ять.

Але якби ви створили екземпляр, скажімо, a ConnectedTCPClient об'єкт, використовуючи той самий параметр текстового рядка example.com:8888, у вас може виникнути буфер пам’яті, готовий для зберігання тимчасових даних, а також мережевий сокет, виділений операційною системою, який готовий обмінюватися даними із сервером example.com через порт TCP 8888.

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

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

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

Звичайно, атака настільки проста, щойно ви досягнете останнього етапу, чого ви не повинні бути в змозі зробити, оскільки Exchange має суворий білий список, який не дозволяє вам вибирати будь-який старий об’єкт для створення екземпляра.

Теоретично лише безпечні об’єкти або об’єкти з низьким рівнем ризику можна створювати дистанційно за допомогою PowerShell, щоб створити екземпляр нашого уявного TextString вище або a SimpleIntegerValue, можна вважати прийнятним, тоді як a ConnectedTCPClient або RunCmdAndReadOutput точно не буде.

Але дослідники ZDI помітили, що перед тим, як запустити останній крок, вони могли зробити це:

• КРОК 3. Дистанційно змусьте Exchange подумати, що об’єкт із низьким рівнем ризику, який пройшов перевірку безпеки, насправді є іншим об’єктом на ваш вибір.

Незважаючи на це, можна очікувати, що Exchange запобігатиме віддаленому створенню навіть об’єктів із низьким рівнем ризику, щоб ще більше мінімізувати загрозу.

Але дослідники виявили, що вони можуть:

• КРОК 2. Дистанційно змусьте Exchange використовувати його PowerShell Remoting функція для створення об’єкта на основі параметрів ініціалізації, керованих ззовні.

І це стало можливим завдяки отвору, схожому на ProxyShell, який був лише напівзаправлений:

• КРОК 1. Віддалено змусьте Exchange прийняти та обробити веб-запит із кодом, запакувавши дійсний username:password у запиті.

Навіть якщо користувач, вказаний у запиті, насправді не ввійшов у систему, і йому потрібно буде пройти якийсь процес 2FA, щоб отримати доступ до своєї власної поштової скриньки, зловмисник, який знав їх username:password комбінація матиме достатньо інформації для автентифікації, щоб обманом змусити Exchange прийняти веб-з’єднання, яке можна використати для запуску ланцюжка атак, описаного в кроках 2–4 вище.

Грубо кажучи, будь-який дійсний username:password комбінація підійде, враховуючи, що «автентифікація» була потрібна просто для того, щоб запобігти відхиленню Exchange запиту HTTP.

Що ж робити?

Зауважте, що ця атака працює лише:

• Якщо у вас є локальні сервери Exchange. Корпорація Майкрософт стверджує, що швидко заблокувала власні хмарні служби, тому це не вплинуло на Exchange Online. Переконайтеся, що ви знати, де знаходяться ваші сервери Exchange. Навіть якщо ви зараз використовуєте Exchange Online, у вас все ще можуть працювати локальні сервери, можливо, помилково залишені в процесі міграції.
• Якщо ваші сервери не виправлені. Переконайтеся, що у вас є застосував оновлення програмного забезпечення Exchange від 2022-11-08 до закрийте вразливі місця що вимагає експлойт.
• Якщо ваші сервери все ще приймають базову автентифікацію, також відому як застаріла автентифікація. Переконайтеся, що у вас є заблокував усі аспекти застарілої автентифікації тому ваші сервери не приймуть username:password заголовки, згадані вище, і в першу чергу не прийматиме ризиковані запити протоколу автовизначення. Це зупиняє нападників обманом змусити сервер прийняти їхні трюки створення екземплярів об’єкта, навіть якщо цей сервер не виправлено.

Ти можеш відслідковувати наших офіційних порад із запобігання, виправлення та реагування, а клієнти Sophos можуть відстежувати назви виявлення загроз, які використовуються нашими продуктами, через стрічку Twitter Sophos X-Ops (@SophosXOps).

Опубліковано нову інформацію щодо CVE-2022-41040 і CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) Листопад 21, 2022

---

ДІЗНАЙТЕСЯ БІЛЬШЕ ПРО АВТЕНТИФІКАЦІЮ EXCHANGE ТА OAUTH2

З Полом Дакліном і Честером Вишневським
Вступна та кінцева музика Едіт Мадж.

---