Архив рубрики: Темы

А как собственно изменилась работа с уязвимостями в 2022 году?

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

А как собственно изменилась работа с уязвимостями в 2022 году? Возвращаясь к названию исследования Positive Technologies. Как я вижу.

1. Раньше было страшно не успеть обновиться и получить инцидент с эксплуатацией уязвимости. Теперь ещё страшно обновиться и получить кирпич или бэкдор, потому что вендор решил прогнуться под геополитику. Эти страхи борются. Сейчас ситуация несколько стабилизировалась и первый страх побеждает. Что завтра будет неизвестно.
2. Замена ПО на стабильное (отечественное) выглядит как избавление от второго страха и возврат к более простому и надежному процессу. VM-щики могут этому способствовать, но их слово вряд ли будет решающим. Более значима позиция регуляторов, бизнеса и IT.
3. Переход на стабильное (отечественное) ПО совсем не обязательно будет простым с точки зрения VM. Есть сомнения в зрелости вендоров ПО. Заводят ли они уязвимости своих продуктов в БДУ? Выпускают ли бюллетени безопасности? Если не будет идентификаторов уязвимостей и бюллетеней, значит не может быть адекватной поддержки в VM решениях. Хотелось бы, чтобы регуляторы обращали на это внимание и выдвигали такие требования к сертифицированным решениях и решениям находящимся в реестрах.
4. С VM-решениями стало хуже. Западные вендоры официально ушли, продолжать использовать их решения теоретически можно, но сложно и они становятся менее эффективны с учетом перехода организаций на стабильное (отечественное) ПО, которое в западных VM-решениях не поддерживается. Для приобретения VM решения доступно сейчас 3-4 опции и стоимость у них отнюдь не как у Nessus Professional. Нужно раскошеливаться или проявлять изобретательность. А скорее и то, и другое.
5. Регуляторы начали уделять гораздо больше внимания исправлению уязвимостей в организациях. С информированием стало на порядок лучше. Не удивлюсь, если скоро мы увидим ещё и жесткий публичный ататат за неисправление уязвимостей, о которых было проинформировано, приведшее к серьезным инцидентам. С одной стороны ответственность растет, а с другой стороны и обосновывать важность VM-а становится гораздо проще.

Прочитал исследование Positive Technologies "Как изменилась работа с уязвимостями в 2022 году"

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

Прочитал исследование Positive Technologies Как изменилась работа с уязвимостями в 2022 году

Прочитал исследование Positive Technologies "Как изменилась работа с уязвимостями в 2022 году". Впечатления не очень. Компания мне родная. Особенно команда VM. Но тут вопросы не к ним, а к авторам этого исследования.

