Методическая рекомендация № 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

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

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

Тип недостатка: Отсутствие путей выполнения программы, обнаруженных фаззером.

Описание: На рис. 1 представлена статистика работы фаззера afl++ (UI-представление). Параметр last new find: none yet говорит о том, что за всё время работы фаззер не смог обнаружить ни одного нового пути выполнения программы.

При выполнении фаззинг-тестирования фаззер анализирует поведение программы, подавая на вход различные варианты тестовых данных (семплов). Основной метрикой эффективности работы фаззера afl++ является количество найденных уникальных путей выполнения исследуемой программы (объекта оценки). Если в процессе работы фаззера значение параметра last new find остается равным none yet, это указывает на то, что фаззер не может обнаружить ни одного нового пути выполнения программы. Полное отсутствие найденных путей выполнения программы является показателем неэффективности процедуры фаззинг-тестирования, так как основная цель фаззинг-тестирования заключается в исследовании различных сценариев работы программы для выявления потенциальных уязвимостей и ошибок. Такое тестирование не достигает своей цели и, как правило, не имеет практической ценности. В соответствии с требованиями Методики выявления уязвимостей и недекларированных возможностей, утвержденной ФСТЭК России 25 декабря 2020 года (далее - Методика ВУ НДВ), одним из критериев завершения фаззинг-тестирования является следующее условие:

В течение не менее двух часов фаззер не находит новой трассы или отсутствует прирост покрытия кода.

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

Дополнительное предупреждение (odd, check syntax!) может свидетельствовать о проблемах с форматом или синтаксисом входных данных, которые передаются фаззеру.

Возможные причины отсутствия найденных путей:
- некорректный формат входных данных. Если семплы, передаваемые фаззеру, имеют неправильный формат или не соответствуют ожидаемому синтаксису, программа может игнорировать их или обрабатывать некорректно (например, если программа ожидает JSON, а входные данные содержат недопустимые символы или неверную структуру, фаззер не сможет обнаружить новые пути);

- ограниченность начального корпуса. Начальный набор тестовых данных (корпус) слишком мал или не покрывает достаточное количество состояний программы. Это ограничивает возможности фаззера по исследованию новых путей (например, если корпус содержит только один или несколько однотипных семплов, фаззер может не иметь достаточно разнообразных входных данных для анализа). На рис. 1 значение параметра corpus count равно 1 - это значит, что на вход исследуемой программе был передан всего один семпл, что противоречит требованиям Методики ВУ НДВ.

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

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

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

- необходимо анализировать значения last new finds и corpus count для оценки эффективности работы фаззера

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

- описание основных параметров UI-представления AFL++