Explorando gerenciadores de inicialização assinados para contornar a Inicialização segura UEFI

Versão russa deste artigo.
O firmware das placas-mãe de PC modernas segue a especificação UEFI desde 2010. Em 2013, uma nova tecnologia chamada Secure Boot apareceu, destinada a impedir a instalação e execução de bootkits . O Secure Boot impede a execução de códigos de programas não assinados ou não confiáveis ​​(programas .efi e carregadores de inicialização do sistema operacional, firmware de hardware adicional, como OPROMs da placa de vídeo e do adaptador de rede).
O Secure Boot pode ser desativado em qualquer placa-mãe de varejo, mas um requisito obrigatório para alterar seu estado é a presença física do usuário no computador. É necessário inserir as configurações UEFI quando o computador inicializar e somente então é possível alterar as configurações de Inicialização Segura.

A maioria das placas-mãe inclui apenas chaves da Microsoft como confiáveis, o que força os fornecedores de software inicializáveis ​​a solicitar que a Microsoft assine seus gerenciadores de inicialização. Esse processo inclui o procedimento de auditoria de código e justificativa para a necessidade de assinar seu arquivo com chave confiável globalmente, se quiser que o disco ou o flash USB funcione no modo Inicialização segura sem adicionar a chave em cada computador manualmente.
Distribuições Linux, hipervisores, discos de inicialização antivírus, autores de softwares de recuperação de computadores precisam assinar seus gerenciadores de inicialização na Microsoft.

Eu queria criar uma unidade flash USB inicializável com vários softwares de recuperação de computador que inicializassem sem desativar o Secure Boot. Vamos ver como isso pode ser alcançado.

Carregadores de inicialização assinados

Portanto, para inicializar o Linux com o Secure Boot ativado, você precisa de um carregador de inicialização assinado. A Microsoft proíbe assinar software licenciado sob a GPLv3 devido à regra de licença de restrição de tivoização , portanto, o GRUB não pode ser assinado .
Para resolver esse problema, a Linux Foundation lançou o PreLoader e Matthew Garrett fizeram shim - pequenos carregadores de inicialização que verificam a assinatura ou o hash de um único arquivo e o executam. O PreLoader e o shim não usam o repositório de certificados UEFI db , mas contêm um banco de dados de hashes permitidos (PreLoader) ou certificados (shim) dentro do arquivo executável.
Os dois programas, além de executar automaticamente arquivos confiáveis, permitem executar qualquer programa não confiável anteriormente no modo Inicialização segura, mas exigem a presença física do usuário. Quando executado pela primeira vez, você precisa selecionar um certificado a ser adicionado ou o arquivo a ser hash na interface gráfica, após o qual os dados são adicionados a uma variável NVRAM especial na placa-mãe que não pode ser acessada pelo sistema operacional carregado . Os arquivos tornam-se confiáveis ​​apenas para esses pré-carregadores, não para a Inicialização Segura em geral, e ainda não puderam ser carregados sem o PreLoader ou shim.


Inicialização de software não confiável com calço.

Todas as distribuições populares do Linux modernas usam shim devido ao suporte ao certificado, o que facilita o fornecimento de atualizações para o carregador de inicialização principal sem a necessidade de interação do usuário. Em geral, o shim é usado para executar o GRUB2 - o gerenciador de inicialização mais popular no Linux.

GRUB2

Para evitar abuso de carregador de inicialização assinado com intenções maliciosas, a Red Hat criou patches para o GRUB2 que bloqueiam funções "perigosas" quando o Secure Boot está ativado: insmod / rmmod, appleloader, linux (substituído por linuxefi), inicialização múltipla, xnu, memrw, iorw. O módulo chainloader, que carrega arquivos .efi arbitrários, introduziu seu próprio carregador interno .efi (PE) personalizado sem usar as funções UEFI LoadImage / StartImage, bem como o código de validação dos arquivos carregados via shim, a fim de preservar o capacidade de carregar arquivos confiáveis ​​por shim, mas não confiáveis ​​em termos de UEFI. Não está exatamente claro por que esse método é preferível - o UEFI permite redefinir (ligar) as funções de verificação UEFI, é assim que o PreLoader funciona e, de fato, o recurso de calço está presente, mas desativado por padrão.

De qualquer forma, o uso do GRUB assinado de alguma distribuição Linux não se adequa às nossas necessidades. Há duas maneiras de criar uma unidade flash inicializável universal que não exigiria a adição de chaves de cada arquivo executável aos arquivos confiáveis:

• Use GRUB modificado com carregador EFI interno, sem verificação de assinatura digital ou restrições de módulo;
• Use o pré-carregador personalizado (o segundo) que conecta as funções de verificação de arquivo UEFI (EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication)

O segundo método é preferível, pois o software executado pode carregar e iniciar outro software, por exemplo, o shell UEFI pode executar qualquer programa. O primeiro método não fornece isso, permitindo que apenas o GRUB execute arquivos arbitrários. Vamos modificar o PreLoader removendo todos os recursos desnecessários e o código de verificação de patches para permitir tudo.

A arquitetura do disco é a seguinte:

______ ______ ______ ╱│ │ ╱│ │ ╱│ │ /_│ │ → /_│ │ → /_│ │ │ │ → │ │ → │ │ │ EFI │ → │ EFI │ → │ EFI │ │_______│ │_______│ │_______│ BOOTX64.efi grubx64.efi grubx64_real.efi (shim) (FileAuthentication (GRUB2) override) ↓↓↓ ↑ ↑ ______ ↑ ╱│ │ ║ /_│ │ ║ │ │ ═══════════╝ │ EFI │ │_______│ MokManager.efi (Key enrolling tool) 

