Security WatchSistema de proteção de serviços no Windows Vista

Wole Moses

A Microsoft anunciou a Iniciativa de Computação Confiável no início de 2002, no rastro de diversos vírus e worms de perfil alto que causaram estragos em sistemas Windows, paralisaram departamentos de TI e cuja remediação custou enormes somas a empresas e consumidores. Com essa iniciativa, a Microsoft lançou um

mea culpa em relação a seu registro de rastreamento de segurança e fez uma rápida correção de curso, mudando o paradigma de desenvolver software com ênfase em recursos sofisticados e na capacidade de uso para a prioridade em torno de segurança e integridade de software. O worm Blaster fez sua investida em agosto de 2003, aumentando ainda mais o ímpeto da iniciativa de segurança. (Para conhecer a estória do Blaster, consulte a barra lateral "Ataque dos clones".)

Os princípios da iniciativa de computação confiável são Seguro por Design, que dialoga com as filosofias de codificação segura; Seguro por Padrão, que trata de garantir que os componentes de padrão Windows® tenham a configuração mais segura possível; e Seguro na Implantação, que diz respeito à criação de ferramentas e à orientação prescritiva para ajudar empresas e consumidores a proteger sua infra-estrutura Windows.

A Iniciativa de Computação Confiável resultou, globalmente, em grandes avanços na segurança; infelizmente, o Windows XP nunca pôde aproveitá-la totalmente, pois foi lançado dois anos antes de a iniciativa ter início. (Embora o Service Pack 2, SP2, tenha feito grandes progressos na incorporação dessas filosofias, o Windows XP não pôde ser inteiramente retroajustado para a iniciativa.)

Assim, o Windows Vista™ é o primeiro sistema operacional de área de trabalho da Microsoft a estar em conformidade total com as metas da Computação Confiável. O Sistema de Proteção de Serviços do Windows Vista, uma implementação específica do princípio Seguro por Padrão da Computação Confiável (consulte a Figura 1), é um recurso novo e importante, criado para impedir comportamento de serviço errôneo que uma boa parte do malware de hoje consegue executar. O Sistema de Proteção de Serviços ajuda a Microsoft a avançar na mudança do comportamento e do perfil de segurança padrão dos serviços do Windows.

Figure 1 Seguro por padrão: serviços do Windows

Serviços arriscados

Os serviços do Windows, anteriormente conhecidos como serviços do NT, são aplicativos executáveis de longa duração, executados em sessões próprias do Windows. Os serviços podem ser iniciados automaticamente quando o computador é inicializado, podem ser pausados e reiniciados, geralmente não exibem nenhuma interface do usuário e podem ser executados no contexto de segurança de uma conta diferente daquela do usuário no logon atual ou da conta padrão do computador. Os serviços do Windows são, portanto, um ótimo recurso para certos tipos de desenvolvimento de aplicativos e para usuários finais que necessitam usar esses aplicativos. No entanto, devido a sua potência e flexibilidade, os serviços do Windows têm sido, tradicionalmente, vulneráveis a exploit, por diversos motivos.

Primeiro porque, no passado, os serviços do Windows eram executados, geralmente, em contas do Windows com altos privilégios, como a conta Sistema Local. Se um serviço em execução na conta Sistema Local for comprometido por malware, esse terá uma grande chance de fazer absolutamente tudo o que desejar no sistema. Considere, por exemplo, o serviço de RPC (chamada de procedimento remoto) no Windows XP. Antes do Windows XP SP2, o serviço de RPC era executado na conta Sistema Local, o que permitiu ao Blaster, Welchia e outros worms realizar tarefas administrativas explorando a vulnerabilidade do RPC.

Segundo, porque muito serviços são de rede, o que dá ao malware a oportunidade de explorá-los por meio da criação de conexões de entrada para eles através da rede, fazendo com que o serviço infectado crie uma conexão de saída para infectar outros sistemas e realizar outras atividades ilícitas, como encaminhar pressionamentos de tecla monitorados. A maioria das infecções por worms e malware de hoje ocorrem através de algum método de conexão de rede.

Finalmente, porque os serviços são, normalmente, de longa duração, o que equivale a dizer que são executados desde o momento em que o sistema é inicializado até o instante em que é desligado. Isso é atraente para autores de malware, porque significa que podem testar o serviço quanto a falhas por todo o tempo em que o sistema estiver ativo, o que, por fim, dá muito tempo ao malware para realizar suas atividades nefastas.

Ataque dos clones

