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

5 моментов про отечественные Linux-дистрибутивы

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

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы. Каждый раз, когда появляется новость про российский Linux-дистрибутив в комментарии приходят хейтеры с криками "Bolgenos!". Типа это ненастоящий дистрибутив. Вот есть какие-то настоящие, а этот нет. Имею сказать следующее:

1. Даже тот самый мемный BolgenOS Дениса Попова по прошествии лет выглядит как вещь, которая вполне имела право на существование в качестве учебного проекта несколько странноватого, но вполне безобидного 16летнего парня. 🤷‍♂️ Ну сделал он сборку Ubuntu с нескучными обоями и переименованными приложениями (где-то вроде даже копирайты затер 😱). Ну сняли про него дурацкий репортаж на региональном ТВ. Это был повод для травли, вот серьёзно?

2. Если какие-то люди собрали очередной Linux-дистрибутив, допустим, на основе Debian, используют его сами и собираются его кому-то продавать, то они в своём праве. Даже если они (о ужас!) не собирают сами пакеты, а продают ванильный Debian с налепленным своим логотипом. Вот даже тогда. Насколько мне известно, ничто сейчас не запрещает это делать. Ни российское законодательство, ни требования регуляторов, ни даже опенсурсные лицензии.

3. Если с этим Linux-дистрибутивом можно комфортно и относительно безопасно (в смысле оперативного исправления уязвимостей, отсутствия явных закладок, обновления с российских серверов) работать, то в общем-то и норм. Если вдруг почему-то нельзя, то это хорошая тема для предметного обсуждения. Ну ещё неплохо бы бюллетени безопасности в формате OVAL, чтобы уязвимости было удобно детектировать. 😇

4. Если маркетинг компании, которая выпустила Linux-дистрибутив, позволяет себе в официальной коммуникации писать, что это какая-то уникальная отечественная ОС, разработанная с нуля, то это, имхо, скверно и достойно порицания. Но на сам дистрибутив это никак не влияет.

5. Я не верю в какие-то прям "хорошие Linux-дистрибутивы". Это ВСЕГДА переупакованный ЧУЖОЙ код от апстримов. В этом отношении прилетела ли ко мне программная закладка непосредственно от разработчика (например, XZ Utils или самого Торвальдса) или от Debian-ов мне, как потребителю, как-то пофигу. В возможности всерьёз контролировать апстрим я не верю. Если вы так здорово закладки можете выявлять, почему вы тогда Linux-овые уязвимости не выявляете? Сотни Linux-овых уязвимостей исправляются каждый месяц, что же вы их не выявляете сами раньше разработчиков? 😏 Использование Linux и опенсурсного софта это всегда некоторый компромисс функциональных возможностей и безопасности. Лучше бы, конечно, своё ядро. Лучше бы, конечно, чтобы и системные компоненты свои. И прикладной софт свой. А раз этого всего нет и не ожидается, то и чего щёки надувать, что вы принципиально лучше тех самых "болгеносов"? 😏

Возможно ли использовать AI для детектирования уязвимостей?

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

Возможно ли использовать AI для детектирования уязвимостей?

Возможно ли использовать AI для детектирования уязвимостей? Думаю да, но тут нужно определиться, что мы под этим понимаем.

🔻 Если речь идёт об обнаружении ранее неизвестных уязвимостей, о ресёрче, то здесь AI инструменты работают уже сейчас. Буквально на днях, 1 ноября, исследователи из Google Project Zero обнаружили первую реальную эксплуатабельную уязвимость с помощью своего LLM проекта Big Sleep. Это была stack buffer underflow в SQLite. Очень круто и многообещающе. 👍

🔻 Если же речь идёт об известных (CVE) уязвимостях, то задача сводится к генерации чётких правил их детектирования в инфраструктуре. AI должен взять на вход имя продукта и вендора, обнаружить источник данных об уязвимостях, понять структуру данных и как можно из них сгенерировать формальные правила для детектирования (например, на языке OVAL), произвести генерацию и оценить корректность правил. Не выглядит как что-то невероятное, но практических реализаций этого я пока не встречал. 🤷‍♂️

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

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

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

