Security WatchRevisitando as 10 leis imutáveis da segurança, parte 2

Jesper M. Johansson

Sumário

Lei 4: caso você permita a uma pessoa mal-intencionada carregar programas no site, este deixa de ser o seu site.
Lei 5: senhas fracas superam segurança forte.
Lei 6: um computador é tão seguro quanto o administrador é confiável.
Lei 7: dados criptografados são tão seguros quanto a chave de descriptografia.
Conclusão

Na edição do mês anterior da TechNet Magazine, iniciei uma série de três partes que revisitava o ensaio bastante conhecido "10 leis imutáveis da segurança". O meu objetivo é avaliá-las, oito anos depois de serem postuladas inicialmente, e saber se elas perderam ou não a validade – em outras palavras, ver se elas são, de fato,"imutáveis". (É possível encontrar a primeira parte desta série em microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.)

Descobri que as três primeiras leis continuam se aplicando muito bem. Agora estou pronto para analisar mais quatro. Na parte final do mês que vem, abordarei as três últimas leis, bem como apresentarei algumas idéias novas que aproveitam oito anos de observação.

Lei 4: caso você permita a uma pessoa mal-intencionada carregar programas no site, este deixa de ser o seu site.

Talvez você esteja pensando: a Lei 4 é um pouco estranha. Afinal, as demais leis são de um nível bem mais elevado, isso sem falar em serviços específicos, e sim de funcionalidade geral. Todas as três primeiras leis descrevem cenários em que o computador deixa de ser o seu computador. Em seguida, chegamos à Lei 4, que fala sobre sites.

Para compreendê-la, o contexto histórico é bastante importante. As leis foram originalmente publicadas em 2000. Era o momento de uma Web ainda relativamente nova e imatura. Sites como Amazon e eBay ainda estavam em desenvolvimento. Enquanto as explorações que executavam comandos arbitrários nos sites eram algo comum, a correção delas não era.

Diante desse pano de fundo, é bem provável que a Microsoft tenha visto a Lei 4 como uma demonstração pública necessária de que você precisa assumir a responsabilidade pelo que o seu site oferece. Esse aspecto chegou até as casas, destruindo tudo, em setembro de 2001, quando surgiu o Nimda. Nimda era um worm de rede multivetorial, e um dos vetores que ele usava para se espalhar era infectar sites vulneráveis e modificá-los para transportar o worm.

O intervalo de tempo relacionado à Lei 4 também foi uma das desfigurações do site. Attrition.org executa um espelho de muitas das desfigurações daquela época (attrition.org/mirror/attrition/months.html). Havia muitas dessas desfigurações, quase sempre de sites importantes. Até mesmo a home page do SANS Institute de treinamento em segurança foi desfigurada. A Figura 1 mostra a desfiguração do site do Estado do Arizona em outubro de 1998.

Figura 1 Desfiguração do site do Estado do Arizona (Clique na imagem para ampliá-la)

O problema era que, naquele momento, em geral, as pessoas não sabiam o que realmente acontecia quando um site era desfigurado. A idéia geral era se livrar da página mal-intencionada e seguir a vida. Se estivesse lá, você taparia o buraco que as pessoas mal-intencionadas usaram (se conseguisse encontrá-lo).

As pessoas não estavam observando toda a situação. A Lei 4 foi projetada para fazer as pessoas pensarem no que poderia ter acontecido quando o site foi desfigurado, e não no que aconteceu.

Infelizmente, ela não conseguiu todo o êxito. Apesar da Lei 4, em 2004 me cansei de responder a pergunta: "Podemos apenas remover a página da Web que o hacker inseriu e continuar nossas tarefas normalmente?". Não sendo homem de poucas palavras, tentei difundir novamente essas noções com um artigo chamado "Help: I Got Hacked. Now What Do I Do?" (technet.microsoft.com /en-us/library/cc512587.aspx).

