S3 Ep102.5: Помилки обміну “ProxyNotShell” – говорить експерт [Аудіо + текст]

Мітка часу: 1 жовтня 2022 р., 10:05
Вихідний вузол: 1712650

by
Пол Даклін

НЕ ПАНІКУЙТЕ... АЛЕ БУДЬТЕ ГОТОВІ ДІЯТИ

З Полом Дакліном і Честером Вишневським

Вступна та кінцева музика Едіт Мадж.

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

Ви можете послухати нас на Soundcloud, Apple Podcasts, Підкасти Google, Spotify, брошюровщик і скрізь, де можна знайти хороші подкасти. Або просто скиньте URL-адреса нашого каналу RSS у ваш улюблений подкечер.

ПРОЧИТАЙТЕ СКРИПТ

[МУЗИЧНИЙ МОДЕМ]

КАЧКА.  Привіт всім.

Ласкаво просимо до ще одного спеціального міні-серіалу подкасту Naked Security.

Я Пол Даклін, до мене знову приєднався мій друг і колега Честер Вишневскі.

Привіт, Чет.

ЧЕТ.  [ПОРОЖНИЙ АВСТРАЛІЙСЬКИЙ АКЦЕНТ] Привіт, Дак.

КАЧКА.  Ну, Чет, я впевнений, що всі слухають. якщо вони слухають незабаром після виходу подкасту, знають, про що ми будемо говорити!

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

Наші друзі з продажів кажуть: «Ой, кінець місяця, кінець чверті, шалений час… але завтра всі отримають скидання до 0 доларів».

У ці вихідні для сисадмінів та ІТ-менеджерів цього не буде!

ЧЕТ.  Качка, я думаю, за безсмертними словами покійного Дугласа Адамса, "НЕ ПАНІКУЙТЕ" може бути в порядку.

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

Але якщо ви використовуєте Exchange локально…

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

КАЧКА.  Отже, це CVE-2022-41040 та CVE-2022-41042… це досить великий ковток.

Я бачив, як у Твіттері це називають ProxyNotShell, оскільки він має деякі подібності до ProxyShell вразливість, яка була великою історією трохи більше року тому,

Але, незважаючи на те, що він має такі подібності, це абсолютно нова пара експлойтів, які з’єднані разом, потенційно забезпечуючи віддалене виконання коду – це правильно?

ЧЕТ.  Ось як це звучить.

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

Здається, вони відповідально розкрили ці вразливості Ініціативі нульового дня [ZDI], яку проводить Trend Micro, для відповідального звітування про вразливості нульового дня.

І, звісно, ​​трохи більше трьох тижнів тому ZDI поділився всією цією розвідкою з Microsoft.

І причина того, що він виходить сьогодні, полягає в тому, що я думаю, що в’єтнамська група…

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

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

КАЧКА.  І, чесно кажучи, вони обережно сказали, «Ми не збираємося розкривати, як саме використовувати ці вразливості, але ми збираємося дати вам засоби пом’якшення, які ми вважаємо ефективними».

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

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

ЧЕТ.  І це дійсно важливе зауваження, Дак, що ти сказав, «Хтось, хто може читати електронну пошту на вашому сервері».

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

КАЧКА.  Зараз ми не знаємо, які саме облікові дані їм потрібні, тому що на момент запису [2022-09-30T23:00:00Z] все ще залишається в основному секретним.

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

Однак після введення пароля, якщо була двофакторна автентифікація [2FA], перша помилка (та, яка відкриває двері) запускається *між точкою, в якій надається пароль, і точкою, в якій будуть коди 2FA. запитуваний*.

Тож вам потрібен пароль, але вам не потрібен код 2FA…

ЧЕТ.  Звучить так, ніби це «вразливість проміжної автентифікації», якщо ви хочете це так назвати.

Це змішане благословення.

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

Протягом останніх 18 місяців ми спостерігали повернення черв’яків, що завдало шкоди багатьом організаціям.

КАЧКА.  «Вормаг»?

ЧЕТ.  Вормаж, так! [СМІЄТЬСЯ]

КАЧКА.  Це слово?

Ну а якщо ні, то зараз!

Мені це подобається… Я міг би позичити, Честер. [СМІЄТЬСЯ]

ЧЕТ.  Я думаю, що це помірно гельмінтозне, чи не так?

Вам потрібен пароль, але, на жаль, знайти одну дійсну комбінацію адреси електронної пошти та пароля на будь-якому заданому сервері Exchange, мабуть, неважко.

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

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

Але для цієї атаки не потрібен другий фактор.

Отже, лише отримання комбінації імені користувача та пароля є досить низьким бар’єром…

КАЧКА.  Тут є інша складність, чи не так?

А саме те, що хоча Керівництво Microsoft офіційно сказано, що клієнти Microsoft Exchange Online можуть відмовитися від Blue Alert, це небезпечно, лише якщо у вас є локальний Exchange…

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

ЧЕТ.  Точно!

Ми бачили це ще до ProxyLogin і ProxyShell.

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

Мовляв, хтось не перевірив список віртуальних машин, запущених на їхньому сервері VMware, щоб помітити, що їхні міграційні сервери Exchange, які допомагали їм під час передачі даних між їхньою локальною мережею та хмарною мережею…

…насправді все ще були ввімкнені, увімкнені та доступні для Інтернету.

І що ще гірше, коли вони невідомі про їхню присутність, ще менше шансів, що їх виправлять.

Я маю на увазі, що організації, які мають Exchange, принаймні, ймовірно, докладуть усіх зусиль, щоб планувати їх обслуговування на регулярній основі.

Але коли ви не знаєте, що щось є у вашій мережі, «тому що ви забули», що дуже легко з віртуальними машинами, ви перебуваєте в ще гіршій ситуації, тому що ви, ймовірно, не застосовували оновлення Windows або оновлення Exchange.

КАЧКА.  І закон Мерфі говорить, що якщо ви дійсно покладаєтеся на цей сервер і не доглядаєте за ним належним чином, він вийде з ладу лише за день до того, як він вам дійсно знадобиться.

Але якщо ви не знаєте, що він є, і його можна використати на зло, ймовірність того, що він працюватиме роками і роками без будь-яких проблем, ймовірно, досить висока. [СМІЄТЬСЯ]

ЧЕТ.  Так, на жаль, це був мій досвід!

Це звучить безглуздо, але сканування власної мережі, щоб дізнатися, що у вас є, є те, що ми все одно рекомендуємо вам робити регулярно.

Але, звичайно, коли ви чуєте про такий бюлетень, якщо це продукт, який, як ви знаєте, використовували в минулому, як-от Microsoft Exchange, це вдалий час запустити цей внутрішній Сканування Nmap...

…і, ​​можливо, навіть увійти shodan.io і перевірте свої зовнішні служби, щоб переконатися, що всі ці речі вимкнено.

КАЧКА.  Тепер ми знаємо з власної відповіді Microsoft, що вони шалено біжать, щоб отримати виправлення.

Коли ці патчі з’являться, вам краще швидко їх застосувати, чи не так?

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

ЧЕТ.  Так, точно, Дак!

Навіть після того, як ви виправите, буде вікно часу, чи не так?

Я маю на увазі, що зазвичай Microsoft випускає свої виправлення у вівторок о 10.00:XNUMX за тихоокеанським часом.

Зараз у нас літній час, тож UTC-7… отже, приблизно о 17:00 UTC зазвичай Microsoft випускає виправлення, тож у більшості їхніх співробітників є цілий день, щоб відповісти на вхідні запити в Сіетлі. [Штаб-квартира Microsoft знаходиться в Белв’ю, Сіетл, штат Вашингтон.]

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

І знову, повертаючись до попередньої експлуатації Exchange із ProxyShell і ProxyLogon, ми часто виявляли, що навіть клієнти, які виправляли протягом трьох, чотирьох, п’яти днів…

…це, чесно кажучи, досить швидко для сервера Exchange, їх дуже важко виправити, потрібно багато тестувати, щоб переконатися, що це надійно, перш ніж порушити роботу серверів електронної пошти.

Цього часу було достатньо для цих серверів веб-оболонки, криптомінератори, всі види бекдори встановлені на них.

Тому, коли вийшов офіційний патч, вам не тільки потрібно діяти швидко...

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

Я впевнений, що буде багато розмов про Naked Security тощо Twitter та інших місцях, розповідаючи про типи атак, які ми бачимо, щоб ви знали, на що звертати увагу.

КАЧКА.  Хоча ви можете шукати купу хешів відомого зловмисного програмного забезпечення, яке вже було розповсюджено під час обмеженої кількості атак…

