Tutorial SQLi avançado

[0KaL]

Se ainda não o fez, recomendo que leia Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., onde explico como ocorre o ataque SQLi, mostro como é feito o SQLi básico e mostro técnicas de defesa. Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... também é interessante. Além disso, é realmente necessário que você Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... e, obviamente, aprenda-a. O que você verá nas próximas linhas se tornará impesquisável daqui a alguns tempos e o conhecimento aqui adquirido deve ser utilizado apenas para fins acadêmicos. Não me responsabilizarei por danos judicialmente ou não que o mau uso do mesmo poderão lhe trazer. O que faremos aqui de forma alguma será para incentivar ao crime, mas sim, mostrar como o mesmo funciona (façam o que eu digo, não façam o que faço, mas de qualquer forma, se forem fazer, Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou um Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...).

Olá.
Certos de que você já conhece a linguagem SQL e é capaz de organizar ataques de SQLi básico, vamos dar início ao nosso tutorial de SQL Injection.
Em suma, SQLi (injeção de SQL) é um método de invasão onde você pode incluir e até modificar, em certos pontos, a instrução SQL a ser executada pelo servidor.
Sinceramente, não sei o que leva uma pessoa a utilizar tools como Havij. Nas últimas semanas, venho tentando utilizá-lo e só estou apanhando. Keyword... Para que? Fui no manual on-line e me falaram para iniciar um ataque manual!!! É mole? Se eu for iniciar, por que não terminar manualmente também? E se o target vulnerável fica após um login, o que fazer já que o Load Cookie não funciona de maneira alguma? E se eu quiser aprender alguma coisa? E se no computador da escola não tiver o Havij?
Creio eu que quando vários caracteres aparentemente ilegíveis pode assustar, mas depois que o ataque é realmente entendido, a opinião se modifica.
E, por favor, peço que os one-click-deface-likes me apresentem bons argumentos para que eu mude de lado. Mas, por enquanto, vamos continuar.
Primeiramente, vamos entender uma coisa: a instrução SQL é uma string demarcada por aspas simples ('), aspas duplas (") e/ou SQL quotes (`), sendo que a mais usada é a primeira. Ao realizar um ataque SQLi não podemos modificar o que está antes ao valor capturado do formulário. Apenas depois. Isto significa que nesta string, por exemplo, com o valor recuperado do formulário em negrito, só conseguimos modificar a parte em itálico:

SELECT login,password,id FROM usuarios WHERE login='hack' AND password='me'

Note que não podemos retirar a primeira aspa simples, antes do login inserido no formulário. Mas podemos fechá-lo. Quando inserimos uma aspa a mais na string e o desenvolvedor não aplica uma boa proteção, o servidor SQL não entenderá o porque da aspa estar ali e mostrará um erro. Note:

SELECT titulo,descricao,texto FROM noticias WHERE id='1''

Então, pela lógica, o servidor só executará uma instrução se o número de caracteres demarcadores for par. Caracteres demarcadores podem ser, como eu já disse, aspas simples, duplas ou SQL quotes. Para descobrir qual tipo de caractere demarcador o alvo está utilizando, teste os 3, colocando-o na entrada (podendo ser via GET ou POST). Ignore os erros que dizem que a tabela foi encontrada e aceite o erro que diz que a sintaxe está incorreta.
Aceitar um erro? Sim. No SQLi e, principalmente no SQLi blind (sobre o qual irei escrever um tutorial como este em algum tempo), nós trabalhamos em cima do erro. Uma mensagem de erro pode ser para o atacante uma mensagem de sucesso, ao mesmo tempo. Nas mensagens de erro é que você reconhece que servidor SQL está rodando ali. Não vá pela extensão do arquivo, ou Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar....
Vamos utilizar o Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... para servir de teste. Após se certificar que você possui Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... para isso, configure o login e senha do MySQL no arquivo /inc/config.php e instale o DVWA. Logue-se (login: admin e senha: password), configure o nível de segurança do DVWA para 'low' e clique em SQL Injection. Clique no botão [View help] e leia que sua missão é pegar as senhas dos 5 usuários do banco de dados, identificados com ID's de 1 a 5. Coloque número a número e veja que ele apenas te dará o primeiro nome e o sobrenome do usuário. Não é o suficiente!
Vamos testar este ''alvo'', para ver se é vulnerável. Vamos colocar a ID de qualquer usuário e uma aspa simples na frente. Vemos um erro de sintaxe. Ótimo! Como eu disse, este erro será nosso sucesso.
Antes de seguir em frente, lembra-se de como inserimos comentários em algumas linguagens?

// comentario
/* comentario */
:: comentario

Na linguagem SQL fazemos assim:

-- comentario

Ou seja, dois sinais de subtração, um espaço e o comentário em seguida. Com isso podemos transformar partes da instrução SQL em comentários, fazendo com que o servidor SQL não os execute. Vamos aproveitar isso e escrever no campo de ID do Damn Vulnerable:

1' or 1=1--

Lembre-se do espaço após os dois sinais de 'menos'. Fizemos, então, o servidor listar todos os usuários em que a ID for igual a 1 ou se 1 for igual a 1. Em outras palavras, isto sempre será positivo, ou seja, ele listará todos os usuários. Porém, mostrará apenas seus primeiros nomes e sobrenomes. Ainda não conseguimos a senha, mas isto já foi um grande passo.
Vamos agora obter a quantidade de colunas existentes na tabela atual que podemos utilizar. Para isso, mandamos o servidor ordenar os resultados por uma determinada coluna, definida por um número. Ou seja, se ultrapassarmos este número, ultrapassaremos a quantidade de colunas, e o servidor nos retornará um erro. Vamos digitar o seguinte no campo:

1' ORDER BY 1--

Deu certo? Claro! Agora, vamos tentar:

1' ORDER BY 2--

1' ORDER BY 3--

É interessante saber que também podemos injetar via GET, os valores que são enviados via URL, injetando nossas instruções diretamente na mesma.
Note que quando tentamos ordenar pela terceira coluna, ele nos retorna um erro. Então, temos duas colunas utilizáveis. Vale ressaltar que mesmo com este resultado, faz bem saber que não é equivalente a real quantidade de colunas na tabela, mas sim a quantidade de colunas acessada pela instrução. Ou seja, pode ser que haja na tabela a coluna 'nome', 'sobrenome', 'login', 'senha' e 'id', além de outras, como 'endereco', 'email', não sabemos. Mas já sabemos que apenas duas destas colunas são requisitadas pelo sistema. Para nos certificarmos disto, vamos fazer:

1' UNION ALL SELECT 1--

Não obtivemos sucesso aqui.

1' UNION ALL SELECT 1,2--

Aqui obtivemos sucesso, pois não foi exibido erro do MySQL. Então, realmente apenas 2 colunas são acessadas pelo sistema.
Agora é bom saber que nós só acessaremos duas informações por vez, pois apenas duas informações são requisitadas pelo sistema. Se tentarmos obter mais de uma informação, teremos erros. Vamos então obter o nome de usuário logado no sistema, o nome do banco de dados atual e a versão do MySQL rodando ali. Como são duas por vez, vamos primeiramente obter o usuário e o banco de dados. E, em seguida, a primeira coluna (já que não há dados mais importantes) e a versão. Façamos os dois requests:

1' UNION ALL SELECT user(),database()--

1' UNION ALL SELECT 1,@@version--

Caso o banco de dados selecionasse 3 dados por vez (por exemplo, título, descrição e texto) poderíamos obter as 3 informações em apenas um request, fazendo user(),database(),@@version.
Agora, saibamos o seguinte: o servidor mantém um banco de dados chamado 'information_schema' com vários dados importantes, inclusive, os nomes de todas as tabelas acessíveis pelo usuário atual. Vamos listar todas as tabelas que podemos acessar:

1' UNION ALL SELECT 1,table_name FROM information_schema.tables--

E se o sistema requisitasse 3 informações por vez? Faríamos assim:

1' UNION ALL SELECT 1,2,table_name FROM information_schema.tables--

Notou o '2' ali no meio? Simplesmente requisitaríamos mais uma informação que seria inútil para nosso ataque.
Agora, note que o sistema nos retornou muitos nomes de tabela. Poderíamos fazer como o Havij, listar tabela por tabela, mas isso é perda de tempo. Procure apenas a tabela que lhe interessa, a julgar pelo nome. Pode ser algo como ''clientes'', ''login'', ''admin''... Use o bom senso, coisa que o Havij não possui. Não tente pegar a senha do PHPMyAdmin por ali, pois ela não é guardada no banco de dados, mas sim no arquivo config.inc.php.
No caso do DVWA, encontramos uma tabela chamada ''users''. Vamos verificá-la, listando suas colunas. Se não for a que queremos, apenas voltamos e tentamos com outra.

1' UNION ALL SELECT 1,column_name from information_schema.columns WHERE table_name=('users')--

Vemos aqui alguns nomes de colunas como user_id, first_name, last_name e password. Realmente há fortes indícios de que seja essa a tabela que procuramos. Vamos listar seu conteúdo. Se não for esta, voltamos e procuramos outra.
Mas, peraí! Você não falou que só podemos requisitar duas informações por vez? Sim. Mas, é para burlar isso que existe a gracinha do concat. Sua função é simples, apenas inclui mais de uma informação em apenas um dos resultados, fazendo o sistema acreditar que aquele valor trata-se realmente do valor requisitado, por estar tudo em apenas uma string. O separador que utilizaremos aqui é <=>, representado pelo hash 0x3c3d3e. Escolhi este pois é algo mais difícil de se colocar em um login, e assim é mais complicado que você se confunda. Mas isto não é nada de mais. Se quiser outro, utilize outro sem problemas, como o :, que é representado pelo hash 0x3a. Vamos pedir algumas informações:

1' UNION ALL SELECT 1,concat(user_id,0x3c3d3e,password,0x3c3d3e,user,0x3c3d3e,first_name,0x3c3d3e,last_name) from users--

Lembre-se que a ordem dos dados que você colocar no concat será a ordem retornada. Veja que obtemos vários resultados. As senhas estão criptografadas em MD5, ao que parece. Tente descriptografar com Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou até mesmo o decrypter que vem no Havij, que consulta vários sites. Missão cumprida!

Como encontrar sites vulneráveis: Você pode usar Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou o próprio Google. Utilize Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., pesquise-a no Google e, dos resultados, vá colocando aspas simples, duplas e SQL quotes na variável da URL recebida via GET. Vamos colocar e... que pena! Nas 3 tentativas ocorreu erros de colunas não encontradas? Passe para o próximo.
Vamos a este e, opa. Antes da aspa que colocamos apareceu uma barra invertida ("\"), ou sua aspa foi convertida para &quot; . Isso ocorre pelo uso de uma função como addslashes ou stripslashes.
Olhe só! Neste, conseguimos rodar aspas simples e não ocorreu a aspa. Vamos procurar o painel administrativo. Utilize Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar..., Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... ou utilize o do Havij ou seu admin panel find predileto. Não achou? Pode continuar tentando, de repente fazer um UPDATE, mas na maioria dos bancos de dados é impossível fazer um UPDATE ou DROP na mesma instrução em que faz SELECT. Por isso, se não conseguir, passe para o próximo.
Olhe esse. Não apareceu a barra ou a entitie, você achou o painel e ocorreu o erro de sintaxe. Parabéns! Mais um ponto no zone-h, atack-h e remote-injection para você.

Só lembrando que SQLi é apenas para servidores SQL. Nem tente atacar a wiki/cms/blog/fórum de contato externo do GhostMan Security (ou seja, GhostManHacks e 1NF4M3 H4CK3R GR0UP unidos), pois usamos flat-files e hospedagem gratuita, por enquanto. Espere até daqui a algum tempo. Agora, deixem eu ir tomar um *ex (sedalex, nevralgex ou qualquer coisa assim) e ir dormir pois estou com uma put* dor de cabeça, após cerca de 1 hora e meia escrevendo este texto.

Até mais!

Sugestão de enriquecimento:
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...

[inocente]

otimo boa õ/ até que fim 1 tutorial avançado

[jackads]

Arrasou irmão, que Deus possa continuar te abençoando tutorial excelente! Vou ler com mais calma depois.

[Nobody]

Muito bom, Origado 0Kal.
Gosto muito dos seus tutoriais.
Finalmente ownei um site manualmente.

[sky_hack]

Poha kra, n sei se tu copio tudo e colo, ou se entendeu o q ta escrito, só sei q tu ta ligado mano, ótimo tópico =P

[whITe_D3m0N]

muito bom 0Kal!

faltava um tutorial assim

[Belmont]

Muito obrigado, um tutorial perfeito.

[0KaL]

Lendo arquivos
Além de ler o banco de dados, o atacante ainda consegue ler arquivos no servidor. Veja um exemplo:
<code>1' UNION ALL SELECT 1,LOAD_FILE('/etc/passwd')</code>

Ataques sem o banco de dados information_schema
Alguns servidores bloqueiam acesso ao information_schema. Porém, é possível obter os dados por meio do "chute".
1' UNION ALL SELECT login,senha FROM admin--
Assim, o atacante irá tentar advinhar os nomes das colunas e da tabela, colocando por exemplo, "usuarios", "users", "administracao", "login" etc.

[f3li93darzan]

Mais uma ves você me surpriende otimo !!