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

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux

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

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux. Продолжаю обозревать крутые штуки от ФСТЭК.

У меня в декабре был пост, что если бы я был регулятор, то обязал бы вендоров сертифицированных Linux-ов привести в порядок бюллетени безопасности, а идеально было бы OVAL контент предоставлять. Так как это делает RedOS. И в каком-то виде это осуществилось. 🤩 Ну не силами Linux-вендоров, а силами ИБ-вендора и регулятора. И с существенными ограничениями. Но факт - вот тебе OVAL-контент для сертифицированных Linux-ов в паблике и бесплатный сканер, который с ним работает.

На сайте ФСТЭК-а выложили бесплатный локальный сканер уязвимостей ScanOVAL в версиях под Linux (раньше был только под Windows). И OVAL-контент к нему. В трёх вариантах:

1. ScanOVAL для ОС Astra Linux 1.6 SE - тестовая версия сканера и OVAL-контент
2. ScanOVAL для ОС Альт 9 - тестовая версия сканера и OVAL-контент
3. ScanOVAL для ОС Роса «Кобальт» - тестовая версия сканера (OVAL-контент пока недоступен)

ScanOVAL это, конечно, не вполне полноценный сканер. Он может сканировать только локалхост. Штатно запускается только в графическом режиме. Т.е. использовать его, чтобы вручную валидировать уязвимости на хостах получится, а приспособить для регулярного сканирования всей инфры скорее всего нет. Понятно зачем сделано, этот продукт не должен рушить бизнес VM-вендорам.

Другой вопрос, который естественно возникает, когда видишь OVAL-контент в паблике, а можно ли его использовать не в составе ScanOVAL? 😏 Например, OpenSCAP-у скормить, свой OVAL сканер написать или интерпретировать во что-нибудь? Ответ: технически реально, а юридически нельзя, т.к. EULA для ScanOVAL это отдельно оговаривает:

"Не допускается осуществлять следующие действия:
…
использовать ПО и (или) описания проверок (включая любые их фрагменты), применяемые в ее составе, с целью создания баз данных или кода, предназначенных для предотвращения угроз безопасности информации;
публиковать, а также распространять от своего имени любые фрагменты описаний проверок, применяемых в составе ПО;
…"

Тоже понятно почему. Идентификаторы дефинишенов, такие как "oval:ru.altx-soft.nix:def:156318", не оставляют сомнений в происхождении контента и понятно, что рушить свой бизнес коммерческому VM вендору совсем не нужно.

Поэтому,
1. Круто, что появилась возможность сканировать сертифицированные отечественные Linux-ы бесплатным решением. Даже если использовать его только в ручном режиме как эталонный сканер, это более чем полезно.
2. Потребность в OVAL-контенте (или просто бюллетенях хотя бы) от Linux-вендора это не снимает, т.к. EULA конечно полноценно использовать контент для ScanOVAL не позволяет, к сожалению.

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК

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

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК. Что? 😳 ДА! 🎉Теперь можно ссылаться не на CIS, не на DISA STIGs, не на BSI IT-Grundschutz, а на технические требования нашего отечественного регулятора. Ну круть же! Скачать можно на сайте ФСТЭК.

