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

В этой статье мы расскажем, какие механизмы в KasperskyOS позволяют снизить риски, характерные для распространенных ОС. А также покажем на реальном примере, как системы на базе Linux и KasperskyOS по-разному справляются с киберугрозами.

В качестве примера мы выбрали сценарий вредоносной функциональности, заложенной в open-source-драйвер сетевой карты. В свете роста количества и сложности атак на цепочку поставок сценарий более чем реалистичный. Если вам интересно, почему мы выбрали именно сценарий использования Linux-драйвера и атаку на цепочку поставок, — оставим объяснения под спойлерами.

Модели угроз современных ОС, «песочницы» для приложений и драйверов

Разумеется, при создании собственной операционной системы мы не собирались изобретать велосипед. Поэтому для начала мы провели анализ распространенных стандартов безопасности операционных систем и безопасной разработки, а также изучили подходы, которые применяют создатели современных коммерчески успешных ОС. В числе прочих мы изучили Android, ChromeOS, GrapheneOS, Whonix, Ubuntu Core, Qubes OS, Genode OS Framework, Legato, HarmonyOS NEXT, OpenBSD, seL4.

Большинство этих систем переосмысляют взгляды на модель угроз персональных и профессиональных устройств. То есть устройств, которые круглые сутки подключены к глобальной Сети и обрабатывают контент из недоверенных источников со сложной структурой, а также позволяют расширять функциональность за счет приложений, разрабатываемых третьими сторонами. При этом такие устройства могут быть атакованы с использованием разнообразных беспроводных технологий, таких как NFC, Bluetooth и Wi-Fi. А носимые девайсы вдобавок могут попасть в руки злоумышленников, то есть для их защиты необходимо рассматривать угрозы, предполагающие еще и физический доступ.

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

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

Угрозы и способы их митигации в KasperskyOS

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

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

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

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

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

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

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

Демонстрационный сценарий

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

На базе этого сценария мы построили экспериментальный стенд с использованием Radxa ROCK 3A. Стенд состоит из двух образов, выполняющих идентичную бизнес-задачу. При этом один образ реализован на простой сборке GNU/Linux, а другой использует KasperskyOS Community Edition. Обе системы имеют идентичную модельную «закладку» с уязвимостью в сетевом драйвере. Отправка специально сформированного пакета вызывает незамедлительный переход драйвера в ошибочное состояние.

Эксперимент демонстрирует сохранение критической функциональности с KasperskyOS и падение ядра ОС на основе GNU/Linux. Отметим, что данный пример реализует защиту от конкретной уязвимости в конкретном сценарии. Для митигации других угроз следует правильно подходить к архитектуре решения и использовать различные паттерны безопасности.

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

Описание стенда и код можно посмотреть в нашем репозитории на GitFlic. Если вам интересно узнать больше о нашей операционной системе и заложенных в ней принципах безопасности, вы можете воспроизвести наш пример, установив KasperskyOS Community Edition.