Os arquivos da área de trabalhoDeixando o administrador para trás

Wes Miller

Há mais de três anos, dei início ao processo de migrar a minha conta de usuário no meu sistema Windows primário de administrador local para usuário local. Trabalhei na Microsoft por mais de sete anos, sempre executando como um administrador com privilégios totais. É claro que isso era prático, mas a absurda falta de segurança

realça a sorte incrível que tive (e que tantos de nós temos) de a execução diária como administrador não ser mais prejudicial a mais sistemas com freqüência maior.

Meu desejo costuma ser de que houvesse uma forma de conseguir estatísticas favoráveis em relação a isso, mas algo e o setor me dizem que muitas organizações – e muitos profissionais de TI – estão em operação como administradores locais. Na Winternals, quando optei pela execução como usuário, foi com a premissa de conhecer a dificuldade que era (como "prosumidor") e compreender em parte como o nosso produto, o Winternals Protection Manager, poderia ajudar uma organização de médio porte. Considerando que a maioria das organizações estava, e continua, executando com uma porcentagem considerável de usuários como administradores, a nossa meta era habilitar os administradores para a execução como usuários, mas diminuindo o máximo possível – ou ao menos os pontos problemáticos – a transição. Independentemente da tecnologia usada por você, não é fácil migrar a organização de uma na qual os usuários são administradores para outra em que eles são usuários, embora essa seja a forma única mais efetiva de reduzir a superfície de ataque dentro da organização. Considere esse um firewall interno do sistema porque é isso que ele é na realidade.

Como chegamos até aqui?

Fica aqui o meu desafio: encare essa

Caso ainda não tenha pensado na migração dos administradores para usuários, você deve. E fica aqui o meu incentivo para que você comece fazendo um teste com você mesmo. Não em uma máquina secundária, porque isso não vale. Faça um teste no sistema primário, o que você usa diariamente. Também deixaria o meu incentivo para que você testasse até mesmo sem usar o UAC (Controle de Conta de Usuário) se estivesse executando o Windows Vista®. Quando você começa a divulgar uma iniciativa dentro da organização no sentido de mudar algo, é uma boa idéia praticá-la antes dessa divulgação. Acho que você descobrirá que a execução como não-administrador não é tão difícil assim – e que, com a segurança agregada a partir disso, você realmente mudará a superfície de ataque da organização.

A ação da maioria dos usuários como administradores está enraizada no histórico do Windows®. Com as primeiras versões do Windows, antes do Windows NT® 3.1, todos os usuários interativos tinham tantos poderes quanto os seguintes – funcionalmente, não havia nenhuma segurança. No ambiente doméstico, isso não era de todo ruim; isso queria dizer que os softwares eram todos instalados da mesma forma. A pressuposição era de que o usuário era o proprietário do computador e de que todos os softwares eram instalados para os usuários desse computador.

Quando surgiu, o Windows NT certamente não tomou conta do mercado corporativo de imediato (deixemos o consumidor de lado). E dada a compatibilidade do Win32® entre o Windows de 32 bits e o Windows NT, a maioria dos fornecedores não refez os aplicativos exclusivamente por conta da infra-estrutura de segurança do Windows NT. Na verdade, só foi depois do Windows 2000 que muitos ISVs (fornecedores independentes de software) orientados a clientes começaram a prestar atenção no Windows NT. É claro que foi o Windows XP o responsável pelo problema porque ele encerrou a família 9x do Windows.

Mas os aplicativos continuaram sendo implantados, pressupondo que todos os usuários do sistema tinham acesso de gravação em Arquivos de Programas (usuários não têm) e em HKEY_LOCAL_MACHINE (HKLM) no Registro (usuários não têm), além de HKEY_CLASSES_ROOT (usuários não têm). Os jogos costumam ser os piores invasores na pressuposição do acesso; consulte o artigo de Matt Clapham sobre esse tópico em technetmagazine.com/issues/2007/02/Gaming.

Isso é problemático porque a maioria dos aplicativos em vários sistemas armazena os arquivos e as configurações do Registro nesses locais e você precisa estar apto a ler e a gravar neles para que possa instalá-los. Infelizmente, alguns aplicativos insistem na gravação nessas chaves após a instalação. Por exemplo, minha filha tem um jogo baseado em Flash. Ele tenta instalar um player personalizado sempre que você o executa – o que significa que, quando a minha filha o executa como usuário, e não como administrador, ocorre uma falha na inicialização do aplicativo com um erro fatal. Embora isso seja algo extremo, além de ser um aplicativo do cliente, a realidade é que muitos aplicativos não-clientes ainda não vão muito bem no mundo dos usuários não-administrativos. Na verdade, se acompanhar o meu desafio (consulte a barra lateral, "Fica aqui o meu desafio: encare essa"), você descobrirá em que medida o próprio Windows não é tolerante à execução como usuário.

