A Perpetuação dos Esqueletos no Armário

Introdução

Esse ensaio provê uma introdução às vulnerabilidades de segurança em sites web e descreve o serviço profissional de localizar e catalogar sistematicamente esses "esqueletos no armário". Em seguida discute-se uma possível proposta para que os resultados desses trabalhos sejam publicados como forma de incentivo para que os problemas encontrados sejam efetivamente corrigidos.

O texto tenta equilibrar rigor técnico com acessibilidade a um público amplo. Alguns termos técnicos avançados de informática são citados em alguns momentos, mas podem ser ignorados sem prejuízo para o entendimento do texto como um todo.

Vulnerabilidades

Uma vulnerabilidade em um site web¹ é uma brecha, deixada por seu criador, permitindo fazer coisas que não deveriam ser possíveis. Quase sempre é um deslize, uma desatenção, cometida inadvertidamente, mas que gera um meio de subverter um sistema.

Vejamos um exemplo trivial: suponha que o formulário abaixo permita aos visitantes se cadastrarem para receber um boletim via email com as novidades do meu site. Experimente digitar seu endereço de email (tente mesmo!) e vai aparecer um popup com o email hipotético de confirmação de inscrição (se você tiver um bloqueador de popups, desative-o).

Digite seu email: 

Da maneira que esse recurso foi implementado, há algumas vulnerabilidades nele. A primeira coisa óbvia é que se você colocar o endereço de outra pessoa ao invés do seu, você inscreve outra pessoa. Grande coisa -- o próprio texto do email diz, "se não foi você, ignore".

Só que existe outra maneira de disparar esse programa. Leia com atenção o link abaixo e veja se entende como ela funciona:

http://www.postcogito.org/Kiko/EsqueletosNoArmario.html?to=vitima@algo.com&subj=Viagra&msg=Bem+baratinho%21+Compre+aqui%21&lang=pt-br

O lance é que não apenas o destinatário, mas também o conteúdo da mensagem e o assunto estão sob seu controle. Se você apenas clicou no link, talvez isso não lhe seja imediatamente óbvio. Experimente clicar nele com o botão direito, pedir a opção "Copiar Link" ou "Copiar Atalho". Depois, cole o endereço resultante na barra de endereços do seu navegador e altere o Compre+aqui no final por Compre+agora.

Sabendo disso, você poderia, por exemplo, enviar spam como se tivesse sido do meu site -- o que certamente não vai fazer bem à minha reputação.

Muita gente acharia razoável esperar que esse abuso não deveria ser possível; sob esse ponto de vista, isso seria uma vulnerabilidade. Não deveria haver um meio de alguém externo controlar o conteúdo das mensagens automáticas que meu site envia.

Mas isso é o de menos. Há uma outra vulnerabilidade mais séria, ainda que de natureza mais técnica. Experimente digitar (copiar e colar também funciona) o texto abaixo no formulário acima e apertar no botão "Enviar":

fulano@exemplo.com; echo 1nv@did0 p0R M1m > EsqueletosNoArmario.html

Aparentemente nada acontece; o "email" é gerado normalmente. Feche o popup e pressione F5 na janela do navegador onde você está lendo esse texto. Você terá a impressão de ter conseguido sobrescrever o conteúdo dessa página com sua pichação virtual, adequadamente grafada em leetspeak.

Claro, essa doce ilusão se desvanece assim que você abre e fecha o navegador ou manda limpar seus cookies: meu site não é vulnerável de verdade; isso é apenas uma simulação, implementada na forma de um programa em JavaScript rodando no seu navegador.

O que significa exatamente esse echo, esse sinal de "maior-que" e o embasamento técnico necessário para ter uma compreensão mais profunda sobre por que exatamente essas palavras mágicas funcionam não são meus objetivos nesse texto -- livros inteiros já foram escritos sobre isso. Queria apenas dar um exemplo realista do que são essas vulnerabilidades. De fato, se você aliar bastante paciência de experimentar essas "palavras mágicas" em milhares de sites pela Internet afora com uma mínima noção de como adaptá-las para que funcionem neles, não duvido que consiga achar algum em que esse truque banal ainda funcione.

