Além das vulnerabilidades de corrupção de memória: uma extinção da segurança e o futuro da exploração

Por Chintan Shah · 24 de janeiro de 2022

As técnicas modernas de exploração mudaram a forma como os adversários executam suas estratégias de ataque e como os defensores analisam caminhos da vulnerabilidade à exploração. Na última década, testemunhamos um sólido foco no reforço da segurança tanto no sistema operacional geral quanto em aplicativos, o que resultou em progressos notáveis na introdução de várias minimizações de exploração. Esse progresso vem eliminando gradualmente classes inteiras de vulnerabilidades de corrupção de memória em alguns casos. A Use-After-Free (UAF) é uma classe de vulnerabilidades, por exemplo, que é muito comum em bases de código grandes e complexas, como navegadores da Web. Devido à facilidade de exploração, a Microsoft introduziu um heap isolado e liberação atrasada de objetos em seu mecanismo de navegador (mshtml.dll), quebrando a cadeia de exploração da UAF e exigindo que os malfeitores recriassem as explorações. A figura 1 abaixo mostra a parte do código introduzida para minimizar as vulnerabilidades da UAF.

Podemos notar a diferença entre o código protegido e o código desprotegido. Embora essa fosse apenas a ponta do iceberg, ela tornou a exploração de vulnerabilidades UAF extremamente desafiadora, uma vez que passou a exigir que os atacantes abordassem restrições específicas de tempo e limiares de memória também. A figura 2 abaixo é a visualização simples das minimizações de exploração de memória do SO Windows introduzidas na última década.

No entanto, em várias ocasiões, vimos essas minimizações de exploração serem contornadas pouco depois de serem introduzidas, principalmente porque todo o código, incluindo código dependente e código de terceiros, não era compatível com ou não compilava com essas minimizações ativadas no compilador. Isso essencialmente significava que a minimização da exploração não era aplicada em todas as partes do código, ou não era completamente implementada, deixando várias brechas que, por sua vez, poderiam ser exploradas. Por exemplo, pode-se notar a partir da visualização acima que o ASLR não foi implementado inicialmente em sua totalidade, mas sim em etapas, deixando assim grande parte do código ainda vulnerável a desvios.

Vulnerabilidades de corrupção de memória vão se tornar coisa do passado?

Embora as vulnerabilidades de corrupção de memória continuem a ser a classe de bugs mais amplamente relatada, convertê-las em explorações que possam ser usadas como armas tornou-se um desafio nos últimos anos devido às minimizações de exploração introduzidas no SO, bem como no aplicativo no lado do cliente (por exemplo, motores de script). Traduzir vulnerabilidades de corrupção de memória em explorações completas, que levem à execução arbitrária de código, requer ignorar várias minimizações sem acionar qualquer proteção ou detecção de soluções de segurança para terminais. Isso agora significa que um investimento considerável de esforço, tempo e custo da parte dos adversários é necessário para explorar desvios de minimização. Em várias ocasiões, os adversários também podem precisar encadear múltiplas vulnerabilidades para poder executar uma exploração funcional no sistema alvo, o que também aumenta consideravelmente o custo de desenvolvimento, elevando a complexidade da exploração.

Acreditamos que essa evolução das minimizações de explorações será crucial para moldar a natureza das classes de vulnerabilidade de interesse dos adversários no futuro. A resposta para a pergunta: “Será que as vulnerabilidades de corrupção de memória serão extintas?” é questionável e requer alguma introspecção.

Estratégias de exploração do futuro: o que vem pela frente?

As vulnerabilidades de corrupção de memória continuarão a existir nos aplicativos, desde que haja algum código no aplicativo que lide com a memória incorretamente, mas a intensidade e a frequência de exploração dessa classe de vulnerabilidades eventualmente desaparecerão. Testemunhamos várias instâncias de técnicas de exploração no passado, onde os atacantes alcançaram leitura/gravação arbitrária de memória, explorando uma falha de corrupção de memória e usando essa primitiva para alterar certos sinalizadores ou dados na memória do aplicativo que levam à execução do código. Esses conjuntos de métodos com codinome “ataques apenas de dados” eram estratégias relativamente mais fáceis vistas em muitas explorações. Eventualmente, randomizar certos locais de estruturas de dados críticos na memória reduziu essa natureza de ataques ao longo do tempo.