No entanto, a dúvida é se a Lei 4 ainda se aplica hoje. De fato, uma pessoal mal-intencionada detém o site caso consiga carregar um programa nele? Ou mais especificamente, ela é proprietária do site ou dos visitantes, ou de ambos? Como a Lei 4 acaba não sendo clara em relação ao que se refere, analisarei ambos.

No que diz respeito à propriedade do site, a resposta é sim. A pessoa mal-intencionada detém o site caso você permita a ela inserir programas nele (porém, existem algumas exceções que observarei daqui a pouco). Com um site típico, existem duas coisas que a pessoa mal-intencionada pode fazer carregando programas, além de uma implicação bastante significativa decorrente do fato de ser capaz de carregar no site.

A primeira medida que a pessoa mal-intencionada pode tomar é fazer o site atender às necessidades dele. Se alguém está interessado em oferecer conteúdo ilegal como, por exemplo, pornografia infantil, qual lugar é melhor do que um site que não pode ser controlado exceto pelo próprio hacker? Os criminosos tenderiam a oferecer esse tipo de conteúdo muito mais pelo seu site do que pelo deles.

A segunda coisa que a pessoa mal-intencionada pode fazer carregando um programa no site é assumir o controle do sistema por trás do site. Obviamente, isso depende da possibilidade de execução do programa no servidor Web. Apenas ter o programa lá, sem fazer nada, não ajudará muito. No entanto, caso consiga executar o programa, a pessoa mal-intencionada detém definitivamente o site e agora pode não apenas atender a necessidades próprias, mas também usá-lo para controlar outras coisas.

A implicação a que me referi é ainda mais importante do que os aspectos específicos. No artigo "Help: I Got Hacked", o ponto a que estava tentando chegar era que você não sabe exatamente o que uma pessoa mal-intencionada pode ter feito depois de entrar. Se ela consegue inserir conteúdo próprio no site, você precisa se perguntar o que mais poderia ter feito.

A resposta poderia estar em muitas coisas. É essa a peça mais importante do quebra-cabeça. Se uma pessoa mal-intencionada consegue executar programas em um servidor atrás do site, ela detém por completo este site, bem como o que ele faz. Na verdade, ele deixa de ser o seu site.

Com relação ao comprometimento dos visitantes do site, essa pergunta é mais difícil de responder. Os navegadores estavam repletos de falhas de segurança no final dos anos 90. Em 2004, a situação melhorou drasticamente. Os principais navegadores atuais, o Internet Explorer e o Firefox, são ambos bastante consistentes em termos de segurança. Na verdade, em comparação com o que tínhamos nos anos 90, os navegadores atuais são autênticos bastiões da segurança.

Se uma pessoa mal-intencionada pode comprometer os visitantes, depende muito de duas coisas. Primeiro, existem falhas nos navegadores que ela pode explorar? Talvez haja, mas não tantas quanto as que existiam. E segundo, a pessoa pode persuadir os usuários a se comprometer? A resposta, com surpreendente freqüência, é sim.

A grande maioria dos usuários instalará coisas que um site solicitar. Trata-se de um problema grave, porque não podemos resolvê-lo com tecnologia. Nas edições de julho, agosto e setembro de 2008 da Security Watch, abordei esse problema. Em relação à Lei 4, ela infelizmente significa que a pessoal mal-intencionada tem boas chances de conseguir comprometer os visitantes.

As exceções mencionadas anteriormente devem ser óbvias. Os sites fazem muitas coisas hoje que não eram previstas no final dos anos 90. Por exemplo, sites de colaboração internos como, por exemplo, o Microsoft SharePoint, são comuns. Qualquer um com as permissões apropriadas pode carregar um programa em um site desses, mas isso não significa que o site ou um usuário que o acesse será comprometido. Trata-se simplesmente daquilo para que o site foi criado. Os usuários são considerados confiáveis, até certo ponto, simplesmente por terem as permissões necessárias ao acesso ao site.

