Эксплуатация подписанных загрузчиков для обхода защиты UEFI Secure Boot / Хабр

Отдельные почтовые клиенты с российской криптографией

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

Что могут предложить флешки в плане защиты?

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

Второй вариант — навесная программная защита для обычной флешки.

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

В чем же слабость — спросите вы.

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

А если пароль короткий и простой, то подобрать его по словарю будет не таким уж и сложным делом.

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

Поэтому, если вы не враг самому себе, то пароль должен быть «стойким». Но поскольку вам же потом этот же «стойкий» пароль придется многократно набирать — это начинает противоречить утверждению на предыдущей строке.

Что же делать — спросите вы.

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

Оказывается, да, можно, если вы российский производитель устройств электронной подписи (токенов и смарт-карт).

Введение

Внедрение электронной подписи (без разделения на используемые криптоалгоритмы и критерий «квалифицированности», см. закон

, ст. 5) в информационную систему обычно вызвано необходимостью контроля целостности и авторства порождаемых в системе информационных потоков и документов.

Под катом описаны интерфейсы для работы с электронной подписью, а также распространенные форматы электронной подписи.

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

Электронная подпись реализуется на основе асимметричной криптографии, или криптографии с открытым ключом. Асимметричные криптографические алгоритмы предполагают использование пары ключей: открытого и закрытого. Закрытый ключ служит для выработки электронной подписи, открытый – для ее проверки.

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

Для выдачи, проверки действительности, отзыва и управления сертификатами необходима инфраструктура открытых ключей (Public Key Infrastructure). Вопрос сопоставления открытого ключа и его владельца – один из самых важных и сложных при работе с асимметричной криптографией, так как открытый ключ – это никак не идентифицируемый набор публичной информации, которая служит для проверки электронной подписи.

Grub2

Чтобы злоумышленники втихую не наделали делов с помощью подписанного загрузчика какого-либо дистрибутива, Red Hat сделал патчи для GRUB2, блокирующие «опасные» функции при включенном Secure Boot: insmod/rmmod, appleloader, linux (заменён linuxefi), multiboot, xnu, memrw, iorw.

К модулю chainloader, загружающему произвольные .efi-файлы, дописали собственный загрузчик .efi (PE), без использования команд UEFI LoadImage/StartImage, а также код валидации загружаемых файлов через shim, чтобы сохранялась возможность загрузки файлов, доверенных для shim, но не доверенных с точки зрения UEFI.

, но по умолчанию отключена.

Так или иначе, воспользоваться подписанным GRUB из какого-то дистрибутива Linux не получится. Для создания универсальной загрузочной флешки, которая бы не требовала добавление ключей каждого загружаемого файла в доверенные, есть два пути:

Второй вариант предпочтительней — загруженные недоверенные программы тоже смогут загружать недоверенные программы (например, можно загружать файлы через UEFI Shell), а в первом варианте загружать всё может только сам GRUB.

, убрав из него лишний код и разрешив запуск любых файлов.

Итого, архитектура флешки получилась следующая:

   ______            ______                ______
  ╱│     │          ╱│     │              ╱│     │
 /_│     │    →    /_│     │      →      /_│     │
 │       │    →    │       │      →      │       │
 │  EFI  │    →    │  EFI  │      →      │  EFI  │
 │_______│         │_______│             │_______│

BOOTX64.efi        grubx64.efi        grubx64_real.efi

  (shim)      (FileAuthentication         (GRUB2)
                override)

    ↓↓↓                ↑
                       ↑
   ______              ↑
  ╱│     │             ║
 /_│     │             ║
 │       │  ═══════════╝
 │  EFI  │
 │_______│

MokManager.efi

(Key enrolling
 tool)

Так появился Super UEFIinSecureBoot Disk.

Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.

Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.

Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2.

Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный .efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.

Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.

Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.

Microsoft crypto api 2.0

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

С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.

Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов. Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса.

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

Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.

В Windows Vista Microsoft представила новую версию криптографического программного интерфейса – Microsoft CNG (Cryptography API: Next Generation). Данный интерфейс базируется уже не на поставщиках криптографии, а на поставщиках алгоритмов и поставщиках хранилищ ключевой информации.

Pkcs#11

PKCS#11 (Public-Key Cryptography Standard #11) – платформонезависимый программный интерфейс для работы с аппаратно реализованными СКЗИ: смарт-карты, HSM’ы, криптографические токены. Иногда PKCS#11 используется для доступа к программно реализованным криптографическим библиотекам.

PKCS#11 представляет собой довольно обширный документ, опубликованный RSA Laboratories, который описывает набор функций, механизмов, алгоритмов и их параметров для работы с криптографическими устройствами или библиотеками. В данном документе четко прописаны правила, в соответствии с которым будет работать прикладное программное обеспечение при вызове криптографических функций.

