на винфак

Никогда такой хернёй не занимался, но подозреваю, что сам загрузчик проверяет сертификат на подлинность (читай — принадлежность Microsoft) и заворачивает загрузку, патамушта ты перат (ну не может же лицензионна Windows быть подписана каким-то левым ключом, правда?)!

Так что да, поддерживаю оратора выше.

Напиши как делал.

Создал свою подпись

Подписал ею загрузчик

Добавил свой публичный ключ в UEFI, а остальные ключи удалил.

сам загрузчик проверяет сертификат на подлинность (читай — принадлежность Microsoft) и заворачивает загрузку

Не думаю, что они до этого догадались. Надо проверить…

Если да, то у нас проблемы с безопасностью в дуалбуте с вантузом. Наличие серта M$ разрешает обладателям его приватной части внедрять буткиты в Linux.

Не думаю, что они до этого догадались.

Ну не с целью выявления пиратства, а просто на всякий случай. Microsoft и не такое может.

Если да, то у нас проблемы с безопасностью в дуалбуте с вантузом.

Проблемы мышей кота не волнуют. ☺

Наличие серта M$ разрешает обладателям его приватной части внедрять буткиты в Linux.

Ваще пофиг:

 % uname -srm
FreeBSD 12.1-RELEASE-p5 amd64

Никаких дуалбутов ни в Linux, ни в Windows, ничего из этого не стоит на реальном железе, да и в виртуалках запускается нечасто.

Никаких дуалбутов

Он хочет дуалбут. К стати не важно с чем. Если есть сертификат вантуза, то буткиты можно внедрить в любую ось которая стоит в дуалбуте, даже FreeBSD.

Удалось подписать загрузчик винды самоподписным сертификатом. Грузится на ура. Просто надо подписывать не \EFI\BOOT\BOOTX64.EFI, а \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI, как видно по выводу efibootmgr -v. [br] [code=bash] root ~# efibootmgr -v BootCurrent: 0003 Timeout: 1 seconds BootOrder: 0000,0003,0002,0004 Boot0000* Windows Boot Manager HD(1,GPT,87eafe5e-7e53-4c06-a2b8-72ca10bd4236,0x1000,0x64000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS………x…B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}…t……………. [/code]

