CVE-2019-1405

Falha de elevação de privilégio local no serviço Windows UPnP (Universal Plug and Play), que permite instanciação indevida de um objeto COM. Um processo com privilégios baixos já autenticado na máquina pode abusar dessa criação de objeto para obter execução com privilégios de sistema. O CVSS 7.8 reflete corretamente que não é uma falha remota: o pré-requisito é acesso local já estabelecido, e por isso ela importa sobretudo como etapa de pós-exploração, não como vetor de entrada.

A descrição oficial da Microsoft é direta: o serviço UPnP do Windows permite de forma inadequada a criação de um objeto COM. Serviços Windows que expõem interfaces COM acessíveis a usuários pouco privilegiados e que executam com token de sistema ou de conta de serviço elevada são um padrão clássico de escalonamento local (CWE relacionado a controle de acesso/gerenciamento impróprio de privilégios) — o processo chamador controla os parâmetros da chamada COM, e o serviço, ao processá-la, executa ação com privilégio superior ao do chamador sem validação suficiente de quem está solicitando.

O vetor CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H confirma isso: AV:L (ataque só é possível localmente), PR:L (o atacante precisa de privilégio baixo — uma conta de usuário padrão já autenticada na máquina), UI:N (não precisa de interação de outro usuário), e AC:L (baixa complexidade de exploração uma vez satisfeitas as condições). O impacto é total em confidencialidade, integridade e disponibilidade porque o resultado final é execução com privilégios elevados no host.

Não apuramos, a partir das fontes lidas, o detalhamento interno de qual DLL ou interface COM específica do UPnP (por exemplo o serviço associado a fdrespub/SSDP) é o ponto exato de abuso, nem o nome técnico da classe COM envolvida — a Microsoft não publica esse nível de detalhe no advisory, e não tivemos acesso ao conteúdo integral da análise do PacketStorm/Metasploit para confirmar esses pontos com segurança.

A exploração exige que o atacante já tenha uma sessão local na máquina Windows afetada, com uma conta de usuário padrão (baixo privilégio) — não é exploração remota nem depende de interação de outro usuário. Isso posiciona a falha como ferramenta de escalonamento pós-comprometimento: útil depois que um invasor já obteve um shell ou acesso via phishing, exploração de outra falha, ou credenciais de baixo privilégio, e precisa virar administrador/SYSTEM na máquina.

Existem PoC pública (catalogada no PacketStorm) e módulo Metasploit conhecidos, o que reduz a barreira técnica para quem já tem o pré-requisito de acesso local — a exploração em si, uma vez com esse acesso, é considerada de baixa complexidade (AC:L). A CISA incluiu a CVE no catálogo KEV (adicionada em 15/03/2022, com prazo de correção até 05/04/2022), o que confirma exploração observada em ambientes reais, embora o registro da CISA não detalhe campanhas, grupos de ameaça ou o vínculo com ransomware de forma inequívoca — o campo correspondente na entrada consultada não trouxe informação clara e não deve ser tomado como confirmação.

O resultado final de uma exploração bem-sucedida é execução de código com privilégios de sistema na máquina local, o que normalmente é o passo que precede movimento lateral, dump de credenciais ou persistência.

A mitigação primária é aplicar a atualização de segurança da Microsoft referente a esta CVE, publicada no ciclo de novembro de 2019. Não localizamos, nas fontes consultadas, o número exato do KB/atualização de segurança nem a lista completa e oficial de todas as versões afetadas do Windows além das listadas nos metadados fornecidos — por isso não vamos citar um número de patch específico; confirme a atualização exata pelo MSRC ou pelo Windows Update/WSUS para a versão de build em uso.

Como controle compensatório quando a atualização não pode ser aplicada de imediato, a recomendação genérica da CISA no KEV é 'aplicar atualizações conforme instrução do fornecedor' — não há paliativo de configuração (desabilitar UPnP, por exemplo) confirmado pelas fontes lidas como mitigação eficaz específica para esta falha; desativar o serviço UPnP reduz superfície de ataque em geral, mas não temos confirmação de que isso neutraliza especificamente este bug, então trate como redução de risco, não como correção equivalente ao patch.

O que não funciona: como o vetor é local e a falha está na lógica de criação do objeto COM dentro do serviço, controles de rede (firewall, segmentação, WAF) não mitigam a exploração — o problema só é alcançável por quem já está na máquina. Reduzir contas com logon interativo padrão e aplicar princípio de menor privilégio ajuda a limitar quem tem o pré-requisito PR:L, mas não substitui o patch.

Como a exploração é estritamente local e envolve chamada a um objeto COM do serviço UPnP a partir de um processo de usuário comum, o sinal mais relevante é telemetria de endpoint (EDR/Sysmon) mostrando um processo de baixo privilégio instanciando ou interagindo com componentes do serviço UPnP (associado a fdrespub/SSDP Discovery) seguido de criação de processo ou handle com token de privilégio elevado — divergência entre o privilégio do processo pai e o do processo/thread resultante é o indicador clássico de escalonamento local via COM. Não apuramos, nas fontes consultadas, um IOC específico (nome de arquivo, hash, ou string de PoC) publicado para esta CVE em particular, e a existência de módulo Metasploit sugere que a exploração pode variar de execução para execução, o que reduz a confiabilidade de uma assinatura estática única — trate a ausência de sinal fixo como informação relevante para a defesa.