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

В двух словах о Security Vision Vulnerability Scanner

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

В двух словах о Security Vision Vulnerability Scanner

В двух словах о Security Vision Vulnerability Scanner. Коллеги из Security Vision запустили видео-рубрику "В двух словах", в рамках которой рассказывают о ключевых возможностях продуктов компании, о том, как они защищают бизнес и помогают ему развиваться. В первом выпуске Альбина Михалёва, менеджер по работе с партнёрами, рассказала о Security Vision Vulnerability Scanner (VS).

Видео, естественно, высокоуровневое и маркетинговое. Но для понимания позиционирования решения компании - весьма любопытное. 😉

Security Vision Vulnerability Scanner - это инструмент для поиска уязвимостей в вашей инфраструктуре, использующий собственный движок. Он проверяет: операционные системы, прикладное ПО, сетевые устройства, базы данных, контейнеры. Сканирование можно проводить с агентом или без него. Поддерживаются российские ОС (Астра Линукс, Альт Линукс, РЕД ОС). Работает на основе ведущих баз уязвимостей (ФСТЭК, NVD и других).

🔑 5 ключевых особенностей продукта

1. Продвинутые режимы сканирования. Белый ящик для аудита защищённости. Чёрный ящик (пентест) с более чем 80 экспертных скриптов для проверки эксплуатации уязвимостей, подбора слабых паролей и проверки устаревших алгоритмов шифрования. Мой коммент: если всего 80 сейфчеков, то звучит как-то недостаточно. 🤷‍♂️

2. Специализированные проверки. Сканирование веб-приложений на XSS, SQL-инъекции и другие уязвимости из OWASP Top 10. Проверки контейнеров Docker и Kubernetes. Retro Scan - мгновенный поиск по ранее собранным данным без повторного подключения к активам.

3. Мультисканер и работа в изолированных сетях. Поддерживается одновременная работа с любыми (Мой коммент: тут, естественно, не совсем с любыми, а с теми, для которых интеграции запилены 😉) сторонними решениями (MaxPatrol, Tenable, Nessus, Qualys и др.). Для изолированных сегментов без прямого доступа есть отчуждаемый агент и цепочка прокси-компонентов.

4. Граф достижимости уязвимостей. Система анализирует правила межсетевых экранов и маршрутизацию, показывает, какие уязвимости реально доступны атакующему. Это помогает точнее оценивать реальные риски.

5. Умная приоритизация. Система смотрит не только на формальную оценку опасности уязвимости, но и оценивает, насколько реально ей можно воспользоваться прямо сейчас. Для этого используются данные из внешних источников и собственная аналитика Security Vision.

Мой коммент: видим, что в первых трёх пунктах перечисляются режимы детектирования и поддерживаемые системы; в двух последних пунктах методы приоритизации уязвимостей с закосом в CTEM.

🎯 Какую выгоду получает ваш бизнес?

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

2. Снижение рисков. Граф достижимости помогает понять реальную угрозу, а приоритизация по EPSS и CISA KEV сфокусироваться на том, что действительно опасно.

3. Экономия ресурсов. Автоматизация сканирования и гибкие расписания снижают нагрузку на команду, а возможность точечного ретроскана экономят время.

4. Прозрачность. Отчёты в любых форматах, динамика устранения проблем, полная картина защищённости для руководства и регуляторов.

Мой коммент: "проактивная защита", отчёты, EPSS/CISA KEV выглядят как универсальные фичи практически для всех VM-вендоров; а вот ретросканы и граф достижимости - довольно редки.

Заключительный мессадж: "Security Vision VS - это рентген для IT-инфраструктуры. Он помогает видеть слабые места, оценивать реальные риски и защищать бизнес до того, как атака произойдёт. Просто, быстро, эффективно!"

Мой коммент: тут тоже мессадж более-менее универсальный.

В целом, мне ролик понравился, отторжения никакие тезисы не вызвали. 👍

Нам нужна национальная мобильная ОС

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

Нам нужна национальная мобильная ОС

Нам нужна национальная мобильная ОС. Соглашусь с Игнатием Цукергохером, что в плане мобильных ОС дело пахнет керосином и нужно что-то срочно предпринимать. Apple удалила из App Store национальный мессенджер MAX, после чего были удалены и другие приложения VK. Вслед за этим появились новости о предупреждении Apple от ФАС и возможном штрафе до 4 млрд рублей. Вряд ли Apple устранит "дискриминацию российских поисковых систем и обеспечит предустановку отечественного ПО на устройствах с iOS до 15 июля 2026 года". 🙄 Да и в то, что Эппл Рус выплатит штраф, тоже верится с трудом. Есть основания полагать, что идёт постепенная эскалация, результатом которой будет запрещение мобильных устройств Apple (в каком-то виде) и дальнейшее снижение их функциональности в России, реализованное как со стороны купертинцев, так и со стороны РКН.

