SQL Injection
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
RootedCON é 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.
Uma injeção SQL é uma falha de segurança que permite que atacantes interfiram nas consultas de banco de dados de uma aplicação. Essa vulnerabilidade pode permitir que atacantes visualizem, modifiquem ou deletam dados que não deveriam acessar, incluindo informações de outros usuários ou qualquer dado que a aplicação possa acessar. Tais ações podem resultar em mudanças permanentes na funcionalidade ou conteúdo da aplicação ou até mesmo comprometimento do servidor ou negação de serviço.
Quando um site parece ser vulnerável a injeção SQL (SQLi) devido a respostas incomuns do servidor a entradas relacionadas a 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. Estes são alguns exemplos úteis:
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 você pode apenas inserir seus dados e adicionar um símbolo de comentário no final.
Observe que se você puder ver mensagens de erro ou notar 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 SQL injection envolve executar 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' ou '1'='1 indica uma vulnerabilidade de SQL injection.
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 produzir os mesmos resultados, isso é indicativo de SQL injection.
Exemplos demonstrando a confirmação de operação lógica:
Esta lista de palavras foi criada para tentar confirmar SQLinjections da maneira proposta:
Em alguns casos, você não notará nenhuma mudança na página que está testando. Portanto, uma boa maneira de descobrir SQL injections blindas é fazer com que o DB execute ações que terão um impacto no tempo que a página leva para carregar. Portanto, vamos concatenar na consulta SQL uma operação que levará muito tempo para ser concluída:
Em alguns casos, as funções sleep não serão permitidas. Então, em vez de usar essas funções, você poderia 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ê poderia usar as funções sleep da seção anterior ou estas (tabela do payloadsallthethings:
Também, se você tiver acesso à saída da consulta, poderá fazer com que imprima a versão do banco de dados.
A continuação, vamos discutir diferentes métodos para explorar diferentes tipos de SQL Injection. Usaremos MySQL como exemplo.
Se você puder ver a saída da consulta, esta é a melhor maneira de explorá-la. Primeiro de tudo, precisamos descobrir o número de colunas que a requisiçã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 esse 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é que uma resposta falsa seja recebida. 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.
Selecione mais e mais valores nulos até que a consulta esteja correta:
Você deve 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.
Nos próximos exemplos, vamos recuperar o nome de todos os bancos de dados, o nome da tabela de um banco de dados, os nomes das colunas da tabela:
Existe uma maneira diferente de descobrir esses dados em cada banco de dados diferente, mas a metodologia é sempre a mesma.
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, é necessário discernir a consulta de execução no backend.
Isso pode ser realizado através 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) alvo. Para entender essas tabelas padrão, é aconselhável consultar a documentação do DBMS alvo.
Uma vez que a consulta tenha sido extraída, é necessário adaptar seu payload para fechar com segurança a consulta original. Em seguida, uma consulta de união é anexada ao seu payload, 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.
Se por algum motivo você não pode ver a saída da consulta, mas pode ver as mensagens de erro, você pode fazer com que essas mensagens de erro exfiltratem dados do banco de dados. Seguindo um fluxo semelhante ao da exploração baseada em União, você poderia conseguir despejar o DB.
Neste caso, você não pode ver os resultados da consulta ou os erros, mas pode distinguir quando a consulta retorna uma resposta verdadeira ou falsa porque há conteúdos diferentes na página. Neste caso, você pode abusar desse comportamento para despejar o banco de dados caractere por caractere:
Este é o mesmo caso de antes, mas em vez de distinguir entre uma resposta verdadeira/falsa da consulta, você pode distinguir entre um erro na consulta SQL ou não (talvez porque o servidor HTTP falhe). Portanto, neste caso, você pode forçar um erro SQL toda vez que adivinhar corretamente o caractere:
Neste caso, não há nenhuma maneira de distinguir a resposta da consulta com base no contexto da página. Mas, você pode fazer a página demorar mais para carregar se o caractere adivinhado estiver correto. Já vimos essa técnica em uso anteriormente para confirmar uma vulnerabilidade de SQLi.
Você pode usar consultas empilhadas para executar várias consultas em sucessão. Note que, enquanto as consultas subsequentes são executadas, os resultados não são retornados para a aplicação. Portanto, essa técnica é principalmente útil em relação a vulnerabilidades blindas onde você pode usar uma segunda consulta para acionar uma consulta DNS, erro condicional ou atraso de tempo.
Oracle não suporta consultas empilhadas. MySQL, Microsoft e PostgreSQL as suportam: QUERY-1-HERE; QUERY-2-HERE
Se nenhum outro método de exploração funcionou, você pode tentar fazer com que o banco de dados exfiltre as informações para um host externo controlado por você. Por exemplo, via consultas DNS:
Verifique o SQLMap Cheatsheet para explorar uma vulnerabilidade de SQLi com sqlmap.
Já discutimos todas as maneiras de explorar uma vulnerabilidade de Injeção de SQL. Encontre mais algumas dicas dependentes da tecnologia de banco de dados neste livro:
Ou você encontrará muitas dicas sobre: MySQL, PostgreSQL, Oracle, MSSQL, SQLite e HQL em https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection
RootedCON é 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.
Lista para tentar contornar a funcionalidade de login:
Esta consulta demonstra uma vulnerabilidade quando o MD5 é usado com verdadeiro para saída bruta em verificações de autenticação, tornando o sistema suscetível a SQL injection. Os atacantes podem explorar isso criando entradas que, quando hashadas, produzem partes inesperadas de comandos SQL, levando ao acesso não autorizado.
Lista recomendada:
Você deve usar como nome de usuário cada linha da lista e como senha sempre: Pass1234. &#xNAN;(Esses payloads também estão incluídos na grande lista mencionada no início desta seção)
SE ' estiver sendo escapado, você pode usar %A8%27, e quando ' for escapado, será criado: 0xA80x5c0x27 (╘')
Para isso, você deve tentar criar um novo objeto nomeado como o "objeto mestre" (provavelmente admin no caso de usuários) modificando algo:
Criar usuário nomeado: AdMIn (letras maiúsculas e minúsculas)
Criar um usuário nomeado: admin=
SQL Truncation Attack (quando há algum tipo de limite de comprimento no nome de usuário ou e-mail) --> Criar usuário com 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ê quiser 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 introduzido existe dentro do banco de dados. Se não, ele irá cortar o nome de usuário para o número máximo permitido de caracteres (neste caso para: "admin [25 espaços]") e então irá remover automaticamente todos os espaços no final atualizando dentro do 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://resources.infosecinstitute.com/sql-truncation-attack/#gref
Note: Este ataque não funcionará mais como 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 do que o comprimento de um campo resultará em um erro, e a inserção falhará. Para mais informações sobre essa verificação: https://heinosass.gitbook.io/leet-sheet/web-app-hacking/exploitation/interesting-outdated-attacks/sql-truncation
Adicione quantos ','','' você considerar para sair da declaração VALUES. Se o atraso for executado, você tem uma SQLInjection.
A cláusula ON DUPLICATE KEY UPDATE no MySQL é utilizada para especificar ações que o banco de dados deve tomar quando uma tentativa é feita para inserir uma linha que resultaria em um valor duplicado em um índice UNIQUE ou PRIMARY KEY. O seguinte exemplo demonstra como esse recurso pode ser explorado para modificar a senha de uma conta de administrador:
Exemplo de Injeção de Payload:
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 é uma isca, e a segunda linha visa o e-mail de um administrador existente com a intenção de atualizar a senha:
Aqui está como funciona:
A consulta tenta inserir duas linhas: uma para generic_user@example.com e outra para admin_generic@example.com.
Se a linha para admin_generic@example.com já existir, a cláusula ON DUPLICATE KEY UPDATE é acionada, instruindo o MySQL a atualizar o campo password da linha existente para "bcrypt_hash_of_newpassword".
Consequentemente, a autenticação pode ser tentada usando admin_generic@example.com com a senha correspondente ao hash bcrypt ("bcrypt_hash_of_newpassword" representa o hash bcrypt da nova senha, que deve ser substituído pelo hash real da senha desejada).
Ao tentar criar um novo usuário, nome de usuário, senha e e-mail são necessários:
Com esta técnica, você pode extrair informações criando apenas 1 conta. É importante notar que você não precisa comentar nada.
Usando hex2dec e substr:
Para obter o texto, você pode usar:
Usando hex e replace (e substr):
RootedCON é 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 fervente para profissionais de tecnologia e cibersegurança em todas as disciplinas.
A injeção SQL roteada é uma situação em que a consulta injetável não é a que gera a saída, mas a saída da consulta injetável vai para a consulta que gera a saída. (Do Paper)
Exemplo:
Sem Espaço (%20) - bypass usando alternativas de espaço em branco
No Whitespace - contornar usando comentários
No Whitespace - contornar usando parênteses
No Comma - bypass usando OFFSET, FROM e JOIN
Lista negra usando palavras-chave - bypass usando maiúsculas/minúsculas
Blacklist usando palavras-chave sem diferenciação entre maiúsculas e minúsculas - contornar usando um operador equivalente
Você pode encontrar uma explicação mais detalhada desse truque no blog da gosecure. Basicamente, você pode usar a notação científica de maneiras inesperadas para contornar o WAF:
Primeiramente, note 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 sqlinjection isso pareceria assim:
Ou usando um bypass de vírgula:
Este truque foi retirado de https://secgroup.github.io/2017/01/03/33c3ctf-writeup-shia/
RootedCON é 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.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
