Космическая одиссея: анализ безопасности экспериментального программного обеспечения спутников

Аннотация

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

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

1.Введение

1. Введение

Спутники — это сложные технические устройства, которые размещаются в космическом пространстве в исследовательских целях или для предоставления наземным приложениям услуг, использующих покрытие земной поверхности. В то время как первый спутник, Sputnik, датируется 1957 годом, мы находимся в разгаре возрождения космических полетов, называемого Новой космической эрой [1]. Особенно в последние годы мы наблюдаем огромный рост числа спутников на околоземной орбите. По данным Управления ООН по вопросам космического пространства (UNOOSA), их количество почти удвоилось с 4867 в 2019 г. до 9350 в 2022 г. [2]. Подавляющее большинство этих спутников образуют мегагруппировки, такие как Starlink, которая планирует запустить более 40 000 спутников в ближайшие годы [3].

Малые спутники [4] лежат в основе новой космической эры, поскольку их размер и широкое использование готовых коммерческих компонентов (COTS) делают их доступными даже для небольших организаций. Кроме того, они охватывают широкий спектр вариантов использования, начиная от коммерческих приложений (таких как наблюдение Земли, межмашинная связь и интернет-сервисы) и заканчивая исследовательскими приложениями, такими как тестирование технологий, прогнозирование погоды и землетрясений и даже межпланетные миссии. [5]–[8].

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

В прошлом этот вопрос не был очень актуален, поскольку доступ к наземным станциям был дорогим и ограничивался крупными операторами спутниковой связи. Однако в последние годы ситуация коренным образом изменилась. В настоящее время наземные станции доступны даже для частных лиц, а с появлением моделей «Наземная станция как услуга» (GSaaS), таких как предлагаемые Amazon Web Services [9] и Microsoft Azure [10], входной барьер становится еще ниже. Мы видели в области безопасности мобильных сетей, как предположение провайдеров о том, что радиооборудование, необходимое для атак, будет слишком дорогим и недоступным для злоумышленников, было в конечном итоге опровергнуто технологическими достижениями [11]. Аналогичным образом доступные по цене наземные станции создают новую поверхность для атаки, где злоумышленники могут связываться со спутниками и использовать уязвимости программного обеспечения. Если им удастся скомпрометировать прошивку спутника, они смогут получить доступ к спутнику и потенциально получить полный контроль над системой.

Несмотря на ранние предупреждения [12], мало что было сделано для решения этой проблемы по нескольким причинам, как указывает Фалько [13]. Хотя отсутствие стандартов безопасности для спутников и сложная цепочка поставок усложняют ситуацию, основной причиной является недоступность программного обеспечения спутников. Исторически сложилось так, что разработчики спутников полагались на безопасность через неизвестность. Разработчики сети Iridium даже упомянули, что их система будет слишком сложной для злоумышленников [13]. Тем не менее, Дриссен и соавт. показали, что злоумышленники могут успешно расшифровать передачу данных по сети [14]. В частности, недоступность спутников на орбите делает lfvg прошивки исследователями очень сложным (если не невозможным), препятствуя прогрессу в этой области. Следовательно, разработчики спутниковых прошивок выступают в роли привратников и не предоставляют исследователям объекты исследования. Примечательно, что Павур и Мартинович [15], а также Фалько [13] признают, что тема все еще недостаточно изучена, и делают вывод о необходимости сотрудничества между разработкой спутников и сферой безопасности. Кроме того, в последнее время все большее внимание привлекают такие хорошо известные темы, как безопасность спутниковой связи, безопасность спутниковых интернет-сервисов и сценарии угроз для спутников [16], [17]. Однако в дискуссиях об отдельных спутниках обычно не хватает технических деталей спутников и реальных основ из-за недоступности спутникового программного обеспечения.

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

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

В-третьих, мы провели опрос 19 профессиональных инженеров и разработчиков спутников, чтобы расширить сферу нашего исследования. Всего в ответах содержится техническая информация о 17 спутниках, а всего участники работали со 132 спутниками. Наш опрос показывает, что неясность протокола так же распространена, как и шифрование для защиты доступа, и что небольшие группы разработчиков скорее склонны разрабатывать полностью настраиваемые протоколы, чем использовать существующие. Как отметил один из участников нашего опроса: «Мы сосредоточились на предоставлении функционирующей системы, а не безопасной».

Подводя итог, мы делаем следующие основные вклады:

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

- Систематический анализ безопасности трех реальных образов прошивок спутников, который выявил 13 уязвимостей и основан на модели злоумышленника с учетом последних технических разработок (например, GSaaS).

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

2. Спутниковый контекст

Искусственный спутник (обычно сокращенно спутник) — это объект, намеренно размещенный в космическом пространстве, который вращается вокруг другого тела, например Земли. Спутники предназначены для работы в суровых условиях космоса, включая экстремальные перепады температуры около 200 °C, происходящие более десяти раз в день, почти вакуум и космическое излучение. Однако развертывание в космосе часто необходимо для предоставления космических услуг на Землю с общими спутниковыми приложениями, включая связь, наблюдение за Землей и исследования. Хотя большинство спутников развернуто на НОО (250–2000 км), в зависимости от назначения спутника могут потребоваться другие орбиты, такие как геостационарная орбита (ГСО) (35 786 км).

2.1. Спутниковые операции

Спутниковые операции, как показано на рис. 1, развиваются вокруг трех основных компонентов: группового сегмента, который управляет спутниковой службой, космического сегмента, состоящего из всех космических средств, и пользовательского сегмента, который получает спутниковую службу, такую как Глобальная система позиционирования (GPS) или связь.


2.1.1. Наземный сегмент. Наземный сегмент является центром всех спутниковых операций на протяжении всего срока службы спутника. Группа операторов связывается со спутником, используя наземную станцию (GS), чтобы передать спутнику новые инструкции, называемые Telecommand (TC). В свою очередь, спутник отправляет телеметрию (TM) обратно в GS, предоставляя информацию о статусе спутника, ошибках и других показателях. TC использует космический протокол, который мы описываем в разделе 2.3. Далее мы называем комбинацию данных TC и TM трафиком TC/TM.

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

2.1.3. Пользовательский сегмент. Терминал, например, терминал с очень малой апертурой (VSAT) или приемник GPS в пользовательском сегменте, получает услугу, предоставляемую космическим сегментом. Обратите внимание, что некоторые спутники, такие как спутники наблюдения Земли, обмениваются данными исключительно со своим наземным сегментом и не включают пользовательский сегмент.

2.2. Спутниковая архитектура

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

2.2.1. Система управления и обработки данных (CDHS). Шина сосредоточена вокруг CDHS, которая управляет спутником и контролирует все функции космического корабля. CDHS использует бортовой контроллер (OBC), который использует вычислительную платформу, то есть микроконтроллер и память, аналогичную наземным встроенным устройствам. Программное обеспечение, выполняемое в этой системе, называется бортовым программным обеспечением (OBSW), которое является основным направлением нашей работы. Он реализует сервер удаленного управления, обычно основанный на операционной системе реального времени (RTOS), аналогичный наземным приложениям реального времени. Основной задачей OBSW является обработка трафика TC/TM, обеспечение хранения данных, планирование команд, выполнение автономных действий и обновление программного кода. Важно отметить, что OBSW, как и любое программное обеспечение, уязвимо для распространенных ошибок программного обеспечения, которые злоумышленники могут использовать для получения несанкционированного контроля над CDHS.

2.2.2. Коммуникационный модуль (COM). Связь с GS обеспечивается коммуникационным модулем (COM), который состоит из антенны, радиостанции и, иногда, вычислительной установки для обработки декодирования, реализации протоколов и проецирования доступа. Кроме того, COM обычно предназначен только для трафика TC/TM, тогда как трафик с высокой пропускной способностью, такой как нисходящий канал данных полезной нагрузки, часто обрабатывается более мощной радиоустановкой. Поскольку COM напрямую связан с CDHS для обработки трафика TC/TM, он также является основной точкой входа для злоумышленников, создавая значительную поверхность атаки. Кроме того, реализация протокола в COM может иметь отношение к безопасности, поскольку может быть первой линией защиты.

2.2.3. Система определения ориентации и управления (ADCS). Спутники используют ADCS для определения и корректировки своего положения, чтобы они могли направлять антенны на Землю, а солнечные панели — на Солнце. Кроме того, ADCS выполняет автономную раскрутку для прекращения углового вращения спутника после его выхода из ракеты-носителя, что необходимо для установления исходной связи. Кроме того, спутник может также использовать двигатель для создания системы управления ориентацией и орбитой (AOCS) для незначительных изменений орбиты, что особенно важно по соображениям безопасности. AOCS превращает спутники в киберфизические системы, поскольку они могут воздействовать на свое физическое окружение, врезаясь в другой объект, что может привести к разрушительной орбитальной цепной реакции (см. раздел 3.1.1).

2.2.4. Блок питания (EPS). Электроэнергетическая система (EPS) — это источник питания спутника, обычно вырабатываемый солнечными панелями и хранящийся в батареях для обеспечения питания в отсутствие света, например, при движении вокруг Земли. Кроме того, очень важно, чтобы батарея никогда полностью не разряжалась, так как в этом случае спутник не может перезапуститься. Следовательно, управление питанием имеет решающее значение для живучести, поскольку глубокий разряд батареи представляет интерес для злоумышленников, чтобы навсегда отключить спутник.

2.2.5. Полезная нагрузка. В то время как полезная нагрузка в основном развертывает оборудование для конкретной миссии, она часто также развертывает систему обработки данных полезной нагрузки (PDHS), которая действует аналогично CDHS. PDHS может либо получать управляющий трафик от модуля связи полезной нагрузки (PLCOM), которым может быть любой приемник полезной нагрузки, либо выполнять общие задачи обработки данных от оборудования полезной нагрузки. Из-за высокой степени настройки полезной нагрузки точные термины для PDHS и PLCOM могут отличаться в описаниях других спутников.
2.3. Протоколы спутниковой связи
Спутниковый трафик TC/TM передается через протокол спутниковой связи, который мы назвали космическим протоколом на рисунке 1. Основной организацией, публикующей такие космические протоколы, является Консультативный комитет по системам космических данных (CCSDS), консорциум многочисленные космические агентства, которые договариваются о стандартах. В конечном счете, CCSDS предоставляет множество стандартов протоколов для связи со всеми компонентами и сторонами, участвующими в работе космического корабля [18]. Эти стандарты охватывают все уровни модели OSI, и обычно на каждый уровень приходится несколько вариантов [19]. Протоколы, упомянутые в этой работе, — это Space Data Link Security (SDLS) для канального уровня, который также реализует расширение безопасности [20], и Space Packet Protocol (SPP) для сетевого уровня. Обратите внимание, что коллекция CCSDS больше похожа на коллекцию всех сетевых протоколов, обычно используемых в Интернете, чем на конкретный протокол. Далее мы будем называть набор протоколов CCSDS протоколом CCSDS.

3. Угрозы спутниковой прошивки

Теперь мы предлагаем таксономию угроз встроенного программного обеспечения для спутников в виде трехуровневого представления, показанного на рисунке 3. На рисунке обобщены наши представления об угрозах встроенного программного обеспечения для спутников, чтобы обеспечить компактный и функциональный обзор. В предыдущей работе Falco и Boschetti [21] была представлена широкая классификация общих угроз для спутников, включая экологические, физические и цифровые кибер-технические риски. Последние служат целями атакующего высокого уровня, поэтому наши работы хорошо интегрируются с их таксономией. Обратите внимание, что их работа представляет собой более абстрактную классификацию высокого уровня, в то время как наша фокусируется на подробных технических угрозах для спутниковой прошивки.

3.1. Таксономия угроз

Наша таксономия, представленная на рис. 3, включает в себя три слоя, которые мы описываем, используя подход «сверху вниз». На самом верхнем уровне, уровне управления, мы находим конечные цели атакующего. Для их достижения злоумышленник должен нацелиться на какой-либо компонент, который представляет собой функциональный вспомогательный компонент (см. раздел 2.2) на уровне компонентов. Чтобы связаться с компонентом, злоумышленник должен сначала получить доступ к одному из интерфейсов, которые находятся на интерфейсном уровне, и управлять взаимодействием между компонентами и внешними субъектами, такими как GS.

Сплошными линиями мы описываем иерархию элементов (т. е. шина является частью сателлита, а СГД — частью шины, см. рис. 3), а набором точечных стрелок — пути атак (т. е. злоумышленник должен получить доступ к COM перед выдачей телекоманды в CDHS). Мы используем цвета, соответствующие различным слоям рисунка 3.

3.1.1. Слой управления. Мы моделируем цели высокоуровневого злоумышленника против спутника на основе окончательных цифровых кибер-технических рисков, определенных Фалько и Боскетти [21]. Затем мы определяем промежуточные цели, которых злоумышленник должен достичь для достижения своей конечной цели, и различаем два целевых компонента: шину и полезную нагрузку. Напомним, что шина управляет полезной нагрузкой, что позволяет достигать цели по полезной нагрузке от шины, но не наоборот. Такое разделение шины и полезной нагрузки обычно встречается в спутниках из-за соображений безопасности, чтобы предотвратить распространение неисправностей оборудования полезной нагрузки. Далее мы подробно рассмотрим цели злоумышленника и то, как они касаются разделения шины и полезной нагрузки.

Отказ в обслуживании/контроле. Отказ в обслуживании (DoS) сегодня является наиболее распространенным вектором атаки на спутники [22] и угрожает доступности спутника. Это может быть достигнуто как на шине, так и на полезной нагрузке, которая развертывает оборудование для обслуживания спутника. Напротив, отказ в управлении может быть достигнут только через шину.

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

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

Захват контроля не только проблематичен для владельцев спутника, но и может иметь разрушительные последствия для всей космической экосистемы. Если спутник развернет двигатели, злоумышленники могут попытаться вызвать синдром Кесслера, эффект, при котором обломки одного спутника сталкиваются с другими спутниками, разрушая их и испуская новые обломки, что приводит к цепной реакции. Эти обломки потенциально могут сделать космос недоступным на десятилетия, как показано в симуляциях [23], [24]. Эти потенциальные последствия единственного успешного взлома спутника в значительной степени игнорируются сообществом безопасности, даже несмотря на то, что они могут сильно повлиять на космические полеты, какими мы их знаем.

3.1.2. Слой компонентов. Уровень компонентов состоит из соответствующих общих спутниковых компонентов (см. раздел 2.2), канала связи «шина-полезная нагрузка» и системы обработки недоверенных данных (UDHS). На практике эти компоненты могут быть отдельными аппаратными компонентами или объединены в единый образ микропрограммы. Здесь мы разделяем их по функциям.

Далее мы обсудим каждый компонент, его задачи и угрозы для него. Мы классифицируем угрозы по трем общеизвестным столпам безопасности: честность (1), доступность (3) и конфиденциальность (4). Кроме того, мы рассматриваем Стабильность (2) как подкатегорию Целостности для описания угроз, которые изначально существуют в спутнике, но подвергают риску эксплуатационную целостность спутника, если они доступны злоумышленникам.

COM/PLCOM. COM получает входящие TC по удаленному каналу (например, по радио), в то время как PLCOM получает либо данные полезной нагрузки, либо TC, предназначенные для полезной нагрузки. Так как мы рассматриваем только атаки на прошивку спутников, мы резюмируем угрозы против (PL)COM как обход контроля доступа. Сюда входят общие радиочастотные угрозы, такие как атаки «человек посередине», и криптографические угрозы, такие как временные побочные каналы, которые подробно исследовались в предыдущих работах [25], [26]. Кроме того, сюда входят угрозы, нацеленные на микрокод, демодулирующий или декодирующий TC.
CDHS. CDHS обрабатывает входящие TC, выполняя соответствующую функцию в программно-аппаратном обеспечении спутника, которая выполняет прямое или запланированное действие на спутнике (см. раздел 2.2). Он должен соответствовать следующим требованиям:

(1) Целостность. Уязвимые TC могут позволить злоумышленнику получить доступ к личным данным, перехватить поток управления или утечку информации. Сюда также входят все уязвимости, связанные с повреждением памяти при обработке TC, например, переполнение буфера, уязвимости строки формата или уязвимости использования после освобождения [27].

(2) Стабильность: некоторые чрезмерно разрешительные опасные TC могут позволить злоумышленнику захватить управление доступом к спутнику, механизм обновления прошивки, поток управления или критические данные, просто выпустив соответствующий TC. Такие TC часто существуют для целей отладки. TC, которые предоставляют произвольные гаджеты для записи в память (например, для отладки) или произвольные изменения секретов управления доступом, не должны реализовываться, в то время как доступ к образу микропрограммы должен требовать дополнительного уровня проверки (например, подписанные образы), что обычно рекомендуется и называется глубокоэшелонированной защитой [28].

(3) Доступность: обработка TC должна быть доступна в любое время для срочных действий, таких как корректировка курса. Мы суммируем все угрозы доступности CDHS как угрозы подавления TC, поскольку они подавляют способность спутника обрабатывать TC.

(4) Конфиденциальность: TC могут позволить злоумышленнику выдать секреты, например, касающиеся управления доступом, и тем самым поставить под угрозу весь спутник, если эта утечка допускает повышенный доступ. Мы резюмируем утечки управляющих данных как угрозу конфиденциальности CDHS.

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

