Устройства, формирующие современный Интернет вещей, зародились еще в мире встраиваемых (бортовых) систем, унаследовав из него как возможности, так и ограничения. Google Home и Amazon Echo позволяют пользователям голосом управлять домашним оборудованием; термостаты и камеры Nest взаимодействуют с облаком, обеспечивая удаленный мониторинг и дистанционное управление, — подобные устройства прочно вошли в повседневную жизнь, а число их типов только увеличивается. В умных домах и системах автоматизации зданий, на промышленных предприятиях и в медицинских учреждениях уже порядка десятка миллиардов таких устройств. Все это оборудование пришло из мира встраиваемых систем, а их процессоры и микроконтроллеры различной архитектуры прошиты программным обеспечением, специализированным для каждого вида устройств. Большинство таких прошивок — фирменное программное обеспечение с закрытым исходным кодом. Конечные пользователи обычно не имеют представления о «содержании» таких прошивок и редко их обновляют, а если и делают это, то всего лишь «заливают» устройство неким двоичным кодом в надежде, что все будет работать не хуже прежнего.

С ростом популярности Интернета вещей оказалось, что не все работает по-прежнему — появились атаки, специально нацеленные как на изменение прошивок устройств при их обновлении, так и уже изначально запрограммированные для изменения функций устройства. Например, вредоносная программа BadUSB позволяет злоумышленнику снабдить прошивку USB-флешки функциональностью клавиатуры и выполнить сценарий автоматического набора нажатий клавиш, нужных для атаки, а BlueBorne [1] и BleedingBit [2] открывают возможность выполнить сценарии оболочки в целевой системе с использованием уязвимостей программных стеков Bluetooth и Bluetooth LE (Bluetooth с низким энергопотреблением) в прошивках микроконтроллеров. Смартфоны на платформе Android имеют свою уязвимость — из-за дыры в программном обеспечении ATtension на основе модемных команд [3] злоумышленник может обойти механизмы безопасности ОС. На ботнете Mirai — армии зараженных устройств Интернета вещей — лежит ответственность за серию наиболее масштабных на сегодняшний день распределенных DDoS-атак. И даже автомобили, в которых традиционно применялись полностью закрытые от внешнего враждебного мира системы, как выясняется, запросто могут быть дистанционно остановлены на трассе из-за уязвимости в телематическом контроллере [4].

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

Анализ прошивок

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

Интернет вещей: автоматизированный анализ прошивок

Рис. 1. Обзор подходов к анализу кода прошивок

Статический анализ использует только код прошивки и данные, не требуя работающего устройства или эмуляции его окружения. При статическом анализе могут быть извлечены и исследованы инструкции ассемблера и производимые ими манипуляции с данными. Общепринятым подходом к статическому анализу дизассемблированного исполняемого кода является восстановление управляющего потока, в результате которого между вершинами, представляющими процедуры, восстанавливаются ребра, представляющие собой передачу управления, — формируется остов программы для последующего анализа. При наличии списка функций и связей между ними можно отвечать на такие вопросы, как: «кто вызывает функцию X?», «какие байты относятся к коду, а какие к данным?». Статические подходы работают только с содержимым исполняемого кода, что накладывает определенные ограничения — функции и границы данных могут быть и не обнаружены, если нет явных вызовов и явных переходов. Например, отслеживание межпроцедурной передачи управления через непрямые ветвления — задача, чувствительная к контексту, а статический анализ не имеет доступа к состоянию программы, поэтому не может точно отслеживать все ветвления. Эта проблема характерна для таких языков, как C++, в которых для классов используются динамически присваиваемые списки указателей на функции для вызова методов. Таким образом, статический анализ имеет определенные ограничения и в целом вынужденно дает более пессимистичные оценки.

