Архив метки: vulnerability

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

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

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

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

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

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

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

Уязвимости в 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-софтов там, где сканер попроще их не найдёт. 😉

Нужно ли учитывать данные из даркнета при приоритизации устранения уязвимостей?

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

Нужно ли учитывать данные из даркнета при приоритизации устранения уязвимостей? Конечно. Если видите объявление о продаже эксплоита для уязвимости или рекламу, что какая-то малварь эксплуатирует новую уязвимость, то грех не поднять этой уязвимости приоритет. Лучше ошибиться и устранить неэксплуатабельное, чем дождаться атак в собственной инфре.

Но нужно ли устранять только то, что засветилось в даркнете? Разумеется нет. Хотя бы потому, что даркнет велик и наиболее ценная инфа может долго не выходить за пределы закрытых форумов и площадок. А доступ туда либо просто платный (вопрос +- решаемый для компании, занимающейся разведкой), либо ещё требует определенной репутации в киберпреступном сообществе. 🦹‍♂️ Поэтому то, что выходит в паблик - лишь малая часть того, что есть на самом деле. Это как в замочную скважину подсматривать. Видно, но не всё. 😉

Поэтому анализ даркнета не снимает необходимости устранять ВСЕ уязвимости в соответствии с разумными приоритетами.