Esta é a oitava 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.
No escritório, Gafanhoto toma seu café da manhã com toda calma, pois, para ele, é a melhor refeição do dia. Não é à toa que ele sempre repete este ritual, tomando o seu café da tarde como se fosse o da manhã.
Depois de um banho bem gelado, os irmãos estavam preparados para o dia. Eles sabiam que os testes em seu site já estavam chegando ao final e queriam saber como aconteceu aquele defacement e, mais que isso, se algum documento em seu servidor fora copiado indevidamente.
A hora passou rapidamente e nem sinal do Aranha chegar. Gafanhoto já estava preocupado: Será que aconteceu algo? Acidente? Vou ligar para o … pensava ele. Quando o telefone tocou, Aranha estava do outro lado da linha.
– Gafanhoto! Viu, não vou trabalhar hoje, pois terei que ministrar aquela palestra.
– Qual palestra?
– Aquela que você revisou e me ensinou como se faz!
– Nossa, outra vez… quantas palestras você ministrou hein?! Parabéns!
– Bastante né! Não vou trabalhar então, até mais!
Aranha se despediu com certa pressa. Gafanhoto estranhou o comportamento do seu colega. Talvez estava animado demais, mas agir desta forma… era muito esquisito. “Enfim”, pensou ele, “vou dar continuidade ao pentest explorando aquela falha de SQL Injection“.
Diante de seu notebook, Gafanhoto acessa o site dos irmãos. Os Não-fiz-teste tomaram alguns cuidados durante a confecção do Vai-e-Volta, porém não pensaram que do lado do usuário é possível digitar quaisquer dados, maliciosos ou não, e que estes dados, deveriam ser tratados pela aplicação antes de chegar ao banco de dados em que o banco de dados está instalado. Vejamos como funciona:
O usuário navega pela Internet através de seu navegador predileto. Ao acessar o site Vai-e-Volta, ele escolhe a imagem de uma obra e clica sobre ela, abrindo a sua página. Na URL temos uma referência a esta imagem, assim:
http://www.vaievolta.br/obra.php?id=1
O usuário não está vendo, mas esta requisição faz uma consulta ao servidor de banco de dados. Caso o objeto exista, o banco de dados repassa os dados que serão mostrados na página. Como na figura abaixo:
SQL Injection — #1
Podemos ver que o usuário está na camada de Apresentação. Quando ele faz a requisição da imagem ela é passada para camada Lógica, onde temos a codificação feita em PHP, ASP etc. A camada Lógica envia esta requisição (consulta) para o banco de dados, que por sua vez retorna para a camada Lógica, a qual envia novamente para o usuário.
No entanto, se um usuário malicioso resolver testar o site para ver se está vulnerável a SQL Injection, ele irá alterar a requisição por algum dado não esperado pelo banco de dados, como:
http://www.vaievolta.br/obra.php?id=gafanhoto
O que não pode acontecer é que está requisição seja passada e tratada pelo banco de dados. Como gafanhoto é uma string, ou seja, uma palavra, e temos que, neste caso, a consulta é feita com números, id=1, o banco de dados não irá executar tal consulta e, em vez de retornar dados, retornará um erro. Este erro será repassado para a camada Lógica e será mostrado para o usuário.
SQL Injection — #2
Desta forma, o usuário saberá que a aplicação está vulnerável e poderá começar a injetar instruções SQL a fim de obter informações do banco de dados.
O que seria ideal para prevenir este ataque? Quanto a apresentação dos erros, pode-se criar uma página genérica avisando que o resultado da consulta não existe. Ou então, a página consiga controlar entradas estranhas através de funções implementadas na camada Lógica, para que os dados de entrada do usuário . Ou seja, como gostam de dizer, sanitizar tais entradas não permitindo seguir adiante. Desta forma:
SQL injection — #3
Gafanhoto, enquanto trabalhava gostava de pensar o que acontece nos bastidores.
No fim, o nosso amigo solitário conseguiu obter acesso ao banco de dados através de injeção de comandos SQL na URL. Porém, os irmãos se preveniram e criptografaram a senha do administrador utilizando o método bcrypt para criar o hash. Para isso, os irmãos usaram um programa apropriado em vez de optar por sites que também fazem este tipo de serviço. O problema destes sites é que o par senha:hash ficam armazenados em seu banco de dados, sendo de fácil consulta para qualquer pessoa curiosa.
O problema mais grave do Vai-e-Volta, e que torna este ataque mais perigoso ainda, é que era possível, com certas consultas SQL, ler arquivos (load_file) e salvar dados selecionados em um arquivo através instrução select … into outfile na URL.
Gafanhoto ainda tinha muito que pensar: rever dados coletados, informações organizadas de acordo com grau de gravidade etc. Era muito cedo para supor algo, mas já tinha uma ideia do que o atacante conseguiria fazer com tal falha.
Já é tarde e Gafanhoto decide ir embora, quando toca o telefone.
– Gafanhoto, é o Aranha. É seguinte, não volto mais para trabalhar aí, agora tenho outro local, vou ganhar mais e serei conhecido.
Gafanhoto que já estava em pé, sentou-se novamente e perguntou: “Como assim?”
“Você sabe né, como são as coisas”, Aranha respondeu com uma voz seca e mal-humorada, e completou: “Até mais e boa sorte!”, desligando o telefone na cara de seu colega.
Gafanhoto, assustado com esta mudança brutal de comportamento, embora já acostumado com a atitude de certas pessoas do passado, se levanta, olha para a mesa do Aranha e murmura: “Traição, ambição e ganância, até parece novela!”. Gafanhoto dá um suspiro, caminha até a porta e finaliza: “Depois eu é que sou a praga!” e vai-se embora.
Esta é a oitava 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.
Linha Defensiva 
Meeeu DEUS :O
O Aranha foi muito babaca pp reto pqp mané :/ que otario nuss
CurtirCurtir
Infelizmente o mundo está cheio deles… ;-)
CurtirCurtir