Архив за месяц: Февраль 2024

💂 От наших регуляторов к британским: NCSC опубликовали руководство по Vulnerability Management-у для организаций

💂 От наших регуляторов к британским: NCSC опубликовали руководство по Vulnerability Management-у для организаций

💂 От наших регуляторов к британским: NCSC опубликовали руководство по Vulnerability Management-у для организаций. Приятный документ. Написан по-человечески и с прогрессивной позиции. Бальзам на душу. 😇

❗️ В введении подчеркивают: Управление Уязвимостями требуется для контроля как хорошо в вашей организации работает процесс обновления ПО и безопасное конфигурирование. Обновление ПО должно быть регулярным процессом, а не чем-то исключительным и по требованию. Хотя они и признают: многие организации сейчас исповедуют принцип "работает - не трогай". Но это нужно изживать.

Кажется, что документ настолько хорош, что его можно переносить на российские реалии практически без изменений. 🤔

Пока ограничусь весьма вольным переводом Пяти основных принципов:

🔸 Установите политику безусловных обновлений (update by default). Применяйте обновления как можно скорее, в идеале автоматически. Старайтесь укладываться по времени в рекомендуемые сроки обновления в зависимости от типа актива.

🔸 Определите свои активы. Вы должны понимать какие системы и ПО имеются в вашей инфраструктуре (technical estate), какие уязвимости в них присутствуют и какие люди за них отвечают.

🔸 Сортируйте (triaging) и приоритизируйте уязвимости. ❗️ Это требуется для уязвимостей и мисконфигураций, которые не исправляются простым обновлением до последней версии. Т.е. это не для всех уязвимостей, а для относительно небольшой части нетипичных и проблемных.

🔸 Организация должна взять на себя риски необновления. Иногда могут быть веские причины не обновляться. Но принимать решение по такому риску должны ТОПы (senior-level). И это решение должно рассматриваться в контексте Управления Рисками организации. В общем, пусть ТОПы явно подпишутся, что понимают последствия - может в процессе и поменяют своё мнение. 😉

🔸 Проверяйте и регулярно анализируйте свой процесс Управления Уязвимостями. Ваш процесс управления уязвимостями должен постоянно развиваться, чтобы идти в ногу с изменениями в состоянии вашей организации, новыми угрозами или новыми уязвимостями. Быстрее-выше-сильнее и т.д. 🙂

Дальше каждый принцип подробно раскрывается. Если мне будет не лень, то буду их также вольно переводить. 😉
Если вам такое надо, то в реакции кита 🐳 ставьте.

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации"

Вышел драфт Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что там с Управлением Уязвимостями?

Есть 2 показателя безопасности, зависящие от оперативности устранения уязвимостей:

🔸 3.2. "На устройствах и интерфейсах, доступных их сети Интернет, отсутствуют уязвимости критического уровня опасности с датой публикации обновлений (компенсирующих мер по устранению) в банке данных угроз ФСТЭК России, на официальных сайтах разработчиков, иных открытых источниках более 30 дней"

🔸 3.3 "На пользовательских устройствах и серверах отсутствуют уязвимости критического уровня с датой публикации обновления (компенсирующих мер по устранению) более 90 дней (не менее 90% устройств и серверов)"

❓Во втором случае не указано откуда дату публикации обновления брать. Наверное нужно сделать единообразно.
❓"доступных их сети Интернет" - опечаточка, "из".

Из пунктов следует, что нужно:

🔻 покрывать все активы детектами уязвимостей
🔻 понимать какие именно активы опубликованы в Интернет
🔻 уметь оценивать критичность уязвимостей по методике ФСТЭК
🔻 отслеживать дату публикации обновления (а не дату публикации самой уязвимости!) в разных источниках 😲

Последнее выглядит как нетривиальная задача, т.к. общего реестра данных по обновлениям не наблюдается, получается ведение такого реестра и наполнение его ляжет на организацию. На практике, скорее всего, придется ориентироваться именно на дату публикации уязвимости, т.к. её гораздо проще определять (непосредственно в NVD/BDU) и, по идее, она должна быть всегда более ранней или равной дате публикации обновления. 🤔 Поэтому, возможно, имеет смысл подкрутить формулировочку, например на "дата публикации уязвимости или обновления (компенсирующих мер по устранению)". И сделать пометочку, что допустимо взять наибольшую из имеющихся дат.

И, в идеале, хотелось бы ещё видеть аналог CISA KEV с непосредственно указанными датами, когда конкретные уязвимости должны быть исправлены.

Про 0day уязвимость EventLogCrasher (без CVE)

Про 0day уязвимость EventLogCrasher (без CVE)

