Tempo de execução RPC, tomada dois: descobrindo uma nova vulnerabilidade
Resumo executivo
O pesquisador da Akamai Ben Barnea encontrou uma vulnerabilidade importante na biblioteca de tempo de execução RPC (Remote Procedure Call, chamada de procedimento remoto): CVE-2022-22019, com uma pontuação básica de 8.8.
A nova vulnerabilidade aproveita um estouro de número inteiro que foi reportado anteriormente à Microsoft e corrigido em abril de 2022.
A nova vulnerabilidade foi eliminada na May Patch Tuesday da Microsoft.
Recomendamos, juntamente com a lista anterior de atenuações da Microsoft, a aplicação rápida de patches e a utilização da segmentação de rede para limitar a exploração dessas vulnerabilidades para movimentação lateral.
Introdução
Em 12 de abril de 2022, a Microsoft lançou patches para três vulnerabilidades na biblioteca de tempo de execução RPC (Remote Procedure Call, chamada de procedimento remoto) (rpcrt4.dll). Essas vulnerabilidades receberam os seguintes CVEs: CVE-2022-26809, CVE-2022-24492 e CVE-2022-24528. Os sistemas operacionais afetados são Windows 7, 8, 10 e 11, e Windows Servers 2008, 2012, 2019 e 2022.
A exploração dessas vulnerabilidades permitiria que um invasor remoto não autenticado executasse código na máquina vulnerável com os privilégios do serviço RPC. Esse recurso pode ser usado tanto para violar uma rede quanto para executar movimentos laterais e, portanto, é desejado por invasores e operadores de ransomware. A Microsoft, por sua vez, marcou essas vulnerabilidades como prováveis de serem exploradas. Devido à sua gravidade (CVSS 9.8), decidimos dar uma olhada detalhada na biblioteca corrigida e escrever sobre nossas descobertas em uma publicação anterior do blog sobre o assunto.
Descobrimos que todas as três vulnerabilidades eram estouros de número inteiro e que o patch estava adicionando uma verificação para ver se ocorreu um estouro de número inteiro. Esta correção permitiu que a Microsoft evitasse a exploração dessas vulnerabilidades específicas. No entanto, durante nossa investigação, conseguimos encontrar uma vulnerabilidade adicional utilizando o estouro de número inteiro da mesma variável que foi descoberta anteriormente, o que não foi atenuado pela verificação adicionada.
Depois de um processo de divulgação responsável com a Microsoft, podemos descrever a nova vulnerabilidade RPC. Ela foi descoberta no dia em que a terça-feira de patches de maio foi lançada, e agora foi abordada no patch de maio. A vulnerabilidade, presente tanto no código do servidor como no código do cliente, recebeu um único CVE:
Noções básicas sobre a vulnerabilidade encontrada
Para entender a vulnerabilidade RPC recém-descoberta, vamos analisar novamente a vulnerabilidade corrigida em abril. Como concluímos em nossa publicação anterior no blog, um bug de estouro de número inteiro existia no código da biblioteca de tempo de execução RPC que, quando abusado, poderia levar a um estouro de buffer de heap, uma situação em que os dados são copiados em um buffer muito pequeno para preenchê-lo. Isso, por sua vez, permite que os dados sejam gravados fora dos limites do buffer, no heap. Quando explorado corretamente, isso pode levar à execução remota de código.
Para corrigir essa vulnerabilidade, uma nova chamada foi adicionada a ProcessReceivedPdu:
Esta chamada aciona uma função que verifica exatamente se o parâmetro de número inteiro está em excesso:
Ao observar OSF_SCALL::GetCoalescedBuffer (a função na qual o estouro de heap ocorre), também podemos observar a verificação adicionada:
GetCoalescedBuffer é responsável pela coalescência de fragmentos de buffers que foram enfileirados em ProcessReceivedPdu. O estouro de número inteiro original ocorre quando o comprimento total de fragmentos que foram enfileirados é adicionado ao comprimento do buffer recebido no momento; essa adição leva a um estouro. Invocando uma função que verifica o estouro, a Microsoft corrigiu a vulnerabilidade original.
No entanto, o patch apenas solucionou parcialmente a vulnerabilidade. Durante nossa pesquisa, descobrimos que, antes de alocar memória para o novo buffer coalescido, o código adiciona mais 24 bytes ao tamanho da alocação (visto acima com a chamada para OSF_SCALL::TransGetBuffer). Esses 24 bytes são o tamanho de uma estrutura chamada rpcconn_request_hdr_t, que serve como cabeçalho de buffer. Como o patch executa a verificação de estouro de número inteiro antes de adicionar o tamanho do cabeçalho, ele não leva em consideração esse cabeçalho, o que pode levar ao mesmo estouro de número inteiro que o patch estava tentando atenuar.
A nova vulnerabilidade (uma em uma função do lado do cliente e outra do lado do servidor) foi atenuada. O novo patch adiciona outra chamada para validar que a adição de 24 bytes não estoura.
Mitigação
Aplicar as atualizações de segurança de maio podem atenuar essa vulnerabilidade.
Bloqueie o tráfego para a porta TCP 445 de dispositivos fora do perímetro da empresa.
Limite o movimento lateral permitindo a entrada da porta TCP 445 somente em máquinas onde ela é necessária (controladores de domínio, servidores de impressão, servidores de arquivos, etc.).
Cronograma de divulgação
13 de abril de 2022: Um relatório foi enviado à Microsoft
13 de abril de 2022: Status alterado de Novo para Revisão/Reprodução
22 de abril de 2022: Status alterado de Revisão/Reprodução para Desenvolvimento
10 de maio de 2022: O patch foi lançado
Conclusão
A aplicação de patches é considerada uma das medidas de segurança mais básicas; uma vulnerabilidade é encontrada, um patch é lançado, a vulnerabilidade é atenuada. Enquanto os dias zero recebem muita atenção na mídia e na comunidade em geral, como profissionais, sabemos que as maiores vulnerabilidades vêm de situações semelhantes a essa. Este é um ótimo exemplo do motivo pelo qual esse processo deve ser contínuo e repetitivo.
Nós, como uma comunidade, muitas vezes nos concentramos no código original ao procurar bugs, mas trabalhar especificamente em atualizações e patches oferece outro aspeto da busca por bugs, o que pode facilitar a colaboração para encontrar soluções e permitir uma melhor segurança em todos os lugares.
Essa situação também reitera fortemente a importância de pesquisadores de segurança independentes. Gostaríamos de incentivar outros pesquisadores de segurança a continuar a analisar esse e outros patches em outras partes em busca de vulnerabilidades.
Tem dúvidas ou quer discutir o que descobrimos? Entre em contato conosco no Twitter @Akamai_Research para nos dizer o que você pensa.
