Falha crítica no MSMQ permite execução remota de código sem autenticação pela porta 1801

Falha crítica no MSMQ permite execução remota de código sem autenticação pela porta 1801

A vulnerabilidade CVE-2023-21554, chamada QueueJumper, afeta o serviço Microsoft Message Queuing e pode permitir controle do processo mqsvc.exe quando o MSMQ está habilitado e acessível pela rede.

ComponenteMicrosoft Message Queuing, também conhecido como MSMQ, executado pelo processo de serviço mqsvc.exe em sistemas Windows nos quais o recurso opcional está habilitado.
VetorEnvio remoto e sem autenticação de pacotes para o serviço exposto na porta 1801/tcp, quando o MSMQ está instalado, em execução e aceitando conexões de origem não confiável.
ImpactoA CVE-2023-21554 pode permitir execução remota de código no contexto do processo de serviço mqsvc.exe; outras falhas corrigidas no mesmo ciclo podem causar negação de serviço em nível de aplicação ou no núcleo do Windows.
PrioridadeAplicar a atualização oficial de abril da Microsoft e reduzir a exposição da porta 1801/tcp, especialmente em servidores acessíveis pela Internet ou com funções instaladas automaticamente por outros produtos.
VersõesO MSMQ é um componente opcional ainda disponível em sistemas Windows, incluindo Windows Server 2022 e Windows 11.
ArtefatosServiço Windows chamado Message Queuing, processo mqsvc.exe e escuta de rede na porta 1801/tcp.
MitigaçãoRemover ou desabilitar o MSMQ quando não houver necessidade operacional, instalar o patch oficial e bloquear conexões de entrada para 1801/tcp a partir de redes não confiáveis quando a atualização imediata não for possível.
Resumo técnico

A vulnerabilidade CVE-2023-21554, apelidada de QueueJumper, atinge o Microsoft Message Queuing, serviço de mensageria distribuída do Windows conhecido como MSMQ. O problema foi corrigido na atualização de abril da Microsoft e é o caso mais severo dentro de um conjunto de três falhas identificadas no mesmo componente. A condição crítica é a presença do serviço habilitado e alcançável pela rede, pois o vetor descrito envolve tráfego remoto para a porta 1801/tcp sem autenticação prévia. Quando explorada com sucesso, a falha pode levar à execução de código no contexto do processo de serviço mqsvc.exe, o que torna a exposição do serviço uma superfície de alto impacto em servidores Windows.

O MSMQ não é apenas um recurso histórico abandonado em instalações antigas. Ele continua disponível como componente opcional em sistemas Windows atuais, incluindo Windows Server 2022 e Windows 11, e pode ser ativado como dependência de software que precisa de filas de mensagens. Esse detalhe muda a análise de risco: administradores podem não ter escolhido conscientemente expor o serviço, mas ele pode ter sido habilitado durante a instalação de outro produto. O exemplo citado envolve o instalador do Microsoft Exchange Server, que pode ativar funções e recursos necessários quando a opção de instalação automática é selecionada, deixando o serviço Message Queuing no mesmo servidor.

Fluxo técnico

O fluxo de ataque confirmado para a CVE-2023-21554 depende do acesso ao serviço MSMQ pela porta 1801/tcp. O contexto técnico disponível indica que um pacote enviado ao serviço pode acionar a vulnerabilidade e permitir execução remota de código sem etapa de autenticação. A exploração não deve ser tratada como um problema de credenciais fracas ou de abuso de conta existente; a pré-condição principal é a escuta do serviço vulnerável em uma interface acessível pelo atacante. Isso faz com que regras de firewall, segmentação de rede e inventário de serviços tenham papel direto na redução de risco, além da aplicação do patch.