Динамический анализ выполняется с использованием действующей среды выполнения. Среда может быть запущена как на целевом оборудовании, так и на эмулированном. Возможны комбинированные варианты в зависимости от доступности аппаратных платформ и полноты реализации эмуляторов. Для аппаратного динамического анализа, скорее всего, потребуются множество экземпляров целевых устройств и развитые средства для их мониторинга и управления. В случае эмуляции анализ выполняется над программной моделью целевой системы. Самой популярной платформой для эмуляции оборудования является, по-видимому, QEMU, в которой реализовано множество архитектур и типов оборудования. При наличии качественной модели эмуляции анализ кода масштабируется пропорционально доступным вычислительным ресурсам, при этом не требуется дополнительных экземпляров целевого оборудования. Однако создание модели эмуляции требует больших затрат и усилий, что особенно проблематично в условиях оборудования специального назначения, разработанного под конкретную задачу. Эмуляторы значительно облегчают выявление уязвимостей и возможных утечек, позволяют достаточно легко инструментировать процесс в сравнении с закрытым кодом в «черном ящике». В случае, когда существует лишь частичная модель эмуляции и ее доработка до полного варианта слишком трудозатратна, для недостающих компонентов может быть задействовано реальное оборудование, такой подход используется фреймворком Avatar [5].

Символьный анализ использует подход, аналогичный динамическому анализу, но программная память описывается в некоторой символьной форме в процессе исполнения. Это означает, что байтам в памяти могут быть присвоены не просто конкретные значения, а их диапазоны. Программа пропускается через механизм символьного исполнения, который записывает каждую операцию в символьную память (сложения, вычитания, сдвиги и др.), в результате содержимое символьной памяти и регистров представляет собой некоторые выражения. Если выражения выходят на операции условного перехода или сравнения, то применяется вычислитель ограничений, определяющий, возможно или невозможно ветвление либо в каких границах допустимы варианты. Если однозначно определить ветку не удается, то символьное вычисление распадается на две части. Таким образом, если вся память определена как символьная, то данная техника выдаст все возможные пути выполнения программы для всех комбинаций входных данных. Но на практике исполнение достаточно сложной программы зачастую порождает так называемый взрыв состояний — экспоненциальный рост количества возможных состояний по всем возможным путям выполнения, что приводит к истощению памяти. Чтобы избежать этого, можно использовать так называемое целевое символьное исполнение, а также комбинации с традиционным динамическим анализом. Например, если прошивка получает входные данные только из определенного диапазона памяти, то только этот диапазон можно сделать символьным и тем самым ограничить потенциал «взрыва».

Поддержка новых архитектур микроконтроллеров

USB-контроллеры чаще всего основываются на микроконтроллерной архитектуре Intel 8051. В отличие от наборов инструкций x86 или ARM, для которых разработано множество средств анализа, 8051 — это система гарвардской архитектуры, корни которой уходят в 1980 год. Несмотря на то что она считается одной из самых распространенных в микроконтроллерном мире и базовый анализ исполняемого кода для нее существует уже около десятилетия, для 8051 не было полноценной поддержки глубокого анализа, в том числе средств символьного исполнения. В FirmUSB для анализа исполняемого микропрограммного кода для Intel 8051 предусмотрены средства двоичного подъема (binary lifter) — преобразователи двоичного кода в промежуточное представление для LLVM (Low Level Virtual Machine — проект инфраструктуры для создания компиляторов и сопутствующих утилит) и VEX IR (промежуточное представление кода Valgrind LLVM). «Подъемник» переводит инструкции ассемблера в платформно и архитектурно независимое промежуточное представление. Фактически это первый шаг по обратному инжинирингу процесса компиляции, позволяющий достичь высокоуровневого понимания исполняемого кода. Особенно важен выбор целевого представления — LLVM и VEX для применения фреймворков символьного исполнения FIE на основе KLEE (символьного интерпретатора кода LLVM) и ANGR (анализатора бинарного кода).

Однако в 8051 отсутствует иерархия памяти, а инструкции напрямую работают с процессорными регистрами и вводом-выводом через память (MMIO, memory-mapped input-output). Захват такой низкоуровневой семантики в целевых промежуточных представлениях вызывает сложности в связи с закладываемыми в таком подходе соглашениями и ограничениями. Например, в 8051 есть несколько областей памяти, доступ к которым имеют только определенные инструкции. При подъеме в стандартное промежуточное представление при символьном исполнении операции с памятью теряют эту семантику. Чтобы решить такую проблему, необходимо отлавливать все операции загрузки и сохранения и соответствующим образом поправлять операции перед их выполнением. Но в целом выполнение промежуточного представления недостаточно для точного воспроизведения поведения кода для 8051 как для LLVM, так и для VEX.

