No Natal desse ano, o SQL Injection vai poder entrar em um bar qualquer e pedir uma bebida.
Talvez ele tenha que mostrar os documentos, mas a grande verdade é que a vulnerabilidade preferida de 11 em 10 hackers irá completar 18 anos em 25 de Dezembro de 2016.
Inicialmente, ela nem mesmo tinha esse nome. Ela sequer tinha nome. Desde aquela época (e até hoje, vale dizer) ela foi subestimada por seus criadores e por desenvolvedores de uma forma geral. Mas ela continua fazendo vítimas, ano após ano, porque é um ataque tão fácil de fazer e automatizar que até uma criança de três anos é capaz de executar. Sem exageros.
O primeiro indício de sua existência foi publicado no e-zine Phrack #54, de 25 de Dezembro de 1998. Um bastião da cultura phreaker, fundada em 1985, a revista/manifesto/site marcou história em diversos momentos, mas naquela edição em especial ela introduziu o SQL Injection para o mundo. Coube a Jeff Forristal, na época conhecido pela alcunha Rain Forest Puppy, a dúbia honra de ser o autor do artigo, com a ajuda de um amigo não identificado.
Forristal hoje é CTO da empresa de segurança mobile Bluebox. Mas, em 1998, ele queria ver o mundo pegar fogo. Segundo ele escreveu, seu parceiro na descoberta tentou notificar a Microsoft sobre como era fácil injetar comandos em páginas web que faziam consultas a um banco de dados SQL: “ele fez a coisa certa e contou para a Microsoft, e a resposta deles foi, bem, hilária. De acordo com eles, o que vocês estão prestes a ler não é um problema”. Em seguida, Rain Forest Puppy explica em vários parágrafos como usar e abusar da ingenuidade do SQL (e da Microsoft) para obter dados que deveriam ser privados, enviar instruções e outras sabotagens em páginas e formulários sem tratamento para entrada de dados.
Estavam abertos os portões do Inferno.
Em 2005, um adolescente invadiu o site de uma revista de segurança da informação em Taiwan e furtou dados de seus assinantes. Usando SQL Injection.
Em 2006, hackers russos invadiram os sistemas do governo do estado norte-americano de Rhode Island e conseguiram dados de cartão de crédito de empresas que fizeram transações online com estatais. Usando SQL Injection.
Em 2007, o site britânico da Microsoft foi comprometido e descaracterizado. Usando SQL Injection.
Em 2009, 130 milhões de números de cartões de crédito foram furtados por três hackers nos Estados Unidos dos sistemas de lojas como 7-Eleven, cadeias de supermercados e financeiras de uma única vez. Usando SQL Injection.
Em 2010, o painel de controle do The Pirate Bay e dados de seus administradores e usuários foram comprometidos por um especialista de segurança. Usando SQL Injection.
Também em 2010, o site oficial da Marinha do Reino Unido foi comprometido e descaracterizado por um hacker da Romênia. Usando SQL Injection.
Em 2011, o próprio site oficial do MySQL foi invadido. Usando SQL Injection.
Em 2015, os sistemas da empresa de telecomunicações britânica TalkTalk foram invadidos e dados de 4 milhões de usuários foram furtados. Usando SQL Injection.
Como se pode ver, a tática de 1998 não apenas se tornou global como continua ativa mesmo quase duas décadas após sua divulgação inicial. Por quê?
W0rm, pseudônimo do hacker responsável por um ataque ao site do The Wall Street Journal, resume muito bem: “é a forma mais fácil de hackear”. Mustafa Al-Bassam, atualmente um profissional de segurança, mas também um ex-integrante do infame coletivo hacker LulzSec, confirma a afirmação e já conseguiu “ensinar” o método para seu filho de três anos.
Embora o SQL Injection possa ser feito “no braço”, com o próprio hacker digitando os comandos e pesquisando sites vulneráveis a essa abordagem, atualmente o processo pode ser fortemente automatizado com ferramentas amplamente disponíveis para quem quiser pesquisar sobre o tema. De acordo com Al-Bassam, uma dessas ferramentas “vasculha as páginas de um site, de forma similar a um robô de mecanismo de busca, procura por entradas de dados de formulários no site, e envia os formulários com entradas que podem causar um erro de sintaxe de MySQL”. Basta digitar a URL para iniciar a busca por vulnerabilidades.
De posse desses programas, basta preparar uma lista de endereços e aguardar os resultados. É um processo tão simples para quem está começando sua “carreira” pelo hacking que o pesquisador de segurança gravou um vídeo onde mostra seu filho de três anos conseguindo explorar o universo do SQL Injection.
Outro fator para a perenidade do SQL Injection é a desinformação ou desleixo por parte dos administradores de bancos de dados. Quase tão antiga quanto a vulnerabilidade são os métodos para se evitá-la. E, ainda assim, ano após ano, os ataques continuam. Troy Hunt, fundador do haveibeenpwned.com, já viu dezenas de vazamentos de dados em sua carreira e alerta: “SQL Injection sempre é o risco número um”.
Al-Bassam sugere o uso de bibliotecas já existentes de SQL para limpar a entrada de dados. Mas, para o pesquisador, o problema pode estar na cultura das empresas: “qualquer programador sério deveria sobre SQLi, mas há uma escassez maciça de programadores, então as empresas contratam qualquer um mesmo que eles não tenham o treinamento correto ou a experiência para neutralizar vulnerabilidades básicas”. E denuncia: “eles são frequente colocados sob pressão por seus gerentes para desenvolver software funcional ao invés de software seguro”.
Embora a facilidade da aplicação do SQL Injection não possa ser revertida, aquilo que a Microsoft considerou lá atrás “não ser um problema”, as defesas dos bancos de dados podem e devem ser fortalecidas. Enquanto não houver uma mudança nesse cenário, aquela Caixa de Pandora aberta e 1998 ainda continuará entre nós por muitos e muitos anos.
Confira nossas dicas para não fazer parte dessa história:
