Gerenciamento da Segurança - Novembro de 2005

Como Atirar em seu Próprio Pé com Segurança, Parte 2: ACL ou Não ACL

Publicado: 8 de novembro de 2005

Por Jesper M. Johansson
Estrategista de Segurança Sênior
Unidade de Tecnologia da Segurança
Microsoft Corporation
Veja outras colunas sobre Gerenciamento da Segurança (em inglês).

A "verbificação" das línguas é algo maravilhoso, não é? ACL é apenas uma das adições recentes à poderosa lista de novos verbos disponíveis em inglês. ACL significa Access Control List (Lista de Controle de Acesso). Entretanto, você provavelmente já ouviu alguém usar a sigla como um verbo, em um contexto como "você precisa 'ACL' a partição de boot assim nem Todos poderão acessá-la".

Se o uso de substantivos como verbos faz os lingüistas subirem pelas paredes, frases como essa devem fazer o mesmo com os profissionais da segurança. O mau uso de ACLs é mais um dos modos bastante comuns de atirar em seu próprio pé com segurança. Neste artigo, parte 2 de uma série com várias partes sobre como não lidar com a segurança, discutiremos alguns dos problemas comuns que ocorrem com o uso de ACLs.

Introdução às ACLs

Antes de falarmos sobre os diversos métodos para atirar no próprio pé com as ACLs, precisamos discutir algumas noções básicas sobre elas. Se você já sabe o que são e como funcionam, talvez queira ir direto para Atirando Em Seu Próprio Pé com ACLs. As ACLs são usadas para controlar o acesso de sujeitos a objetos. Os termos sujeito e objeto merecem uma definição. Um sujeito é basicamente um superior de segurança no sistema. Pode ser um usuário, ou alguma outra entidade identificável, como um programa. Por exemplo, como parte do trabalho de fortalecimento no Windows Vista, um serviço será agora uma entidade identificável que pode ter permissões associadas a ela.

Um objeto é qualquer entidade a ser protegida. Nos sistemas operacionais baseados em Windows NT, como Windows 2000, Windows XP, e Windows Server 2003, qualquer objeto pode ser protegido. Isso inclui coisas em que pensamos diariamente, como arquivos, chaves de registro, e objetos do Active Directory; assim como as coisas em que não pensamos (a menos que sejamos programadores), como pipes nomeados, mutexes, seções importantes, processos, objetos SAM, e serviços.

Há na verdade vários tipos de ACLs. Os três tipos básicos são:

Uma ACL é simplesmente uma lista de Entradas do Controle de Acesso (ACE). Cada ACL contém 0 ou mais ACEs. Se nenhuma ACE estiver presente na ACL, significa que nenhum usuário tem o tipo de acesso representado pela ACL.

Se você quiser mais informações sobre ACLs, como elas trabalham, e como o sistema operacional as analisa, por favor vá a Windows Platform SDK para encontrar informações técnicas mais detalhadas. A discussão sobre Estruturas de Autorização é um bom lugar para começar. Proteja Sua Rede Windows também tem uma seção detalhada sobre como as ACLs realmente trabalham. Daqui por diante, usaremos o termo ACL para nos referir às ACLs genericamente, abrangendo conceitos comuns tanto às DACLs como às SACLs. Apenas quando nos referirmos especificamente a um tipo ou outro, usaremos os termos DACL ou SACL.

Início da página

Atirando Em Seu Próprio Pé com ACLs

Há muitas maneiras de usar ACLs, e algumas levam ao resultado esperado, ao passo que outras têm conseqüências terríveis. Neste artigo, veremos:

Cada um desses itens pode causar problemas, alguns mais graves que outros. Infelizmente, muitos também não entendem que se você estabelece ACLs incorretas, há poucas maneiras de se recuperar. Na verdade, se você destruir as DACLs-padrão nos arquivos do sistema operacional, há apenas uma ferramenta garantida de reversão:

Format c:

Não há como reverter ACLs de modo automático. Você pode obviamente exportar ACLs, e há ferramentas para isso. Há até mesmo ferramentas que gravam essas ACLs novamente nos objetos. Contudo, nenhuma delas sabe o que fazer com objetos que não existiam quando o estado do sistema foi registrado, ou com objetos que deliberadamente tiveram suas ACL alteradas desde esse registro. ACLs são propriedades dos objetos, não do registro ou sistema de arquivos. Se o objeto não existia quando o estado do sistema foi registrado, ou foi deletado depois disso, não é possível reaplicar uma ACL antiga. Se você registrar o estado do sistema e então imediatamente reaplicá-la, essas ferramentas provavelmente funcionarão. Entretanto, se você fizer algo com o sistema entre o momento do registro e o momento em que reaplica a ACL, as conseqüências podem ser terríveis.

Início da página

Substituição Coletiva das ACLs

Por muitos anos tem estado na moda realizar substituição coletiva das ACLs para "proteger" o sistema. Por exemplo, se você olhar a ACL em %systemdrive%\boot.ini, ela contém uma ACE para Power Users (Usuários Avançados). Muitas pessoas acreditam que se você simplesmente remover todas as ACEs para Usuários Avançados, já conseguiu conter esse grupo. Não é verdade. Há um fato muito simples sobre Usuários Avançados que você precisa saber:

Usuários Avançados são administradores que simplesmente ainda não se tornaram administradores.

Você não pode remover as ACLs no sistema de arquivos, ou até mesmo o registro, e evitar problemas. Usuários Avançados estão arraigados no sistema operacional, e têm privilégios suficientes para tornarem-se administradores facilmente. Você não pode usá-los para conter usuários não confiáveis. Só servem para impedir que usuários bem intencionados prejudiquem a si mesmos e ao sistema operacional acidentalmente. No entanto, muitas organizações têm diretivas que incluem tentativas de limitar os Usuários Avançados realizando substituição coletiva de DACLs. O mesmo tipo de diretiva é comumente usado para substituir o grupo Todos por Usuários Autenticados ou Usuários do Domínio, de que falaremos abaixo. Infelizmente, tentativas de realizar substituição coletiva de DACLs geralmente têm efeitos desastrosos.

Para entender por quê, considere o exemplo das DACLs-padrão no sistema de arquivos (o Windows, como padrão, não tem nenhuma SACL especificada no sistema de arquivos ou registro). As DACLs-padrão são exibidas em um arquivo chamado %systemroot%\security\templates\setup security.inf. Esse arquivo não é, como muitos pensam, o modelo aplicado durante a instalação; na verdade é o contrário. O arquivo de instalação security.inf é criado durante a instalação, como um registro do estado das configurações aplicadas durante a instalação. As configurações realmente aplicadas vêm de outro modelo e configurações que diversas rotinas de instalação desempenham durante a instalação. O arquivo que especifica os parâmetros de segurança padrão se chama %systemroot%\inf\deflt<systemtype>.inf, em que <systemtype> é o tipo de sistema que você tem. Nenhum desses arquivos é suficiente para reverter, no entanto. Por exemplo, defltsrv.inf (para servidores) não contém o diretório DACL para %systemroot%\inetsrv. Esse diretório, usado para IIS, não é instalado durante a instalação no Windows Server 2003. Conseqüentemente, se a DACL desse diretório for destruída, defltsrv.inf não terá as informações para reverter.

O que é pior, alguns diretórios têm uma DACL que é alterada a cada operação. Considere a lixeira, por exemplo (localizada em %systemdrive%\recycler). A DACL no diretório, herdada de %systemdrive% é:

Quando um usuário faz logon e deleta um arquivo, um novo diretório para esse usuário é criado em %systemdrive%\recycler. A DACL nesses diretórios é agora estabelecida parcialmente, baseada na herança de %systemdrive%\recycler e em parte programaticamente. Isso significa que uma ACL nesse diretório pode conter as seguintes entradas (os identificadores reais de segurança usados aqui são somente exemplos):

Essas são basicamente DACLs de controle total e apenas herdadas, concedendo controle total a filhos para três usuários: BUILTIN\Administrators, NT AUTHORITY\System, e o usuário proprietário dessa lixeira. Aí está o problema; esses diretórios ignoram a DACL especificada no pai. Se um administrador decide realizar substituição coletiva das DACLs para se livrar de Usuários Avançados ou Todos, o modo mais comum de fazê-lo é definir uma ACL que você quer no diretório %systemdrive%. Uma freqüente, que tem sido recomendada em inúmeros guias de segurança, é esta:

Os guias então são orientados a propagar essa DACL a toda a árvore. Isso significa que a lixeira não trabalha mais para usuários não-administradores. Eles agora só têm acesso de leitura à sua própria lixeira! Novos usuários talvez nem sequer criem uma lixeira, já que não têm mais o direito de fazê-lo. Por outro lado, todas as lixeiras agora têm a mesma DACL, portanto a lixeira do Administrador pode ser lida por todos os usuários, assim como todos os perfis de usuários, armazenados em %systemdrive%\Documents and Settings.

É fácil perceber como esse tipo de substituição coletiva das DACLs não apenas destrói o modelo de segurança no sistema, mas também enfraquece a segurança. Apenas tornou diretórios sensíveis, como todos os perfis de usuários, legíveis a todos os usuários. Reverter o sistema aos padrões é virtualmente impossível sem um esforço manual significante. Não há conhecimento inerente de quem deveria ter qual acesso aos diretórios. Por exemplo, o diretório de perfis de usuários é sempre propriedade de Administradores, não do usuário. O nome no diretório pode nem corresponder ao nome do usuário se um deles foi alterado. Por isso, o único modo de garantir uma reversão perfeita é reinstalar o sistema operacional. Qualquer outro método que não inclua reinstalação conta com a possibilidade de ter todas as ACLs detalhadamente especificadas.

Início da página

Substituindo Todos por Usuários Autenticados

É bastante comum que "especialistas" em segurança fiquem nervosos quando vêem ACLs especificadas para o grupo Todos no Windows. No Windows NT 4.0 e anteriores, essa era uma das ACEs mais comuns, e literalmente significava todos. Naquela época havia razão em se preocupar com o Todos em muitos aspectos. Desde o Windows XP, no entanto, essas preocupações são quase sempre injustificadas. Como padrão, o usuário anônimo não está mais incluído em Todos. Isso significa que Todos é funcionalmente idêntico a Usuários Autenticados no Windows XP e Windows Server 2003, a menos que o padrão da configuração "Todos incluem anônimos" tenha sido alterado. Portanto, há poucos casos em que vale a pena substituir ACEs com Todos.

Recentemente houve um cliente que queria deter usuários de outros domínios na floresta através da substituição de Todos por Usuários do Domínio. Isso é problemático não só por causa do que já dissemos sobre substituição coletiva das ACLs, mas também porque não resolve muita coisa com relação à segurança. A fronteira real de segurança é a floresta, não o domínio. Portanto, usuários com privilégios avançados em um domínio de uma floresta podem facilmente adquirir privilégios mais altos em outros domínios. Domínios dentro de uma floresta nunca foram planejados para servir como fronteira de segurança, mas sim como meros recipientes convenientes e unidades de gerenciamento.

Já me deparei várias vezes com o argumento de que se você tem que alterar o valor padrão de "Todos incluem anônimos" para permitir que Todos incluam usuários anônimos, então há uma razão legítima para realizar a substituição coletiva de Todos por Usuários Autenticados. Entretanto, tal raciocínio é falho. Primeiro, permitir que Todos incluam anônimos gera uma ampla série de brechas, e nem todas podem ser fechadas usando a substituição de ACL no sistema de arquivos e no registro. Segundo, se você tem uma razão para fazer esse tipo de substituição, normalmente é com o intuito de diminuir deliberadamente a segurança. Restabelecer seletivamente a segurança alterando as ACLs é basicamente assumir uma posição contrária à que o forçou a abrir as brechas, antes de mais nada. Finalmente, se acesso anônimo é o que você precisa, conceda acesso ao usuário ANÔNIMO. Isso gera acesso anônimo controlado de forma bastante granular, sem abrir brechas desnecessárias.