Другое ограничение — отсутствие побитовой семантики. Например, процессор 8051 может выполнять побитовые операции над системным управляющим регистром таким образом, что меняет только один бит, не трогая окружающие, поскольку каждый отдельный бит может иметь значение для состояния процессора. Однако оперирующие на байтовом уровне LLVM и VEX не могут компактно представить побитовые операции, сплошь и рядом встречающиеся в кодах прошивок. То есть для работы с одним битом приходится манипулировать целым байтом, в результате чего для символьного исполнения нужно проделать намного больше инструкций промежуточного представления, чем это потребовалось бы в случае поддержки побитовых операций; при этом процесс выполнения замедляется, а точность отражения операций с памятью снижается. Уже одно это различие может повлиять на качество воссоздаваемой среды в процессе символьного исполнения.

В общем случае микроконтроллерная архитектура во фреймворке символьного анализа должна в точности воспроизводить модель окружения прошивки, в том числе прерывания и обработчики. Для FirmUSB в FIE поддержаны прерывания для архитектуры MSP430 — 16-разрядных микроконтроллеров Texas Instruments, но фреймворк ANGR не поддерживает прерывания, поскольку спроектирован для анализа программ пользовательского уровня. Соответственно, в FirmUSB добавлено расширение к ANGR, позволяющее работать с обработчиками прерываний, расписаниями и некоторыми другими особенностями Intel 8051, такими как специальные или псевдонимные регистры. Все эти ограничения показывают актуальность создания специализированных для микропрограмм языков промежуточного представления и средств символьного исполнения.

Проверка поведения

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

В FirmUSB можно автоматически найти ответы на вопросы: «какими функциональными возможностями обладает данная USB-прошивка?» и «корректно ли микропрограмма выполняет заявленные функции?». Для этого использована техника символьного исполнения, проверяющая достижимость кодом точек, соответствующих поставленным вопросам. Так, для ответа на вопрос о функциональных возможностях проверяется, достигает ли микропрограмма точки в дизассемблированном коде, соответствующей искомой функциональности, такой как USB-накопитель или устройство пользовательского ввода (human interface device, HID). Для выявления потенциальных кусков кода, отвечающих за то или иное поведение, используется статический анализ потоков данных и производится отслеживание областей памяти, хранящих специфические для USB объекты. Для ответа на вопрос о корректности работы программы проверяется, например, пересылка HID-прошивкой клавиатурных кодов, полученных от внешнего порта ввода-вывода. Если она вместо этого передает какие-то заранее запрограммированные нажатия, то делается вывод о некорректности.

Символьное исполнение — мощное средство, помогающее получить ответ на такого рода вопросы, причем не ограничивающиеся сферой USB-прошивок. Сходная проблемно-ориентированная техника может быть применена, например, для анализа Bluetooth-прошивок: достаточно лишь обеспечить «поднятие» инструкций соответствующей аппаратной архитектуры до промежуточного представления, изучить алгоритмы в преломлении к возможностям Bluetooth и сделать выводы о поведении устройств. Принципиально возможно даже выработать некоторый согласованный набор проблемно-ориентированных вопросов к микропрограммам для стандартных тестов на соответствие, подобных тем, что проводит Underwriters Labs при сертификации в области пожарной безопасности.

Проблемно-информированный анализ

Поскольку нашей задачей был поведенческий анализ USB-прошивок, вопросы были сформулированы в контексте возможностей протокола USB: USB-устройство взаимодействует с хостом, отвечая на его запросы. Вызовы Get_Descriptor и Get_Configuration сообщают операционной системе о возможных функциях устройства. Все USB-устройства должны реализовывать эти вызовы, но для различных классов USB-устройств могут реализовываться и другие вызовы. Например, для класса HID-USB требуется предоставление существенно более сложной информации о возможностях, поэтому используется специальный дескриптор «отчет», чтобы сообщить хосту дополнительные сведения. FirmUSB работает с USB-константами для всех типов дескрипторов и ищет в прошивке ссылки на каждый из них. Использование этой проблемно-специфичной информации как отправной точки упрощает дальнейший анализ, так как дает среде символьного исполнения сведения об интересных для исследования местах.

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

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

AT-команды в Android

FirmUSB работает с традиционным типом микропрограммного обеспечения, выполненного в виде единого модуля исполняемого кода, обрабатывающего прерывания и работающего на микроконтроллере непосредственно без операционной системы. Android-прошивки — это программы более сложного типа; они включают образы операционной системы (Linux) и соответствующей файловой системы (rootfs), предоставляющие все необходимые средства пространства пользователя и сервисы. Целью данного исследования было изучение масштаба использования AT-команд в устройствах на базе Android с применением техник статического и динамического анализа кода.

