Время начала моего выступления и дискуссии по базам уязвимостей на PHDays сместилось на 35 минут: теперь стартуем 24 мая (пятница) в 16:25 в локации Галактика. Надеюсь, что больше изменений не будет, но если что, отпишу в канал. 🙂 Также можете уточнять в интерактивной программе мероприятия (выделил фильтрами день и трек "Государство").
Записи c VulnCon 2024 доступны на Youtube. Я об этой конфе уже писал ранее, она прошла в конце марта.
Там много интересного контента связанного с уязвимостями: их описание, приоритизация, ответственное разглашение, разнообразные связанные стандарты. 🤩 Кейсы про управление уязвимостями в организациях тоже есть. В России такого контента пока маловато. У нас если и говорят об уязвимостях, то скорее обсуждают конкретные ресерчи или атаки, а не то, как работать с уязвимостями более-менее массово и систематически. 😔
Описание докладов также доступно в программе конференции. Там удобно подыскивать интересное, а потом уже смотреть запись в Youtube канале.
Есть там и панельная дискуссия с Tanya Brewer из NIST. Но что-то откровений про кризис NVD, которые ей приписывали в статье по итогам VulnCon ("story behind it, it is long, convoluted and very administrivia" и т.п.) я не нашёл. Искал по автоматическим субтитрам. Ну, может это было сказано не на панельке, а где-то ещё. 🤷♂️
Мой доклад на PHDays "Кризис NVD и светлое БуДУщее" пройдёт 24 мая (Пятница) в 16:25–17:10 в локации Галактика. На сайте PHDays уже доступно расписание.
В рамках доклада рассмотрим:
🔹 Как ретроспективно развивался кризис NVD, реакцию на него со стороны сообщества безопасников и текущее состояние.
🔹 Какие меры предлагались сообществом для уменьшения зависимости от NVD, чтобы такая ситуация в будущем не могла повториться.
🔹 Оценку текущего состояния NVD и БДУ ФСТЭК: возможно ли для российских организаций использовать только БДУ?
🔹 Уязвимости, которые присутствуют только в БДУ ФСТЭК: общее количество, распределение по годам, типы уязвимостей, уязвимые продукты.
Сразу после доклада в 17:20–18:20 в той же локации будет дискуссия "Источники данных об уязвимости в современных реалиях" с моим участием (и модерированием).
upd. 22.05 Обновил время начала
Детектирование известных (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 мая. Картинка из сервиса 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. В этом году я заявил на CFP рассказ про кризис в NVD (честно говоря, я предполагал, что к маю он закончится, но куда там 🌝) и развитие ресёрча уникальных уязвимостей БДУ. 👨💻
Но тема получила развитие и помимо доклада будет ещё и дискуссия по поводу национальных баз уязвимостей, которую сегодня упомянул у себя Алексей Лукацкий. 🎤
Планируем собрать представителей от БДУ, VM-вендоров, IT-вендоров, клиентов и обсудить:
🔹 Как нам жить в дивном мире, где американцы сначала политизировали ведение главной мировой базы уязвимостей, а теперь, как оказалось, вообще это не тянут? 🤷♂️
🔹 Чего нам не хватает в нашей российской базе БДУ? Как сделать её ещё полнее, а работу с ней ещё эффективнее? Как мы (каждый со своей стороны) можем этому способствовать?
🔹 Качество детектирования известных уязвимостей VM-продуктами. Удовлетворительно ли оно сейчас и как можно его улучшить?
В общем, приходите, должно получиться интересно. 🙂
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.
