CVE-2015-0016
Patch now. It under exploitation confirmed by CISA and has a working public exploit.
Apply updates per vendor instructions.
Summary
Falha de directory traversal (CWE-22) no componente TS WebProxy (TSWbPrxy.exe) do Windows, que permite a um processo rodando em Low Integrity (como o Internet Explorer em Protected Mode) escapar do sandbox e alcançar Medium Integrity. Não é uma RCE remota clássica apesar do texto da Microsoft dizer 'remote attackers' — é uma escalação de privilégio local que depende de execução de código prévia dentro de um sandbox e de interação do usuário. Importa porque foi usada como peça de encadeamento em exploit chains contra o IE e está no catálogo KEV da CISA com exploração confirmada.
Technical detail
O TSWbPrxy (TS WebProxy) é o processo que hospeda RemoteApps do Terminal Services/RDS quando lançadas via navegador, atuando como broker entre o IE e a execução de aplicações RemoteApp. O bug está na forma como o componente sanitiza o nome de caminho (pathname) do executável que ele é instruído a lançar: um caminho malformado com sequências de traversal permite escapar do diretório restrito esperado e apontar para um binário arbitrário.
Como o TSWbPrxy roda com nível de integridade superior ao do processo que o invoca (o IE em Protected Mode roda em Low Integrity), o traversal permite que código controlado por um atacante, já em execução dentro do sandbox de baixa integridade, force o lançamento de um executável de sua escolha em Medium Integrity — a transição de integridade que a própria Microsoft usa para descrever a falha ('Directory Traversal Elevation of Privilege Vulnerability').
O atacante controla o pathname passado ao componente em um arquivo executável especialmente criado; a Microsoft corrigiu isso ajustando a sanitização de file paths no componente (KB3025421). Não há, nas fontes analisadas, detalhamento público do código vulnerável linha a linha — o mecanismo documentado é o traversal em si e o resultado (mudança de nível de integridade), não a rotina de parsing específica.
How it’s exploited
O CVSS oficial (AV:L/AC:L/PR:N/UI:R) reflete a realidade prática: é uma escalação local, não uma exploração via rede. O pré-requisito real é ter conseguido executar código em contexto de baixa integridade — tipicamente dentro do sandbox do Internet Explorer (Protected Mode) — e convencer o usuário a rodar uma aplicação especialmente criada, como a própria Microsoft descreve no MS15-004. Por isso a CVE raramente aparece isolada: ela é usada como segundo estágio em uma cadeia de exploração, depois de uma vulnerabilidade inicial de execução de código no navegador ou em outro processo sandboxed.
O resultado da exploração é escapar do isolamento de Low Integrity para Medium Integrity, o que na prática elimina as restrições do Protected Mode do IE e amplia o que o código do atacante pode acessar no sistema — sem, por si só, dar privilégios de administrador.
Existem PoC pública (Exploit-DB 35983 / writeup no Packet Storm baseado no MS15-004) e módulo Metasploit, o que reduz a barreira de reprodução para quem já tem o primeiro estágio (execução em sandbox). A entrada no catálogo KEV da CISA confirma exploração real observada, embora a CISA não classifique a falha como associada a campanhas de ransomware conhecidas.
Versions
How to protect
A correção oficial é aplicar a atualização do boletim MS15-004 (KB3025421), disponível para todas as edições afetadas listadas pela Microsoft. Não há service pack ou versão numerada de substituição — trata-se de patch cumulativo do componente, sem paliativo de configuração documentado pelo fornecedor (o boletim não lista workaround além de instalar a atualização).
Como a falha depende de um estágio anterior de comprometimento (execução em sandbox de baixa integridade), reduzir a superfície de exploits que atingem o Internet Explorer/Protected Mode — isolamento de processo, EMET/mitigações de exploit da época, ou simplesmente descontinuar o uso do IE em sistemas legados — funciona como controle compensatório indireto, mas não corrige a falha em si.
Não funciona como mitigação: desabilitar RDP ou Terminal Services genericamente sem remover/atualizar o componente TSWbPrxy, já que o vetor não é uma sessão RDP direta, e sim o broker de RemoteApp acionado a partir de um processo já em execução no host.
How to detect
As fontes analisadas não descrevem uma assinatura de log ou tráfego confiável para identificar tentativas de exploração — a falha ocorre em uma escalação de privilégio local pós-comprometimento, sem componente de rede a monitorar diretamente. Monitorar a criação de processos filhos anômalos pelo TSWbPrxy.exe (execução de binários fora dos diretórios esperados de RemoteApp) é o indicador mais plausível, mas nenhuma das fontes lidas confirma esse padrão como assinatura validada.