0
0
BLACK HAT ASIA 2022 — Quando se trata de desenvolver o firmware que alimenta dispositivos de computação, o ecossistema consiste em cadeias de suprimentos complexas que têm múltiplos colaboradores. Para qualquer dispositivo, o firmware pode ser feito de uma mistura de componentes de diferentes fontes. E isso significa que, na hora de lidar com vulnerabilidades de segurança, está longe de ser um processo simples para levar um remendo ao público.
Durante uma sessão de discussão no Painel de Discussão na Black Hat Asia na quinta-feira, intitulada “A segurança da cadeia de suprimentos de firmware está quebrada: podemos corrigi-lo?”, Kai Michaelis, co-fundador e CTO da Immune GmbH, esboçou o que ele chamou de “árvore” da cadeia de suprimentos crescida, da qual cresce revisões de códigos onerosos e processos de patching demorados quando um bug é encontrado.
Na verdade, de seis a nove meses para os patches serem lançados é a média, segundo os palestrantes — com dois anos não sendo incomuns. E isso significa que a cadeia de suprimentos representa uma ampla superfície de ataque que está pronta para compromisso, eles alertaram. Dado que o firmware vulnerável ameaça a segurança do sistema operacional e de quaisquer aplicativos, o potencial para os ciberatacantes encontrarem vulnerabilidades exploráveis é uma preocupação séria.
Uma árvore espinhosa da complexidade da cadeia de suprimentos
O firmware final que os fornecedores incorporam em seu hardware é um caso multifonte, explicou Michaelis. As partes interessadas podem incluir vários fornecedores de componentes, alguns repositórios de código aberto, implementações de referência, fabricantes de design originais, fornecedores independentes de BIOS e, finalmente, os fabricantes originais de equipamentos (OEMs) que criam e vendem o produto final para parceiros de canal e usuários finais.
Complicando ainda mais as coisas é o fato de que os fornecedores de subsistemas podem estar sentados no meio da árvore de código, combinando elementos de vários fabricantes de componentes em uma única oferta.
O resultado final infeliz é que, quando uma vulnerabilidade é relatada, os OEMs geralmente têm vários “ramos” dos quais patches e atualizações fluem — e geralmente não têm visibilidade uns aos outros.
“É uma árvore de fornecedores e atualizações com pouca coordenação entre eles, e o OEM tem que ingerir tudo isso”, disse Michaelis. “Para os fornecedores, as atualizações de embalagens são um processo bastante manual e, em seguida, os consumidores precisam realmente instalar essas atualizações. Em suma, o processo de remenda como está pode ser medido em meses a anos.”
Uma das principais questões que Michaelis sinalizou é o fato de que quando os insetos são encontrados, eles podem ser benignos em si mesmos. No entanto, quando combinadas com vulns adicionais em outras partes do firmware, as falhas se tornam armaizáveis e podem permitir ataques a parceiros de revendedor de valor agregado (VAR) — e a partir daí, usuários finais.
“Convencer um fornecedor a corrigir o que acredita ser uma falha inofensiva não é fácil”, disse ele. “E mesmo que haja um patch, leva tanto tempo para que ele fique rio abaixo que um invasor poderia facilmente encontrar outra vulnerabilidade para combinar com ele enquanto isso. Então esse é o problema: os bugs existem isoladamente porque os vendedores não conversam entre si, e os bugs têm uma vida útil longa.”
Há pelo menos três outros aspectos que tornam as coisas ainda piores: um dispositivo de fim de vida (EoL) muitas vezes não recebe atualizações; dois, cada fornecedor segue seu próprio ciclo de patch; e três, às vezes, os fornecedores oferecem atualizações silenciosas sem emitir um aviso, o que pode desencorajar os OEMs de incorporar patches.
Repetindo os mesmos erros
Alex Matrosov, fundador e CEO da Binarly, explicou durante o painel que, como na cadeia de fornecimento de software, bugs de firmware também podem ser espalhados e re-importados mesmo depois de corrigidos, resultando no que ele chamou de “falhas repetíveis”.
Por exemplo, um bug recentemente divulgado em um dos componentes do kit portátil Intel M15 (CVE-2022-27493) é uma falha clássica de gravação fora dos limites decorrente da corrupção de memória do modo de gerenciamento do sistema (SMM) — mas não como parece.
“Na verdade, é um bug de 2019 encontrado na base de códigos de AMI que descobrimos agora em 2022”, explicou Matrosov. “Essa vulnerabilidade foi corrigida, mas a versão fixa não foi incluída pelo fornecedor do dispositivo. É um componente muito vulnerável e é conhecido há anos como um vetor de ataque adequado, e deve ser removido.”
Em outro exemplo, o código vulnerável em uma biblioteca de código aberto EDK chamada SecurityPkg foi removido em EDK II em 2018. No entanto, de alguma forma, ele encontrou seu caminho para o firmware 2022 afetando vários OEMs, através de outra biblioteca. “O risco foi exponencialmente compilado”, disse Matrosov.
Melhores princípios para podar de volta a miséria de remendamento
Então, o que deve ser feito? De acordo com o painel, será preciso uma mudança profunda na estratégia e pensando em reforçar de forma confiável a segurança do firmware. No entanto, um bom lugar para começar é uma lista aspiracional de primeiros princípios.
Os palestrantes defenderam, por exemplo, que os OEMs e membros da comunidade de segurança como um todo façam um esforço conjunto para educar fornecedores de componentes e outros elementos da cadeia de suprimentos sobre segurança e convencê-los de que as atualizações são uma necessidade, mesmo para dispositivos EoL — e que, além disso, se eles não emitirem um CVE, torna-se mais difícil comunicar a urgência de corrigir e os bugs se tornam difíceis de rastrear.
Os OEMs também devem colocar em prática esforços para aumentar a transparência dos riscos, de acordo com o painel. Isso pode ser feito facilitando uma maior comunicação entre os fornecedores e criando um repositório centralizado de informações sobre patches e bugs.
“Consertar a cadeia de suprimentos é um esporte em equipe”, disse Matrosov, observando que trabalhar com equipes de resposta a emergências de computador (CERTs) é um bom objetivo.
“Nós realmente precisamos de um corpo independente para ajudar a coordenar patches quando eles afetam vários fornecedores e para facilitar o patcheamento simultâneo. Se um fornecedor remenda e outro não, isso cria uma situação perigosa de zero-day para um subconjunto dos dispositivos”, acrescentou.
A colaboração da comunidade de segurança privada também será fundamental, disseram os palestrantes. Por exemplo, a Linux Foundation lançou um site chamado LVFS, que é um serviço de firmware de fornecedores que permite que os OEMs carreguem atualizações de firmware para serem distribuídas aos usuários do Linux a custo zero. Até agora, cerca de 150 fornecedores estão participando, incluindo Dell, HP, Intel e Lenovo.
“Existem cerca de 1.000 dispositivos diferentes suportados, e enviamos mais de 51 milhões de atualizações desde que iniciamos o projeto”, disse o painelista Richard Hughes, engenheiro principal da Red Hat. “Além disso, podemos pegar o firmware e descompactá-lo em fragmentos. Um fragmento pode ser um EFI, binário, microcó códigos Intel, imagem AMD PSP, etc. Então, todos esses fornecedores que carregam todas essas atualizações nos dão uma enorme quantidade de dados.”
A partir daí, o sistema pode mostrar aos usuários, por exemplo, o mais novo microcódigo Intel disponível para todos os diferentes modelos do sistema — e pode pressionar as atualizações automaticamente.
Há muito a ser feito, mas Hughes fez uma nota otimista.
“Minha conclusão pessoal é que, trabalhando em conjunto com CERTs e empresas de segurança, podemos melhorar ainda mais o sistema imunológico, acelerando o processo de correções de envio para usuários finais e certificando-se de que os problemas de segurança corrigidos por todos os fornecedores”, disse Hughes. “São problemas muito difíceis que assolam toda a indústria há 20 anos. Só agora temos toda a infraestrutura e os dados para melhorar as coisas.”
FONTE: DARK READING