…справді, суть у тому, що всілякі шкідливі програми є можливі.

І тому, як я думаю, ви сказали в останній міні-епізод що ми зробили, тепер недостатньо просто чекати сповіщень про щось погане, що трапилося, щоб з’явитися на вашій інформаційній панелі:

Ви повинні активно виходити на вулицю та шукати, чи не шахраї вже були у вашій мережі та залишили щось позаду (що могло бути там багато років!), чого ви ще не помітили.

ЧЕТ.  Тож я думаю, що це веде нас до «Що нам робити зараз, поки ми чекаємо на патч?»

Опубліковано блог Microsoft Security Research Center (MSRC). деякі поради щодо пом'якшення і деталі... стільки, скільки Microsoft готова розкрити на даний момент.

Я б сказав, якщо ти чистий Microsoft Exchange Online Клієнте, вам майже все ясно, і вам варто просто звернути увагу, якщо щось зміниться.

Але якщо ви перебуваєте в гібридній ситуації або все ще використовуєте Microsoft Exchange локально, я думаю, що є певна робота, яку варто виконати сьогодні вдень або завтра вранці, якщо нічого іншого.

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

Які тут найкращі практики, Дак?

Очевидно, одну річ, яку ви можете зробити, це просто вимкнути зовнішній доступ до Інтернету, доки не буде доступним патч.

Ви можете просто вимкнути свій сервер IIS, і це буде зроблено!

КАЧКА.  Я підозрюю, що багато компаній не будуть у такому становищі.

І Microsoft перераховує дві речі, які вони кажуть… ну, вони не кажуть, «Це точно спрацює».

Вони припускають, що це значно обмежить ваш ризик.

Перший полягає в тому, що існує правило перезапису URL-адрес, яке можна застосувати до свого сервера IIS. (Я розумію, що саме IIS приймає вхідне з’єднання, яке перетворюється на доступ до веб-служб Exchange [EWS].)

Отже, ви можете зробити налаштування IIS, яке шукатиме ймовірне використання першої діри, що запобігатиме запуску PowerShell.

Є кілька портів TCP, які можна заблокувати на сервері Exchange.

Я вважаю, що це порти 5985 і 5986, які зупинять те, що називається PowerShell Remoting… це зупинить ці шахрайські команди віддаленого виконання PowerShell, які надсилаються на сервер Exchange.

Зауважте, однак, що корпорація Майкрософт каже, що це «обмежить» ваш вплив, а не обіцяє, що вони знають, що це все виправляє.

І це може бути тому, що вони підозрюють, що існують інші способи, якими це може бути спровоковано, але вони просто ще не зовсім зрозуміли, що це таке. [СМІЄТЬСЯ]

Жоден параметр не є тим, що ви робите в самому Exchange.

Один із них знаходиться в IIS, а інший є певним правилом мережевої фільтрації.

ЧЕТ.  Що ж, це допоможе нам пережити наступні кілька днів, поки Microsoft надасть нам постійне виправлення.

Хороша новина полягає в тому, що я думаю, що багато програмного забезпечення безпеки, будь то IPS, інтегроване у ваш брандмауер, або продукти безпеки кінцевих точок, які ви використовуєте для захисту інфраструктури Microsoft Windows Server…

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

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

КАЧКА.  Це правильно, Честере.

І хороша новина для клієнтів Sophos полягає в тому, що ви можете відстежувати специфічні для Sophos виявлення, якщо хочете переглянути свої журнали.

Не лише для IPS, будь то IPS на брандмауері чи кінцевій точці, але ми також маємо купу правил поведінки.

Ви можете відстежувати ці імена виявлення, якщо хочете піти їх шукати… дотримуйтеся цього на @SophosXops Потік у Twitter.

Оскільки ми отримуємо нові назви виявлення, які можна використовувати для полювання на загрози, ми публікуємо їх там, щоб ви могли легко їх шукати:

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

Але я цілком впевнений, що ми ще довго не зможемо покласти це в ліжко…

КАЧКА.  Я думаю, що, як у ProxyShell, так і в Log4Shell, відлуння буде відбиватися ще досить довго.

Тому, можливо, нам краще сказати, як ми завжди робимо, Честере:

До наступного разу…

ОБИМ.  Залишайтеся в безпеці.

[МУЗИЧНИЙ МОДЕМ]

Часова мітка:

Більше від Гола безпека