1. Мое мнение, что любая публикация про Vulnerability Management в России это здорово. Особенно если это исследование, а не рекламный проспект. Это порождает дискуссию, подсвечивает проблемные места и в конечном итоге улучшает качество продуктов и конкурентоспособность отечественных VM компаний.
2. В данном случае методология исследования вызывает вопросы. Публичный опрос на "сайте Positive Technologies, интернет-порталах, посвященных ИБ, в социальных сетях, тематических чатах и Telegram-каналах" с интерпретацией результатов автором отчета это не то, что хотелось бы видеть. Это делать дешево и просто, но при этом напрочь теряется контекст.
3. Формулировки вопросов странные. "Какие продукты вы используете для управления уязвимостями?" Множественный выбор. 43% "используют решения open-source". – Петька, приборы! – 20! – Чё "20"?! – А чё "приборы"? О чем здесь речь? Сканируют ли сетку nmap-ом? Используют опенсурсные утилиты для детекта уязвимостей? OpenVAS? OpenSCAP/Wazuh? Есть что-то достаточно хорошее опенсурсное для сканирования Windows? Может это не про детект, может просто результаты детекта в опенсурсный Faraday складывают?
4. Варианты ответов неполные. На вопрос "Где вы ищете информацию о новых уязвимостях?" получили аномалию, что БДУ ФСТЭК используют больше чем NVD. Переходим на отечественные источники! Как тебе такое Илон Маск?! Но в вариантах ответа нет важного в нашей стране источника данных об уязвимостях - бюллетеней регуляторов. Они как раз и содержат ссылки на БДУ. Может результаты показывают не то, что люди БДУшный фид анализируют, а то, что они реагируют на рассылки регуляторов и лезут потом в БДУ?
5. Формулировки выводов странные. "Проблемы с организацией патч-менеджмента остаются у каждого десятого респондента." А у 90% нет проблем с организацией патч-менеджмента? Все автоматом патчится-тестится, VM не нужен, расходимся?
6. Вопросы "как быстро вы это делаете ?" - просто песня. Это как, извините, в анекдоте про разницу в размерах у жителей в Вилариба и Вилабаджо. В одной деревне измеряли, а в другой опрашивали. Абстрактные уязвимости на абстрактных активах исправляются за какое-то время. Получили, что 75% опрошенных закрывают критически опасные уязвимости на важных активах за неделю и меньше! А в месяц укладываются 90%! При этом на фултайме VM-ом практически никто не занимается. "Какой процент рабочего времени занимают задачи специалиста по ИБ, связанные с VM?" Свыше 75% процентов только у 4% опрошенных. Удивительно!
7. Раздел "Какими возможностями должно обладать VM-решение для вашей компании?" норм. Важные фичи перечислены. Есть некое лукавство, очень уж они похожи на фичи и бэклог MaxPatrol VM, но это ладно. Если бы весь опрос был преимущественно в эту сторону и опрашиваемые могли предлагать свои варианты, то это могло быть любопытно.

Критикуешь - предлагай. Кажется правильным изменить методологию. Не опрашивать всех подряд. Работать адресно с людьми, которые специализируются на VM-е. Собрать экспертную группу. В рамках этой экспертной группы отобрать человек 50. Провести с ними полноценные интервью минут на 30. Задавать примерно те же вопросы, но получить развернутые ответы, а не выбор вариантов из опросника. В чем трудности VM-а? Что работает, что не работает? Спрашивать о фиксах конкретных актуальных уязвимостей, например Log4Shell или ProxyShell, как с ними справлялись? Как устроен процесс патчинга? Как патчатся неудобные активы: BIOS/UEFI, прошивки устройств и т.п.? Да, такие ответы будет сложнее и дороже анализировать. Но будет видна более-менее реальная картина. Возможно какие-то best practices можно будет сформулировать. Ну и вопросы, а затем и результаты, неплохо бы с экспертной группой провалидировать, чтобы исключить откровенные странности и ляпы.

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910

1 комментарий

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910. Прочитал исследование. Может я что-то не понял, но похоже из мухи слона делают. Описание-то прямо страшное: "Jamf Threat Labs recently discovered a new macOS vulnerability in Archive Utility that could lead to the execution of an unsigned and unnotarized application without displaying security prompts to the user, by using a specially crafted archive". Можно подумать, что скачал пользователь архив, кликнул по нему случайно и всё, похачен.

На самом деле там пишут про вот этот механизм macOS:

"Когда архив загружается из Интернета, он будет содержать расширенный атрибут com.apple.quarantine. Этот расширенный атрибут укажет macOS, что файл был загружен из удаленного источника и должен быть проверен, прежде чем будет разрешено его выполнение. Когда утилита архивирования извлекает архив, она применяет атрибут карантина ко всем извлеченным элементам. Это обеспечивает соответствующее распространение атрибута карантина и проверку Gatekeeper-ом любых открытых исполняемых файлов".

И вот простановку атрибута com.apple.quarantine (и проверку Gatekeeper) исследователи научились обходить.

"Когда пользователь загружает и запускает такой архив, он будет открыт Archive Utility в следующем виде. [картинка] Как мы видим, приложение не имеет атрибута карантина и, следовательно, будет обходить все проверки гейткипера, позволяя выполняться unnotarized a и/или неподписанным двоичным файлам."

