Falha no Azure App Service permitia execução como SYSTEM a partir de processo de trabalhador

A vulnerabilidade estava no serviço DWASSVC e explorava uma inconsistência de tamanho em mensagens enviadas por pipe nomeado entre processos do Azure App Service.

Componente	Azure App Service, com foco no serviço DWASSVC, na biblioteca DWASInterop.dll, em processos w3wp.exe e na comunicação por pipe nomeado usada para controle de trabalhadores.
Vetor	Código executado no contexto de uma aplicação de locatário poderia abusar de um handle já aberto para um pipe nomeado e enviar uma mensagem manipulada diretamente ao serviço de gerenciamento.
Impacto	A falha resultava em estouro de heap no processamento de mensagens e permitia execução de código como NT AUTHORITY/SYSTEM no cenário local analisado.
Prioridade	Ambientes que operam App Service ou componentes equivalentes devem validar correções da plataforma, revisar isolamento de locatários, monitorar uso anômalo de pipes e investigar processos de trabalhador que carregam bibliotecas nativas incomuns.
Artefatos	Componentes citados incluem DWASSVC, DWASInterop.dll, Microsoft.Web.Hosting.ProcessModel.dll, RsFilter.sys, RsHelper.dll, w3wp.exe, Kudu, WorkerItem, IPM_MESSAGE_IMP e o caminho especial D:\home.
Limite	O contexto descreve uma vulnerabilidade de execução local dentro da arquitetura do App Service; não há indicação fornecida de exploração ativa, CVE, pontuação CVSS, versão afetada, campanha ou ator.

Resumo técnico

A análise descreve uma vulnerabilidade crítica na infraestrutura do Azure App Service, concentrada no caminho de comunicação entre processos de trabalhador e o serviço responsável por gerenciar a execução das aplicações. O App Service é apresentado como uma plataforma para hospedar aplicações web, back ends móveis e APIs REST sem que o locatário administre diretamente a infraestrutura. Essa abstração depende de uma arquitetura com múltiplas funções internas: controlador, camada de gerenciamento com API e portais, roteamento frontal, publicação por FTP e Web Deploy, armazenamento de conteúdo e servidores de aplicação que executam o código dos locatários.

O ponto central da falha está no componente DWASSVC, que inicia trabalhadores IIS e mantém comunicação com eles por meio de pipes nomeados. Em condições normais, cada aplicação de locatário pode ter processos separados para Kudu e para a aplicação propriamente dita, ambos executados sob o mesmo usuário de baixa permissão. A vulnerabilidade rompe essa expectativa de isolamento porque um processo de aplicação, já dentro do contexto do trabalhador, poderia alcançar um handle de pipe aberto e enviar uma mensagem construída fora do fluxo esperado das APIs internas. O processamento incorreto dessa mensagem gerava um estouro de heap com conteúdo e tamanho controlados, levando à execução de código como NT AUTHORITY/SYSTEM no cenário analisado.

A falha não é descrita como uma invasão remota direta contra uma URL pública da aplicação. O vetor depende de execução prévia dentro do contexto da aplicação de locatário, como uma função ou código hospedado no próprio App Service. O impacto, porém, é relevante para ambientes multilocatários e para operadores de nuvem porque o salto de um processo de baixa permissão para SYSTEM no trabalhador ameaça o modelo de contenção que separa código de locatário da camada de infraestrutura.

Fluxo técnico

O App Service usa uma arquitetura conhecida internamente como Antares para executar aplicações de locatários. A execução ocorre em máquinas de trabalhador web, onde processos IIS w3wp.exe são criados para hospedar Kudu e a aplicação. O serviço DWASSVC participa dessa criação e, antes de iniciar um novo trabalhador, cria um pipe nomeado para comunicação de controle. O nome desse pipe é passado ao processo por um parâmetro de inicialização, permitindo que o trabalhador se conecte ao canal logo após ser criado.

A comunicação por esse pipe implementa mensagens de controle entre trabalhador e serviço. Um exemplo funcional é o pedido de encerramento ordenado de um trabalhador, usado para evitar finalizações abruptas. A parte vulnerável aparece no processamento de uma estrutura de mensagem referida como WorkerItem. O objeto interno IPM_MESSAGE_IMP mantém um ponteiro para o item recebido e um campo com o tamanho total da mensagem, enquanto a própria estrutura da mensagem também contém um comprimento específico para os dados. Em fluxos legítimos, esses valores são calculados por APIs exportadas de bibliotecas internas, o que mantém consistência entre o tamanho total e o tamanho do conteúdo.

O problema ocorre quando uma mensagem é enviada diretamente ao pipe e não passa pela lógica que preserva a consistência esperada. Durante uma realocação, o código aloca um novo item com base no campo de comprimento dos dados, mas copia bytes usando o tamanho total da estrutura. Se o comprimento de dados for menor que o tamanho total da mensagem, a cópia ultrapassa a área alocada. O contexto descreve esse caso como um estouro de heap em DWASInterop.dll, com controle sobre conteúdo e tamanho, porque o emissor da mensagem influencia os campos usados no cálculo.

O caminho de exploração descrito parte de uma aplicação C# hospedada no App Service. Como esse código roda no contexto do trabalhador w3wp.exe, ele pode observar handles já abertos no processo e localizar o pipe usado para a comunicação com DWASSVC. A partir desse ponto, a mensagem manipulada é enviada pelo canal existente. O detalhe operacional da carga e da invocação de código nativo deve ser tratado apenas como informação de risco: defensivamente, o dado importante é que carregamento de DLL nativa por uma função, interação incomum com handles de pipe e comportamento anômalo do trabalhador são sinais de alta prioridade para investigação.

Superfície afetada

A superfície principal é o plano de execução do Azure App Service, especialmente os hosts de aplicação que executam código de locatário em processos IIS. O contexto também cita Azure Stack como parte da linha de pesquisa, pois a arquitetura do App Service pode ser estudada em ambiente estendido e offline. A matéria, entretanto, descreve o impacto sobre o Azure Cloud a partir de um componente do App Service, não um problema genérico de todas as cargas Azure.

A presença de mecanismos de sandbox mostra que a arquitetura já tenta reduzir o alcance do código do locatário. O driver RsFilter.sys acompanha criação e remoção de processos, mantém estruturas como ProcessInfo e SandboxSettings, aplica substituições de caminhos e impõe limites de sistema de arquivos. O caminho D:\home, por exemplo, é resolvido dinamicamente para um compartilhamento UNC associado ao armazenamento da aplicação por meio de configuração definida no início do trabalhador. Esse mesmo modelo contém filtros de rede, como restrições de portas, controle de conexões, bloqueio de sockets brutos e listas de intervalos permitidos.

Outro componente relevante é RsHelper.dll, carregado pelos processos IIS de trabalhador. Ele intercepta funções de bibliotecas do Windows, incluindo rotinas de criação de processos, e injeta a própria DLL em processos filhos para manter controles da sandbox. Esse comportamento é legítimo dentro da plataforma, mas tem valor para defesa porque cria uma linha de base: trabalhadores esperados carregam módulos específicos do App Service, e desvios como bibliotecas nativas inesperadas, filhos de processo fora do perfil da aplicação ou comunicação incomum com pipes internos devem ser analisados com prioridade.

A vulnerabilidade não exige que o invasor controle o serviço DWASSVC diretamente no início. A pré-condição crítica é a capacidade de executar código no contexto da aplicação hospedada. Isso inclui cenários em que o próprio locatário executa código malicioso, uma aplicação foi comprometida, um pipeline pública artefato indevido ou uma função serverless contém lógica abusiva. O risco cresce quando o ambiente permite carregamento de código nativo, quando não há telemetria de integridade dos trabalhadores e quando eventos do host são tratados como opacos pela equipe responsável pela carga.

• Serviço DWASSVC e biblioteca DWASInterop.dll no caminho de criação e controle de trabalhadores.
• Processos w3wp.exe usados por Kudu e pela aplicação do locatário.
• Comunicação por pipe nomeado entre trabalhador e serviço de gerenciamento.
• Driver RsFilter.sys e estruturas de sandbox associadas a processos de locatário.
• Carregamento de RsHelper.dll e interceptação de funções de criação de processo como parte do isolamento da plataforma.

Hunting e telemetria

A investigação defensiva deve começar pela relação entre processos de aplicação, pipes nomeados e carregamento de módulos. Em um ambiente instrumentado, é relevante correlacionar criação de trabalhadores w3wp.exe, parâmetros de inicialização que apontam para canais de comunicação internos, abertura de handles e tentativas de escrita em pipes que normalmente são usados apenas pelo fluxo controlado da plataforma. Como a falha depende de mensagem enviada diretamente, a anomalia esperada é o trabalhador atuando como emissor de conteúdo fora do padrão para um canal que deveria obedecer ao protocolo interno.

