Dependências de Segurança em Ambiente Windows

O guru Marcus Ranum começou a fazer os seus próprios podcasts, e logo no primeiro (slides, transcrição) ele se propõe modestamente a enunciar as leis da segurança de computadores. Vale a pena ler e ouvir tudo, mas vou me fixar aqui apenas na segunda lei: a que diz que confiança ("trust") é uma relação transitiva. Ou seja, se A confia em B e B confia em C, então A confia em C - mesmo que A não perceba.

Na Microsoft nós costumamos dar a isso o nome de "dependências". Em uma rede a segurança de uma sistema pode depender da segurança de outro sistema, que por sua vez pode depender da segurança de outros sistemas, e assim em diante. Como veremos adiante, por exemplo, a segurança de todos os computadores pertencentes a um domínio Active Directory depende da segurança de um servidor controlador de domínio, que por sua vez depende da segurança de todos os outros servidores controladores de domínio (incluindo o da filial de Fortaleza), que por sua vez depende da segurança física da sala onde o servidor está. Essas relação são transitivas, como diz Ranum, e a conclusão lógica é que a segurança de todos os sistemas ligados ao Active Directory da empresa dependem da segurança física do pequeno escritório de Fortaleza - e ninguém sabia disso!

Entender as relações de dependência é na verdade entender como a segurança da sua organização pode ser comprometida, e é portanto um passo fundamental para definir uma estratégia de segurança. O problema é que muitas vezes estas relações de dependência permanecem ocultas, o que impede que organizações tenham uma verdadeira idéia do seu nível de risco, e impede que os controles adequados sejam aplicados para reduzir ou eliminar as dependências indesejáveis.

Para ajudar na tarefa de identificar as dependências, eu listei aqui abaixo uma série de regras que você pode usar identificar dependências em ambientes Windows. Essa não é uma lista exaustiva - outras dependências mais sutis vão com certeza existir, e somente analisando especificamente o seu ambiente seria possível identificar todas elas. Ainda assim acredito que elas cubram a maior parte dos casos e já forneçam uma boa idéia das dependências existentes.

 

1. Active Directory

A segurança de todos os computadores que fazem parte de um domínio Active Directory depende da segurança dos servidores controlador de domínio. É simples assim. Se um controlador de domínio seu for comprometido um atacante pode resetar a senha de todos os usuários, ou definir uma política de grupo que execute um programa qualquer nos computadores. Em uma análise de riscos de um ambiente Windows os controladores de domínio são sempre os ativos mais importantes.

Note que eu estou usando o plural aqui porque os controladores de domínio são replicados entre si, e comprometer um significa comprometer todos os demais. Isso vale inclusive para domínios diferentes dentro de uma mesma floresta - não existe isolamento entre estes domínios, e se um for comprometido todos os outros podem ser afetados.

Isso muda no Windows Server 2008 com os Read Only Domain Controllers (RODC), que forem projetados para não serem uma dependência de segurança do Active Directory caso sejam comprometidos, e por isso podem ser expostos diretamente na Internet com muito menos risco. A dependência no entanto continua no caso dos controladores de domínio regulares. A floresta como fronteira de segurança também permanece no Windows Server 2008.

2. Contas de Serviço 

As contas de serviço são a maior fonte de dependências ocultas em ambientes Windows. Opa, como assim? Vamos começar então do começo. Contas de serviço são utilizadas como identidade para rodar serviços como servidores Web, bancos de dados, correio eletrônico, bem como antivírus, agentes de backup, agentes de distribuição de software e de monitoração, entre outros. Ao ser iniciado o serviço se autentica no Windows usando as credenciais dessa conta, e é executado com os privilégios atribuídos a ela.

O problema é que para iniciar o serviço o Windows precisa ter a senha da conta "em claro" para que possa ser feita a autenticação. Isso significa que as senhas das contas de serviço precisam estar armazenadas localmente utilizando uma criptografia reversível e não simplesmente um hash, e que essas senhas podem ser acessadas pelo sistema. Traduzindo: se um computador for comprometido, um atacante pode obter facilmente todas as senhas das contas de serviço que estão configuradas naquele computador.

Suponha por exemplo que você instale um agente de backup em todos os seus servidores, que esse agente esteja rodando com a mesma conta de serviço em todos eles, e que essa conta tenha privilégios de administrador do sistema (ou semelhante -  veja adiante). A partir desse momento caso um servidor seja comprometido o atacante vai poder obter imediatamente a senha dessa conta, e acessar como administrador todos os demais servidores. A segurança de todos os seus servidores depende agora da segurança individual de cada um deles, e só por causa da conta de serviço de um agente de backup.

[Se a conta de serviço for administradora de domínio então...]

O que pode ser feito nesse caso? A Microsoft recomenda que você execute os seus serviços como LocalSystem, NetworkService ou LocalService, dependendo dos privilégios que o serviço necessite. Em especial se recomenda o uso dos dois últimos, que possuem os privilégios equivalentes ao de um usuário normal. Estas identidades não possuem uma senha associada e não podem ser utilizadas para comprometer outros sistemas. No Windows Vista e Windows Server 2008 ainda é possível restringir as permissões dadas a cada serviço e bloquear o acesso a rede quando desnecessário, reduzindo ainda mais a superfície de ataque e as possíveis dependências.

3. Privilégios

Outra fonte de dependências ocultas é o fato de, no Windows, um usuário poder ser efetivamente administrador e ter controle total sobre um sistema mesmo sem estar explicitamente incluído no grupo "Administrators" (ou "Administradores"). Basta que a conta de usuário tenha algum dos privilégios equivalentes, que podem ser vários:

¦ Act as part of the operating system - permite que o usuário possa se passar por qualquer outro usuário do sistema, incluindo o administrador.

¦ Debug programs - permite que o usuário possa injetar código em qualquer processo do sistema, incluindo os serviços rodando como administrador ou LocalSystem.

¦ Restore files and directories - permite que o usuário possa sobrescrever qualquer arquivo, inclusive binários do sistema, ignorando qualquer permissão.

¦ Replace a process level token - permite ao usuário criar um processo com qualquer identidade, incluindo a de administrador (requer o privilégio de increase quotas no Windows 2000 e anteriores).

Existem ainda outros. Se uma conta de usuário tem quaisquer destes privilégios, então a segurança do seu sistema depende da segurança desta conta.

Isso me lembra a vez em que fizemos uma análise de risco em um cliente, e apontamos o fato de um agente de um software de segurança rodar com uma mesma conta de serviço em todas os compuradores da organização, conta essa que era administradora do domínio. O fornecedor pesquisou e depois triunfalmente anunciou que a conta de serviço não precisava mais ser administradora do domínio - bastava que ela tivesse o privilégio de act as part of the operating system em todos os computadores...

4. Segurança Física

Por fim, a segurança de um computador depende sempre da sua segurança física. Essa é uma conseqüência de uma das leis imutáveis da segurança: se um atacante tem acesso físico irrestrito ao seu sistema, então este sistema não é mais seu. Mecanismos que usam chips TPM como o BitLocker fornecem um bom nível de proteção contra essa ameaça mas não a impedem totalmente.

 

Usando estas quatro regras você pode provavelmente identificar uma série de dependências no seu ambiente. O seu servidor de backup comanda uma conta de usuário que tem privilégio de restore files and directories nos seus servidores -> a segurança dos seus servidores depende da segurança do servidor de backup. Os seus notebooks rodam o antivirus com uma conta de serviço que é administrador do domínio -> a segurança de todos os seus sistemas dependem da segurança física dos seus notebooks. E assim por diante. Bom exercício!