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

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

Методические рекомендации по безопасной настройке 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.

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

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

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

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

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 вендоров, чтобы уж там-то точно всех упомянуть

Также были предложения сделать полноценную карту отечественных 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)

И снова уязвимость, которую не подсветил вообще никто из 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-вендоры подсвечивают как правило так и остается неэксплуатабельным. 🤷‍♂️

Смотрю на карту российского рынка информационной безопасности 2023 от TAdviser

Смотрю на карту российского рынка информационной безопасности 2023 от TAdviser

Смотрю на карту российского рынка информационной безопасности 2023 от TAdviser. Для Vulnerability Management решений отдельной категории снова не нашлось. Не просто в САЗах, а ещё и вместе с DevSecOps. 🙂 На взгляд VM-щика расклад по этой картинке такой:

Vulnerability Management решения

* Positive Technologies - MaxPatrol 8, MaxPatrol VM
* НПО Эшелон - Сканер ВС
* АЛТЭКС-СОФТ - RedCheck
* Газинформсервис - Efros Config Inspector

Managed VM Services

* Ростелком Солар - сервис контроля уязвимостей (+ анализ исходного кода)

Сканеры веб-приложений/периметра

* Pentestit - NEMESIDA SCANNER, сканер веб-приложений
* Необит - VulnFinder, сканер веб-сайтов
* BIZONE - контроль уязвимостей внешнего периметра (+ решение для SSDLC)

Средства анализа исходного кода

* Стингрей - анализ защищённости мобильных приложений
* ИСП РАН - анализаторы исходного кода
* PVS-Studio - статический анализатор исходного кода

Другое

* R-Vision - CERS, построение центра реагирования на угрозы и уязвимости