Методическая рекомендация № 2025-04-003

Область: Определение поверхности атаки (ПА) / Фаззинг-тестирование

Тип недостатка: Некорректное определение составляющего ПА кода компонентов. Необоснованный фаззинг аргументов командой строки консольных приложений.

Описание: На рис. 1 представлено описание проведения фаззинг-тестирования утилиты ssh через аргументы командной строки с использованием заголовочного файла argv-fuzz-inl.h, для СЗИ типа А - "Операционная система общего пользования". На рис. 2 представлена консоль фаззера afl++, с помощью которого в ходе испытаний выполнялось фаззинг-тестирование в отношении утилиты ssh.

Фаззинг-тестирование параметров запуска (аргументов командной строки) консольных приложений как правило не представляет значительной ценности с точки зрения исследования ПА. Если злоумышленник уже получил доступ к терминалу (закрепился в системе), его действия будут направлены на задачи повышения собственных привилегий, воздействие на критичные компоненты системы, такие как ядро, сетевые сервисы или права доступа. Эксплуатация потенциальных ошибок в обработке аргументов запуска консольных приложений, как правило, не позволит пользователю нанести системе больший ущерб, чем уже достигнутая возможность запускать данное приложение с различными штатными параметрами. Например для утилиты ssh указанные некорректно имя пользователя или адрес удаленного хоста приведут к завершению приложения с сообщением об ошибке, без влияния на безопасность приложения (объекта оценки) в целом.

При этом необходимо отметить, что в ряде случаев — в первую очередь при работе приложения с привилегиями, превышающими непосредственные привилегии пользователя (см. ниже пример утилиты ping) — эксплуатация дефектов приложения может позволить пользователю-нарушителю выполнять вредоносные действия с повышенными привилегиями. В таких случаях исследование кода данного приложения в приоритетном порядке может являться обоснованным.

Рекомендации:

- при определении ПА и приоритизации исследований необходимо сосредоточиться на реальных сценариях атак, которые могут быть реализованы злоумышленниками

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

- при исследовании сетевых сервисов наиболее приоритетным, как правило, является исследование кода, отвечающего за разбор (парсинг) трафика, поступающего из сети

Дополнительные информационные материалы:

- пример исследования кода сетевого сервиса sshd
- определение ПА в ГОСТ 56939-2024
- слайды 4, 6, 9 по ссылке
- слайды 16, 18

Методическая рекомендация № 2025-04-004

Область: Определение поверхности атаки (ПА) / Фаззинг-тестирование

Тип недостатка: Некорректное определение ПА. Необоснованное фаззинг-тестирование интерпретаторов за счет подачи скриптов на вход.

Описание: На рис. 1-3 представлены примеры фаззинг-тестирования сред выполнения программного кода на языках программирования OpenJDK, Bash, Python (далее — интерпретатор), путем перебора скриптов, поданных на вход.

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

Например:
Мутация вида print("Hello world") → print("llHeo world") сохраняет семантику исходного кода, не влияя на работу интерпретатора.
Мутация вида print("Hello world") → ntpri("llHeo world") приводит к синтаксической ошибке, после которой интерпретатор прекращает выполнение скрипта.

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

Поэтому для веб-приложений, поддерживающих выполнение скриптов на стороне серверной части, важно проводить тестирование в отношении функций, непосредственно доступных потенциальному нарушителю для взаимодействия с ними и передачи значений аргументов в них. (Пример таких функций: обработка входных данных через API или веб-интерфейсы; анализ и обработка данных, передаваемых через HTTP-запросы).

Рекомендации:

- необходимо проводить фаззинг-тестирование участков кода, непосредственно взаимодействующих с данными, поступающими от потенциального нарушителя (парсеры, анализаторы)

- рекомендуется взаимодействие с Центром исследований безопасности системного программного обеспечения для организации фаззинг-тестирования интерпретаторов, поскольку Центр обладает значительным опытом в их анализе и выявлении потенциальных уязвимостей

Дополнительные информационные материалы:

- презентация Центра
- слайды 8, 9 по ссылке
- определение ПА в ГОСТ 56939-2024
- слайды 16, 18

Уважаемые коллеги!

Сегодня, 16:15 (мск) на канале Общественного телевидения России выйдет передача серии "Очевидно.Вероятно", посвященная математике - "Математика вокруг нас".

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

Ведущий программы – Арутюн Аветисян, академик РАН, директор Института системного программирования им. В.П. Иванникова РАН.

Гости программы – выдающие российские ученые, работающие в самых разных областях науки – математики, информатики, химии, биологии, астрономии и так далее.

Сегодня гость в студии – Николай Андреев, заведующий лабораторией популяризации и пропаганды математики Математического института им. В.А. Стеклова РАН.

Ссылка на прямой эфир ОТР: https://otr-online.ru/online/

https://otr-online.ru/programmy/ochevidno-veroyatno/anons-matematika-vokrug-nas-88285.html

Для того чтобы обеспечить четкую и объективную оценку выявленных замечаний, принято решение внедрить специальную систему классификации — шкалу критичности. Система классификации позволит структурировать рекомендации по степени их влияния на качество и корректность испытаний. Каждая Методическая рекомендация теперь будет не просто указывать на проблему, но и показывать, насколько её устранение важно для достижения целей испытаний.

Шкала «Критичность» разделяет все рекомендации на три основных уровня, каждый из которых отражает степень влияния ошибки на процесс и результаты испытаний:

- 3 (Недостаток высокого уровня критичности)
Прямое нарушение требований Методики ВУ и НДВ. Невыполнение требований, игнорирование ключевых процедур.

- 2 (Недостаток среднего уровня критичности)
Необоснованная приоритизация испытания с целью создания видимости проведения полноценного тестирования. Тестирование менее важных компонентов системы, неправильное распределение ресурсов, акцент на второстепенные задачи.

- 1 (Недостаток низкого уровня критичности)
Неэффективное выполнение испытаний, проведение испытаний с отклонениями от лучших практик РБПО.

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

Методическая рекомендация № 2025-04-005 | Уровень критичности: 2

Область: Фаззинг-тестирование / Оценка критичности дефекта ПО

Тип недостатка: Недостаточный анализ критичности выявленного аварийного завершения ПО. Несоответствие оценки критичности выявленного дефекта обоснованию выбора поверхности атаки

Описание: На рис. 1 представлена команда запуска фаззинг-тестирования командного интерпретатора bash, определенного экспертом как составляющего поверхности атаки, посредством передачи утилите на вход мутированных файлов-скриптов для последующих интерпретации и выполнения, для СЗИ типа А - "Операционная система общего пользования". На рис. 2 представлены статистики работы фаззера afl++, с помощью которого выполнялось фаззинг-тестирование. На рис. 3 представлен анализ результатов фаззинг-тестирования.

Фаззер зафиксировал несколько воспроизводимых падений тестируемого ПО. В качестве оценки критичности данных падений эксперт полагается на утилиту exploitalbe (см. ниже), экспериментальный инструмент, с некоторой долей вероятности классифицирующий критичность выявленных ошибок в тестируемом ПО. Данная утилита для ряда частных случаев может доказать наличие дефекта ПО и возможности его эксплуатации, автоматически построив пример эксплойта. Для большего числа случаев утилита может только классифицировать (с некоторой точностью) причину падения и подсветить её эксперту. Оценка критичности падения (разметка) в любом случае является прерогативой эксперта, "слепое" доверие экспериментальному инструменту с открытым исходным кодом не является корректным.

Особого внимания заслуживает тот факт, что выполняется фаззинг-тестирование утилиты, доступной любому пользователю, имеющему доступ к терминалу, выполняющейся с привилегиями данного пользователя (без повышенных привилегий - SUID, capabilities и т. п.). Пользователь в любом случае может подавать в интерпретатор bash произвольные подпрограммы (скрипты). Непонятен как выбор данной утилиты в качестве фаззинг-цели, так и трактовка её аварийных завершений, в качестве не несущих угроз безопасности. Если целью было найти падения, и они были найдены - почему данные падения не являются подтвержденными проблемами и не были исправлены. Если целью было повысить привилегии найдя и проэксплуатировав ошибку в утилите, выполняющейся с повышенными привилегиями - выбор bash некорректен.

Рекомендации:

- выбирать цели фаззинг-тестирования исходя из реальной поверхности атаки на СЗИ с учетом наиболее вероятных сценариев воздействия нарушителя

- досконально анализировать все выявленные аварийные завершения и дефекты кода, являющиеся их причинами, и приводить в протоколах подробные разъяснения

- взаимодействовать с Центром исследований безопасности системного ПО и апстримов с целью оформления Issue и передачи патчей, исправляющих выявленные дефекты кода


Дополнительные информационные материалы:

- презентация Центра
- детекторы утилиты exploitable
- CASR - открытый отечественный улучшенный аналог exploitable

Коллеги, добавившиеся сегодня после Релавэкспо - презентации представлены в основном чате из семейства чатов РБПО-сообщества ФСТЭК России и ИСП РАН https://t.me/sdl_community/8171

Методическая рекомендация № 2025-04-006 | Уровень критичности: 3

Область: Фаззинг-тестирование

Тип недостатка: Низкая стабильность фаззера. Снижение эффективности генетического фаззинга.

Описание: На рис. 1 и рис. 2 представлены статистики работы фаззера afl++ (UI-представление и текстовые логи работы фаззера). Характеристика стабильности работы фаззера - параметр Stability - является значимо отличной от целевого (максимального) значения 100%.

Стабильность - важный показатель работы фаззера, характеризующий степень воспроизводимости покрытия кода при запусках на одинаковых данных. Предполагается, что при запуске программы с одними и теми же входными данными на каждом запуске будет получено одинаковое покрытие кода, однако в реальности это не всегда так. Возможные причины:

- недетерминированное поведение программы. Выполнение программы может зависеть, например, от системного таймера и тогда могут выполниться другие базовые блоки. Изменение окружения от запуска к запуску также может влиять на выполнение программы

- ошибки в инструментировании. Даже если программа выполняется по одному и тому же пути, ошибки в инструментировании могут привести к тому, что покрытие будет сохраняться недетерминированно

Значение параметра стабильности меньшее 95%, особенно в случае если отличие составляет не 2-3%, а 5% и более, является признаком сниженной эффективности фаззинг-процедуры, поскольку фаззер "перестает понимать" полезность смутированных сэмплов для открытия новых трасс выполнения - теряется (снижается) эффективность, достигаемая за счет генетического фаззинга (фаззинга с "обратной связью").

Рекомендации:

- анализировать значение стабильности фаззера, рассматривать его как один из важнейших показателей корректной организации фаззинг-тестирования

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

Дополнительные информационные материалы:

- описание стабильности в документации Crusher (прил. Г, на русском)
- описание подходов AFL к повышению стабильности (на английском)
- библиотека preeny, модуль derand