Казалось бы, чего нам переживать за Apple и эплофилов? Есть же устройства на Android. Но там Google тоже переходит к гиперцентрализации и вводит обязательную регистрацию авторов приложений. У тех, кто не пройдёт верификацию (или у тех, кто будет неугоден по каким-то причинам 😉), приложения будут заблокированы на каждом Android-устройстве по всему миру. Речь не только о приложениях из Play Store, а вообще обо всех приложениях. Продвинутые пользователи смогут установить произвольную APK, но для этого придётся пройти пляски с бубном из 9 пунктов, один из которых - "Подождите 24 часа". Чистой воды издевательство. Закручивать гайки начнут с сентября 2026 года.

Ну и в целом, когда Дуров говорил, что без собственной операционной системы "все приложения на смартфонах - "национальные" или "иностранные" - остаются уязвимыми для точечной слежки и цензуры со стороны США через бэкдоры и магазины приложений iOS и Android", он был прав.

Как по мне, появление в широкой продаже устройств с отечественной мобильной операционной системой возможно только в случае повторения того же финта, что и с национальным мессенджером МАКС:

🔻 Необходимо, чтобы было принято политическое решение, что да, нужно создавать мобильную ОС директивно.

🔻 Особый статус национальной мобильной операционной системы (НМОС) должен быть закреплён в законе РФ.

🔻 В закрытом режиме должен быть выбран конкретный исполнитель, у которого есть наработки и компетенции, чтобы развивать НМОС.

🔻 Производители устройств должны быть директивно простимулированы производить устройства на НМОС, а ритейл - их продавать. Хочешь быть на рынке и не иметь проблем - участвуй в продвижении НМОС.

🔻 При появлении устройств с НМОС в продаже необходимо агрессивно навязывать их потребителям. Устройство с НМОС в кармане должно быть таким же атрибутом лояльности, как портрет президента в кабинете. На публике каждого чиновника должны видеть только со смартфоном с НМОС.

🔻 Бизнесы, у которых есть мобильные приложения, должны в первую очередь обеспечить их работу в НМОС. Определённые важные типы приложений должны работать только под НМОС.

Какая именно мобильная ОС должна стать национальной? Как по мне, непринципиально. Их сейчас в России достаточно много: Аврора, РЕД ОС М, РОСА Мобайл, Astra Linux Mobile, Alt Mobile, KasperskyOS for Mobile, kvadraOS и другие.

Из личного опыта могу сказать только то, что у меня есть смартфон на Авроре - Fplus R570E, который я купил в 2023 году. Это единственное устройство на Авроре, которое можно было официально купить физику. Казалось бы, флагман и показатель потенциала платформы для обычных потребителей, но последняя версия ОС для Fplus R570E (5.1.6) вышла в октябре прошлого года. А 3 последние версии ОС для этого смартфона выпущены не будут. ОМП показывает пальцем на Fplus, а у Fplus с прошлого года проблемы, им не до этого. Их гендиректора в июне этого года вообще признали банкротом. Не то чтобы я пожалел о покупке Fplus R570E - опыт был прикольный, но веры в то, что ОМП может достойно поддерживать НМОС, у меня поубавилось. 🤷‍♂️ Да и заставлять российские компании, у которых уже есть приложения под Android и iOS, портировать их под Аврору, ИМХО, как-то слишком.

Более логичным выглядит вариант на базе AOSP без гуглосервисов. Из отечественных AOSP-based ОС наиболее адекватной и живой выглядит РЕД ОС М.

Но, повторюсь, важна не конкретная ОС как таковая, а политическая воля по её насаждению. Посмотрим, будет ли эта воля продемонстрирована. Но в то, что без каких-либо директивных мер воздействия в России в широкой продаже могут появиться мобильные устройства на отечественных ОС и они займут существенную долю рынка, я не верю. 🙂

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. Коллеги из РЕД СОФТ быстро отреагировали и проблему исправили. 🙂👍

Поделюсь своими грустными мыслями по поводу 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-контентом в РЕД СОФТ занимаются, скиньте им, пожалуйста, этот пост. Буду рад познакомиться и пообщаться.

До End of Life CentOS 7 осталось 2 недели

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

До End of Life CentOS 7 осталось 2 недели

До End of Life CentOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с CentOS 7 не особо понятно. RedHat превратили CentOS в нестабильный дистрибутив CentOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону SberLinux, RedOS и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов совместимых с RHEL в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubuntu.

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday

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

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday
Сгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday. За прошедший месяц Linux-вендоры начали выпускать исправления для рекордного количества уязвимостей - 348. Есть признаки эксплуатации вживую для 7 уязвимостей (данные об инцидентах из БДУ ФСТЭК). Ещё для 165 есть ссылка на эксплоит или признак наличия публичного/приватного эксплоита.

