Como hackear um servidor Exchange sem patch com código PowerShell desonesto

Há pouco menos de dois meses, surgiram algumas notícias preocupantes sobre bugs: um par de vulnerabilidades de dia zero foi anunciado no Microsoft Exchange.

Como nós aconselhou na época, essas vulnerabilidades, designadas oficialmente CVE-2022-41040 e CVE-2022-41082:

[eram] dois dias zero que [poderiam] ser encadeados, com o primeiro bug usado remotamente para abrir uma brecha suficiente para acionar o segundo bug, que potencialmente permite a execução remota de código (RCE) no próprio servidor Exchange.

A primeira vulnerabilidade foi uma reminiscência do problemático e amplamente abusado Falha de segurança do ProxyShell desde agosto de 2021, porque dependia de comportamento perigoso no recurso Autodiscover do Exchange, descrito pela Microsoft como um protocolo que é “usado por clientes Outlook e EAS [Exchange ActiveSync] para localizar e conectar-se a caixas de correio no Exchange”.

Felizmente, o recurso incorreto de Descoberta Automática que poderia ser explorado no ataque ProxyShell por qualquer usuário remoto, conectado ou não, foi corrigido há mais de um ano.

Infelizmente, os patches ProxyShell não fizeram o suficiente para fechar a exploração para usuários autenticados, levando ao novo dia zero CVE-2022-40140, que logo foi lacônico, embora enganosamente, apelidado ProxyNotShell.

Não tão perigoso, mas perigoso mesmo assim

Claramente, o ProxyNotShell não era nem de longe tão perigoso quanto o ProxyShell original, já que exigia o que é conhecido como acesso autenticado, portanto não estava aberto a abusos por qualquer pessoa de qualquer lugar.

Mas rapidamente ficou claro que em muitos servidores Exchange, saber o nome de logon e a senha de qualquer usuário seria suficiente para passar como autenticado e montar esse ataque, mesmo que o próprio usuário precisasse usar autenticação de dois fatores (2FA) para fazer logon corretamente para acessar email deles.

Como o especialista da Sophos Chester Wisniewski colocá-lo no momento:

É uma “vulnerabilidade de autenticação intermediária”, se você quiser chamá-la assim. Isso é uma bênção mista. Isso significa que um script Python automatizado não pode simplesmente escanear toda a Internet e potencialmente explorar todos os servidores Exchange do mundo em questão de minutos ou horas, como vimos acontecer com ProxyLogon e ProxyShell em 2021. […]

Você precisa de uma senha, mas encontrar um endereço de e-mail e uma combinação de senha válida em qualquer servidor Exchange provavelmente não é muito difícil, infelizmente. E você pode não ter sido explorado até o momento, porque para fazer login com êxito no Outlook Web Access [OWA] é necessário o token FIDO, ou o autenticador, ou qualquer segundo fator que você possa estar usando.

Mas este ataque não requer esse segundo fator. […] Adquirir apenas uma combinação de nome de usuário e senha é uma barreira bastante baixa.

Como você provavelmente se lembra, muitos de nós assumimos (ou pelo menos esperávamos) que a Microsoft correria para corrigir os buracos do ProxyNotShell, visto que ainda faltavam duas semanas para o Patch Tuesday de outubro.

Mas ficamos desapontados ao descobrir que uma correção confiável foi aparentemente mais complexo do que o esperado, e outubro veio e foi com ProxyNotShell tratado apenas por soluções alternativas, não por patches adequados.

Mesmo o Patch Tuesday de novembro não forneceu diretamente as correções necessárias, embora os patches no entanto saiu no mesmo dia como parte de uma atualização de segurança específica do Exchange que pode ser buscada e instalada separadamente:

Prova de conceito revelada

Agora que a poeira baixou e todos tiveram tempo de corrigir seus servidores Exchange (aqueles que eles não esqueceram, pelo menos), os pesquisadores da Zero Day Initiative (ZDI), aos quais essas vulnerabilidades foram originalmente divulgadas de forma responsável para submissão ao Microsoft, ter explicado como os bugs podem ser explorados.

A má notícia, dependendo da sua opinião sobre divulgações de exploração aberta, é que a equipe ZDI agora forneceu efetivamente uma prova de conceito (PoC) explicando como atacar servidores Exchange.

