Reciclando Hackers — A história dos irmãos Não-fiz-teste: #6

Esta é a sexta parte de uma história fictícia (ou não) sobre testes de invasão. Clique na tag Reciclando Hackers para conferir todas as partes publicadas.

---

O dia já havia amanhecido e os irmãos ainda dormiam. O céu estava nublado, a temperatura fria; ventava muito, chamando uma chuva para aquela região que parecia ser uma bela tempestade. Os dois irmãos tinham idades completamente diferentes, mas nasceram na época do inverno e, apesar de suas diferenças de personalidades, eles dormiam muito.

Do outro lado do bairro, a alguns quilômetros de distância, Aranha e Gafanhoto já estavam no escritório organizando todo o material para poder dar continuidade aos testes no Vai-e-Volta. Os irmãos, durante a primeira reunião, não estipularam um horário de testes, eles deixaram em aberto, não importando se fosse durante o dia ou durante noite e/ou de madrugada.

Uma vez tudo arrumado e organizado, Aranha iniciou a próxima fase atualizando os plug-ins de dois scanners de vulnerabilidade que ele e, seu colega, iriam utilizar: Nessus e OpenVAS.

Ambos são scanners gratuitos. Embora o Nessus possua versões pagas, nossos analistas gostavam de pegar um caso por vez e não viam necessidade de comprar tal licença. É bom notar que este tipo de teste muitas vezes é deixado de lado pelos pentesters, pois durante as fases anteriores já se tem toda visão do que acontece no alvo: suas vulnerabilidades e como explorá-las.

Como nossos analistas brincalhões tinham suas disciplinas, eles gostavam de utilizar os scanners como forma de confirmar e corroborar suas teorias sobre o que planejavam. Além disso, o trabalho feito pelos scanners era como se fosse um descanso para eles, e o resultado final de cada análise era como uma prova do que fizeram: mostrando o que acertaram e o que deixaram de lado, o que pode acontecer com qualquer analista. No entanto, os resultados sempre devem ser verificados e confirmados, pois podem ser falsos positivos apontados pelos scanners.

De volta à casa dos irmãos, o Sol já estava a pino quando eles começaram a se espreguiçar em suas camas. Aquele clima frio era familiar e aconchegante: dormiam quase o dia todo quando bebês, somente acordavam para mamar ou por causa de algumas cólicas irritantes.

Enquanto isso, em um restaurante qualquer, no exato momento em que os dois irmãos acordavam, Gafanhoto tinha dado a última garfada em sua refeição. Gafanhoto sempre procurava uma mesa vazia, longe de todos. Ele gostava de almoçar cedo, comia de tudo, mas sempre procurava fazer uma alimentação equilibrada, sem sal e bem colorida, o alimento em seu prato era colocado de forma a formar figuras abstratas e com formatos irregulares.

De volta ao escritório, Gafanhoto viu Aranha já analisando os resultados dos scanners. Aranha virou para seu amigo e disse “terminou agora!”. Gafanhoto perguntou “o que apareceu?!” e seu colega aracnofóbico respondeu com um tom de satisfação: “uma novidade ou outra, porém as falhas graves nós identificamos todas!”. Gafanhoto sorriu e sentou-se, e sabendo agora qual seria a atitude do seu previsível colega, apenas aguardou.

“Gafanhoto”, exclamou Aranha, “foi mais que confirmada a vulnerabilidade de SQL Injection, explique sobre ela”.

Gafanhoto sabia que daqui para frente seria um jogo de perguntas. Foi uma maneira que os dois encontraram para sempre estarem atualizados, embora tal falha seja bem antiga.

Gafanhoto levantou, pegou um copo d’água, sentou-se novamente, respirou fundo e se dispôs a falar sobre SQL Injection.

— Esta falha creio que seja uma das mais antigas e que persiste até os tempos atuais. Ela tem uns 15 anos e ainda assim é sempre listada nas 10 falhas mais perigosas pela OWASP. Grosso modo, ela se resume à simples injeção de consultas feitas em SQL, consultas estas maliciosas, convencendo a aplicação a te dar uma reposta que ela não estava esperando. Por exemplo, o nome do banco de dados, versão e dados mais sensíveis. Para incluir as consultas em SQL no site, basta localizar alguma URL que aceite tais códigos e/ou formulários, especialmente a página de login.

