Анализ прошивки дрона DJI Mavic 3: часть 1

Лаборатория Nozomi Networks провела исследование безопасности дрона серии DJI Mavic 3, уделив особое внимание протоколу на базе Wi-Fi под названием QuickTransfer Mode. Этот протокол позволяет пользователю быстро загружать видео и фотографии с дрона непосредственно на свой мобильный телефон, когда дрон не находится в воздухе.

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

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

Компоненты связи DJI

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

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

- неясно, заслуживают ли доверия сторонние платформы и распространяют ли они оригинальное подлинное ПО;

- неизвестно, как долго образы будут оставаться доступными в сети;

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

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

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

1. Облачная инфраструктура DJI: облачная веб-инфраструктура, которая хранит пакеты прошивки для каждой модели дрона.
2. Пульт дистанционного управления: устройство, которое действует как пульт дистанционного управления для дрона.
3. Радиоконтроллер: специфическое оборудование DJI, которое общается с дроном через проприетарный беспроводной протокол DJI, называемый OcuSync.
4. Мобильное устройство: смартфон (iOS или Android), физически связанный с радиоконтроллером, который действует как графический интерфейс для пользователя;
5. Устройство дрона: целевое устройство, которое получает и устанавливает пакет обновления прошивки.

Процедура обновления прошивки DJI

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

Всякий раз, когда доступна новая версия прошивки, DJI Fly отправляет уведомление пользователю, который может выбрать, устанавливать её или нет. Прошивка подписана DJI и будет принята дроном только в том случае, если проверка подписи будет успешной. На рисунке 1 представлено изображение из официальной документации DJI, которое даёт обзор всего процесса.

После быстрого анализа мобильного приложения экспертам Nozomi Networks удалось собрать некоторые дополнительные детали, которые обобщены на рисунке 2. Хотя специалисты пытались пассивно отслеживать трафик между мобильным приложением и облачной инфраструктурой, они быстро поняли, что этого недостаточно из-за шифрования, обеспечиваемого HTTPS.

Первоначальная попытка атаки типа «человек посередине» (MitM) также не удалась из-за привязки сертификатов, реализованной в мобильном приложении, которая разрешает подключения только к сервисам, предоставляющим доверенный TLS-сертификат. Привязка сертификатов может быть реализована несколькими способами, со стандартными библиотеками или реализована с помощью пользовательского кода непосредственно внутри приложения.

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

Анализ приложения DJI Fly

Исследователи Nozomi Networks проанализировали последнюю доступную версию приложения DJI Fly для Android на момент анализа:

- Версия 1.9.0-3055175

- SHA256 7fbc75516445cf6c26decc08d286f76a46ab8079

После первого статического анализа, который включал изучение манифеста приложения и декомпилированных файлов .dex в файле .apk, специалисты обнаружили, что приложение не включает никакой реализации DJI. Вместо этого оно содержит оболочку приложения, реализованную как com.secneo, которая служит основной точкой входа для загрузки собственной библиотеки, известной как libDexHelper.so, и выполнения собственного метода на ней, как показано на рисунке 3.

В дополнение к файлу libDexHelper.so, многие другие собственные библиотеки включены в приложение. Однако из-за сильной обфускации кода такие инструменты, как Ghidra или IDA Pro, не могут сразу его проанализировать. Дальнейший анализ показал, что упаковщик также реализует несколько методов защиты от отладки и специфические возможности обнаружения Frida, что ещё больше усложнило анализ приложения.

Реверс-инжиниринг и анализ упаковщика для понимания того, как обойти эти защиты, чтобы отладить и инструментировать его, может быть чрезвычайно трудоёмким из-за сильной обфускации кода. Чтобы упростить код для дальнейшего анализа, исследователи выполнили дамп расшифрованных файлов .dex, читая необработанную структуру памяти приложения из /proc/self/maps через инъекцию кода, эксплуатируя записи DT_NEEDED с LIEF от QuarksLab, и проверяя его для извлечения распакованных данных.

В результате было извлечено несколько файлов .dex, и после некоторых скриптов с использованием dex2jar был создан единый JAR-файл с кодом приложения. Теперь JAR-файл можно анализировать с помощью таких инструментов, как Jd-Gui, как показано на рисунке 4.

Преодоление привязки сертификатов

При проверке кода можно найти реализацию привязки сертификатов, которая, по-видимому, выполняется с использованием стандартных библиотек, предоставляемых экосистемой Android. Для этой цели используется Java-класс TrustManagerFactory, предоставляемый пакетом javax.net.ssl, как показано на рисунке 5.

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

Поскольку каждое приложение в операционной системе Android создаёт клон основного процесса для запуска, это делает инъекцию прозрачной, так как она происходит до загрузки приложения. Киберэксперты достигли этого с помощью двух инструментов на рутированном мобильном устройстве Pixel 6a:

1. Фреймворк LSPosed, который позволяет делать инъекции на zygote-уровне.
2. Плагин TrustMeAlready, который реализует инструментарий класса TrustManager Android на zygote-уровне во время запуска приложения.

Загрузка и анализ прошивки

Способность проверять данные, обмениваемые между мобильным приложением и облачной инфраструктурой DJI, позволила исследователям проанализировать типы запросов и ответов, обмениваемых во время обновления прошивки на дроне. При обновлении Mavic 3 Classic специалисты перехватили связь и проанализировали API конечной точки, используемой для загрузки нового пакета прошивки.

Исследование показало, что дрон имеет несколько компонентов, каждый из которых имеет свой уникальный образ прошивки, идентифицируемый идентификатором модуля и загружаемый отдельно. Этот процесс выполняется через аутентифицированный HTTP REST запрос (по одному для каждого модуля прошивки) к конечной точке /getfile/downpath на хосте mydjiflight.dji.com, как показано на рисунке 6.

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

Авторы работы не исследовали точный способ генерации этой подписи, однако предполагается, что это код аутентификации сообщений на основе хэша (HMAC) как часть запроса. Ответ, в свою очередь, содержит ссылку с соответствующим ключом аутентификации, auth_key, как видно на рисунке 6, необходимым для загрузки образа прошивки.

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

Загруженный образ прошивки следует формату productID_moduleID_moduleVersion_buildDate.pro.fw.sig. В случае с Mavic 3 Classic наиболее интересным пакетом обновления в доступном списке является модуль с соответствующим ID 0802 из-за его большого размера, что предполагает, что он, вероятно, содержит основную операционную систему дрона.

Для анализа структуры образа прошивки отличным источником информации является поддерживаемый сообществом репозиторий Github dji-firmware-tools, который содержит документацию и некоторые скрипты. Изучая код dji_imah_fwsig.py, можно понять, как составлен образ прошивки:

1. Заголовок образа, содержащий размер (количество фрагментов) зашифрованной полезной нагрузки на основе фрагментов вместе с контрольными суммами зашифрованных и расшифрованных данных.
2. Список заголовков фрагментов, которые определяют смещение и размер фрагментов данных внутри образа.
3. Цифровая подпись на основе RSA как для заголовков образа, так и для фрагментов.
4. Список зашифрованных с помощью AES фрагментов, которые содержат необходимые данные для обновления прошивки.

Подлинность образа прошивки обеспечивается цифровой подписью заголовков образа. Злоумышленник, стремящийся изменить какие-либо данные, должен обновить значения контрольной суммы и дайджеста внутри заголовков образа (рисунок 8), что требует генерации новой действительной подписи RSA (невыполнимо без требуемого закрытого ключа). Это гарантирует, что дрон установит прошивку только в том случае, если она действительно предоставлена компанией DJI.

Из официальной документации DJI можно понять, что управление ключами осуществляется на дроне через ARM TrustZone CryptoCell, который хранит ключи для выполнения операций шифрования и проверки подписи.

Скрипт, предоставленный в dji-firmware-tools (dji_imah_fwsig.py), содержит список просочившихся ключей, которые можно использовать для расшифровки прошивки, однако ни один из этих ключей не был эффективен для загруженного образа, с которым работали исследователи.

К счастью, эксперты Nozomi Networks нашли независимого исследователя безопасности по имени Феликс Домке, который ранее публиковал некоторые ключи, связанные с DJI Mavic 3, в репозитории dji-firmware-tools. В одной из своих публикаций он поделился двумя ключами, связанными с DJI Mavic 3, идентифицированными как ключ шифрования образа обновления прошивки (UFIE) и ключ шифрования образа доверенной загрузки (TBIE).

Эти конкретные ключи не были интегрированы в список ключей, найденных в скрипте dji-firmware-tools для расшифровки и распаковки прошивки, поэтому исследователи вручную добавили их в код как UFIE-2022-04 и TBIE-2022-04 соответственно. С этим дополнением они наконец смогли успешно расшифровать прошивку, используя вручную добавленный ключ UFIE-2022-04, как показано на рисунке 9.

После распаковки оказалось, что фрагмент представляет собой JAR-архив, показанный на рисунке 10. При проверке было обнаружено, что он имеет такую же структуру, как пакет Android OTA, описанный в официальной документации. Это приводит к выводу, что серия дронов Mavic 3 работает на операционной системе на базе Android.

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

Экспертам удалось распаковать файлы vendor.new.dat.br и system.new.dat.br, которые представляют собой соответственно системный раздел (/system) и раздел поставщика (/vendor), используя официальную утилиту Google Brotli и инструмент sdat2img для создания монтируемых образов ext4, как показано на рисунке 11. Разделы system и vendor содержат все бинарные файлы, библиотеки и файлы конфигурации, необходимые для запуска служб дрона.

Помимо разделов system и vendor, файл normal.img является ещё одной интересной целью, поскольку он содержит основной образ Linux (ядро и корневую файловую систему). Этот файл зашифрован и может быть расшифрован только с использованием вручную добавленного ключа TBIE-2022-04 в скрипте dji_imah_fwsig.py. Расшифровка его с помощью этого ключа дала 18 фрагментов расшифрованных данных.

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

Копирование ранее извлечённых папок vendor и system внутрь корневого раздела завершает компоновку файловой системы Android, как показано на рисунке 12, со всем необходимым для анализа и реверс-инжиниринга служб, работающих на дроне.

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

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

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

Не пропустите вторую часть исследования, которая будет опубликована на нашем портале уже в ближайшее время.