É assim que o Super UEFIinSecureBoot Disk foi criado.

O Super UEFIinSecureBoot Disk é uma imagem inicializável com o carregador de inicialização GRUB2 projetado para ser usado como base para recuperação de unidades flash USB.

Recurso principal: o disco está totalmente funcional com o modo UEFI Secure Boot ativado. Ele pode iniciar qualquer sistema operacional ou arquivo .efi, mesmo com assinatura não confiável, inválida ou ausente.

O disco pode ser usado para executar várias distribuições do Live Linux, ambiente WinPE, inicialização de rede, sem desativar o modo Inicialização Segura nas configurações UEFI, o que pode ser conveniente para executar a manutenção do PC e laptops corporativos de outras pessoas, por exemplo, com as configurações UEFI bloqueadas com uma senha.

A imagem contém 3 componentes: shim pre-loader do Fedora (assinado com a chave da Microsoft que é pré-instalada na maioria das placas-mãe e laptops), Linux Foundation PreLoader modificado (desativa a verificação de assinatura digital dos arquivos executados) e o GRUB2 modificado.

Na primeira inicialização, é necessário selecionar o certificado usando o MokManager (inicia automaticamente); depois disso tudo funcionará como com a Inicialização segura desabilitada - o GRUB carrega qualquer arquivo .efi ou kernel Linux não assinado, os programas EFI executados podem carregar outros executáveis ​​não confiáveis ​​ou motoristas.

Para demonstrar as funções do disco, a imagem contém o Super Grub Disk (um conjunto de scripts para pesquisar e executar o SO, mesmo que o carregador de inicialização esteja quebrado), o GRUB Live ISO Multiboot (um conjunto de scripts para carregar as distribuições Linux Live diretamente do arquivo ISO), um Arquivo Linux (o kernel e initrd em um único arquivo, para recuperação do sistema) e vários utilitários UEFI.

O disco também é compatível com UEFI sem inicialização segura e com PCs mais antigos com BIOS.

Carregadores de inicialização assinados

Eu queria saber se é possível ignorar o primeiro registro de chave de inicialização através do shim. Poderia haver algum gerenciador de inicialização assinado que permita fazer mais do que os autores esperavam?
Como se viu - existem tais carregadores. Um deles é usado no Kaspersky Rescue Disk 18 - disco de inicialização do software antivírus. O GRUB do disco permite carregar módulos (o comando insmod), e o módulo no GRUB é apenas um código executável. O pré-carregador no disco é personalizado.

Obviamente, você não pode simplesmente usar o GRUB do disco para carregar código não confiável. É necessário modificar o módulo chainloader para que o GRUB não use as funções UEFI LoadImage / StartImage, mas carregue automaticamente o arquivo .efi na memória, execute a realocação, encontre o ponto de entrada e salte para ele. Felizmente, quase todo o código necessário está presente no repositório do Red Hat GRUB Secure Boot , o único problema - o analisador de cabeçalho PE está ausente. O GRUB obtém o cabeçalho analisado do shim, em resposta a uma chamada de função por meio de um protocolo especial. Isso pode ser facilmente corrigido, portando o código apropriado do shim ou do PreLoader para o GRUB.

É assim que o Silent UEFIinSecureBoot Disk foi criado. A arquitetura final do disco é a seguinte:

  ______ ______ ______ ╱│ │ ╱│ │ ╱│ │ /_│ │ /_│ │ → /_│ │ │ │ │ │ → │ │ │ EFI │ │ EFI │ → │ EFI │ │_______│ │_______│ │_______│ BOOTX64.efi grubx64.efi grubx64_real.efi (Kaspersky (FileAuthentication (GRUB2) Loader) override) ↓↓↓ ↑ ↑ ______ ↑ ╱│ │ ║ /_│ │ ║ │ │ ═══════════╝ │ EFI │ │_______│ fde_ld.efi + custom chain.mod (Kaspersky GRUB2) 

O fim

Neste artigo, provamos a existência de carregadores de inicialização confiáveis ​​e insuficientes, assinados pela chave da Microsoft, o que permite inicializar código não confiável no modo Inicialização segura.
Usando arquivos assinados do Kaspersky Rescue Disk, conseguimos uma inicialização silenciosa de qualquer arquivo .efi não confiável com a Inicialização segura ativada, sem a necessidade de adicionar um certificado ao UEFI db ou deslocar o MOK.
Esses arquivos podem ser usados ​​tanto para boas ações (para inicializar a partir de unidades flash USB) quanto para más (para instalar bootkits sem o consentimento do proprietário do computador).
Suponho que o certificado de assinatura do carregador de inicialização da Kaspersky não terá vida útil longa e será adicionado à lista global de revogação de certificados UEFI , que será instalada em computadores executando o Windows 10 via Windows Update, quebrando o Kaspersky Rescue Disk 18 e o Silent UEFIinSecureBoot Disk. Vamos ver quanto tempo isso aconteceria.

Download do Super UEFIinSecureBoot Disk: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk
Download silencioso do UEFIinSecureBoot Disk (rede ZeroNet Git Center ): http://127.0.0.1:43110/1KVD7PxZVke1iq4DKb4LNwuiHS4UzEAdAv/