А вы в курсе, чем отличается центр обработки данных (ЦОД) от обычной серверной комнаты? 🙂

А вы в курсе, чем отличается центр обработки данных (ЦОД) от обычной серверной комнаты? 🙂 26 февраля в 11:00 Игорь Дорофеев из Академии Информационных Систем проведёт вебинар "ЦОД: актуальность и горизонты развития". Судя по описанию, нас ждёт ликбез и рассказ о перспективах развития отрасли ЦОДостроительства. Канал "Управление Уязвимостями и прочее" в информационных партнёрах мероприятия. 😉

А причём же здесь Управление Уязвимостями?

🔻 Неделю назад Гарда опубликовала результаты опроса российских компаний нефтегазового сектора. 30% опрошенных считают именно ЦОД-ы наиболее уязвимыми информационными системами.

🔻 В паблик кейсы с атаками на ЦОД-ы также периодически попадают [1, 2, 3].

Так что вебинар должен быть интересен не только тем, кто ЦОД-ы строит, обслуживает и использует, но и VM-щикам, которым и в этой части инфраструктуры необходимо устранять уязвимости. Собираюсь посмотреть и поделиться впечатлениями.

➡️ Регистрация на сайте АИС
⏰ 26 февраля в 11:00

VM-ная загадка: есть 2 подразделения

Добавить комментарий

VM-ная загадка: есть 2 подразделения. 🙂 В одном Linux-админы на золотые образы и харденинг заточенные, в другом IT-шники исключительно работой приклада озабоченные (например, PostgreSQL).

Кому из них регулярный патчинг Linux-хостов (ядро и пакеты) с этим развёрнутым прикладом поручишь?

Имхо, обновлением хостов должны заниматься те же сотрудники, что обслуживают приклад на этих хостах. Иначе они будут постоянно вешать проблемы с прикладом на команду, которая делала обновление ОС: "вы опять нам всё сломали". Пусть лучше сами полностью обновляются и тестируются. 😇

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

➡️ Кстати, 24 февраля стартует новый поток курса "VM от теории к практике", где мы и такие вопросы тоже обсуждаем. 🙂 А ещё есть моя статья про работу VM-щиком, если кто не видел.

Уязвимости в CISA KEV это не все эксплуатирующиеся уязвимости!

Добавить комментарий

Уязвимости в CISA KEV это не все эксплуатирующиеся уязвимости! Кейс с CVE-2024-21413, которую в CISA KEV добавили через год после появления эксплоита, отлично демонстрирует специфику CISA KEV. Были ли атаки с использованием этой уязвимости за прошедший год? Разумеется. 🙂 Их не могло не быть, учитывая наличие всех инструментов.

Но дело в том, что CISA абсолютно фиолетово даже на самую очевидную эксплуатабельность. 🤷‍♂️ Им важны ТОЛЬКО сигналы об успешных атаках. Что логично, они "known exploited", а не "exploitable". И эти сигналы должны быть либо от вендора (очевидно не любого, а то бы там одни уязвимости плагинов WordPress были бы 🙂), либо от расследователей атак (также не любых, а признаваемых CISA). Появился сигнал - добавили. А если б не появился, то и не добавили бы.

CISA KEV - очень специфическая выборка из всех эксплуатирующихся уязвимостей, отражающая своеобразное понимание того, какие уязвимости должны исправляться в федеральных агентствах США приоритетно. И только. 😉

Уязвимость Remote Code Execution - Microsoft Outlook (CVE-2024-21413) добавили в CISA KEV почти через год после появлений достоверных доказательств эксплуатабельности

Добавить комментарий

Уязвимость Remote Code Execution - Microsoft Outlook (CVE-2024-21413) добавили в CISA KEV почти через год после появлений достоверных доказательств эксплуатабельности.