A execução de código ocorre no contexto do processo mqsvc.exe, o processo do serviço Message Queuing. O impacto concreto descrito é controle do processo vulnerável, não um vazamento de dados confirmado, não uma campanha de exploração ativa documentada e não uma movimentação lateral observada. A consequência operacional, porém, é séria porque o serviço pode estar presente em servidores que acumulam outras funções de negócio. Em um servidor Exchange, por exemplo, a presença simultânea do MSMQ amplia a superfície de ataque da própria máquina, mesmo que a função de fila não seja o serviço principal percebido pela equipe responsável.

As outras duas vulnerabilidades corrigidas no mesmo ciclo ajudam a delimitar a área afetada. A CVE-2023-21769 foi descrita como uma negação de serviço remota e sem autenticação em nível de aplicação, com possibilidade de travamento do serviço. A CVE-2023-28302 foi descrita como negação de serviço remota e sem autenticação em nível de núcleo, com potencial de tela azul do Windows. Essas falhas não têm o mesmo impacto de execução remota de código atribuído à QueueJumper, mas reforçam que o processamento remoto de mensagens pelo MSMQ exposto pode gerar efeitos de disponibilidade e integridade operacional relevantes.

Superfície afetada

A superfície afetada não deve ser medida apenas por instalações explicitamente administradas como sistemas de mensageria. O MSMQ é uma infraestrutura para aplicações distribuídas e desacopladas, com entrega garantida de mensagens, roteamento, suporte a transações, segurança e prioridade de mensagens. Por esse motivo, softwares que dependem dessa infraestrutura podem ativá-la como parte do preparo do sistema. A exposição real nasce da combinação entre componente instalado, serviço em execução, porta 1801/tcp aberta e origem de rede capaz de alcançar o host.

Uma varredura de Internet descrita no material técnico identificou mais de 360 mil endereços IP com a porta 1801/tcp aberta e executando o serviço MSMQ. Esse número representa somente hosts voltados para a Internet e não inclui máquinas internas, onde a quantidade de sistemas com o componente habilitado pode ser maior. Em ambientes corporativos, a presença em redes internas também importa, porque a falha é acionada remotamente e sem autenticação quando o serviço está acessível; segmentação deficiente entre zonas internas pode transformar um componente esquecido em alvo alcançável por tráfego lateral.

A prioridade de inventário deve começar por servidores Windows com funções críticas e por máquinas nas quais instaladores de produtos tenham permissão para adicionar recursos automaticamente. Sistemas Windows Server com Exchange instalado merecem verificação específica quando a instalação foi realizada com a opção de adicionar funções e recursos exigidos pelo assistente. Clientes Windows também podem ter o recurso habilitado, mas a urgência tende a ser maior em servidores expostos, servidores multifunção, ambientes com regras permissivas de entrada e segmentos nos quais a porta 1801/tcp cruza fronteiras de confiança.

  • Hosts Windows com o serviço Message Queuing instalado e em execução.
  • Servidores com a porta 1801/tcp aberta para a Internet ou para redes internas amplas.
  • Instalações em que softwares de terceiros ou produtos Microsoft ativaram o MSMQ como dependência.
  • Ambientes com Windows Server 2022, Windows 11 ou outras versões Windows nas quais o componente opcional foi habilitado.
Hunting e telemetria

A investigação defensiva deve combinar inventário de serviço, escuta de porta e análise de exposição. No host, a presença do serviço Message Queuing em execução é o primeiro sinal operacional. Na rede, a escuta da porta 1801/tcp indica que o serviço está pronto para receber mensagens. Esses dois sinais precisam ser correlacionados com o contexto do ativo: função do servidor, necessidade legítima de filas de mensagens, origem permitida de conexões e existência de patch aplicado. A simples presença do MSMQ não confirma exploração, mas identifica uma superfície que precisa ser justificada.