Novamente nosso conceito de vulnerabilidade: parece razoável esperar que esse singelo formulário não deveria aceitar palavras mágicas que permitissem sobrescrever o conteúdo do site.

Para os não-iniciados, sei que soa impenetrável, quase mágico: algo como se eu enfiasse uma geringonça pelo escapamento do seu carro e, de repente, ele destravasse, como se você o tivesse aberto com a chave. Muita gente jamais imaginaria que a partir do escapamento do seu carro fosse possível subverter a porta. (E, tanto quanto saiba, não conheço nenhum carro em que isso seja possível.) Mas conheço muitos sites onde singelos campos de formulários são portas para dominá-los totalmente.

Ethical Hacking

Os projetos de Ethical Hacking são serviços onde especialistas em segurança da informação são contratados para, sistemática e profissionalmente, localizar e catalogar essas "palavras mágicas", esses "esqueletos nos armários" que os criadores e mantenedores dos sites juram de pé junto que não existem. Eles esquadrinham o site em busca desse e muitos outros truques, alguns deles bem tecnicamente sofisticados. Como resultado, o cliente recebe um relatório listando todas as maneiras diferentes (às vezes centenas) que encontramos de subverter a segurança do site sob diversos aspectos. A esperança é que, de posse dessa informação, os responsáveis pelo site possam tomar as medidas corretivas que julgarem cabíveis.

No mercado internacional, esse serviço se chama "penetration test" ("teste de penetração", em Português) ou apenas "pen-test", para abreviar. Lá na Tempest a gente não curte muito esses termos: eles têm um tom meio pornofônico que não condiz lá muito bem com a seriedade do serviço. Por isso, nossa equipe comercial emprega outros nomes: os focados em amplitude mas não em profundidade saem pelo nome de "Análises de Vulnerabilidades", ao passo que os mais aprofundados costumam ser chamados de "Ethical Hacking" mesmo.

Já os técnicos tendem a chamar tudo por um nome só, apelidando-os carinhosamente de "EHs". Nesse ponto eu poderia enveredar por aquela discussão de que o termo deveria ser "Ethical Cracking" ao invés de "hacking", mas vou deixar essa de fora por hoje. Para mal ou para bem, o termo "Ethical Hacking" se tornou padrão.

Ao longo de mais de sete anos fazendo esse tipo de trabalho, temos acumulado uma série de estatísticas interessantes. Nossa taxa de sucesso em EHs externos (aquele que tentamos "invadir" a partir da Internet, sem acesso prévio à rede interna do contratante) tem girado em torno de 80% dos casos. Em EHs internos -- aqueles em que desde o princípio temos acesso à rede interna, simulando um ataque "de dentro" -- não houve sequer um único caso onde não tenhamos obtido sucesso.

Sucesso aqui significa "comprometimento total" do ambiente: nós obtivemos tanto ou mais controle quanto seus próprios donos. Freqüentemente significa que obtivemos senhas de milhares de usuários, inclusive os que têm privilégios de alterar o site. Para os técnicos: em EHs internos de redes Microsoft, significa que obtivemos poderes de "Enterprise Admin" do Active Directory. Em muitos casos isso tudo acontece sem os administradores sequer notarem o que aconteceu.

Há muitas outras estatísticas intrigantes e histórias curiosas que eu poderia contar sobre esses projetos. A execução é uma montanha-russa emocional: à medida em que o prazo (limitação que nós temos, mas um atacante real, não) vai se esgotando, a tensão vai escalando a níveis insuportáveis. O alívio só vem quando finalmente achamos a brecha que nos conduz ao domínio total do site, dando lugar à recompensadora sensação de "dever cumprido".

Outro ponto interessante é a apresentação dos resultados: ela freqüentemente se dá na forma de uma reunião/apresentação onde nossos técnicos e os da contratante ficam cara-a-cara -- um exercício de tato e diplomacia para expor os esqueletos sem ferir os brios de ninguém.

Eu poderia também discorrer sobre a intrincada cadeia de fatores econômicos, técnicos e culturais que geram tantos esqueletos; e há algumas estatísticas que parecem apontar para possíveis luzes no fim dos túneis.