Делал все по этой [url=https://habr.com/en/post/273497]Укрощаем UEFI SecureBoot[/url] статье. Дальше можно подобрать длинну ключа, хэша и алгоритм шифрования. Моя материнка максимум подреживает конфигурацию rsa:4096, sha512, aes256, наприме.

А если грузится несколько EFI-загрузчиков последовательно (например, refind -> veracrypt -> bootmgr) - подписывать нужно все? Потому что если достаточно подписать refind, то пофигу эти ваши подписывания, из него что угодно потом загрузить можно…

sb проверит подпись efi-приложения, а оно само может грузить что угодно. Есть даже подписанный загурзчик shim(или был) в стандартном наборе сертификатов uefi типа для загрузки системы с лайвсиди. Естественно, стандартные сертификаты нужно удалять и использовать только свои.

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

Только подключать диск к другому пк. Только в таком случае можно подменить то, чему передает управление загрузчик винды и все остальное на разделе винды. Если носишь esp на флешке и шифруешь рут то действительно в sb почти никакого нет смысла, но sb в любом случае немного повышает безопастность. Усложняет доступ к твоему пк(т.е. к виндовсу) не давая злоумышленнику загрузится с livecd.

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

Полная верификация загружаемой системы

Secure boot верифицирует загрузчик: https://habr.com/en/post/273497

Загрузчик верифицирует свои модули, настройки, ядра и инитрд: https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

Ядро верифицирует все запускаемые программы, библиотеки, настройки,… https://sourceforge.net/p/linux-ima/wiki/Home/

Корневой ключ платформы (Chipset key)

Каждый чипсет от Ынтель имеет вшитый свой уникальный ключ от Ынтель, который используется для расшифровки корневого ключа платформы, которым в свою очередь подписаны UEFI и/или TPM. Вот его подменить незя он аппаратный. Этот аппаратный ключ одинаков для всего поколения процов. Вещь очень лакомая для всех и поэтому смею предположить что уже взломана...

Уязвимость в чипсетах Intel, позволяющая извлечь корневой ключ платформы:

Исследователи из компании Positive Technologies выявили уязвимость (CVE-2019-0090), позволяющую при наличии физического доступа к оборудованию извлечь корневой ключ платформы (Chipset key), используемый в качестве корня доверия при проверке подлинности различных компонентов платформы, включая прошивки TPM (Trusted Platform Module) и UEFI.

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

Кроме извлечения ключа ошибка также позволяет добиться выполнения кода на нулевом уровне привилегий Intel CSME (Converged Security and Manageability Engine). Проблема затрагивает большинство выпущенных за последние пять лет чипсетов Intel, но в 10 поколении процессоров (Ice Point) проблема уже не проявляется. Intel стало известно о проблеме около года назад и в мае 2019 года были выпущены обновления прошивок, которые, хотя и не могут изменить уязвимый код в ПЗУ, но пытаются на уровне отдельных модулей Intel CSME блокировать возможные пути эксплуатации.

Из возможных последствий получения корневого ключа платформы, упоминается поддержка прошивок компонентов Intel CSME, компрометация систем шифрования носителей на базе Intel CSME, а также возможность подделки идентификаторов EPID (Enhanced Privacy ID) для того, чтобы выдать свой компьютер за другой для обхода защиты DRM. В случае компрометации отдельных модулей CSME компания Intel предусмотрела возможность перегенерации связанных с ними ключей при помощи механизма SVN (Security Version Number). В случае доступа к корневому ключу платформы этот механизм не эффективен так как корневой ключ платформы применяется для генерации ключа для шифрования блока контроля целостности (ICVB, Integrity Control Value Blob), получение которого, в свою очередь, позволяет подделать код любого из модулей прошивки Intel CSME.

При этом отмечается, что корневой ключ платформы хранится в зашифрованном виде и для полной компрометации дополнительно требуется определить аппаратный ключ, хранящийся в SKS (Secure Key Storage). Указанный ключ не уникальный и одинаков для каждого поколения чипсетов Intel. Так как ошибка позволяет выполнить код на стадии до блокировки механизма генерации ключа в SKS, прогнозируется, что рано или поздно данный аппаратный ключ будет определён.

https://www.opennet.ru/opennews/art.shtml?num=52487

PS: Все диски, включая /boot и / необходимо шифровать. Лучше шифровать диск целиком и заглавия хранить на флешке, соответственно грузится с флешки.

CVE-2020-0543 в микроархитектурных структурах процессоров Intel уязвимость манипулирует утечкой из ранее недокументированного промежуточного буфера: https://www.vusec.net/projects/crosstalk/

Опубликовали прототип эксплоита, демонстрирующий возможность утечки сведений о случайных значениях, получаемых через инструкции RDRAND и RDSEED, для восстановления закрытого ключа ECDSA, обрабатываемого в анклаве Intel SGX, после осуществления в системе всего одной операции с цифровой подписи: https://github.com/vusec/ridl

https://www.opennet.ru/opennews/art.shtml?num=53126

Модераторы, переместите пожалуйста эту тему в раздел секурити.

Уязвимость в процессорах AMD, позволяющая выполнить код на уровне SMM

Компания AMD сообщила о работе над исправлением серии уязвимостей «SMM Callout» (CVE-2020-12890), позволяющей получить контроль над прошивкой UEFI и выполнить код на уровне SMM (System Management Mode). Для атаки необходим физический доступ к оборудованию или доступ к системе с правами администратора. В случае успешной атаки злоумышленник может воспользоваться интерфейсом AGESA (AMD Generic Encapsulated Software Architecture) для выполнения произвольного кода, который невозможно выявить из операционной системы.

Уязвимости присутствуют в коде прошивки UEFI, выполняемом в режиме SMM (Ring -2), более приоритетном, чем режим гипервизора и нулевое кольцо защиты, и имеющим неограниченный доступ ко всей системной памяти. Например, после получения доступа к ОС в результате экслплуатауии других уязвимостей или методов социальной инженерии, атакующий может использовать уязвимости SMM Callout для обхода режима безопасной загрузки (UEFI Secure Boot), внедрения в SPI Flash невидимого для системы вредоносного кода или буткитов, а также для атак на гипервизоры для обхода механизмов проверки целостности виртуальных окружений.

Уязвимости вызваны ошибкой в коде SMM, связанной с отсутствием проверки адреса целевого буфера при вызове функции SmmGetVariable() в SMI-обработчике 0xEF. Из-за данной ошибки атакующий может записать произвольные данные во внутреннюю память SMM (SMRAM) и запустить их как код с правами SMM. По предварительным данным проблема проявляется в некоторых APU (AMD Fusion) для пользовательских и встраиваемых систем, выпускавшихся с 2016 по 2019 год. AMD уже передал большинству производителей материнских плат обновление прошивки с исправлением проблемы, а оставшимся производителям обновление планируется отправить до конца месяца.

https://www.opennet.ru/opennews/art.shtml?num=53204

Уязвимость в чипах Qualcomm (ARM64), позволяющая извлечь закрытые ключи из хранилища TrustZone

Исследователи из компании NCC Group раскрыли [url=https://www.qualcomm.com/company/product-security/bulletins#_CVE-2018-11976]детали уязвимости (CVE-2018-11976) в чипах Qualcomm[/url], позволяющей определить содержимое закрытых ключей шифрования, размещённых в изолированном анклаве Qualcomm QSEE (Qualcomm Secure Execution Environment), основанном на технологии ARM TrustZone. Проблема проявляется в большинстве SoC Snapdragon, получивших распространение в смартфонах на базе платформы Android. Исправления, устраняющие проблему, уже включены в апрельское обновление Android и в новые выпуски прошивок для чипов Qualcomm. На подготовку исправления компании Qualcomm потребовалось больше года - изначально сведения об уязвимости были направлены в Qualcomm ещё 19 марта 2018 года.

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

Уязвимость связана с недоработкой в реализации алгоритма обработки эллиптических кривых, приводившей к утечке информации о ходе обработки данных. Исследователи [b]разработали технику атаки по сторонним каналам, позволяющую по имеющимся косвенным утечкам восстановить содержимое закрытых ключей, размещённых в аппаратно изолированном Android Keystore[/b]. Утечки определяются на основе анализа активности блока предсказания переходов и изменения времени доступа к данным в памяти. В ходе эксперимента исследователи успешно продемонстрировали восстановление 224- и 256-разрядных ключей ECDSA из аппаратно изолированного хранилища ключей, применяемого в смартфоне Nexus 5X. Для восстановления ключа потребовалась генерация около 12 тысяч цифровых подписей, на которую ушло более 14 часов. Для проведения атаки использовался инструментарий Cachegrab.

Основной причиной возникновения проблемы является совместное использование общих аппаратных компонентов и кэша для вычислений в TrustZone и в основной системе - изоляция выполнена на уровне логического разделения, но с использованием общих вычислительных блоков и с оседанием следов вычислений и информации об адресах переходов в общем процессорном кэше. При помощи метода Prime+Probe, основанного на оценке изменения времени доступа к прокэшированной информации, можно через проверку наличия определённых шаблонов в кэше с достаточно высокой точностью отслеживать потоки данных и признаки выполнения кода, связанного с вычислениями цифровых подписей в TrustZone.

Большая часть времени формирования цифровой подписи с использованием ключей ECDSA в чипах Qualcomm тратится на выполнение операций умножения в цикле с использованием неизменного для каждой подписи вектора инициализации (nonce). Если атакующий сможет восстановить хотя бы несколько битов с информацией о данном векторе, появляется возможность совершения атаки по последовательному восстановлению всего закрытого ключа.

В случае с Qualcomm выявлено два места утечки подобной информации в алгоритме умножения: при выполнении операций поиска в таблицах и в коде условного извлечения данных на основе значения последнего бита в векторе «nonce». Несмотря на наличие в коде Qualcomm мер по противодействию утечкам сведений по сторонним каналам, разработанный метод атаки позволяет обойти эти меры и определить несколько битов значения «nonce», которых достаточно для восстановления 256-разрядных ключей ECDSA.

https://www.opennet.ru/opennews/art.shtml?num=50572

Уязвимость в чипах Qualcomm (ARM64), позволяющая извлечь закрытые ключи из хранилища TrustZone

Публикую для «баланса черного пиара».

Исследователи из компании NCC Group раскрыли детали уязвимости (CVE-2018-11976) в чипах Qualcomm, позволяющей определить содержимое закрытых ключей шифрования, размещённых в изолированном анклаве Qualcomm QSEE (Qualcomm Secure Execution Environment), основанном на технологии ARM TrustZone. Проблема проявляется в большинстве SoC Snapdragon, получивших распространение в смартфонах на базе платформы Android. Исправления, устраняющие проблему, уже включены в апрельское обновление Android и в новые выпуски прошивок для чипов Qualcomm. На подготовку исправления компании Qualcomm потребовалось больше года - изначально сведения об уязвимости были направлены в Qualcomm ещё 19 марта 2018 года.

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

Уязвимость связана с недоработкой в реализации алгоритма обработки эллиптических кривых, приводившей к утечке информации о ходе обработки данных. Исследователи разработали технику атаки по сторонним каналам, позволяющую по имеющимся косвенным утечкам восстановить содержимое закрытых ключей, размещённых в аппаратно изолированном Android Keystore. Утечки определяются на основе анализа активности блока предсказания переходов и изменения времени доступа к данным в памяти. В ходе эксперимента исследователи успешно продемонстрировали восстановление 224- и 256-разрядных ключей ECDSA из аппаратно изолированного хранилища ключей, применяемого в смартфоне Nexus 5X. Для восстановления ключа потребовалась генерация около 12 тысяч цифровых подписей, на которую ушло более 14 часов. Для проведения атаки использовался инструментарий Cachegrab.

Основной причиной возникновения проблемы является совместное использование общих аппаратных компонентов и кэша для вычислений в TrustZone и в основной системе - изоляция выполнена на уровне логического разделения, но с использованием общих вычислительных блоков и с оседанием следов вычислений и информации об адресах переходов в общем процессорном кэше. При помощи метода Prime+Probe, основанного на оценке изменения времени доступа к прокэшированной информации, можно через проверку наличия определённых шаблонов в кэше с достаточно высокой точностью отслеживать потоки данных и признаки выполнения кода, связанного с вычислениями цифровых подписей в TrustZone.

Большая часть времени формирования цифровой подписи с использованием ключей ECDSA в чипах Qualcomm тратится на выполнение операций умножения в цикле с использованием неизменного для каждой подписи вектора инициализации (nonce). Если атакующий сможет восстановить хотя бы несколько битов с информацией о данном векторе, появляется возможность совершения атаки по последовательному восстановлению всего закрытого ключа.

В случае с Qualcomm выявлено два места утечки подобной информации в алгоритме умножения: при выполнении операций поиска в таблицах и в коде условного извлечения данных на основе значения последнего бита в векторе «nonce». Несмотря на наличие в коде Qualcomm мер по противодействию утечкам сведений по сторонним каналам, разработанный метод атаки позволяет обойти эти меры и определить несколько битов значения «nonce», которых достаточно для восстановления 256-разрядных ключей ECDSA.

https://www.opennet.ru/opennews/art.shtml?num=50572