E, em seguida, surgem os sites shareware. Embora tenham postado malware neles no passado, eles foram criados para compartilhar software. Isso não quer dizer, por si, que algum usuário é comprometido. Resumindo, todos esses sites têm proteções para garantir que permaneçam seguros e para que os usuários não sejam comprometidos automaticamente visitando-os. Acho que se trata da exceção que confirma a regra. Por isso, a Lei 4, pelo menos o espírito dela, permanece – apesar de alguns sites criados para permitir que pessoas, com boas e más intenções, carreguem programas neles.

Lei 5: senhas fracas superam segurança forte.

As senhas foram uma das minhas paixões por muitos anos. As senhas ou, mais genericamente, segredos compartilhados são uma grande forma de autenticar assuntos. Só existe um problema mínimo com elas: caem por completo diante da natureza humana.

De volta aos dias de tranqüilidade da computação, quando a computação de compartilhamento do tempo foi inventada, a necessidade de uma forma de diferenciar os usuários se tornou aparente. O sistema precisava de uma forma de diferenciar os dados de Alice e os de Bob. O ideal era que Bob pudesse impedir Alice de ler seus dados, ainda que este fosse um requisito vago.

A solução foram as contas de usuário e as senhas. Costumávamos ter uma conta em um sistema de computador. E normalmente tínhamos uma senha, que costumava ser uma das seguintes:

• o nome dos filhos
• o nome do cônjuge
• o nome do bicho de estimação
• "Deus" (se você fosse o superusuário)

Avancemos aproximadamente 30 anos. Agora temos centenas de contas – em sites em toda a Internet e em vários computadores. Todos esses sistemas nos informam que não devemos usar a mesma senha em qualquer outro sistema. Você é avisado para torná-la forte, não anotá-la e alterá-la entre cada 30 a 60 dias.

Como as pessoas comuns não podem alterar quatro senhas por dia e conseguir se lembrar de nenhuma delas, o resultado é que elas, infelizmente, acabam usando a mesma senha em todos os sistemas (ou possivelmente duas senhas diferentes). E elas costumam ser escolhidas dentre a seguinte lista de possibilidades:

• o nome de um dos filhos com o número 1 acrescentado
• o nome do cônjuge com o número 1 acrescentado
• o nome do bicho de estimação com o número 1 acrescentado
• "DeusDeus11" (apenas se você for o superusuário)

Passados 30 anos, não avançamos tanto quanto qualquer pessoa esperaria. Os pesquisadores continuam achando as senhas uma área de pesquisa proveitosa; para obter mais informações, consulte o artigo da PC World "Too Many Passwords or Not Enough Brainpower" (em pcworld.com/businesscenter/article/150874/too_many_passwords_or_not_enough_brain_power.html).

Obviamente, as senhas, como são normalmente usadas, são uma forma muito fraca de segurança. Ainda assim, existem formas de usar senhas com segurança. Por exemplo, é possível gerar senhas fortes e anotá-las – não há, na verdade, nada de errado nisso. No entanto, as pessoas recebem tantos avisos de segurança equivocados em todos os lugares e de todos que os usuários acabam pensando ser melhor usar a mesma senha em todos os lugares a anotar as senhas.

O fato é que toda uma segurança se resume a um ponto fraco. Use o acesso à rede virtual privada (VPN), por exemplo. Já participei de inúmeras discussões sobre várias tecnologias VPN, avaliações de fornecedor em que os fornecedores indicam as virtudes da criptografia incrivelmente forte e lenta; como eles trocam as chaves de criptografia para ter a certeza de que um invasor não possa detectar pacotes e analisá-los por criptografia.

Mas tudo isso deixa de lado o aspecto principal. Um invasor não tentará analisar por criptografia um fluxo de pacotes que demorará 10 milhões de anos para ser analisado usando a tecnologia de computação atualmente disponível. De fato agrega algum valor diminuir a velocidade da rede em termos de magnitude para obter uma criptografia que demorará 100 milhões de anos para ser analisada? Particularmente, não me preocupo se alguém, daqui a 100 milhões de anos (ou mesmo daqui a 10 milhões de anos), de alguma forma, conseguir descriptografar o email do meu trabalho.

