Extorsão Smash-and-Grab, uma ameaça crescente na cibersegurança

O relatório “2024 Attack Intelligence Report” da equipe da Rapid7 é uma leitura obrigatória para aqueles que desejam entender as ameaças cibernéticas atuais. Alguns pontos-chave incluem:

1. 53% das mais de 30 novas vulnerabilidades amplamente exploradas em 2023 e início de 2024 foram zero-days.
2. Mais eventos de comprometimento em massa surgiram de vulnerabilidades zero-day do que de vulnerabilidades n-day.
3. Quase um quarto dos ataques generalizados foram zero-day, onde um único adversário comprometeu dezenas a centenas de organizações simultaneamente.
4. Os atacantes estão se movendo do acesso inicial para a exploração em minutos ou horas, em vez de dias ou semanas.

Portanto, a estratégia convencional de aplicar patches e corrigir falhas é tão eficaz quanto um caminhão de bombeiros chegando depois que um prédio já queimou até o chão. Embora essa abordagem possa prevenir ataques futuros, considerando que o desenvolvimento de patches leva de dias a semanas e que o tempo médio para aplicar patches críticos é de 16 dias, os dispositivos permanecem vulneráveis por um longo período após a descoberta pública de um zero-day. Isso permite que atores menores aproveitem a situação, como abutres. Diante do relatório da Rapid7, algo diferente deve ser feito para proteger dispositivos IoT e outros vulneráveis.

Como o firmware é desenvolvido

O artigo “Software Bills of Materials for IoT and OT devices” da IoTSF é outra leitura essencial. Foi surpreendente aprender que “o software moderno raramente é criado do zero, mas sim integra uma pequena quantidade de código novo com dezenas, centenas ou até milhares de componentes pré-existentes…”. Nos velhos tempos (cerca de 2015), escrevíamos nosso próprio firmware, mas não mais.

Agora, de acordo com os autores, o firmware IoT é montado principalmente a partir de componentes de código aberto que estão repletos de vulnerabilidades. Isso não é um avanço para a segurança dos dispositivos!

Os autores da IoTSF afirmam que os componentes trazem mais componentes, cada um com mais vulnerabilidades. Além disso, criar SBOMs precisos é difícil, e identificar todas as vulnerabilidades em um SBOM é ainda mais difícil. As equipes de segurança enfrentam SBOMs inadequados e a tarefa de decidir quais vulnerabilidades são exploráveis e então corrigir essas vulnerabilidades.

De acordo com outros relatórios, o número de vulnerabilidades e a complexidade do firmware IoT estão crescendo rapidamente ano após ano. Acompanhar os patches parece ser uma tarefa impossível. Não é de se admirar que as equipes de segurança estejam se esgotando.

Explorações alarmantes

Os zero-days são especialmente preocupantes porque muitos atores estatais têm inventários deles prontos para serem usados como armas. Tendemos a pensar em explorações como exfiltrações de dados ou ataques de ransomware. No entanto, isso não é toda a história. Em 2007, no Idaho National Laboratory, decidiu-se testar se malware poderia danificar um gerador elétrico de tamanho real. O malware controlava um relé que conectava ou desconectava o gerador da rede elétrica. Ao exercer uma sequência de conexões e desconexões, o malware conseguiu destruir o gerador.

O resultado não foi um dano reparável, mas sim sucata que só poderia ser derretida para fabricar um novo gerador. O gerador foi destruído em menos de um minuto. Assim, o malware em execução em um pequeno MCU conseguiu destruir uma grande máquina. E se um ator malicioso pudesse destruir 10% dos geradores elétricos nos EUA?  Quanto tempo levaria para fabricar e instalar geradores de reposição? O que aconteceria nesse meio tempo?

Precisamos de uma solução melhor

Devemos reconhecer que a aplicação de patches não é suficiente para lidar com novas ameaças emergentes e as ameaças armadas detalhadas acima. Isolar firmware vulnerável é a melhor solução. Isso é amplamente demonstrado pelo Integrity da Green Hills para o setor aeroespacial, pelo QNX da BlackBerry para automotivo, e por vários “núcleos de separação” de outras empresas.

No entanto, o problema com essas soluções é que elas exigem processadores que consomem muita energia, e a isolação é feita no nível do processo usando unidades de gerenciamento de memória (MMUs). Dispositivos IoT geralmente requerem microcontroladores de baixo consumo (MCUs), seu firmware normalmente é composto por um único processo e são limitados a unidades de proteção de memória (MPUs). O que é necessário é uma isolação mais granular (ou seja, no nível da tarefa) que funcione para MCUs.

Temos uma Solução

Demonstramos que a partição isolada é prática para MCUs baseados em Cortex-M (que compõem cerca de 80% de todos os MCUs em produção). Além disso, a barreira pmode fornecida por essa arquitetura oferece proteção adicional para código crítico e outros códigos confiáveis. Esse código precisa de apenas uma modificação mínima para a partição. A figura a seguir ilustra os fundamentos da partição Cortex-M e como ela se encaixa no panorama geral da segurança:

Como mostrado, firmware crítico para a missão, firmware de segurança e firmware de modo de manipulador (hmode) são protegidos pela barreira pmode e executados em modo privilegiado (pmode) ou hmode. Firmware de aplicação vulnerável, SOUP e middleware estão acima da barreira pmode e executados em modo não privilegiado (umode). Firmware em umode pode acessar pmode ou hmode apenas por meio de exceções causadas por falhas ou pela exceção SVC, que é usada para chamadas de serviço do sistema. A barreira pmode é imposta por hardware e, portanto, é impenetrável a partir do umode.

Conforme mostrado na figura, o firmware umode é dividido em partições isoladas. Se um hacker penetrar uma partição umode, ele não poderá acessar dados ou código em outras partições. A comunicação entre partições é feita por portais, que preservam a isolação. Como consequência, um hacker pode desabilitar a funcionalidade de uma partição umode, mas não de outras. Além disso, o código pmode e umode é duplamente protegido pela barreira pmode. Assim, o dispositivo é capaz de continuar realizando suas funções primárias e a maioria das funções secundárias quando atacado. Durante um ataque, a partição invadida pode ser interrompida, o malware exorcizado e a partição reiniciada para retomar a operação normal.

Vale ressaltar que a partição isolada é tão eficaz contra zero-days quanto contra vulnerabilidades não corrigidas. Não importa como o invasor entrou na partição; ele está em uma sandbox. Além disso, a partição permite a segmentação, que pode mitigar ameaças internas (outro vetor de ataque crescente), e fornece imposição de hardware de certas boas práticas de programação, o que pode levar a mais entregas pontuais!

Para aqueles interessados, postamos demonstrações e um ebook em www.smxrtos.com/securesmx. Que os mocinhos vençam!