А вот и эксплоит для Remote Code Execution – Microsoft Word (CVE-2023-21716), которую я подсвечивал в февральском Patch Tuesday. Тут подробности. Об этой уязвимости писали, что она эксплуатируется через панель предварительного просмотра Outlook. Хороший повод форсировать патчинг, если вы пока ещё нет.
PS: У Joshua J. Drake очень классный сайт. 👍
Тренды/драйверы Vulnerability Management рынка. Пару месяцев назад попросили накидать. С моей колокольни выглядит как-то так:
1. Изменение IT-ландшафта в странах в силу геополитических изменений. Соответственно меняются и ожидания того какие продукты должны поддерживать VM решение.
2. База знаний VM вендора должна быть анализируемой. Для того, чтобы понимать можем ли мы в достаточной мере детектировать уязвимости, нужно знать что на самом деле умеет и не умеет VM решение.
3. Не будет одного VM-решения, которое продетектирует все уязвимости. Разные части инфраструктуры придется покрывать разными решениями. Детектирование уязвимостей отделяется от анализа, приоритизации и исправления.
4. Правильная инвентаризация активов. В организациях сейчас слишком много разнообразных активов. Для эффективного VM-а нужно покрыть их все. Причем необходимо понимать можем ли мы детектировать уязвимости для актива и если не можем, то что с этим делать? В качестве вариантов: покупать или разрабатывать механизмы для детекта, выводить актив из эксплуатации, принимать риски.
5. Правильная приоритизация уязвимостей. Слишком много CVE, слишком мало actionable информации. Необходимо уметь отличать экспулатабельное от неэксплуатабельного. Как это сделать непонятно, но видимо необходимо лучше работать с объектами относящимися к уязвимостям, в первую очередь с эксплоитами и сообщениями об атаках.
6. Автоматическое обновление активов. Дилемма: если не обновлять автоматом, это нагружает IT-администраторов массой однообразной работы, если обновлять автоматом, то непонятно кто будет нести ответственность в случае если что-то сломается. Решение: изменение архитектуры, чтобы обновляться было проще, обновляться постепенно, начиная с тестовых хостов.
7. Если не обновление, то что? Для уязвимостей VM решение должно знать набор компенсирующих мер, уметь их детектировать и желательно автоматически применять.
8. Обоснование комплаенс-требований. Для большей части CIS контролей не ясно как детектируемые мисконфигурации могут использовать злоумышленники в реальных атаках. Отсюда скепсис.
Эксплоиты к Osprey Pump Controller. Если вы подписаны на @avleonovnews, вы наверное видели, что всю неделю в #DailyExploits попадали эксплоиты для Osprey Pump Controller из разных сплоит-паков. Все от македонского исследователя Gjoko 'LiquidWorm' Krstic, zeroscience.mk.
Osprey Pump Controller это решение для автоматизации полива от американской компании ProPump & Controls (не уверен, что это вендор, но больше нигде не упоминается). Эксплуатируемых уязвимостей у него как у DVWA. Самое смачное захардкоженная админская учетка admin/Mirage1234. Также есть и RCE. К тому же Osprey Pump Controller выставляют прямо в интернет и они индексируются и тривиально ищутся в Google. 🤷♂️
"For our customers with limited budgets, we can supply our versatile new Osprey controller integrated into a complete control package at eye opening prices."
Не знаю уж что там по ценам, но владельцы уязвимых устройств вполне вероятно получат теперь "eye opening" опыт в области ИБ. 😏
Если вендор не предоставляет воркэраунд для исправления инфраструктурной уязвимости, возможно ли выработать его внутри организации? Если да, то кто должен за это отвечать? RedTeam? InfraSec? Совместно?
Честно говоря, не особо верю в тему разработки эффективных workaround-ов для уязвимостей внутри организации без участия вендора, т.к. по-хорошему каждый раз это будет тянуть на полноценное исследование.
1. В рамках этого исследования для начала нужно получить рабочий эксплоит, чтобы можно было оценить результативность workaround-а. Хорошо если эксплоит доступен публично и работоспособен. Или хотя бы есть подробное описание уязвимости. А если нет? В любом случае это скорее задача RedTeam. Без эксплоита рассуждения о workaround-ах становятся чисто теоретическими.
2. Когда есть рабочий инструмент для атаки, можно продумывать какой workaround можно применить. Заниматься этим вероятнее всего должны сотрудники InfraSec вместе с системными администраторами и владельцами уязвимых систем. Компенсирующие меры могут повлиять на функциональность систем, поэтому одни только безопасники этот вопрос решить не смогут.
3. На тестовом скоупе применяем workaround. Проверяем на хостах из этого скоупа, что эксплуатация уязвимости с помощью нашего эксплоита там больше невозможна. С помощью RedTeam подтверждаем, что легкого способа обойти это исправление нет. Принимаем решение о массовом применении workaround-а.
Всё это сложно, трудозатратно, очень плохо масштабируется и по определению является ненадежным временным решением. Посмотрите, например, сколько раз MS меняли рекомендуемый workaround для ProxyNotShell. А у них там лучшие эксперты работают и занимаются этим на фулл-тайм. Поэтому если есть возможность исправить уязвимость обновлением, лучше обновиться. Workaround-ы и компенсирующие меры лучше брать готовые от вендора или регулятора (для многих уязвимостей они есть прямо в БДУ!) и применять их только на время, пока обновление недоступно.
Аналитика от VM-вендоров: Tenable, Rapid7, Positive Technologies. Выпустили практически одновременно.
1. Tenable "2022 Threat Landscape Report". 66 страниц. 16 упоминаний слова "Russia" (терпимо). Есть раздел с ТОПовыми уязвимостями за год "A Closer Look at the Key Vulnerabilities of 2022".
2. Rapid7 "The Annual Vulnerability Intelligence Report: 2022 Edition". 51 страница. Одно упоминание слова "Russia" (да ладно! 🙂). Есть несколько подборок уязвимостей по категориям. Глаз зацепился за странное в глоссарии: RCE у них это не тип уязвимости, а одна из "Attacker Utilities". А тип уязвимости это, например, "injection". Подозреваю тут отголоски холивара что есть атака, а что уязвимость. Но допустим.
3. Positive Technologies "Актуальные киберугрозы для промышленных организаций: итоги 2022 года". Здесь без CVE, только статистика по атакам. "Статистика основана на многочисленных расследованиях и открытых данных как российских, так и зарубежных авторитетных источников". Есть небольшая подборка громких кейсов.
В чем различие между "уязвимостями инфраструктуры" и "уязвимостями приложений"? По мне так разница между "уязвимостями инфраструктуры" и "уязвимостями приложений" не техническая, а скорее в способе детектирования и исправления. Это условное разделение, чтобы понимать чем должен заниматься отдел Application Security, а чем отдел Infrastructure Security. Если уязвимость публично известная и у неё есть CVE/BDU, она детектируется сканерами уязвимостей и должна исправляться обновлением ПО/воркэраундом полученным от вендора, то это "уязвимость инфраструктуры". Если уязвимость публично неизвестная, была обнаружена с помощью SAST/DAST инструментов и должна исправляться изменением в коде самописного приложения, то это "уязвимость приложения". А технически и то, и другое может быть уязвимостью одного типа, например, Path Traversal. Технических типов уязвимостей можно выделить великое множество (см. CWE), но в рамках Vulristics я стараюсь всё раскладывать в несколько основных типов, отталкиваясь от уязвимостей, которые заводит MS.
Выпустил-таки блогопост и видяшечку по февральскому Microsoft Patch Tuesday до конца праздников. По сравнению с первоначальным вариантом добавились перспективные уязвимости Microsoft Edge, Microsoft Publisher и Word.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.