Применение фаззинг-тестирования при разработке встраиваемого ПО терминалов релейной защиты (РЗА)

Фаззинг-тестирование – вид работ по исследованию программы, основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы ¹.

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

Фаззинг-тестирование – способ сделать ПО более надёжным и безопасным, систематически проверяя его на устойчивость к некорректным данным и реальным сценариям атак. Внедрение процедуры фаззинг-тестирования предусмотрено ГОСТ 56939-2024 в рамках внедрения процессов разработки безопасного программного обеспечения.

Как именно фаззить?

У большинства специалистов по безопасности приложений после принятия решения о внедрении практики фаззинг-тестирования встаёт вопрос «Как именно фаззить?». Если воспользоваться поиском, создаётся впечатление, что фаззинг-тестирование проводится преимущественно в отношении веб-приложений, некоторым типовым набором инструментов, используемых при пентестах, для участия в CTF и т.д. При этом информации о проведении фаззинг-тестирования встраиваемого ПО, например, микроконтроллеров или терминалов релейной защиты в открытом доступе практически нет. Большая часть неспециализированных ресурсов ссылается на поверхностные методики ограниченного применения.

Опыт есть!

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

Фаззинг же при этом осуществляется в отношении конкретных функций, используемых в коде приложения и определёнными инструментами, с которыми также можно ознакомиться на ресурсах ИСП РАН.

5 наиболее используемых инструментов динамического анализа и фаззинга из арсенала ИСП РАН:

1. Natch – это инструмент для определения поверхности атаки, основанный на полносистемном эмуляторе QEMU. Использует технологии анализа помеченных данных, интроспекции виртуальных машин и детерминированного воспроизведения.
2. Блесна проводит точный динамический анализ помеченных данных, проводимый комплексно, для объекта оценки и его программной среды функционирования. Возможности инструмента опираются на многолетний опыт разработчиков компиляторов и специалистов по информационной безопасности.
3. ИСП Crusher – программный комплекс, комбинирующий несколько методов динамического и статического анализа, в частности, фаззинг (ИСП Fuzzer) и символьное выполнение (в качестве одного из движков может выступать Sydr).
4. Sydr – инструмент динамического символьного выполнения бинарных программ, используемый для автоматической генерации тестов для сложных программных систем с целью увеличения покрытия кода и обнаружения ошибок. Строит математическую модель программы, позволяя фаззеру открывать новые пути выполнения, которые сложно обнаружить классическими методами генетических мутаций.
5. LibAFL-DiFuzz — это инструмент направленного фаззинга, основанный на модульной архитектуре фаззера LibAFL и инструменте статической предобработки DiFuzz. LibAFL-DiFuzz позволяет выполнять фаззинг-тестирование, фокусируясь на достижении определённых участков кода.

Для интеграции с CI-процессом ИСП РАН также предлагает использовать средство автоматизации фаззинга АвтоФАЗЗ.

Для решения задач по организации фаззинг-тестирования прикладного ПО доступен широкий арсенал инструментов. Однако, если стоит задача фаззинг-тестирования встраиваемого ПО на специфических архитектурах, то налицо дефицит инструментария.

Особенностью фаззинга встраиваемого ПО терминалов релейной защиты являются:

• определённые ограничения платформы;
• зависимость от аппаратной части;
• проблемы изоляции отдельных модулей и функций;
• проблемы сборки и среды исполнения.

Определение поверхности атаки для ВПО терминалов РЗА ограничено ручными способами, т.к. не существует инструментов автоматизации для определения поверхности атаки под большинство из встраиваемых платформ.

С точки зрения бизнеса ([[Бизнес со скоростью сборки]]) затраты на реализацию такого подхода в полном объёме крайне нежелательны. С практической точки зрения целесообразно прийти в этом вопросе к компромиссу – при невозможности внедрения сторонних инструментов в сжатые сроки в качестве начального этапа построения процессов РБПО внедрить фаззинг-тестирование по принципу «серого ящика».

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