Se observar a Figura 1, você verá como é a execução de IPConfig /release como usuário no Windows XP. Se compará-la com a Figura 2, você verá que o mesmo comando no Windows Vista não é tão melhor assim, mas ao menos sabe por que está havendo uma falha. Observe que as ferramentas de rede foram, como um todo, aprimoradas para permitir que os usuários atualizassem os endereços IP. Da mesma forma, a tentativa de executar Gerenciamento de Computador (compmgmt.msc) como usuário permite realizar um número limitado de tarefas, embora normalmente resultem em becos sem saída, como mostrado na Figura 3. Embora não habilite inicialmente muitas das ferramentas no Gerenciamento de Computador, o Windows Vista apresenta mensagens de acesso negado mais claras.

Figure 1** Running as a user under Windows XP **(Clique na imagem para aumentar a exibição)

Figure 2** Running as a user under Windows Vista **(Clique na imagem para aumentar a exibição)

Figure 3** Misleading message after running compmgmt.msc as a user on Windows XP **(Clique na imagem para aumentar a exibição)

Por que isso é importante

Então por que você deveria se preocupar com isso? Porque nós, como profissionais de TI, devemos começar a forçar o ajuste dos aplicativos em relação a usuários com menos privilégios, e não o contrário, quando os aplicativos pressupõem que o usuário interativo é o proprietário do sistema.

Infelizmente, as mesmas diretivas que permitem aos administradores gravar em chaves do Registro também concedem a qualquer execução de malware, no contexto do usuário, acesso total a tudo o que eles não tiverem negado explicitamente por meio das ACLs (listas de controle de acesso). No mundo do UNIX, as pessoas seguem a regra a respeito da não-execução como raiz (o equivalente funcional da conta Administrador do Windows) principalmente porque o ecossistema do software que ultrapassa os limites do modelo de segurança é mínimo, praticamente inexistente.

Enquanto isso, o melhor que você tem a fazer é seguir essa sabedoria e só executar como administrador quando isso for explicitamente necessário – melhor ainda, só execute aplicativos individuais como administrador. Fazendo isso, você melhora aquele firewall interno do sistema que mencionei anteriormente. Dessa forma, quando um malware ou spyware tenta fazer algo que não deveria, ocorre uma falha – porque ele não consegue gravar no Registro ou nos locais do sistema de arquivos para, de fato, infectar o sistema (como, por exemplo, instalar um serviço ou driver ou aplicar uma instalação a todos os usuários). Além disso, existe a permissão para que o software antimalware tenha o malware que ele reconhece sem que todo o sistema seja colocado em risco inicialmente.

Observe, no entanto, que os usuários não estão imunes ao ataque. Embora essa classe de malware ainda não exista em larga escala, existe o potencial para que o malware consiga infectar o contexto de um usuário individual ou destruir seus dados. Porém, o vetor de ataque proporcionado por esse software é limitado. Dessa forma, o mesmo que mantém poucas as instâncias de malware em Linux ou no Macintosh (o menor número de vítimas em potencial o torna um parque menos divertido para autores de malware) pode ajudar a garantir a segurança geral dos usuários finais – e a sua – atualmente.

Usuários menos avançados?

Quando estávamos desenvolvendo o Protection Manager, um dos comentários que ouvíamos dos clientes era "estamos executando o Windows XP com todos os nossos usuários como sendo avançados, e não administradores, logo, estamos protegidos". No entanto, a realidade é que usuários avançados estão a apenas algumas etapas dos administradores. Há várias deficiências em potencial que poderiam, com um mínimo de trabalho, permitir a um usuário avançado do Windows XP se tornar um administrador. Na verdade, o grupo de usuários avançados foi eliminado no Windows Vista e no Windows Server® 2008; apenas um sistema atualizado de uma versão anterior do Windows contará com um grupo de usuários avançados. Afinal, você deve sempre evitar usar o grupo de usuários avançados, mesmo que esteja usando o Windows XP.

Permissões com perdas