CVE-идентификаторы с пробелом в OVAL-контенте RedOS. В ходе подготовки отчёта по октябрьскому Linux Patch Wednesday обнаружил, что у меня откуда-то лезут невалидные CVE-идентификаторы с пробелом в конце. Источником оказался OVAL-контент RedOS (7.6 мб). По находится 115 таких проблемных ссылок на CVE. Вряд ли это ошибки при ручном заполнении, видимо ошибка в последних версиях генератора OVAL-контента.

Если вы используете OVAL-контент RedOS, обратите внимание, что такое может быть и потенциально может аффектить Vulnerability Management процесс.

Просьба коллегам из РЕД СОФТ пофиксить проблему и накрутить тесты, что используемые CVE-идентификаторы матчатся регуляркой.

Upd. Коллеги из РЕД СОФТ быстро отреагировали и проблему исправили. 🙂👍

Размышляю о развитии Scanvus

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

Размышляю о развитии Scanvus

Размышляю о развитии Scanvus. Давненько не было обновлений проекта. Так-то понятно, что опекать конкретную инфру мне стало не нужно, поэтому приоритизирующий уязвимости Vulristics мне стал важнее, чем детектирующий их Scanvus. 🤷‍♂️ Однако проблема оценки качества детектирования уязвимостей никуда не делась, поэтому и необходимость в "прозрачном" (и желательно бесплатном 😏) сканере остаётся.

Подход к интерпретации OVAL-контента в рамках Vuldetta показал, что хоть это делать и можно, но местами довольно хлопотно (для уязвимостей ядра например).

Использовать для детектирования OpenSCAP было бы гораздо проще. В этом случае задачей Scanvus было бы зайти на хост, определить версию дистрибутива, найти инсталляцию OpenSCAP, скачать и загрузить на хост актуальный OVAL-контент, запустить утилиту OpenSCAP, забрать и отобразить отчёт сканирования.

Мне кажется, что такой "агентный" режим работы имеет смысл реализовать.

Поделюсь своими грустными мыслями по поводу RedOS в связи с Linux Patch Wednesday

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

Поделюсь своими грустными мыслями по поводу RedOS в связи с Linux Patch Wednesday

Поделюсь своими грустными мыслями по поводу RedOS в связи с Linux Patch Wednesday.

🔹 С одной стороны, РЕД СОФТ большие молодцы, так как добавляют в своими репозитории пакеты прикладного софта, которых нет у других Linux-вендоров, и поддерживают детекты уязвимостей для них в OVAL-контенте. Причём добавляют новые сборки пакетов с исправленными CVE-шками очень оперативно.

🔹 С другой стороны, они, видимо, не особо смотрят какие именно CVE-шки исправил вендор софта и относятся ли эти CVE-шки к Linux-у. 🤷‍♂️ Поэтому возникают казусы, которые видны, например, в августовском Linux Patch Wednesday.

Что там в ТОП-е?

🔻 Remote Code Execution - PHP (CVE-2024-4577). Которая связана с функцией преобразования кодировки Best-Fit в операционной системе Windows. 😏 Исправлена в RedOS.

🔻 Remote Code Execution - Mozilla Firefox (CVE-2024-2605). "An attacker could have leveraged the Windows Error Reporter to run arbitrary code". 😌 Исправлена в RedOS.

🔻 Command Injection - Rust Standard Library (CVE-2024-24576). "who invoke batch files on Windows with untrusted arguments". 😣 Исправлена в RedOS.

То есть отчёт по Linux Patch Wednesday замусоривается уязвимостями, которые эксплуатируются только в Windows.

Как на моём уровне с этим бороться непонятно. Моя концепция, которая лежит в основе Linux Patch Wednesday, "Linux-овые уязвимости - это уязвимости, которые исправляют Linux-овые вендоры" в этом случае трещит по швам. А отказываться от RedOS как от источника данных тоже не хотелось бы (см. первый пункт про то, что РЕД СОФТ молодцы). Остаётся только закрывать на часть уязвимостей глаза и страдать. 🫣😔