Mas nesse texto eu gostaria de focar em um ponto específico: como o véu de segredo por trás desse trabalho praticamente assegura a perpetuação dos esqueletos nos armários.

Os Acordos de Confidencialidade

Todos esses EHs são regidos pelos famosos NDAs, sigla em inglês de "non-disclosure agreements", ou "acordos de confidencialidade", em Português. Basicamente eles dizem que não podemos comentar nada sobre resultados específicos dos trabalhos com ninguém senão os próprios contratante, durante um certo número de anos. Esses contratos exigem de nós uma disciplina quase militar para coleta, guarda e transferência de dados desses projetos. Eles também são a razão da minha reticência quanto a detalhes mais específicos nesse texto e em minhas palestras.

Mesmo quando os NDAs expiram, nossa prática tem sido continuar a manter os resultados em sigilo, principalmente para não dar nem remotamente margem a questionamentos sobre se o NDA que protege aquela informação teria expirado mesmo ou não, nem sobre nossa seriedade em cumpri-los à risca.

À primeira vista, os NDAs soam o que há de mais justo e natural: "ok, ache os esqueletos no meu armário, mas conte só pra mim, para que eu tenha tempo de consertar". Acontece que, por causa deles, as "medidas corretivas cabíveis" em muitos casos acabam sendo "deixar tudo como está".

Há uma gama de vulnerabilidades que são fáceis de consertar: atualize essa versão do seu servidor web por essa mais recente; substitua todos seus velhos Windows 9x por por Windows XP configurados segundo essa cartilha; e coisas assim. Fazer isso em milhares de computadores dá um trabalho danado, requerendo coordenação e gerência. Mas hoje o mercado tem soluções pra isso; de fato, nós mesmos da Tempest oferecemos um serviço que automatiza esse trabalho em grande escala, produzindo métricas de gerência que mostram aos gestores que suas equipes técnicas estão mesmo fazendo o dever de casa. Ok, chega de propaganda por hoje.

Só que muitas outras vulnerabilidades, contudo, são muito mais difíceis de consertar porque exigiriam uma reengenharia de grande escala nos sistemas. Se fosse mesmo possível abrir um carro inserindo uma geringonça pelo cano de escape, isso significaria que o projeto do carro é intrinsecamente falho e a solução seria reprojetá-lo do zero -- coisa que o fabricante provavelmente não estaria muito a fim de fazer. Mas é exatamente o que acontece no mundo da segurança da informação: há muitos, muitos sites, redes, sistemas e serviços que precisariam ser reprojetados do zero. Mesmo quando os gerentes dos ambientes reconhecem de fato o problema e se dispõem a corrigi-los, freqüentemente são atropelados por outras prioridades/restrições -- prazos e custos, normalmente.

E se ninguém, exceto um punhado de pessoas, fica sabendo disso, não há o menor incentivo para que isso seja realmente feito. É mais simples e mais barato deixar como está, seja abafando a questão ou decidindo "assumir o risco". Isso a despeito dos genuínos esforços de alguns dos técnicos e gestores dos contratantes. No olhar e no jeito do "dar de ombros", vejo que a frustração deles com as "pizzas" resultantes não é menor que a minha. Mas ainda assim perpetuam-se os esqueletos nos armários.

Alternativa: Tirando o "N" dos "NDAs"

Não gosto de escrever artigos que só apontam problemas. Tenho uma coçeira quase incontrolável de tentar propor soluções. Consideremos, então, a seguinte alternativa -- e se houvesse uma lei que:

1. obrigasse certos tipos de instituição a fazerem EHs regularmente;
2. após um período de resguardo de alguns anos, os resultados desses EHs seriam publicados;

Lógico, seria algo mais detalhado do que isso. O item (1), por exemplo, teria uma tabelinha especificando a periodicidade e escopo dos EHs para diferentes tipos de instituição. Por exemplo, instituições que provêem serviços considerados essenciais deveriam fazer EHs em tais e tais ativos computacionais a cada X anos. Instituições onde incidentes de segurança poderiam causar perdas de Y milhões de reais e/ou atingir Z milhares de pessoas teriam de fazer EHs em tais e tais ativos a cada tantos meses.

