Три года эксплуатации уязвимостей в эхолотах и судовых MFD: почему нельзя доверять конечному пользователю embedded-системы
Эхолот давно превратился из узкоспециализированного прибора в полноценный бортовой компьютер. Современный многофункциональный дисплей, или MFD, отвечает не только за отображение рельефа дна и поиск рыбы. Он объединяет картографию, навигацию, управление двигателем, радиосвязью, освещением, аудиосистемой и сигналами тревоги - включая уведомления о человеке за бортом и аварийные сообщения.
Чем больше функций сосредоточено в одном устройстве, тем выше цена ошибки. При этом встроенное программное обеспечение морской электроники нередко разрабатывается с приоритетом на удобство эксплуатации и поддержку оборудования, а не на полноценную защиту от вмешательства. История исследования прошивок эхолотов Lowrance и Simrad хорошо показывает, почему одной проверки цифровой подписи обновления недостаточно для гарантии безопасности.
Как началось исследование
В течение примерно трёх лет автор занимался русификацией эхолотов Lowrance и Simrad. Официально русскоязычный пакет поставлялся далеко не для всех регионов, поэтому на рынке сформировалась отдельная услуга по установке нужного языка. Одни специалисты использовали официальные подписанные обновления, полученные через дилерские каналы, другие искали способы модифицировать программное обеспечение самостоятельно.
В феврале 2023 года к этой задаче пришлось обратиться после покупки эхолота без русского интерфейса. На тот момент уже существовало несколько мастеров, способных выполнить русификацию, однако для этого прибор требовалось отправлять транспортной компанией. Из-за высокой стоимости устройства, большого стеклянного дисплея и риска повреждения было решено разобраться с проблемой самостоятельно.
Опыт в реверс-инжиниринге был минимальным: несколько простых задач, реверс старой игры и базовые соревнования по информационной безопасности. Перед исследователем оказался типичный embedded-прибор с монолитным приложением-комбайном. Это была не привычная Android-система и не Windows-компьютер, а специализированная платформа с неизвестной архитектурой и закрытой логикой загрузки.
Изучение прошивки без вскрытия корпуса
Самый прямой способ получить доступ к программному обеспечению - разобрать устройство, извлечь NAND или eMMC и считать содержимое памяти. Однако такой подход несёт очевидные риски: можно повредить плату, нарушить герметичность корпуса или окончательно вывести прибор из строя.
Поэтому исследование началось с файлов обновлений. Формат оказался достаточно удобным для анализа: файлы с расширением `.upd` представляли собой tar-архивы, внутри которых находились скрипты и компоненты прошивки.
Конкретная схема зависела от модели. В одних устройствах корневая файловая система поставлялась в архиве tar.xz, после чего разворачивалась в UBIFS для NAND-памяти. В других использовался сжатый образ Btrfs, который напрямую записывался в раздел eMMC. Ядро Linux и device tree объединялись в стандартный для U-Boot образ FIT. Внутри ядра находился initrd: он монтировал необходимые разделы, передавал управление сценариям rootfs либо запускал процедуру обновления.
На первый взгляд решение выглядело элементарным: достаточно было заменить языковой пакет в архиве на собственный, добавив русские файлы. Но именно здесь проявилась первая серьёзная преграда.
Почему простая замена файлов не сработала
Сценарий `update.sh` содержал SHA-1-хэши остальных компонентов обновления. Сам скрипт, в свою очередь, сопровождался цифровой подписью GPG, которую проверял код из initrd. Следовательно, простая подмена языковых файлов приводила к провалу проверки целостности, а изменение хэшей - к несоответствию подписи.
Теоретически подобную защиту можно было бы попытаться обойти через криптографическую коллизию SHA-1 или уязвимость в реализации GPG. Но для этого потребовались бы ресурсы и возможности, несопоставимые с задачей русификации эхолота. К тому же злоумышленник, способный надёжно взламывать криптографическую проверку, скорее всего, выбрал бы более ценные цели.
На этом этапе исследование было отложено. Казалось, что цепочка доверия построена достаточно грамотно: производитель подписывает сценарий, сценарий проверяет содержимое, а загрузчик не принимает изменённые данные.
Неожиданное изменение в обновлении
К задаче вернулись ближе к июню 2023 года. При повторном анализе выяснилось, что привычная модель обновлений изменилась. В мае вышла версия 23.3, причём Live-файл оказался примерно вдвое больше стандартного.
Установка теперь запускалась не напрямую из корня архива. Внутри появились две отдельные директории с собственными сценариями, а корневой `update.sh` фактически выполнял роль диспетчера: он определял, какой из вложенных вариантов следует запустить.
Это изменение оказалось принципиальным. Защита действительно контролировала целостность подписанного сценария в корне, но доверенная логика затем передавала управление другим файлам. Если один из внутренних сценариев не проходил аналогичную проверку, возникал классический разрыв цепочки доверия: безопасный компонент запускал потенциально изменяемый.
Именно такие ошибки особенно опасны в embedded-системах. Разработчики могут тщательно защитить загрузчик и основной пакет, но оставить без внимания вспомогательные сценарии, временные каталоги, инструменты восстановления или альтернативные ветки обновления.
Цепочка эксплуатации
Дальнейшее исследование сводилось не к поиску "магической" уязвимости, а к последовательному анализу доверенных компонентов. Важно было понять:
- какие файлы проверяются криптографически;
- кто именно запускает сценарий обновления;
- с какими правами он работает;
- какие разделы доступны на момент выполнения;
- можно ли повлиять на порядок монтирования;
- какие переменные и аргументы передаются дочерним процессам;
- существует ли отдельный режим восстановления.
Такой подход типичен для аудита встроенных устройств. Безопасность системы определяется не наличием подписи как таковой, а тем, насколько полно она распространяется на весь путь выполнения. Если подписан только верхнеуровневый манифест, а он запускает непроверенные команды, злоумышленнику достаточно найти слабое звено ниже.
В случае с эхолотами важную роль играло и то, что обновление выполнялось с привилегиями администратора. Это превращало локальную ошибку в скрипте в потенциальную возможность изменить корневую файловую систему, добавить собственные компоненты или добиться выполнения произвольного кода.
От изменения языка к выполнению кода
Русификация была лишь исходной целью исследования. Однако после обнаружения способов вмешательства задача переросла в полноценный аудит безопасности. Стало очевидно, что возможность заменить языковой пакет - это только частный случай более серьёзной проблемы.
Если атакующий получает возможность выполнить команды с правами root, он потенциально может:
- изменить системные настройки;
- заменить исполняемые файлы;
- встроить собственные сервисы;
- получить доступ к навигационным данным;
- вмешаться в работу сетевых интерфейсов;
- повлиять на взаимодействие с периферией и бортовыми шинами;
- закрепить модификацию после перезагрузки.
В промышленной или автомобильной системе подобные последствия очевидны. В морской электронике риск может быть ещё выше: единый дисплей связывает навигационные функции, картографию, двигатель, связь и аварийные уведомления. Поэтому компрометация MFD не ограничивается "неправильным языком меню".
Почему подпись обновления не решает проблему
Цифровая подпись подтверждает, что конкретный объект создан владельцем ключа и не был изменён после подписания. Но она не гарантирует, что подписанный объект безопасен сам по себе, не содержит ошибок и корректно обращается с другими файлами.
Надёжная модель должна проверять каждый компонент, который влияет на загрузку и выполнение: ядро, initrd, rootfs, сценарии, конфигурации, вспомогательные утилиты и данные восстановления. Кроме того, необходимо исключать запуск файлов из недоверенных каталогов и контролировать права доступа на каждом этапе.
Отдельная проблема - автоматические сценарии. Shell-скрипты часто кажутся безобидными, но именно они могут неправильно обрабатывать имена файлов, переменные окружения, аргументы командной строки и содержимое съёмных носителей. Любая такая ошибка, выполняемая с привилегиями root, становится потенциальной точкой компрометации.
Уроки для разработчиков embedded-устройств
История с эхолотами демонстрирует несколько универсальных выводов. Во-первых, нельзя считать конечного пользователя доверенной стороной. Пользователь имеет физический доступ к устройству, может копировать прошивку, анализировать обновления и экспериментировать с режимами восстановления.
Во-вторых, безопасность должна проектироваться по принципу минимального доверия. Подписанный установщик не должен автоматически доверять всем файлам, которые он запускает. Каждый переход между компонентами обязан сопровождаться проверкой происхождения и целостности.
В-третьих, необходимо защищать не только штатное обновление, но и аварийные режимы. Именно сервисные сценарии, заводские инструменты и процедуры восстановления часто остаются за пределами основного threat model.
Наконец, производителю важно разделять функциональность и привилегии. Интерфейс пользователя, обновлятор, драйверы периферии и сетевые службы не должны без необходимости работать с максимальными правами.
Итог
Исследование началось с бытовой задачи - добавить русский язык в купленный эхолот. Однако анализ формата обновлений показал, что даже хорошо заметная криптографическая защита может быть ослаблена ошибками в логике загрузки и исполнения.
Главный вывод прост: подпись файла не равна безопасности всей системы. Защищать нужно не отдельный архив и не один скрипт, а всю цепочку от первого загрузочного кода до конечного процесса. Если хотя бы один доверенный компонент запускает непроверенное содержимое с правами администратора, устройство может оказаться уязвимым независимо от качества используемой криптографии.
Для владельцев морской электроники это означает необходимость осторожно относиться к сторонним прошивкам, неизвестным пакетам обновлений и сервисным режимам. Для разработчиков - необходимость воспринимать пользователя не как доверенного оператора, а как потенциально мотивированного исследователя, имеющего полный физический доступ к своему устройству. Именно такой подход позволяет создавать embedded-системы, устойчивые не только к случайным ошибкам, но и к целенаправленному анализу.