Данный стандарт поддерживается во многих open source-проектах, использующих криптографию. Для примера, Mozilla Firefox позволяет хранить сертификаты и закрытые ключи для аутентификации через SSL/TLS на токенах, работая с ними по PKCS#11.

Если прикладное программное обеспечение «умеет» работать с PKCS#11, то производителю СКЗИ необходимо реализовать программную библиотеку, которая наружу будет выставлять интерфейсы, описанные в стандарте, а внутри реализовывать необходимую СКЗИ логику: работа непосредственно с криптографическим устройством или реализация необходимых криптоалгоритмов программно.

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

Единственным существенным минусом PKCS#11 является отсутствие рекомендаций по работе с сертификатами открытого ключа, что предполагает либо использование проприетарных расширений стандарта, либо использование других средств для работы с сертификатами.

Pkcs#7

PKCS#7 (Public-Key Cryptography Standard #7), или CMS (Cryptographic Message Syntax) – стандарт, публикуемый и поддерживаемый все той же RSA Laboratories, описываемый синтаксис криптографических сообщений.

PKCS#7 также публикуется в качестве RFC с номером 2315.

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

С этой целью в PKCS#7 размещается информация об исходном сообщении (опционально), алгоритмах хеширования и подписи, параметрах криптоалгоритмов, времени подписи, сертификат ключа электронной подписи, цепочка сертификации и т. д.

Большинство атрибутов PKCS#7 являются опциональными, но их обязательность может определяться прикладной системой.

Отдельно следует отметить, что PKCS#7 позволяет ставить несколько подписей под одним документом, сохраняя всю необходимую информацию в сообщении.

Формирование и проверка PKCS#7 реализованы в криптографических «надстройках» в Microsoft Crypto API, речь о которых шла выше. Но сам формат довольно хорошо специализирован и его поддержка может быть реализована нативно.

Безопасная флешка все-таки существует

В устройствах Рутокен ЭЦП 2.0 Flash флеш-память подключена через специальный защищенный контроллер, прошивка которого, карточная операционная система Рутокен, целиком и полностью разработана специалистами компании «Актив» (карточная ОС Рутокен находится в реестре отечественного ПО Минкомсвязи).

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

А так как в карточной операционной системе Рутокен испокон веков есть функциональность, обеспечивающая доступ к криптографическим ключам электронной подписи по PIN-кодам, мы реализовали в ней своего рода «вентиль», который может быть открыт, закрыт или открыт в одностороннем режиме (например, только для чтения). Вентиль этот как раз и управляется PIN-кодом. Не зная его, этот вентиль невозможно повернуть.

Теперь представьте, что такой вентиль по умолчанию находится в положении «закрыт». А чтобы открыть его, нужно предъявить PIN-код, который знаете только вы. Причем, вентиль автоматически закрывается при извлечении устройства из компьютера. И количество попыток ввода неправильного PIN-кода жестко ограничено. Причем, устройство защищено от физического взлома и извлечения флеш-карты.

Получается вполне безопасная, надежная и удобная система. Мы реализовали ее в виде небольшой управляющей программы, которая называется — «Рутокен Диск».

Флеш-память устройства Рутокен ЭЦП 2.0, на котором работает «Рутокен Диск», разбита на 2 области: одна служебная, для эмулирующего CD-ROM раздела с управляющей программой; вторая — для пользовательских данных.

При подключении такого устройства к компьютеру вы увидите два физических диска. CD-ROM раздел сразу доступен для чтения и автоматически монтируется, а в операционных системах Windows еще и всплывает симпатичное окошко.

Защищенный раздел выглядит как ридер карт памяти, но без вставленной в него карты, доступа к данным нет.

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

Сам токен уже много лет продаётся и возможность реализации защищённой флешки в нем была изначально. На токен для организации безопасного доступа загружено приложение Рутокен. Диск.

Встраивание электронной подписи в прикладные системы

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

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

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

В «западном» мире широко используется сертификация решений на соответствие Common Criteria, в России процесс сертификации средств криптографической защиты проводит ФСБ России.

Дополнительно, средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительных специализированных железок (Hardware Security Module, HSM).

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

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

Можно ли использовать программу cybersafe?

Одно дело — шифрование личных файлов, но государственный и банковский сектор — совсем другое. Какие нормы позволяют считать CyberSafe программой, использующей сертифицированное ФСБ России СКЗИ и не требующей соответствующей сертификации? Ответ на этот вопрос можно получить в паспорте (формуляре) на программный продукт КриптоПро CSP и в методических рекомендациях по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации. Последние утверждены ФСБ России 21 февраля 2008 года № 149/54-144.

