Ataque de truncamento SQL

A vulnerabilidade de truncamento SQL ocorre quando um banco de dados trunca a entrada do usuário devido a uma restrição no comprimento. Os invasores podem coletar informações sobre a duração de um campo crítico (como um nome de usuário) e explorar essas informações para obter acesso não autorizado. Os invasores podem fazer login como outro usuário, como um administrador, com sua própria senha registrada.

A vulnerabilidade de truncamento SQL geralmente existe nos bancos de dados MySQL. Essa vulnerabilidade foi descrita pela primeira vez na CVE-2008-4106, que estava relacionada ao WordPress CMS.

Como funcionam os ataques de truncamento do SQL

Este ataque funciona devido ao truncamento da entrada do usuário em bancos de dados usando as funções 'Seleção' e 'Inserção'.

• Quando a entrada é fornecida no campo do formulário, a função 'selecione' verifica a redundância correspondente a entradas no banco de dados.
• Depois de verificar a redundância, a função 'inserção' verifica o comprimento da entrada, e a entrada do usuário truncará se o comprimento exceder.

Suponha que um desenvolvedor crie a tabela "Usuários" através da seguinte consulta:

Crie usuários de tabela (
user_id int não nulo auto_incrent,
user_name varchar (20) não nulo,
senha varchar (40) não nula,
Chave primária (user_id)
);

Usando este esquema, se o desenvolvedor criar uma conta de administrador com o seguinte:

user_name = 'admin'
senha = “secret_p4ssw0ord”

Obviamente, essas credenciais não são públicas. Existe apenas uma conta de administrador no banco de dados e, se um invasor tentar registrar outra conta no nome de usuário 'Admin', o invasor falhará devido às verificações de redundância do banco de dados. O invasor ainda pode ignorar essa verificação de redundância para adicionar outra conta de administrador, explorando a vulnerabilidade do truncamento SQL. Suponha que o invasor registre outra conta na seguinte entrada:

User_name = 'adminxxxxxxxxxxxxxxxrandom'
(x são os espaços)
&
Senha = "Randomuser"

O banco de dados levará o 'user_name' (26 caracteres) e verifique se isso já existe. Em seguida, a entrada user_name será truncada e 'admin' ('admin' com espaço) será inserido no banco de dados, resultando em dois usuários de administrador duplicados.

O invasor pode então criar um usuário 'admin' com sua própria senha. Agora, o banco de dados tem duas entradas de 'user_name' do Admin, mas com senhas diferentes. O invasor pode fazer login com as credenciais recém -criadas para obter um painel de administração, porque os dois user_names "admin" e "admin" são iguais para o nível do banco de dados. Agora, veremos um amostra de ataque prático.

AMOSTRO ATAÇÃO

Neste exemplo, levaremos um cenário do site demais.org. A Comunidade de Overhewire fornece CTFs de jogo de guerra nos quais podemos praticar nossos conceitos de segurança. O cenário de truncamento SQL ocorre no nível de NATAS Nível 26-> 27. Podemos acessar o nível usando o seguinte:

URL: http: // natas27.Natas.laboratórios.demais.org
Nome de usuário: Natas27
Senha: 55tbjppzuujgvp5b3bnbg6on9udpvzcj

Este nível está disponível em: https: // Overthewire.Org/Wargames/Natas/Natas27.html. Você será mostrado uma página de login vulnerável a um ataque de truncamento SQL.

Ao inspecionar o código -fonte, você verá que o comprimento do nome de usuário é 64, como mostrado abaixo.

Um usuário chamado 'natas28' já existe. Nosso objetivo é criar outro usuário chamado 'natas28' usando o ataque sql_truncation. Portanto, inseriremos o Natas28, seguido por 57 espaços e um alfabeto aleatório (no nosso caso, a), nome de usuário e qualquer senha. A letra 'A' não é visível na captura de tela por causa do nome de usuário do comprimento de 65 caracteres. Após a criação da conta de usuário, você poderá ver o 'a.'

Se o banco de dados contiver vulnerabilidade SQL_TRUNCATION, o banco de dados agora deve ter dois nomes de usuário 'natas28'. Um nome de usuário conterá nossa senha. Vamos tentar inserir as credenciais na página de login.

Agora, estamos conectados como o usuário 'natas28'.

Mitigação

Para mitigar este ataque, precisaremos considerar vários fatores.

• Não devemos permitir a duplicação de identidades críticas como o nome de usuário. Devemos fazer essas chaves primárias dessas identidades.
• A função truncada deve ser implementada para todos os campos de formulários de front -end, bem como código de back -end, para que os bancos de dados recebam entradas truncadas.
• O modo rigoroso deve ser ativado no nível do banco de dados. Sem o modo rigoroso ativado, os bancos de dados apenas dão avisos no back -end, mas ainda salvam os dados duplicados. Com o modo rigoroso, os bancos de dados dão erros em caso de duplicação e evitam a economia de dados.

Por exemplo, vamos verificar o modo rigoroso usando a seguinte consulta:

mysql> selecione @@ sql_mode

Vamos criar um banco de dados e os usuários da tabela '.'

MySQL> Criar teste de banco de dados
Consulta ok, 1 linha afetada (0.02 Sec)
MySQL> Usar teste
Banco de dados alterado
MySQL> Criar usuários da tabela (nome de usuário varchar (10), senha varchar (10));
Consulta ok, 0 linhas afetadas (0.05 seg)

Em seguida, criaremos um usuário administrador com credenciais usando a consulta de inserção.

mysql> inserir nos valores dos usuários ('admin', 'senha1');
Consulta ok, 1 linha afetada (0.01 seg)

Podemos ver as informações da tabela 'Usuários' usando a opção 'Selecionar * do Usuários'.

O comprimento do nome de usuário é de 10 caracteres. Agora, tentaremos o ataque de truncamento SQL.

Quando tentamos inserir o seguinte:

Nome de usuário = 'adminxxxxxa'
(x são os espaços)
&
Senha = 'pass2'

Teremos um erro, o que significa que o modo rigoroso é totalmente eficaz.

mysql> inserir nos valores dos usuários ('admin a', 'pass2')
Erro 1406 (22001): dados muito longos para a coluna 'Nome de usuário' na linha 1

Sem o modo rigoroso ativado, o banco de dados produzirá avisos, mas ainda inserirá os dados na tabela.

Conclusão

Os invasores podem obter acesso a contas de alto privilégio se a vulnerabilidade SQL_TRUNCT existir em seu aplicativo. O invasor pode facilmente obter informações sobre um nome de usuário e seu comprimento de banco de dados usando os campos críticos e criar o mesmo nome de usuário, seguido de espaços e alfabetismo aleatório após o comprimento mínimo, resultando na criação de múltiplas contas de alto privilégio. Essa vulnerabilidade é crítica, mas pode ser evitada se você tomar algumas precauções de segurança, como ativar o modo rigoroso para entradas do usuário e tornar o campo sensível a chave primária no banco de dados.