In der letzten Woche sollte ich einen Microsoft SQL Server untersuchen, um mögliche Performance-Engpässe zu identifizieren. Dazu lasse ich in der Regel mit Hilfe von Skripten bestimmte Messwerte (Drive Latency, Wait Stats, etc.) ausgeben. Um jedoch an die Messwerte zu gelangen, benötigen die meisten Skripte administrative Berechtigungen (mindestens jedoch VIEW SERVER STATE-Berechtigungen). Dieses Recht besaß jedoch der Kunde selbst nicht auf dem Zielsystem; er war jedoch lokaler Administrator auf dem Windows-Server.

Zunächst wollte ich die Analyse bereits abbrechen; habe dann aber gesehen, dass die Reporting Services ebenfalls auf dem Server installiert waren. Eigentlich wollte ich nur prüfen, ob die Reporting Services überhaupt benötigt werden. Dabei bin ich dann auf folgende – interessante – Datenquelle gestoßen, die von allen Berichten verwendet wurde.

image

Super, da wird also mit dem [sa]-Konto des Microsoft SQL Servers auf den Datenbankserver zugegriffen. Normalerweise können Standardbenutzer die Datenquellen so nicht einsehen. Wenn jedoch (und das ist ein Standard) der Webbrowser mit der Option “Als Administrator ausführen” gestartet wird, ist man ebenfalls mit administrativen Berechtigungen mit den Reporting Services verbunden!

Nachdem also klar war, dass eine Datenquelle mit dem sa-Account verwendet wird, war der Rest ein Kinderspiel:

  • Man lade einen beliebigen Bericht aus dem Reporting Services, um ihn zu modifizieren
  • Man öffne die RDL-Datei (ist XML) mit Notepad / Notepad++ (wenn keine SQL Server Data Tools zur Hand sind)
  • Ist es ein simpler Report mit einer Datenquelle, dann suche man einfach nach “DataSet” im Code
  • Hinter  “CommandText” verbirgt sich das auszuführende SQL-Statement, dessen Inhalt angepasst werden muss

image

Das obige Beispiel zeigt die Datenquelle, die eine Stored Procedure verwendet. Letztendlich möchten wir aber Mitglied der SYSADMIN-Gruppe in Microsoft SQL Server werden. Also ändern wir den CommandText wie folgt ab:

image

  • Nun wird der Bericht gespeichert und anschließend als neuer Bericht in den Reportserver hochgeladen.
  • Sobald der Bericht ausgeführt wird – logisch, dass er keine Daten anzeigt – , wird der obige Code ausgeführt und man ist sysadmin auf dem Microsoft SQL Server

Dieses – einfache – Beispiel ist natürlich nur möglich, weil die Datenquelle ein hoch privilegiertes Konto für die Ausführung der SQL-Befehle gegen den SQL Server verwendet.

Zusammenfassung

Es gibt im Internet etliche Beispiele für die Konfiguration einer Sicherheitsrichtlinie für Microsoft SQL Server. Unter anderem gilt natürlich auch, dass:

  • möglichst nur integrierte Sicherheit verwendet werden soll
  • das [sa]-Dienstkonto nicht aktiviert ist
  • der [sa] möglichst nicht Eigentümer einer Datenbank sein soll

Sich jedoch nur – und ausschließlich – auf den SQL Server zu konzentrieren, reicht nicht immer aus. Die Sensibilisierung für sicherheitsrelevante Themen geht uns alle an, da sie uns alle betrifft. Ich möchte nicht wissen, auf wie vielen Datenbanksystemen Informationen über mich gespeichert sind, die vermeintlich sicher sind! Was nützt es mir, wenn meine Daten zwar in dem technisch sichersten Tresor liegen; aber irgendein Depp den Schlüssel dazu im gleichen Raum versteckt!

Wichtiger Hinweis

Damit nicht der Verdacht aufkommt, dass wir tatsächlich so die “Sicherheit” umgangen haben! Nein, wir haben diese Technik NICHT eingesetzt sondern haben ganz normal nach den Rechten gefragt. Der Administrator hat uns dann die notwendigen Berechtigungen für die weitere Untersuchung des Systems gewährt. Wir haben aber deutlich auf das erhöhte Sicherheitsrisiko hingewiesen.

Vielen Dank fürs Lesen!