Com aplicativos ricos em recursos, os atacantes sempre estarão atentos às estratégias mais fáceis para alcançar a execução de código no sistema alvo. Sempre há sistemas legados expostos à Internet que oferecerão o caminho de menor resistência aos atacantes, uma vez que eles não contam com as minimizações introduzidas. No entanto, uma das maneiras de avançar nessa direção é abusar de recursos ou falhas de design no aplicativo ou no protocolo de rede. Se os adversários puderem descobrir uma maneira de abusar do design ou recurso inerente do aplicativo alvo (por exemplo, fazendo com que o aplicativo ou um serviço se conectem à máquina controlada pelo invasor sem orquestrar a memória explicitamente), torna-se relativamente mais fácil alcançar a execução remota de código e, ao mesmo tempo, causar estragos na máquina alvo, uma vez que a funcionalidade do código arbitrário executado pelo processo explorado está completamente na imaginação do agressor. A figura 3 abaixo é uma visão simplista sobre a progressão das estratégias de exploração nos últimos anos.

Testemunhamos ataques apenas de dados e abuso de recursos e falhas de design de aplicativos várias vezes nos últimos anos. Eles oferecem diversas vantagens sobre as explorações tradicionais de corrupção de memória. Seguem abaixo algumas das razões pelas quais acreditamos que essa será a estratégia de exploração do futuro:

• Tem potencial para contornar as minimizações de explorações empregadas, fazendo com que os adversários não tenham que trabalhar na exploração para lidar especificamente com essas barreiras.
• O código arbitrário é executado com os privilégios do processo explorado e, portanto, ajuda a elevar os privilégios.
• Explorações que se aproveitem de recursos ou falhas de design de um aplicativo não têm que lidar com a manipulação explícita de memória e restrições de espaço antes que a vulnerabilidade seja explorada. Consequentemente, livrando-se da injeção de código shell na memória e de técnicas antigas de pivotação de pilha.
• Mais fácil de explorar, em termos relativos, com menor custo de desenvolvimento/manutenção e menos tempo para transformação em uma arma.

Fazer uma retrospectiva das vulnerabilidades críticas nos últimos trimestres pode nos dar a pista definitiva da forma que ataques futuros tomarão. Nas seções a seguir, analisamos algumas das vulnerabilidades de alto impacto mais recentes e verificamos como recursos ou falhas de design em serviços ou aplicativos foram abusados para se alcançar execução de código ou vazamento de informações confidenciais com um mínimo de resistência.

CVE-2021-44228: vulnerabilidade na biblioteca de registro Log4j2 leva a execução remota de código

Essa vulnerabilidade de execução remota de código relatada na biblioteca de registro Log4j do Apache é uma das falhas mais críticas relatadas nos últimos anos, permitindo que invasores executem código arbitrário no servidor vulnerável que usa a biblioteca de registro Log4j para registrar mensagens de texto. Em nossa postagem de blog anterior, tratamos detalhadamente sobre como o software de código aberto atua como bloco de construção para o desenvolvimento moderno de software e sobre a importância de auditá-lo, pois qualquer vulnerabilidade terá um impacto significativo no produto que o utiliza.

A vulnerabilidade está no método “Lookup” da classe “jndimanager”. When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. Isso permite que o servidor controlado pelo atacante envie a referência JNDI maliciosa na resposta levando à execução de código arbitrário no servidor vulnerável.

Essa exploração remota de código foi possível porque o Java implementa diversos provedores de serviços JNDI (Java Naming Directory Interface) como LDAP, DNS, RMI e CORBA; o carregamento de classes remotas também era possível, dependendo do conjunto de propriedades padrão do sistema.