🔹Эта уязвимость из февральского Microsoft Patch Tuesday 2024 года (13.02.2024). На следующий день после MSPT на сайте СheckPoint вышел write-up и PoC. Ещё через день Microsoft поставили для уязвимости флаг "Exploited", но по каким-то причинам в тот же день этот флаг убрали. 🤷‍♂️ К 18 февраля на GitHub уже был код эксплоита и демка. "В демке жертва кликает на ссылку в письме, через несколько секунд атакующий получает шелл". Каких-то сомнений в эксплуатабельности на тот момент уже не оставалось.
🟥 Естественно, к этому времени уязвимость уже была в трендовых.

🔹 А что CISA KEV? Они добавили эту уязвимость в каталог буквально недавно, 06.02.2025. Практически год спустя! 😏 И без каких-либо объяснений причин такой задержки.

Про уязвимость Remote Code Execution - CommuniGate Pro (BDU:2025-01331)

Добавить комментарий

Про уязвимость Remote Code Execution - CommuniGate Pro (BDU:2025-01331). CommuniGate Pro - это универсальная серверная платформа для организации корпоративных коммуникаций. Она объединяет в себе множество сервисов, включая электронную почту, передачу голосовых данных, обмен сообщениями и автоматизацию совместной работы. Так как это отечественное решение, его часто используют для импортозамещения Microsoft Exchange.

Уязвимость позволяет удалённому неаутентифицированному злоумышленнику выполнить произвольный код на уязвимом сервере CommuniGate Pro. Причина уязвимости - Stack-based Buffer Overflow. Уязвимы версии с 6.3.0 до 6.3.39.

👾 По данным компании CyberOK, есть признаки эксплуатации уязвимости в реальных атаках. По состоянию на 14 февраля около 40% всех отслеживаемых хостов CommuniGate Pro были подвержены уязвимости.

⚡️ Это первая трендовая уязвимость в отечественном продукте с 2023 года.

Методические рекомендации ЦБ по управлению уязвимостями и пентестам

Добавить комментарий

Методические рекомендации ЦБ по управлению уязвимостями и пентестам. 21 января был утверждён документ "Методические рекомендации Банка России по проведению тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка".

Документ на 21 страницу. Он содержит общие положения и рекомендации:

🔹 по проведению пентестов
🔹 по проведению анализа уязвимостей
🔹 по самостоятельному проведению этих работ и с привлечением сторонней организации
🔹 по информированию ЦБ о результатах работ (с формой отчёта)

В части Управления Уязвимостями наиболее важными видятся рекомендации:

🔻 3.7. проводить работы по анализу и устранению уязвимостей по руководству ФСТЭК по организации VM-процесса от 17.05.2023 ‼️
🔻 3.4. оценивать критичность уязвимостей по методике ФСТЭК от 28.10.2022 ❗
🔻 использовать сертифицированные ФСТЭК средства детектирования уязвимостей инфраструктуры 3.3. и исходного кода 3.5.

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

Добавить комментарий

О детекте уязвимостей софтов, установленных не из официального репозитория Linux-вендора. У моего коллеги по PT ESC Владислава Молькова на прошлом PHDays был доклад про детектирование уязвимостей Linux-хостов. Один из кейсов там был про софт установленный не из официального репозитория Linux-вендора, а из сторонних пакетов вендора софта (допустим, nginx) или из исходников. Как для такого софта уязвимости искать? Ведь детект по бюллетеням или OVAL-контенту Linux-вендора тут не поможет. 🤷‍♂️

Инсталляцию и версию запущенного софта можно найти в "ps -eo pid,cmd". Для nginx будет а-ля "nginx/1.22.1".

А откуда брать для них известные уязвимости? Брать их придётся из бюллетеней вендора софта, таких как nginx security advisories.

Т.е. для каждого подобного софта, придётся:

🔹 написать "непакетные" детекты
🔹 найти бюллетени вендора этого софта и превратить их в правила детектирования

И всё это для того, чтобы найти уязвимости Linux-софтов там, где сканер попроще их не найдёт. 😉