1. Документ очень компактный, всего 7 страниц. CIS Benchmark для Ubuntu Linux 20.04 LTS, для сравнения, занимает 531 страницу.
2. Рекомендации подлежат реализации в государственных информационных системах (ГИС) и на объектах критической информационной инфраструктуры (КИИ).
3. Рекомендации распространяются на настройку НЕсертифицированных ОС (как раз Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Т.е. мейнстримные Linux дистрибутивы из КИИ и ГИС придется выносить, если они есть. Сертифицированные же Linux-ы должны настраиваться "в соответствии с эксплуатационной документацией разработчиков".
4. Рекомендации касаются именно настройки. Пример: "2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH путём установки для параметра PermitRootLogin значения no в файле /etc/ssh/sshd_config." Как проверять не расписывается.
5. Сложность реализации настроек и проверок соответствия по пунктам из этих рекомендаций зависит от конкретности рекомендаций. Часть рекомендаций выглядят достаточно конкретными, часть нет, например "2.3.8. Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путём анализа корректности прав доступа к утилитам и системным библиотекам, расположенным по стандартным путям (, /usr/bin, , и другим путям), а также к модулям ядра (для Linux: /lib/modules/версия-текущего-ядра)". Понятно, что конкретные настройки могут зависеть от конкретного дистрибутива, но все же хотелось бы большей однозначности, что нужно делать.
6. В некоторых пунктах приводится обоснование зачем это настройка нужна, например "в противном случае это может привести к выполнению произвольного кода от имени владельца задания cron". Но для большей части рекомендаций этого нет. А тоже хотелось бы.

Блоки рекомендаций:
1. Настройка авторизации в операционной системе.
2. Ограничение механизмов получения привилегий.
3. Настройка прав доступа к объектам файловой системы.
4. Настройка механизмов защиты ядра Linux.
5. Уменьшение периметра атаки ядра Linux.
6. Настройка средств защиты пользовательского пространства со стороны ядра Linux.

В целом, инициатива очень крутая, но к такому документу нужны ещё дополнительные конкретизирующие документы с настройками/проверками для конкретных ОС и обоснованиями почему каждая настройка важна и что может сделать злоумышленник в случае, если рекомендации по настройке не будут применены.

Результаты тестирования обновлений безопасности

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

Результаты тестирования обновлений безопасностиРезультаты тестирования обновлений безопасности

Результаты тестирования обновлений безопасности уже доступны на сайте БДУ ФСТЭК. Вкладка Уязвимости -> Тестирование обновлений. Пишут, что "в настоящее время проводится опытная эксплуатация раздела". Это результаты работ по той самой госзакупке? Не знаю, но судя по таймингу тестирований вполне возможно.

1. Всего 112 обновлений протестировано.
2. Скачать весь фид целиком похоже пока нельзя. По кнопке "скачать" скачивается только текущая страница.
3. Первое тестирование от 28.08.2022, последнее тестирование от 24.12.2022.
4. Похоже, что обновления пока только Microsoft-овские.
5. Для обновления доступно его наименование, ссылка на описание, ссылка на файл-обновления, хеши, дата выпуска обновления, вендор, ПО, версии уязвимого ПО, версии тестируемого ПО, идентификаторы БДУ, идентификаторы CVE, вердикт.
6. Возможные значения для вердикта: "Влияние на инфраструктуру отсутствует", "Может оказать некритичное влияние на инфраструктуру", "Выявлено деструктивное воздействие на инфраструктуру".
7. Пока для всех тестов вердикт "Влияние на инфраструктуру отсутствует".

Теперь перед раскаткой обновления можно/нужно поглядывать на его вердикт в БДУ. Как это делать удобно и автоматизированно пока не особо понятно, но какой-то ручной процесс уже можно выстраивать. И это несоизмеримо проще, чем делать полноценное тестирование обновлений своими силами по методике. Ура!

Не грех пошарить важную новость:

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

Не грех пошарить важную новость:

"Тинькофф запустил публичную программу по поиску ошибок и уязвимостей в своих сервисах за вознаграждение на платформе BI.ZONE Bug Bounty. В ней могут участвовать любые исследователи безопасности из России и стран ЕАЭС."

Собственно ссылка на программу.

Что в скоупе:

"Уязвимости можно искать на всех наших ресурсах, а именно — *.tinkoff.ru, *.tcsbank.ru, *.tinkoffinsurance.ru." Но максимальные выплаты только для уязвимостей определенных сервисов.
Максимальная выплата за Critical 150 000 ₽.

За что платят:

"Ниже приведены примеры уязвимостей, за которые мы с радостью выплатим вознаграждение (список далеко не полный):

Удаленное исполнение кода (RCE);
Инъекции (например, SQL-инъекции или XML-инъекции);
LFR/LFI/RFI;
SSRF;
Утечки памяти;
Уязвимости бизнес-логики;
IDOR;
Уязвимости контроля доступа;
Раскрытие чувствительной информации;
Угон аккаунта;
Недостатки аутентификации/авторизации;
XSS и CSRF с воздействием на чувствительные данные."

Также в описании программы подробный перечень за что НЕ платят и что вообще присылать не нужно. Описание само по себе очень подробное и классное, любо-дорого посмотреть.

Также были предложения сделать полноценную карту отечественных Vulnerability Management вендоров, чтобы уж там-то точно всех упомянуть

10 комментариев

Также были предложения сделать полноценную карту отечественных Vulnerability Management вендоров, чтобы уж там-то точно всех упомянуть. Почему бы и нет. Я сам в VM-ном вендоре НЕ работаю, относительно беспристрастен, стараюсь со всеми дружить, каких-то интересов кроме продвижения российской VM-ной темы в целом не имею. Для себя профитов вижу 2: когда кто-то приходит с вопросом о выборе VM-решния, можно будет не повторяться, а просто показывать карту; если представители вендоров будут сами приходить и предлагать что-то поправить на карте, будет проще отслеживать состояние VM рынка.

В чем вообще беда таких карт и обзоров от Gartner/Forrester? Ну кроме того, что это маркетинговые инструменты с понятными целями, задачами, схемой монетизации и т.п. 😏 Основная беда в том, что там всё вперемешку. Вендоры продуктов детектирующих уязвимости идут вместе с вендорами продуктов только приоритизирующих уязвимости. Вендоры продуктов для детекта известных инфраструктурных уязвимостей идут вместе с вендорами сканеров веб-приложений. Хаос. Маркетинг вендоров этой неразберихе только способствует. Без негатива, понять можно, их интерес конверсию и продажи поднимать. Но объективное сравнение продуктов в интересах конечного пользователя это усложняет.

Как эту проблему минимизировать? Начать следует с более-менее четкого определения групп продуктов. И рассматривать затем вендоров и их продукты в рамках этих групп. Я прикинул, у меня группы получились такие:

Средства Управления Уязвимостями (СУУ) - зонтичный термин, включающий в себя всё, что ниже.

1. Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)
Позволяют детектировать известные уязвимости CVE/БДУ и мисконфигурации CIS/CCE для инфраструктурных активов. Для сбора информации об активах может использоваться установка агентов, активное сетевое сканирование, интеграция с системами инвентаризации, перехват сетевого трафика. Анализируемые объекты включают операционные системы, различные программные продукты, сетевые устройства, контейнеры и базовые образы.

