Скачиваешь программу с официального сайта - получаешь малварь. Кейс огненный 🔥 и опять-таки про доверие вендорам ПО. Есть такая кроссплатформенная утилита для скачки файлов Free Download Manager. Так вот, Касперские пишут, что на официальном сайте этой утилиты три года раздавали затрояненный FDM. 😱 Причём
1. Это касалось только Linux-овой версии. 2. Затрояненное ПО скачивалось не всегда, а с некоторой вероятностью и видимо в зависимости от цифрового отпечатка жертвы. 3. Сам вендор был похоже не в курсе. 🤷♂️ Типа сайт подломили.
После заражения устройства злоумышленники собирали сведения о системе, историю просмотров, сохраненные пароли, файлы криптовалютного кошелька и учетные данные для облачных сервисов.
Что с этим делать непонятно. Я и сам частенько забираю актуальные версии софта с официальных сайтов в формате AppImage. 🙄 Например, Inkscape или OpenShot. Тоже мог бы попасться на подобную атаку. Видимо EDR в Linux становится вполне себе насущной необходимостью. 🧐
EoP в Linux Kernel с 6.1 по 6.4 (CVE-2023-3269, StackRot). Непривилегированный локальный пользователь может использовать эту уязвимость для компрометации ядра и повышения своих привилегий. Полный код эксплоита и подробное описание будут опубликованы не позднее конца июля.
RCE у Apple устройств (CVE-2023-37450). Активно эксплуатируется. Находится в WebKit (движок Safari и всех веб-браузеров на iOS и iPadOS) и триггерится при обработке специально созданного (вредоносного) веб-контента. Обновления для macOS Ventura 13.4.1, Safari 16.5.2 в macOS Big Sur/Monterey, iOS/iPadOS 16.5.1.
На днях вышла openKylin v.1.0. По описанию существенных отличий от 0.7 не видно, но нужно тестить. 🙂 Также непонятно, как обстоят дела с бюллетенями безопасности. Для коммерческой Kylin OS они есть, а для openKylin я пока не нашел.
Посмотрел запись онлайн-запуска MaxPatrol VM 2.0 и MaxPatrol HCC. Выписал некоторые тезисы. 🙂
По уязвимостям
В рамках пилотов MaxPatrol VM в организациях находят в среднем ~30к уязвимостей, из них ~50 особо критичных и легко эксплуатируемых.
Главное согласовать SLA на исправление уязвимостей в организации. Идеально укладываться в 24 часа для особо критичных (что и ФСТЭК рекомендует).
Большой акцент на "трендовые уязвимости", которые отбирает и подсвечивает PT на основе пентестов и хитрого анализа данных.
От меня: фокус на собственную приоритизацию сейчас у всех топовых VM-вендоров. Например, Tenable VPR и Qualys TruRisk.Дело хорошее 👍
Информация о трендовых уязвимостях попадает в MaxPatrol VM с минимальной задержкой благодаря архитектурным изменениям в базе знаний. Привели пример кейса по добавлению трендовой уязвимости для софта (22:45), который в MaxPatrol VM вообще не поддерживается (VirtualBox). Если вдруг будет трендовая супер-критичная уязвимость, несмотря на отсутствие поддержки, исследователь добавит её с SLA в 12 часов.
По контролю конфигураций
Новый модуль HCC, лицензируется отдельно. Проблематика - очень много противоречивых требований, соответствовать всему невозможно.
Предлагается следующий процесс:
Этап 1. 1. Определение регламента принятых стандартов. Возможно надергать требований из CIS Benchmarks, чтобы составить свой. 2. Определение правил и задач по работе со стандартом, которые направляются IT-специалисту. 3. Проверка соответствия активов. 4. Проводим troubleshooting, возможно с видоизменением стандарта. 5. Принятие и внедрение стандарта на живую информационную систему. Этап 2. Работа с отчётами по нарушению требований (исправление или корректировка стандартов), разработка новых стандартов.
Сейчас в HCC доступный 17 стандартов PT Essential (44:13). Они разработаны совместно с пентестерами:
Windows Desktop Windows Server Microsoft SQL Server Generic Linux Oracle Database VMware ESXi VMware vCenter Microsoft Exchange RHEL-based Linux HP UX IBM AIX Linux Kernel Docker Cisco IOS Cisco IOS XE Cisco ASA года Cisco Nexus
Можно отслеживать коммуникацию с IT и выполнение установленных сроков в рамках политик.
Отдельного комплаенс сканирования нет, используется та же инвентаризация аудита. Проверки реализованы в виде запросов на собственном языке. Функционально можно сравнить с .audit от Tenable. Есть шансы, что в перспективе дадут делать свои проверки на нем. 😉
Из PT Essentials можно надёргать требований и составить из них свой стандарт.
Подробнее про PT Essential - Linux Kernel
В ядре Linux >30 млн. строк кода, 4000 разработчиков в год участвуют, каждый день 8000 строк меняются. Множество уязвимостей, особенно из-за ошибок доступа к памяти. Уязвимости добавляются быстрее, чем исправляются. Среднее время жизни критической уязвимости в ядре 5,5 лет. Проект Kernel Self Protection Project - "подушка безопасности" для устранения некоторых проблем как класса. Есть карта средств защиты ядра. Стандарт для ядра Linux был реализован с использованием этой карты и собственной дефенс экспертизы. Эти же требования были использованы в стандарте по настройке Linux систем от ФСТЭК. 👍
Методика ФСТЭК по оценке критичности уязвимостей
Теперь официально поддерживается в MaxPatrol VM. Про вопросы к реализации я уже раньше писал, это не silver bullet пока. Но и в таком виде работать в MaxPatrol VM проще, чем считать руками или скриптовать своё. Эта функциональность реализована в виде PDQL фильтра, такие фильтры будут доступны в общей библиотеке.
Добавили интеграцию с LAPS, чтобы избегать компрометации учёток с правами админа на многих хостах.
---
Крутой запуск! Многая лета новому поколению Compliance Management-а в MaxPatrol HCC! Буду активно отслеживать эту тему. 🙂 И не только я. Валерий Ледовской из X-cofig запустил канал по CM и тоже поделился впечатлениями от запуска HCC, зацените и подпишитесь! Взгляд со стороны прямых конкурентов это всегда любопытно. И чем больше будет авторских околоVM-ных каналов, тем лучше. 😉
Наблюдаю за попыткой Red Hat расправиться с бесплатными клонами RHEL. Они прекратили публиковать srpm-пакеты RHEL в репозитории git.centos.org. Теперь можно будет забирать только исходники пакетов нестабильного дистриба CentOS Stream. 😏 Естественно, Alma и Rocky оказались в щекотливом положении. Вендоров отечественных RPM-based дистрибутивов новость тоже, наверняка, не порадовала. Самый смачный пост был у Mike McGrath, "Vice President of Core Platforms Engineering at Red Hat". Вообще в выражениях не стесняется:
"Я чувствую, что большая часть гнева из-за нашего недавнего решения относительно даунстримов исходит либо от тех, кто не хочет платить за время, усилия и ресурсы, вложенные в RHEL, либо от тех, кто хочет переупаковать их для собственной выгоды. Этот спрос на код RHEL лицемерен."
"В конечном счете, мы не находим ценности в ребилдерах RHEL-а и не обязаны облегчать жизнь ребилдерам"
"Простой ребилд кода без добавления ценности или какого-либо изменения представляет собой реальную угрозу для компаний с открытым исходным кодом во всем мире. Это реальная угроза открытому исходному коду, и она потенциально может вернуть опенсурс обратно в деятельность только для любителей […]".
Вот тебе и опенсурс. Как в КВНе было: "- Дайте полотенце - Вон там, на швабре возьмите". А кто-то ещё критикует МЦСТ за нарушение GPL. 😏
Так-то ещё с закапывания CentOS было понятно, что дело пахнет керосином и бежать нужно не на RHEL-клоны, а куда подальше.
Linux Patch Wednesday? Раз уж значение Linux-а у нас стремительно растёт, выглядит правильным смещать фокус внимания с уязвимостей продуктов Microsoft на уязвимости Linux. При этом для продуктов Microsoft у нас есть единый день повышенного внимания - Microsoft Patch Tuesday, а для Linux такого нет. Слишком там всё фрагментировано и патчи выпускаются буквально ежедневно. Но что нам мешает самостоятельно раз в месяц формировать список исправленных за месяц CVE-шек и подсвечивать критичное? Кажется ничего. Список CVE можно получать, например, через парсинг OVAL-контента дистрибутивов (а кто такое не публикует - позор им 🙂).
Выпускать подобное предлагаю в каждую третью среду месяца и называть Linux Patch Wednesday. Как вам идейка?
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.
