Une étude de cas dans la base de vulnérabilité de sécurité

Dans cette étude de cas, Chip Andrews, un expert en sécurité SQL Server, a partagé cette expérience de (éthiquement) le piratage dans une base de données client pour découvrir des failles de sécurité. Cet exemple fournit un récit édifiant pour protéger vos informations importantes en insistant sur la sécurité de base de données sonore.

La situation

Lors d'un test de pénétration de routine, M. Andrews a effectué les recherches obligatoires Google, la recherche de nom de domaine, des empreintes digitales du système d'exploitation, et les analyses de ports, mais ce site particulier a été verrouillé serré. Passant à l'application basée sur le Web en cours d'exécution sur le système, il a été immédiatement confronté à une page de connexion en utilisant l'authentification crypté SSL formes.

En cochant la source de la page web, il a remarqué qu'une caché App_name domaine a été d'être transmis à l'application chaque fois qu'un utilisateur a tenté de se connecter au site. Serait-ce que les développeurs auraient omis de procéder à la validation d'entrée correcte sur ce paramètre à l'air innocent? La chasse était ouverte.

Le résultat

Tout d'abord, il était temps pour assembler la boîte à outils. Au moment de ce test de pénétration, M. Andrews a préféré utiliser la suivante: Paros Proxy, Absinthe, Cain Abel, voleur de données, et le Management Studio Microsoft SQL Server / SQL Server (Express Edition), qui sont tous disponibles gratuitement.

Pour commencer, il a utilisé Paros Proxy pour permettre plus de contrôle et de visibilité aux requêtes Web effectuées sur le serveur web.

Après spidering le site pour les pages disponibles et effectuer un contrôle rapide de la vulnérabilité à l'injection SQL, il a été confirmé que le App_name paramètre semble susciter l'application de lancer une exception Error 500, indiquant un échec de l'application. Les tests de pénétration sont l'une des rares occasions où une défaillance d'application est un résultat souhaitable.

Parce que l'échec de l'application a indiqué que M. Andrews pourrait injecter des caractères non désirées dans le code SQL étant envoyé par l'application à la base de données, il peut voir si elle était une condition exploitable.

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

Ensuite, M. Andrews a tenté d'utiliser l'outil de voleur de données pour attaquer la page de connexion. Cet outil tente de forcer la base de données à utiliser un OPENROWSET commande pour copier les données de la base de données cible de la base de données de M. Andrews situé sur Internet.

Cela est généralement un moyen très efficace pour siphonner de grandes quantités de données provenant 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 sur la cible avait désactivé le OPENROWSET fonctionnalité en configurant correctement l'option Désactiver Adhoc requêtes distribuées.

Avec la diligence que son mot d'ordre, M. Andrews a persisté avec l'outil suivant - Absinthe. Cet outil utilise une technique appelée injection SQL aveugle à prendre des décisions sur des données en utilisant simple oui ou non des questions de la base de données. Par exemple, l'outil peut se demander si la base de données la première lettre d'une table est inférieure à “ L. n ° 148;

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

Enfin, il était temps de tenter un dernier acte de lâcheté base de données. Tout d'abord, M. Andrews chargé l'outil appelé Cain Abel et le régler pour entrer en mode reniflant. Puis, en utilisant Paros Proxy et le paramètre vulnérable déjà identifié, il a utilisé le xp_dirtree procédure stockée étendue, qui est disponible pour les utilisateurs de base de données SQL Server, pour tenter de montrer un répertoire sur sa machine connectée à Internet en utilisant un chemin Universal Naming Convention.

Cela a forcé la base de données cible pour réellement tenter de se authentifier contre la machine de M. Andrews. Parce que Cain Abel a été à l'écoute sur le fil, il a obtenu le hachage du défi utilisé pour authentifier le partage de fichiers exposée.

En adoptant ce hachage au cracker de mot de passe intégré à Cain Abel, M. Andrews aurait le nom d'utilisateur et mot de passe du compte sous lequel le serveur SQL vulnérables courait dans juste une question de temps.

Serait-ce compte piraté utiliser le même mot de passe du compte admin de l'application web? Serait-ce mot de passe est le même que le compte d'administrateur local sur l'hôte? Ce sont des questions d'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 distance pour un autre jour.

Chip Andrews est un co-fondateur du cabinet de conseil de sécurité de sécurité Special Ops, Inc. et propriétaire de SQLSecurity.com, qui possède de multiples ressources sur la sécurité de Microsoft SQL Server, y compris l'outil de SQLPing3. Un co-auteur de plusieurs livres sur la sécurité de SQL Server et un présentateur Black Hat, M. Andrews a été la promotion de SQL Server et de la sécurité de l'application depuis 1999.