Другие Linux-вендоры бюллетени (и OVAL-definition-ы) об исправлении виндовых уязвимостей не выпускают. Они обычно имеют страницу по каждой CVE. И если CVE не аффектит Linux-овую версию софта, то в бюллетень она не попадает. Было бы здорово, чтобы RedOS также эту практику пересмотрели.

Если у кого-то из подписчиков есть выход на людей, которые бюллетенями безопасности и OVAL-контентом в РЕД СОФТ занимаются, скиньте им, пожалуйста, этот пост. Буду рад познакомиться и пообщаться.

Linux Patch Wednesday: вот где этот майский пик!

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

Linux Patch Wednesday: вот где этот майский пик!

Linux Patch Wednesday: вот где этот майский пик! 🤦‍♂️ Также об июньском Linux Patch Wednesday. Помните, я в посте про майский Linux Patch Wednesday радовался, что, несмотря на введение правила по Unknown датам, пик в мае был незначительный. Хотя "32 406 oval definition-ов без даты получили номинальную дату 2024-05-15". Оказалось пик не был виден из-за ошибки в коде. Ба-дум-тсс! 🥸🤷‍♂️

То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Linux-ового OVAL-контента действительно раскидываются по бюллетеням. Включая CVE-2024-1086. Вот она в феврале:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json:        "CVE-2024-1086": [
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",

Ну и пик в мае действительно есть. Да ещё какой! 11 476 CVE! 😱 Настолько много, что я перегенерил Vulristics отчёт для него только с использованием 2 источников: Vulners и БДУ. И даже из Vulners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Execution - Apache HTTP Server (CVE-2021-42013), я не буду подробно их разбирать - кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday (31.3 мб.)

Что касается июньского Linux Patch Wedneday, который финализировался 19 июня, то там 1040 уязвимости. Тоже довольно много. Почему так? С одной стороны правило по Unknown датам добавило 977 Debian-овских OVAL дефинишенов без даты. Не 30к, как в мае, но тоже значительно. Из 1040 уязвимостей 854 это уязвимости Linux Kernel. Причём, довольно много "старых" идентификаторов уязвимостей, но заведенных в 2024 году. Например, CVE-2021-47489 с NVD Published Date 05/22/2024. 🤔 Что-то странное творит CNA Linux Kernel.

🔻 С признаками эксплуатации вживую опять Remote Code Execution - Chromium (CVE-2024-5274, CVE-2024-4947), как и Microsoft Patch Tuesday. Судя по данным БДУ, Remote Code Execution - Libarchive (CVE-2024-26256) также активно эксплуатируется.

🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Execution - Cacti (CVE-2024-25641) и Remote Code Execution - onnx/onnx framework (CVE-2024-5187).

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday (4.4 мб.)

upd. 30.06 Обновил отчёт.

Узнал про услугу Kaspersky "Поток машиночитаемых данных Kaspersky Industrial Vulnerability Data Feed в формате OVAL"

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

Узнал про услугу Kaspersky Поток машиночитаемых данных Kaspersky Industrial Vulnerability Data Feed в формате OVAL

Узнал про услугу Kaspersky "Поток машиночитаемых данных Kaspersky Industrial Vulnerability Data Feed в формате OVAL". Оказывается у них есть компетенции в разработке OVAL-контента, круто! 🙂👍

Доступна свежая видяшка, в которой они демонстрируют работу проверок на Windows 7 хосте. Причём для демонстрации используется утилита ovaldi (заброшенная с 2015 года 😏). И всё работает! 😳 Судя по видяшке, в контенте 1021 дефишен, получается где-то 819 детектов уязвимостей для 202 продуктов от Siemens, Schneider Electric, Yokogawa, ABB, Emerson, GE, ARC, Codesys, AVEVA, OPC, ЭКРА, НПФ «ИнСАТ» и других вендоров.

Я так понимаю, что контент демонстрировали на ovaldi, чтобы показать его валидность. В проде же предлагают использовать этот контент в Kaspersky Security Center, который, оказывается, поддерживает OVAL проверки через Endpoint Agent (но нужна доп. лицензия на ICS Audit 🤷‍♂️).