CVE-2021-44228 é um exemplo clássico de exploração de recursos. O recurso abusado aqui foi a substituição de pesquisa que suporta pesquisas. Pesquisas são uma maneira de adicionar valores às mensagens de log que normalmente são nomes variáveis resolvidos usando um mapa definido ou no tempo de execução através de interfaces implementadas como as classes StrSubstitutor e StrLookup.

O Log4j suporta a sintaxe de propriedade “${prefixo:nome}” onde o prefixo indica ao Log4j que o nome variável deve ser avaliado no contexto específico. O contexto JNDI é incorporado ao Log4j, como mostrado abaixo.

Uma vez que as pesquisas JNDI eram habilitadas por padrão na versão 2.14.1 e anteriores do Log4j (veja a figura 6 acima), a biblioteca poderia identificar as referências JNDI passadas como o valor do parâmetro nos cabeçalhos de solicitação HTTP registrados no servidor, permitindo, consequentemente, que os invasores injetassem referências JNDI maliciosas nos parâmetros de solicitação HTTP que levam à execução remota do código Java.

CVE-2021-34527: vulnerabilidade no serviço de spooler de impressão leva a execução remota de código

Vulnerabilidade de execução remota de código privilegiada em spoolsv.exe ou seja, a PrintNightmare foi outra vulnerabilidade crítica relatada no ano passado e ilustra bem como uma falha de design no protocolo pode ser abusada para executar código arbitrário na máquina alvo sem a necessidade de operação na memória.

A vulnerabilidade foi explorada por meio dos protocolos MS-RPRN e MS-PAR, fazendo chamadas RPC sobre SMB. A exploração aproveita uma falha de design clássica na implementação do componente do servidor de impressão no serviço de spooler, quando solicitações de RPC são feitas às interfaces MS-RPRN e MS-PAR para instalar os drivers da impressora no sistema alvo. Fazer a chamada RPC para RpcAddPrinterDriverEx (MS-RPRN Opnum 89) ou RpcAsyncAddPrinterDriver (MS-PAR Opnum 39) requer que uma estrutura DRIVER_CONTAINER seja passada como um argumento.

Como indicado nos detalhes da estrutura acima, DRIVER_CONTAINER contém pDriverPath e pConfigFile, que são o caminho completo do nome de arquivo contendo o driver da impressora e o módulo de configuração, respectivamente. Tanto pDriverPath quanto pConfigFile são verificados para o caminho UNC para evitar o carregamento de código arbitrário.

A falha de design ou lógica no código aqui é que essa mesma verificação de caminho UNC não é aplicada a pDataFile, que é o caminho completo do arquivo que contém dados da impressora. Um adversário poderia fazer várias chamadas para RpcAddPrinterDriverEx com:

1. pDataFile como o caminho UNC da DLL maliciosa acessível à máquina alvo que, quando bem-sucedida, copiará a DLL maliciosa para a máquina alvo localmente.
2. A mesma API com o nome de arquivo copiado atribuído a pConfigFile (desta vez a DLL maliciosa se torna o caminho local), levando ao carregamento de código malicioso pelo serviço de spooler de impressão.

CVE-2021-36942: vulnerabilidade de falsificação de LSA no Windows leva a vazamentos de credenciais

O RPC sobre SMB sempre esteve envolvido em muitos métodos de exploração. Essa vulnerabilidade pode ser explorada novamente abusando-se do protocolo MS-EFSRPC, que é usado no Windows para gerenciar os arquivos no sistema remoto e criptografados usando o Encrypting File System (EFS).

Ao fazer chamadas RPC específicas como EfsRpcOpenFileRaw pela interface LSARPC, o atacante pode fazer um host do Windows autenticar em outro servidor, o que essencialmente significa que um servidor alvo pode ser levado a autenticar para um servidor controlado por um adversário via autenticação NTLM. Outro fato ainda mais importante: o LSARPC pode ser emitido usando chamadas RPC sem qualquer autenticação prévia e, se esse servidor alvo for Active Directory (AD), então o adversário pode fazer o AD se conectar ao servidor arbitrário usando a conta da máquina para autenticação NTLM. Este protocolo EFSRPC pode ser abusado para encadear várias vulnerabilidades dentro da rede corporativa para retransmitir credenciais NTLM para um servidor controlado pelo atacante que poderia ser usado para executar movimentos laterais, eventualmente levando a um comprometimento completo do domínio.