Note que não faz sentido existir (2) sem existir (1): se houvesse a obrigatoriedade em revelar sem a obrigatoriedade de investigar, provavelmente ninguém se interessaria contratar EHs para não correr o risco de ter seus esqueletos expostos em público.

Em todo caso, se existir uma lei que exija tanto (1) quanto (2), passaria a existir uma coisa que hoje não existe: incentivo real para que os problemas sejam corrigidos, mas com uma escala de tempo razoável para que as equipes os consertem.

Seria uma omissão séria da minha parte se eu não comentasse as semelhanças e diferenças entre essa proposta e um conceito chamado "responsible disclosure" ("revelação responsável [de vulnerabilidades de segurança]") que vem há vários anos sendo discutido na comunidade de segurança da informação. A idéia básica é que quando algum pesquisador descobre alguma vulnerabilidade em algum produto, ele deveria primeiro informar ao fabricante e lhe dar um tempo razoável (um mês? um ano? dois anos?) para prover um conserto e alertar seus clientes. Isso é em oposição à prática do "full disclosure" (revelação total), muito popular nos anos 90, onde o pesquisador publica detalhes técnicos sobre as vulnerabilidades imediatamente, sem necessariamente notificar o fabricante.

A doutrina da revelação responsável (péssimo nome, pois falsamente sugere que qualquer outra abordagem seria irresponsável) é normalmente discutida em termos de produtos específicos, como por exemplo o Windows; os "afetados" seriam a Microsoft e seus usuários. No nosso caso seria o oposto: as vulnerabilidades publicadas após o período de resguardo seriam as específicas do site auditado, independente se elas usam Windows ou Linux, IIS ou Apache, ASP, PHP, Cold Fusion ou IntraWeb.

Assim, quem teria de agir para consertar um problema não seria a Microsoft (para usar o exemplo de um cenário comum, que seria um site totalmente Windows-cêntrico); seriam os técnicos da instituição que montaram e/ou operam o site. Se o site deles fosse invadido porque eles não consertaram tudo antes da publicação das vulnerabilidades, o problema seria deles e de seus usuários.

Claro, para uma lei dessas funcionar, diversos detalhes precisariam ser muito bem esclarecidos. Seria importante garantir que os contratantes alternassem entre diversos fornecedores de tempos em tempos. Por que? Pela mesma razão que quando alguém revisa um texto mais de uma vez, deixa de enxergar os erros, pois, tendo se familiarizado com ele, não mais consegue se distanciar o suficiente para realmente relê-lo com olho crítico. E também para dificultar o jogo combinado: "olha, você me audita, mas o relatório tem de dizer que tá tudo bem."

Suspeito que haveria também formidáveis questões jurídicas a serem tratadas. Imagino que não seria difícil propor uma lei que, digamos, limitasse o período máximo de vigência de acordos de confidencialidade para vulnerabilidades em sistemas web públicos a, digamos, dois ou três anos. Mas não sei o quão viável seria obrigar que os resultados fossem publicados -- afinal, em princípio, pode-se argüir que as vulnerabilidades são propriedade das instituição tanto quanto os computadores que as "hospedam". Questão filosófica para teóricos do direito se esbaldarem: até onde vai o meu direito de esconder um problema que te afeta?

Além disso, quais seriam os padrões para a guarda desses resultados enquanto os NDAs estiverem em vigor? Como seria exatamente o processo de publicação? Viraria um documento público? Seria publicado no Diário Oficial? Ou em alguma revista especializada? Aos poucos ou tudo de uma vez?

Mais ainda: e se a instituição simplesmente se recusasse a cumprir a obrigatoriedade do item (1), o que aconteceria? Seria multada? Tenho uma sugestão: que tal congelar-lhe o domínio? (Isso torna o nome "algo.com.br" inválido na Internet, efetivamente tornando o site inacessível aos visitantes).

