Cadeia combinava carregamento remoto de modelos sem validação adequada e um serviço interno sem autenticação para expor metadados e imagens de máquinas de locatários e da infraestrutura.
| Componente | Azure Stack, incluindo portal de usuário, Azure Resource Manager, Service Fabric Applications, DataService e Compute Cluster Manager no ambiente ASDK analisado. |
| Vetor | SSRF por carregamento remoto de template via URL no portal, com requisição HTTP GET encaminhada a serviço interno acessível sem autenticação. |
| Impacto | Consulta de informações de máquinas virtuais de infraestrutura e de locatários, incluindo identificadores, nomes, características de hardware e captura de tela por função de thumbnail do Hyper-V. |
| Prioridade | Aplicar atualizações do Azure Stack, revisar exposição de APIs internas, restringir chamadas do portal para endereços internos e auditar acessos anômalos a rotas de template e serviços de controle. |
| Versões | A falha de API interna sem autenticação foi tratada no Azure Stack 1811; a vulnerabilidade de SSRF foi divulgada e corrigida pela Microsoft. |
| Artefatos | CVE-2019-1234, DataService, VirtualMachineScreenshot, QueryVirtualMachineInstanceView, Compute Cluster Manager, Get-CpiVmThumbnail e chamada WMI GetVirtualSystemthumbnailImage. |
A pesquisa descreve uma cadeia de vulnerabilidades no Azure Stack em que uma função legítima do portal podia ser abusada para alcançar serviços internos e extrair dados de máquinas virtuais. O ambiente analisado foi o Azure Stack Development Kit, uma implantação local baseada em Hyper-V que reproduz componentes essenciais do Azure Stack para uso empresarial e testes. A arquitetura separa camadas como portal, Azure Resource Manager, provedores de recursos, controladores de infraestrutura e papéis responsáveis por computação, rede e armazenamento. O problema técnico não estava em uma aplicação de cliente hospedada na nuvem, mas em componentes de infraestrutura e no caminho de comunicação entre camadas internas do próprio ambiente.
A cadeia dependia de dois pontos principais. O primeiro era o carregamento remoto de templates pelo portal de usuário, que aceitava uma URL e fazia uma requisição HTTP GET para buscar o conteúdo. A implementação descrita não validava adequadamente se o destino era interno ou externo e ainda aceitava IPv6, criando uma condição de SSRF. O segundo era a existência de um serviço interno chamado DataService, executado na camada associada a provedor de recursos e controle de infraestrutura, que expunha rotas sem autenticação. Quando esses dois comportamentos eram combinados, um usuário capaz de acionar o carregamento remoto de template podia fazer o portal consultar endpoints internos que não deveriam estar disponíveis a locatários.
O impacto confirmado foi a obtenção de informações sobre máquinas virtuais e a captura de imagens equivalentes a telas de VMs por meio de uma funcionalidade interna de thumbnail. A rota de alocação de máquinas virtuais retornava dados em XML ou JSON, dependendo do cabeçalho de aceitação, incluindo nomes, identificadores e características como núcleos e memória. Outra rota, associada a screenshots, encaminhava a requisição para o Compute Cluster Manager, que localizava o nó proprietário da máquina virtual e acionava uma rotina de coleta de imagem baseada em Hyper-V. A correção foi tratada pela Microsoft após comunicação ao MSRC; a falha de API interna sem autenticação já havia sido endereçada separadamente na atualização Azure Stack 1811, e a vulnerabilidade de SSRF recebeu o identificador CVE-2019-1234.
O fluxo começa no portal de usuário do Azure Stack, uma interface usada por locatários para criar e administrar recursos. Esse portal conversa com o Azure Resource Manager, que decide se uma requisição pode ser tratada diretamente ou se precisa ser encaminhada a provedores de recursos. Abaixo dessa camada ficam serviços internos e controladores que operam recursos de computação, rede e armazenamento. No ASDK, esses papéis são distribuídos em máquinas virtuais separadas sobre Hyper-V, com redes virtuais próprias. Essa segmentação cria uma expectativa de que serviços de controle não sejam alcançáveis diretamente por usuários comuns, mas a SSRF altera o ponto de origem da requisição: em vez de o locatário falar diretamente com a rede interna, o próprio portal faz a chamada em seu nome.
O recurso de carregamento remoto de template era suficiente para a etapa de SSRF porque ele buscava uma URL informada e retornava o conteúdo como JSON. Mesmo limitado a GET, o comportamento bastava para atingir rotas internas do DataService que também respondiam a GET. A pesquisa identificou que algumas APIs listadas por meio do Service Fabric Explorer não exigiam autenticação, embora normalmente se esperasse autenticação por certificado ou por HTTP em serviços desse tipo. Como o código-fonte dos serviços não era público, a análise envolveu engenharia reversa de bibliotecas C# para mapear controladores e rotas REST. Essa etapa revelou endpoints que não exigiam parâmetros difíceis de descobrir e rotas que aceitavam identificadores de máquinas virtuais.
Uma rota de inventário, associada a QueryVirtualMachineInstanceView, retornava um conjunto amplo de informações sobre máquinas virtuais presentes no nó Hyper-V. Esses dados podiam servir como base para identificar alvos e preencher parâmetros exigidos por chamadas posteriores. A rota VirtualMachineScreenshot exigia parâmetros como identificação da máquina virtual e dimensões da imagem. Quando os parâmetros eram válidos, o serviço repassava a operação a outro componente interno, o Compute Cluster Manager, localizado na camada de controle de infraestrutura. Esse componente determinava em qual nó do cluster a VM residia e executava a coleta de thumbnail por uma rotina PowerShell interna que chamava a função WMI do Hyper-V para obter a imagem da máquina virtual.
Embora a função original fosse apresentada como thumbnail, a possibilidade de especificar dimensões tornava o resultado comparável a uma captura de tela útil. O ponto crítico é que o invasor não precisava receber execução arbitrária de código no host para obter impacto sensível; bastava acionar funcionalidades administrativas já existentes por um caminho indevido. A cadeia ilustra um padrão recorrente em ambientes de nuvem e appliance: uma API interna desenhada para confiança entre componentes pode se tornar exposta quando outra função aceita destinos controlados pelo usuário e não bloqueia endereços internos, loopback, ranges privados ou formatos alternativos de endereçamento.
A superfície afetada envolve implantações de Azure Stack em que o portal de usuário tinha capacidade de buscar templates remotos sem filtragem adequada e em que serviços internos como DataService podiam ser acessados sem autenticação. O contexto analisado foi o ASDK, mas a lógica descrita pertence a componentes centrais do Azure Stack: portal, ARM, provedores de recursos, aplicações Service Fabric, controladores de infraestrutura e papéis de computação sobre Hyper-V. Os ativos expostos incluíam máquinas virtuais de locatários e máquinas de infraestrutura, porque a API de alocação retornava informações sobre ambos os tipos no nó do cluster.
A precondição prática era a capacidade de interagir com a função de template remoto do portal. A partir desse ponto, a requisição saía de um componente com conectividade interna maior do que a do usuário final. O risco aumentava porque o endpoint vulnerável aceitava apenas GET, mas as APIs internas relevantes também respondiam por GET. Portanto, defesas focadas apenas em bloquear métodos como POST ou PUT não resolveriam o problema. O controle relevante precisava validar destino, autenticar serviço interno e aplicar autorização contextual sobre quais identidades poderiam consultar metadados ou imagens de máquinas virtuais.
- Portal de usuário do Azure Stack com carregamento remoto de templates por URL.
- Serviço interno
DataServiceacessível a partir do caminho alcançável pelo portal. - APIs de Service Fabric Applications expostas sem autenticação esperada.
- Máquinas virtuais de locatários e de infraestrutura listadas no retorno de alocação.
- Ambientes sem atualização Azure Stack 1811 para a falha interna citada no contexto.
A investigação defensiva deve se concentrar em sinais de abuso do recurso de template remoto e em chamadas internas incomuns para serviços de controle. Em logs do portal, procure requisições de carregamento de template apontando para destinos internos, endereços privados, loopback, IPv6 local, nomes de host de infraestrutura ou padrões que não correspondam a repositórios corporativos aprovados. Como o vetor usa GET, a ausência de métodos de escrita não deve ser tratada como evidência de baixo risco. O sinal relevante é a tentativa de fazer o portal atuar como cliente HTTP para destinos que um locatário não deveria conseguir alcançar.
No lado de serviços internos, eventos de acesso a rotas de DataService podem indicar enumeração de máquinas virtuais ou tentativa de captura de imagem. Consultas a endpoints de alocação, chamadas relacionadas a VirtualMachineScreenshot e acionamentos incomuns do Compute Cluster Manager devem ser correlacionados com identidade do usuário no portal, endereço de origem, horário e recurso que disparou a chamada. Em hosts Hyper-V e camadas de controle, eventos de coleta de thumbnail fora de fluxos administrativos esperados também merecem revisão. A detecção ganha força quando combina telemetria de portal, logs de aplicação Service Fabric, auditoria de ARM e registros operacionais dos nós de computação.
Como a cadeia não depende de malware nem de payload executável entregue ao endpoint do usuário, ferramentas tradicionais de EDR podem não enxergar o fluxo completo se não houver integração com logs de plataforma. A visibilidade precisa incluir trilhas de requisições HTTP internas, decisões de roteamento do ARM, identificação de templates carregados por URL e chamadas administrativas de computação. Um alerta de alta fidelidade pode ser construído quando uma mesma sessão de locatário faz carregamento remoto de template para destino interno e, em seguida, há acesso a APIs de inventário ou screenshot que retornam metadados de VMs.
- URLs de template remoto apontando para redes internas, loopback, IPv6 local ou nomes de infraestrutura.
- Chamadas GET para rotas de
DataServiceoriginadas do portal em contexto de usuário locatário. - Consultas anômalas a
QueryVirtualMachineInstanceViewou rotas equivalentes de inventário de VMs. - Acionamentos de
VirtualMachineScreenshotcom dimensões incomuns ou fora de rotinas administrativas. - Eventos do Compute Cluster Manager relacionados a coleta de thumbnail sem operação legítima correspondente.
A prioridade é garantir que o Azure Stack esteja atualizado com as correções disponibilizadas pela Microsoft, incluindo o tratamento da falha interna sem autenticação citado para Azure Stack 1811 e a correção da SSRF identificada como CVE-2019-1234. A mitigação estrutural exige duas linhas de defesa independentes: o portal não deve buscar destinos internos controlados pelo usuário, e serviços internos não devem confiar apenas na posição de rede como prova de legitimidade. Mesmo que a SSRF seja corrigida, uma API administrativa sem autenticação permanece perigosa diante de outros caminhos de acesso interno, erros de roteamento, proxies, integrações ou futuras vulnerabilidades.
Equipes responsáveis por ambientes Azure Stack devem revisar políticas de egress do portal, allowlists para carregamento de templates, bloqueio de faixas privadas e validação de formatos de endereço que possam contornar filtros simples. Também é necessário exigir autenticação e autorização em APIs internas, com identidade de serviço, escopo mínimo e verificação de finalidade da chamada. Para endpoints que retornam metadados de máquinas virtuais ou imagens de console, a resposta deve ser restrita ao contexto administrativo apropriado e registrada de forma auditável. Em ambientes onde a exploração possa ter ocorrido, a resposta deve incluir revisão de logs históricos, inventário de contas que usaram templates remotos e checagem de acessos a rotas internas sensíveis.
A validação pós-correção deve testar explicitamente tentativas defensivas de SSRF contra destinos internos controlados em laboratório, sem publicar payloads ou comandos operacionais. O objetivo é confirmar que o portal rejeita endereços internos, que o serviço interno exige autenticação e que chamadas a screenshots de VMs ficam limitadas a fluxos autorizados. Também é recomendável documentar os caminhos legítimos de administração que acessam Compute Cluster Manager e funções de thumbnail, porque essa linha de base reduz falsos positivos e ajuda a distinguir operação normal de abuso.
- Atualizar Azure Stack para versões que incluam as correções citadas para a API interna e para
CVE-2019-1234. - Bloquear carregamento remoto de templates para destinos internos, loopback, metadados locais e endereços privados.
- Aplicar autenticação forte e autorização contextual em APIs internas como
DataService. - Registrar e auditar chamadas de inventário e screenshot de máquinas virtuais, associando usuário, sessão e origem.
- Revisar logs de portal, Service Fabric, ARM e Hyper-V para sinais históricos de enumeração ou captura indevida.
0 Comentários