Security WatchRevisitando as 10 leis imutáveis da segurança, parte 1
Jesper M. Johansson
Em 2000, Scott Culp publicou um ensaio chamado "10 leis imutáveis da segurança". É um dos melhores ensaios que eu já li sobre segurança. As informações que ele apresentou continuam fundamentais para todo trabalho em segurança de informações e eu recomendo que você o confira (e até mesmo imprima), se ainda não o tiver feito. Você pode encontrá-lo em microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
O ensaio foi recebido com respostas variáveis. Algumas pessoas comentaram de modo sarcástico que era uma maneira de a Microsoft evitar corrigir aquilo que era percebido como vários problemas sérios. Outros o consideraram um dos textos mais básicos sobre segurança e o plagiaram à vontade devido à sua importância absoluta. Algumas das minhas respostas favoritas, no entanto, eram aquelas nas quais as pessoas foram inspiradas a criar suas próprias listas, como a que está disponível em edgeblog.net/2006/10-new-immutable-laws-of-it-security.
Nos oito anos, desde que esse ensaio foi publicado, muito aconteceu no campo da segurança. Praticamente todos os principais worms foram “lançados”. Entramos em um estado de guerra de informações (com crime organizado, entidades políticas e assim por diante). Uma variedade de palavras e expressões se tornou parte de um vocabulário comum, incluindo phishing, pharming, botnet, spyware e falsificação de solicitação entre sites. Temos alguns dos rootkits mais sofisticados já criados em execução no Windows. Temos novas versões de sistemas operacionais dedicadas, em grande parte, à segurança e outros sistemas operacionais onde a segurança ainda é amplamente ignorada.
A engenharia social se desenvolveu em uma ameaça maior. Violações de dados, como quando um importante varejista expôs 94 milhões de números de cartões de crédito, se tornaram notícias bem conhecidas (e, ainda, as pessoas continuam comprando em tais lojas). Os governos dos EUA e do Reino Unido, em conjunto, conseguiram guardar em lugares errados informações secretas sobre uma porcentagem significativa dos habitantes do mundo ocidental (e, ainda, as pessoas arquivam informações secretas com esses governos). E uma quantidade enorme do espetáculo da segurança entrou em nossas vidas — e em nossos aeroportos.
Acho que chegou a hora de dar uma outra olhada nas leis. Supondo que todas as alterações que vimos surgiram a primeira parte deste século, podemos ainda alegar que essas leis são imutáveis? Se forem — se sobreviveram nos últimos 8 anos — é provavelmente seguro dizer que elas irão sobreviver nos próximos 10.
Nessa série de três partes, examinarei de forma crítica cada uma dessas 10 leis. Neste mês, falarei das leis de 1 a 3. Na edição do próximo mês, irei examinar as leis de 4 a 7. E na última parte, irei examinar as leis de 8 a 10 e oferecer um assunto adicional para se pensar, além de comentários que parecem razoáveis, levando-se em consideração o que ocorreu desde que as leis foram originalmente escritas em 2000.
Lei 1: Se uma pessoa mal-intencionada conseguir persuadi-lo a executar um programa em seu computador, o computador não é mais seu.
Essa lei afirma, efetivamente, que qualquer software que você execute no computador pode controlar esse computador. Quando as leis imutáveis surgiram pela primeira vez, os sistemas operacionais atuais da Microsoft eram o Windows 98, Windows Me e Windows NT 4.0. Hoje, temos o Windows Vista e o Windows Server 2008.
No Windows 98 e Windows Me, qualquer software que você executava tinha controle total sobre o computador. O Windows NT 4.0 possuía um modelo de segurança subjacente muito sólido, mas se você o executasse como Administrador, você, efetivamente, fazia o downgrade de seu modelo de isolamento para o do Windows 98 e Windows Me. Era possível executar o Windows NT 4.0 como não-administrador, mas era bem penoso e pouquíssimas organizações o faziam (você provavelmente conseguiria contar o número total de organizações que faziam isso sem tirar seus sapatos).
Digamos que você executasse o Windows NT 4.0 como não-administrador. Então, a Lei 1 se aplicava mesmo quando foi escrita? A resposta é sim. Primeiro, o Windows NT 4.0 tinha um grande número de brechas significativas. Por exemplo, havia permissões que poderiam ter sido mais rígidas, particularmente em objetos do kernel e no Registro. Também existiam vários tipos de ataques que ainda não haviam sido descobertos, mas que os especialistas esperavam que fossem emergir. Por exemplo, em 1999, as pessoas não haviam percebido que ter processos em execução como usuários elevados na área de trabalho interativa poderia comprometer o computador. Somente em 2002, quando Chris Paget publicou seu white paper sobre ataques shatter, "Explorando a API Win32", que isso se tornou um conhecimento básico (seclists.org/bugtraq/2002/Aug/0102.html).
A Microsoft havia previsto os ataques shatter quando a Lei 1 foi esboçada? Na verdade não. A Microsoft simplesmente reconheceu um simples fato: existem pouquíssimos limites de segurança verdadeiros que podem impedir que um aplicativo em execução em um computador assuma o comando desse computador.
O Windows Vista e Windows Server 2008 são duas gerações removidas do Windows NT 4.0. Eles invalidaram a Lei 1? Existe algum outro sistema operacional que o fez? Depende. Certamente, existem limites de segurança mais sólidos nos novos sistemas operacionais e existiam alguns sistemas operacionais experimentais em 2000 que possuíam limites de segurança adequados. No entanto, ainda existem apenas alguns desses limites. Por exemplo, a segurança de acesso ao código no Microsoft .NET Framework é um limite de segurança. Ela é projetada especificamente para impedir que o código em execução na área de segurança afete o sistema operacional subjacente.
O Iframes no Internet Explorer proporciona outro limite de segurança. Mas o Iframes não afeta o acesso ao sistema operacional em si, apenas o acesso entre partes de conteúdo em uma página da Web. O Modo Protegido no Internet Explorer, mostrado na Figura 1, é um limite de segurança de nível de sistema operacional. Seu objetivo é impedir que códigos executados em um navegador afetem o sistema operacional subjacente — sem a ação do usuário. Existem alguns outros, como contas de usuário padrão, que devem impedir que uma conta de usuário afete o sistema operacional subjacente ou qualquer outro usuário.
Figura 1 O Internet Explorer 7 usa um limite de segurança chamado Modo Protegido (clique na imagem para ampliá-la)
É extremamente importante entender o que significa o termo "limite de segurança". Ele não significa que existe uma parede inviolável com garantia de fornecimento de um isolamento impermeável e indefinido. O que o termo realmente significa é que o fornecedor de software, a Microsoft por exemplo, é responsável por corrigir qualquer violação desse limite por meio de um patch de segurança. O software sempre terá bugs e, sem dúvida, continuaremos descobrindo mais violações que os fornecedores de software continuarão consertando. Com o tempo, eles devem melhorar seu software para impedir essas vulnerabilidades, em primeiro lugar. Isso pode ser considerado como confirmação de que a Lei 1 ainda é válida.
Existe uma parte mais crucial que preciso considerar, no entanto. Você pode ter observado anteriormente a expressão "sem a ação do usuário". A Lei 1 não é, na verdade, sobre limitações ou vulnerabilidades no software. Ela é, realmente, sobre vulnerabilidades nas pessoas! A expressão-chave é "persuadi-lo". Se uma pessoa mal-intencionada conseguir persuadi-lo a executar um programa, ele provavelmente conseguirá persuadi-lo a fazê-lo em um contexto que, intencionalmente, dá ao programa privilégios elevados.
Mesmo se você não possuir privilégios administrativos, pode não importar. Você, como usuário padrão, ainda tem acesso a muitas informações interessantes: seus arquivos de banco, cartas de amor, fotos, vídeos e dados confidenciais da empresa. Todos esses dados são potencialmente interessantes para um invasor e todos eles podem ser lidos sem qualquer privilégio elevado. Em termos das informações que você gerencia no seu computador, executar um programa mal-intencionado entrega tudo o que você faz ao invasor. Portanto, se você define "seu computador" como "os dados que você gerencia no seu computador", você pode ignorar qualquer discussão sobre privilégio e simplesmente concluir que a Lei 1 se aplica.
Mesmo sem discutir minuciosamente a definição de seu computador, a Lei 1 ainda parece ter resistido ao teste do tempo. A finalidade da Lei 1 é estabelecer o fato que você, como operador de um computador, deve assumir a responsabilidade pelo software que executa nesse computador. Se você instala um driver mal-intencionado ou um codec de vídeo perigoso, você entregou o controle completo desse computador a um criminoso!
Embora os fornecedores de software possam fazer muitas coisas para impedir um comprometimento acidental, que é, na verdade, ao que se resumem os limites de segurança, a execução intencional de software mal-intencionado irá geralmente superar todas essas medidas de proteção. É por isso que a educação do usuário é crucial, além de garantir que os usuários não tenham permissão de executar tarefas administrativas. Portanto, é seguro dizer que a Lei 1 se aplica hoje, mas possivelmente com uma leve modificação na definição de seu computador.
Lei 2: Se uma pessoa mal-intencionada conseguir alterar o sistema operacional em seu computador, o computador não é mais seu.
À primeira vista, essa lei parece bem direta. Obviamente, se a pessoa mal-intencionada conseguir alterar o sistema operacional em seu computador, você não pode mais confiar no computador. Mas o que se entende por sistema operacional mudou, à medida que as necessidades de computação se desenvolveram. Vários anos atrás, escrevi uma definição do termo “sistema operacional” para a enciclopédia de gerenciamento Blackwell (managementencyclopedia.com). A definição dizia algo sobre um sistema operacional gerenciando acesso a dispositivos de entrada e saída, acesso a hardware e essas coisas. Bem, nunca recebi uma cópia da enciclopédia e meu envio original foi perdido na história, mas estou certo de que não mencionei que um sistema operacional inclui paciência, um sistema de entrada para tablet e transcodificadores de vídeo.
Como a computação tem aumentado e ficado cada vez mais complexa, os sistemas operacionais cresceram para suportar muito mais recursos. Complicando ainda mais a questão, os OEMs muitas vezes incluem sua própria variedade de softwares adicionais — que normalmente varia de um pouco útil a totalmente prejudicial. E alguns desses softwares adicionais duplicam funcionalidades já existentes no sistema operacional principal.
Por exemplo, uma instalação padrão do Windows Server 2008 Enterprise Edition possui uma superfície de disco de mais de 5 gigabytes. O Windows Vista Ultimate Edition inclui mais de 58.000 arquivos, compreendendo mais de 10 gigabytes. E há mais do que apenas arquivos formando o sistema operacional. Existem configurações, milhares delas; e existem daemons ou serviços.
Todo e qualquer item desses faz parte do sistema operacional. É um termo coletivo que inclui todos os arquivos, todas as definições de configuração e todos os serviços, bem como todos os objetos de runtime — semáforos, pipes nomeados, pontos de extremidade RPC — criados pelos arquivos e configurações. Mesmo as construções altamente abstratas, como o tempo do sistema e certos tipos de dados, como conteúdo de log de evento, devem ser considerados como parte do sistema operacional.
Dado como o sistema operacional cresceu e se desenvolveu, modificar qualquer um desses arquivos realmente faz com que o computador não seja mais confiável? A resposta direta é não. Por exemplo, o Windows Vista vem equipado com edlin.exe, o antigo editor de linha do MS-DOS. Não posso dizer com certeza, mas eu apostaria um moca triplo grande que o edlin.exe apenas foi invocado duas vezes em todas as cópias instaladas do Windows Vista desde que o sistema operacional foi lançado. As duas vezes foram aproximadamente três minutos atrás, quando eu estava tentando lembrar a sintaxe. Se alguém modifica edlin.exe ou algum outro arquivo que ninguém nunca usa, realmente significa que ele não é mais o seu computador?
O arquivo edlin.exe é, indiscutivelmente, parte do sistema operacional, mas se ninguém jamais executar o arquivo, como uma modificação nele irá resultar no comprometimento do seu computador? A resposta, é claro, é que não irá. Modificar uma parte do sistema operacional que nunca é usada não comprometerá seu computador. E existem várias partes do sistema operacional que nunca são usadas.
A resposta indireta, no entanto, é sim. Você não pode simplesmente observar se alguém executa um arquivo para ver se a modificação pode resultar em um comprometimento do seu computador. O problema é mais sutil que esse. Dê uma olhada na ACL (lista de controle de acesso) para edlin.exe, exibida na Figura 2.
Figura 2 A ACL para edlin.exe é muito restritiva (clique na imagem para ampliá-la)
A ACL para edlin.exe é muito restritiva. Apenas o serviço TrustedInstaller possui direitos para modificar esse executável. Isso é muito importante: significa que existe um efeito indireto para uma pessoa mal-intencionada modificar esse arquivo no seu computador. O ato de modificar o edlin.exe significa que não é mais o seu computador. É o fato de que o usuário mal-intencionado possui a habilidade de modificar o edlin.exe que é chave aqui. Se a pessoa mal-intencionada consegue modificar esse arquivo, ela poderá modificar qualquer arquivo, o que significa que você não pode mais confiar em nada do computador.
O sistema operacional irá se proteger. Os serviços são protegidos de modificação não autorizada. As configurações são protegidas de modificação não autorizada. Os arquivos no disco são protegidos contra modificação não autorizada. Até mesmo os semáforos e os pontos de extremidade RPC usados pelo sistema operacional são protegidos contra modificação não autorizada. Se um invasor conseguir modificar qualquer um desses objetos protegidos, ele poderá modificar todos eles e, muito possivelmente, já o fez.
Esse é um ponto crítico. Com várias das leis imutáveis, não é o ato de fazer algo que significa que seu computador está comprometido. O que importa somente é que alguém possui a capacidade de fazer algo. Esse é um ponto que não deve passar despercebido. Em todos os aspectos da segurança do computador, você sempre deve se lembrar de que a capacidade é, freqüentemente, muito mais importante do que a ação realmente executada.
Se um computador está exposto à Internet e fica sem correções durante meses, ele ainda é confiável? Não. Esse computador deve ser considerado comprometido. Você simplesmente não pode confiar em nada em um sistema que poderia ter sido comprometido. (Eu disse exatamente isso cinco anos atrás no meu artigo "Socorro! Meu computador foi atacado. E agora, o que eu faço?" disponível em technet.microsoft.com/library/cc512587.) Se estiver lidando com um adversário habilidoso, um sistema comprometido pode nem mesmo mostrar sinais de que está comprometido. O sistema pode parecer perfeitamente normal.
Sem dúvidas, a Lei 2 ainda se aplica. Se um invasor tem a habilidade de modificar qualquer objeto protegido no seu computador, ele não é mais seu computador. Apenas lembre-se, é a capacidade de modificar esses objetos que importa, e não se ele realmente foi atacado.
Lei 3: Se uma pessoa mal-intencionada tiver acesso físico irrestrito ao seu computador, o computador não é mais seu.
Essa lei foi crucial em 2000. Um grande número de pessoas não entendia completamente o que era possível fazer com o acesso físico a um sistema. Na verdade, até mesmo algumas agências do governo que deveriam saber muito mais falharam em compreender esse ponto fundamental. Naquele momento, a orientação de segurança recomendava configurar a opção Permitir encerramento sem logon como desabilitada. Isso faz com que o botão Desligar… na tela de logon fique esmaecido. A teoria por trás disso era que para desligar o computador, o usuário precisa primeiro fazer o logon para que houvesse um registro de auditoria de quem desligou o sistema.
Esse é um estudo de caso em um pensamento com falhas. Para ter acesso ao botão Desligar… na tela de logon, você realmente precisa sentar no console. E se você está sentado no console e realmente deseja desligar o computador, pode normalmente usar aquele grande botão redondo na frente do computador — ou até mesmo o cabo de alimentação. Sistema desligado. Sem trilha de auditoria.
O Windows 2000 inclui uma configuração de segurança chamada “permitir desencaixe sem fazer logon” e essa opção ainda está disponível no Windows Vista, como exibido na Figura 3. O princípio era o mesmo. Para desencaixar um laptop de sua base de encaixe, é necessário primeiro fazer logon no sistema.
Figura 3 Por que você não furtaria o computador e o encaixe? (clique na imagem para ampliá-la)
O valor de segurança real dessa configuração é extremamente duvidoso. Eu acho que a teoria era que se simplesmente qualquer pessoa pudesse ir até o laptop e desencaixá-lo, alguém poderia facilmente roubar o computador. Bem, não que eu algum dia roubaria um laptop, mas se eu fosse fazê-lo, essa medida preventiva não me deteria. Eu provavelmente agarraria o laptop e a base de encaixe juntos como um único pacote. Quer saber? Eu também roubaria o cabo de rede e o cabo de alimentação. Isso é que é um ajuste de segurança insignificante!
O problema do acesso físico realmente tocou em um ponto vulnerável quando Petter Nordahl-Hagen criou sua Senha Offline do NT e o Editor do Registro. Sua criação foi simplesmente um disco de inicialização do Linux com um driver de sistema de arquivos NTFS experimental que permitia acesso de leitura e gravação a um volume NTFS. O software no disco de inicialização montaria o Registro na máquina local e escreveria uma nova senha para a conta do Administrador no hive do SAM (gerenciamento de ativos de software). Tudo o que você precisava era acesso físico ao sistema e um ou dois minutos.
Ferramentas como essa são exatamente o porquê de a Lei 3 ter sido escrita, em primeiro lugar. Na verdade, a ferramenta de Nordahl-Hagen foi usada em várias demos. Infelizmente, o caso nunca conseguir chegar à maioria dos públicos. Eu pessoalmente usei a ferramenta em algumas demos, mas parei de usá-la após ficar cansado por me perguntarem: "Como podemos ter certeza de que nenhum dos nossos usuários conhece ferramentas como essa?" e "O que a Microsoft está fazendo para corrigir esse problema?". Uma parte alarmantemente grande da indústria de TI não queria aceitar ou entender que o acesso físico superaria tudo.
Naquele ambiente, a Lei 3 era uma instrução muito importante. Ainda assim, os críticos a atacaram sem piedade. Ela foi ridicularizada como uma tentativa da Microsoft de evitar ter que corrigir qualquer problema que poderia, até mesmo da maneira mais remota, ser vinculado ao acesso físico. A Lei 3 foi na verdade usada em vários casos para ignorar relatórios de vulnerabilidade, incluindo o golpe da Senha Offline do NT e do Editor do Registro. No entanto, bloquear os invasores que possuem acesso físico ao sistema apenas é realmente possível de uma maneira: garantindo que eles não consigam chegar a lugar algum.
É aqui que reside a possível fenda na armadura de Lei 3. Desde que as leis foram escritas, a tecnologia de criptografia de disco completa se tornou uma solução viável. Com criptografia de disco rígido completa, ou com um termo mais correto, criptografia de volume total, um volume inteiro (conhecido como partição nos outros sistemas operacionais) pode ser criptografado. Então, se todo o volume de inicialização (em outras palavras, o volume com o sistema operacional nele) está criptografado, a pergunta que precisamos fazer é: a Lei 3 ainda se aplica?
A resposta é um firme provavelmente. Primeiro, as chaves de descriptografia precisam ser armazenadas em algum lugar. O local mais simples para colocar as chaves, e a opção padrão no BitLocker, é em um chip Trusted Platforms Module no computador. Fazendo isso, o computador será inicializado de modo autônomo. Depois que o computador for iniciado, um invasor engenhoso e bem fundamentado com controle físico permanente sobre o computador poderá atacá-lo de várias maneiras. Como o computador pode ser conectado agora a uma rede arbitrária, podem existir maneiras relacionadas à rede de atacar o sistema.
O invasor pode, por exemplo, ler ou gravar memória por meio de um dispositivo DMA (acesso direto à memória), como uma unidade flash USB. Depois que o computador estiver em execução, encerram-se todas as apostas quando se trata de um invasor com acesso físico àquele computador.
Se as chaves não forem armazenadas no computador em si, o ataque então dependerá se o invasor pode obter ou adivinhar as chaves. Se um código PIN for usado para inicializar o computador, o invasor pode provavelmente adivinhar o código com relativamente pouco esforço. Se as chaves forem armazenadas ou derivadas de um dispositivo de hardware separado, como uma unidade flash USB ou um fob de senha única, o invasor deverá ter acesso a esse dispositivo separado. Certamente existem maneiras de se obter essas teclas ou tornar a vida mais desconfortável para a pessoa com acesso a elas, embora o esforço necessário seja provavelmente um pouco maior.
Você também poderia interpretar a Lei 3 de uma maneira levemente diferente: "Se o invasor possui acesso físico ao seu computador, é provável que o computador tenha sido roubado e, portanto, é improvável que você consiga recuperá-lo." Dessa perspectiva, ele realmente não é mais o seu computador. E de outra perspectiva, pode não importar ao invasor se ele pode acessar os dados no seu computador ou não. No entanto, esse realmente não é do que trata o espírito da Lei 3. Ele significava que o invasor tinha acesso aos dados no seu computador e não apenas ao computador em si.
Com tudo considerado, a Lei 3 ainda se aplica. É verdade que certas tecnologias disponíveis hoje percorrem um longo caminho em direção a parar vários invasores com acesso físico e, portanto, minimizar o número de invasores capazes de acessar dados em um computador que emprega uma medida de segurança. Isso dito, os recursos do invasor sempre definem quanto o invasor realmente pode atingir e novas tecnologias resolvem várias das 10 leis imutáveis — até uma parte. Mas o acesso físico ainda oferece maneiras, embora mais complexas, de entrar em um sistema.
Até agora, as leis imutáveis de segurança estão se provando bastante resistentes, em relação a avanços tecnológicos e ao tempo. Das 3 primeiras, a Lei 3 está no plano mais instável, ainda assim, até mesmo ela se aplica em alguns casos. Ela é, no entanto, a que possui as mitigações eficientes e mais prontamente disponíveis no lugar. Voltarei nas duas próximas edições da TechNet Magazine para continuar essa discussão e determinar se as Leis de 4 a 10 ainda não imutáveis.
Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele é Ph.D. em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP (Most Valuable Professional) da Microsoft em segurança corporativa. Seu livro mais recente é o Windows Server 2008 Security Resource Kit.