То есть пользователь должен скачать архив и запустить оттуда зловредное приложение и тогда ему не дадут по рукам встроенные механизмы безопасности. Но возможно дадут по рукам какие-то другие механизмы безопасности.

В общем, уязвимость это? Уязвимость. Критикал ли это, который нужно срочно патчить? Ну вроде нет. Возможно повод научиться искать подобные архивы в почте.

Интересный пост вышел вчера в блоге Qualys

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

Интересный пост вышел вчера в блоге Qualys. Про устаревшие активы. Суть в следующем. В ходе эксплуатации Vulnerability Management системы в неё добавляются активы. В основном сетевые хосты, но в случае Qualys не только. На них каким-то образом, агентно или безагентно детектируются уязвимости. И вот по какой-то причине данные по некоторому активу перестают обновляться. Как правило, это связано с тем что актива больше нет. Сервер выключили, виртуалку удалили, десктоп перезалили и т.п. А в интерфейсе Qualys актив продолжает отображаться, для него показываются уязвимости, он в лицензии учитывается. Непорядок.

И какую же функциональность предлагает Qualys для решения этой проблемы? Во-первых отображают активы в дашборде, с разбивкой по дате последнего обновления данных. Уже неплохо. Как минимум можно поресерчить что с этими активами случилось. Во-вторых можно настроить правила, которые будут активы неактивные больше N дней удалять. Это конечно не самое хорошее решение, десятки дней терпеть в VM-е зомби-хосты и неисправляемые уязвимости на них. Но зато просто. И эти правила не работают для "IP/DNS/NetBIOS tracked scanned assets (no Cloud Agent)", для них там ручной метод предлагается.

Но, имхо, самое лучшее решение, о котором в посте не пишут это забирать актуальные статусы активов непосредственно из IT-систем через которые они управляются, залезать в VM решение по API и оперативно подчищать неживое. Благо у Qualys API мощный и такие штуки можно делать без проблем. Кастомная автоматизация рулит! 🙂

Занимательно порефлексировать над очередным набросом Дурова на WhatsApp

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

Занимательно порефлексировать над очередным набросом Дурова на WhatsApp. Он там делает далеко идущие выводы, что очередная исправленная RCE уязвимость в WhatsApp это на самом деле умышленно добавленный бэкдор. 🙂 И что эта уязвимость давала доступ ко всем файлам на телефоне пользователей. И поэтому ради безопасности своих данных не пользуйтесь WhatsApp-ом.

Нет, ну что такая атака с использованием WhatsApp в принципе возможна, мы ещё по кейсу с Pegasus от NSO Group помним. Но не настолько же все тривиально! То, что используется в десятках таргетированных атак вряд ли будет долго и массово использоваться против простых обывателей.

С тем же успехом можно сказать, что, например, уязвимость в виндовом клиенте Telegram это тоже был бэкдор. 🙂

С другой стороны, является ли смартфон с удаленным ватсапом или даже телеграммом безопасным устройством? Нет конечно! Он как был убогой пальцетыкалкой с нелепым обрубком вместо операционной системы так и остался. Обрубком, который был вкорячен на конкретную железку матюками и грязными хаками, так что поставить туда что-то альтернативное в общем случае не получится, только попользоваться пару лет и выкинуть. На каждый чих по приложению требующему максимум прав. Дичь ведь. И всё это намертво завязано на американский бигтех и им же полность контролируется. Использовать смартфон с Android или iOS для чего-то чем вы не готовы сейчас же поделиться со всем миром это очень плохая идея. Если вы так делаете, прекращайте.

Собственно вот и обещанный пост про OpenSCAP

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

