Drivers vulneráveis no Windows expõem falhas de fronteira entre usuário e núcleo

Análise de drivers WDM assinados mostra que permissões fracas no dispositivo permitem comunicação por usuários sem privilégio e podem viabilizar elevação local quando combinadas com funções sensíveis.

Componente	Drivers WDM de 64 bits assinados para Windows, com destaque para um driver antirrootkit de produtos Dr.Web associado ao artefato dwshield.sys.
Vetor	Comunicação local com o dispositivo do driver por usuário sem privilégio quando a DACL é ausente ou fraca, ou quando IoCreateDeviceSecure é usado sem FILE_DEVICE_SECURE_OPEN.
Impacto	Elevação local de privilégio, leitura e escrita arbitrárias em modo núcleo/usuário e encerramento arbitrário de processos foram confirmados no componente Dr.Web corrigido.
Prioridade	Inventariar drivers assinados acessíveis por usuários sem privilégio, aplicar correções dos produtos afetados e revisar controles de carregamento de drivers contra abuso BYOVD.
Versões	O contexto confirma exploração em Dr.Web Security Space, Dr.Web KATANA e Dr.Web CureIt, sem listar versões específicas.
Artefatos	Nomes observados incluem dwt-6088-1976-26975aba.sys, dwt-2444-2348-9cc4e5df.sys, caminho dwshield_x64.pdb e referência pública BDU:2024-02836.

Resumo técnico

A pesquisa descreve uma classe recorrente de vulnerabilidades em drivers do Windows em que o problema central não é apenas a presença de uma função sensível no binário, mas a quebra da fronteira entre um usuário sem privilégio e operações executadas no modo núcleo. Drivers WDM assinados podem expor objetos de dispositivo com uma DACL ausente, fraca ou incompleta. Quando isso ocorre, processos locais sem privilégio conseguem abrir comunicação com o driver. Se as rotinas internas desse driver oferecem primitivas reutilizáveis para abrir processos, manipular memória, encerrar processos ou acessar objetos privilegiados, a exposição deixa de ser apenas um defeito de configuração e passa a sustentar elevação local de privilégio.

O levantamento partiu de drivers já classificados como vulneráveis em bases públicas defensivas e mostrou que a maioria dos drivers de 64 bits assinados analisados compartilha a característica de aceitar acesso de usuários sem privilégio. Em um conjunto de 924 drivers vulneráveis, assinados e de 64 bits, aproximadamente 90% estavam acessíveis por esse perfil de usuário. Um filtro mais restritivo, que exigia também capacidades de abuso por meio de APIs de núcleo, manteve cerca de 20% desse grupo. A mesma metodologia foi aplicada em busca de drivers ainda não classificados como vulneráveis, resultando em milhares de amostras em risco que precisariam de engenharia reversa e validação manual antes de qualquer conclusão definitiva.

O caso mais concreto apresentado envolve um driver antirrootkit usado por produtos Dr.Web. O componente é um driver de dispositivo de núcleo para Windows, de 64 bits e com assinatura válida, normalmente gravado com nomes variáveis no formato dwt-...sys, enquanto metadados de depuração apontam para dwshield_x64.pdb e dwshield.sys. A falha foi corrigida e recebeu a referência pública BDU:2024-02836, com severidade alta e pontuação base 8.8 em CVSS 3.0. O contexto informa que um identificador CVE estava em andamento em junho de 2024, portanto nenhum CVE deve ser atribuído ao caso sem confirmação posterior.

Fluxo técnico

A condição inicial da vulnerabilidade está na criação do dispositivo do driver. O componente Dr.Web citado cria um dispositivo por meio de IoCreateDevice sem especificar explicitamente uma DACL restritiva no próprio código. Em drivers WDM, essa decisão é crítica porque a segurança do objeto de dispositivo define quais usuários e processos podem abrir um identificador para conversar com o driver. Quando o objeto é acessível por contas sem privilégio, qualquer funcionalidade exposta pela interface de controle do driver precisa ser tratada como uma superfície local de ataque. A existência de uma função perigosa no binário não basta para comprovar uma vulnerabilidade, mas a combinação entre acesso não privilegiado e capacidade privilegiada acionável cruza a fronteira de segurança usuário sem privilégio para sistema.

A análise também destaca uma variação de desenho inseguro em que o driver usa IoCreateDeviceSecure com uma DACL forte, mas não define a característica FILE_DEVICE_SECURE_OPEN. Nesse cenário, as permissões podem não ser aplicadas de forma uniforme a todo o namespace do dispositivo, o que preserva uma rota de acesso onde a proteção pretendida não cobre todos os caminhos relevantes. Esse tipo de erro é particularmente importante em produtos de segurança porque seus drivers costumam ter funções legítimas capazes de observar, bloquear ou encerrar processos, manipular objetos de sistema e operar com autoridade superior à de processos comuns.

