Windows PowerShellPrevenção contra código mal-intencionado

Don Jones

Você se lembra de quando o Windows Vista ainda estava na versão beta e havia muitos rumores sobre uma versão muito recente de um novo código de shell da linha de comando chamado "Monad"? (Esse, é claro, viria a ser conhecido como o Windows PowerShell.) Na época, havia muitas informações predominantes na mídia sobre o “primeiro vírus do Windows Vista”. Na

realidade, o “vírus" era apenas um script de malware de verificação de conceito destinado ao "Monad". Para executar o script, o próprio “Monad” precisaria ter sido especialmente configurado – o script não funcionaria nas configurações padrão. Além disso, quando esses relatórios surgiram, a Microsoft já havia anunciado que o "Monad" não seria fornecido como parte do Windows Vista®. Em resumo, toda a situação foi “muito barulho por nada” (ou, pelo menos, muito sobre muito pouco).

À medida que o Windows PowerShellTM se torna mais conhecido – ele já foi baixado mais de um milhão de vezes – aumentam as possibilidades de que alguém o utilize para criar um script malicioso. O recurso de gravar um script potencialmente perigoso no Windows PowerShell é uma certeza; qualquer ferramenta de administração – incluindo o Windows PowerShell, o cmd.exe e o VBScript – pode ser usada maliciosamente. Assim, você não pode presumir que determinado arquivo PS1 é inofensivo.

Felizmente, o Windows PowerShell está configurado por padrão para não executar scripts, de modo que o script malicioso precisará da sua ajuda para que seja executado. Neste mês, gostaria de prever como isso provavelmente acontecerá. O objetivo disso não é desqualificar o Windows PowerShell – penso que a Microsoft fez um excelente trabalho ao desenvolver um shell de script que evita muitos riscos. No entanto, essa é uma discussão válida somente para ajudá-lo a se preparar e estar pronto para evitar um possível ataque.

Seguro por padrão

É válido salientar que o Windows PowerShell foi a primeira linguagem desenvolvida pela Microsoft depois da famosa iniciativa Trustworthy Computing. O guru da segurança, Michael Howard (autor do livro Writing Secure Code), foi o "contato de segurança" da equipe do Windows PowerShell. Ele ajudou a garantir que o código fosse escrito com o máximo de segurança possível e, o mais importante, que o shell fosse configurado com a maior proteção possível pronta.

Primeiramente, vamos analisar de forma breve as configurações iniciais de segurança do Windows PowerShell. Por padrão, o shell não executará arquivos com uma extensão de nome de arquivo PS1 quando você clicar duas vezes neles. Essa extensão está associada ao Bloco de notas. Na verdade, por padrão, o shell não executará scripts em razão de um recurso interno denominado Diretiva de Execução, que descreve as condições nas quais um script será executado. Ele é definido como Restrito pronto, o que proíbe a execução de todos os scripts e habilita o shell somente para uso interativo. A Diretiva de Execução pode ser alterada usando o cmdlet Set-ExecutionPolicy ou por meio de um modelo administrativo da Diretiva de Grupo (arquivo ADM) fornecido pela Microsoft. (Você pode obter o arquivo ADM em go.microsoft.com/fwlink/?LinkId=102940.) A Figura 1 mostra as Diretivas de Execução que você pode definir.

Figura 1** Como escolher uma Diretiva de Execução segura **(Clique na imagem para aumentar a exibição)

A Diretiva de Execução tem somente algumas exceções. Especificamente, mesmo quando definida como Restrita, ela permitirá que o shell importe determinados arquivos de configuração XML, os quais são fornecidos pela Microsoft e instalados junto com o shell. Esses arquivos serão utilizados para fornecer funcionalidades específicas, como extensões para tipos Microsoft® .NET Framework e layouts de formatação padrão para a maioria dos tipos de objetos .NET. Assim, esses são os arquivos que você definitivamente deseja que o shell carregue na inicialização.

Embora esses arquivos possam conter, e contêm, código executável, eles foram assinados digitalmente pela Microsoft. Violá-los de qualquer forma inutilizará a assinatura e, se isso ocorrer, o shell não importará os arquivos na inicialização. Esse projeto torna os arquivos muito mais seguros em relação a malware que possam tentar inserir código malicioso neles.

É claro, a Diretiva de Execução, se mantida como Restrita, também impedirá que seus próprios scripts de perfil do Windows PowerShell sejam executados na inicialização. Por padrão, o Windows PowerShell não criará um script de perfil, mas irá pesquisar quatro locais específicos quanto a nomes de arquivos específicos e, se localizá-los, tentará executá-los sempre que o shell for iniciado. (A documentação instalada junto com o Windows PowerShell fornece detalhes sobre os nomes de arquivo e pasta utilizados para scripts de perfil.) O perfil é fundamental para explorar o que abordarei a seguir.

Como modificar a Diretiva de Execução

Cmdlet do mês