No endpoint, eventos de carregamento de DLL por aplicações C# ou funções hospedadas merecem análise quando não fazem parte do comportamento normal da carga. O contexto indica que a prova técnica usou uma função C# para carregar uma biblioteca nativa e acionar a lógica necessária. Em defesa, isso não deve ser convertido em regra simples contra todo uso de DLL nativa, porque aplicações legítimas podem depender de código nativo. A abordagem mais útil é combinar reputação do artefato, caminho de origem, momento da publicação, identidade do processo, relação pai-filho e tentativa de interação com handles herdados ou já abertos.

Logs de infraestrutura também devem observar reinicializações inesperadas de trabalhadores, falhas de heap, travamentos de DWASSVC, mensagens de exceção em módulos de hospedagem, mudanças incomuns em contadores de processos e comportamento fora do perfil de Kudu. Em ambientes onde o operador tem visibilidade de kernel ou EDR no host, callbacks de criação de processo, operações de arquivo mediadas por RsFilter.sys e conexões bloqueadas por filtros de rede podem ajudar a reconstruir a linha do tempo. O objetivo não é procurar um payload específico, mas identificar o encadeamento: código de locatário, carregamento de módulo incomum, acesso a handle interno, mensagem anômala e instabilidade ou elevação subsequente.

• Processos w3wp.exe com carregamento de bibliotecas nativas não esperadas para a aplicação publicada.
• Interação incomum de código hospedado com handles de pipe nomeado associados ao controle de trabalhador.
• Falhas, reinicializações ou travamentos próximos a eventos de comunicação entre trabalhador e DWASSVC.
• Criação de processos filhos a partir do trabalhador fora do perfil operacional da aplicação.
• Mudanças em telemetria de sandbox envolvendo limites de processo, acesso a D:\home, substituições de caminho e bloqueios de rede.

Mitigação

A correção efetiva para a falha descrita pertence ao plano de plataforma, porque o erro está em componente interno de gerenciamento do App Service. Em ambientes consumidos como serviço gerenciado, a prioridade operacional é confirmar que a plataforma está atualizada e que eventuais comunicações do provedor sobre correções foram aplicadas. Em ambientes que operam componentes equivalentes em Azure Stack ou infraestrutura controlada localmente, a validação deve incluir versões dos componentes de App Service, integridade de DWASSVC, bibliotecas relacionadas e reinicialização coordenada dos trabalhadores depois da atualização.

Enquanto a correção estrutural é tratada, a contenção deve reduzir a chance de código de locatário abusar do contexto do trabalhador. Isso inclui revisar quem pode publicar aplicações, funções e artefatos nativos; exigir controle de mudanças em pipelines de implantação; auditar integrações de GitHub, Azure DevOps ou repositórios Git; e bloquear publicações que adicionem módulos nativos sem justificativa técnica. Para cargas críticas, a equipe deve comparar o inventário esperado de módulos com o observado em tempo de execução e investigar qualquer adição repentina.

A resposta a um alerta compatível com esse cenário deve preservar evidências do processo de trabalhador, módulos carregados, handles relevantes, logs de implantação e eventos de controle do App Service. Se houver suspeita de abuso, a aplicação deve ser isolada, credenciais associadas à publicação devem ser rotacionadas e pipelines devem ser revisados para descartar artefatos introduzidos por conta comprometida. Como o contexto não fornece IoCs de infraestrutura, CVE ou versões afetadas, a defesa deve se apoiar em comportamento e integridade, não em listas estáticas de indicadores.

Também é importante revisar limites de confiança internos. A falha nasce de uma suposição de que mensagens recebidas pelo pipe seriam sempre geradas por bibliotecas legítimas, com tamanhos coerentes. Para engenharia de plataforma, a lição defensiva é validar campos redundantes no ponto de consumo, recusar mensagens inconsistentes antes de realocar memória e aplicar testes negativos em protocolos internos. Para equipes de segurança, a prioridade é tratar canais internos de IPC como superfície de ataque quando código não confiável compartilha o mesmo processo, sessão ou conjunto de handles.

• Confirmar aplicação de atualizações da plataforma App Service ou dos componentes equivalentes em ambientes administrados pelo operador.
• Auditar permissões de publicação e integrações de implantação que permitem introduzir código C#, artefatos nativos ou extensões de aplicação.
• Monitorar trabalhadores w3wp.exe para carregamento inesperado de DLLs, criação de processos filhos e comunicação anômala com pipes internos.
• Preservar evidências de processo, módulos, logs de implantação e eventos de falha antes de reciclar instâncias suspeitas.
• Revisar validação de protocolos internos para rejeitar mensagens com divergência entre tamanho total e tamanho de dados antes de qualquer cópia em memória.