С точки зрения разработчика фаззинг – это ещё один из вариантов интеграционного тестирования, что подталкивает к выводу о формировании дорожной карты внедрения процедур фаззинга поэтапно, начиная с фаззинга по методу «серого ящика».

Классические вопросы, которые стоят перед специалистом по безопасности приложений: «Хорош ли фаззер?», «Достаточное ли покрытие обеспечивается?», остаются актуальными и в случае разработки ВПО терминалов РЗА. Но к этим вопросам также добавляется ряд новых, не менее важных: «Для тестирования использовали другой компилятор. Можно ли перенести выводы тестирования на финальную сборку?», «Для тестирования использовалась не идентичная аппаратная платформа. А как поведёт себя код на реальном терминале РЗА?», «Мы собрали под х86, а что будет под ARM?». Широко используются системы на кристалле, при разработке ВПО, под которые требуется обязательно учитывать взаимное влияние модулей и аппаратных компонентов.

Особенности внедрения фаззинг-тестирования при разработке ВПО терминалов РЗА

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

Прилагая, согласно закону Парето, 20% усилий по методу «серого ящика» возможно получить 80% результата, что на начальном этапе внедрения процедур является оправданным, но, тем не менее, не отменяет планов по тестированию отдельных функций, признанных высокорисковыми на этапе определения поверхности атаки. В то же время, изучение поверхности атаки, результатов композиционного и статического анализа позволяет сконцентрировать и правильно направить усилия.

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

Например, самописный фаззер для терминала ЮНИТ М300 был написан на Python, исходный код объёмом 1000 строк, поддерживает на текущий момент 2 режима: «белый шум» и «разреженный белый шум». Фаззер генерирует полезную нагрузку на основе случайных чисел с помощью встроенного модуля random Python, которую может отправлять на заданный TCP-порт с заданной скоростью. Фаззер ожидает нестандартную обратную связь (заложены эталонные пары сообщений «запрос-ответ»), позволяет экспортировать копию отправляемых данных в файл и импортировать полезную нагрузку из файла.

Для полноценного отслеживания обратной связи был собран стенд, моделирующий процессы, происходящие на электрической подстанции, защищаемое оборудование и сигналы, так называемый «киберфизический двойник» подстанции. Коммуникационное оборудование в составе стенда позволяет проводить неинвазивный сбор трафика моделируемого объекта, а комплекс полунатурного моделирования РИТМ обеспечивает моделирование сигналов подстанции.

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

Вывод фаззера нуждается в отдельном анализе, который значительно затруднён полученным объёмом логов, и простая фиксация отличающихся ответных сообщений может быть не совсем информативна, т.к. параллельно требуется отслеживать события в пространстве сигналов РЗА, для чего обязательным условием является синхронизация всех устройств с единым источником времени.

Если синхронизация по какой-то причине будет нарушена (что само по себе может произойти в ходе тестирования, но будет зафиксировано в журнале терминала РЗА и испытательным оборудованием), то соотнесение блоков данных, поданных на интерфейс, с событиями будет значительно осложнено (скорее всего, невозможно в виду объёмов подаваемых данных).

В текущей конфигурации для синхронизации используется протокол NTP (в ряде конфигураций NTP+1PPS), но в перспективе использование протокола IEEE 1588 v.2 (PTP) через Ethernet.

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

В данный момент полезная нагрузка пактов формируется случайным образом, что требует увеличения объёмов и, как следствие, увеличивает время на тестирование.

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

В embedded-разработке на текущий момент очень мало готовых решений для фаззинга, что оправдывает применение подхода фаззинга методом «серого ящика» на начальном этапе.

Примечания

1. ГОСТ Р 56939-2024. Национальный стандарт Российской Федерации. Защита информации. Разработка безопасного программного обеспечения. Общие требования” (утв. и введён в действие Приказом Росстандарта от 24.10.2024 N 1504-ст)