Security WatchSaltos de ilha: redução de dependências indesejáveis

Jesper M. Johansson

Na última edição de Security Watch, abordei as etapas iniciais do uso de uma unidade flash USB para atacar uma rede. O ataque foi iniciado com a conexão de uma unidade flash USB infectada a um computador. Em seguida, o código malicioso foi executado automaticamente ou com mínima ajuda do usuário (fazendo uso de uma simples

engenharia social). Esse ataque permaneceu local à estação de trabalho, mas é evidente que o malware poderia se disseminar para o restante da rede. Abordo detalhadamente essa forma de ataque em uma rede no meu próximo livro, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008) e estou adaptando parte de um capítulo para esta coluna.

Obviamente, uma opção de proteção é proibir o uso de unidades removíveis. Embora possa parecer prudente, os usuários irão detestá-lo se você tentar fazer isso; e será complicado culpá-los por isso. A melhor opção, em todos os ambientes, com exceção dos mais confidenciais, é tentar administrar o risco envolvido e conter a exposição.

Além disso, as unidades removíveis são certamente o único método de comprometer um computador cliente. Você está lembrado das "10 Leis Imutáveis de Segurança" (disponíveis em microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Bem, o sentido geral da Lei 3 ainda é válido: "Se uma pessoa mal-intencionada tiver acesso físico irrestrito ao seu computador, o computador não é mais seu". No contexto desta discussão, se um invasor tiver acesso ao seu computador, esse computador deverá ser considerado comprometido. Isso pode ser realizado até mesmo remotamente se o invasor conseguir fazer com que você execute o código dele no seu computador. Você pode reconhecer isso como a Lei Imutável número 1: “Se uma pessoa mal-intencionada conseguir persuadi-lo a executar um programa em seu computador, o computador não é mais seu”.

É seguro pressupor que as leis imutáveis ainda são válidas – elas se mostraram extremamente flexíveis e é improvável que sejam alteradas de modo signicativo enquanto não alterarmos fundamentalmente o modo como os computadores funcionam. Então, considerando como essas leis se aplicam ao cenário descrito, é fundamental que você remova unidades removíveis. Além disso, você pode fazer isso com alguns ajustes do Registro.

É claro,você também deve usar camadas adicionais de proteção. Você pode pressupor razoavelmente que muitos de seus computadores cliente já foram comprometidos ou são operados por usuários que nem sempre consideram os melhores interesses de segurança da organização. Isso significa que você precisa reduzir esses efeitos no restante da rede e, assim, aumentar a importância da compreensão, da análise e da redução de dependências de segurança.

Definição de uma dependência de segurança

Uma dependência de segurança ocorre quando a segurança de um computador é dependente da segurança de outro. Você já deve ter ouvido alguém falar que se o seu DC (controlador de domínio) for atacado, toda a sua rede também será atacada. Essa é uma forma simplista de afirmar que todos os membros do domínio são dependentes nos DCs de sua segurança. Se o DC não for mantido seguro, os computadores membro não poderão ser mantidos seguros. Se um invasor puder alterar a configuração de segurança do domínio, ele poderá assumir qualquer computador no domínio ao, por exemplo, adicionar novas contas ao grupo de administradores em um computador membro. Qualquer vulnerabilidade que permitir comprometimento por um administrador não é nada interessante. Um administrador deve ter acesso total ao que quer que seja que ele esteja administrando.

As dependências nos sistemas de computador são inevitáveis. Na realidade, elas são comuns e freqüentemente desejáveis; no entanto, isso não significa que todas as dependências sejam aceitáveis. Nesta coluna, abordo quais tipos de dependências são aceitáveis e quais não o são; em seguida, analisarei os tipos de dependências e como reduzi-las. No Windows Server 2008 Security Resource Kit, abordo em mais detalhes as dependências específicas e como gerenciá-las.

Dependências aceitáveis

Em geral, uma dependência é aceitável quando um sistema menos confidencial depende de um sistema mais confidencial para segurança. Os computadores e sistemas em geral podem ser divididos em classes com base em seu nível de sigilo. (O conjunto específico de classes em qualquer ambiente específico é irrelevante para a discussão geral – tudo o que é importa é que há classificações inerentes.) Apenas para nossa discussão, vamos supor que tenho duas classificações: estações de trabalho e DCs. Nesse cenário, é aceitável que as estações de trabalho dependem de DCs para sua segurança. A classe de DCs é muito mais confidencial do que as estações de trabalho; portanto, obviamente, essa deve ser mais bem protegida.

O mesmo argumento pode ser feito para contas de usuários. É aceitável que um administrador possa comprometer os dados de propriedade de um usuário. Isso ocorre devido ao fato de os administradores terem mais responsabilidade e acesso irrestrito (embora nem sempre direto ou evidente) ao computador e a tudo que há nele. Se você compreender esse ponto e gerenciar os computadores adequadamente, não haverá nada de errado com essa dependência.

Até mesmo o software pode ser analisado da mesma forma. É certamente aceitável para uma parte menos confidencial do software, como um navegador da Web, que use e dependa de uma parte mais confidencial do software, como o sistema operacional, para sua segurança. Se o SO tiver um bug, o fato de o navegador da Web agora estar vulnerável a algum novo problema não será nenhuma surpresa e provavelmente está no final da lista de preocupações imediatas – o SO e outros dados e aplicativos críticos serão o foco principal de atenção. Isso tem a ver com como os bugs são corrigidos ou onde são instalados hotfixes – um bug deve ser corrigido o máximo possível do problema. Ao fazer isso, o impacto de proteção da correção é maximizado. Portanto, em vez de trabalhar para resolver o problema no navegador da Web, o próprio SO deverá ser corrigido.

Como alternativa, a dependência poderá ser removida alterando-se o projeto. Por exemplo, o navegador da Web poderá ser reescrito para reduzir suas dependências no SO. Essa última abordagem é apropriada nos casos em que a funcionalidade de componentes mais seguros (o SO, nesse caso) nunca tiver sido planejada para de fato ser usada da forma como o componente menos confidencial (o navegador da Web) a está utilizando.

Dependências inaceitáveis

Em decorrência da minha explicação de dependências aceitáveis, a definição de uma dependência inaceitável agora deveria ser óbvia. Basicamente, um sistema mais confidencial nunca deve depender de um sistema menos confidencial para sua segurança.

Se o comprometimento de uma estação de trabalho significar que a segurança do DC foi violada, você terá um sério problema de segurança em mãos. É impossível proteger uma rede se sua segurança agregada for dependente da segurança de cada computador nessa rede.

Considere isso estatisticamente. Se cada computador na rede estiver “seguro” 99,999% do tempo, você poderá achar que tem uma rede extremamente segura. Na realidade, esse percentual está provavelmente muito longe do que é a realidade em todas, exceto as menores redes hoje em dia. Agora, vamos supor que a sua rede tenha 40 mil computadores, qualquer um deles sendo vulnerável em 0,001% do tempo. Curiosamente falando, a sua rede geral estaria desprotegida em um potencial de até 40% do tempo.

E, é claro, com dependências não gerenciadas, é necessário apenas um computador nesse 0,001% de tempo para comprometer toda a rede. Nesses termos, o quão segura é a rede? É claro que é absolutamente fundamental que sistemas mais confidenciais estejam protegidos dos menos confidenciais.

Esse argumento pode ser facilmente ampliado para contas de usuários e software. Por exemplo, o novo cliente de Serviços de Terminal para Windows® permite que você armazene nomes e senhas de usuários para logon de Serviços de Terminal praticamente transparente. Essas credenciais são armazenadas usando a API do Credential Manager, protegidas pelas credenciais usadas para a sessão principal de logon.

Isso pode criar uma dependência de segurança. Considere o caso de uma administradora de rede fazendo logon em sua estação de trabalho pessoal. Ela usa essa estação de trabalho para email, navegação na Web e outras tarefas características de operadores de informações. Naturalmente, ela usa uma conta de domínio com poucos privilégios para esse fim.

Em algum momento durante o dia, essa administradora se conecta a um dos DCs para realizar determinadas tarefas de gerenciamento. Ela usa o cliente de Serviços de Terminal para fazer isso e escolhe armazenar sua senha para facilitar futuras conexões. Isso resulta em pelo menos uma, e possivelmente duas, dependências de segurança não aceitáveis. A primeira é que suas credenciais de conta administrativa de domínio agora são protegidas por suas credenciais de operadora de informações com poucos privilégios. Se essa conta de usuário com poucos privilégios for comprometida, a conta de usuário administrativo de domínio também será comprometida e, portanto, todo o domínio será comprometido.

A segunda dependência resulta do fato de que ela digitou uma credencial administrativa de domínio em um controlador que não é de domínio. A não ser que a estação de trabalho pessoal dela esteja tão protegida quanto os DCs – e provavelmente não está – haverá uma dependência na qual a segurança dos DCs dependerá da segurança dessa estação de trabalho pessoal do usuário. Se, por exemplo, um funcionário insatisfeito no mesmo escritório tiver instalado um agente de log de pressionamentos de tecla na estação de trabalho do administrador da rede, as credenciais administrativas de domínio agora teriam sido capturadas. A qualquer momento que digitar uma credencial administrativa de domínio em um controlador que não seja de domínio, você estará expondo todo o domínio a quaisquer falhas de segurança no controlador que não for de domínio.

Suponha agora que um invasor insira uma unidade removível em um computador no qual o administrador de domínio esteja atualmente conectado ou já tenha efeito logon ou até mesmo no qual efetuará logon. Esse administrador de domínio será comprometido e, por extensão, todo o domínio será comprometido. É fundamental que você compreenda essa situação para que possa evitá-la. E, é claro, a mesma situação pode acontecer com software quando um aplicativo seguro depender da funcionalidade de um aplicativo menos seguro para realizar determinada tarefa.

Análise de um ataque

Anteriormente, descrevi o que pode acontecer se uma unidade removível maliciosa for inserida em um computador. No entanto, talvez somente seja óbvio o que aconteceria ao computador no qual a unidade foi inicialmente inserida. Portanto, vamos supor que o computador em questão seja integrado ao domínio, conforme mostra a Figura 1.

Figura 1** Dependências ideais de domínio **

O cenário ilustrado aqui descreve uma dependência ideal. As setas são direcionais e indicam de onde a dependência é herdada. Por exemplo, a segurança da estação de trabalho depende da segurança do DC e a segurança do usuário é dependente da segurança da estação de trabalho. O invasor poderá comprometer a estação de trabalho, que poderia comprometer todas as informações que o usuário tiver inserido nessa estação de trabalho, mas o comprometimento nesse caso seria isolado.

Mas vamos supor que o usuário efetuando logon na estação de trabalho seja um membro do grupo de administradores locais no servidor. Além disso, digamos que o administrador do domínio faça freqüentemente logon no servidor. Agora, você terá as dependências mostradas na Figura 2.

Figura 2** Dependências de domínio comprometidas **

Ao simplesmente alterar a pressuposição de quem efetuou logon nos computadores em questão, a segurança de toda a rede pode ter sido comprometida. Como um administrador de domínio efetuou logon no servidor, a segurança do DC e, portanto, de todo o domínio é dependente da segurança desse servidor.

Isso seria aceitável se o servidor fosse gerenciado de modo tão seguro quanto o DC. No entanto, nesse caso, um usuário que efetua logon na estação de trabalho é um membro do grupo de administradores no servidor. Portanto, a segurança do servidor é dependente da segurança da estação de trabalho. Isso significa que a segurança de todo o domínio é dependente da segurança da estação de trabalho. E, adivinhe só: o usuário nessa estação de trabalho executou involuntariamente a ferramenta do invasor.

Há provavelmente alguns conceitos no atual mundo da segurança da informação que são mais importantes do que as dependências de segurança. Se você começar a analisar sua rede e tentar compreender o que são as dependências, você certamente encontrará dependências inaceitáveis. No pior cenário possível, que é muito mais comum do que você possa imaginar, a segurança de toda a rede é dependente de toda a rede – em outras palavras, a segurança de cada computador é, de alguma forma, dependente da segurança de cada computador. Portanto, é impossível criar qualquer tipo de estratégia de gerenciamento de risco razoável e realista nesse tipo de ambiente, pois as relações são impossíveis de controlar e a complexidade é incompreensível. A solução é analisar e gerenciar suas dependências.

Nesta coluna, apresentei somente uma breve visão geral das dependências e como você pode analisar e reduzi-las. Você pode encontrar mais informações no meu livro, Windows Server 2008 Security Resource Kit. Ele contém um capítulo inteiro dedicado ao tópico de segurança da rede ao analisar dependências e gerenciá-las usando técnicas avançadas, como Isolamento de servidor e domínio, bem como técnicas mais comuns, como gerenciamento de conta administrativa.

Gostaria de agradecer a David LeBlanc por me ajudar a desenvolver as idéias embrionárias que resultaram nesta coluna.

Jesper M. Johansson é arquiteto de software e trabalha com questões de segurança de software, além de editor-colaborador da TechNet Magazine. Ele possui PhD em MIS (sigla em inglês para Sistemas de Gerenciamento de Informação) e mais de 20 anos de experiência em segurança.

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