(1) Целостность: ссылка не развертывает собственные TC, а использует те, что из CDHS, через интерфейсы TC. Эти API-подобные интерфейсы могут быть уязвимы, как и уязвимые TC, которые мы классифицируем как уязвимые интерфейсы TC.

(2) Стабильность. Критические интерфейсы TC могут скомпрометировать шину, преднамеренно предлагая чрезмерно разрешающую функциональность команд для (потенциально скомпрометированной) полезной нагрузки. Критические TC включают неограниченное управление питанием или регулировку положения спутника, чтобы сделать радиосвязь невозможной. Команды, выдаваемые полезной нагрузкой, должны воздействовать только на оборудование полезной нагрузки и должны быть обратимыми в любой точке шины. Разница между критическими и опасными TC заключается в том, что критические TC предлагают функциональные возможности, которые должны быть эксклюзивными для шины, в то время как опасные TC должны либо вообще не существовать (даже на шине), либо должны требовать дополнительной аутентификации/проверки.

(3) Доступность: если существует более одного PDHS или UDHS, ни один из них не должен отказывать другим в доступности канала. Таким образом, мы определяем подавление ссылок как угрозу для связи между подключенными компонентами полезной нагрузки.

(4) Конфиденциальность: линк скомпрометирован, если компоненты полезной нагрузки могут извлекать информацию, предназначенную исключительно для других компонентов полезной нагрузки. Мы резюмируем их как утечки данных полезной нагрузки.

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

(1) Целостность: мы обобщаем все классические угрозы уязвимости программного обеспечения, подобные уязвимым TC, как уязвимую обработку данных.

(2) Стабильность. Это имеет значение только в том случае, если PDHS обрабатывает командный трафик аналогично CDHS для полезной нагрузки. В этом случае мы определяем категорию угроз опасной полезной нагрузки, аналогичную опасным TC.

(3) Доступность: Доступность PDHS находится под угрозой, если возможность обработки входящих пакетов запрещена, что приводит к отказу в обслуживании полезной нагрузки. Следовательно, мы называем это отказом в обслуживании полезной нагрузки.

(4) Конфиденциальность: мы определяем утечку информации общего характера как угрозу конфиденциальности PDHS.

UDHS. UDHS запускает ненадежный код пользователей полезной нагрузки непосредственно на спутнике. Поскольку код ненадежен, он должен быть изолирован от обычных операций с полезной нагрузкой в PDHS. Этот компонент не является частью общей спутниковой архитектуры (см. раздел 2.2), но с учетом тенденции к аренде спутниковых возможностей и соображений по созданию орбитальных сервисов облачных вычислений [29], [30] пришло время рассмотреть этот компонент. На практике мы обнаружили, что этот компонент развернут в наших тематических исследованиях в разделе 5.2.

PDHS и UDHS имеют особые отношения в нашей таксономии. Во-первых, UDHS может быть частью PDHS (т. е. PDHS работает под управлением операционной системы, где один изолированный процесс выполняет ненадежный код), где в той же среде также выполняется обработка данных полезной нагрузки. Во-вторых, PDHS может быть частью UDHS, т. е. UDHS развертывает (ненадежное) приложение, которое обрабатывает данные от принимающих компонентов. С точки зрения злоумышленника приложение для синтаксического анализа, развернутое UDHS, действует как PDHS. Мы называем этот PDHS в оболочке UDHS UDHS-PDHS. С точки зрения пути атаки UDHS-PDHS по-прежнему изолирован, что отличает его от основного PDHS, но при этом он сталкивается с теми же угрозами, что и PDHS. Мы выделяем пример этого механизма в разделе 5.2.

(1) Целостность + (2) Стабильность: целостность UDHS находится под угрозой, если изоляция среды подвергается атаке, которую мы называем угрозами Escape to PDHS.

(3) Доступность: Мы не рассматриваем угрозы доступности UDHS, поскольку только UDHS-PDHS имеет обязательства по доступности.

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

3.1.3. Интерфейсный слой. Интерфейсы образуют третий и нижний уровень нашей таксономии. Всякий раз, когда компонент взаимодействует с другим компонентом или внешним источником, между ними используется интерфейс. Мы различаем два типа интерфейсов: внешние интерфейсы, которые взаимодействуют между компонентом и внешним элементом. Каждый интерфейс имеет только одного родителя, например, родителем COM Rx является COM. Однако компонент может иметь несколько интерфейсов, например, CDHS может иметь два разных сборщика TC для COM и канала полезной нагрузки шины. На рис. 3 мы опускаем стрелки между интерфейсами и компонентами для простоты, но каждый интерфейс имеет линию иерархии, ведущую к родителю, и пунктирную стрелку пути атаки от интерфейса к компоненту.

Внешний приемник. Внешние интерфейсы получают данные из-за пределов спутника (например, радиоприемники или оптические приемники). Мы опускаем рассмотрение угроз, поскольку в нашей модели эти интерфейсы реализуют только чисто аппаратные операции без программного обеспечения и могут подвергаться только электромагнитным и радиочастотным угрозам. Если спутник использует прошивку, то есть в виде микрокодов для выполнения демодуляции сигнала, мы считаем это частью COM, поскольку эксплуатация потенциально может привести к обходу контроля доступа. Следовательно, мы рассматриваем этот интерфейс только для моделирования наших злоумышленников, как подробно описано в разделе 4. Кроме того, мы рассматриваем только получателей структурированных данных, которые анализирует какой-либо компонент. Например, научная аппаратура для измерения радиации или термометр не могут получать побитовые структурированные данные, что исключает их из нашего рассмотрения.

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

(1) Целостность + (2) Стабильность: Злоумышленник может захотеть манипулировать существующими данными, вводя новые или изменяя существующие данные. Таким образом, внедрение и изменение данных представляют собой угрозу целостности сборщиков данных. Например, интерфейс TC Fetcher скомпрометирован, если злоумышленнику удается внедрить дополнительный TC, хотя был отправлен только один.

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