O assistente do Set-AuthenticodeSignature é o Get-AuthenticodeSignature. Esse cmdlet foi desenvolvido para examinar um script assinado digitalmente e fornecer detalhes sobre a assinatura. Basta apontá-lo para o arquivo em questão e você verá não somente se um arquivo foi assinado, mas se a assinatura está intacta, qual certificado foi usado para assinar o arquivo e assim por diante. Além de funcionar com os scripts do Windows PowerShell, esse cmdlet também funciona com os executáveis assinados, como a seguir:

PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *

Ao executar esse comando, é possível ver se o executável foi assinado pela Microsoft Corp. usando um certificado emitido pela Microsoft Code Signing CA.

Resultados do comando  (Clique na imagem para aumentar a exibição)

Devo salientar que em condições padrão, é muito difícil – se não impossível – que o Windows PowerShell execute qualquer código ou deixe qualquer código malicioso isolado. Somente se você alterar a Diretiva de Execução é que os scripts maliciosos se tornarão possíveis. Para ser mais específico, esta coluna não é um alerta sobre as brechas de segurança no Windows PowerShell; em vez disso, tem como objetivo compartilhar algumas das práticas recomendadas para manter os sistemas protegidos.

A Diretiva de Execução mais baixa é Irrestrita, o que permite que todos os scripts sejam executados sem restrição ou dúvida – oferecendo basicamente o mesmo cenário indesejável que você teve por anos com os arquivos em lote e VBScript. Defina o shell como Irrestrito e você estará apenas solicitando que um script malicioso surja e cause danos. Se você não tiver escolhido a configuração Irrestrita e um script surgir e o atacar, certifique-se de que você possa justificar por que escolheu essa configuração e prepare-se para sustentar sua decisão quando estiver explicando como um vírus eliminou seu ambiente!

Para ser honesto, o Windows PowerShell ainda tentará detectar scripts obtidos pela Internet e avisá-lo antes da execução, mesmo quando estiver definido como Irrestrito. Mas a questão é que ter uma Diretiva de Execução definida como Irrestrita não é uma boa idéia.

Como assinar scripts

A Diretiva de Execução mais segura que permite que os scripts sejam executados é a AllSigned. Essa configuração, como o nome sugere, executa somente scripts que têm uma assinatura digital intacta criada usando um certificado confiável (diferente do que a assinatura antiga faria). A assinatura de scripts requer que você adquira um certificado digital de Classe III – mais especificamente, um certificado de assinatura de código Authenticode da Microsoft. Tais certificados podem ser obtidos da Infra-estrutura de chave pública (PKI, Public Key Infrastructure) interna de sua empresa, se você tiver uma, ou adquirida de autoridades de certificação comercial (CAs, certificate authorities), como CyberTrust, Thawte e VeriSign.

Se você quiser saber se tem certificados instalados na sua máquina que podem ser usados para assinar scripts, o seguinte cmdlet exibirá:

Get-ChildItem CERT: -recurse –codeSigningCert

Depois de instalar o certificado no seu computador Windows®, utilize o cmdlet Set-AuthenticodeSignature para criar e aplicar uma assinatura digital, que lhe mostrará uma série de linhas de comentário sem sentido no final do script. Alguns editores de script podem oferecer a opção de aplicar uma assinatura a um arquivo de script, incluindo uma oportunidade para assinar automaticamente scripts à medida que você salvá-los, o que pode ser conveniente.

AllSigned é a melhor Diretiva de Execução a ser utilizada em um ambiente de produção. Embora isso não impeça diretamente scripts maliciosos, garante que um script malicioso seja assinado e, portanto, você poderia rastrear o autor do script (pressupondo-se que os computadores Windows estão configurados para confiar somente em CAs confiáveis, mas esse tópico foge do objetivo desta coluna). Curiosamente, o Windows Script Host (WSH) 5.6 e suas versões posteriores podem ser configurados com uma definição TrustPolicy semelhante, que também requer assinaturas digitais, mas sei de poucos administradores que usam de fato essa configuração.

Portanto, façamos uma rápida recapitulação. Com uma Diretiva de Execução definida como Irrestrita, você está protegido contra scripts maliciosos, mas não poderá executar scripts benéficos. Com a sua Diretiva de Execução configurada como AllSigned, o shell permite scripts assinados, o que é muito seguro, pois alguns autores de scripts maliciosos querem que uma identidade verificada e rastreável seja aplicada em seus trabalhos. A configuração Irrestrita, por outro lado, é extremamente desprotegida e, se você a estiver usando, poderá esperar ser atingido por algum script malicioso em algum momento. (Observe que não considero a configuração Irrestrita uma vulnerabilidade específica, pois ela não finge ser algo, apenas é insegura, mas se você estiver usando essa configuração, provavelmente sabe quais são os riscos.)

Acesso pela "porta lateral"

Ainda há mais uma configuração de Diretiva de Execução: RemoteSigned. Essa é a que eu considero estar sendo utilizada atualmente pela maioria dos administradores, simplesmente por que é percebida como mais segura do que a Irrestrita e menos problemática do que a AllSigned. A RemoteSigned não requer uma assinatura para scripts locais. Os arquivos PS1 que residem nas suas unidades locais serão executados sem serem assinados. Os scripts remotos – principalmente os obtidos da Internet usando o Internet Explorer® or Outlook® (esses aplicativos marcam os arquivos baixados com um sinalizador especial) – não serão executados a menos que sejam assinados.

No entanto, a configuração RemoteSigned pode lhe dar a falsa impressão de segurança. Para começar, é fácil de baixar scripts remotos sem precisar aplicar o sinalizador especial. Os navegadores que não são da Microsoft, por exemplo, geralmente não definem esse sinalizador, e o mesmo se aplica à maioria dos clientes de email que não são da Microsoft. É importante observar que sem esse sinalizador, o Windows PowerShell trata os scripts de download como locais – o que significa que não será necessária uma assinatura. Ainda assim, não considero isso uma vulnerabilidade significativa. Na verdade, você precisa fazer download do script, abrir o Windows PowerShell e executar manualmente esse script para que ele seja executado. É um pouco difícil enganar alguém para que realize todas essas tarefas e, os administradores – geralmente os únicos usuários em uma rede que têm o Windows PowerShell instalado – já deviam estar cientes disso.

No entanto, a RemoteSigned oferece uma “porta lateral” significativa que pode ser utilizada pelo malware. Você se lembra dos scripts de perfil do Windows PowerShell? Se eles existirem – sejam criados por você ou por um código de malware – eles serão executados sempre que o Windows PowerShell for executado. E na Diretiva de Execução RemoteSigned Execution, os seus scripts de perfil – que são locais – não precisarão ser assinados.

Veja o cenário:

1. Parte do código consegue entrar no seu sistema e criar um script de perfil de shell, ou inserir um código malicioso em um script de perfil existente. O malware geralmente é executado na conta do usuário conectado, o qual geralmente tem permissão para modificar o script do seu perfil.
2. Você abre o Windows PowerShell, não percebendo que o seu script de perfil foi criado ou modificado para incluir o código malicioso. O código é executado e o dano está feito. O dano é pior se você tiver o hábito de abrir o Windows PowerShell com credenciais de administrador – uma prática comum, pois quando você está usando o shell, precisa de privilégios administrativos para realizar quaisquer tarefas para as quais está usando o shell.

O perfil apresenta então uma forma para que o código arbitrário e malicioso seja executado sem o seu conhecimento, e a Diretiva de Execução RemoteSigned permite que isso aconteça.

Como proteger o perfil

Há apenas um método ideal para proteger o seu perfil: use a Diretiva de Execução AllSigned. Na AllSigned, até mesmo os seus scripts de perfil devem ser assinados digitalmente; caso contrário, o Windows PowerShell não irá executá-los na inicialização. E se você tiver assinado seus scripts de perfil, as modificações maliciosas neles violarão suas assinaturas digitais, impossibilitando-os de serem executados – na verdade, o Windows PowerShell irá alertá-lo do problema na inicialização. A AllSigned é realmente a única configuração segura de Diretiva de Execução para ambientes de produção que precisam permitir a execução de scripts.

Há outra abordagem, mas é mais complicada e menos confiável. Você pode criar arquivos de script de perfil em branco para cada um dos quatro arquivos que o Windows PowerShell verificar. Use uma nova conta de usuário (a chamarei de "Editor de perfil") para criar esses arquivos e definir as permissões NTFS dos arquivos, de modo que somente a conta do Editor de perfil possa modificá-las. Outras contas podem ter acesso somente leitura.

Agora, nunca faça logon no computador usando a conta de Editor de perfil, exceto para editar seu perfil. Com essa abordagem, a sua conta (ou contas) de usuário normal não poderá modificar seus scripts de perfil. E qualquer malware que for executado enquanto você estiver conectado com uma conta normal não poderá modificar os scripts. O que acontece se o malware for executado enquanto você estiver conectado como Editor de perfil? Bem, considerando que você está conectado como Editor de perfil para editar seus scripts de perfil, você deverá observar as alterações.

Você também pode criar sua própria segurança de rede ao criar um script de perfil para todos os usuários, que será controlado com rígidas permissões de arquivo, como acabei de descrever. Nesse script, grave o código que utilizará o cmdlet Get-AuthenticodeSignature para examinar as assinaturas digitais em outros perfis que o shell verificar. Isso basicamente permite que você exija assinaturas em scripts de perfil, sem exigi-las para outros scripts.

No entanto, a Diretiva de Execução AllSigned é uma forma muito mais completa de proteger o seu perfil. Minha recomendação é que qualquer computador conectado à sua rede tenha uma Diretiva de Execução Restrita, preferencialmente aplicada pela Diretiva de Grupo. Isso substitui qualquer configuração local e garante que os computadores do novo domínio sejam definidos automaticamente para desativar scripts. Os computadores nos quais os scripts devem ser permitidos devem ter uma Diretiva de Grupo alternativa que defina a Diretiva de Execução AllSigned. Você precisará assinar digitalmente todos os scripts, mas ficará tranqüilo sabendo que somente os scripts confiáveis de autores identificáveis serão executados no seu ambiente.

Don Jones é o guru de scripts da SAPIEN Technologies e co-autor do Windows PowerShell: TFM (SAPIEN Press, 2007). Para entrar em contato com ele, visite www.ScriptingAnswers.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..