Архив за месяц: Май 2024

С Днём Победы!

С Днём Победы! 09.05.1945

Через 2 дня после начала войны в газете Известия было опубликовано стихотворение Евгения Долматовского "Будем крушить разбойничью рать!". Я попробовал превратить его в песню с помощью сервиса Suno. Получилось, конечно, не без огрех, особенно в части ударений и произношения (к сожалению, это пока слабо настраивается). Но по общему настроению, как мне кажется, получилось неплохо.

Нашему солнцу сиять всегда! С праздником!

В самую короткую ночь в году
— Час этот в памяти заучи —
Коршун напал на нашу звезду,
Когти обжёг об ее лучи.

Будем крушить разбойничью рать
Бомбой, пулей, снарядом, штыком.
Чтоб коршуну перьев своих не собрать,
Чтоб пепел взлетел над его гнездом.

С той ночи на убыль пойдёт его день,
А нашему солнцу сиять всегда.
Нет, не затмит зловещая тень
Наши родимые города.

Дорогой отечественной войны
Лавиной идём на чёрный фашизм.
Дни врага уже сочтены,
Смертью его будет наша жизнь.

Страница той самой газеты, где было опубликовано стихотворение.

На фотографии пехотинцы из состава сводной колонны 248-й стрелковой дивизии 9-го стрелкового корпуса 5-й ударной гвардейской армии по пути к месту берлинского Парада Победы 7 сентября 1945 года.

Зарелизили материалы по апрельским трендовым уязвимостям

Зарелизили материалы по апрельским трендовым уязвимостям

Зарелизили материалы по апрельским трендовым уязвимостям. Всего выделили 5 уязвимостей.

🔻 Удалённое выполнение команд в устройствах PaloAlto (CVE-2024-3400) [Горячий пятничный привет]
🔻 4 уязвимости Microsoft Windows (CVE-2022-38028, CVE-2023-35628, CVE-2024-29988, CVE-2024-26234)

🗣 Моя статья на Хабре по мотивам постов из канала
🚀 Дайджест на сайте PT (коротко и по делу)
🟥 Пост в канале PT
🎞 Рубрика "В тренде VM" в ролике SecLab-а выйдет в понедельник 🙂 Upd. Выложили.

На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации"

На сайте ФСТЭК выложили финальную версию Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что изменилось по сравнению с драфтом в части Управления Уязвимостями?

🔻 Поправили опечатку "их сети Интернет".
🔻 В обоих пунктах появилась приписка "или в отношении таких уязвимостей реализованы компенсирующие меры".

Понятно почему появилась приписка про компенсирующие меры - не всегда уязвимости можно исправить обновлением. Но есть опасность, что этим будут злоупотреблять, т.к. не указано какие меры можно считать компенсирующими. Возможно толкование, что компенсирующие меры могут выбираться произвольно. В духе "на десктопе есть EDR, значит все уязвимости на нём скомпенсированы". 🤪 Но даже если меры будут браться строго от вендора или из БДУ непонятно как контролировать, то что они были корректно применены, а главное, что эти меры действительно препятствуют эксплуатации уязвимости. На практике это будет выглядеть так: сканер детектирует уязвимости, а IT/ИБ с покерфейсом говорят "а у нас всё скомпенсировано". 😐 Так что моё мнение - без приписки было лучше, не нужно было создавать такую лазейку.

Также остался вопрос с "датой публикации обновления (компенсирующих мер по устранению)". Такой даты нет в БДУ (равно как и в других базах уязвимостей). Непонятно откуда её массово забирать, чтобы автоматически отслеживать, что организация укладывается в сроки. Вряд ли источник с датами появится, так что видимо на практике в VM-решениях будут использовать какую-то другую дату (например дату заведения уязвимости). А в случае инцидента это будет повод для лишних разбирательств. Имхо, зря это сразу не прояснили.

На эту же тему может быть интересная ситуация: допустим выходит обновление в котором вендор втихую исправляет уязвимость критического уровня опасности. А о существовании этой уязвимости становится известно, допустим, через полгода. В момент публикации данных об этой уязвимости у организации сразу получается просрочка. 🤷‍♂️ Просто потому, что используется дата, привязанная к обновлению, а не к уязвимости. Надумана ли такая ситуация? Да нет, "silent patches" проблема достаточно распространенная.

В этом, правда, есть и позитивный момент. Чтобы не попасть в такую ситуацию организации придётся выстраивать Patch Management процесс независящий от уязвимостей. И с неплохими требованиями регулярности обновлений: 30 дней для хостов на периметре, 90 дней для десктопов и серверов. 😏