3.2. Получение информации о спутниках

Наша таксономия на рис. 3 выделяет не только угрозы, но и пути атак и все вычислительные компоненты, обнаруженные на спутнике. Следовательно, наша таксономия функциональна и позволяет нам получать модели для конкретных спутников, которые перечисляют все возможные деревья атак и полную поверхность атаки. Далее мы сначала опишем, как получить спутниковую модель, которую мы также используем для всех трех тематических исследований (см. Раздел 5). Затем мы объясним, как из этой модели можно извлечь все деревья атак и поверхности атакующих.

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

В частности, при сопоставлении компонентов каждый компонент в слое компонентов может быть продублирован или удален, чтобы соответствовать конкретным требованиям спутника. Например, если у спутника нет PDHS или UDHS, оба (а также канал Bus-Payload Link) можно удалить, оставив только COM и CDHS. Если спутник имеет несколько компонентов PLCOM, мы дублируем компонент PLCOM, сохраняя при этом линию иерархии и стрелку пути атаки для каждого отдельного COM. Примечательно, что нельзя создавать новые компоненты, можно дублировать только существующие компоненты таксономии.

Далее интерфейсы сопоставляются с компонентами. Каждый компонент изначально имеет собственный интерфейс (см. рис. 3). Однако, поскольку у каждого интерфейса может быть только один родитель, но несколько дочерних элементов, несколько интерфейсов могут совместно использоваться как принимающие интерфейсы для одного компонента. Например, CDHS может использовать один и тот же сборщик TC для нескольких COM, т. е. при наличии активных резервных COM.

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

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

4. Модель атакующего

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

4.1. Знание злоумышленника

На первом этапе мы рассматриваем преобладающее, но устаревшее предположение, которое необходимо пересмотреть.

Безопасность через неизвестность. На протяжении десятилетий спутниковое сообщество и разработчики выступали в роли привратников в отношении темы спутниковой безопасности [15]. Держа программное обеспечение и компоненты спутников под замком, они создали «барьер неясности», препятствовавший любым значимым исследованиям по этому вопросу. Следовательно, у внешних сообществ не было возможности изучить внутреннее устройство спутника и потенциальные проблемы безопасности.

В последние годы это изменилось, поскольку разработки в космической области переместились в сторону компонентов COTS [15], [31], конструкций открытых спутников [7], [32] и библиотек с открытым исходным кодом [33]. Эти факторы были умножены на взрывной рост числа спутников [4] и неотъемлемое увеличение размера сообщества. Следовательно, число людей, владеющих знаниями о спутниках, неуклонно растет. В целом, мы утверждаем, что медленно происходит трансформация эффективности защиты за счет скрытности в космических средствах.

Пересмотренное предположение. В результате мы должны предположить, что злоумышленники имеют подробные сведения о целевом спутнике, включая подробную документацию и доступ к образам прошивки. Кроме того, несколько спутников с открытым исходным кодом уже позволяют злоумышленникам изучать спутники [34]–[36]. Поэтому мы предполагаем, что злоумышленники имеют подробные сведения о спутниках, включая их прошивку, за исключением криптографических секретов.

4.2. Уровень доступа злоумышленника

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

Миф о недоступности. До недавнего времени считалось, что спутники всегда связываются с непомерно дорогими GS. В результате лишь немногие субъекты могли атаковать спутник (аналогично предположению для сетей мобильной связи много лет назад). Это предположение оказало большое влияние на адаптацию функций безопасности в спутниках [15]. Однако за последние несколько лет цены на GS значительно снизились. Сегодня можно создать полнофункциональную GS менее чем за 10 000 долларов [37], и существуют сообщества с открытым исходным кодом, занимающиеся разработкой GS [38]. Кроме того, поставщики GSaaS, такие как Amazon Web Services или Microsoft Azure, сдают в аренду GS пользователю [9], [10] или позволяют владельцам GS монетизировать неиспользуемые мощности GS, временно сдавая их в аренду конечным пользователям. В результате для взаимодействия со спутниками даже не нужно иметь собственное ГС-оборудование. Кроме того, приемопередатчики для определенных спутниковых служб стали настолько компактными и дешевыми, что их можно найти в бытовой электронике, такой как iPhone 14 [39]. Кроме того, в настоящее время в космосе имеется множество группировок спутников LEO с возможностью межспутниковой связи. В то же время растет число небольших исследовательских низкоорбитальных спутников. В космосе уже есть ряд спутников со значительными коммуникационными возможностями, которые даже предназначены для использования третьими сторонами [32].

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

4.3. Модели злоумышленников

Далее мы описываем модели злоумышленников с учетом наших пересмотренных предположений. Кроме того, мы подключаем каждого злоумышленника к интерфейсу из нашей таксономии, представленной в разделе 3.1.3.

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

Пользовательская атака наземной станции. Связь с GS является основным каналом управления спутником. Даже если этот канал защищен с помощью механизмов контроля доступа, злоумышленник может обойти контроль доступа, который мы идентифицировали как основную угрозу для COM-компонентов (см. раздел 3.1.2). С этой целью мы предлагаем собственный атакующий GS, который может связываться с целевым спутником через любой GS, кроме того, который используется операторами спутников, поскольку он может содержать секреты управления доступом. Мы также предполагаем, что злоумышленники обладают необходимыми знаниями для установления радиосвязи, то есть частотами, модуляциями и орбитальной позицией, за исключением вышеупомянутых секретов.

ISL атака. В дополнение к пользовательскому доступу к GS мы предполагаем, что внешний злоумышленник имеет доступ к пользовательским спутникам для связи с внешними принимающими интерфейсами через соединения ISL (см. Раздел 2.1).

