0
0
Como a quantidade de dados confidenciais armazenados em computadores explodiu na última década, fabricantes de hardware e software têm investido quantidades crescentes de recursos para proteger dispositivos contra ataques físicos no caso de serem perdidos, roubados ou confiscados. No início desta semana, a Intel corrigiu uma série de bugs que permitiram que os invasores instalassem firmware malicioso em milhões de computadores que usam suas CPUs.
As vulnerabilidades permitiram que hackers com acesso físico anulassem uma proteção que a Intel embutida em CPUs modernas que impede que o firmware não autorizado seja executado durante o processo de inicialização. Conhecida como Boot Guard, a medida foi projetada para ancorar uma cadeia de confiança diretamente no silício para garantir que todo o firmware que carrega seja assinado digitalmente pelo fabricante do computador. O Boot Guard protege contra a possibilidade de alguém adulterar o chip flash conectado ao SPIque armazena o UEFI,que é uma peça complexa de firmware que conecta o firmware do dispositivo de um PC com seu sistema operacional.
Segurança imposta por hardware
Esses tipos de hacks geralmente acontecem quando os atacantes anexam hardware ao interior de um computador e usam ferramentas de programação de chips de dediprog ou similares para substituir o firmware autorizado por firmware malicioso.
Como a Intel explica aqui:
A execução do código UEFI BIOS é geralmente desamarada ao hardware subjacente, o que significa que este código UEFI BIOS é executado sem ser verificado ou medido. Assim, isso torna todo o processo de inicialização vulnerável à subversão do BIOS, quer isso possa acontecer através de um processo de atualização desprotegido ou simples ataques de hardware usando substituição de memória flash SPI ou usando um Dediprog.
O Intel Boot Guard fornece controles robustos de política de inicialização aplicadas por hardware aos fabricantes de plataformas e proprietários de plataformas para autorizar qual código BIOS é permitido ser executado nessa plataforma. O Intel Boot Guard fornece esse RoT (Root-of-Trust) baseado em hardware para verificação de inicialização da plataforma, que é responsável por verificar a imagem do BIOS antes da execução do BIOS. O Intel Boot Guard eleva a barra de segurança da plataforma, reduzindo os vetores de ataque acima e dificultando o lançamento de ataques para subverter o processo de inicialização.
No início deste ano, o pesquisador de segurança Trammell Hudson descobriu três vulnerabilidades que impediam o Boot Guard de funcionar quando um computador sai do modo de sono. Conhecido tecnicamente como S3, este modo preserva todos os itens armazenados na memória do computador, mas desliga totalmente a CPU.
Subvertendo a Guarda de Bota
Um atacante que é capaz de contornar o Boot Guard durante o despertar seria então capaz de realizar uma série de atividades maliciosas. O principal deles é a obtenção das chaves usadas para criptografar discos rígidos, desde que as chaves sejam armazenadas na memória, como estão com muitos computadores durante o sono. Com isso, um invasor poderia obter as versões descriptografadas de todos os dados armazenados no computador sem exigir a senha do usuário.
Um invasor também pode infectar a máquina com um rootkit — código malicioso que é difícil ou impossível de detectar — que seria executado no modo de gerenciamento do sistema até a próxima reinicialização. Esses implantes SMM são o tipo de coisa que a NSA diz ter.
Embora esses tipos de explorações sejam sérias, os cenários de ataque são limitados porque o hack não pode ser feito remotamente. Para muitas pessoas, ataques que requerem acesso físico não fazem parte de seu modelo de ameaça. Também exigiria experiência em hardware e firmware e ferramentas especiais como o Dediprog ou Spispy, um emulador de flash de código aberto que Hudson desenvolveu. Em uma redup publicada esta semana,Hudson escreveu:
Como o CVE-2020-8705 requer acesso físico, é mais difícil para um invasor usar do que uma exploração remota. No entanto, há alguns cenários de ataque realistas onde ele poderia ser usado.
Um exemplo é ao limpar a alfândega em um aeroporto. A maioria dos viajantes fecha seu laptop durante a descida e permite que ele entre no sono S3. Se o dispositivo for tomado pela agência adversária ao pousar, as chaves de criptografia de disco ainda estiverem na memória. O adversário pode remover a tampa inferior e anexar um emulador flash no sistema como o spispy ao chip flash. Eles podem acordar a máquina e fornecê-la com seu firmware através do spispy. Este firmware pode digitalizar a memória para localizar o processo de tela de bloqueio do SISTEMA e desabilitá-lo e, em seguida, permitir que o sistema seja retomado normalmente. Agora eles têm acesso ao dispositivo desbloqueado e seus segredos, sem necessidade de obrigar o proprietário a fornecer uma senha.
O adversário também pode instalar seu próprio rootkit SMM “Ring -2” neste momento, que permanecerá residente até a próxima reinicialização dura. Isso poderia fornecer-lhes execução de código no sistema quando ele se moveu para uma rede confiável, potencialmente permitindo o movimento horizontal.
Outro exemplo é um implante de hardware que emula o flash SPI. O iCE40up5k [uma pequena placa de matriz de portão programável em campo] usado em uma das variantes do spispy se encaixa facilmente dentro ou debaixo de um pacote SOIC-8, permitindo um ataque persistente contra o caminho do currículo. Uma vez que o FPGA pode facilmente distinguir entre uma bota fria e validação do sistema que retoma o sono, o dispositivo pode fornecer uma versão limpa do firmware com a assinatura correta quando está sendo validado ou lido por uma ferramenta como flashrom, e apenas fornecer a versão modificada durante um currículo do sono. Esse tipo de implante seria muito difícil de detectar via software, e se bem feito, não olharia fora do lugar na placa principal.
A correção está em
Uma das vulnerabilidades do Boot Guard decorreu das configurações que os fabricantes literalmente queimam na CPU através de um processo chamado fusíveis programáveis únicos. Os OEMs devem ter a opção de configurar o chip para executar o Boot Guard quando um computador sai do S3 ou não. Hudson não sabe por que todos os cinco fabricantes que ele testou tiveram que desligar, mas ele suspeita que é porque as máquinas retomam muito mais rapidamente dessa forma.
Em um e-mail, um porta-voz da Intel escreveu: “A Intel foi notificada de uma vulnerabilidade que afeta o Intel Boot Guard, no qual um ataque físico pode ser capaz de contornar a autenticação do Intel Boot Guard ao retomar o estado de sono. A Intel liberou atenuações e recomenda manter a posse física de dispositivos.”
A Intel não está dizendo como corrigiu uma vulnerabilidade que decorre de configurações de fusíveis que não podem ser redefinidas. Hudson suspeita que a Intel fez a mudança usando firmware que funciona no Intel Management Engine, um coprocessador de segurança e gerenciamento dentro do chipset de CPU que lida com o acesso aos fusíveis OTP, entre muitas outras coisas. (No início desta semana, a Intel publicou detalhes inéditos sobre o ME aqui.)
As duas outras vulnerabilidades decorreram de falhas na forma como as CPUs buscavam firmware quando eram alimentadas. Todas as três vulnerabilidades foram indexadas sob o ID de rastreamento único CVE-2020-8705, que recebeu uma alta classificação de gravidade da Intel. (A Intel tem uma visão geral de todos os patches de segurança de novembro aqui. Os fabricantes de computadores começaram a disponibilizar atualizações esta semana. O post de Hudson, ligado acima, tem uma redisco muito mais detalhada e técnica.
FONTE: ARS TECHNICA