Poderia ser seu maior triunfo. Se tudo saísse conforme o planejado, ele poderia, em breve, controlar centenas de milhares de sistemas Windows em todo o mundo, emitir virtualmente qualquer instrução para eles e, depois, voltar e assisti-los transmitir obedientemente cada comando seu.

Persistente, ainda que evasivo em seus métodos, ele começou testando, sorrateiramente, diversos sistemas computacionais, em busca de um ponto de entrada vulnerável. Não demorou muito para que encontrasse exatamente o que estava procurando: um sistema não corrigido que sofria de uma vulnerabilidade que ele sabia muito bem como explorar.

O que tornava essa vulnerabilidade em particular tão sinistra era que, explorando-a com êxito, ele poderia ganhar acesso administrativo total ao sistema. Não estaria tomando o controle apenas de uma conta qualquer: estaria manipulando a conta administrativa mais poderosa do Windows. O que ele faria a seguir só poderia ser limitado por sua própria imaginação.

Após alguns momentos de reflexão, ele testou seu código trapaceiro contra o computador não corrigido e vulnerável; e funcionou! Simples assim, ele agora tinha privilégios ilimitados no computador. Ele usou seu acesso administrativo para obrigar o computador a fazer o download e instalar código de cavalo de Tróia, fazer modificações no Registro e, em seguida, reinicializar, transformando o sistema infectado em um assessor pronto e disposto a transmitir seus comandos. A modificação do Registro fez com que o software mal-intencionado fosse executado a cada reinicialização do computador.

Agora, suas intenções estavam claras. Ao ser infectado, todo o computador contaminado testaria portas de rede específicas de todos os outros computadores na rede. Se a porta de rede estivesse aberta e o computador fosse vulnerável, o código do cavalo de Tróia receberia download e seria instalado nesse novo computador. Ocorreriam as mesmas modificações no Registro. O ciclo se repetiria recorrentemente e, assim, estava criado um grande exército de clones pronto a atacar. Ao final do dia, milhares de sistemas Windows em todo o planeta fariam parte desse sinistro exército de clones, deixando de responder a todo comando que fosse emitido por qualquer outra pessoa no mundo.

Como não bastasse, ele se voltou, então, para o site do Microsoft Windows Update e instruiu todos os seus clones a realizar um Ataque de Negação de Serviço, em 15 de agosto de 2003, em uma tentativa de impedir todos os computadores do mundo de fazer o download da correção da vulnerabilidade, que, curiosamente, estava disponível havia meses.

A esta altura você, provavelmente, já se deu conta de que eu apenas descrevi a pandemia do worm MS Blaster que, em agosto de 2003, abateu computadores Windows em todas as partes do globo. O Blaster foi, indiscutivelmente, um dos ataques mais graves de toda a história do Windows, provocando um prejuízo de bilhões de dólares. A ironia é que, embora o MS Blaster tenha tido um poder enorme sobre os computadores que infectou, ele era notavelmente simples em sua implementação.

Como o Blaster funciona

O Blaster e seus derivados usam a vulnerabilidade do serviço de RPC do Windows para executar um estouro de buffer. Um agressor que explorasse com êxito essa vulnerabilidade conseguiria executar código com os privilégios do Sistema Local no sistema afetado, permitindo-lhe efetuar qualquer ação no sistema: instalar programas, visualizar, alterar ou excluir dados e criar novas contas com privilégio total.

No caso do Blaster, o worm verifica as redes, automaticamente, em busca de computadores com a porta TCP 135 aberta. Quando encontra uma vítima, o Blaster tentar explorar a vulnerabilidade de RPC. Se obtém êxito, ele se conecta à porta 4444 no destino e instrui o computador-vítima a inicializar o TFTP e fazer o download de uma cópia do worm, denominada MSBLAST.EXE, a partir do sistema infectado. (O TFTP é incluído como parte do sistema operacional no Windows 2000, Windows XP e Windows Server 2003). Em seguida, o sistema de ataque instrui o computador recém-infectado a inicializar o MSBLAST.EXE, fazendo com que o computador vitimado se torne um novo agressor. O Blaster também escreveu código na chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Run do Registro, o que o habilitou a ser executado em toda a reinicialização do computador.

Sistema de Proteção de Serviços

Os serviços foram fortalecidos e protegidos, no Windows Vista, de quatro maneiras: sendo executados com Privilégios Mínimos, Isolamento de Serviço, Acesso de Rede Restrito e Isolamento de Sessão 0. Discutirei todos em detalhe.