Se leu a minha coluna de março sobre clientes finos do Windows (technetmagazine.com/issues/2008/03/DesktopFiles), você se lembrará de que fui contra a possibilidade de diminuir o Windows XP para economizar espaço. No mesmo sentido, existe uma prática comum de permitir a migração de administradores para usuários que você deverá considerar, embora tomando cuidado. Trata-se de prática de ajustar as ACLs no Registro e no sistema de arquivos de forma que os usuários possam gravar em locais nos quais normalmente não podem – daí, habilitando aplicativos problemáticos.

Obviamente, a melhor opção é obter uma versão atualizada de um aplicativo que não exige essa alteração, mas isso nem sempre é possível. Caso precise alterar as permissões (ou seja, descartá-las), proceda com muito cuidado. Lembre-se de que o firewall entre um usuário e um administrador é, em grande parte, definido pelas permissões do Registro e do sistema de arquivos. Abri-las reduz a proteção e pode ampliar a superfície de ataque proporcionada pelo malware – assim, faça isso com moderação.

E o UAC?

Nenhuma discussão da migração dos usuários de administradores para usuários está completa sem abordar o UAC do Windows Vista. O UAC, assim como a funcionalidade semelhante do Mac OS X, permite a execução "como administrador" sem que você corra tantos riscos.

Como isso funciona? Observe a Figura 4 na qual o Process Explorer está mostrando informações sobre cmd.exe. A instância de cmd.exe à direita foi iniciada sem elevação comigo em execução como administrador. Dessa forma, mesmo que o usuário à direita seja idêntico ao da esquerda (em que cmd.exe foi iniciado com elevação), o aplicativo propriamente dito não contém os privilégios necessários e os tokens dele (e do usuário que está executando essa instância) para realizar tarefas que exijam direitos administrativos. O UAC funciona reduzindo a superfície de ataque dentro de um contexto interativo do usuário. O único problema é que algo precisa informar ao Windows que essa tarefa exige privilégios administrativos e que o usuário concorda em permitir a elevação necessária à conclusão dessa tarefa.

Figure 4** Two instances of cmd.exe with different privileges **(Clique na imagem para aumentar a exibição)

Os escudos pequenos no Windows Vista mostram quais tarefas exigem elevação (consulte a Figura 5). Elas exigem elevação sempre que são executadas – e esse é um dos pontos críticos que a imprensa resolveu realçar em relação ao Windows Vista. A alternativa, deixar as credenciais serem mais "fixas", oferece uma ameaça potencial à segurança que poderia ser usada para explorar mais facilmente o sistema.

Figure 5** Shields in Windows Vista indicate the need for elevation **(Clique na imagem para aumentar a exibição)

Se o UAC estiver habilitado e os usuários estiverem em execução apenas como usuários, será solicitado a eles um conjunto de credenciais administrativas quando um aplicativo exigir privilégios administrativos. Observe que, nesse caso, assim como durante o uso de runas ou psexec, esse aplicativo é literalmente executado no contexto do usuário da inicialização, ao contrário do UAC, executado como um administrador. Nessa situação, as tarefas são executadas no seu contexto, mas com privilégios elevados.

Executando o Windows Vista como um usuário?

A minha preferência pessoal ao executar o Windows Vista é pela efetiva execução como usuário, e não como administrador com UAC, porque acredito que, em empresas de médio porte, essa ainda é a melhor idéia. Afinal, os usuários têm controle total sobre seus sistemas e você talvez tenha reduzido a abertura para o malware.

Além disso, caso pretenda gerenciar os usuários usando Diretiva de Grupo, antivírus, antimalware ou outro tipo de software e queira um controle centralizado sobre a imposição ou a conclusão efetiva dessas tarefas, garantir que os usuários finais não sejam administradores é uma etapa crítica. Caso sejam administradores, os usuários podem interromper serviços, adicionar ou remover drivers e muito mais. É claro que um usuário final hábil em execução como usuário pode usar o Windows PE para ignorar algumas barreiras de segurança. O BitLocker® pode dificultar isso, mas, mais uma vez, lembre-se de que usuários finais com acesso físico podem fazer o que querem em sua máquina, desde que haja tempo suficiente, conhecimento e dedicação.