В паспорте на КриптоПро CSP читаем п. 1 из раздела 2:

Допускается использование СКЗИ для криптографической защиты персональных данных

Далее открываем методические рекомендации и читаем пункт 1 из раздела 5:

5.1. Встраивание криптосредств класса КС1 и КС2 осуществляется без контроля со стороны ФСБ России (если этот контроль не предусмотрен техническим заданием на разработку (модернизацию) информационной системы).

На базе nss

На картинке представлена архитектура решения, реализованная в проекте по расширению NSS aToken.

Проблемы:

Плюсы:

Подписанные загрузчики

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

Как оказалось — такие загрузчики есть. Один из них используется в

— загрузочном диске с антивирусным ПО. GRUB с диска позволяет загружать модули (команда insmod), а модули в GRUB — обычный исполняемый код. Пред-загрузчик у диска собственный.

Разумеется, просто так GRUB из диска не загрузит недоверенный код. Необходимо модифицировать модуль chainloader, чтобы GRUB не использовал функции UEFI LoadImage/StartImage, а самостоятельно загружал .efi-файл в память, выполнял релокацию, находил точку входа и переходил по ней.

К счастью, почти весь необходимый код есть в репозитории GRUB’а с поддержкой Secure Boot от Red Hat, единственная проблема: код парсинга заголовка PE отсутствует, заголовок парсит и возвращает shim, в ответ на вызов функции через специальный протокол. Это легко исправить, портировав соответствующий код из shim или PreLoader в GRUB.

Так появился Silent UEFIinSecureBoot Disk. Получившаяся архитектура диска выглядит следующим образом:

   ______            ______                ______
  ╱│     │          ╱│     │              ╱│     │
 /_│     │         /_│     │      →      /_│     │
 │       │         │       │      →      │       │
 │  EFI  │         │  EFI  │      →      │  EFI  │
 │_______│         │_______│             │_______│

BOOTX64.efi        grubx64.efi        grubx64_real.efi

(Kaspersky     (FileAuthentication         (GRUB2)
  Loader)        override)

    ↓↓↓                ↑
                       ↑
   ______              ↑
  ╱│     │             ║
 /_│     │             ║
 │       │  ═══════════╝
 │  EFI  │
 │_______│

 fde_ld.efi   custom chain.mod

(Kaspersky GRUB2)

Подписанные загрузчики загрузчиков

Итак, чтобы загрузить Linux при включенном Secure Boot, нужен подписанный загрузчик. Microsoft запретила подписывать ПО, лицензированное под GPLv3, из-за запрета

тивоизации

правилами лицензии, поэтому

В ответ на это, Linux Foundation выпустили

, а Мэтью Гарретт написал

— маленькие начальные загрузчики, проверяющие подпись или хеш следующего загружаемого файла. PreLoader и shim не используют сертификаты

UEFI db

, а содержат базу разрешенных хешей (PreLoader) или сертификатов (shim) внутри себя.

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

Действия, необходимые при первом запуске недоверенной программы через shim.

Все современные популярные дистрибутивы Linux используют shim, из-за поддержки сертификатов, которая позволяет легко обновлять следующий загрузчик без необходимости взаимодействия с пользователем. Как правило, shim используется для запуска GRUB2 — наиболее популярного бутлоадера в Linux.

Расширения классов

В платформе существует набор криптографических классов, в которых предусмотрены механизмы расширения сторонними алгоритмами. Наиболее известным на рынке решением по расширению платформы Microsoft.NET российскими криптоалгоритмами является продукт КриптоПро. NET, представляющий собой надстройку над КриптоПро CSP.

Установка КриптоПро.NET позволяет использовать российские криптоалгоритмы, например,

в WEB-сервисах на базе ASP.NET, SOAP-сервисах, в клиентских браузерных приложениях MS.Silverlight.

Средства формирования доверенной среды

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

На последнем способе формирования ДС хотелось бы остановиться подробнее.

Компанией «Код безопасности» предложен интересный продукт Jinn, который позволяет эмулировать доверенную среду как на многоядерном, так и на одноядерном компьютере. Основной идеей данного решения является то, что доверенная среда выполняется на логических ядрах, на которых не выполняется сама клиентская ОС.

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

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

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

Электронная цифровая подпись для чайников: с чем ее есть и как не подавиться. часть 3

Заключение

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

С помощью подписанных файлов Kaspersky Rescue Disk мы добились «тихой» загрузки любых недоверенных .efi-файлов при включенном Secure Boot, без необходимости добавления сертификата в UEFI db или shim MOK.

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

Предполагаю, что сертификат Касперского долго не проживет, и его добавят в

, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.