Executando com privilégios mínimos Muitos serviços do Windows eram, antes, executados no contexto da conta Sistema Local, a mais poderosa do Windows. A conta Sistema Local possui direitos e privilégios de usuário tais como a capacidade de acessar quase todos os objetos do sistema ou outro perfil de usuário, representar usuários, abrir chaves confidenciais do Registro, como: HKLM\SECURITY e apresentar as credenciais do computador a servidores remotos. Uma vez que os autores de malware adorariam ter esse nível de acesso e controle do Windows, é certo que todo o serviço em execução no contexto de Segurança do Sistema Local se tornariam um alvo saboroso.

Acontece que, embora uma série de serviços do Windows tenham sido configurados para execução na conta Sistema Local, muitos deles precisam, apenas, de um pequeno subconjunto dos privilégios exclusivos dessa conta. Infelizmente, o Windows XP e versões anteriores do Windows operam à maneira "tudo ou nada", o que equivale a dizer que não fornecem um mecanismo de seleção e escolha dos privilégios necessários. Assim, muitos serviços do Windows acabam, inevitavelmente, com privilégios de segurança excessivos e desnecessários.

O Sistema de Proteção de Serviços do Windows Vista cuida desse assunto, introduzindo o conceito de privilégios mínimos na configuração de serviços. Os privilégios mínimos permitem que os serviços sejam executados com o mínimo de privilégios necessários para que funcionem, em vez de obrigá-los a executar com todos os privilégios padrão atribuídos à conta que usam para fazer o logon.

Por exemplo, pode ser necessário que um serviço consiga atuar como parte do sistema operacional, mas não precise criar um token de segurança. Com privilégios mínimos, é possível remover o privilégio de criar tokens. Por conseqüência, são reduzidos os danos possíveis de serem causados por um agressor, caso o serviço se torne vulnerável a um explorador no futuro. Os desenvolvedores podem usar ferramentas de linha de comando, como o SC.exe (consulte a Figura 2), ou métodos de programação para definir e especificar aos privilégios suas necessidades particulares de serviços. Prontamente, a Microsoft aplicou os privilégios mínimos para reduzir os privilégios padrão em todos os serviços pré-instalados do Windows Vista.

Figura 2** As opções de comando do SC definem os privilégios dos serviços no Windows Vista **(Clique na imagem para aumentar a exibição)

Isolamento de serviço Nas versões do Windows anteriores ao Windows Vista, quando um serviço precisa acessar um objeto privilegiado (como uma chave do Registro ou arquivo confidencial), ele ganha acesso por um de três métodos: usando a conta Sistema Local para acessar o objeto; diminuindo a segurança na chave do Registro ou no arquivo para habilitar uma conta de serviço de menos privilégios e ganhar acesso; ou criando uma conta especificamente para o serviço e permitindo acesso a todos os objetos apenas por essa conta.

Embora todas essas abordagens funcionem, existem problemas básicos em cada uma delas. As duas primeiras são arriscadas por natureza e a última apresenta a dor de cabeça de ter que gerenciar senhas manualmente nas contas novas.

Suponha, por exemplo, que um programa antivírus instale um serviço que precisa de acesso a diversos objetos confidenciais do sistema, como o arquivo de assinaturas de vírus e entradas do Registro pertencentes ao software antivírus. Se o serviço antivírus estiver configurado para usar a conta Sistema Local ou, nesse quesito, qualquer outra conta de segurança interna para acessar seus objetos, isso poderia significar que, se algum outro serviço do Windows que use essa conta fosse infectado por malware, esse poderia, potencialmente, acessar e modificar os arquivos de assinatura de vírus, alterar configurações do Registro que afetam o modo de funcionamento do software antivírus ou, simplesmente, desligar de uma vez o serviço antivírus. De fato, os malwares de hoje usam exatamente algumas dessas técnicas para se manterem ocultos e funcionais.

O Windows Vista cuida dessas preocupações de segurança e capacidade de gerenciamento com o isolamento de serviço, que permite ao serviço reservar um objeto para uso exclusivo, protegendo o recurso – tal como acesso a arquivo ou chave do Registro – com uma entrada de controle de acesso que contém o SID (identificador de segurança) do serviço. Assim, o serviço antivírus descrito em nosso exemplo pode ser executado em uma conta de privilégios baixos e continuar a ter acesso a arquivos de assinatura ou chaves do Registro confidenciais. Para permitir esse acesso, o serviço antivírus (em execução nessa conta de menos privilégios) teria um SID atribuído pelo Windows Vista. Atribuído o SID, o programa antivírus pode, então, modificar as ACLs (listas de controle de acesso) de seu sistema de arquivos e objetos do Registro para dar acesso, exclusivamente, ao serviço antivírus.