No caso Dr.Web, o driver não dependia apenas de permissões do objeto para limitar o uso. Ele criava um nome de dispositivo gerado automaticamente e também um link simbólico com nome hexadecimal de 16 caracteres, diferente a cada carregamento. Além disso, implementava uma verificação de assinatura digital do processo que tentava obter um identificador para o dispositivo, permitindo a comunicação apenas a componentes Dr.Web assinados. O problema descrito é que essas barreiras puderam ser contornadas em cadeia: o nome do link simbólico podia ser descoberto por enumeração defensivamente observável do namespace de dispositivos, e a restrição baseada em assinatura podia ser bypassada por vulnerabilidades de carregamento lateral de DLL em componentes Dr.Web autorizados a falar com o driver.

O resultado técnico confirmado para o componente afetado inclui elevação local de privilégio, leitura e escrita arbitrárias entre modo núcleo e modo usuário e encerramento arbitrário de processos. Esses efeitos são relevantes para defesa porque se encaixam no modelo BYOVD, em que um operador malicioso ou malware carrega um driver legítimo, assinado e vulnerável como componente auxiliar. O driver não precisa ter sido desenvolvido como malware para ser abusado: basta que possa ser instalado ou carregado no ambiente e que exponha uma interface capaz de transformar uma chamada local em operação privilegiada.

Superfície afetada

A superfície principal envolve endpoints Windows capazes de carregar drivers de modo núcleo e que possuam drivers WDM assinados com permissões de dispositivo insuficientes. O recorte técnico do levantamento ficou em drivers de 64 bits com assinatura válida, pois esse perfil é especialmente valioso para abuso: a assinatura reduz barreiras de carregamento, enquanto o modo núcleo fornece acesso a operações fora do alcance normal de aplicações de usuário. A análise de bases conhecidas mostrou que a falha de desenho é repetitiva, não restrita a uma única família de produto, e aparece com frequência em drivers que não deixam explícita a política de acesso ao dispositivo.

Nos produtos Dr.Web citados, a exploração foi confirmada em Dr.Web Security Space, Dr.Web KATANA e Dr.Web CureIt. O contexto não fornece versões afetadas, sistemas operacionais específicos, hashes ou uma matriz de builds vulneráveis. Por isso, a resposta defensiva deve partir do inventário real do ambiente: presença dos produtos, presença dos arquivos de driver com nomes variáveis, validação de versão corrigida e confirmação de que o componente instalado não corresponde ao artefato vulnerável. Como o nome em disco pode variar, procurar apenas por um nome fixo de arquivo é insuficiente; metadados, assinatura, caminho PDB remanescente e comportamento de criação de dispositivo também são sinais úteis.

A superfície de risco se amplia quando drivers vulneráveis são mantidos em repositórios internos, imagens de golden image, caches de software, pacotes de instalação antigos, ferramentas de suporte, estáções de engenharia ou diretórios usados por EDR, antivírus e utilitários administrativos. Mesmo quando um produto define uma DACL durante a instalação por registro ou arquivo INF, o mesmo binário ainda pode ser interessante em cenários BYOVD se for carregado fora do fluxo previsto. Isso reforça que a governança precisa cobrir o artefato do driver, sua assinatura, sua origem, seu caminho de distribuição e as condições que permitem sua carga local.

• Drivers WDM de 64 bits assinados que criam dispositivos sem DACL explícita ou com DACL fraca.
• Drivers que usam IoCreateDeviceSecure sem aplicar FILE_DEVICE_SECURE_OPEN ao namespace do dispositivo.
• Instalações de Dr.Web Security Space, Dr.Web KATANA e Dr.Web CureIt com o driver antirrootkit vulnerável antes da correção.
• Ambientes que permitem carregamento de drivers antigos ou não inventariados como parte de fluxos administrativos, suporte ou segurança.

Hunting e telemetria

A detecção defensiva deve combinar inventário de drivers, análise de permissões do dispositivo, validação de assinatura e correlação de comportamento local. O primeiro eixo é identificar drivers assinados de 64 bits presentes nos endpoints, coletar metadados PE, assinatura, status de revogação, informações de versão e imphash, e separar duplicatas por versão e similaridade. O segundo eixo é analisar se o driver cria objetos acessíveis por usuários sem privilégio, seja por ausência de DACL, por uso fraco de SDDL, por IoCreateDevice sem proteção explícita ou por uso incompleto de IoCreateDeviceSecure. O terceiro eixo é procurar importações e chamadas a APIs de núcleo associadas a capacidades privilegiadas, como abertura de processos, threads ou tokens.

