Если вы поставляете продукт клиентам в виде апплаенса, не забывайте его проверять и обновлять, а то может получиться стыдновато (на примере Ivanti Connect Secure)

1 комментарий

Если вы поставляете продукт клиентам в виде апплаенса, не забывайте его проверять и обновлять, а то может получиться стыдновато (на примере Ivanti Connect Secure)

Если вы поставляете продукт клиентам в виде апплаенса, не забывайте его проверять и обновлять, а то может получиться стыдновато (на примере Ivanti Connect Secure). 😏 Вчера в блоге компании Eclypsium вышло исследование апплаенса Ivanti:

🔸 Ivanti применяют шифрование образа прошивки, но от реверса это не защитило. Исследователи изучили прошивку Ivanti Connect Secure ICS-9.1.18.2-24467.1 с установкой на аппаратный апплаенс. Доступ получили через эксплуатацию известной уязвимости.
🔸 В качестве ОС в апплаенсе используется CentOS 6.4 (EOL c 30 ноября 2020 года).
🔸 Исследователи применили анализатор безопасности прошивок EMBA и обнаружили следующие устаревшие компоненты:

Ядро Linux 2.6.32 (EOL в феврале 2016 г.)
OpenSSL 1.0.2n (декабрь 2017 г.)
Python 2.6.6 (август 2010 г.)
Perl v5.6.1, для i386-linux (не x64, апрель 2001 г.)
Bash 4.1.2, который, как ни странно, пропатчен для Shellshock.
Ряд устаревших библиотек с известными CVE и эксплойтами

🔸 Большая часть графического интерфейса Pulse Secure написана на Perl, что создает огромную поверхность атаки.
🔸 Ivanti удалили доступ к административной оболочке, поэтому исследователи не нашли захардкоженные креды или бэкдор-аккаунты. Но не значит, что их там нет. 😉
🔸 Исследователи продолжат ковырять обнаруженные бинари и shell-скрипты, вполне возможно что-то ещё нароют.
🔸 Исследователи изучили Ivanti "Integrity Checking Tool" (ICT). Утилита исключает из сканирования более десятка каталогов, а это означает, что злоумышленник теоретически может оставить свои постоянные C2 (Command-and-control) имплантаты в одном из этих путей, и устройство все равно пройдет проверку целостности. 🤷‍♂️ Исследователи пишут, что между разными версиями ICT разница в том, что в исключения добавлялось всё больше каталогов - видимо вендор боролся так с фолсами.

Вендорам имеет смысл привести в порядок свои апплаенсы до того как туда залезут исследователи. А клиентам стоит иметь в виду, что в апплаенсе может быть тот ещё адок и вендоры тоже могут жить по принципу "работает - не трогай".

На сайте Positive Technologies выложили дайджест трендовых уязвимостей за январь 2024 года

3 комментария

На сайте Positive Technologies выложили дайджест трендовых уязвимостей за январь 2024 года

На сайте Positive Technologies выложили дайджест трендовых уязвимостей за январь 2024 года. В работе над которым я принимал участие. 😇 Это наш первый опыт в таком формате, планируем выпускать подобные дайджесты ежемесячно и возможно не только текстом. 😉

За январь в трендовые добавили 6 уязвимостей.

🔻 По двум эксплуатация вживую указана прям в CISA KEV: RCE в Confluence (CVE-2023-22527) и RCE в vCenter (CVE-2023-34048).
🔺 По двум есть эксплоиты и эксплуатация вживую скорее всего есть, но формально она пока не зафиксирована: AuthBypass в GitLab (CVE-2023-7028), Arbitrary File Reading в Jenkins CLI (CVE-2024-23897).
🔸 По двум есть признаки, что эксплуатация вживую может скоро начаться: RCE в Junos OS (CVE-2024-21591), Information Disclosure в Outlook (CVE-2023-35636).

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

🟥 Пост в канале PT

Галя, у нас отмена: Microsoft убрали галку "эксплуатируются вживую" для Remote Code Execution - Microsoft Outlook (CVE-2024-21413)

2 комментария

Галя, у нас отмена: Microsoft убрали галку эксплуатируются вживую для Remote Code Execution - Microsoft Outlook (CVE-2024-21413)Галя, у нас отмена: Microsoft убрали галку эксплуатируются вживую для Remote Code Execution - Microsoft Outlook (CVE-2024-21413)

Галя, у нас отмена: Microsoft убрали галку "эксплуатируются вживую" для Remote Code Execution - Microsoft Outlook (CVE-2024-21413). 🤡😅 Видимо всё-таки эта галка за ночь переехала к уязвимости Exchange.

Но и у уязвимости Outlook, судя по простоте POC-а, который был описан в статье CheckPoint-а, признак эксплуатации вживую вполне возможно скоро опять появится.

У нас новый лидер в февральском Microsoft Patch Tuesday - Elevation of Privilege - Microsoft Exchange (CVE-2024-21410)

3 комментария

У нас новый лидер в февральском Microsoft Patch Tuesday - Elevation of Privilege - Microsoft Exchange (CVE-2024-21410)

У нас новый лидер в февральском Microsoft Patch Tuesday - Elevation of Privilege - Microsoft Exchange (CVE-2024-21410). 🚀 Как и в случае с RCE в Outlook, Microsoft изменили описание уязвимости, обозначив эксплуатацию вживую и наличие функционального эксплоита (пока непубличного). Microsoft пишут про использование уязвимости в NTLM relay атаках. Какого-то более подробного исследования этой уязвимости в паблике пока не наблюдается.

Не удивлюсь, если окажется, что эта уязвимость использовалась в атаках совместно с Remote Code Execution - Microsoft Outlook (CVE-2024-21413) #MonikerLink. Уж больно синхронно у них статус поменялся и исследователи Check Point в своей статье тоже про NTLM relay атаки писали.

В общем, пока подробностей немного, но понятно, что Exchange нужно оперативно обновлять.

Обновление в февральском Microsoft Patch Tuesday: резкое повышение критичности Remote Code Execution - Microsoft Outlook (CVE-2024-21413)

3 комментария

Обновление в февральском Microsoft Patch Tuesday: резкое повышение критичности Remote Code Execution - Microsoft Outlook (CVE-2024-21413)

Обновление в февральском Microsoft Patch Tuesday: резкое повышение критичности Remote Code Execution - Microsoft Outlook (CVE-2024-21413). 🚀 Microsoft признали, что эта уязвимость оказывается эксплуатировалась вживую (упс), а исследователи из Check Point выпустили подробный write-up с PoC-ом. Исследователи Check Point называют уязвимость #MonikerLink и рекомендуют обновить Outlook ASAP.

Я эту уязвимость в своём обзоре подсветил, но буквально последней в списке. Вот так предполагаем по описанию, что одни уязвимости будут эксплуатироваться в атаках. А потом может оказаться, что реально эксплуатироваться будут совсем другие уязвимости. 🤷‍♂️ Очень сложно предугадать, что за какой-то CVE оказывается ресерчер, который завтра выложит write-up с PoC-ом, а послезавтра начнутся массовые атаки. Поэтому про уязвимости, конечно, читаем, гадаем что выстрелит, но обновления устанавливаем для всего!

upd. Отменили

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

1 комментарий

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

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

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

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

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

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

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

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

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

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

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

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

2 комментария

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

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

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

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

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

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

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

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

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

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