Há muito tempo, quando a grama era mais verde e a Internet mais segura, a iniciativa Web Based Enterprise Management (WBEM) nasceu em TI. Patrocinado originalmente em 1996 por empresas como Cisco Systems, Intel e Microsoft, foi amplamente adotado e implementado em plataformas que vão do MAC OS ao Redhat. O WBEM é claramente documentado, com base nos padrões da Internet, e fornece uma abordagem diferente para gerenciamento de sistemas do SNMP, por exemplo.
A adaptação do WBEM para Windows é chamada de WMI (interface de gerenciamento do Windows) e foi introduzida pela primeira vez no Windows XP. Sabemos que os sistemas são atualizados mais rapidamente do que seus componentes, e muitas vulnerabilidades que antes eram uma ferramenta de gerenciamento conveniente migram de uma versão para outra. Neste artigo, desejo descrever como as tarefas do WMI são executadas e como evitar riscos potenciais.
Devido ao seu poder, o WMI permite o uso de utilitários ou scripts especiais para realizar várias ações potencialmente perigosas em um PC, incluindo interromper serviços críticos e até desligar o computador. Por exemplo, como este:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges) .Win32Shutdown (5)
(GWMI -Class Win32_Service -Filter "name = 'WinRM'" -ComputerName Server) .StopService ()
Além disso, execute as mesmas ações na máquina remota assim como no local - basta escrever o nome da máquina necessária no caminho para o objeto WMI.
O namespace WMI é uma seção do repositório WMI projetada para agrupar classes e objetos WMI por propósito, além de definir atributos de segurança ao acessar classes e objetos em cada um desses contêineres. Todos os namespaces começam com uma raiz, que é denotada pela palavra-chave root no WMI. O namespace é seguido por uma barra após o nome da raiz. Os namespaces podem ser aninhados. A maioria das classes e objetos interessantes estão localizados no namespace root / CIMv2.
Um dos namespaces WMI existentes do Windows pode ser selecionado como padrão. Isso significa que, se você tentar se conectar a este host sem especificar um namespace, será automaticamente conectado ao host selecionado por padrão. Em uma instalação padrão do Windows, o espaço padrão é root \ cimv2.
A tecnologia WMI é projetada para administradores do Windows, e todo o sistema de segurança no WMI é projetado para que, usando scripts WMI, um usuário em um determinado PC possa executar apenas as ações para as quais ele recebeu permissões / privilégios. Esses são os chamados privilégios padrão. É assim que a segurança do WMI é implementada no nível do sistema operacional: se o usuário no nível do sistema operacional não tiver o privilégio de reiniciar o computador, ele não poderá fazer isso usando o WMI.
Políticas de segurança adicionais no WMI são implementadas no nível de namespace do protocolo Distributed COM (DCOM), um modelo de objeto de componente distribuído. Para examinar mais de perto esses tipos de segurança WMI, vou relembrar brevemente os conceitos gerais básicos relacionados à segurança no Windows. E essa segurança é baseada em nomes de usuários e suas senhas.
Sobre as permissões WMI
Quando um usuário é criado no Windows, sua conta do sistema recebe uma ID de segurança exclusiva (Security IDentifier ou SID). Com base no SID, é gerado um token de acesso para o usuário, ao qual também são adicionados a lista de grupos dos quais o usuário é membro e a lista de privilégios que ele possui (por exemplo, interromper serviços ou desligar o computador). Esse token de acesso também é atribuído a todos os processos que o usuário inicia. Neste momento, cada objeto do sistema operacional, cujo acesso é determinado pelo sistema de segurança - um arquivo, ou um processo, ou um serviço ou outra coisa - possui um Descritor de Segurança (SD). Este descritor, por sua vez, armazena a Lista de Controle de Acesso (ACL) para este objeto.
Assim, quando um usuário ou um processo por ele lançado acessa um objeto, o token de acesso desse usuário é comparado com a lista de controle de acesso. Dependendo dos resultados, permissão / privilégio é emitido ou negado para executar as ações solicitadas no objeto.
No nível do namespace, o mecanismo de segurança WMI segue o modelo geral de segurança do Windows. Cada namespace pode ter seu próprio descritor de segurança que armazena uma lista de controle de acesso (ACL).
Cada entrada de ACE (Access Control Entry) contém informações sobre quais permissões um determinado usuário possui ao executar várias operações nesse namespace.
E aqui está a lista de permissões ao trabalhar com o namespace:
Métodos de execução. Permite chamar métodos de classes de um namespace específico. O sucesso ou a falha do método depende se o usuário tem permissão para executar a operação no sistema.
Escrita completa. Permite a criação e modificação de subnamespaces, classes de sistema e instâncias de classe.
Gravação parcial. Abre a capacidade de criar e modificar quaisquer classes estáticas e instâncias de classes não pertencentes ao sistema.
Gravação do provedor.Permite verificar as classes de provedor WMI e instâncias dessas classes para o repositório CIM.
Ative a conta. Concede acesso de leitura ao namespace WMI. Os usuários com essa permissão podem executar scripts no computador local que lêem dados WMI.
Habilite remotamente (habilitação remota). Permite que os usuários acessem o namespace WMI em um computador remoto. Por padrão, apenas administradores têm essa permissão; usuários padrão não podem recuperar dados WMI de máquinas remotas.
Leia Segurança. Concede o direito de ler o descritor de segurança do namespace WMI sem modificação.
Altere as regras de segurança (Editar Segurança). Permite que você modifique o descritor de segurança para o namespace WMI.
Todas essas entradas ACL são armazenadas no repositório WMI. As permissões WMI para um determinado namespace se aplicam a todos os subnamespaces e classes definidas nesse namespace (herdadas de). Você não pode definir suas próprias permissões de segurança para uma classe WMI individual.
Sobre a configuração padrão
No Windows, o grupo Administradores possui todas as permissões da tabela acima, e para outros usuários a conta está habilitada ( Habilitar Conta ), é permitido chamar métodos ( Execute Method s) e gravar instâncias de classes de provedor no CIM ( Provider Write ).
Um administrador pode alterar as permissões para usuários específicos usando o utilitário Configurações WMI (snap-in wmimgmt.msc do Console de Gerenciamento MMC).
Captura de tela 1.
O protocolo DCOM acima é usado para acessar a infraestrutura WMI em um computador remoto. O usuário executa um script ou se conecta ao WMI usando utilitários especiais e atua como um cliente, e o objeto WMI que está sendo acessado é o servidor. Os níveis de representação DCOM padrão são usados para determinar qual token de acesso será usado ao trabalhar com o WMI em um computador remoto.
Sobre os níveis de roubo de identidade ou roubo de identidade
Em russo, parece um tanto desajeitado. O que é personificação e por que ela é necessária? Esta é uma técnica na qual um processo ou sistema deve usar as credenciais de outra entidade de segurança em vez de seu próprio contexto de segurança para se conectar a um recurso.
Imagine - um determinado serviço lançado no contexto de segurança LocalSystem deve executar uma ação em nome de outra conta (por exemplo, em nome do usuário atual conectado ao computador). Nesse caso, o serviço precisa criar um token de acesso especial que descreva o contexto de segurança da conta sob a qual queremos executar a ação especificada.
Para criar tal token de acesso, o serviço precisa saber as credenciais desse usuário e, se esse processo ocorrer na máquina local, obter uma cópia do token de acesso do usuário anteriormente registrado localmente.
Para fazer isso, o contexto de segurança do serviço deve ter o privilégio de criar tokens de acesso.
Existe uma versão mais complexa de personificação - delegação. Esta opção é necessária quando a conexão com o recurso de destino não é realizada pelo próprio principal de segurança (no exemplo acima, pelo serviço em nome do usuário), mas por meio de um intermediário (por exemplo, um servidor intermediário).
Imagine: um usuário se conecta não diretamente ao banco de dados, mas por meio de um aplicativo da web em um terceiro servidor. Para fazer essa conexão, o aplicativo da web deve receber um token de acesso delegado do principal de segurança (nosso serviço) - isso permitirá que o aplicativo da web use o token de acesso do principal de segurança ao se conectar ao banco de dados.
No caso do WMI, a delegação pode ser assim: nós, trabalhando na estação do administrador, nos conectamos via WMI a um determinado servidor e iniciamos um processo nele usando o método Execute da classe Win32_Process. Este processo nada mais é do que outro script WMI que se conecta a outro host na rede para realizar alguma ação. Se não usarmos a delegação, na máquina de destino o script será iniciado no contexto de segurança da conta do servidor intermediário, o que está longe de ser sempre desejável. Por outro lado, uma situação semelhante com a delegação na vida real acontece muito raramente.
Sobre níveis de falsificação de identidade
Acesso anônimo (anônimo). O objeto servidor não tem o direito de obter informações sobre o usuário ou o processo que está acessando esse objeto (em outras palavras, o objeto não pode representar o cliente). Este nível de representação não é usado no WMI.
Identificação. O objeto do servidor pode solicitar um token de acesso associado ao cliente, mas não pode representar.
Esse nível de representação raramente é usado em scripts WMI, caso em que você não pode executar scripts WMI em máquinas remotas.
Personificar.O objeto servidor pode usar todos os direitos e privilégios que o cliente possui. É recomendado que você use este nível de representação em scripts WMI, porque então o script WMI na máquina remota será capaz de realizar todas as ações que o usuário que executa o script tem permissão para fazer.
DelegarUm objeto em um servidor que um cliente está acessando pode se referir a outro objeto em um servidor diferente em nome do cliente. A delegação permite que um script use o token de acesso do usuário que o executa na máquina remota. O mesmo token é usado para acessar objetos WMI em outras estações de trabalho. Há um risco potencial com esse nível de representação; a delegação em scripts WMI deve ser usada apenas quando estritamente necessário.
O nível de representação padrão depende da versão do WMI no computador de destino. Nas versões do WMI abaixo de 1.5, o nível padrão é Identify, nas versões do WMI 1.5 e acima - Impersonate. Se necessário, você pode alterar o nível de representação padrão escrevendo o nome do nível necessário (por exemplo, representar ou delegar) na chave de registro
HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Wbem \ Scripting \ Nível de representação padrão .
Captura de tela 2.
O protocolo DCOM também fornece a capacidade de solicitar um nível específico de autenticação (autenticação) e privacidade para uma conexão WMI:
Nenhum. Sem autenticação.
Por padrão (padrão). As configurações de segurança padrão são usadas para selecionar o nível de autenticação. Este é o nível recomendado, pois o cliente será atribuído ao nível de autenticação especificado pelo servidor.
Conexões (conectar). O cliente só é autenticado quando se conecta ao servidor. Depois que a conexão for estabelecida, nenhuma verificação adicional será executada.
Chamadas. O cliente é autenticado no início de cada chamada, enquanto o servidor aceita solicitações. Nesse caso, os cabeçalhos dos pacotes são assinados, mas os próprios dados (o conteúdo dos pacotes) transmitidos entre o cliente e o servidor não são assinados ou criptografados.
Pacote (Pkt).Todos os pacotes de dados que vêm de clientes para o servidor são autenticados. Tal como acontece com a autenticação no nível da chamada, os cabeçalhos dos pacotes são assinados, mas não criptografados. Os pacotes em si não são assinados ou criptografados.
Integridade do pacote (Pktlntegrity). Todos os pacotes de dados são verificados quanto à autenticidade e integridade. É verificado se o conteúdo do pacote não foi alterado durante a transferência do cliente para o servidor. Nesse caso, os dados são assinados, mas não criptografados.
Privilégios (PktPrivacy). Todos os pacotes de dados são verificados quanto à autenticidade e integridade, e os dados são assinados e criptografados para garantir a confidencialidade dos dados transmitidos.
Os administradores do Windows estão bem cientes das configurações de segurança do sistema disponíveis no Console de Segurança do Sistema e nas Políticas de Grupo do Domínio e na seção Atribuições de Direitos do Usuário. Várias ações com o sistema operacional podem ser realizadas apenas se o usuário ou grupo ao qual ele pertence tiver um ou outro privilégio. Tais ações, por exemplo, incluem: reinicializar o sistema (encerrar seu trabalho), restaurar o estado do sistema a partir de um backup ou alterar a hora do sistema.
Como o WMI pode executar todas essas ações, os desenvolvedores do WMI forneceram um mecanismo de segurança adicional: mesmo se uma conta de usuário tiver os privilégios necessários para operar no sistema, ela ainda não pode executar esta ação até que ative explicitamente o privilégio antes de executar a ação. Em particular, se um administrador executar um script WMI solicitando a reinicialização do sistema, isso ainda não acontecerá até que esse privilégio seja explicitamente ativado no script.
Resumo
O que é sugerido ser feito para garantir a segurança das conexões WMI:
- Altere o nível de representação para serviços essenciais (captura de tela 2).
- Configure as permissões wmimgmt.msc (captura de tela 1).
- Altere o repositório padrão. Isso pode quebrar o cenário de ataque padrão.
4. Altere os grupos de pessoas com recursos de inicialização remota e ativação WMI por meio do utilitário DCOMCNFG
5. Para iniciar o WMI, um usuário deve ser membro do grupo de administradores ou usuários DCOM. O serviço de registro remoto também deve estar disponível.
6. Configure o firewall - as conexões de entrada para DCOM passam pela porta TCP 135 e (tem?) O intervalo dinâmico RPC.
Concluindo, quero dizer o seguinte: o WMI oferece velocidade, poder e facilidade de execução de comandos em hosts remotos, e a semântica de comandos baseada em SQL facilita o aprendizado.
Há muitas informações na Internet sobre hackers e ataques WMI, porque eles se encaixam na tendência de ataque atual - o uso de ferramentas de hacking de sistema nativas - junto com telnet NTP e DNS. Nossa tarefa é captar essa tendência e encontrar métodos de contra-ataque já embutidos no sistema.
Autor: Galiulin Timur GTRch