Журнал "Information Security/ Информационная безопасность" #1, 2025

l Неправильная реализация функции сравнения версий пакетов (например, не учитывают эпоху – наиболее значи- мую часть версии пакета). l Неправильный источник безопасных версий пакетов (когда в бюллетенях source-пакеты, а от них нужно перейти к версиям бинарных пакетов). Это приводит к тому, что сканер одного VM-вендора может сообщить, что пакет, установленный на хосте, имеет уязвимую версию. А сканер другого вендора может сообщить, что этот пакет неуязвим. Всё из-за того, что функция сравнения рабо- тает некорректно или сравнение идет не с теми безопасными версиями паке- тов. Особенно наглядно получится, если проверить один Linux-хост несколькими сканерами. В случае расхождений каж- дый VM-вендор будет говорить, что его результаты правильные, пока не будет доказано обратное. А доказать бывает не так просто. Но допустим, что эта часть детектов реализована у VM-вендора корректно. Достаточно ли детектов на основе бюлле- теней безопасности Linux-вендора для того, чтобы VM-вендор мог со спокойной совестью заявлять о поддержке Linux- дистрибутива своим сканером? Не совсем. Детектирование уязвимостей для Linux-софта не из официального репозитория вендора ОС Софт в Linux может быть установлен разными способами, например: l из подключенного стороннего репози- тория; l пакета (вендорского или собранного самостоятельно) стандартной пакетной системы дистрибутива (deb, rpm); l альтернативных пакетов для распро- странения софта (Snap, Flatpak, AppI- mage и т. п.); l средств распространения модулей (pip, conda, npm и т. п.); l образа контейнера (Docker, Podman и т. п.); l исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесен в виде бинарных файлов. Независимо от способа установки софта на хосте, предполагается, что ска- нер должен корректно продетектировать уязвимости. Естественно, никакой инфор- мации по уязвимостям в софте, установ- ленном такими способами, у Linux-вен- дора не будет. И, чтобы продетектировать уязвимости в нем, VM-вендору необхо- димо: l найти информацию об уязвимостях софта у вендора этого софта; l превратить эту информацию в правила детектирования уязвимостей; l научиться детектировать версию софта, установленного на хосте, для каждого варианта установки; l реализовать детектирование в соот- ветствии с правилами. Это весьма нетривиально и трудоемко. И все это ради того, чтобы продвинутый сканер уязвимостей корректно проде- тектировал уязвимости на том хосте, на котором сканер попроще ничего не най- дет. Немногие пользователи оценят такой внимательный подход к нюансам детектирования уязвимостей, поэтому и немногие VM-вендоры готовы в это инве- стировать. Что же делать в такой ситуации поль- зователю? Если вы понимаете, что ваш сканер не настолько хорош в части детектирования уязвимостей для Linux, следует самим следить за тем, что весь софт на Linux-хостах устанавливается из официального репозитория, и софта, установленного иначе, нет. Если такой софт есть – меняем инфраструктуру или думаем, как расширить способы детектирования. О важности детектирования без аутентификации Есть мнение, что при детектировании уязвимостей внутренней ИТ-инфраструк- туры организации сканировать без аутентификации не нужно. Достаточно расставить агенты по хостам. А те хосты, на которые агенты установить невоз- можно, например сетевые устройства, достаточно сканировать с аутентифика- цией. Это аргументируется тем, что ска- нирование без аутентификации всегда менее достоверно, чем сканирование с аутентификацией, и требуется оно толь- ко для аудита сетевого периметра или первичной инвентаризации внутренней сети. Однако, именно из-за многообра- зия способов установки ПО сетевое ска- нирование без аутентификации часто оказывается полезным в качестве допол- нительного способа детектирования, осо- бенно в случае хостов с веб-приложе- ниями. Допустим, у нас есть коммерческий или опенсорсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Получив доступ к хосту по SSH, этот софт не так- то просто найти за ограниченное время сканирования. А при взгляде на хост извне он ищется тривиально: сканируем порты, находим веб-интерфейс, зача- стую на главной странице находим вер- сию софта и по ней детектируем уязви- мости. В этом случае детект вообще не зависит от конкретного способа уста- новки и запуска софта на хосте. Главное, что веб-интерфейс приложения доступен для анализа. Такие "внешние" правила детектиро- вания гораздо проще разрабатывать. Кроме того, можно воспользоваться пуб- лично доступной экспертизой. Фингер- принтинг для получения CPE-идентифи- катора1 софта в сочетании с поиском уязвимостей в NVD по CPE-идентифи- катору – это, конечно, не самый надеж- ный способ детектирования уязвимостей, зато простой и универсальный. И если улучшать и фингерпринтинг и правила детектирования по CPE-идентификато- рам, то количество ошибок детектиро- вания можно уменьшить до приемлемого уровня. А если еще добавить валидацию уязвимостей с помощью проверок с попыткой эксплуатации (например, используя nuclei), то для значительной части уязвимостей надежность детекти- рования станет еще выше. Именно такой способ баннерных детектов с подтвер- ждением с помощью nuclei реализован в MaxPatrol VM начиная с версии 2.5. Почему VM-специалисту важно проверять качество детектирования уязвимостей? К сожалению, большинство VM-спе- циалистов относится к качеству детек- тирования уязвимостей формально. Они полностью доверяют полученным резуль- татам сканирования и не стимулируют VM-вендоров улучшать качество детек- тирования. Цель работы VM-специалиста в том, чтобы уязвимости в ИТ-инфра- структуре организации устранялись до того, как злоумышленники попытаются их проэксплуатировать в атаках. Но этой цели нельзя достичь, если получаемый набор продетектированных уязвимостей неполон и недостоверен. Таким образом, ситуация с недостаточным детектирова- нием и, как следствие, устранением уязвимостей тянется вплоть до реальных инцидентов, ответственность за которые ложится на VM-специалистов. А VM-вен- доры при этом не несут издержек, что создает порочный круг, в котором теряет- ся весь смысл процесса управления уязвимостями. Поэтому призываю вас включить непрерывную оценку качества детекти- рования уязвимостей в состав VM-про- цесса и руководствоваться качеством детектов при выборе VM-решений. l • 15 Управление Уязвимостями www.itsec.ru Рис. 2. Уровень опасности уязвимо- стей, обнаруженных в российскомПО Ваше мнение и вопросы присылайте по адресу is@groteck.ru Источник: Positive Technologies 1 CPE – это структурированная схема именования информационных систем, программного обеспечения и пакетов.