4.3.2. Злонамеренные полезные нагрузки. Пользователи полезной нагрузки являются субъектами пользовательского сегмента (см. раздел 2.1) и предназначены для взаимодействия со спутником через полезную нагрузку спутника. Злоумышленники службы полезной нагрузки используют заранее определенную услугу, предлагаемую спутником, обычно используя небольшую антенну, предоставленную поставщиком услуг спутника, как показано на рисунке 4b. Далее трафик, испускаемый злоумышленником, должен быть обработан на борту спутника, т. е. путем его парсинга, и получен на интерфейсе Payload Data (PD) Fetcher. Кроме того, мы суммируем злоумышленников, которые успешно скомпрометировали полезную нагрузку, например, через PDHS, как атакующих полезную нагрузку. Они взаимодействуют с шиной с помощью интерфейса Link TC Fetcher, что позволяет им потенциально распространить атаку с полезной нагрузки на шину.

4.3.3. Вредоносный хост службы полезной нагрузки. Эти хостеры имеют возможность размещать настраиваемую службу в полезной нагрузке, то есть путем загрузки ненадежного кода. Ненадежная служба этого пользователя выполняется на UDHS. Следовательно, злоумышленник имеет доступ к UDHS для загрузки, обновления или изменения службы с помощью интерфейса сборщика недоверенных данных (UD), как показано на рисунке 4c.

4.3.4. Операторы. Операторы контролируют работу спутника и осуществляют полный контроль над спутником, выдавая команды через интерфейс TC Fetcher. Хотя мы не рассматриваем атаки со стороны полностью привилегированных операторов, мы утверждаем, что операторы часто делятся на полностью привилегированных и полупривилегированных. Это может относиться к любой достаточно большой группе операторов, где обязанности и права доступа разделены. Этот сценарий становится более вероятным благодаря модели «Спутник как услуга» (SataaS), при которой доступ к спутнику сдается в аренду ненадежным третьим сторонам. В таких сценариях недоверенные стороны могут взаимодействовать ограниченным образом, например, включать или выключать полезную нагрузку, вызывая проблемы с повышением привилегий.

Полупривилегированный инсайдер. Полупривилегированное положение, показанное на рисунке 4d, позволяет злоумышленникам взаимодействовать, используя некритические TC, например, запрашивать данные телеметрии или управлять системами, не относящимися к жизненно важной полезной нагрузке. Следовательно, этот злоумышленник взаимодействует со спутником, находясь в ограниченном пространстве, например, с помощью наземных ограничений на загрузку. Хотя сообщение этого злоумышленника принимается механизмом управления доступом спутника, злоумышленник не имеет прямого доступа к криптографическим секретам.

5. Тематические исследования

Мы демонстрируем применимость нашей таксономии и моделей злоумышленников в реальных условиях путем подробного анализа трех разных спутников. Для каждого из них мы сначала проводим технический анализ компонентов спутника, который используем для построения модели угроз для конкретного спутника с использованием нашей таксономии, как описано в разделе 3. В таблице 1 представлен обзор проанализированных спутников, включая ключевые данные. Затем мы анализируем безопасность прошивки спутников, и в таблице 2 суммированы основные результаты. Мы обнаруживаем, что каждый спутник затронут, и успешно обнаруживаем несколько уязвимостей. В двух кейсах мы экспериментально проверили возможность эксплуатации выявленных нами уязвимостей и добились выполнения произвольного кода на CDHS, предоставив злоумышленнику полный контроль над спутником, чего, насколько нам известно, никогда раньше не было.

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

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

В качестве второго примера мы искали более сложный спутник и нашли идеальный пример в OPS-SAT. Мало того, что Европейское космическое агентство (ЕКА) участвует в разработке, которая уже вносит свой вклад в знания крупного космического агентства, так еще и спутник является открытой исследовательской платформой, что приводит к интересной модели злоумышленника.

Наконец, мы нацелились на еще более крупный и сложный спутник. Здесь прекрасным примером является Flying Laptop, поскольку его вычислительная установка на основе FPGA работает аналогично даже гораздо более сложным спутникам.

Объем анализа. В ходе нашего анализа мы сосредоточимся на OBSW в CDHS, так как злоумышленники могут использовать этот модуль для получения полного контроля над спутником. В OBSW мы фокусируемся на канале данных TC/TM, поскольку он является основной поверхностью атаки. Таким образом, мы анализируем разбор входящих пакетов, затем следим за обработкой TC перед их выполнением и фактическим выполнением TC. Мы также анализируем влияние заметных ТК и ищем в них уязвимости. Обратите внимание, что все функции и уязвимости в следующих тематических исследованиях активно используются на спутнике, если мы не указываем иное.

Метод анализа. Мы использовали IDA Pro и Ghidra в качестве инструментов во время нашего анализа. Наш первоначальный анализ был ручным и в основном включал обратное проектирование двоичных файлов прошивки, когда мы анализировали поток данных от COM-систем до обработки телеуправления. Таким образом, мы вручную проверили и исследовали код на предмет проблем с безопасностью. Кроме того, мы искали ссылки на функции, вызывающие повреждение памяти, такие как memcpy и strcat. Наконец, мы использовали фаззинг с учетом покрытия путем повторного размещения прошивки для ESTCube-1 с использованием Fuzzware от Scharnowski et al. [40].

Согласованное раскрытие. Мы ответственно и скоординированно сообщили о наших выводах соответствующим разработчикам спутников и GomSpace, разработчику космического SDK, и предложили свою помощь в решении проблем. Команда ESTCube-1 уже подтвердила, что исправит проблемы в грядущем ESTCube-2. Команды OPS-SAT, Flying Laptop и GomSpace подтвердили, что получили наши отчеты, но не раскрыли никаких подробностей и не ответили ни на один из наших последующих запросов.

Исправление уязвимостей спутников. Оценка времени, необходимого для исправления уязвимостей, как правило, непростая задача, поскольку она зависит от сложности лежащей в основе проблемы. Кроме того, спутники сталкиваются с уникальной проблемой — загружать исправленную прошивку. Команда ESTCube-1 сообщила нам, что загрузка образа прошивки обычно занимает от нескольких дней до недели, в зависимости от GS и качества связи. Это связано с низкой пропускной способностью компонентов УВЧ/ОВЧ (т. е. 9600 бит/с) и общей пропускной способностью.