Vou dar outro exemplo. Ainda em 2003, o worm Welchia começou a aproveitar uma vulnerabilidade de RPC para gravar a si mesmo em %System%\Wins\Dllhost.exe. Ele também adicionou chaves a HKLM\SYSTEM\CurrentControlSet\Services para instalar seus próprios serviços no sistema Windows infectado. Hoje, contudo, o Windows Vista poderia parar o Welchia, restringindo o acesso a ambos os locais aos serviços apropriados específicos e usando contas de menos privilégios para lhes conceder acesso.

Acesso de rede restrito O Windows Vista contém um novo firewall que se baseia nos recursos disponibilizados pelo firewall do Windows XP SP2. Os principais recursos novos compreendem filtragem de saída e integração de IPSec. O novo firewall também se integra com o Sistema de Proteção de Serviços do Windows Vista, para dificultar a execução de malware em um serviço explorado do Windows visando a realização de certas atividades de rede impróprias.

No firewall do Windows Vista, são atribuídas, aos serviços do Windows, diretrizes de firewall de rede que impõe limitações e restrições de comportamento. Por exemplo, a um serviço como o Plug and Play, que talvez nunca precise se comunicar por uma porta de rede, pode ser atribuída uma restrição de tipo "sem acesso de rede". Com essa restrição ativada, um exploit criado tendo em vista esse serviço em particular jamais o alcançará por meio de uma abordagem baseada em rede. Qualquer tentativa, de entrada ou de saída, de fazer comunicação através do serviço restrito seria bloqueada pelo firewall. Outros serviços que têm necessidades legítimas de acessar uma rede podem ser configurados de modo que usem somente portas específicas. Os desenvolvedores podem aproveitar esse recurso para restringir o acesso de rede de seus serviços.

As restrições de rede cooperam com o Sistema de Proteção de Serviços para proporcionar uma defesa robusta contra potenciais ataques baseados em serviços, o que representa um grande avanço em relação às versões anteriores do Windows. Antes, não havia um modo para o Windows decidir como, onde e quais serviços poderiam ter permissão de se comunicar através da rede. Todavia, usando as restrições da Rede de Firewall do Windows nos serviços de RPC, poderíamos evitar que vírus tais como Blaster, Sasser ou Welchia usassem serviços infectados para se comunicar com outros computadores.

Isolamento de sessão 0 A Troca Rápida de Usuário do Windows XP acomoda, simultaneamente, os usuários registrados por logon colocando cada um deles em uma sessão diferente do Windows. A sessão 0 é criada durante a inicialização e, conforme a necessidade, vão sendo acrescentadas mais sessões. Os serviços sempre foram executados na Sessão 0 e, antes do Windows Vista, os aplicativos de usuário também conseguiam executar nela. Contudo, há implicações de segurança arriscadas em executar aplicativos de usuário e serviços do Windows na mesma sessão, pois os serviços são executados com privilégios elevados, havendo, portanto, espaço para softwares mal-intencionados buscarem um meio de elevar seus próprios níveis de privilégios.

O Windows Vista cuida desses riscos de segurança reservando a Sessão 0 exclusivamente para os serviços, executando os aplicativos em outras sessões e tornando a Sessão 0 não interativa (o que significa que um serviço não pode criar uma interface de usuário, como uma caixa de diálogo ou prompt, que possa ser acessada por um usuário final). Devido a essas alterações, o Isolamento da Sessão 0 terá impacto sobre a compatibilidade de aplicativo de todos que desenvolvem serviços ou drivers do Windows.

Resumo

O Windows Vista é o primeiro sistema operacional de área de trabalho de Computação Confiável completa lançado pela Microsoft e contém avanços significativos que terão longa vida na proteção de usuários do Windows. A segurança computacional é, obviamente, uma disciplina em evolução e não há dúvida de que os autores de malware estejam fazendo constantes buscas, testes e pesquisas para descobrir maneiras de explorar o Windows. No entanto, os recursos do novo Sistema de Proteção de Serviços do Windows Vista erguem uma barreira significativa, aprimorando as configurações de segurança padrão e reduzindo a área de superfície potencial para ataques. Consulte microsoft.com/whdc/system/vista/Vista_Services.mspx para obter mais informações sobre esses aperfeiçoamentos substanciais.

Wole Moses é líder regional do Microsoft Windows e veterano da Microsoft há oito anos. Vivendo atualmente em Istambul, Turquia, Wole trabalha com os clientes do maior mercado emergente do Oriente Médio e África para ajudá-los a imaginar e criar soluções baseadas em Microsoft que otimizem sua infra-estrutura de TI ao mesmo tempo em que maximizem a segurança.

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