PS: Также pdf-документ выпустили как-то странно, так что по нему не работает поиск. По odt-документу поиск работает нормально.

Вчера Qualys представили CyberSecurity Asset Management 3.0

Вчера Qualys представили CyberSecurity Asset Management 3.0Вчера Qualys представили CyberSecurity Asset Management 3.0

Вчера Qualys представили CyberSecurity Asset Management 3.0. В названии решения значится "Asset Management", но само решение сразу презентуется нам как "переопределение управления поверхностью атаки" , т.е. EASM. Такая вот гартнеровская маркетинговая мешанина. 🤷‍♂️ При этом, у Qualys действительно достаточно необычный Asset Managementи и EASM. И необычно как они к этому пришли. Тут, естественно, исключительно мои впечатления как стороннего наблюдателя, никакого инсайда у меня нет.

🔹 В 2020 году Qualys представили решение Global AssetView. Если упрощённо, то пользователи могли бесплатно раскатать облачные агенты Qualys на известные в инфре хосты, развернуть Qualys Passive Sensor для поиска неизвестных активов по трафику и получить некоторое базовое представление о составе инфры и её состоянии (без расчета уязвимостей). Такое Freemium предложение, с которого можно было бы удобно апселить основную функциональность Vulnerability Management и Compliance Management. Ход весьма и весьма смелый.

🔹 В 2021 году как развитие Global AssetView появился продукт CyberSecurity Asset Management. Это уже был заход в полноценное Управление Активами: двусторонняя синхронизация с CMDB ServiceNow, учёт критичности активов, учёт ПО, оценка поверхности атаки при помощи Shodan (последнее тогда не особенно подчёркивали). Насколько я могу понять, изначальная цель CSAM была в том, чтобы отслеживать кейсы, которые влияют на безопасность активов, но уязвимостями, строго говоря, не являются: shadow IT, хосты с подходящими end-of-life (EoL)-of-support (EoS), хосты без установленных EDR, рискованные порты опубликованные в Интернет, мисконфигурации софта и сервисов.

🔹 В 2022 Qualys выпустили CyberSecurity Asset Management 2.0 с интегрированным решением по контролю внешней поверхности атаки (EASM). Сама идея, что EASM можно развивать и продавать в рамках решения по Управлению Активами весьма необычная. Но логика в этом есть. Уменьшение поверхности атаки это не про то, что нужно пропатчить тот или иной торчащий наружу сервер, а про то, что какого-то торчащего наружу старья вообще не должно быть ("if an externally facing asset or its configuration is not necessary for the business, then it should be shut down"). И вот с этой точки зрения EASM это действительно не столько периметровый сканер, сколько хитрая штуковина, которая накидывает неочевидные активы, с некоторой вероятностью относящиеся к компании, и показывает риски с ними связанные. 🐇 🎩 Часть управления активами? Ну видимо да.

Таким образом, насколько я понимаю, сейчас у Qualys есть VMDR (Vulnerability Management, Detection and Response), который включает в себя CSAM (CyberSecurity Asset Management ), который включает в себя EASM (External Attack Surface Management). Такая вот матрёшка. 🪆

А что же в версии CSAM 3.0?

🔻 Убрали упоминания Shodan. "CSAM 3.0 использует новую систему оценки атрибуции и расширяет использование технологий с открытым исходным кодом и собственного интернет-сканера для обеспечения точного обнаружения, атрибуции и оценки уязвимостей" . При атрибуции актива отображаются показатели достоверности (можно по ним фильтровать).

🔻Используются возможности детектирования активов Cloud Agent Passive Sensing (хостовые агенты, снифающие трафик - я о них уже писал)

🔻Коннекторы для интеграции с источниками данных об активах (анонсированы коннекторы для Active Directory и BMC Helix). Видимо раньше интеграции с AD не было. 🤷‍♂️

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме Пентест): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе. Что достаточно расставить агенты по хостам. А те хосты, куда агенты установить нельзя, например сетевые устройства, достаточно сканировать с аутентификацией. Дескать сканы без аутентификации всегда менее достоверны, чем сканы с аутентификацией, и нужны они только для сканирования периметра или первичной инвентаризации сети. На мой взгляд, это не совсем правильно. Сканировать без аутентификации на наличие известных уязвимостей, обязательно нужно, особенно в случае хостов с веб-приложениями.

