Como o Controle de Aplicativos funciona com o PowerShell

  • Artigo

Este artigo explica como o Controle de Aplicativos para Empresas protege o PowerShell e as restrições que ele impõe. O comportamento seguro do PowerShell varia de acordo com a versão do Windows e do PowerShell que você está usando.

Como o PowerShell detecta uma política de bloqueio do sistema

O PowerShell detecta políticas de todo o sistema AppLocker e App Control for Business . O AppLocker foi descontinuado. O App Control é o sistema de controle de aplicativos preferido para Windows.

Detecção de imposição de política de Controle de Aplicativos herdado

O PowerShell usa a API de Controle de Aplicativos WldpGetLockdownPolicy herdada para descobrir duas coisas:

  • Imposição de políticas em todo o sistema: None, Audit, Enforce
  • Política de arquivo individual: None, Audit (permitido pela política), Enforce (não permitido pela política)

Todas as versões do PowerShell (v5.1 - v7.x) dão suporte a essa detecção de política de Controle de Aplicativos.

Detecção mais recente de imposição de política do Controle de Aplicativos

O Controle de Aplicativos introduziu novas APIs em versões recentes do Windows. Começando na versão 7.3, o PowerShell usa a nova API WldpCanExecuteFile para decidir como um arquivo deve ser tratado. O Windows PowerShell 5.1 não oferece suporte a essa nova API. A nova API tem precedência sobre a API herdada para arquivos individuais. No entanto, o PowerShell continua a usar a API herdada para obter a configuração de política em todo o sistema. Se a nova API não estiver disponível, o PowerShell retornará ao comportamento da API antiga.

A nova API fornece as seguintes informações para cada arquivo:

  • WLDP_CAN_EXECUTE_ALLOWED
  • WLDP_CAN_EXECUTE_BLOCKED
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX

Comportamento do PowerShell sob a política de bloqueio

O PowerShell pode ser executado nos modos interativo e não interativo.

  • No modo interativo, o PowerShell é um aplicativo de linha de comando que usa a entrada de linha de comando dos usuários como comandos ou scripts a serem executados. Os resultados são exibidos de volta para o usuário.
  • No modo não interativo, o PowerShell carrega módulos e executa arquivos de script sem entrada do usuário. Os fluxos de dados resultantes são ignorados ou redirecionados para um arquivo.

Modo interativo em execução sob imposição da política

O PowerShell executa comandos no modo ConstrainedLanguage. Esse modo impede que usuários interativos executem determinados comandos ou executem código arbitrário. Para obter mais informações sobre as restrições nesse modo, consulte a seção Restrições do PowerShell sob a política de bloqueio deste artigo.

Modo não interativo em execução sob imposição da política

Quando o PowerShell executa um script ou carrega um módulo, ele usa a API de Controle de Aplicativos para obter a imposição de política para o arquivo.

O PowerShell versão 7.3 ou superior usa a API WldpCanExecuteFile, se disponível. Essa API retorna os seguintes resultados:

  • WLDP_CAN_EXECUTE_ALLOWED: o arquivo é aprovado pela política e é usado no modo FullLanguage com algumas restrições.
  • WLDP_CAN_EXECUTE_BLOCKED: o arquivo não é aprovado pela política. O PowerShell gera um erro quando o arquivo é executado ou carregado.
  • WLDP_CAN_EXECUTE_REQUIRE_SANDBOX: o arquivo não é aprovado pela política, mas ainda pode ser executado ou carregado no modo ConstrainedLanguage.

No Windows PowerShell 5.1 ou se a API WldpCanExecuteFile não estiver disponível, o comportamento por arquivo do PowerShell será:

  • None: o arquivo é executado carregado no modo FullLanguage com algumas restrições.
  • Audit: o arquivo é executado ou carregado no modo FullLanguage sem restrições. No PowerShell 7.4 ou superior, a política registra informações de restrição nos logs de eventos do Windows.
  • Enforce: o arquivo é executado ou carregado no modo ConstrainedLanguage.

Restrições do PowerShell sob a política de bloqueio

