Agora que o título já chamou sua atenção, eu preciso esclarecer que o que você lerá a seguir pode ser somente uma fábula sobre segurança. Mas também existe a possibilidade de ser a descrição do crime perfeito. De um jeito ou de outro, é um alerta importante que não deve ser ignorado.
Em um momento em que a comunidade de segurança parece sacudida pelas possibilidades quase arcanas de extração de dados através de falhas sofisticadas nos próprios processadores, um especialista chamado David Gilbertson, que pode ou não ser o seu nome verdadeiro, abriu o ano com um texto que pode ou não ser a definição da mais sutil, capciosa e fácil de implementar fraude eletrônica dos últimos tempos.
Ele aprendeu como furtar dados de cartão de crédito, logins e senhas de milhares de sites sem que ninguém perceba.
Então, você se pergunta: “como?”. E eu respondo: alinhando uma série de vulnerabilidades na forma como a comunidade open source opera e implementando diversos truques para burlar detecção. Em uma única frase, a mensagem é clara: não confie em código fornecido por terceiros em seu site.
Modus Operandi
Segundo Gilbertson, o segredo é injetar código no site alheio. Não é necessário ser um especialista para saber que, a partir do momento em que um invasor tem acesso ao código fonte do seu site, é fim de jogo. Normalmente, esse tipo de ataque é realizado através de um ataque ao servidor ou utilizando scripts que funcionam em outros domínios mas conseguem interagir com o código do seu domínio (o chamado cross-scripting).
A sacada de Gilbertson é pular essas etapas. Para quê quebrar a cabeça tentando invadir o site alheio se isso pode ser feito espontaneamente pelo próprio administrador do site?
O autor do texto se aproveita do conceito dos Cavalos de Troia ou dos ataques de malvertising, comprometendo um plugin ou pacote npm com seu código. Esse plugin aparentemente inofensivo realiza alguma funcionalidade útil ou soluciona um problema de algum outro plugin e acaba sendo baixado por usuários desavisados. Gilbertson vai além e alega que não é difícil para que seu pacote do mal se torne uma dependência para outros projetos do Github, ampliando seu alcance. Aumente sua superfície de ataque com mais de um pacote preparado, com diferentes “utilidades”, mas a mesma carga nefasta, e está pronta a receita para se alcançar centenas de milhares de sites sem precisar forçar a entrada em nenhum deles.
Olhando para trás para aqueles anos dourados, não posso acreditar que as pessoas realizassem tanto esforço para mexer com scripts entre sites apenas para obter o código em um único site. É tão fácil enviar códigos maliciosos para milhares de sites, com pouca ajuda dos meus amigos de desenvolvedores web.
Ficção? Na verdade, já aconteceu antes e mais de uma vez: plugins com vulnerabilidades distribuídos em larga escala. Para que tal incidente aconteça de forma intencional basta malícia. Talvez já esteja acontecendo, nesse exato minuto. No seu site. No meu. Ou em ambos.
A partir daí, como já foi dito, é fim de jogo. O texto poderia parar por aqui, mas eu explico: o código de Gilbertson é capaz de identificar a existência de campos de formulário nas páginas onde está presente, um JavaScript primário que até o mais obtuso iniciante seria capaz de escrever. O conteúdo do formulário é capturado em silêncio e enviado para o servidor de Gilbertson. Depois de filtrar os dados que chegam, ele compila tudo em um banco de dados e vende no mercado negro: logins, senhas, emails, números de cartão de crédito (incluindo códigos de segurança).
Como um ninja!
Se você não entende de segurança digital, deve estar suando frio agora. Se entende, deve estar suando frio também, mas com a cabeça cheia de perguntas. Gilbertson antecipa algumas dessas dúvidas e rebate como é possível que seu esquema permaneça indetectado com tantos mecanismos automatizados de proteção em funcionamento ou como ele desvia dos especialistas.
Primeiramente, o código malicioso muda seu comportamento se está sendo observado: ele não é executado dentro do DevTools, não roda em um localhost ou qualquer domínio que possa indicar um ambiente de desenvolvimento. É uma prática que não foi inventada por Gilbertson e já é adotada por qualquer criador de malware com mais de dois neurônios. São táticas utilizadas para ludibriar o trabalho dos especialistas e driblar armadilhas de empresas de segurança.
Por conta disso, o ladrão de dados de Gilbertson só realiza suas atividades maliciosas fora do horário comercial, quando a maioria daqueles que poderiam detectá-lo estão trabalhando. Testes de rotina e monitoramento de tráfego de rede também costumam acontecer dentro desse período. O seu criador acaba perdendo também uma larga fatia de vítimas, mas mantém seu esquema operando por um período maior e ganha a longo prazo. Usando cache e cookies, tampouco o mesmo golpe é aplicado duas vezes no mesmo alvo, reduzindo ainda mais as chances de detecção.
“O ponto é, só porque você não vê, não significa que isso não está acontecendo”, se gaba o “golpista”.
Mas o próprio Github não barraria a entrega da carga viral diretamente na fonte? Gilbertson então expõe uma vulnerabilidade alarmante: é possível submeter um código para o Github que é diferente daquele que é efetivamente empacotado no npm.
Além disso, com uso cauteloso de código, é perfeitamente possível esconder as reais intenções de suas funções maliciosas mesmo visíveis na versão “minified” do código. Em outras palavras, até um administrador de site competente, com conhecimento de scripts, poderia ser facilmente enganado com um código incompreensível, a menos que ele estivesse procurando especificamente por falhas de segurança. Obfuscação pode ser uma faca de dois gumes…
Blindando seu site
É claro que o senhor David Gilbertson não cometeu crime algum e está apenas ilustrando uma série de pontos críticos que precisam ser corrigidos na segurança de sites e plataformas. A menos que todo o artigo seja um duplo engodo e ele tenha uma conta bancária secreta engordando em algum paraíso fiscal, talvez em criptomoedas, quem sabe?
Não há escassez de pessoas inteligentes e desagradáveis lá fora, e 400.000 pacotes npm. Parece-me que as chances são enormes de que pelo menos um desses pacotes tenha algum código malicioso nele, e que, se bem feito, você nunca saberia.
Mas de pouco serviria um alerta bombástico desse porte se Gilbertson não oferecesse sugestões para bloquear o ataque que ele mesmo engendrou. Seria praticamente uma apologia ao crime, o que também é crime.
Ele explica então que uma Content Security Policy (CSP) implementada para o servidor é capaz de proteger sites e visitantes contra esse tipo de coletador de campos de formulários. Desde que o visitante não esteja usando o Chrome, já que por enquanto existe uma forma muito simples de enganar o navegador do Google, mesmo com uma CSP ativa no site.
Essa estratégia de segurança funciona não apenas restringindo o que pode ir para o navegador, mas também o que sai do navegador, que é o modelo de ataque do seu cavalo de Tróia. É por isso que um hacker poderia, como Gilbertson sugere, verificar a existência de uma CSP em ação e pausar a ação maliciosa do seu código para evitar detecção. O golpe continuaria existindo, mas sites e usuários estariam protegidos.
Mais alarmante é a revelação por parte do autor de que grandes sites como Amazon e Ebay não possuem uma Content Security Policy em ação nas páginas onde seus usuários adicionam dados críticos, como cartões de crédito e senhas, enquanto outros, como Twitter e PayPal, até possuem o recurso, mas ele ainda é fácil de burlar.
Então, se o uso de um CSP não é garantia de proteção, o que um administrador de site de pequeno porte que sequer sabe o que é um CSP pode fazer para garantir que seu formulário está seguro? Se não ficou óbvio ainda, eu repito: não confie em código de terceiros.
Gilbertson dá o conselho mais claro e simples possível: isole seu formulário em uma página que não use nenhum código que você mesmo não tenha feito. Nada de código de publicidade, nada de código de data mining, nada, mas nada mesmo, de plugin algum ou framework. Até mesmo o JavaScript utilizado para validação seria bom se fosse criado do próprio punho. Se preciso for, isole o formulário do template da página usando um iframe: é feio, mas resolve o problema.
Gilbertson prometeu uma continuação do artigo, com mais precauções que podem ser tomadas para evitar se expor a esse tipo de ataque silencioso. Se ele estiver falando a verdade sobre não ser um hacker e não for preso primeiro, é claro.