И связано это именно с особенностями детектирования уязвимостей при сканировании с аутентификацией. Возьмём Linux-хосты. Как правило, VM-вендоры при сканировании Linux-хостов с аутентификацией ограничиваются детектированием уязвимостей в пакетах из официального репозитория Linux-вендора. 🤷‍♂️ Просто потому, что эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. Удобно. Научился работать с этим контентом и можно ставить галочку, что Linux-дистриб поддерживается VM-решением. А как насчёт уязвимостей софта, который отсутствует в официальном репозитории Linux-вендора? Вот тут всё сложнее.

Такой софт может быть установлен:

🔹 Из подключенного стороннего репозитория
🔹 Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост ручками
🔹 Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.)
🔹 Из средств распространения модулей (pip, conda, npm и т.д.)
🔹 Из образа контейнера (docker, podman и т.д.)
🔹 Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесён в виде бинарных файлов

В идеале, независимо от способа установки софта на хосте, сканер уязвимостей должен его корректно продетектировать, определить его версию, а по версии определить связанные уязвимости. 🧙‍♂️ Но на практике, из-за того что способов установки софта множество, это весьма нетривиальная задача. 🧐

В итоге мы получаем ситуацию: допустим, у нас есть какой-то коммерческий или опенсурсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Рыская по хосту по SSH этот софт не так-то просто надёжно найти. А при взгляде на хост извне, он ищется тривиально: сканируем порты, находим web-GUI, зачастую на главной странице находим версию и по ней детектируем уязвимости. При этом мы вообще не зависим от конкретного способа установки и запуска софта на хосте. Главное, что мы сам веб-интерфейс приложения видим. 🤩

Такие "внешние" правила детектирования уязвимостей и самим гораздо проще разрабатывать, и открытой экспертизой можно воспользоваться. Фингерпринтинг для получения CPE в сочетании с поиском в NVD по CPE это, конечно, грязный способ. Зато массовый. 😏 И если грамотно подтачивать и фингепринтилку, и правила детектирования по CPE, то и количество фолзов можно уменьшить до приемлемого уровня. А если ещё и добавить валидацию с помощью проверок с попыткой эксплуатации уязвимости (подтянуть nuclei тот же), то значительный набор уязвимостей можно будет детектировать более чем надежно. 😉

В общем, "пентест"-сканирование для определения известных уязвимостей - must have и для внутрянки тоже, особенно для веб-приложений.

Более 826 новых уязвимостей добавили в NVD за один день 3 мая

Более 826 новых уязвимостей добавили в NVD за один день 3 мая

Более 826 новых уязвимостей добавили в NVD за один день 3 мая. Картинка из сервиса CVE.icu, который визуализирует изменения NVD. Также есть выгрузка этих уязвимостей. Большую часть из них, 709, добавили ZDI. А чего это они вдруг? 🤔

В ноябре прошлого года у меня был пост, что ряд трендовых уязвимостей, которые репортили ZDI, отображаются в NVD как "CVE ID Not Found". Так вот, похоже гении из Trend Micro ZDI наконец обратили внимание на то, что их CVE-шки до NVD не доходят и решили это пофиксить таким вот массовым импортом проблемных CVEшек. 🤷‍♂️ При этом наглядно продемонстрировав масштаб бедствия. 🙂

Не, ну так-то лучше поздно, чем никогда. Но задержку между заведением ZDI-CAN идентификатора и появлением уязвимости в NVD теперь будет занятно посчитать. 😏 Например, для эксплуатируемой в фишинговых атаках RCE - WinRAR CVE-2023-40477 она составила 260 дней. 🤠

PS: окончательная цифра за 3 мая - 847 CVE, но не суть.

Выступление и дискуссия на PHDays 2024

Выступление и дискуссия на PHDays 2024

Выступление и дискуссия на PHDays 2024. В этом году я заявил на CFP рассказ про кризис в NVD (честно говоря, я предполагал, что к маю он закончится, но куда там 🌝) и развитие ресёрча уникальных уязвимостей БДУ. 👨‍💻

Но тема получила развитие и помимо доклада будет ещё и дискуссия по поводу национальных баз уязвимостей, которую сегодня упомянул у себя Алексей Лукацкий. 🎤

Планируем собрать представителей от БДУ, VM-вендоров, IT-вендоров, клиентов и обсудить:

🔹 Как нам жить в дивном мире, где американцы сначала политизировали ведение главной мировой базы уязвимостей, а теперь, как оказалось, вообще это не тянут? 🤷‍♂️

🔹 Чего нам не хватает в нашей российской базе БДУ? Как сделать её ещё полнее, а работу с ней ещё эффективнее? Как мы (каждый со своей стороны) можем этому способствовать?

🔹 Качество детектирования известных уязвимостей VM-продуктами. Удовлетворительно ли оно сейчас и как можно его улучшить?

В общем, приходите, должно получиться интересно. 🙂