Um comentário final sobre Todos antes de prosseguir: Até o Windows XP a DACL padrão em compartilhamentos era Todos com Controle Total. Isso causava grande consternação a muitos usuários, para os quais isso significava que qualquer pessoa podia fazer qualquer coisa a todos os dados naquele compartilhamento. Não é bem assim. As permissões que o usuário tem em objetos de um compartilhamento são a combinação mais restritiva das permissões do compartilhamento e das permissões nos próprios objetos. Em outras palavras, se a DACL no compartilhamento diz "Todos:Controle Total", o que ela realmente quer dizer é "Não quero gerenciar permissões aqui." As permissões no compartilhamento não significam nada nessa situação. Apenas as permissões no sistema de arquivos controlam o acesso. Portanto, a menos que haja uma razão para restringir pessoas mais intensamente quando estão acessando arquivos da rede do que quando estão acessando-os localmente, não há motivo para alterar a permissão padrão em um compartilhamento. Talvez você queira usar ACLs de compartilhamento para proteger-se contra DACLs de arquivo potencialmente incorretas, mas nesse caso, é melhor consertar as DACLs de arquivos.

Início da página

Falhas na compreensão do SDDL

Muitas ACLs se romperam porque a pessoa que as criou não entendia SDDL. SDDL é uma linguagem muito complexa, e um tratamento completo sobre ela vai além do objetivo deste documento. Entretanto, se você vai criar manualmente modelos de segurança (que usam SDDL) ou escrever programas encarregados da segurança, precisa saber muito sobre SDDL.

Há alguns recursos para aprender SDDL. O primeiro é a Plataforma SDK. Procure na SDK por "Linguagem de Definição de Descritores de Segurança" como um ponto de partida. Proteja Sua Rede Windows também dá tratamento detalhado à SDDL.

Em lugar nenhum, no entanto, estão documentadas as pequenas alterações feitas no Editor de Configuração de Segurança (SCE) para SDDL padrão. O SCE também deixa um sinal na seqüência de caracteres da SDDL para descrever a disposição das ACLs existentes. Esse sinal pode ter valor de 0, 1, e 2, e tem o seguinte significado:

0. ACEs definidas explicitamente no objeto alvo são unidas às da seqüência da SDDL para chegar à ACL final

1. Usada apenas durante a instalação, mesma semântica de 2, mas incorre em processamento extra para garantir a aplicação completa da DACL

2. ACEs definidas explicitamente no objeto alvo são reescritas pelas da seqüência da SDDL.

Se você vai alterar significativamente as ACLs, é realmente necessário aprender como funciona a SDDL. Durante o processo você aprenderá muita coisa sobre o funcionamento das ACLs, e reduzirá bastante o risco de usá-las equivocadamente.

Início da página

Mau uso da herança

No Windows 2000 foi introduzido um modelo totalmente novo de herança de ACL. O novo modelo é grandiosamente mais potente que o anterior. É também muito mais complicado. Isso causa uma série de possíveis problemas.

O primeiro é não reconhecer que se você adicionar ou remover uma ACE a um diretório, ela também será adicionada a ou removida de todos os objetos e recipientes dentro daquele diretório que herdam a ACL do pai. Isso pode ter inúmeras conseqüências.

Outro conceito equivocado é o de que você pode remover as ACEs de uma ACL herdada. Você pode adicionar a uma ACL herdada, mas não remover algo dela. Se isso for necessário, você deve copiar a ACL e depois remover as ACEs que lhe causam problemas.

O ultimo problema é não usar a herança quando isso se justifica. Alguns softwares, e alguns administradores, definem explicitamente as ACLs em objetos até embaixo em uma hierarquia. Herança serve para facilitar a configuração de ACLs e torná-la menos propensa a erros.

Início da página

DACLs com opção Todos: Controle Total

DACLs para Todos que especificam Controle Total são quase sempre perigosas (veja acima um exemplo de quando não está em compartilhamentos). Alguns programas, no entanto, definem DACLs com opção Todos: Controle Total porque "senão os programas não funcionam como um usuário comum." Tentar fazer as coisas funcionarem como usuários regulares é admirável, mas o modo adequado de fazê-lo é consertar o programa para que ele não precise de DACLs com opção Todos: Controle Total. Em alguns casos, é necessária uma alteração no projeto. Até nos casos em que o programa é projetado adequadamente e há necessidade de acesso por Todos, quase nunca se justifica permitir controle total. Na maior parte do tempo ter apenas acesso a ler e executar é suficiente. Em alguns casos, talvez você precise conceder mais permissões do que isso, mas calcule com cuidado o mínimo de permissões necessárias e o conjunto mínimo de sujeitos que as necessitam.

