S3 Ep102.5: Ошибки Exchange «ProxyNotShell» — говорит эксперт [Аудио + текст]

Нажмите и перетащите звуковые волны ниже, чтобы перейти к любой точке. Вы также можете слушать прямо на Саундклауд.

[МУЗЫКАЛЬНЫЙ МОДЕМ]

---

УТКА.  Привет всем.

Добро пожаловать в очередной специальный мини-эпизод подкаста Naked Security.

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

Привет, Чет.

---

ЧЕТ.  [FAKE AUSSIE ACCENT] Добрый день, Дак.

---

УТКА.  Что ж, Чет, я уверен, что все слушают. если они слушают вскоре после выхода подкаста, то знают, о чем мы будем говорить!

И это должно быть двуствольное Microsoft Exchange нулевой день который вышел из моды в последний день сентября 2022 года:

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

В эти выходные для системных администраторов и ИТ-менеджеров ничего подобного не будет!

---

ЧЕТ.  Дак, думаю, бессмертными словами давно ушедшего Дугласа Адамса, "НЕ ПАНИКУЙТЕ" может быть в порядке вещей.

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

Но если вы используете Exchange локально…

…если бы это был я, я мог бы работать сверхурочно, просто чтобы ввести несколько мер по смягчению последствий, чтобы быть уверенным, что меня не ждет неприятный сюрприз в понедельник или вторник, когда это, по всей вероятности, перерастет во что-то большее. драматический.

---

УТКА.  Так что это CVE-2022-41040 и CVE-2022-41042… это довольно много.

Я видел, как это упоминается в Твиттере как Проксинотшелл, потому что он имеет некоторое сходство с ПроксиШелл уязвимость, которая была большой новостью чуть более года назад,

Но хотя у него есть сходство, это совершенно новая пара эксплойтов, которые соединяются вместе, потенциально обеспечивая удаленное выполнение кода — это правильно?

---

ЧЕТ.  Вот как это звучит.

Эти уязвимости были обнаружены во время активной атаки на жертву, и вьетнамская организация GTSC раскрыла эти две новые уязвимости, которые позволили злоумышленникам получить доступ к некоторым из их клиентов.

Похоже, они ответственно раскрыли эти уязвимости к инициативе Zero Day Initiative [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 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, их очень сложно исправить, требуется много тестов, чтобы убедиться в их надежности, прежде чем вы нарушите работу своих почтовых серверов.

Этого времени было достаточно, чтобы эти серверы получили веб-ракушки, cryptominers, все виды бэкдоров установлены на них.

И так, когда вышел официальный патч, нужно не только действовать быстро…

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

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

---

УТКА.  Пока можно пойти и поискать кучу хэшей известных вредоносных программ, которые уже были распространены в ограниченном количестве атак…

…действительно, суть в том, что возможны любые вредоносные программы.

Итак, как я думаю, вы сказали в последний мини-эпизод что мы и сделали, уже недостаточно просто ждать оповещений о чем-то плохом, что произошло на вашей панели инструментов:

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

---

ЧЕТ.  Так что я думаю, что это ведет нас к, «Что нам делать сейчас, пока мы ждем патч?»

Выпущен блог Microsoft Security Research Center (MSRC) некоторые советы по смягчению последствий и подробности… столько, сколько Microsoft готова раскрыть на данный момент.

Я бы сказал, если ты чистый Microsoft Exchange онлайн клиент, вы в значительной степени в ясности, и вы должны просто обратить внимание на случай, если что-то изменится.

Но если вы находитесь в гибридной ситуации или все еще используете Microsoft Exchange локально, я думаю, что, вероятно, есть какая-то работа, которую стоит выполнить сегодня днем ​​или завтра утром, если ничего другого.

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

Каковы лучшие практики здесь, Дак?

Очевидно, что вы можете просто отключить внешний веб-доступ до тех пор, пока не будет выпущен патч.

Вы можете просто выключить свой сервер IIS, и тогда это сработает!

---

УТКА.  Подозреваю, что многие компании не окажутся в таком положении.

И Microsoft перечисляет две вещи, которые они говорят… ну, они не говорят, «Это определенно сработает».

Они предполагают, что это значительно ограничит ваш риск.

Во-первых, существует правило перезаписи URL-адресов, которое вы можете применить к своему серверу IIS. (Насколько я понимаю, именно IIS принимает входящее соединение, которое превращается в доступ к веб-службам Exchange [EWS].)

Таким образом, вы можете настроить IIS, который будет искать вероятные возможности использования первой дыры, что предотвратит запуск триггера PowerShell.

И есть некоторые порты TCP, которые вы можете заблокировать на своем сервере Exchange.

Я считаю, что это порты 5985 и 5986, которые остановят то, что называется Удаленное взаимодействие PowerShell… это предотвратит ввод этих мошеннических команд удаленного выполнения PowerShell на сервер Exchange.

Обратите внимание, однако, что Microsoft говорит, что это «ограничит» ваше воздействие, а не обещает, что они знают, что это все исправит.

И это может быть потому, что они подозревают, что есть другие способы, которыми это может быть вызвано, но они просто еще не совсем поняли, что это такое. [СМЕЕТСЯ]

Ни одна из этих настроек не выполняется в самом Exchange.

Один из них находится в IIS, а другой — какое-то правило сетевой фильтрации.

---

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

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

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

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

---

УТКА.  Это верно, Честер.

И хорошая новость для клиентов Sophos заключается в том, что вы можете отслеживать специфические обнаружения Sophos, если хотите просмотреть свои журналы.

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

Вы можете отслеживать эти имена обнаружения, если хотите их искать… @SophosXops Лента Твиттера.

По мере того, как мы получаем новые имена обнаружения, которые вы можете использовать для поиска угроз, мы публикуем их там, чтобы вы могли легко их найти:

Sophos X-Ops добавила следующие обнаружения:

Troj/WebShel-EC и Troj/WebShel-ED обнаруживают веб-шеллы, обсуждаемые в атаках.

Подпись IPS sid:2307757 основана на информации, опубликованной Microsoft как для брандмауэра Sophos XG, так и для Sophos Endpoint IPS.

— Sophos X-Ops (@SophosXOps) 30 сентября, 2022

---

ЧЕТ.  Я уверен, что у нас будет больше, что сказать в подкасте на следующей неделе, будь то Даг, воссоединяющийся с вами, или я снова в гостевом кресле.

Но я совершенно уверен, что мы еще долго не сможем покончить с этим….

---

УТКА.  Я думаю, что, как ProxyShell, как и Log4Shell, какое-то время будет отдаваться эхо.

Так что, возможно, нам лучше сказать, как мы всегда делаем, Честер:

До скорого…

---

ОБА.  Оставайтесь в безопасности.

[МУЗЫКАЛЬНЫЙ МОДЕМ]