0
0
A Acer está trabalhando para corrigir uma falha de firmware que afeta cinco de seus modelos de laptop. Uma exploração pode permitir que invasores desativem as configurações de inicialização segura de uma máquina para ignorar as principais medidas de segurança e carregar malware, descobriram os pesquisadores.
O pesquisador da ESET Research Martin Smolar descobriu a falha, rastreada como CVE-2022-4020 , no driver HQSwSmiDxe DXE em algumas versões de notebooks Acer Aspire e Extensa. Um invasor com privilégios elevados pode usar a falha para modificar as configurações de UEFI Secure Boot por meio de uma variável NVRAM, divulgou a ESET em uma série de tweets publicados em 28 de novembro.
“#CVE-2022-4020 é encontrado no driver DXE HQSwSmiDxe, que verifica a variável NVRAM ‘BootOrderSecureBootDisable'”, de acordo com a ESET. “Se a variável existir, o driver desativa o Secure Boot.”
Secure Boot é um recurso de segurança da Unified Extensible Firmware Interface (UEFI) 2.3.1 projetado para detectar adulteração de carregadores de inicialização, arquivos do sistema operacional e ROMs opcionais não autorizados, validando suas assinaturas digitais. O recurso bloqueia qualquer atividade maliciosa antes que ela possa infectar o sistema.
Ao explorar a falha, os agentes de ameaças podem contornar esse recurso e executar o código que quiserem na máquina, malware ou outro, até mesmo alcançando persistência em um caso em que um sistema operacional é reinstalado, disseram os pesquisadores.
Fabricante diferente, vulnerabilidade de segurança semelhante
Especificamente, o CVE-2020-4020 afeta os notebooks Acer Aspire A315-22, A115-21 e A315-22G e Extensa EX215-21 e EX215-21G. A falha cria uma oportunidade semelhante para os invasores à causada por vulnerabilidades rastreadas como CVE-2022-3430, CVE-2022-3431 e CVE-2022-3432 que os pesquisadores da ESET encontraram no início de novembro em vários dispositivos Lenovo Yoga IdeaPad e ThinkBook, e posteriormente detalhado extensivamente em uma série de tweets .
Como naquele caso, a ESET também relatou a vulnerabilidade ao fabricante do computador para correção. A Acer respondeu rapidamente em 29 de novembro com uma atualização de segurança corroborando as descobertas de Smolar e enfatizando a gravidade da falha.
“Ao desabilitar o recurso Secure Boot, um invasor pode carregar seu próprio gerenciador de inicialização malicioso não assinado para permitir controle absoluto sobre o processo de carregamento do sistema operacional”, disse a empresa. “Isso pode permitir que eles desativem ou ignorem as proteções para implantar silenciosamente suas próprias cargas com os privilégios do sistema”.
A Acer está trabalhando em uma atualização do BIOS para resolver o problema que será postado no site de suporte da Acer e recomenda que os usuários afetados atualizem seu BIOS, uma vez disponível, para a versão mais recente para resolver o problema. O patch também será incluído como uma atualização crítica do Windows, disse a empresa.
Problema comum de variável NVRAM
Nos cenários da Lenovo e da Acer, os invasores podem explorar o bug da Acer criando variáveis NVRAM especiais, cujo valor real não é importante – a existência da própria variável é a única coisa que um driver de firmware afetado verifica, observaram os pesquisadores.
As variáveis NVRAM definem um nome para a opção de inicialização que pode ser exibida para um usuário. A variável também contém um ponteiro para o dispositivo de hardware e para um arquivo nesse dispositivo de hardware que contém a imagem UEFI a ser carregada.
Esse problema parece ser bastante conhecido, com os pesquisadores já aconselhando contra os desenvolvedores de firmware que armazenam componentes sensíveis à segurança nessas variáveis. O engenheiro de segurança de firmware Nikolaj Schlej até twittou um apelo aos desenvolvedores de firmware em outubro para “parar de usar NVRAM comum como armazenamento confiável” devido ao problema de segurança que ela representa.
“É realmente tentador usar NVRAM ou CMOS SRAM para armazenar gatilhos para várias coisas, mas ambos precisam ser assumidos sob controle total do invasor”, disse ele em resposta ao seu próprio tweet. “Mesmo as variáveis NVRAM voláteis não são completamente seguras porque ainda há uma chance de verificação de atributo incorreta.”
No caso das falhas da Lenovo, parece que os desenvolvedores já estavam cientes do problema antes de chegar aos laptops da empresa, já que alguns dos componentes afetados deveriam ser usados apenas durante a fabricação e foram incluídos por engano na produção. de acordo com a ESET.
FONTE: DARK READING