A boa notícia, claro, é que:

• Agora podemos estudar e entender os bugs nós mesmos. Isso não apenas nos ajuda a garantir que as precauções gerais que tomamos (não apenas limitadas a patches) provavelmente forneçam a proteção que esperamos, mas também nos informa sobre práticas de programação que desejamos evitar no futuro, portanto, não não caia na armadilha de abrir bugs desse tipo em nosso próprio código do lado do servidor.
• Agora não temos mais desculpas para não aplicar os patches. Se demoramos a atualizar, a explicação de ZDI de por que o ataque funciona deixa claro que a cura é definitivamente preferível à doença.

Como Funciona

ZDI's explicação dessa vulnerabilidade cria uma história fascinante de como pode ser complexo encadear todas as partes necessárias para transformar uma vulnerabilidade em uma exploração viável.

Também vale a pena ler para ajudá-lo a entender por que investigar uma exploração existente pode ajudar a revelar outras maneiras pelas quais uma vulnerabilidade pode ser mal utilizada, potencialmente solicitando patches adicionais, solicitando alterações de configuração e promovendo novas práticas de programação que podem não ter sido óbvias apenas corrigindo o buraco inicial.

A explicação é, necessariamente, complicada e bastante técnica, e conduz você por uma longa série de etapas para alcançar a execução remota de código (RCE) no final.

Na esperança de ajudá-lo a seguir os detalhes de alto nível mais facilmente se você decidir ler o relatório ZDI, aqui está um resumo não muito simplificado com as etapas listadas ao contrário…

…assim você saberá de antemão por que a história segue os rumos que segue:

• ETAPA 4. Enganar remotamente o Exchange para instanciar um objeto .NET de sua escolha, com um parâmetro de inicialização de sua escolha.

Na codificação moderna, um objeto instanciado é o jargão para um pedaço de memória alocado, inicializado automaticamente com os dados e recursos necessários enquanto estiver em uso e vinculado a um conjunto específico de funções que podem operar nele. (Instanciar é apenas uma palavra chique para crio.)

Os objetos podem ser gerenciados e controlados pelo próprio sistema operacional, para ajudar a evitar o tipo de erro de gerenciamento de memória comum em uma linguagem como C, onde você normalmente precisa alocar memória por conta própria, preencher manualmente os campos de dados relevantes e lembrar de libere a memória e os recursos que está usando, como soquetes de rede ou arquivos de disco, quando terminar.

Os objetos geralmente têm uma função programática associada a eles chamada de construtor, que é executado automaticamente quando um novo objeto é criado para alocar a quantidade certa de memória e o conjunto correto de recursos do sistema.

Normalmente, você precisa passar um ou mais parâmetros como argumentos para o construtor, para denotar como deseja que o objeto seja configurado ao iniciar.

Simplificando, se você instanciar, digamos, um TextString objeto (estamos inventando esses nomes, mas você entendeu) usando um parâmetro que é uma string de texto como example.com:8888...

…você provavelmente terminará com um buffer de memória alocado para armazenar seu texto, inicializado para conter o mesmo valor que você passou, ou seja, o texto bruto example.com:8888.

Nesse contexto, a sequência de texto passada como dados para o construtor de objeto não representa imediatamente nenhuma ameaça óbvia de segurança cibernética quando você aciona o construtor remotamente, além de uma possível negação de serviço (DoS) solicitando repetidamente sequências cada vez maiores para tente esgotar a memória.

Mas se você fosse instanciar, digamos, um ConnectedTCPClient objeto usando o mesmo parâmetro de string de texto de example.com:8888, você pode acabar com um buffer de memória pronto para armazenar dados temporários, junto com um soquete de rede alocado pelo sistema operacional que está pronto para trocar dados com o servidor example.com pela porta TCP 8888.

Você pode ver o risco de execução remota de código lá, mesmo que nunca consiga enviar nenhum dado para o soquete aberto, visto que você enganou o servidor para chamar de lar para um local que você controla.

Você pode até encontrar um objeto chamado, digamos, RunCmdAndReadOutput, onde a string de texto que você envia como parâmetro é, literalmente, um comando que você deseja executar automaticamente assim que o objeto é criado, para que você possa coletar sua saída posteriormente.

Mesmo que você nunca consiga recuperar a saída do comando, apenas instanciar tal objeto permitiria que você escolhesse um comando para executar, dando a você a execução remota genérica do código e apresentando um risco limitado apenas pelos direitos de acesso do próprio processo do servidor .

Claro, o ataque só é fácil quando você chega ao último estágio, o que você não deveria ser capaz de fazer, porque o Exchange tem uma lista de permissões estrita que o impede de escolher qualquer objeto antigo para instanciar.

Em teoria, apenas objetos seguros ou de baixo risco podem ser criados remotamente via PowerShell, de modo que instanciar nosso imaginário TextString acima, ou um SimpleIntegerValue, pode ser considerado aceitável, enquanto um ConnectedTCPClient ou um RunCmdAndReadOutput definitivamente não seria.

Mas os pesquisadores do ZDI percebem que antes de acionar a última etapa, eles poderiam fazer isso:

• ETAPA 3. Engane remotamente o Exchange fazendo-o pensar que um objeto de baixo risco que passou no teste de segurança é, na verdade, algum outro objeto de sua escolha.

Mesmo assim, você pode esperar que o Exchange impeça a criação remota até mesmo de objetos de baixo risco, para minimizar ainda mais a ameaça.

Mas os pesquisadores descobriram que eles poderiam:

• ETAPA 2. Induza remotamente o Exchange a usar seu Remoção do PowerShell recurso para criar um objeto com base em parâmetros de inicialização controlados externamente.

E isso foi possível por causa do buraco semelhante ao ProxyShell que foi apenas parcialmente corrigido:

• ETAPA 1. Enganar remotamente o Exchange para que ele aceite e processe uma solicitação da Web com código, empacotando um username:password campo na solicitação também.

Mesmo que o usuário nomeado na solicitação não estivesse realmente conectado e precisasse passar por algum tipo de processo 2FA para acessar sua própria caixa de correio, um invasor que conhecesse seu username:password A combinação teria informações de autenticação suficientes para induzir o Exchange a aceitar uma conexão da Web que poderia ser usada para iniciar a cadeia de ataque descrita nas etapas 2 a 4 acima.

Falando vagamente, qualquer válido username:password combinação faria, dado que a “autenticação” era necessária simplesmente para evitar que o Exchange rejeitasse a solicitação HTTP antecipadamente.

O que fazer?

Observe que este ataque só funciona:

• Se você tiver servidores Exchange locais. A Microsoft afirma ter bloqueado seus próprios serviços de nuvem rapidamente, portanto, o Exchange Online não é afetado. Assegure-se de que você saiba onde estão seus servidores Exchange. Mesmo se você agora usa o Exchange Online, ainda pode ter servidores locais em execução, talvez deixados por engano de seu processo de migração.
• Se seus servidores não tiverem patches. Certifique-se de que você tem aplicou a atualização de software do Exchange de 2022-11-08 para fechar as vulnerabilidades que a exploração requer.
• Se seus servidores ainda aceitam autenticação básica, também conhecida como autenticação herdada. Certifique-se de que você tem bloqueou todos os aspectos da autenticação herdada para que seus servidores não aceitem o username:password cabeçalhos mencionados acima e não aceitará solicitações de protocolo de descoberta automática arriscadas em primeiro lugar. este para os atacantes enganar um servidor para que aceite seus truques de instanciação de objetos armadilhados, mesmo que esse servidor não esteja corrigido.

Você pode observar de nossos conselhos oficiais de prevenção, remediação e resposta, e os clientes da Sophos podem acompanhar os nomes de detecção de ameaças usados ​​por nossos produtos, por meio do feed do Sophos X-Ops no Twitter (@SophosXOps).

Novas informações foram publicadas sobre CVE-2022-41040 e CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

—Sophos X-Ops (@SophosXOps) 21 de novembro de 2022

---

SAIBA MAIS SOBRE AUTENTICAÇÃO DE EXCHANGE E OAUTH2

Com Paul Ducklin e Chester Wisniewski
Música de introdução e final de Edith Mudge.

---