Про 0day уязвимость EventLogCrasher (без CVE). Уязвимость позволяет злоумышленнику удаленно крашить службу Event Log на устройствах в том же Windows-домене (включая контроллеры домена). И пока логи не ведутся злоумышленник потенциально может брутить пароли, атаковать системы ненадежными эксплоитами с риском их покрашить и творить прочую заметную дичь.

🔻Для эксплуатации злоумышленнику необходимо сетевое подключение к целевому устройству и любая валидная учётка (даже с низкими привилегиями)
🔻 Уязвимость затрагивает все версии Windows: от Windows 7 до последней версии Windows 11 и от Server 2008 R2 до Server 2022
🔻 Есть PoC и видео демонстрация
🔻 Microsoft заявили исследователю, что уязвимость недостаточно критична ("didn't meet the requirements for servicing"), не требует срочного исправления и что они исправят её в будущем. 🤷‍♂️ Также сообщили, что это дубль какой-то уязвимости 2022 года, которая также была недостаточно критичной для исправления. Видимо официального исправления ждать пока не приходится. 😐
🔻 Уязвимость подтвердили исследователи из 0patch и выпустили неофициальное исправление
🔻 Похожую уязвимость в прошлом году описывали исследователи из компании Varonis, они назвали её LogCrusher. Она также прошла без CVE и там тоже были проблемы с признанием её критичности со стороны Microsoft.

Пока Microsoft не прояснят ситуацию остаётся либо фиксить это микропатчем от 0patch, либо ловить эксплуатацию SIEM-ом. Например с помощью 🟥 MaxPatrol SIEM. 😉

Февральский Microsoft Patch Tuesday

Февральский Microsoft Patch TuesdayФевральский Microsoft Patch TuesdayФевральский Microsoft Patch TuesdayФевральский Microsoft Patch TuesdayФевральский Microsoft Patch TuesdayФевральский Microsoft Patch TuesdayФевральский Microsoft Patch TuesdayФевральский Microsoft Patch Tuesday

Февральский Microsoft Patch Tuesday. 105 уязвимостей (это с учётом 32 набежавших с январского).

С признаком эксплуатации вживую, но пока без публичных эксплоитов:

🔻 Memory Corruption - Chromium (CVE-2024-0519). В V8.
🔻 Security Feature Bypass - Windows SmartScreen (CVE-2024-21351). Ещё один обход Mark-of-the-Web.
🔻 Security Feature Bypass - Internet Shortcut Files (CVE-2024-21412). По факту тоже обход Microsoft Defender SmartScreen. Есть видео с демонстрацией и write-up от Trend Micro.

Из остальных можно отметить:

🔹 Elevation of Privilege - Microsoft Exchange (CVE-2024-21410). Возможность атаки NTLM relay.
🔹 Elevation of Privilege - Windows Kernel (CVE-2024-21338, CVE-2024-21345, CVE-2024-21371)
🔹 Remote Code Execution - Microsoft Outlook (CVE-2024-21413). Есть обход Office Protected View.
🔹 Remote Code Execution - Microsoft Outlook (CVE-2024-21378)

🗒 Отчёт Vulristics

🟥 PT относит CVE-2024-21351 и CVE-2024-21412 к трендовым

SSRF/AuthBypass-уязвимость Ivanti Connect Secure, Policy Secure и ZTA (CVE-2024-21893) используются злоумышленниками для установки ранее неизвестного бэкдора под кодовым названием DSLog

SSRF/AuthBypass-уязвимость Ivanti Connect Secure, Policy Secure и ZTA (CVE-2024-21893) используются злоумышленниками для установки ранее неизвестного бэкдора под кодовым названием DSLog

SSRF/AuthBypass-уязвимость Ivanti Connect Secure, Policy Secure и ZTA (CVE-2024-21893) используются злоумышленниками для установки ранее неизвестного бэкдора под кодовым названием DSLog. Об этом сообщает Orange Cyberdefense. Бэкдор добавляется в легитимный модуль логирования.

🔻 Бэкдор позволяет выполнять команды от root-а, не возвращает статус/код при попытке соединиться с ним (усложняет обнаружение), использует уникальный ключ аутентификации для каждого скомпрометированного апплаенса.

🔻 По состоянию на 3 февраля Orange Cyberdefense обнаружили 670 скомпрометированных устройств.

В статье описывается работа бэкдора, приводятся IOC-и.

Завтра в 15:00 пройдёт вебинар по API MaxPatrol VM

Завтра в 15:00 пройдёт вебинар по API MaxPatrol VM

Завтра в 15:00 пройдёт вебинар по API MaxPatrol VM. Зарегался, буду смотреть. Я так-то базово умею пользоваться, даже пост по выгрузке данных по PDQL-запросу делал. Но наверняка коллеги расскажут что-нибудь новое и интересное. 🙂🍿