Интернет вещей: автоматизированный анализ прошивок

Рис. 2. Процесс сбора и анализа прошивок

AT-команды впервые появились в начале 1980-х годов для управления модемами, но по-прежнему используются в современных смартфонах для обеспечения ряда телефонных функций, при этом они могут стать каналом проникновения к обширным функциональным возможностям устройства посредством доступа к привилегированным операциям. С использованием процесса, показанного на рис. 2, выявлено 3,5 тыс. применений AT-команд в более чем 2 тыс. Android-прошивок. Подавляющая часть этих вызовов не документирована. Среди них были AT-команды, способные «перешивать» устройство, обходить механизмы безопасности Android, извлекать чувствительную информацию об устройстве, разблокировать экран, имитировать события прикосновения к экрану и пр.

Сбор прошивок

В некоторых случаях, например у Google и ASUS, прошивки можно скачать с официального сайта, а другие производители прячут ссылки на загрузку под сложным интерфейсом, реализованным на устройстве, и не предоставляют возможности просто скачать образ. Сторонние сайты (например, AndroidMTK.com) коллекционируют различные прошивки, но зачастую встраивают множество перенаправлений, перед тем как выдать окончательный URL для загрузки. В результате нам удалось собрать более 2 тыс. образов от 11 различных производителей (atcommands.org). Таким образом, для пользователей и для аналитиков требуется простой и стандартизованный доступ к образам прошивок.

Инструментовка

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

Статический и динамический анализ

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

Статические методы не дают информации о том, действительно ли выполняется тот или иной код, поэтому необходимо физическое Android-устройство для проверки и подтверждения функциональности найденных AT-команд. С этой целью применяется унифицированный фреймворк, использующий USB-подключения к телефонам для выполнения соответствующих тестов. Таким образом на физическом оборудовании осуществляется динамический анализ, но так как некоторые команды приводят к сбоям, то требуется перепроверка неоднозначных результатов исполнения путем анализа исходного или исполняемого кода для подтверждения наблюдаемого поведения. Сочетая статический и динамический анализ, можно выявлять широкий диапазон функциональных возможностей, включая неизвестные ранее уязвимости. Очень вероятно, что существует и ряд других направлений, исследуя которые можно обнаружить и обезвредить новые уязвимости. Подробная техническая документация и результаты анализа прошивок могли бы способствовать этому. Кроме того, весьма полезными могут оказаться коллекции подключенных устройств, доступные по сети, такие как Droid Army Джошуа Дрейка.

Перспективы анализа прошивок устройств

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

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

Тем не менее имеются определенные подвижки, позволяющие говорить о возможности автоматизации процесса анализа в будущем. Например, символьное исполнение — одна из основных техник анализа программ, используемая в таких фреймворках, как Firmalice, ANGR, S2E и FIE. В этой технике сочетаются конкретные и символьные входные значения, поэтому удается получать относительно высокую точность и измеримость результатов. Но если посмотреть на различные типы процессоров и микроконтроллеров, используемые в устройствах Интернета вещей, то окажется (см. таблицу), что для многих микроконтроллерных архитектур невозможно получить промежуточное представление, необходимое для их включения во фреймворки символьного выполнения. Хотя во многих случаях поддерживается подъем до представления TCG, а для ряда архитектур поддерживается представление BIL для фреймворка Binary Ninja. Редко можно поднять исполняемый код до LLVM или VEX, которые необходимы для таких фреймворков, как FIE и ANGR. Опыт трансляции кода 8051 в LLVM и VEX свидетельствует о необходимости значительных трудозатрат для создания средств подъема до новых промежуточных представлений. Таким образом, одна из открытых проблем анализа прошивок — отсутствие полного покрытия существующими фреймворками всего спектра используемых сегодня микроконтроллерных архитектур.

Интернет вещей: автоматизированный анализ прошивок