Em endpoints, eventos de carregamento de drivers devem ser revisados junto com criação de links simbólicos de dispositivo, interação de processos não administrativos com dispositivos de drivers e falhas ou sucessos anormais de abertura de identificadores para objetos de dispositivo. Para o caso Dr.Web, o link simbólico com nome hexadecimal de 16 caracteres é um traço importante, mas deve ser tratado como indicador comportamental, não como valor fixo. A enumeração repetitiva do namespace de dispositivos por processos comuns, tentativas de comunicação com drivers de produto de segurança e execução de componentes Dr.Web a partir de diretórios não esperados também são sinais que merecem investigação.

A cadeia descrita envolve carregamento lateral de DLL em componentes autorizados a se comunicar com o driver. Portanto, telemetria de criação de processo, carregamento de módulos, diretório de execução, assinatura dos binários e discrepância entre caminho esperado e caminho observado são relevantes. O objetivo defensivo não é reproduzir a técnica, mas identificar quando um componente assinado de segurança passa a carregar bibliotecas de localização incomum ou quando um processo sem relação administrativa tenta herdar confiança de um binário autorizado. Em paralelo, EDR e SIEM devem correlacionar encerramento inesperado de processos de segurança, acesso a memória privilegiada e eventos de driver próximos no tempo.

• Carregamento de drivers assinados antigos, desconhecidos ou sem correspondência com o inventário aprovado.
• Dispositivos de driver acessíveis por usuário sem privilégio por DACL ausente, fraca ou configuração incompleta de SDDL.
• Uso de APIs de núcleo sensíveis no driver, incluindo famílias relacionadas a processo, thread, token e memória.
• Enumeração incomum de links simbólicos de dispositivo e tentativa de abertura de identificadores por processos não administrativos.
• Carregamento de DLL por componentes Dr.Web assinados a partir de diretórios inesperados ou controláveis por usuário.
• Encerramento anormal de processos de segurança após atividade local envolvendo drivers de modo núcleo.

Mitigação

A mitigação imediata para ambientes com produtos Dr.Web citados é validar a aplicação da correção do componente vulnerável e remover builds antigos dos endpoints, repositórios de software, instaladores offline e imagens usadas para provisionamento. Como o contexto não lista versões, a confirmação precisa ser feita contra o canal oficial do produto e pelo estado efetivo do driver implantado. A referência BDU:2024-02836 ajuda a rastrear a correção, mas não substitui validação local de arquivo, assinatura, data, versão e presença do artefato em disco. Também é importante verificar se componentes temporários ou ferramentas portáteis, como utilitários de limpeza ou recuperação, deixaram drivers carregáveis fora do ciclo normal de atualização.

Para reduzir exposição geral a BYOVD, equipes de segurança devem tratar drivers como ativos executáveis privilegiados, não apenas como dependências de baixo nível. Isso significa manter uma lista aprovada de drivers de modo núcleo, revisar novos drivers antes de distribuição, rejeitar pacotes que exponham dispositivos a usuários sem privilégio sem necessidade clara, e priorizar correção quando o binário combina acesso local amplo com funções capazes de manipular processos, memória ou tokens. A revisão de DACL, SDDL, uso de IoCreateDevice, uso de IoCreateDeviceSecure e presença de FILE_DEVICE_SECURE_OPEN deve fazer parte de avaliações de produto e de auditorias internas de software que instala componentes de núcleo.

A resposta a um alerta deve começar pela contenção do host e preservação de evidências de driver, processos e módulos carregados. Em seguida, a equipe deve confirmar se houve carregamento de driver vulnerável, quais processos abriram identificadores para o dispositivo, se houve carregamento lateral de DLL por componentes confiáveis e se processos de segurança foram encerrados ou degradados. Caso o ambiente tenha aceitado driver vulnerável por cadeia de software interna, a correção precisa alcançar caches, compartilhamentos, ferramentas de suporte, pacotes de instalação e imagens de estáção. A validação final deve comprovar que usuários sem privilégio não conseguem mais acessar o dispositivo vulnerável e que o binário antigo não pode ser carregado novamente por rotas administrativas comuns.

• Atualizar Dr.Web Security Space, Dr.Web KATANA e Dr.Web CureIt para builds que incluam a correção do driver associado a BDU:2024-02836.
• Inventariar drivers de 64 bits assinados e remover cópias antigas de instaladores, caches, imagens e ferramentas portáteis.
• Auditar permissões de objetos de dispositivo para identificar DACL ausente, SDDL fraca ou ausência de FILE_DEVICE_SECURE_OPEN.
• Correlacionar eventos de carregamento de driver com enumeração de links simbólicos, carregamento de DLL e encerramento de processos.
• Exigir revisão de segurança para produtos que instalam drivers com funcionalidades de processo, memória, token ou controle de sistema.
• Documentar exceções de driver aprovado e bloquear a reintrodução de binários vulneráveis por fluxos de suporte ou implantação.