É, de fato, a criptografia o ponto fraco de interesse? É mais do que provável que o invasor explore a vulnerabilidade mais simples – o fato de as senhas de usuário serem normalmente uma das que acabei de listar.

Uma criptografia incrivelmente forte não importa muito caso todos os usuários escolham uma senha com seis ou oito caracteres. Conseqüentemente, agora estamos migrando para o uso de formas mais fortes de autenticação como, por exemplo, cartões inteligentes e geradores de código PIN individuais.

Elas oferecem uma melhoria incrível, embora nem sempre aprimorem a segurança. Os cartões inteligentes, por exemplo, são fáceis de perder ou de esquecer em casa. Já os geradores de código PIN individuais cabem perfeitamente no porta-crachá, o que fica ótimo pendurado no pescoço. Na próxima vez em que você sair para tomar um café na padaria do outro lado da rua, veja se é possível identificar a pessoa que está olhando o PIN individual atual, lendo o seu nome no crachá e tentando adivinhar a pequena possibilidade aleatória que é tudo de que ela precisa para se conectar como você à rede corporativa.

É mais provável que a Lei 5 continue valendo atualmente e que continue assim no futuro. No entanto, acho que isso pode ser bastante generalizado. Mais do que senhas fracas superam segurança forte. Em termos mais gerais, pode-se dizer que "autenticação fraca" ou até mesmo "pontos fracos" superam segurança forte.

Os profissionais de segurança em TI são, em grande parte, os culpados por não serem comedidos e observar todo o panorama. A tendência é de que nós nos concentremos em apenas uma parte do problema, aquela que somos capazes de resolver confortavelmente com tecnologias de segurança fortes. É muito comum que deixemos de perceber a existência de pontos fracos sistêmicos que não atenuamos, ou nos quais até mesmo não pensamos, e que renderizam toda a tecnologia que estamos colocando em questão.

Por exemplo, considere quantas organizações tentam regulamentar os dispositivos removíveis que os usuários podem usar, mas que permitem Secure Shell (SSH) de saída e conexões de email criptografadas. Qual é a perda de dados atenuada com a limitação de dispositivos removíveis caso você permita a transmissão de dados com criptografia de forma que não seja possível sequer ver os dados? Trata-se de um dos principais problemas que nós, profissionais de segurança, devemos resolver caso queiramos sobreviver e prosperar.

Lei 6: um computador é tão seguro quanto o administrador é confiável.

Mesmo hoje em dia, fico surpreso ao continuar vendo relatórios de explorações que só funcionam com administradores – ou o que é pior, explorações que só funcionam caso você já seja um administrador. Enquanto escrevo isto, estou sentado em um aeroporto voltando da conferência Black Hat 2008. Mesmo lá, assisti a uma apresentação que começava com a premissa "se você tem acesso à raiz, eis como é possível assumir o sistema".

Por um lado, é bom saber que a pior coisa que alguém pode mostrar é como modificar o sistema, embora seja um pouco mais secretamente, caso já tenha o direito de modificá-lo. Por outro lado, acho frustrante que as pessoas não pareçam ver como isso é inútil e continuem tentando inventar novas formas de fazê-lo – e o que é mais importante, percam tempo e energia se protegendo disso.

O fato é bastante simples: qualquer usuário que seja um administrador (raiz, superusuário ou qualquer coisa que você julgue ser uma função) é onipotente dentro do mundo desse sistema. Esse usuário tem a possibilidade de fazer qualquer coisa!

Certamente, existem formas mais e menos discretas de fazer tudo o que um usuário mal-intencionado desse tipo quer fazer. Mas o aspecto fundamental continua sendo exatamente o mesmo: não é possível detectar com eficiência nada o que um administrador mal-intencionado deseja que você detecte. Esse usuário sabe o meio de ocultar essas trilhas e fazer com que tudo pareça ter sido feito por outra pessoa.