Начнём с 7 уязвимостей с признаком активной эксплуатации вживую и эксплоитами:

🔻 В ТОП-е, внезапно, январская трендовая уязвимость Authentication Bypass - Jenkins (CVE-2024-23897). Насколько я понимаю, обычно Linux-дистрибутивы не включают пакеты Jenkins в официальные репозитарии и, соответственно, не добавляют детекты уязвимостей Jenkins в свой OVAL-контент. В отличие от отечественного RedOS. Поэтому самый ранний таймстемп исправления этой уязвимости именно у RedOS.

🔻 2 RCE уязвимости. Самая интересная это Remote Code Execution - Exim (CVE-2023-42118). Когда я выпускал отчёт, я специально не учитывал описание уязвимости и продукты из БДУ (флаги --bdu-use-product-names-flag, --bdu-use-vulnerability-descriptions-flag). Иначе это привело бы к тому, что часть отчёта была бы на английском, а часть на русском. Но оказалось, что для этой уязвимости адекватное описание есть пока только в БДУ. 🤷‍♂️ К этой уязвимости нужно присмотреться, т.к. Exim является достаточно популярным почтовым сервером. Вторая RCE уязвимость браузерная, Remote Code Execution - Safari (CVE-2023-42950).

🔻 2 DoS уязвимости. Denial of Service - nghttp2/Apache HTTP Server (CVE-2024-27316) и Denial of Service - Apache Traffic Server (CVE-2024-31309). Последняя в отчёте классифицируется как Security Feature Bypass, но это из-за некорректного CWE в NVD (CWE-20 - Improper Input Validation)

🔻 2 браузерные Security Feature Bypass - Chromium (CVE-2024-2628, CVE-2024-2630)

Из уязвимостей, для которых пока есть только признак наличия эксплоита, можно обратить внимания на следующее:

🔸 Большое количество RCE уязвимостей (71). Большая часть из них в продукте gtkwave. Это программа просмотра файлов VCD (Value Change Dump, дамп изменения значения), которые обычно создаются симуляторами цифровых схем. Выглядят опасными уязвимости Remote Code Execution - Cacti (CVE-2023-49084, CVE-2023-49085), это решения для мониторинга серверов и сетевых устройств.

🔸 Security Feature Bypass - Sendmail (CVE-2023-51765). Позволяет внедрить сообщения электронной почты с поддельным адресом MAIL FROM.

🔸 Пачка Cross Site Scripting в MediaWiki, Cacti, Grafana, Nextcloud.

В общем, в этот раз аж глаза разбегаются. 🤩

🗒 Апрельский Linux Patch Wednesday

Управление уязвимостями в новых реалиях

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

Управление уязвимостями в новых реалиях. Крутой доклад по VM-ной теме с недавно прошедшего Инфофорума. Представлял доклад Андрей Никонов, старший инженер-программист из Фродекс (Vulns.io). Видео в паблике не нашел, но есть даже лучше - слайды с текстом выступления.

Выписал тезисно:

1. Зарубежные VM-вендоры ушли - нет детектов, IT-вендоры ушли - нет обновлений.
2. Атаки на российские компаний множатся, утечки ПД и оборотные штрафы.
3. Рост отечественного ПО -> рост проблемы анализа защищенности этого ПО -> "VM-решения должны уметь работать с операционными системами и программами российского происхождения".
4. В достаточной степени отечественные VM-решения поддерживают отечественное ПО? Непонятно. "Никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта".
5. Необходимы данные об уязвимостях отечественного ПО.
5.1. Западные компании "публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим".
5.2. "Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет". -> Ага, детект по CPE-шкам это зло.
5.3. Все ли вендоры одинаково описывают свои уязвимости? Далеко не все. OVAL стал довольно популярным. Но этого недостаточно.
5.4. У нас хорошие источники это БДУ ФСТЭК и OVAL RedOS. "Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку."
5.5. Для прикладного ПО из 65 вендоров в базе ФСТЭК 3 публикуют данные об уязвимостях. А в реестре российского ПО 16000 программных продуктов!
5.6. Одной БДУ ФСТЭК недостаточно, т.к. "не указываются правила применимости той или иной уязвимости, для сканирования использовать эти данные проблематично". Данные в БДУ могут добавляться с запаздыванием, данные не всегда актуальны. Напрямую от вендора было бы быстрее.
6. Итог: "обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности".
Просьбы к регулятору:
"- принять единый стандарт описания уязвимостей или разработать собственный
- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом
- оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК"

В целом, огонь! 🔥 Как раз такие доклады от VM-вендора и хочется видеть. Конкретно про детект уязвимостей и как делать его лучше. Очень сильно перекликается с моими собственными мыслями по этому поводу. Хочется надеяться, что регулятор прислушается.