Как нечеткое тестирование усиливает безопасность устройств Интернета вещей

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

С распространением устройств Интернета вещей растет число атак на встроенные системы безопасности. Исторически сложилось так, что инженеры встраиваемых систем игнорировали безопасность на уровне устройства, несмотря на то, что многие области встроенных устройств уязвимы для ошибок. Последовательные порты, радиоинтерфейсы и даже интерфейсы программирования / отладки могут быть использованы хакерами. Нечеткое тестирование представляет собой важное место, доступное инженерам для поиска слабых мест во встроенных устройствах, и его следует учитывать при укреплении интерфейсов устройств IoT.

Что такое нечеткое тестирование?

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

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

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

Принципы нечеткого тестирования

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

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

Многие современные компиляторы, такие как GCC и Clang, имеют функцию, называемую очисткой памяти. Это помечает блоки памяти как чистые или грязные, в зависимости от того, используются ли они, и отмечает любую попытку доступа к грязной памяти. Однако очистка памяти потребляет циклы флэш-памяти, ОЗУ и ЦП, что затрудняет работу на встроенных устройствах. Поэтому вместо этого мы можем протестировать подмножество кода, создать версию устройства с дополнительными ресурсами или использовать ПК.

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

Однако числа покрытия кода сложно интерпретировать для встроенного нечеткого тестирования, потому что большая часть кода недоступна для векторов нечеткости; например, драйвер устройства для периферийного устройства, работающего независимо от интерфейса. Поэтому трудно определить «полное покрытие кода» для встроенных систем - возможно, только 20% встроенного кода доступны. Покрытие кода также потребляет большое количество циклов флэш-памяти, ОЗУ и ЦП, и для работы потребуется специализированное оборудование или целевой компьютер.

Отчеты об ошибках

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

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

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

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

Непрерывное нечеткое тестирование

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

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

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

Архитектуры Fuzz-тестирования

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

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

Ниже приводится сводка четырех архитектур нечеткого тестирования:

• Прямое тестирование интерфейса на встроенном оборудовании - запуск обычного производственного образа на встроенном устройстве с вводом нечетких пакетов через интерфейс.
• Тестирование пакета (стека) - вызов подпрограмм для входящих пакетов напрямую, без необходимости проверять интерфейс по воздуху.
• Управляемый фаззинг с помощью симулятора - с использованием методов моделирования на базе ПК для разработки и тестирования встроенного кода.
• Фаззинг на основе покрытия с помощью симулятора (показан ниже как Libfuzz).

Несколько тестеров фаззинга

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

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

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

>> Эта статья была первоначально опубликована на наш дочерний сайт EDN.