Une étude de cas sur la vulnérabilité de sécurité de base de données - nuls

Dans cette étude de cas, Chip Andrews, expert en sécurité SQL Server, a partagé cette expérience de piratage (éthique) avec un client. base de données pour découvrir les failles de sécurité. Cet exemple fournit une mise en garde pour protéger vos informations importantes en insistant sur la sécurité de la base de données sonore.

La situation

Lors d'un test de pénétration de routine, M. Andrews a effectué les recherches obligatoires de Google, la recherche de nom de domaine, les empreintes digitales du système d'exploitation et les analyses de port. Passant à l'application Web fonctionnant sur le système, il a immédiatement été confronté à une page de connexion utilisant l'authentification par formulaires cryptés SSL.

En vérifiant la source de la page Web, il a remarqué qu'un champ App_Name caché était transmis à l'application chaque fois qu'un utilisateur tentait de se connecter au site. Se pourrait-il que les développeurs aient échoué à effectuer une validation d'entrée correcte sur ce paramètre à l'apparence innocente? La chasse était allumée.

Le résultat

En premier lieu, il était temps d'assembler la boîte à outils. Au moment de ce test de pénétration, M. Andrews a préféré utiliser: Paros Proxy, Absinthe, Cain et Abel, Data Thief, et Microsoft SQL Server Management Studio / SQL Server (Édition Express), qui sont tous disponibles gratuitement.

Pour commencer, il a utilisé Paros Proxy pour permettre plus de contrôle et de visibilité sur les requêtes web faites au serveur web.

Après avoir recherché les pages disponibles sur le site et effectué une vérification rapide des vulnérabilités de l'injection SQL, il a été confirmé que le paramètre App_Name semblait provoquer une exception Erreur 500 sur l'application, indiquant un échec de l'application. Les tests de pénétration sont l'une des rares occasions où un échec d'application est un résultat souhaitable.

Comme l'échec de l'application indiquait que M. Andrews pouvait injecter des caractères non intentionnels dans le code SQL envoyé de l'application à la base de données, il pouvait voir s'il s'agissait d'une condition exploitable.

Un test courant qui fonctionne avec les bases de données Microsoft SQL Server consiste à injecter une commande, telle que WAITFOR DELAY '00: 00: 10 ', ce qui provoque le blocage du serveur de base de données pendant 10 secondes. Dans une application qui renvoie normalement une page en une seconde ou moins, un délai cohérent de 10 secondes est un bon indicateur que vous pouvez injecter des commandes dans le flux SQL.

Ensuite, M. Andrews a tenté d'utiliser l'outil Data Thief pour attaquer la page de connexion.Cet outil tente de forcer la base de données à utiliser une commande OPENROWSET pour copier des données de la base de données cible vers la base de données de M. Andrews située sur Internet.

C'est généralement un moyen très efficace de siphonner de grandes quantités de données à partir de bases de données vulnérables, mais dans ce cas, son attaque a été déjouée! L'administrateur de base de données de la cible avait désactivé la fonctionnalité OPENROWSET en configurant correctement l'option Désactiver les requêtes distribuées Adhoc.

Avec la diligence de son mot d'ordre, M. Andrews a persisté avec l'outil suivant: Absinthe. Cet outil utilise une technique appelée injection SQL aveugle pour effectuer des déterminations de données à l'aide de simples questions oui ou non de la base de données. Par exemple, l'outil peut demander à la base de données si la première lettre d'une table est inférieure à "L. "

Si oui, l'application pourrait ne rien faire, mais si non, l'application pourrait lancer une exception. En utilisant cette simple logique binaire, il est possible d'utiliser cette technique pour révéler toute la structure de la base de données et même les données stockées à l'intérieur - bien que très lentement. En utilisant l'outil, il a identifié une table d'informations sensibles sur les clients et a téléchargé plusieurs centaines d'enregistrements pour montrer le client.

Enfin, il était temps d'essayer un dernier acte de lamentation de la base de données. D'abord, M. Andrews a chargé l'outil appelé Cain & Abel et l'a mis en mode de reniflement. Puis, à l'aide de Paros Proxy et du paramètre vulnérable déjà identifié, il a utilisé la procédure stockée étendue xp_dirtree, qui est disponible pour les utilisateurs de base de données SQL Server, pour tenter d'afficher un répertoire sur sa machine connectée à Internet.

Cela a forcé la base de données cible à tenter de s'authentifier contre la machine de M. Andrews. Parce que Cain & Abel écoutait sur le fil, il a obtenu le hachage du défi utilisé pour authentifier le partage de fichiers exposés.

En transmettant ce hachage au pirate de mot de passe intégré à Cain & Abel, M. Andrews aurait le nom d'utilisateur et le mot de passe du compte sous lequel SQL Server vulnérable était en cours d'exécution juste un peu de temps.

Ce compte piraté utiliserait-il le même mot de passe que le compte administrateur de l'application Web? Ce mot de passe serait-il le même que le compte d'administrateur local sur l'hôte? Ce sont des questions pour un autre jour. Il était temps de rassembler toutes les données recueillies, de préparer un rapport pour le client et de mettre les outils de côté pour un autre jour.

Chip Andrews est co-fondateur de la société de conseil en sécurité Special Ops Security, Inc. et propriétaire de SQLSecurity. com, qui dispose de plusieurs ressources sur la sécurité de Microsoft SQL Server, y compris l'outil SQLPing3. Un co-auteur de plusieurs livres sur la sécurité de SQL Server et un présentateur de Black Hat, M. Andrews fait la promotion de SQL Server et de la sécurité des applications depuis 1999.