Pesquisadores de segurança da Binarly identificaram a possibilidade de contornar o modo de inicialização verificada UEFI Secure Boot em mais de 800 produtos lançados por empresas como Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo e Supermicro. O problema recebeu o codinome PKfail e está relacionado ao uso em firmwares de uma chave de plataforma (PK, Platform Key) não confiável, gerada pela AMI (American Megatrends International) e fornecida como um exemplo de teste. Os firmwares mais antigos que usavam a chave de teste foram lançados em 2012 e os mais recentes datam de junho de 2024. Segundo os pesquisadores, mais de 10% de todos os firmwares verificados estão vulneráveis ao problema.
Nas configurações da chave, estava especificado que ela não era confiável e não deveria ser incluída em seus produtos. Entendia-se que essa chave de teste deveria ser substituída por uma própria, mas os fabricantes ignoraram o aviso e utilizaram em firmwares finais uma chave genérica padrão, enviada a todos os parceiros e clientes da AMI.
A parte privada da chave de teste da AMI, necessária para a criação de assinaturas digitais, tornou-se publicamente acessível após o vazamento de informações de um dos fabricantes de hardware, cujo funcionário acidentalmente publicou em um repositório público no GitHub um código que continha essa chave. A chave privada foi incluída em um arquivo criptografado, que foi protegido com uma senha simples de 4 caracteres, que foi facilmente descoberta por força bruta.
A chave de plataforma é usada como raiz de confiança para assinar bancos de dados de chaves para Secure Boot. O acesso à parte privada da chave de plataforma compromete toda a cadeia de confiança envolvida na validação dos componentes do sistema em carregamento — conhecendo a chave de plataforma, é possível contornar a proteção do Secure Boot e inserir seus próprios componentes durante a inicialização por meio da manipulação da chave KEK (Key Exchange Key) e dos bancos de dados 'db' (Signature Database) e 'dbx' (Forbidden Signature Database). A KEK é responsável por criar a cadeia de confiança entre o firmware e o sistema operacional, 'db' contém certificados e assinaturas para o carregador e componentes UEFI de terceiros, enquanto 'dbx' inclui assinaturas revogadas de componentes maliciosos conhecidos.
Para realizar um ataque, basta gerar novas chaves e certificados para KEK e db, e em seguida utilizar a chave de teste da plataforma que foi exposta publicamente para carregar o certificado KEK gerado no firmware UEFI. Após carregar o certificado KEK no firmware, é possível usar a chave privada associada para carregar um novo certificado no banco de dados db. Após carregar o certificado db, a chave privada associada pode ser utilizada para assinar os componentes EFI carregados. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY KEK\/" -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY db\/" -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign —key db.key —cert db.crt —output rogue.efi.signed rogue.efi
Para verificar a validade da chave da plataforma, basta executar a ferramenta "efi-readvar -v PK" do pacote efitools e assegurar-se de que a chave da plataforma não é um teste: efi-readvar -v PK Variável PK, comprimento 862 PK: Lista 0, tipo X509 Assinatura 0, tamanho 834, proprietário 26dc4851-195f-4ae1-9a19-fbf883bbb35e Assunto: CN=DO NOT TRUST — AMI Test PK Emissor: CN=DO NOT TRUST — AMI Test PK
Fonte: opennet.ru