Облегчить анализ помогли бы методы автоматизации «подъема» до промежуточного представления. За отправные точки могут быть взяты средства подъема для QEMU и результаты исследования выводимых в них соответствий. Не менее важно изыскать пути для обеспечения лучшей совместной работы различных существующих средств анализа. Некоторые средства анализа исполняемого кода и символьного исполнения поддерживают только один язык промежуточного представления, а каждое из них часто имеет свои сильные стороны. Например, ANGR блестяще справляется с задачей восстановления графа управляющего потока, тогда как KLEE оснащен богатым набором утонченных инструментов для символьного исполнения. Необходимо выработать пути для лучшего взаимодействия между такими средствами либо разработать способы трансляции промежуточных представлений, чтобы использовать результаты анализа, полученные разными инструментами. Подходы, подобные реализованному в платформе Avatar [5], позволяющей провести оркестровку различных средств анализа исполняемого кода, представляются наиболее перспективными и задают направление для исследований в этой области.

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

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

Необходимо отметить и другую серьезную проблему анализа прошивок — отсутствие стандартов для их образов и модифицирующих модулей, что создает серьезное препятствие при анализе ПО смартфонов. Стандартизация форматов для базовых образов и для модулей модификации существенно ускорила бы и автоматизировала анализ. Это касается и микроконтроллерных архитектур: разработчики зачастую добавляют специфические функции — например, для оборудования на основе семейства 8051/MSC-51. Стандартизация могла бы не только способствовать инструментализации процесса анализа, но и была бы полезна самим разработчикам архитектур в деле обеспечения целостности и неотделимости платформы, снизив издержки на создание собственных инструментальных средств решения этих задач.

Наконец, поскольку инструментарий анализа наиболее полно проработан для архитектур ARM и x86, а для этих платформ создается весьма сложное бортовое ПО, именно на их примере стоит изучить вопросы взаимодействия микропрограмм. Многие сложные устройства, такие как смартфоны и ресурсоемкие устройства Интернета вещей, не только оснащены центральным ARM-процессором, использующимся для запуска ОС, но также оборудованы различными датчиками с собственными микроконтроллерами (например, на архитектуре 8051). Однако разработчики устройств зачастую не знают всех функциональных возможностей этих контроллеров и даже устанавливают дополнительные защитные микросхемы для ограничения их потенциала. Таким образом, комплексный подход к анализу микропрограммного обеспечения на таких устройствах должен учитывать как прошивку верхнего уровня, запускаемую на центральном процессоре, так и микропрограммы для встроенных контроллеров.

***

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

Литература

1. G. Hernandez, F. Fowze, D. J. Tian, T. Yavuz, K. R. Butler. FirmUSB: Vetting USB device firmware using domain informed symbolic execution. In Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS'17). — Dallas, TX, 2017. — P. 2245–2262.

2. K. Nohl, J. Lell. BadUSB — On accessories that turn evil. Black Hat, Aug. 2014. [Online]. URL: https://www.blackhat.com/us-14/video/badusb-on-accessories-that-turn-evil.html (дата обращения: 03.12.2019).

3. D. J. Tian et al. ATtention spanned: Comprehensive vulnerability analysis of AT commands within the Android ecosystem. In Proc. 27th USENIX Security Symp. (USENIX Security 18), 2018. — P. 273–290.

4. V. Chipounov, V. Kuznetsov, G. Candea. S2E: A platform for in-vivo multi-path analysis of software systems // ACM SIGPLAN Notices. — 2011 (Mar). — Vol. 46, N. 3. — P. 265–278.

5. D. Davidson, B. Moench, T. Ristenpart, S. Jha. FIE on firmware: Finding vulnerabilities in embedded systems using symbolic execution. In Proc. 22nd USENIX Security Symp. (USENIX Security 13), 2013. — P. 463–478.

Дэйв Тянь (daveti@purdue.edu) — доцент кафедры информатики, Университет Пердью; Туба Явуз (tuba@ece.ufl.edu) — доцент кафедры электротехники и информатики, Патрик Трейнор (traynor@ufl.edu traynor@ufl.edu) — профессор кафедры информатики и инженерии, Грант Хернандез (grant.hernandez@ufl.edu) — аспирант, Фархан Фоуз (farhaan104@ufl.edu) — аспирант, Кевин Батлер (butler@ufl.edu) — доцент информатики, Университет Флориды, директор института исследований по кибербезопасности.

Grant Hernandez, Farhaan Fowze, Dave (Jing) Tian, Tuba Yavuz, Patrick Traynor, Kevin R.B. Butler, Toward Automated Firmware Analysis in the IoT Era. IEEE Security & Privacy, September/October 2019. IEEE Computer Society. All rights reserved. Reprinted with permission.