2. Средства Детектирования Уязвимостей Сетевого Периметра (СДУСП)
Позволяют детектировать известные уязвимости CVE/БДУ, мисконфигурации и (частично) неизвестные уязвимости (например XSS в самописном веб-приложении) для активов, которые публично доступны из Интернет. Для сбора информации об активах используется активное сетевое сканирование. Сканирование производится с внешней площадки вендора, что обеспечивает взгляд на анализируемую инфраструктуру как у атакующего.

3. Средства Детектирования Уязвимостей Приложений (СДУП)
Позволяют детектировать неизвестные уязвимости в приложениях (например XSS в самописном веб-приложении или переполнение буфера с перезаписью адреса возврата в серверном/десктопном приложении). Приложения включают в себя веб-приложения, программные интерфейсы (API), десктопные и серверные приложения, приложения для мобильных устройств (Android, iOS, Аврора). Анализ, как правило, динамический без доступа к исходному коду.

4. Средства Детектирования Уязвимостей Кода (СДУК)
Позволяют детектировать неизвестные уязвимости (например XSS в самописном веб-приложении или переполнение буфера с перезаписью адреса возврата в серверном/десктопном приложении) и известные уязвимости CVE/БДУ на основе анализа исходного кода. Анализ, как правило, статический и проводится в рамках жизненного цикл разработки ПО (SDLC).

5. Средства Анализа Уязвимостей (САУ)
Позволяют анализировать и приоритизировать уязвимости для конкретной инфраструктуры. Имеется в виду не дополнительная функциональность в рамках детектирующего решения, а решение позволяющее импортировать данные об уязвимостях из сторонних источников. Анализ может включать в себя построение цепочки атаки и симуляцию атаки.

6. Средства Исправления Уязвимостей (СИУ)
Позволяют автоматизированное исправлять уязвимости в конкретной инфраструктуре. Имеется в виду не управление задачами для системных администраторов, а непосредственное воздействие на актив, такое как обновление хоста или изменение его конфигурации.

Выпустил эпизод по январскому Microsoft Patch Tuesday

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

Выпустил эпизод по январскому Microsoft Patch Tuesday

Выпустил эпизод по январскому Microsoft Patch Tuesday.

Есть интересные EoP с активной эксплуатацией вживую и даже публичным PoC-ом на GitHub. Но это все же не RCE, поэтому не ужас-ужас.

Есть подозрительные уязвимости для Exchange, которые тоже вроде как не RCE, но с Exchange уже на воду начинаешь дуть. Мало ли, вдруг опять с определением типа ошиблись и вскроется какой-то ProxyAbsolutelyNotShell. Лучше заранее обновиться.

Зато есть прям много RCE во всяких сетевых протоколах. Дойдет ли до реальной эксплуатации? Фиг знает, обычно не доходит.

Ну и наконец окончательное превращение в тыкву Windows 7, Windows 8.1, Windows Server 2008/2008R2. Лишний повод попушить админов, если оно вдруг всё-таки где-то осталось. Хотя если оно где-то и осталось, то наверняка не просто так.

И снова уязвимость, которую не подсветил вообще никто из VM-вендоров, но для которой внезапно появляется два публичных PoC-а на гитхабе от известного исследователя (Filip Dragovic, #Wh04m1001)

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

И снова уязвимость, которую не подсветил вообще никто из VM-вендоров, но для которой внезапно появляется два публичных PoC-а на гитхабе от известного исследователя (Filip Dragovic, #Wh04m1001)И снова уязвимость, которую не подсветил вообще никто из VM-вендоров, но для которой внезапно появляется два публичных PoC-а на гитхабе от известного исследователя (Filip Dragovic, #Wh04m1001)

И снова уязвимость, которую не подсветил вообще никто из VM-вендоров, но для которой внезапно появляется два публичных PoC-а на гитхабе от известного исследователя (Filip Dragovic, #Wh04m1001). Elevation of Privilege - Windows Backup Service (CVE-2023-21752). Первый PoC любой файл может удалить, второй запускает shell с поднятыми привилегиями.

А то, что VM-вендоры подсвечивают как правило так и остается неэксплуатабельным. 🤷‍♂️