3 min de leitura ·

Laboratório - SQL Injection

Saudações!

Nesse artigo eu irei relatar minha experiência com dois laboratórios da plataforma PortSwigger: SQL injection attack, querying the database type and version on Oracle e SQL injection attack, querying the database type and version on MySQL and Microsoft .

A função aqui é mais documentar o que eu aprendi e fixar na minha memoria. A função dele não é ser um passo a passo detalhado, está mais para um caminho ou para um monte de dicas.

Lembrando que testar aplicaçõe sem a devida permissão é crime. Não interessa se você quer fazer uma boa ação, continua errado. Como diria Alan Grant:

"As piores coisas que se podem imaginar foram feitas com as melhores intenções"

Primeiro vamos resumir o que é o SQL Injection. SQLI é uma vulnerabilidade no banco de dados das aplicações web que permitem o atacante acessar, modificar ou deletar informações de outros usuários bem como usernames, emails e senhas e etc. Essas vulnerabilidades são normalmente encontradas nos inputs do usuário ou em filtros.

Para realizar esses dois laboratórios vamos precisar de uma ferramenta chamada Burp Suite, essa ferramenta permite interceptar, modificar e automatizar requisições. Caso você tenha o Kali Linux, é uma ferramenta nativa.

Oracle

Observando a aplicação podemos ver que temos algumas categorias pré-definidas e ao clicar nessas categorias o conteúdo da página muda de acordo. Agora podemos fazer o seguinte: no burp ligamos o proxy para interceptar o trafégo e então voltamos para o navegador e clicamos em qualquer filtro para que o GET chegue até o burp. Eu recomendo enviar essa requisição para o Repeater pois fica mais fácil de visualizar. Observando o GET podemos ver várias informações como o host, idioma, cookies e por aí vai. Mas o interessa nesse caso é o que está na primeira linha:

GET /filter?category=Gifts HTTP/2

Essa linha é o que simboliza a querie do SQL e é nela que iremos trabalhar. Uma forma de fazer um teste é inserindo o seguinte comando em "category":

'+UNION+SELECT+'abc','def'+FROM+dual--

Vamos dar uma olhada nas particularidades desse comando, deixando de lado a parte do SQL. Os " ' " servem para quebrar a string do sistema e inserir o código, os sinais de "+" são necessários pois o burp não lê espaços e "--" é para comentarios no SQL, porém aqui ele serve para ignorar o resto da linha depois do comando. Esse comando vai inserir os campos 'abc' e 'def' no banco de dados, que pode ser vista no campo "Response"(lembrando que estou usando o Repeater, você deve se adaptar de acordo com seu método). Nesse caso você podera visualizar a inserção desses campos no final do Response.

Agora ficou fácil, a única coisa que precisamos alterar é o comando, o processo e a lógica é a mesma. O comando para descobrirmos a versão no Oracle é o seguinte:

'+UNION+SELECT+BANNER,+NULL+FROM+v$version--

Esse comando nos retorna o tipo e a versão do banco de dados, que será exibido em Response no mesmo lugar do nosso teste, solucionando o nosso laboratório.

Microsoft/MySQL

Todo o processo é o mesmo, inclusive a aplicação é igual. A única coisa que muda aqui será os comandos do SQL. O comando de teste é o seguinte:

'+UNION+SELECT+'abc','def'--+

Esse comando me deu uma dor de cabeça. Fiquei um tempo testando ele e sempre dava erro, então resolvi recorrer ao GP(en)T(ester) para descobrir que o que faltava era o "+" no final do comando, absurdo. De acordo com o mesmo, isso pode ter várias causas, desde problemas com truncamento, parsing e interpretação do comando.

'+UNION+SELECT+@@version,+NULL--+

Esse é o comando para exibir a versão, a única particularidade são os comandos do MySQL, e o laborátorio está resolvido.

Descobrir qual é o seu banco de dados e sua versão possibilitam o atacante explorar vulnerabilidades conhecidas para aquele sistema. Algumas formas de se proteger é evitando consultas dinâmicas com queries preparadas, sanitização das entradas do usuário e boas práticas de programação. Caso tenha alguma dica, por favor, compartilhe!