5.1. ESTCube-1

ESTCube-1 был первым спутником Эстонии. Он был разработан Тартауским университетом в сотрудничестве с Немецким аэрокосмическим центром (DLR). Спутник 1U CubeSat на НОО был выведен из эксплуатации в 2015 году, оставаясь на орбите. Основная цель спутника состояла в том, чтобы продемонстрировать новый метод движения, называемый электрическим солнечным парусом [42]. Второстепенной задачей спутника было наблюдение Земли в видимом спектре. Спутник второго поколения будет запущен в январе 2023 года и использует большинство программных компонентов совместно с ESTCube-1. Таким образом, с нуля разрабатываются только компоненты, характерные для новой миссии, а это означает, что следующие результаты, вероятно, также повлияют на ESTCube-2.


5.1.1. Технический анализ. На рис. 5 показан обзор ESTCube-1, который развертывает два настраиваемых компонента полезной нагрузки [7]. Конструкция спутника довольно проста, так как все компоненты напрямую управляются CDHS без специального PDHS. CDHS использует резервный STM32F103VF ARM OBC с OBSW на основе FreeRTOS.

Трафик TC/TM, обрабатываемый CDHS, принимается через COM, который содержит несколько антенн. Одна антенна сверхвысокой частоты (UHF) используется для трафика TC/TM с GS, а другая антенна прослушивает очень высокие частоты (VHF) для сигнала аварийного сброса. Кроме того, имеется антенна S-диапазона для передачи данных изображения с камеры. Примечательно, что конструкция COM не предусматривает механизмов защиты доступа или шифрования.

Протокол внутренней связи. Компоненты ESTCube-1 используют специальный протокол внутренней связи (ICP) для связи с CDHS и GS. Протокол не использует никаких мер безопасности, таких как шифрование или аутентификация, и спроектирован так, чтобы быть простым. Он использует простую схему адресации, в которой каждый компонент, включая GS, имеет идентификатор (например, GS = 5, а CDHS = 2). При синтаксическом анализе пакета в CDHS полезная нагрузка ICP используется как пакет TC и направляется планировщику команд, который в конечном итоге выполняет команду. В конечном счете, протокол представляет собой минимальное решение для отправки упорядоченных пакетов в небольшой ячеистой сети компонентов.

5.1.2. Модель угрозы.

На рис. 6 показана модель угроз, полученная на основе нашей таксономии (см. раздел 3), включая выявленные нами уязвимости. Поскольку полезная нагрузка спутника не предлагает PDHS или внешних приемников для структурированных данных, модель угроз включает только шину. Антенна S-диапазона не входит в комплект, так как используется только для передачи. Поверхность атаки ESTCube-1 определяется через интерфейсы. Следовательно, только внешние злоумышленники с настраиваемой GS против COM Rx и полупривилегированных операторов, подключенных к TC Fetcher, имеют значение (см. Раздел 4.3).

Экспериментальная установка. Мы перестроили (части) спутник в нашей лаборатории, чтобы экспериментально проверить наши результаты. Мы воссоздали аппаратное обеспечение CDHS спутника, используя тот же микроконтроллер STM32 на коммутационной плате с отладчиком J-Link. Кроме того, мы подключили спутник к исполнительным механизмам, представляющим функции управления полезной нагрузкой. Эта установка запускает OBSW без изменений на том же оборудовании. Кроме того, мы подключили динамик к порту, который обычно занимает Solar Sail (см. раздел 5.1.1). Создание эксплойта, воспроизводящего звук, доказывает, что мы можем контролировать этот (или любой) порт.

5.1.3. Анализ безопасности. Резюмируем наши основные выводы. Незащищенный доступ к телеуправлению. Наиболее поразительной проблемой ESTCube-1 является отсутствие шифрования и аутентификации TC, что приводит к тривиальному обходу контроля доступа (см. Раздел 3) на COM. Во время активной эксплуатации спутника внешние злоумышленники с кастомным GS могли отдавать спутнику произвольные команды.

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

Небезопасные по дизайну ТС. Даже без защиты доступа спутник должен быть сконструирован таким образом, чтобы TC не нарушали стабильность спутника без дополнительной проверки, как указано в разделе 3. Здесь два конкретных TC допускают произвольное чтение и запись памяти. На техническом уровне злоумышленник контролирует все параметры, передаваемые в memcpy через аргументы команды, так что эти два TC являются опасными TC. Любой, у кого есть собственный GS, может использовать их для удаленного выполнения кода и захвата контроля над спутником.

Примечательно, что возможность выполнения произвольного кода позволит злоумышленнику постоянно записывать обновления прошивки во флэш-память, что делает захват необратимым. За исключением современных операционных систем, таких как Linux или Windows, которые развертывают средства защиты для предотвращения тривиального использования таких уязвимостей, ОСРВ в ESTCube-1 не имеет таких средств защиты. В частности, не используются ни ASLR, ни куки-файлы стека. Чтобы доказать влияние этой уязвимости, мы создаем эксплойт, отправляем нашу полезную нагрузку через COM-интерфейс нашего восстановленного спутника в лаборатории и выполняем произвольный код (в нашем случае мы воспроизводим звук через подключенный динамик).