Quando o PowerShell detecta que o sistema está sob uma política de bloqueio do Controle de Aplicativos, ele aplica restrições mesmo que o script seja confiável e esteja em execução no FullLanguage modo. Essas restrições impedem comportamentos conhecidos do PowerShell que poderiam resultar na execução de código arbitrário em um sistema bloqueado. A política de bloqueio impõe as seguintes restrições:

  • Dot-sourcing de módulo com restrição de exportação de função curinga

    Qualquer módulo que usar dot-sourcing de scripts e exportar funções usando nomes curinga resultará em um erro. O bloqueio de exportações de curinga impede a injeção de scripts de um usuário mal-intencionado que pode inserir por dot-source um script não confiável em um módulo confiável. O script malicioso poderia então obter acesso às funções privadas do módulo confiável.

    Recomendação de segurança: nunca use o dot-sourcing de scripts em um módulo e sempre exporte funções do módulo com nomes explícitos (sem caracteres curinga).

  • Módulo aninhado com restrição de exportação de função curinga

    Se um módulo pai exportar funções usando caracteres curinga de nome de função, o PowerShell removerá qualquer nome de função em um módulo aninhado da lista de exportação de função. O bloqueio de exportações de curinga de módulos aninhados impede a exportação acidental de funções aninhadas perigosas por meio da correspondência de nome curinga.

    Recomendação de segurança: sempre exporte funções do módulo com nomes explícitos (sem caracteres curinga).

  • Conversão interativa de tipo de parâmetro de shell

    Quando o sistema está bloqueado, as sessões interativas do PowerShell são executadas no modo ConstrainedLanguage para impedir a execução de código arbitrário. Os módulos confiáveis carregados na sessão são executados no modo FullLanguage. Se um cmdlet de módulo confiável usar tipos complexos para seus parâmetros, a conversão de tipo durante a associação de parâmetro poderá falhar se a conversão não for permitida entre limites de confiança. A falha ocorre quando o PowerShell tenta converter um valor executando um construtor de tipo. Os construtores de tipo não têm permissão para serem executados no modo ConstrainedLanguage.

    Neste exemplo, a conversão de tipo de associação de parâmetro normalmente é permitida, mas falha quando executada no modo ConstrainedLanguage. O construtor de tipo ConnectionPort não é permitido:

    PS> Create-ConnectionOnPort -Connection 22
Create-ConnectionOnPort: Cannot bind parameter 'Connection'. Cannot convert the "22"
value of type "System.Int32" to type "ConnectionPort".

  • O cmdlet Enter-PSHostProcess não é permitido

    O cmdlet Enter-PSHostProcess está desabilitado e gera um erro se usado. Esse comando é usado para sessões de anexação e depuração. Ele permite que você se conecte a qualquer outra sessão do PowerShell no computador local. O cmdlet está desabilitado para impedir a divulgação de informações e a execução de código arbitrário.

Restrições do PowerShell sob o modo de linguagem restrita