Se o adversário estiver controlando um servidor Web IIS com o recurso Serviços de Certificados do Active Directory (AD CS) instalado e configurado para usar autenticação NTLM sobre HTTP, fazer um Active Directory autenticar para IIS resultará em vazamento das credenciais NTLM para o adversário, resultando em completo comprometimento do domínio. Embora os ataques de retransmissão NTML não sejam novos, é recomendável usar mecanismos de autenticação mais seguros como o Kerberos para evitar abusos de protocolo como esse.

Em resumo, ser capaz de abusar de um protocolo ou um recurso para fazer um ativo crítico se conectar a um servidor adversário de propriedade externa vem com uma consequência perigosa, como demonstra a vulnerabilidade CVE-2021-44228 do Log4j.

CVE-2021-40444: vulnerabilidade no MSHTML do Windows leva a execução remota de código

Essa foi mais uma vulnerabilidade crítica explorada no ano passado e é um grande exemplo de como um simples abuso de recursos pode ser encadeado com uma falha lógica para alcançar a execução arbitrária de código. Primeiro, Object Linking and Embebeding (OLE) foi usado para vincular o documento ao objeto OLE externo. Historicamente, o OLE teve papel significativo na construção de explorações de escritório usadas como armas e isso continuará a acontecer, pois ele é uma das principais características do formato de arquivo do Microsoft Office projetado especificamente para lidar com a interoperabilidade.

As especificações do Open XML do Microsoft Office permitem que um documento incorpore ou vincule a objetos internos ou externos e, em particular, o vínculo ao objeto OLE externo é especificado através de relacionamentos. Como mostrado no documento de exploração criada abaixo, o arquivo document.xml.rels com atributo Type como “oleObject”, atributo Target definido para o vínculo de objeto OLE e TargetMode definido como externo. Isso permite que o documento criado se vincule ao objeto malicioso hospedado externamente e invoque os respectivos manipuladores de protocolo / recurso para renderizar o objeto, para explorar uma possível falha de lógica / design no manipulador. Essa é uma típica técnica de injeção de modelo OOXML usada em muitas explorações de OOXML no passado. Analisamos detalhadamente explorações de OLE em nossa postagem de blog anterior.

O processamento de código HTML é feito em mshtml.dll enquanto os downloads do protocolo HTTP e do MSHTML têm confiança verificada e são manipulados em urlmon.dll. A falha de design no código de urlmon.dll estava relacionado à extração e à verificação de confiança do arquivo CAB baixado. O arquivo CAB era baixado através do código Javascript (JS) incorporado na página side.html como na figura 11 acima. Devido às verificações de escape de caminho ausentes durante a extração do arquivo CAB, a exploração extraía o arquivo contido dentro do CAB com o caminho relativo conforme a figura 12 abaixo. Isso resultava na liberação da carga maliciosa fora do diretório TEMP criado, eventualmente permitindo que a carga liberada fosse executada.

Conclusão

Houve uma tendência nos últimos anos de vulnerabilidades como CVE-2021-44228, CVE-2021-34527, CVE-2021-36942 and CVE-2021-40444 descritas acima, que se aproveitam de falhas de processamento inerentes e são predominantemente abuso de recursos. As falhas de corrupção de memória continuarão proliferando enquanto houver código inseguro em linguagens sem segurança de memória como Rust, mas certamente esperamos ver a tendência de exploração se movendo mais para a exploração de falhas lógicas e abusos de protocolo. Tanto consumidores quanto desenvolvedores de software de código aberto precisam estar mais atentos, pois essas falhas permitirão que os adversários atinjam seu objetivo inicial de nível de sistema de se mover lateralmente dentro da rede, sem se preocupar com a defesa em profundidade de minimizações de exploração de memória recentemente amadurecidas.