Executar o Windows Vista como usuário não é tão diferente de executar o Windows XP como usuário. Uso as mesmas ferramentas – PSExec, RunAs (e agora UAC) – para executar as tarefas como um administrador quando necessário. O legal é que algumas tarefas no Windows XP que costumavam exigir privilégios administrativos deixaram de exigi-los. Por exemplo, um usuário do Windows Vista pode instalar uma impressora local. (As impressoras em rede podiam ser instaladas por usuários no Windows XP, mas a instalação de uma impressora local exigia um privilégio administrativo.) No Windows Vista, desde que esteja fisicamente na máquina e o driver da impressora esteja no repositório de drivers, o usuário pode instalar uma impressora e gerenciar seus trabalhos de impressão (consulte go.microsoft.com/fwlink/?LinkId=111534 para obter mais informações). Observe que essa funcionalidade está desabilitada no Windows Server 2008.

Obviamente, as pessoas se divertem com a funcionalidade do relógio (ou com sua falta) durante a execução como usuários no Windows XP – tente clicar duas vezes no relógio como usuário (algo que as pessoas costumam fazer para saber a data, independentemente dele ter sido projetado para funcionar dessa forma), e você obtém o erro mostrado na Figura 6. Nada amigável. No Windows XP, é possível modificar a diretiva de forma que os usuários possam fazer isso, mas no Windows Vista houve uma alteração para que o funcionamento fosse dessa mesma forma. De modo geral, a execução como usuário – independentemente do uso do UAC ou da execução como usuário formal e da elevação como outro usuário – costuma ser mais agradável no Windows Vista do que era no Windows XP.

Figure 6** In Windows XP, non-admins couldn't change the time **(Clique na imagem para aumentar a exibição)

Lembre-se dos limites

Não se esqueça de que migrar usuários para não-administradores não é uma solução completa. Usuários finais dedicados continuam localizados fisicamente em seus PCs e podem muito bem trabalhar para explorar seus próprios sistemas, especialmente se a diretiva ou os privilégios de usuário forem inconvenientes a eles ou os impeçam de realizar seu trabalho.

Caso os seus usuários estejam em execução como administradores, não requer muito trabalho ignorar uma Diretiva de Grupo in-loco. É claro que, com um pouco mais de trabalho, os usuários podem inicializar usando o Windows PE e modificar as permissões para as quais eles normalmente não teriam privilégios – embora, caso use o BitLocker ou outra criptografia de unidade/volume, você possa inviabilizar isso ou, ao menos, dificultá-lo.

A coisa mais importante que é possível fazer caso a organização ainda não tenha iniciado a migração dos usuários finais para a execução como usuários é se familiarizar com os motivos pelos quais você e a organização devem perder tempo, dinheiro e esforços para deixar de ter usuários em execução como administradores.

Certamente, os aplicativos herdados podem ser mais difíceis de se desfazer, mas caso você tenha um aplicativo que simplesmente não pode ser executado como usuário, é má idéia mantê-lo colocando em risco a segurança da organização. Você deve considerar a virtualização do aplicativo – migrando-o literalmente para uma máquina virtual em que o usuário é, de fato, um administrador. Isso permite que o aplicativo seja usado conforme necessário, e ainda continua possibilitando que você proteja o restante do sistema migrando os administradores para usuários.

Observe que, ao longo desta coluna, não usei a palavra "bloqueio" ou nenhum de seus derivados. Muitas pessoas consideram a migração de administradores para usuários parte de uma tarefa normalmente descrita com essa palavra. Talvez seja por conta do meu passado na psicologia ou do meu mundo atual do marketing, mas acho importante não usar palavras que façam com que os usuários finais sintam que seus privilégios estão sendo tomados (ainda que, em um nível semântico, estejam).

Em vez de fazer isso, se concentre nos benefícios de segurança oferecidos à organização e verifique se você conta com um bom plano para casos extremos em que um determinado usuário absolutamente não pode estar em execução como usuário ou em que há uma tarefa específica que exige privilégios administrativos. Independentemente de usar algo manual como o meu script Run.vbs (que você encontrará em technetmagazine.com/issues/2007/03/DesktopFiles) ou uma solução comercial para ajudar na migração (isso permite ocultar os detalhes dos usuários finais e faz as coisas "funcionarem"), é importante pôr o pé na estrada do não-administrador assim que possível. O colaborador assíduo da TechNet Magazine Aaron Margosis é o entusiasta quando se aborda a execução como não-administrador. Caso não esteja familiarizado com seu blog, você deve – trata-se do melhor local para procurar informações aprofundadas sobre esse tópico (consulte blogs.msdn.com/aaron_margosis).

Wes Miller é o gerente sênior de produto técnico atual da CoreTrace (www.CoreTrace.com) em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programa na Microsoft. Entre em contato com ele pelo email technet@getwired.com.

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