O script ou a função que não é aprovado pela política de Controle de Aplicativos não é confiável. Quando você executa um comando não confiável, o PowerShell bloqueia a execução do comando (novo comportamento) ou executa o comando no modo ConstrainedLanguage. As restrições a seguir se aplicam ao modo ConstrainedLanguage:

  • O cmdlet Add-Type não é permitido

    Bloquear Add-Type impede a execução de código .NET arbitrário.

  • Cmdlet Import-LocalizedData restrito

    Bloquear o parâmetro SupportedCommand de Import-LocalizedData impede a execução de código arbitrário.

  • Cmdlet Invoke-Expression restrito

    Todos os blocos de script passados para o cmdlet Invoke-Expression são executados no modo ConstrainedLanguage para impedir a execução de código arbitrário.

  • Cmdlet New-Object restrito

    O cmdlet New-Object é restrito a usar apenas tipos .NET e COM permitidos para impedir o acesso a tipos não confiáveis.

  • Restrição do cmdlet ForEach-Object

    A invocação do método de tipo para variáveis passadas para ForeEach-Object não é permitida tipos .NET que não estejam na lista de aprovados. Em geral, o modo ConstrainedLanguage não permite qualquer invocação de método de objeto, exceto para tipos .NET aprovados para impedir o acesso a tipos .NET não confiáveis.

  • Restrição do cmdlet Export-ModuleMember

    Usar o cmdlet Export-ModuleMember para exportar funções em um arquivo de script de módulo aninhado em que o módulo filho não é confiável e o módulo pai é confiável resulta em um erro. O bloqueio desse cenário impede que um módulo não confiável mal-intencionado exporte funções perigosas de um módulo confiável.

  • Restrição do cmdlet New-Module

    Quando você executa New-Module em um script confiável, qualquer bloco de script fornecido pelo parâmetro ScriptBlock é marcado para ser executado no modo ConstrainedLanguage para evitar a injeção de código arbitrário em um contexto de execução confiável.

  • Palavra-chave Configuration não permitida

    A palavra-chave de linguagem Configuration não é permitida no modo ConstrainedLanguage para evitar ataques de injeção de código.

  • Palavra-chave class não permitida

    A palavra-chave de linguagem class não é permitida no modo ConstrainedLanguage para evitar a injeção de código arbitrário.

  • Restrições de escopo de processamento do bloco de script

    Os blocos de script filho não terão permissão para ser executados em escopos de bloco de script pai se os blocos de script tiverem níveis de confiança diferentes. Por exemplo, você cria uma relação filho ao fazer o dot-source de um script em outro. Bloquear esse cenário impede que um script não confiável obtenha acesso a funções perigosas no escopo do script confiável.

  • Impedir a descoberta de comandos de funções de script não confiáveis

    A descoberta de comandos do PowerShell não retorna funções de uma fonte não confiável, como um script ou módulo não confiável, para uma função confiável. Bloquear a descoberta de comandos não confiáveis impede a injeção de código por meio do plantio de comandos.

  • Conversão de tabela de hash para objeto não permitida

    O modo ConstrainedLanguage bloqueia conversões de tabela de hash para objeto nas seções Data de arquivos de dados (.psd1) do PowerShell para evitar possíveis ataques de injeção de código.

  • Conversão automática de tipo restrita

    O modo ConstrainedLanguage bloqueia a conversão automática de tipo, exceto para um pequeno conjunto de tipos seguros aprovados para evitar possíveis ataques de injeção de código.

  • Restrição implícita de exportação de função de módulo

    Se um módulo não exportar funções explicitamente, o PowerShell exportará implicitamente todas as funções de módulo definidas automaticamente como um recurso de conveniência. No modo ConstrainedLanguage, as exportações implícitas não ocorrem mais quando um módulo é carregado entre limites de confiança. O bloqueio de exportações implícitas previne a exposição não intencional de funções de módulo perigosas não destinadas ao uso público.

  • Os arquivos de script não podem ser importados como módulos

    O PowerShell permite importar arquivos de script (.ps1) como um módulo. Todas as funções definidas tornam-se publicamente acessíveis. O modo ConstrainedLanguage bloqueia a importação do arquivo de script para evitar a exposição não intencional de funções de script perigosas.

  • Configurando a restrição AllScope de variáveis

    O modo ConstrainedLanguage desabilita a capacidade de definir AllScope em variáveis. Limitar o escopo das variáveis impede que elas interfiram no estado da sessão de comandos confiáveis.

  • Invocação de método de tipo não permitida

    O modo ConstrainedLanguage não permite a invocação de método em tipos não aprovados. O bloqueio de métodos em tipos não aprovados previne a invocação de métodos do tipo .NET que podem ser perigosos ou permitir a injeção de código.

  • Setters de propriedade de tipo não são permitidos

    O modo ConstrainedLanguage restringe a invocação de setters de propriedade em tipos não aprovados. O bloqueio de setters de propriedade em tipos não aprovados impede ataques de injeção de código.

  • Criação de tipo não permitida

    O modo ConstrainedLanguage bloqueia a criação de tipos em tipos não aprovados para bloquear construtores não confiáveis que podem permitir a injeção de código.

  • Operador de escopo de módulo não permitido

    O modo ConstrainedLanguage não permite o uso do operador de escopo do módulo. Por exemplo: & (Get-Module MyModule) MyFunction. Bloquear o operador de escopo do módulo impede o acesso a funções e variáveis privadas do módulo.

Leitura adicional