O pior ofensor desse princípio na memória recente foi um dispositivo de autenticação biométrica que especificava uma DACL com opção Todos: Controle Total no diretório em que eram armazenadas as informações de identidade do usuário. Infelizmente, esse diretório também continha os binários, incluindo dois binários de serviço, que estavam rodando como NT AUTHORITY\System. Qualquer usuário pode agora substituí-los por qualquer programa que quiserem e esse programa vai rodar como NT AUTHORITY\System na próxima reinicialização. Isso proporciona uma elevação extremamente simples de ataques privilegiados ao computador.

Outro caso em que DACLs com opção Todos: Controle Total parecem ser comuns é quando usuários perceberam que algum aplicativo não funcionou, e tentaram resolver aplicando DACLs com opção Todos: Controle Total. Na verdade isso normalmente resolve o problema; desativar a segurança também. O problema é justamente a segurança ser desativada. O modo adequado de resolver essa questão é usar aplicativos como filemon e regmon para determinar qual é o conjunto mínimo de ACLs necessárias, e abrir apenas essas.

Início da página

DACLs com opção Todos: Negar

DACLs que negam acesso são muito problemáticas, particularmente quando são definidas para o usuário Todos. Em um incidente memorável há muitos anos, uma usuária pôs uma ACE com opção Todos:Negar em %systemdrive%. Após clicar em sim em todas as três caixas de aviso que apareceram, o sistema causou seu logoff e ela não conseguiu mais fazer logon.

Ela se esqueceu que Todos realmente significa todos e negar realmente significa negar! Na ordem de precedência de avaliação seguida pelo sistema operacional, ACEs com opção negar devem aparecer primeiro na DACL (note que não há nada especificamente que execute isso; cabe ao aplicativo encarregado das ACEs garantir que elas sejam classificadas corretamente). Conseqüentemente, elas são avaliadas primeiro. A verificação de acesso só continua até que uma das seguintes condições seja satisfeita:

Essa ordem de precedência é importante. Significa que ACEs com opção negar são muito, muito perigosas. Elas devem ser usadas com extrema limitação. Em quase todos os casos, não são realmente necessárias, a não ser como "defesa a fundo" contra configurações erradas. Embora esse possa ser um propósito valioso, é mais comum que as ACEs com opção negar causem problemas do que impeçam que qualquer pessoa acesse algo que não deveria acessar. Em geral, ACEs com opção negar devem ser evitadas.

Início da página

DACLs nulas

DACLs NULAS são raras, mas acontecem. Em uma DACL NULA simplesmente não há nenhuma DACL em um objeto. É diferente de uma DACL vazia, em que temos uma DACL mas não há nenhuma ACE nela. No caso anterior de DACL NULA, a semântica é que o usuário não quis proteger esse objeto e o efeito é o mesmo de quando a DACL lista "Todos:Controle Total." Na verdade, a maioria das ferramentas realmente exibe a DACL desse modo. Uma DACL vazia, por outro lado, dá a entender que o usuário não quer permitir acesso a ninguém e todas as tentativas de acessar o objeto vão falhar.

DACLs NULAS são mais comuns em construções de sistema operacional interno e objetos kernel. Contudo, podem ocorrer em qualquer coisa. Por exemplo, um jogo recente da Microsoft de fato estabelece uma DACL NULA em alguns arquivos no diretório de arquivos de programas. A recuperação nesse caso é bastante simples. Primeiro você deve tomar posse do objeto, já que apenas como proprietário você poderá estabelecer uma ACL. Então você aplica uma DACL adequada ao objeto. É necessário ser um administrador para fazer isso.

Início da página

SACLs excessivas

Não há nem de perto tantas maneiras de atirar em seu próprio pé com SACLs como há com DACLs. No entanto, uma se diferencia: SACLs excessivas. SACLs definem os tipos de acesso a auditoria. Uma ACE com opção Todos:Controle Total em uma SACL significa que você quer auditar tudo que qualquer pessoa faz ao objeto ao qual se aplica a SACL. Alguns guias de segurança estabelecem esses tipos de SACLs em todo o sistema de arquivos. Não passa de um exercício de ocupação do disco rígido. É bastante improvável que você se importe quando algum usuário lê o binário user32.dll. Esse tipo de recomendação era freqüentemente combinado com conselhos para ativar a configuração FullPrivilegeAuditing (chamada "Auditar: Auditar acesso a objetos do sistema global" na diretiva de grupo). Essa configuração garante que o sistema operacional vai auditar praticamente tudo que pode possivelmente ocorrer. Ativar essa configuração aumenta em cerca de 5 vezes o número de eventos de auditoria.