Logo, fica claro que a Lei 6 continua se aplicando, pelo menos em determinado nível. Caso uma pessoa que tenha recebido direitos onipotentes em um computador se irrite, certamente o computador deixa de ser seu. Em um sentido bastante real, o computador é tão seguro quanto o administrador é confiável.

No entanto, há alguns aspectos a serem considerados. Primeiro, a noção do administrador, da perspectiva do computador, não inclui apenas a pessoa ou as pessoas com direito a essa função. Ela também inclui qualquer software executado no contexto de segurança dessa função. Assim, por extensão, a função do administrador também inclui qualquer autor de qualquer software desse tipo.

Esse é um ponto crítico. Quando a Lei 6 afirma que o computador é tão seguro quanto o administrador é confiável, o significado é muito mais amplo do que parece inicialmente. Jamais se esqueça de que, até onde se entende computador, administrador significa qualquer processo em execução dentro do contexto de segurança de um usuário administrativo. Não importa se esse usuário deseja executar efetivamente aquela parte do código ou causar danos com ela.

Trata-se de um aspecto crítico porque foi apenas recentemente que um usuário médio conseguiu operar um computador baseado no Windows como não-administrador. Trata-se de um dos principais objetivos do Controle de Conta de Usuário (UAC) no Windows Vista. Mesmo assim, não há limite de segurança entre o contexto administrativo de um usuário e o contexto não-administrativo. Conseqüentemente, a Lei 6 se aplica a qualquer usuário que tenha o potencial de se tornar um administrador, e não apenas àqueles que sejam administradores no momento.

Dessa forma, a única forma de não se sujeitar à Lei 6 é efetivamente não sendo um administrador, e sim operar como um verdadeiro usuário padrão. Infelizmente, esse não é o padrão, mesmo no Windows Vista, e muitos fabricantes originais do equipamento (OEMs) também acabam desabilitando o UAC.

No entanto, o UAC promete um pouco mais para o futuro. O recurso mais visível do UAC é o processo de elevação, mostrado na Figura 2. Porém, o benefício estratégico mais importante não é a elevação para um administrador, mas a possibilidade de operar um computador com eficiência sem ser um administrador em primeiro lugar. O Windows Vista contém vários aperfeiçoamentos que possibilitam isso. Por exemplo, ao contrário das versões anteriores do Windows, é possível alterar o fuso horário sem ser um administrador, o que permite que viajantes sejam não-administradores. Indo adiante, é provável que haja mais desses tipos de aperfeiçoamento.

Figura 2 O recurso mais visível e possivelmente o menos importante do UAC é a solicitação de elevação (Clique na imagem para ampliá-la)

A Lei 6 se mantém hoje e continuará assim. Mas a mudança no sentido de um mundo em que os usuários possam operar computadores como não-administradores é um dos fatores moderadores principais previstos na Lei 6. O segundo fator não é lá muita novidade: sistemas de controle de acesso obrigatórios.

Em sistemas de controle de acesso obrigatórios, objetos têm rótulos e existem regras rígidas para a forma com que eles podem ser novamente rotulados. O software aplica segurança a um objeto de maneira consistente com o rótulo, fora do controle imediato do administrador. Falando em termos específicos, nas implementações atuais, o administrador normalmente consegue executar várias etapas ilegítimas para substituir esses controles.

No entanto, o princípio é promissor e talvez seja possível, algum dia, limitar o que os administradores podem fazer. Mas mesmo se tivéssemos restrições para limitar o que os administradores poderiam fazer, ainda assim você poderia argumentar que esses usuários deixariam de ser administradores na real acepção do termo. Dessa forma, a Lei 6 é decididamente imutável.

Lei 7: dados criptografados são tão seguros quanto a chave de descriptografia.