— Isso ocorre porque a aplicação não valida ou codifica corretamente entradas criadas pelo usuário, desta forma, o usuário se aproveita desta falha e inclui comandos maliciosos como parte de suas consultas feitas diretamente para o banco de dados existente por trás da aplicação.

Assim que concluiu sua explicação inicial, Gafanhoto se levantou e foi em direção a uma enorme lousa parafusada em uma das paredes do escritório. Na verdade, era uma lousa digital, com canetas esferográficas, pois Gafanhoto era alérgico a pó e perfumes. Virou-se para seu colega e disse: “vamos a um exemplo”.

— O caso mais tradicional seria uma injeção de comando numa página de login. Primeiramente vamos entender o que acontece no banco de dados quando dados (usuário:senha) são inseridos nos campos do formulário de acesso. Imaginemos o painel:

— Ao inserirmos nossos dados nos campos Usuário e Senha, será feita uma consulta ao banco de dados, que está por trás da aplicação. Esta consulta pode ser entendida como uma busca ou uma pesquisa por palavras que coincidam com os dados que foram colocados. Então temos este tipo de declaração na aplicação para realizar a consulta:

select * from usuários where usuário = ‘ ‘ and senha = ‘ ‘;

A consulta acima verifica todos os dados (*), da tabela usuários, onde o par usuário e senha devem estar cadastrados no banco de dados. Ou seja, ela busca por uma coincidência armazenada. Inserindo os dados:

No banco temos a seguinte consulta:

select * from usuários where usuário = ‘admin’ and senha = ‘admin’;

Uma vez confirmados os dados, o usuário é direcionado para a página de administração. Note que no campo Senha aparecem aquelas bolinhas e não a senha em texto claro — só deixei assim por questão de visualização.

Mas aí vem um espertinho e testa a aplicação: a ideia é provocar um erro para ver se ela está filtrando entradas que não são esperadas. Ele muda a consulta desta forma:

 

Novamente, temos no banco de dados:

select * from usuários where usuário = ‘ad’min’ and senha = ‘admin’;

Note que foi adicionado mais um apóstrofo na palavra admin. Isto mesmo, apóstrofo, “aspas simples” é um terrível erro de português; pior ainda é “aspas duplas”, isso não existe aqui no Brasil. Single quotes ou double quotes são palavras estrangeiras e não são aportuguesadas. Muitas pessoas comentem este tipo de erro — desabafa Gafanhoto.

Depois de uma bela respirada, Gafanhoto dá um gole em sua água e continua.

— O que está entre os apóstrofos representa uma string, um conjunto de caracteres, como um nome. Ao fechar a palavra admin, com um apóstrofo a mais, será consultado em primeiro lugar pela palavra ad, a qual não está cadastrada. Em seguida, o interpretador SQL continua verificando o resto da consulta, como min não representa nada, ou seja, não é um comando válido, e os irmãos não tomaram providências para filtrar este tipo de consulta, será retornado um erro na página. Tal erro, indica a vulnerabilidade.

Encurtei o erro propositalmente, riu Gafanhoto. A partir daí o atacante pode começar a experimentar comandos — instruções SQL — mais sofisticados para tirar proveito da falha na aplicação. É isso, finalizou Gafanhoto.

Aranha se levantou e aplaudiu seu amigo. Gafanhoto aproveitando as palmas de seu colega e aproveitando-se da brincadeira, fez um gesto de reverência se curvando com um sorriso de satisfação. Aranha finaliza: “”este tipo de vulnerabilidade é facilmente encontrada através de um script”.

Ao final da tarde, Victor e Manuel estavam trabalhando em uma nova escultura. Feita com latas de leite em pó, latas de cerveja, papelão, rodas de carrinho de rolimã e mais algum material que estava em pedaços. A aparência inicial do projeto se parecia com a de um robô — os irmãos estavam inspirados com toda sua história no mundo digital.

---

Esta é a sexta parte de uma história fictícia (ou não) sobre testes de invasão. Clique na tag Reciclando Hackers para conferir todas as partes publicadas.