Um vazamento recente de uma “chave de ouro” da Microsoft, juntamente com a presença de um modo de depuração, permitiu que a inicialização segura fosse desativada em dispositivos Windows. Leia!
Os sistemas operacionais baseados em Windows não são mais a escolha padrão e principal no cenário móvel. A natureza de código aberto do Android encontrou muitos fãs em OEMs e, como resultado, cada vez menos telefones usam o Windows atualmente.
Mas se você está entre aqueles que ainda continuam usando um dispositivo Windows no dia a dia, há algumas novidades para você. Bom ou ruim, isso dependeria da sua postura e interpretação dos casos de uso desta notícia.
Conforme relatado por Ars Técnica e O registro com as notícias provenientes de um site que provavelmente lhe dará dor de cabeça (sem brincadeira), alguns desenvolvedores (@never_released e @TheWack0lian) descobriram que um backdoor que a Microsoft incorporou para fins de depuração abriu possibilidades de desabilitar a inicialização segura em dispositivos Windows.
Inicialização segura e o que é?
Quando você inicializa um dispositivo Windows pela primeira vez, o procedimento de inicialização ocorre nesta ordem geral: UEFI (Unified Extensible Firmware Interface, que substitui o BIOS) -> Boot Manager -> Boot Loader -> Janelas. UEFI é onde a funcionalidade Secure Boot está presente. Como o nome indica com Modo de segurança, visa melhorar a segurança, exigindo assinaturas digitais nos próximos passos. Essencialmente, se o bootloader não estiver assinado com as chaves que a UEFI espera, o procedimento de inicialização do seu dispositivo não será concluído.
A inicialização segura é um recurso opcional, mas a Microsoft tornou obrigatória a ativação da certificação do Windows a partir do Windows 8 e posteriores. O raciocínio aqui era que a inicialização segura dificultaria a inserção de código pelos autores de malware no procedimento de inicialização. No entanto, um efeito colateral do Secure Boot foi que ele complicou um pouco a inicialização dupla em máquinas Windows, pois ou o segundo sistema operacional e todos os seus pré-requisitos também precisam ser assinados digitalmente, ou a inicialização segura precisaria ser desabilitado. Há muitos outros problemas envolvidos nisso, e os dual-booters experientes saberiam mais sobre eles do que eu poderia explicar em um parágrafo.
Agora, existem alguns dispositivos nos quais o Secure Boot não pode ser desabilitado pelo usuário, mesmo que ele queira. Este é o domínio onde nosso assunto é drasticamente reduzido em todos os dispositivos Windows (incluindo desktops) para dispositivos Windows específicos, como dispositivos Windows Phone, dispositivos Windows RT, alguns dispositivos Surface e até HoloLens. Esses dispositivos de usuário final têm Inicialização segura bloqueada, significando que um o usuário final não pode modificar ou desabilitar aspectos relacionados à inicialização segurae, por extensão, eles não podem mexer no sistema operacional de maneiras não autorizadas pela Microsoft para o usuário final.
Mas para fins de desenvolvimento oficial contínuo, o Secure Boot precisa ser um pouco mais flexível. Em dispositivos nos quais o Secure Boot está bloqueado, existem políticas de inicialização segura que podem ajudar no desenvolvimento autorizado sem a necessidade de desabilitar o Secure Boot. Como os usuários pesquisadores mencionam, este arquivo de política de inicialização segura é carregado pelo Boot Manager no início do processo de inicialização do Windows. Os arquivos de políticas também podem conter regras de registro que, por sua vez, têm a capacidade de conter configurações para a própria política, entre outras coisas. Novamente, o arquivo de política deve ser assinado e existem outras disposições em vigor para garantir que somente a Microsoft possa provisionar essas alterações.
O elemento de assinatura também depende do que é chamado de DeviceID, que é usado durante a inscrição. Vou deixar a postagem do blog explicar aqui, pois há algumas partes que não estão tão claras para mim:
Além disso, existe algo chamado DeviceID. São os primeiros 64 bits de um hash SHA-256 salgado, de alguma saída UEFI PRNG. É usado ao aplicar políticas no Windows Phone e no Windows RT (mobilestartup configura-o no Phone e SecureBootDebug.efi quando é iniciado pela primeira vez no RT). No Phone, a política deve estar localizada em um local específico da partição EFIESP com o nome do arquivo incluindo a forma hexadecimal do DeviceID. (Com Redstone, isso foi alterado para UnlockID, que é definido pelo bootmgr e é apenas a saída UEFI PRNG bruta).
Basicamente, o bootmgr verifica a política quando ela carrega, se incluir um DeviceID, que não corresponde ao DeviceID do dispositivo em que o bootmgr está sendo executado, a política falhará ao carregar. Qualquer política que permita habilitar testsigning (a MS chama essas políticas de desbloqueio de dispositivo de varejo/RDU e para instalá-los é desbloquear um dispositivo), deve estar bloqueado para um DeviceID (UnlockID em Redstone e acima). Na verdade, tenho várias políticas (assinadas pelo certificado de produção do Windows Phone) como esta, onde as únicas diferenças são o DeviceID incluído e a assinatura. Se não houver nenhuma política válida instalada, o bootmgr volta a usar uma política padrão localizada em seus recursos. Esta política é aquela que bloqueia a ativação de assinatura de teste, etc., usando regras BCD.
Esta é a parte onde as coisas ficam interessantes. Durante o desenvolvimento do Windows 10 v1607, a Microsoft criou um novo tipo de Política de Inicialização Segura (doravante denominada SBP por questões de brevidade) para fins de teste interno e depuração. A política é de natureza "suplementar", sem nenhum DeviceID presente, e faz com que suas configurações sejam mescladas em uma política de inicialização existente. O Boot Manager carrega os tipos mais antigos de SBP, verifica sua assinatura e autenticidade e depois carrega essas políticas de inicialização complementares. A questão aqui é que não há mais verificações sobre a própria apólice suplementar. Além disso, os gerenciadores de inicialização anteriores ao Windows 10 v1511 não sabem da existência da natureza suplementar dessas políticas e, portanto, reagem como se tivessem carregado uma política perfeitamente válida e assinada. Novamente, esse comportamento era provável para desenvolvimento interno, de modo que os desenvolvedores não deveriam ter que assinar cada versão do sistema operacional e pequenas alterações que precisassem fazer no dispositivo.
Este SBP está sendo chamado de “Chave de Ouro”, pois basicamente anula o propósito das verificações de assinatura. Este SBP foi enviado involuntariamente em dispositivos de varejo, embora em estado desativado. Os desenvolvedores encontraram este SBP e divulgaram suas descobertas. Agora, o SBP pode ser encontrado flutuando na internet, com este zip específico sendo usado para instalar o SBP em dispositivos Windows RT.
O que isto significa?
Se você carregou um SBP suplementar, poderá habilitar a assinatura de teste para Windows para permitir o carregamento de drivers não assinados. Além disso, como essas políticas entram em ação antes do estágio do Boot Manager no procedimento de inicialização, você pode comprometer a segurança de todo o pedido e executar código não autorizado (leia-se autoassinado). Isso abre muitas possibilidades, tanto para usuários que pretendem modificar partes do Windows além da autorização, quanto para criadores de malware.
Os autores desta descoberta concentram-se na ironia de todo o fiasco. A Microsoft bloqueou a inicialização segura em determinados dispositivos para manter as alterações não autorizadas longe, mas depois criou um backdoor para permitir que continuassem com o desenvolvimento e a depuração. Mas esse mesmo backdoor abre caminho para que a inicialização segura seja desativada em todos os dispositivos que executam o Windows, tornando toda a provação inútil.
Agora, os usuários dispostos não só podem instalar distros Linux (e possivelmente Android) em tablets e Telefones, usuários involuntários também podem ter bootkits maliciosos instalados se comprometerem o acesso físico aos seus dispositivo. Embora o primeiro seja algo em que possamos pular, o último não inspira muita confiança. Isso funciona nos dois sentidos e nos mostra por que a segurança é uma faca de dois gumes. Além disso, o SBP é de natureza universal, permitindo seu uso em qualquer dispositivo, independentemente da arquitetura. Não é particularmente útil para casos de desktops onde o Secure Boot pode ser desativado facilmente, mas é de grande alcance para dispositivos onde você não pode mexer com o Secure Boot.
Então, qual é a solução?
A Microsoft lançou alguns patches, mas os desenvolvedores insistem que o problema não foi totalmente resolvido. Você pode conferir esses patches (MS16-094 e MS16-100) e depois leia no postagem no blog por que eles não resolvem o problema. Se estiverem corretos, esse problema não tem uma solução ou patch à vista, embora isso não impeça a Microsoft de tentar colocar mais obstáculos no caminho.
Qual o proximo?
Há um mundo de possibilidades, e algumas delas estão surgindo em nossos Fóruns do Windows. Você pode conferir nossos fóruns em Desenvolvimento e hacking do Windows Phone 8 e nossos fóruns para Windows 8, Windows RT e desenvolvimento e hacking de superfície. Você também pode encontrar threads de instruções para alguns dispositivos, onde outros usuários estão discutindo o mesmo.
A presença deste backdoor de depuração e o vazamento do SBP são importantes não apenas para terceiros desenvolvimento de dispositivos Windows bloqueados, eles também nos mostram um lembrete sombrio sobre o que pode acontecer se for intencional backdoors são deixados. O foco recente na segurança voltou-se para as agências de investigação que pressionavam para que a presença de tais backdoors fosse usada para ajudar nos seus fins de investigação legal. Mas, mais cedo ou mais tarde, esses métodos vai cair nas mãos erradas. O que se destina a ser usado como uma ferramenta para combater o crime e ajudar na justiça, um dia se tornará a ferramenta para o próprio crime.
O que você acha do vazamento do Debug SBP? Você acha que deveriam existir “Chaves de Ouro” como essas? Deixe-nos saber nos comentários abaixo!