Поле размера доверенного ICP. После получения пакета ICP пакет передается через очередь данных FreeRTOS планировщику команд, который выполняет соответствующую команду, используя включенные аргументы. Мы заметили, что функция, анализирующая структуру команды, не проверяет поле «длина аргументов» на соответствие общей длине пакета ICP или полезной нагрузки. Таким образом, любой внешний злоумышленник может указать злонамеренное поле длины, которое указывает, что аргументы будут длиннее, чем они есть на самом деле. Это приводит к тому, что функция обработчика команд использует больше байтов из памяти кучи, чем предполагалось, что приводит к перечтению буфера. Следовательно, злоумышленник может включить в TC злоумышленника другие данные, что приведет к утечке управляющих данных (см. раздел 3.1.2). Опять же, мы проверяем, что это работает на реальном спутнике, тестируя его на нашем воссозданном оборудовании, и нам удается успешно использовать эту уязвимость. Сама утечка надежна и не зависит от условий окружающей среды, но извлечение конкретных секретов зависит от схемы кучи. Примечательно, что эта уязвимость аналогична известной уязвимости OpenSSL Heartbleed [43].

5.2. OPS-SAT

OPS-SAT — первый спутник CubeSat, управляемый непосредственно ЕКА. Спутник был разработан Технологическим университетом Граца, запущен в 2019 году на ЛЕО и продолжает активно использоваться. Спутник предлагает универсальную платформу для проведения научных экспериментов и демонстрации технологий. Примечательно, что люди, независимые от ЕSА и не имеющие специальных знаний о спутниках, могут разрабатывать эксперименты с помощью специальной среды с открытым исходным кодом [44], [45]. Следовательно, спутник обеспечивает редкий сценарий с ненадежными третьими лицами, проводящими эксперименты, которые могут получить более широкое распространение в будущем, поскольку SataaS становится более преобладающим [46], [47]. Таким образом, OPS-SAT является отличным примером для раннего изучения этого сценария угрозы. Любопытно, что OPS-SAT недавно участвовал в конкурсе по безопасности. Там спутниковая шина считалась запрещенной, вероятно, из-за критичности потенциальной эксплуатации, что подчеркивало влияние наших результатов [48].

5.2.1. Технический анализ. OPS-SAT разделен на спутниковую шину и полезную нагрузку в соответствии с нашей эталонной спутниковой моделью (см. раздел 2.2), где полезная нагрузка развертывает эксперименты и связанные с ними устройства. На рис. 7 показаны наиболее заметные части и упрощенная версия их соединений.

Спутниковая полезная нагрузка. Полезная нагрузка спутника в нижней части рисунка 7 сосредоточена вокруг спутниковой экспериментальной платформы обработки данных (SEPP) с холодным резервированием, которая оснащена двухъядерным процессором ARM Cortex A9. Кроме того, SEPP подключается к программно-определяемому радио (SDR), камере и тонко регулируемому ADCS, который требуется для оптического приемника (опция Rx). Кроме того, полезная нагрузка развертывает радиопередатчик S-диапазона для передачи данных с высокой пропускной способностью и передатчик X-диапазона для нисходящих каналов с более высокой пропускной способностью. Трафик от этих радиостанций обрабатывается механизмом CCSDS, который реализует аппаратное декодирование CCSDS в программируемой пользователем матрице (FPGA), подключенной к OBC и SEPP.

Спутниковая шина. Спутниковая шина в верхней части рисунка 7 имеет общую конструкцию спутниковой шины и сосредоточена вокруг резервных OBC NanoMind A3200 [49]. COM развертывает радио UHF/VHF для связи с GS.

OBSW использует RTOS FreeRTOS v8.2.1 и построен с использованием SDK GomSpace NanoMind, который обеспечивает аппаратные абстракции и общие функции, такие как доступ к файловой системе и базе данных параметров. Для обработки TC из COM используется Cubesat Space Protocol (CSP), реализованный в библиотеке с открытым исходным кодом libCSP. Протокол обычно используется для небольших спутников из-за минимального сетевого протокола. Таким образом, CSP используется для передачи SPP, который, в свою очередь, содержит данные телеуправления. Кроме того, OBSW также может получать TC в оболочке SPP от механизма CCSDS и SEPP.

5.2.2. Модель угрозы. На рис. 8 представлена модель угроз для OPS-SAT, основанная на нашей таксономии угроз (см. раздел 3). CDHS имеет два сборщика TC, один через шину I2C, подключенный к UHF/VHF COM, и один, подключенный через шину Controller Area Network (CAN) к COM S-диапазона, который имеет механизм CCSDS. CAN-TC Fetcher также получает TC от полезной нагрузки.

Полезная нагрузка содержит PDHS, который в OPS-SAT называется SEPP. Этот PDHS развертывает UDHS для запуска ненадежных приложений научных экспериментов в изолированной среде. Как описано в разделе 3.1.2, среда, в которой выполняется научное приложение, представляет собой UDHS, а само приложение моделируется как вложенная PDHS (UDHS-PDHS). Наконец, все компоненты полезной нагрузки имеют доступ к PLCOM S-диапазона, который физически представляет собой ту же радиостанцию, подключенную к движку CCSDS, что и COM S-диапазона, и они имеют дополнительный доступ к SDR (SDR PLCOM) и оптическим приемник.

Таким образом, OPS-SAT открывает значительную поверхность для атак благодаря обилию вариантов связи. Все злоумышленники, описанные в разделе 4.3, относятся к соображениям безопасности OPS-SAT и используют интерфейсы, показанные на рис. 4, в то время как сборщик UD-PD является сборщиком PD.

5.2.3. Экспериментальная установка. Поскольку плата NanoMind, используемая на реальном спутнике, стоит дорого, а аналогичные платы сняты с производства, мы прибегли к программной эмуляции и статическому анализу. Насколько нам известно, для этой ISA не существует полноценного эмулятора. Поэтому мы реализовали ISA AVR32UC3 в QEMU с нуля, чтобы предоставить нам точную среду тестирования и оценки. CDHS, такие как флэш-память.

5.2.4. Анализ безопасности. Далее мы кратко суммируем наши основные выводы. На рис. 9 представлены уязвимости, которые мы выявили в шине. На рисунке 9 мы опускаем синюю сателлитную рамку, содержащую возможность захвата управления, и интерфейс PD Fetcher из-за нехватки места.