Блог

May 21, 2024

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

Распространение Интернета вещей сопровождалось увеличением количества уязвимостей безопасности. Если их не остановить, злоумышленники могут использовать эти уязвимости для проникновения в системы организаций. Обычный

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

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

Чтобы помочь командам безопасности освоить тестирование встроенных устройств на проникновение, Жан-Жорж Валле, старший вице-президент Kroll, консалтинговой компании по киберрискам и финансовым услугам, написал книгу «Практическое тестирование оборудования на проникновение: изучите методы атаки и защиты для встроенных систем в IoT и других устройствах». .

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

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

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

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

Эмпирическое правило при сравнении динамических и статических подходов заключается в том, что в 99% случаев динамические подходы проще, и им следует отдавать приоритет, если это возможно (не забывайте, что вы не сможете получить доступ к JTAG/SWD или другим протоколы встроенной отладки).

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

Целевая программа находится здесь, в папке, которую вы клонировали, в папке ch12.

Для начала давайте начнём с загрузки его в Ghidra и поверхностно его осмотрим. Обратите внимание на установку правильной архитектуры и базового адреса в окне загрузки Ghidra (обратитесь к предыдущей главе, если вы не помните, как это сделать или значение базового адреса).

На первый взгляд функция main очень похожа на функцию main из предыдущей главы. Мы можем найти ссылку на основную функцию, выполнив поиск по строке ПАРОЛЬ, как в предыдущей главе, и проанализировав ее структуру.

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

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

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

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

Давайте посмотрим на код C, эквивалентный функции проверки, который выводит Ghidra:

Хм... это ничего не делает напрямую с параметрами. Это копирование содержимого статического массива байтов длиной 0x47 (71) в ОЗУ (и НЕ его), а затем вызов его как функции.

Это странно.

Или это?

Это очень распространенный метод маскировки кода (конечно, очень простой его вариант). Если четкая версия кода операции отсутствует в файле .bin (и, следовательно, ее нет во флэш-памяти MCU), инструмент обратного проектирования, такой как Ghidra, не сможет обнаружить, что это код! Здесь у нас есть два возможных подхода: