This post is also available in: Português Español
Algumas semanas atrás, pesquisadores relataram à Microsoft, por meio da Zero Day Initiative, duas novas vulnerabilidades de dia zero no Microsoft Exchange Server. E agora, essas duas vulnerabilidades estão sendo exploradas por cibercriminosos.
A Zero Day Initiative (ZDI) é uma iniciativa internacional que visa identificar vulnerabilidades em softwares, que surgiu em 2005 pela TippingPoint, uma divisão da 3Com que foi adquirida pela Trend Micro em 2015.
A descoberta da vulnerabilidade
No início de agosto deste ano, os pesquisadores do GTSC identificaram ataques explorando a falha de dia zero para execução remota de código enquanto realizavam serviços de monitoramento de segurança e resposta a incidentes.
Enquanto realizavam uma investigação, os especialistas do GTSC Blue Team – profissionais de segurança defensiva, determinaram que uma vulnerabilidade de segurança não publicada do Exchange foi utilizada no ataque. Ou seja, uma vulnerabilidade de dia zero.
O Blue Team apresentou um plano de contenção temporário, enquanto o Red Team pesquisava e depurava o código descompilado do Exchange para encontrar a vulnerabilidade e explorar o código.
A falha descoberta é tão grave que permite que o invasor faça RCE no sistema comprometido. A GTSC encaminhou a vulnerabilidade para a ZDI para que a Microsoft pudesse lançar um patch de correção o mais breve possível.
A ZDI está rastreando os bugs como ZDI-CAN-18802 e ZDI-CAN-1833. Enquanto a CVE as rastreia como CVE-2022-41040 e CVE-2022-41082, com pontuação 8,8 e 6,3.
Exploração das falhas
A GTSC divulgou apenas alguns detalhes relacionados às falhas de dia zero. Preferindo não divulgar detalhes técnicos por enquanto.
O Blue Team revelou que as solicitações usadas na cadeia de exploração são semelhantes às utilizadas em ataques direcionados às falhas do ProxyShell.
autodiscover/autodiscover.json?@evil.com/
Ao verificar outros logs, o Blue Team notou que o invasor pode executar comandos no sistema atacado.
Segundo os pesquisadores, a versão mais recente do Exchange já havia sido instalada, e por conta disso era impossível realizar uma exploração usando a vulnerabilidade ProxyShell. Com isso, o Blue Team pode confirmar que era uma nova vulnerabilidade RCE de dia zero.
Pós exploração
Os pesquisadores notaram que os invasores encadearam as falhas de dia zero para contaminar servidores, possibilitando roubo de dados e movimentação lateral comprometendo outros sistemas nas redes.
Segundo os pesquisadores, um grupo de ameaças chinês está por trás desses ataques recentes. A suspeita é motivada pelo fato da codificação de caracteres da página do webshell ser 936, uma codificação da Microsoft para chinês simplificado.
Além disso, o agente empregado para instalar os webshells pertence a uma ferramenta de administração de código aberto baseada na China, com suporte para gerenciamento de web shell, identificada como Antsword.
Mitigação
Até que os patches de atualizações e segurança sejam lançados para resolver os dois dias zero, a Microsoft compartilhou algumas dicas para mitigação.
Os clientes de Exchange Server devem concluir a mitigação da regra de reconfiguração de URL para CVE-2022-41040 e a mitigação de desabilitar o PowerShell remoto para não administradores para CVE-2022-41082 descrita abaixo.
Os clientes do Exchange Online não precisam realizar nenhuma ação.
Regra de reescrita de URL
A mitigação atual do Exchange Server é adicionar uma regra de bloqueio em “IIS Manager > Default Web Site > URL Rewrite > Actions” para bloquear os padrões de ataques conhecidos.
Os clientes do Exchange Server devem revisar e usar uma dessas opções.
- Opção 1:
- Opção 2:
- Opção 3:
- 1. Abra o “Gerenciador do IIS”;
- 2. Selecione o “Site padrão”;
- 3. Na exibição de “Recurso”, clique em “Reescrever URL”;
- 4. No “painel ações”, no lado direito, clique em “adicionar regras…”;
- 5. Selecione “bloqueio de solicitação” e clique em OK;
- 6. Adicione a string “(?=.*autodiscover)(?=.*powershell)”;
- 7. Selecione “Expressão Regular” em “Usando”;
- 8. Selecione “abortar solicitação” em “como bloquear” e clique em ok;
- 9. Expanda a regra e selecione a regra com o padrão: (?=.*autodiscover)(?=.*powershell) e clique em “Editar” em “Condições”;
- 10. Altere a entrada condição de {URL} para {UrlDecode:{REQUEST_URI}} e clique em OK.
Para clientes que têm o Serviço de Mitigação de Emergência do Exchange (EEMS) habilitado, a Microsoft lançou a mitigação de reescrita de URL para Exchange Server 2016 e Exchange Server 2019.
A mitigação é habilitada automaticamente e é atualizada para incluir os aprimoramentos da regra de reescrita de URL.
a Microsoft criou o script EOMTv2 para as etapas de mitigação de regravação de URL e o atualizou para incluir os aprimoramentos da regra de regravação de URL.
O script EOMTv2 será atualizado automaticamente em máquinas conectadas à Internet e a versão atualizada será exibida como 22.10.07.2029. Ele deve ser executado novamente em qualquer Exchange Server sem o EEMS habilitado.
Os clientes podem seguir as seguintes instruções:
Caso você precise alterar alguma regra, é melhor excluí-la e recriá-la.
A Microsoft informa que não há efeito conhecido na funcionalidade do Exchange se a reconfiguração de URL for instalada conforme recomendado.
Desabilitar o acesso remoto do PowerShell
Os clientes do Exchange Server devem desativar o acesso remoto ao PowerShell para usuários não administradores em sua organização.
Acessando este link do site da Microsoft, você encontrará as orientações necessárias sobre como fazer isso.
A Microsoft e os pesquisadores recomendam a todas as organizações em todo o mundo que utilizam o Microsoft Exchange Serve, que verifiquem, revisem e apliquem soluções temporárias de mitigação o mais rápido possível para evitar possíveis danos graves.
Fontes: Zero Day Initiative, GTSC, Microsoft.
This post is also available in: Português Español