A Lei 7 é possivelmente a menos controversa de todas as leis. A criptografia é comumente vista como a solução completa de muitos problemas de segurança. No entanto, a verdade é que, embora seja uma ferramenta importante no mundo da segurança, ela não é, e jamais será, uma solução autônoma para a maior parte dos problemas que enfrentamos.

A criptografia está em todo os lugares. No Windows, a criptografia é usada em senhas, arquivos, para navegar na Web e se autenticar. Nem toda criptografia foi criada para ser reversível, mas dentre alguns dos exemplos mais importantes de criptografia reversível estão o Encrypting File System (EFS) e o cache de credencial usado para senhas e nomes de usuário armazenados, conforme a ilustração na Figura 3.

Figura 3 O cache de credencial do Windows Vista está protegido pela criptografia (Clique na imagem para ampliá-la)

Tanto o EFS quanto o cache de credencial são protegidos por uma chave de criptografia derivada da senha do usuário. Isso tem várias implicações. Primeiro, se a senha do usuário for redefinida (definida como uma nova senha sem digitar a anterior), todos os dados armazenados nesses locais serão perdidos, a menos que uma chave de recuperação seja designada.

Mas, muito mais importante para a nossa discussão: embora a própria criptografia use chaves e protocolos extremamente fortes, a segurança da chave depende da senha do usuário. Em outras palavras, a segurança dos dados não é maior que a eficiência da senha. Na realidade, a senha é uma chave de descriptografia, ainda que, nesse exemplo em particular, seja uma chave de descriptografia secundária – o que significa que ela descriptografa outra chave de descriptografia.

Isso é crucial. Esses tipos de cadeia de dependências estão em todos os lugares do mundo da TI. Há alguns anos, alguém executou um ataque de engenharia social contra a VeriSign e obteve dois certificados de assinatura do código em nome da Microsoft. Um certificado de assinatura do código é, na verdade, uma chave de descriptografia, usada para verificar se a entidade nomeada no certificado tem a chave de descriptografia.

Porém, nesse caso, a pessoa que solicita o certificado não era a entidade nomeada nele. Em outras palavras, o invasor tinha chaves de assinatura no nome de outra pessoa. As chaves talvez estivessem protegidas, mas assim que analisasse o restante da cadeia de dependências, você descobriria a falha fatal.

Tudo isso serve para comprovar uma coisa: a chave de descriptografia é crítica para a segurança dos dados, mas a chave de descriptografia propriamente dita pode estar protegida por segredos muito mais fracos. Vi muitos sistemas em que os implementadores criaram a criptografia mais forte possível e protegeram a chave de criptografia com alguma outra medida de segurança, mas deixaram de observar que essa segunda camada apresentava uma falha significativa. Ao implementar qualquer criptografia, você deve verificar se analisou toda a cadeia de proteção. Por si só, a simples criptografia não torna os dados seguros.

Portanto, a Lei 7 continua sendo válida. Trata-se da mais incontestável das 10 leis. Na verdade, é o mais próximo que chegamos de uma lei da física neste ramo. Ela também deve servir de lição para todos nós, o que nos lembra de analisar toda a cadeia de proteção dos dados confidenciais. Por isso, é aceitável ter chaves que não tenham a proteção mais forte possível, mas é importante que essas chaves só sejam usadas para criptografar dados que exijam apenas o menor nível de proteção.

Conclusão

Até aqui, as leis imutáveis da segurança são 7 de 7. Todas as que examinei continuam sendo válidas depois de todos esses anos, e parece improvável que, em breve, elas percam essa validade de maneira significativa.

Na realidade, as leis demonstraram um grande poder de previsibilidade. A única que parece deslocada até aqui é a de número 4, mas, conforme mencionado anteriormente, mesmo ela ainda deve ser considerada imutável.

No mês que vem, concluirei esta série observando as leis 8, 9 e 10. Além disso, comentarei onde elas talvez não abranjam todos os aspectos da segurança.

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 é The Windows Server 2008 Security Resource Kit.