Anteriormente eu mencionei uma possível luz no fim do túnel. Em um post anterior no meu blog, comentei sobre grupo de desenvolvedores preocupados em criar softwares e redes que, por projeto, já nasçam sem vulnerabilidades. Um ponto correlato é discutido por Bruce Schneier em sua coluna na revista Wired, onde ele argúi que não precisaríamos da indústria de segurança da informação se os programas de computador já nascessem intrinsecamente seguros. Tentar implementar isso é talvez a mais nobre das iniciativas, mas também, de longe, a mais hercúlea; requer uma mudança de cultura sem precedentes na história da computação: focar em segurança ao invés de funcionalidade ou performance. Por isso mesmo, está sendo lenta. Pode ficar muito mais rápida se a demanda por sistemas seguros aumentar; e expor as vulnerabilidades é uma boa maneira de fazer isso.

Só o aumento na demanda por profissionais especializados na segurança de sistemas computacionais possivelmente já seria um ganho inestimável de uma lei dessas. Forçaria os cursos técnicos e universitários a realmente incluir uma abordagem séria sobre esses assuntos em seus currículos. Hoje o formado em informática costuma sair incrivelmente ignorante sobre como achar, e mais importante, sobre como não gerar vulnerabilidades.

Pensamentos finais

Quando eu circulo essas idéias informalmente entre colegas de profissão, muitos abanam a cabeça em incredulidade e retrucam algo como: "Kiko, você é doido? Quer dar aos maus elementos uma receita para invadir os sites dos outros?" Não, eu realmente não quero. Rejeito a noção de que isso seria análogo a "entregar arma a bandido": se alguém usasse as informações para invadir os sites dessas instituições, ele estaria sujeito às sanções penais previstas em lei; além de que seria burrice, pois atirar justamente em um alvo visado é uma ótima maneira de acelerar ser pego. Mas confesso que gosto do fato que quem teria de assumir esse risco é quem o criou em primeiro lugar.

O que eu gostaria mesmo é que as vulnerabilidades fossem consertadas, que os sites fossem mais seguros, que os esqueletos fossem enterrados. Adoraria ver as taxas de sucesso em nossos projetos de EH diminuindo drasticamente, porque isso significaria que eles estão realmente contribuindo para que as coisas melhorem. A questão é que nossos dados indicam que ou isso não está acontecendo, ou está acontecendo tão devagar que sete anos ainda não foram suficientes para se perceber alguma mudança significativa.

Publicar as vulnerabilidades daria à questão a visibilidade que ela merece: deixaria claro o zelo (ou falta dele) que as instituições dão aos seus sites. As pessoas poderiam optar por não fazer compras em sites inseguros ou exigir de seus representantes para que os sites de serviços públicos/governamentais resistissem àqueles ataques.

Há precedentes do sucesso de certas leis em tratar problemas de segurança. A exigência do cinto de segurança e extintores de incêndio em carros²; a própria engenharia deles foi mudada ao logo de várias décadas para torná-los mais resistentes a colisões. As empresas recebem inspeções periódicas do corpo de bombeiros. A indústria da aviação é fortemente regulada; e, como recentemente veio a público, uma política de silêncio corporativista vinha encobrindo falhas estruturais graves nessa infra-estrutura -- mas, mesmo assim, ela ainda é de longe o meio de transporte mais seguro que existe.

A História mostra que a obscuridade, seja na gestão pública ou na catalogação de vulnerabilidades, invariavelmente colabora para a perpetuação dos esqueletos nos armários. Já a transparência traz consigo o potencial de enterrá-los de uma vez por todas. Os Ethical Hackings resolvem a parte técnica do problema. Nesse ensaio, mostramos que parece haver a possibilidade de conceber algum tipo de regulamento ou incentivo para resolver a outra parte do problema.

---

Notas:

1. Por brevidade e no interesse de tornar o texto mais acessível, empreguei o termo "site" de uma forma ampla, querendo dizer não só as páginas visíveis pelo navegador, mas também rede corporativa e os computadores das instituições que criam tudo isso.
2. Essas analogias são imperfeitas porque o foco dessas leis é em prevenir ou minimizar as conseqüências de acidentes, ao passo que a exploração das vulnerabilidades em sites é uma atividade intencional. E nenhuma delas se aplica ao "mundo virtual", onde as regras do jogo são diferentes.

Comentários

Envie para: .
topo