Собственно вот и обещанный пост про OpenSCAP. Демонстрирую как можно просканить хост на уязвимости с помощью OpenSCAP и бесплатного официального OVAL контента для Ubuntu. Также пробую разнести сбор данных и их анализ с помощью System Characteristics. Не без багов, но работает. Можно ли будет генерить файлы System Characteristics самостоятельно без утилиты oscap, только по собранным пакетам и версии ОС? Так чтобы на основе OpenSCAP сделать бесплатную API-шку совместимую со Scanvus? 🤓 Хе-хе, посмотрим. Но пока выглядит как достаточно перспективная задумка. Следите за обновлениями, ну и если кто хочет поучаствовать в благом деле, пишите в личку (@leonov_av).

Итак, вы решили начать разработку своего Vulnerability Management решения

2 комментария

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 3. На чем можно срезать углы?

Подводные камни подсветили, специализаций коснулись. В этой завершающей части посмотрим как можно быстро слепить VM-решение из того, что есть в паблике:

1. Весьма соблазнительно взять опенсурсный сканер и, несколько доработав его, начать продавать как коммерческий продукт или сервис. Например, взять OpenVAS/GVM, Nuclei, Nmap. Однако следует понимать, что вместе с наработками придется брать в нагрузку и немалое легаси. И возможно реализовать какую-то конкретную функциональность с нуля было бы проще, чем поддерживать форк проекта с историей. Кроме того за успешным опенсурсным сканером, как правило, стоит коммерческая компания, которая этот проект уже монетизирует и конкурентам не рада. Стоит ожидать, что вам будут вставлять палки в колеса, например через хитрое лицензирование (Nmap) или ограничение бесплатного публичного фида с детектами (OpenVAS/GVM). И тут уж как впишитесь.
2. Часто для того, чтобы по-быстрому добавить детектирование уязвимостей реализуют такую схему: детектирование CPE идентификатора установленного софта и поиск уязвимостей в базе NVD. Просто, быстро, универсально. Но далеко не всегда достоверно, т.к. ошибки могут быть и при детектировании CPE, и описании уязвимой конфигурации в NVD. Да и не всё всегда определяется версиями софта, свою роль могут играть патчи и их перекрытия. Продемонстрировать как такая схема работает можно на примере Nmap + Vulners plugin. Nmap тут отвечает за детект CPE, а Vulners за поиск по NVD.
3. Отдельная большая тема это SCAP/OVAL. Если кратко, то это набор открытых спецификаций для описания уязвимостей/мисконфигураций и того как их по этому описанию детектировать. Есть много бесплатного публичного контента: репозиторий CIS, DISA STIGs, профили PCI DSS от OpenSCAP, Windows уязвимости в коненте от ФСТЭК/АЛТЭКС-СОФТ, вендорский контент для Ubuntu, Debian, RHEL. Есть как минимум один опенсурсный SCAP/OVAL сканер, который все ещё развивается, это OpenSCAP от RedHat. Есть старые заброшенные проекты ovaldi и jovaldi. C открытыми SCAP/OVAL сканерами под Windows все традиционно тяжко, OpenSCAP в этом направлении шел, но не так давно под Windows его перестали поддерживать. Следует отметить, что продвигается эта тема в первую очередь американцами для контроля безопасности их государственной инфры (для военных и федеральных агентств в основном). Чуть менее чем все вакансии по SCAP/OVAL открываются в США и требуют американское гражданство и clearance, что намекает. 😉 Также они навязывают VM-вендорам поддерживать SCAP/OVAL, что те и делают, кто-то более формально, кто-то менее. В общем, есть соблазн в это дело крепко влезть, чтобы реюзнуть наработки. И есть как минимум одна success story у кого это получилось - RedCheck от АЛТЭКС-СОФТ. Также можно привести в пример индийскую компанию Secpod. Из минусов - спецификации там не особо простые и удобные, делать всё строго по ним достаточно тяжко, особенно реализовывать нестандартные проверки для нестандартных систем.

На этом мини-цикл про разработку VM я заканчиваю, но тему сканероделания конечно не оставляю. Дальше как раз планирую в очередной раз погружаться в SCAP/OVAL, следующий плановый эпизод будет про детектирование уязвимостей с помощью OpenSCAP.