Что умеет и кому нужен программный модуль доверенной загрузки
Предлагаем заглянуть под капот программного модуля доверенной загрузки ViPNet SafeBoot. Сегодня мы расскажем о его архитектуре, технических возможностях, процессе установки.
Общая информация
Важной задачей при построении любой доверенной системы является необходимость передать управление на доверенную ОС, являющуюся ядром данной системы, убедившись в ее целостности — т.е. только на то верифицированное исполняемое окружение, в рамках которого будет выполняться целевое ПО доверенной системы. Не выполнив данной задачи нельзя с полной ответственностью говорить о том, что в процессе загрузки ОС не могут быть подменены компоненты ОС, а исполняемое окружение останется доверенным.
ViPNet SafeBoot предназначен для решения следующих основных задач:
доверенная загрузка ОС с контролем целостности программной и аппаратной исполняемой среды;
ранняя аутентификация пользователей (для ограничения доступа к конфигурации доверенной загрузки, в частности).
ViPNet SafeBoot — исключительно программное средство, которое функционирует в окружении UEFI, имеет модульную структуру и встраивается в UEFI BIOS платформ, закрепляясь для старта на достаточно ранней стадии загрузки системного кода платформы.
ViPNet SafeBoot — наложенное средство защиты, это означает, что для его работы не нужно иметь специализированное исполняемое окружение (свой UEFI BIOS), а достаточно оригинального UEFI BIOS платформы (в специализированных исполнениях может требоваться доверенный UEFI BIOS платформы, но это не касается напрямую самого ViPNet SafeBoot). Отметим, что установка ViPNet SafeBoot возможна не только на этапе производства платформы, но и на различных фазах работы с целевой платформой (например, администратором в удобном для него окружении) — это интересное и важное преимущество программного МДЗ опишем подробнее ниже.
Исполняемое окружение
Изначально ViPNet SafeBoot разрабатывался для архитектуры процессоров x64 (Intel, AMD), в дальнейшем мы поддержали архитектуру процессоров aarch64/arm64 (например, Байкал-М, которые мы поддержали на нескольких типах материнских плат). Отметим, что по нашему опыту, для платформ с firmware на базе UEFI, поддержка новых процессорных архитектур в ViPNet SafeBoot (сборка, подготовка инсталлятора и прочее) не является такой уж серьезной проблемой и занимает обозримое время.
ViPNet SafeBoot может функционировать в различных средах — на реальном оборудовании, в виртуальных средах (VMware, VirtualBox, QEMU), в эмуляторах (Nt32 из состава edk2).
В качестве реального оборудования могут выступать рабочие станции, сервера, тонкие клиенты, ноутбуки, планшеты, встраиваемое оборудование. Со списком официально поддерживаемых (и неподдерживаемых тоже) платформ можно ознакомиться по ссылке. На самом деле, в реальности, список поддерживаемых платформ с firmware на базе UEFI существенно шире, так как мы добавляем в список поддерживаемых платформ только то, что проверено нами.
Кроме систем на базе нативного UEFI-окружения нами исследуется возможность работы в системах на базе coreboot (в рамках UEFI payload) и U-Boot (в рамках его UEFI-окружения).
Механизм действия
Модули ViPNet SafeBoot встраиваются в UEFI BIOS, а именно в один из исполняемых Firmware Volume (BIOS region), что обеспечивает достаточно ранний старт первой фазы исполнения на стадии DXE dispatch (вызываемой средствами системного DXE-диспетчера). Часть модулей может располагаться на диске в рабочей директории ViPNet SafeBoot на системном разделе ESP в директории EFI\Infotecs — таким образом поддерживается сценарий установки в условиях недостаточного свободного места в UEFI BIOS, когда в UEFI BIOS встраивается только базовый набор модулей, загружающий в доверенном режиме основной набор модулей с диска. Доверенная загрузка модулей с диска происходит с верификацией подписи каждого модуля и проверкой на вхождение модуля в замкнутое исполняемое окружение.
ViPNet SafeBoot функционирует на следующих фазах работы системы:
DXE dispatch — точка старта базового набора модулей, регистрация обработчиков основных фаз исполнения;
EndOfDxe — выполнение раннего функционала защиты (выставление защиты UEFI BIOS после S3, блокировка PCI Option ROM и т.д.);
ReadyToBoot — основная фаза исполнения;
ExitBootServices — завершающая фаза исполнения: включение защиты UEFI BIOS, включение эмуляции NVRAM, очистка памяти (модулей и динамической) и т.д.;
Runtime — эмуляция NVRAM;
SMM — функции самозащиты: фильтрация Software SMI, контроль целостности runtime-модулей.
Рисунок 1. Временная диаграмма загрузки UEFI-совместимых платформ
ViPNet SafeBoot использует в своей основной работе стандартные программные интерфейсы, предоставляемые окружением UEFI: сервисы системных таблиц (EFI_BOOT_SERVICES, EFI_RUNTIME_SERVICES и EFI_MM_SYSTEM_TABLE) и стандартные UEFI/SMM-протоколы. Для выполнения специальных задач, например, по блокировке функционала встроенных средств обновления BIOS, используются вендор-специфичные UEFI-протоколы (в данном случае — их перехват/блокировка).
Установка ViPNet SafeBoot
Основными задачами при установке ViPNet SafeBoot на целевую платформу являются:
встраивание модулей в UEFI BIOS;
разворачивание рабочей директории на диске;
задание стартовой конфигурации.
Предполагаются следующие сценарии установки ViPNet SafeBoot (встраивания модулей в UEFI BIOS) на целевые платформы:
программная установка (инсталлятором) — своими средствами или при взаимодействии с производителем платформы;
установка на производстве (программатором) — своими средствами или при взаимодействии с производителем платформы.
Программная установка
Как основной сценарий, мы рассматриваем именно программную установку своими средствами: таким образом обеспечивается автономность от производителя платформы (часто данный процесс имеет свойство затягиваться по времени), упрощается инструментарий установки, повышается гибкость в выборе времени установки (при отсутствии специального инструментария установки на нужной фазе установки).
На данный момент программная установка производится из окружения EFI Shell — это не только объединяет сценарии по установке и обновлению, но и исключает влияние ПО уровня ОС на протяжении данного процесса.
Сценарий программной установки довольно прост и удобен:
подключение USB-диска с инсталлятором;
запуск EFI Shell с USB-диска из BIOS Setup;
автоматический запуск инсталлятора;
выполнение инсталлятором всех операций по установке.
Вместе с тем, при программной установке своими средствами могут возникать следующие типовые проблемы:
Включенная защита UEFI BIOS на уровне аппаратных средств типа регистров чипсета BIOS_CNTL и PRx — препятствие в виде блокировки записи UEFI BIOS программными средствами.
Варианты решения:
o Отключение защиты через изменение системных NVRAM-переменных или некоторыми другими способами.
o Использование альтернативных программных средств установки.
o Взаимодействие с производителем платформы (разработчиком UEFI BIOS).
Включенная защита UEFI BIOS на уровне аппаратных средств типа Intel BootGuard (или как вариант — программного средства подобного направления) — препятствие в виде верификации UEFI BIOS при каждом старте системы.
Варианты решения:
o Поиск и встраивание модулей ViPNet SafeBoot в другой исполняемый Firmware Volume, не покрытый контролем Intel BootGuard (и аналогов).
o Взаимодействие с производителем платформы (разработчиком UEFI BIOS).
Безусловно сложнейшей задачей при установке ViPNet SafeBoot является встраивание модулей в UEFI BIOS — она включает в себя (в стандартном сценарии):
считывание образа UEFI BIOS из микросхемы SPI Flash платформы;
встраивание одного из набора модулей (в зависимости от настроек) в считанный образ UEFI BIOS;
запись модифицированного образа UEFI BIOS в микросхему SPI Flash платформы.
Для работы с микросхемами SPI Flash для платформ Intel мы используем стандартные средства, находящиеся в открытом доступе, а для платформ AMD предлагаем средства собственной разработки. Кроме того, доступна возможность использования специальных средств, специфичных для конкретных платформ (AMI AFU, flashrom и т.д.).
Для работы с образами UEFI BIOS мы используем средства собственной разработки — данные инструменты позволяют выполнять множество операций по модификации образов UEFI BIOS: добавление/удаление модулей в определенный Firmware Volume, замена секций существующих модулей, управление NVRAM-переменными и многое другое.
Для снятия риска возникновения необратимых (или трудозатратных) последствий, например, при записи поврежденного образа UEFI BIOS в микросхему SPI Flash, в инсталляторе ViPNet SafeBoot реализован специальный режим съема диагностической информации, анализ результатов которой мы готовы проводить по запросу, подтверждая возможность установки на данной платформе.
Диагностику необходимо запускать перед установкой, затем отправлять диагностическую информацию нам для анализа и ждать подтверждения возможности установки.
В инсталляторе ViPNet SafeBoot реализован механизм расширений (аналог плагинов), которые предполагается использовать при наличии каких-то специфических особенностей платформы — таким образом обеспечивается неизменность основной части инсталлятора, находящейся под контролем целостности, и упрощается (формализуется) процесс настройки инсталлятора под конкретную платформу.
Расширения инсталлятора позволяют выполнять специфические для данной платформы действия на разных фазах установки и решать следующие задачи:
управление средствами защиты UEFI BIOS перед установкой (сценарий снятия защиты UEFI BIOS);
задание образа UEFI BIOS, отличного от текущего (сценарий обновления версии UEFI BIOS);
управление встраиванием модулей в UEFI BIOS (сценарий недостаточного свободного места в UEFI BIOS);
задание сторонних средств работы с микросхемами SPI Flash (сценарий отсутствия поддержки работы с микросхемой SPI Flash стандартными средствами инсталлятора);
многое другое.
Например, при определенной комбинации стандартных расширений инсталлятора можно собрать расширение, которое позволит в автоматическом режиме (запускаемом из настроек ViPNet SafeBoot) обновить версию UEFI BIOS с сохранением установленного ViPNet SafeBoot и его данных.
Установка на производстве
При установке на производстве, конечно, не исключается и программный сценарий установки (описанный выше), но все же основным сценарием является установка либо с помощью аппаратного программатора, либо с помощью специальных программных средств — для обеспечения массового производства платформ со встроенным ViPNet SafeBoot в UEFI BIOS.
Взаимодействие с производителями платформ (разработчиком UEFI BIOS)
На данный момент налажено взаимодействие (включающее в себя встраивание модулей ViPNet SafeBoot и подпись полученного образа UEFI BIOS или установку ViPNet SafeBoot на этапе производства платформ) со следующими производителями платформ:
отечественные производители: Аквариус, Depo, iRU, ICL, РАМЕК-ВС;
зарубежные производители: Lenovo, ASUS
Режим неактивности
В ViPNet SafeBoot поддерживается сценарий установки в неактивном режиме. Это серьезное преимущество, и оно может быть интересно в случае, когда производитель платформ захочет выпускать или устанавливать единый образ UEFI BIOS на большую партию платформ, а включать ViPNet SafeBoot будет администратор на необходимом ему подмножестве платформ этой партии. Таким образом, процесс взаимодействия с производителями платформ может сильно упроститься, а объем их работ и издержки значительно уменьшатся.
Функции ViPNet SafeBoot
Проведем обзор с точечным, более детальным описанием основных функций и возможностей ViPNet SafeBoot.
Хранение журнала и БД
Важнейшей задачей при разработке ViPNet SafeBoot является обеспечение доверенного хранения его данных — в первую очередь, журнала событий и БД (настроек). По историческим причинам они хранятся в независимых и отдельных структурных единицах.
Поддерживаются 2 основных режима хранения:
Внутренний режим хранения
Внутреннее хранение данных позволяет уйти от зависимости от внешних хранилищ (дисков) — что обеспечивает, в частности, возможность поддерживать сценарий работы на бездисковых рабочих станциях, и в перспективе реализовать полноценный Zero Client на произвольном оборудовании.
При использовании внутреннего режима хранения данные сохраняются в индексированном списке NVRAM-переменных, оформленном в специальном формате для предотвращения проблем при разрыве списка в случае прерывания по сбросу питания и т.д.
Для предотвращения стороннего доступа к внутренним хранилищам данных используется целый ряд мер, подробнее описанных ниже — от эмуляции NVRAM, до защиты UEFI BIOS (на чтение и запись).
Основным минусом и ограничением внутреннего режима хранения данных является относительно небольшой объем свободного пространства в NVRAM — на современных системах это около 100 Кб, чего, например, явно недостаточно для хранения полных списков контроля целостности компонентов системы. Для закрытия этого ограничения мы ведем исследование по возможности организации автономного от NVRAM внутреннего хранилища и уже есть определенные практические результаты в этом направлении.
Внешний режим хранения
При использовании внешнего режима хранения все данные хранятся в виде файлов в рабочей директории, в формате, предотвращающем сторонний доступ к ним:
в зашифрованном виде (журнал, БД) — для предотвращения чтения данных;
в подписанном виде (журнал, БД, списки эталонов КЦ) — для предотвращения модификации данных (преднамеренной и непреднамеренной);
в привязанном к внутренней БД виде (журнал, БД, списки эталонов КЦ) — для предотвращения атак отката.
Во внутреннем хранилище в данном режиме хранится лишь базовая конфигурация — например, ключи контроля целостности внешних данных.
Доверенная загрузка ОС
Ключевой задачей ViPNet SafeBoot является организация доверенной загрузки ОС.
Поддерживаются следующие типы доверенной загрузки ОС:
legacy ОС;
UEFI ОС;
по сети (UEFI).
Для ViPNet SafeBoot нет явных ограничений по поддержке локально загружаемых ОС — единственным препятствием может служить только использование в ОС разделов с неподдерживаемыми типами ФС (для контроля целостности их содержимого).
Организация доверенной загрузки ОС в ViPNet SafeBoot серьезно отличается от стандарта де-факто Secure Boot и основывается на следующих принципах:
контроль целостности заданных файлов ОС (цепочки загрузки ОС);
явная передача управления на заданный загрузчик ОС (или загрузочное устройство в случае legacy ОС).
Контроль целостности заданных файлов ОС
Перед передачей управления на загрузчик ОС необходимо верифицировать его целостность и целостность цепочки загрузки ОС (т.е. других исполняемых и конфигурационных файлов ОС, следуемых и используемых в процессе загрузки за загрузчиком ОС).
Для этого необходимо поставить на контроль целостности всю цепочку загрузки ОС. Для распространенных дистрибутивов версий ОС Windows и Linux реализован автоматический режим, но есть и возможность ручной конфигурации в настройках контроля целостности ViPNet SafeBoot.
Передача управления на заданный загрузчик ОС
Для передачи управления на заданный загрузчик ОС (или загрузочное устройство в случае legacy ОС) необходимо указать его в настройках загрузки ViPNet SafeBoot, предварительно выбрав тип загрузки.
Передача управления на заданный загрузчик ОС происходит средствами самого ViPNet SafeBoot — с использованием сервисов LoadImage/StartImage системной таблицы EFI_BOOT_SERVICES, т.е. без передачи управления UEFI Boot Manager и манипуляции его параметрами (BootOrder и т.д.). Таким образом упрощается контроль за управлением загрузкой ОС.
Загрузка ОС по сети
Поддерживаются сценарии загрузки UEFI ОС по сети по протоколам PXE и HttpBoot.
При этом на данный момент есть возможность контроля адреса сервера PXE/HttpBoot и контроля целостности загрузчика ОС.
Контроль целостности
Контролируемые компоненты
Для обеспечения контроля исполняемой среды поддерживается контроль целостности следующих программных и аппаратных компонентов системы:
файлов на диске (на разделах с ФС FAT*, NTFS, ext2/¾);
реестра Windows (на уровне ключей/значений);
CMOS (на уровне регистров);
конфигурационных пространств PCI;
таблиц ACPI;
структур SMBIOS (DMI);
карты распределения памяти;
модулей UEFI BIOS;
загрузочных секторов диска (загрузочного);
переменных NVRAM (с релиза 3.1);
системных таблиц UEFI (с релиза 3.1).
Для каждого компонента ведется свой список элементов (хранимый либо в файле на диске, либо во внутреннем хранилище NVRAM), контролируемых отдельно. Например, элементами компонента «Файлы» будут конкретные файлы (с указанием их путей), а элементами компонента «Модули UEFI BIOS» — как это ни странно :) , модули UEFI BIOS (с указанием их в формате
Схема контроля целостности
Для каждого компонента применяется следующая схема контроля целостности («схема каталогов»):
по каждому контролируемому элементу компонента рассчитывается хэш — так называемый эталонный хэш;
формируется список в текстовом виде, каждая строка которого идентифицирует контролируемый элемент с его эталонными хэшем в виде:
; список сохраняется в файле в рабочей директории или в БД;
при сохранении в файле — список подписывается на ключе защиты данных, подпись сохраняется в открепленном виде рядом с файлом списка;
o ключ защиты данных хранится в БД в защищенном виде и его можно изменить из настроек ViPNet SafeBoot;
Данная схема обеспечивает целостность и аутентичность (т.е. невозможность модификации злоумышленником без знания закрытого ключа подписи) контролируемых данных, исключает необходимость в подписи каждого элемента отдельно (т.е. ускоряет процесс контроля целостности) и применяется при контроле целостности программных и аппаратных компонентов системы, запросов удаленного управления, а также пакетов обновлений.
Криптографический базис
В качестве криптографических алгоритмов используются алгоритмы семейства ГОСТ:
ГОСТ 34.10–2018 — для подписи и верификации подписи;
ГОСТ 34.11–2018 — для расчета хэша и HMAC;
ГОСТ 34.12–2018/ГОСТ 34.13–2018 — для шифрования и расчета имитовставки.
В качестве криптографической библиотеки в ViPNet SafeBoot используется криптографическое ядро, разрабатываемое в ИнфоТеКС, и являющееся криптографическим базисом многих других продуктов ИнфоТеКС. Кроме того, для поддержки работы с сертификатами и других подсистем применяется OpenSSL с нашим engine, использующим данное криптографическое ядро.
Аутентификация
Другой важной задачей ViPNet SafeBoot является аутентификация пользователей (разграничение доступа). Аутентификация позволяет заблокировать доступ сторонних пользователей к системе (в частности, к загрузке ОС), а также ограничить возможности по управлению настройками ViPNet SafeBoot со стороны низкопривилегированных пользователей.
В ViPNet SafeBoot используется следующая ролевая модель:
администратор — имеет все права на изменение настроек;
аудитор — имеет права на чтение и экспорт журнала и на изменение своего пароля (пролонгации его срока действия);
пользователь — имеет права только на изменение своего пароля (пролонгации его срока действия).
Одновременно может быть заведено до 32 пользователей всех типов (всего).
Кроме того, может быть задано расписание доступа (графика работы) пользователей — для более гибкого управления аутентификацией пользователей.
Поддерживаются следующие типы аутентификации:
по паролю — с верификацией введенного пароля по хэшу от пароля с солью, сохраненным в БД;
по сертификату на смарт-карте/токене — на основе протокола аутентификации, описанного ниже;
по паролю и по сертификату на смарт-карте/токене — комбинированный режим с последовательным запуском процедуры аутентификации по паролю, а затем по сертификату на смарт-карте/токене;
по паролю на смарт-карте/токене — с верификацией пароля, сохраненного в специальном закрытом файле смарт-карты/токена, по хэшу от пароля с солью, сохраненным в БД;
по LDAP — на основе bind на удаленный LDAP-сервер (Microsoft AD, Astra ALD Pro), с поддержкой ограничения списка разрешенных к аутентификации пользователей через задание белого списка пользователей.
Поддерживаются следующие смарт-карты/токены: Рутокен ЭЦП 2, Рутокен Lite, Рутокен S, JaCarta-2 ГОСТ, JaCarta PKI, JaCarta LT, Guardant ID (и некоторые другие). Драйвера смарт-карт/токенов разрабатываются самостоятельно.
Аутентификация по сертификату на смарт-карте/токене
Аутентификация по сертификату на смарт-карте/токене требует предварительной подготовки смарт-карты/токена со стороны администратора средствами либо ViPNet CSP, либо вендор-специфичного ПО, а именно:
генерации закрытого ключа (неизвлекаемого или в формате программного контейнера закрытого ключа ViPNet CSP) на смарт-карте/токене;
выпуска и сохранения на смарт-карте/токене сертификата пользователя.
Важным требованием при аутентификации по сертификату на смарт-карте/токене является обеспечение невозможности дупликации смарт-карты/токена — полноценно это доступно на смарт-картах/токенах с неизвлекаемыми ключами, на других смарт-картах/токенах это доступно частично (с ограничением знания PIN злоумышленником).
Протокол аутентификации на смарт-карте/токене с неизвлекаемым ключом выглядит следующим образом (см. рис. 2):
запрашивается ввод PIN смарт-карты/токена (для доступа к ключу);
производится аутентификация на смарт-карте/токене по введенному PIN;
на ПДСЧ (программном датчике случайных чисел) генерируется вектор определенной длины;
вектор аппаратно подписывается на неизвлекаемом ключе смарт-карты/токена;
подпись вектора программно верифицируется на сертификате пользователя (сохраненном как на смарт-карте/токене, так и в БД);
при успешном результате верификации можно говорить о том, что смарт-карта/токен соответствует сертификату пользователя и является аутентичной/аутентичным;
o при этом за счет программной верификации подписи исключается возможность подмены/эмуляции аппаратной составляющей (смарт-карты/токена), которая могла бы фиктивно верифицировать подпись аппаратным способом;
происходит верификация цепочки сертификатов (от сертификата пользователя до корневого сертификата) — этим самым проверяется существование всей цепочки сертификатов, сроков действия всех сертификатов в цепочке, а также отсутствие сертификата пользователя в списке отзыва (CRL).
Рисунок 2. Диаграмма аутентификации по сертификату на смарт-карте/токене
Аутентификация в режиме Single Sign-On
Для удобства прохождения множественной аутентификации (в ViPNet SafeBoot, в ОС/СЗИ) реализована поддержка механизма Single Sign-On со сквозной аутентификацией пользователя в ОС/СЗИ. Для аутентификации в режиме Single Sign-On на стороне ОС требуется установка провайдера аутентификации, реализованного на данный момент для ОС Windows и Linux. Кроме того, поддержка аутентификации в режиме Single Sign-On реализована в СЗИ ViPNet SafePoint.
Аутентификационная информация пользователя передается в защищенном виде через эмулятор NVRAM (через память) и имеет минимальное время жизни.
Средства защиты и самозащиты
Средства защиты и самозащиты являются с некоторой точки зрения вспомогательными компонентами, но в то же время без которых о безопасности ViPNet SafeBoot говорить можно было бы лишь условно. Они позволяют противостоять атакам по подмене настроек (конфигурации доверенной загрузки ОС, в частности) и по удалению/отключению ViPNet SafeBoot — в первую очередь с уровня ОС, т.е. со стороны произвольного, даже высокоприоритетного, пользователя ОС.
Далее будут рассмотрены конкретные средства защиты и самозащиты, реализованные в ViPNet SafeBoot.
Защита UEFI BIOS
Для предотвращения возможности перезаписи UEFI BIOS (как в сценарии целенаправленной атаки, так и в сценарии легального обновления UEFI BIOS со стороны ОС, которое просто «удалит» установленный ViPNet SafeBoot) применяется следующий подход:
Intel: на весь BIOS region микросхемы SPI Flash устанавливается защита регионов SPI Flash на уровне регистров чипсета PRx (защита уровня PRx является предпочтительнее защиты уровня BIOS_CNTL, т.к. опирается только на аппаратную составляющую, т.е. имеет большую защищенность — например, в случае совершения атак на SMM);
AMD: блокируются SPI-команды записи и стирания микросхемы SPI Flash (с реализацией части кода на уровне SMM, ввиду специфики AMD);
Байкал-М: на уровне ARM TF (части firmware вне UEFI) реализуется перехват сервисов SMC записи в микросхему SPI Flash.
После включения данная защита обеспечивает невозможность ее отключения до последующей перезагрузки системы (аппаратными средствами для Intel и AMD), которая в свою очередь находится под контролем ViPNet SafeBoot — при последующей загрузке системы защита будет вновь активирована.
Нельзя не обратить внимание на восстановление параметров защиты после выхода из режима сна (S3) — ввиду специфики современных платформ Intel/AMD, на которых после S3 происходит «укороченная» переинициализация конфигурации системы (и регистров чипсета, в частности), ViPNet SafeBoot поддерживает задание параметров защиты в сценариях выхода из S3.
Поскольку со стороны ОС могут быть легальные запросы на чтение-запись NVRAM-переменных, а NVRAM находится в защищаемом регионе UEFI BIOS, при включенной защите UEFI BIOS предполагается дополнительно включать эмуляцию NVRAM (описана ниже).
Эмуляция NVRAM
Эмуляция NVRAM решает сразу несколько задач:
предотвращение доступа к NVRAM-переменным ViPNet SafeBoot;
поддержка легальных запросов на чтение-запись NVRAM-переменных со стороны ОС в случае включенной защиты UEFI BIOS на чтение-запись;
предотвращение атак на реализацию NVRAM со стороны ОС.
При включенной эмуляций NVRAM происходит дупликация содержимого NVRAM в эмулируемый пул памяти и перехватываются сервисы системной таблицы EFI_RUNTIME_SERVICES, отвечающие за работу с NVRAM-переменными, с перенаправлением на эмулятор NVRAM.
Следует отметить, что даже при отключенном режиме эмуляции NVRAM происходит блокировка (фильтрация) доступа к NVRAM-переменным ViPNet SafeBoot для стороннего кода (с уровня ОС).
Контроль (фильтрация) Software SMI
Для предотвращения обновления UEFI BIOS с помощью вендор-специфичных средств (например, AMI AFU), функционирующих по протоколу на уровне SMI (с взаимодействием с SMM-кодом) в отличие от прямой работы с SPI-контроллером, реализован контроль (фильтрация) Software SMI с реализацией своего фильтра на уровне SMM с блокировкой явно опасных SMI, используемых в протоколе взаимодействия. База правил, блокируемых SMI, может дополнительно расширяться/уточняться при установке/обновлении ViPNet SafeBoot.
Блокировка встроенных средств обновления UEFI BIOS
Для предотвращения обновления UEFI BIOS со стороны специальных вендор-специфичных режимов уровня UEFI реализована защита, основанная на перехвате сервисов UEFI-протоколов обновления с последующей блокировкой их выполнения.
Поддерживается блокировка UEFI-протоколов обновления UEFI BIOS от основных производителей платформ (OEM). Реализована формализованная система правил описания перехватываемых UEFI-протоколов для расширения и сопровождения списка.
Контроль runtime-кода
Для контроля неизменности runtime-кода ViPNet SafeBoot (и SMM включительно) реализована защита, функционирующая на уровне SMM, выполняющая периодическую верификацию целостности кода на основе эталонных хэшей модулей и блокирующая доступ к системе в случае нарушения их целостности.
Блокировка входа в специальные режимы настроек
Для предотвращения доступа в специальные режимы настроек, например, в BIOS Setup, реализована блокировка (фильтрация) явно опасных комбинаций клавиш на ранней стадии загрузки системы. База блокируемых комбинаций клавиш может дополнительно расширяться/уточняться администратором (при нашей поддержке) при установке/обновлении ViPNet SafeBoot.
Средства защиты от malware
В последнее время очень активно развиваются инструменты для атаки на системы со встраиванием компонентов malware в firmware на базе UEFI. Причем встраивание malware может проходить как на достаточно длительном цикле цепочки поставок, так и в процессе эксплуатации систем.
Большинство malware уровня UEFI BIOS позволяет автоматически заражать ОС даже после ее переустановки (либо в файловом, либо в бесфайловом режимах). Собственно, для этой цели, а также для обеспечения более раннего старта, malware и встраивается в UEFI BIOS. Основные вектора атак, используемые UEFI malware, указаны на рис. 3.
Рисунок 3. Основные вектора атак UEFI malware
Средства защиты от malware в ViPNet SafeBoot отвечают в первую очередь за блокировку (полную изоляцию) основного функционала уже находящегося в UEFI BIOS вредоносного (или потенциально вредоносного) кода, например, в условиях, когда ViPNet SafeBoot устанавливается в уже зараженный (или потенциально зараженный) UEFI BIOS. В случае установленного ViPNet SafeBoot встраивание malware в UEFI BIOS будет блокироваться средствами защиты UEFI BIOS ViPNet SafeBoot.
Далее будут рассмотрены конкретные средства защиты от malware, реализованные в ViPNet SafeBoot.
Блокировка ACPI WPBT
Для предотвращения записи потенциально вредоносных исполняемых файлов в системные разделы ОС и их запуска со стороны ОС, реализована блокировка механизма специальных ACPI-таблиц WPBT.
Примеры блокируемых malware: Absolute Software Computrace/LoJack.
Защита дисков от записи
Для предотвращения записи потенциально вредоносных исполняемых и конфигурационных файлов в системные разделы ОС, реализован механизм блокировки записи на диск в файловом и блочном/секторном режимах. Механизм основан на перехвате системных UEFI-протоколов SimpleFileSystem, BlockIo, DiskIo с последующим контролем вызывающего кода.
При включении данного механизма возможность доступа к диску на запись будет только у компонентов ViPNet SafeBoot.
Примеры блокируемых malware: Hacking Team«s UEFI Rootkit, Absolute Software Computrace/LoJack, LoJax, MosaicRegressor.
Защита системных таблиц UEFI
Для предотвращения перехвата сервисов системных таблиц UEFI EFI_BOOT_SERVICES и EFI_RUNTIME_SERVICES реализован механизм виртуализации/локализации системных таблиц UEFI для каждого исполняемого модуля, что приводит при перехвате сервисов к модификации только локальной копии системной таблицы вредоносного (или потенциально вредоносного) модуля — при этом системные таблицы, используемые непосредственно в процессе загрузки ОС, остаются неизменными.
Примеры блокируемых malware: EfiGuard, CosmicStrand.
Блокировка загрузки PCI Option ROM
Для предотвращения запуска потенциально вредоносного кода с подключаемых PCI-устройств из исполняемых PCI Option ROM реализован механизм перехвата и блокировки старта исполняемого кода из PCI Option ROM посредством затирания его памяти.
Таким образом, вследствие достаточно раннего старта ViPNet SafeBoot имеется возможность блокировать даже функционал АПМДЗ (примеры приводить не станем J).
Удаленное управление
Для удобной эксплуатации ViPNet SafeBoot, реализован механизм удаленного управления.
В качестве ПО, реализующего функции удаленного управления на стороне ОС, может выступать ViPNet SafeBoot MC или ViPNet EPP. Данное ПО имеет клиент-серверную структуру с возможностью управления агентами (клиентами), функционирующими на ОС Windows и Linux основных версий и дистрибутивов.
Механизм удаленного управления позволяет считывать журналы событий, изменять настройки, а также обновлять версии ViPNet SafeBoot на всем парке управляемых машин.
Механизм удаленного управления функционирует следующим образом (см. рис. 4):
ViPNet SafeBoot передает журнал и БД в канал удаленного управления (на стороне UEFI);
после загрузки ОС ПО удаленного управления получает доступ к журналу и БД из канала удаленного управления (на стороне ОС);
при необходимости изменения настроек ViPNet SafeBoot (на стороне ОС):
o ПО удаленного управления вносит соответствующие изменения настроек в полученную БД;
o ПО удаленного управления формирует так называемый запрос удаленного управления на основе измененной БД и передает его в канал удаленного управления;
o ViPNet SafeBoot верифицирует запрос удаленного управления;
o ViPNet SafeBoot вносит изменения в настройках в БД;
o при наличии в запросе удаленного управления обновления ViPNet SafeBoot — запускает процесс обновления.
Рисунок 4. Диаграмма сеанса удаленного управления (УУ)
Каналом удаленного управления является файловый механизм хранения данных в рабочей директории. Т.е. все исходные и измененные данные, а также служебные структуры, реализующие, в частности, их контроль целостности, представляются в виде файлов — все это вместе и называется запросом удаленного управления. Для ограничения доступа со стороны сторонних пользователей, журнал и БД в канале удаленного управления передаются в зашифрованном виде.
Для подтверждения (аутентификации) запросов удаленного управления применяется механизм подписи всех данных, входящих в запрос. Подпись производится на ключе, сертификат от которого задается в настройках ViPNet SafeBoot. Таким образом обеспечивается защита от формирования или модификации запросов удаленного управления со стороны злоумышленника. Кроме того, реализован механизм защиты от атак повтора, основанный на нал