Por hoje é isso, muito obrigado pela atenção. Desculpem se o blog ficou um pouco grande, tentei resumir o máximo possível.

Fiquem bem!

ivanPechim

10 dias atrás

Eu gostei do artigo. Se me permite perguntar, a qual crime se refere quando diz: "Lembrando que testar aplicaçõe sem a devida permissão é crime" ?
Lendo este artigo da UFL, encontra se o seguinte paragrafo:

Deste modo, quem encontra vulnerabilidade em sistema alheio, mesmo sem autorização para pesquisa, e comunica o administrador, está realizando a “revelação responsável”, não podendo incidir nas penas o art. 154-A, agora previsto no Código Penal. Já a prova de conceito, desenvolvida por quem descobre falha em ativo, sem autorização do titular, dependerá da apreciação pericial para se verificar como afetava o dispositivo atingido e qual foi a extensão decorrente da PoC.

A questão seria a qual finalidade faz se o teste, o que abre diversas interpretações, é meio complexo ainda tipificar crimes ciberneticos, há muitas brexas. Te convido a lê-lo e também ler a lei 12.737, a qual eles referenciam no artigo.

hbm

10 dias atrás

Bom ponto, legislação criminal tipificar conduta de teste de sistemas como ilícito penal é temerária.

GLeite

Autor

9 dias atrás

Exatamente, é brincar com o perigo. Se você ainda pedir uma "recompensa" pro dono da aplicação eu acho que da mais problema ainda. No melhor dos cenários você vai ter que gastar com advogado pra não pegar alguma punição mais pesada.

ivanPechim

9 dias atrás

Cada caso é um caso, se tu estiver sem medo e com resguardo tu entra de cabeça no processo e esperam provar que o que tu fez foi de fato com intenção maliciosa. Eu concordo que é brincar com a sorte mas, devemos tomar cuidado de afirmar as coisas, sendo que não temos total certeza, como é o caso do "ser crime ou não".

GLeite

Autor

8 dias atrás

Exatamente e você tem razão, nos próximos irei colocar de forma diferente. Mas deixo aqui um caso que reflete bem meu ponto e confirma o seu. Mas é exatamente como você disse, tem que ter coragem e paciência. Aqui o vídeo.

GLeite

Autor

10 dias atrás

Primeiramente muito obrigado pelo seu comentário.

É justamente essa Lei 12.737 que eu tinha conhecimento. Hoje em dia eu faço curso e estudo com conteúdo estrangeiro, eles não citam alguma lei específica mas eles sempre rezam a mesma missa "Não faça pentest em uma aplicação que você não tem autorização, é crime, anti ético..." e por aí vai.

Mas nesse mesmo artigo da UFL que você citou tem as seguintes citações:

A questão da finalidade de “obter dados” é também polêmica. Para um grupo de juristas, a “espiada” não seria crime, só se falando em obtenção nos casos de cópia dos dados do dispositivo, ou quando o agente entra na “posse dos dados”. Para outra corrente, o simples acesso a dados (um select na tabela da vítima, por exemplo) já agride o bem jurídico protegido pelo Direito Penal, e demonstra a “intenção em obter dados” eis que já permite ao cracker, em certos casos, se beneficiar das informações, de modo que tal “contato” com os dados estaria inserido no contexto do “obter dados”, previsto no tipo penal.

O que eu acho que realmente é um problema aqui é essa questão do "obter". Imagina só, você vai lá e acha a falha no site de uma empresa, reporta e o cara fica bravo e te ameaça de processo. E pior, fica a mercê da interpretação alheia.

Eu realmente acho que avisar e combinar um serviço de pentest seja a melhor escolha, além de você lucrar com isso você também tem meios melhores de se defender como contratos e definir o escopo do pentest. Para praticar tem vários laborátorios iguais esses que citei, plataforma de bug bounty, então realmente acho que fazer um pentest ou até um serviço de OSINT sem consentimento é arriscado.