Em telemetria de rede, conexões inesperadas para 1801/tcp devem receber atenção, principalmente quando vêm de endereços externos, segmentos não autorizados, estáções de usuário ou origens que não fazem parte do desenho da aplicação. Em servidores que executam Exchange ou outras aplicações críticas, a defesa deve procurar tráfego para 1801/tcp que não esteja documentado em fluxos de aplicação. Como os detalhes completos de exploração não foram incluídos no material disponível, a caça não deve depender de assinatura de payload específico; o caminho mais robusto é detectar exposição indevida, tentativas de conexão anômalas e mudanças no comportamento do processo mqsvc.exe.

No endpoint, eventos de ciclo de vida do serviço, reinicializações inesperadas, travamentos e alterações de configuração ajudam a diferenciar administração legítima de atividade suspeita. Para as falhas de negação de serviço, sintomas como queda do serviço Message Queuing ou instabilidade do sistema podem ser relevantes quando associados a tráfego remoto para 1801/tcp. Para a falha de execução remota de código, sinais posteriores no processo mqsvc.exe devem ser tratados com rigor: criação de processos filhos incomuns, conexões de saída inesperadas a partir do serviço, carregamento anormal de módulos e comportamento que não corresponda ao papel normal de fila de mensagens.

  • Serviço Message Queuing presente em ativos que não têm dependência documentada de filas de mensagens.
  • Porta 1801/tcp escutando em interfaces expostas à Internet ou a segmentos internos amplos.
  • Conexões para 1801/tcp vindas de origens não previstas no fluxo da aplicação.
  • Reinicializações, travamentos ou indisponibilidade do serviço Message Queuing após tráfego remoto.
  • Comportamento incomum do processo mqsvc.exe, incluindo processos filhos ou conexões de saída não esperadas.
Mitigação

A mitigação principal é aplicar a atualização oficial de abril da Microsoft que corrige a CVE-2023-21554, a CVE-2023-21769 e a CVE-2023-28302. A correção deve ser priorizada em servidores com MSMQ habilitado e porta 1801/tcp exposta, especialmente quando o host é acessível pela Internet. A etapa seguinte é validar se o serviço é realmente necessário. Quando o recurso não sustenta uma aplicação de negócio, remover ou desabilitar o Message Queuing reduz uma superfície de ataque que pode permanecer despercebida por anos.

Quando o MSMQ é necessário e a aplicação imediata do patch não é viável, a contenção deve restringir conexões de entrada para a porta 1801/tcp a origens confiáveis. Essa medida é apenas uma redução de exposição, não substitui a atualização, porque hosts internos não confiáveis ou caminhos de rede mal segmentados ainda podem alcançar o serviço. Em servidores voltados para a Internet, bloquear 1801/tcp a partir de fontes externas é uma ação defensiva direta enquanto a janela de manutenção é organizada. Em redes internas, a regra deve refletir dependências reais da aplicação e não permitir acesso amplo por conveniência.

Após corrigir, a validação deve confirmar três pontos: versão atualizada, necessidade operacional do componente e ausência de exposição indevida. O inventário precisa registrar quais sistemas mantêm o MSMQ, quais aplicações dependem dele e quais origens de rede podem acessá-lo. Essa documentação evita que o serviço volte a ser tratado como componente invisível instalado por assistentes. A revisão também deve incluir servidores Exchange implantados com instalação automática de funções, porque esse caminho pode ter habilitado o MSMQ sem que a equipe tenha revisado separadamente a porta 1801/tcp como superfície de entrada.

  • Aplicar a atualização oficial de abril da Microsoft nos sistemas Windows com MSMQ habilitado.
  • Verificar se o serviço Message Queuing está instalado, em execução e escutando na porta 1801/tcp.
  • Desabilitar ou remover o MSMQ quando não houver dependência de negócio validada.
  • Bloquear conexões de entrada para 1801/tcp a partir da Internet e de redes não confiáveis.
  • Revisar servidores Exchange e outros sistemas que possam ter ativado o componente durante a instalação.
  • Monitorar o processo mqsvc.exe e o tráfego para 1801/tcp após a correção para confirmar que a exposição foi reduzida.

Postar um comentário

0 Comentários