SACLs devem ser usadas moderadamente para rastrear atividades significativas especificadas na diretiva de segurança organizacional, e isso pode representar ameaças reais. Normalmente, acesso de leitura, ao menos em binários, não é interessante. Acesso de leitura em dados pode ser interessante dependendo dos dados, das ameaças envolvidas, e da filosofia de gerenciamento de risco da organização. Nunca se esqueça, no entanto, de que auditoria é uma atividade "pós-evento". Quando o evento é registrado, ele já ocorreu. Você não pode desfazê-lo com a auditoria. Você pode apenas rastrear sua ocorrência, supondo obviamente que o vilão não controla o registro de auditoria, caso em que não se pode nem sequer rastreá-lo.

Início da página

Falta de SACLs em Arquivos Confidenciais

Intimamente ligada à afirmação anterior está a falta de SACLs em arquivos confidenciais. O Windows, como padrão, é lançado sem nenhuma SACL no sistema de arquivos. Muitos clientes não percebem que não têm nenhuma auditoria no acesso ao sistema de arquivos, até serem atacados e solicitados a provar quando ocorreu e quem atacou. Esse é infelizmente um mau momento para descobrir que você não tem nenhuma pista de auditoria.

Você deve avaliar com cuidado o que fazer com relação à auditoria, quais objetos auditar, que tipos de eventos auditar, e como gerenciar os registros de auditoria. Essa é uma parte básica da disciplina de gerenciamento de risco e precisa ser feita em todas as organizações. Um conjunto básico de SACLs está disponível em scwsacls.inf, lançado com o Assistente de Configuração de Segurança (SCW) no Windows Server 2003 Service Pack 1. Essas SACLs são razoavelmente genéricas mas proporcionam um bom ponto de partida para definir o que você precisa auditar. Por fim, somente sua disciplina de gerenciamento de risco pode responder à sua pergunta.

Início da página

Conclusão

Neste artigo lidamos com outra questão que normalmente engana as pessoas. Problemas relacionados às ACLs constituem um dos grandes causadores de chamadas ao suporte da Microsoft, e muitos desses problemas se encaixam em uma das categorias mencionadas aqui. Esperamos que este artigo possa ajudá-lo a evitá-los, e talvez até sirva de apoio para seus argumentos contra aqueles que ainda acreditam nessas más práticas operacionais.

Se quiser aprender mais sobre ACLs, ou sobre as ACLs em um sistema específico, vale a pena mencionar três ferramentas. A primeira é o subinacl. O subinacl vêm com o Windows Server 2003 Resource Kit. Contudo, há uma versão atualizada no centro de download da Microsoft. É provavelmente a ferramenta de gerenciamento de ACLs mais versátil, potente, e perigosa que está disponível. É totalmente baseada em linhas de comando, e pode gerenciar ACLs em quase todas as entidades seguráveis, contanto que você possa decifrar a sintaxe correta.

A segunda ferramenta é o Access Enum da Sysinternals. O Access Enum é bastante simples, na verdade: ele enumera todas as subpastas, arquivos, ou chaves de registro que tenham permissões diferentes do pai. Pode ser muito útil como uma verificação rápida para identificar problemas óbvios.

Finalmente, o Security Expressions, da Altaris, é uma ferramenta que eles adquiriram da Pedestal Software. O Security Expressions tem um conjunto incrivelmente rico de funcionalidades. Especificamente para as ACLs, ele permite que você investigue uma hierarquia para achar objetos com uma ACE específica. Por exemplo, você pode pedir-lhe que enumere todas as chaves de registro que permitem escrita para Usuários. O Security Expressions trabalha com o sistema de arquivos e os registros, e é uma ferramenta valiosa em equipamentos de analistas de segurança.

Como sempre, esta coluna é para você. Se há algo que gostaria de ver, por favor envie uma mensagem clicando em Fale Conosco no final da página. Você pode também entrar em meu blog. Lá encontrará um thread em que podemos continuar as discussões sobre este artigo.

Início da página