SQL Server & BI Blog by Andreas Wolter

(de)
In dieser Umfrage möchte ich einmal in einem größeren Kreis ermitteln, welche Accounts typischerweise als Datenbankbesitzer eingetragen werden. Die kumulierten Ergebnisse werde ich anschließend hier veröffentlichen um sie mit der Community zu teilen, zusammen mit einigen Empfehlungen hinsichtlich Sicherheits-Härtung.

Dabei interessieren vor allem bestimmte serverweite Berechtigungen nicht nur des verwendeten Logins selber, sondern auch, falls er Mitglied einer (custom) Server Role ist, bestimmte, kritische Rechte dieser Rolle.

Wer meine Vorträge zum Thema „Sicherheit in SQL Server“ in den letzten Jahren, und insbesondere der im Sommer 2013 gestarteten Reihe „SQL Server Attacked“ verfolgt hat, wird sich vielleicht hat erinnern, wie ich dort auch gezeigt habe, wie man aus einer Datenbank ausbrechen und volle Systemrechte erlangen kann („Privilegien Erweiterung“) – basierend auf einer Kombination von Datenbankbesitzer, -Konfiguration und Impersonierung.

Hier stelle ich nun einen T-SQL Script zur Verfügung, welcher

• Den jeweiligen Datenbankbesitzer aller Datenbanken ermittelt
• Ungültige/Fehlende Datenbankbesitzer erkennt
• Anzeigt, ob der Besitzer direkt über sicherheitskritische systemweite Rechte verfügt
• Mitgliedschaft in hochprivilegierten Server-Rollen anzeigt – inklusive der benutzerdefinierten Serverrollen (ab SQL 2012 möglich)
• Die kritischen Datenbankeinstellungen „Vertrauenswürdig“ und „Datenbankverkettung“ anzeigt.

Und hier ist der Script:

(en)
In this survey, I would like to explore in a greater radius which accounts are typically used as database owners. I will subsequently publish the cumulated results here to share them with the community together with some recommendations for hardening security.

In this instance, particular server-wide permissions both of the used account as well as, in case of membership of a (custom) Server Role, critical permissions of that role, are of interest.

Those who have followed my presentations on the topic “Security in SQL Server” in the last years, and especially the „SQL Server Attacked“ series launched in the summer of 2013, may remember how I had also demonstrated there how to break out of a database and be granted full system rights (“Elevation of privileges”), - based on a combination of database owner, configuration and impersonation.

Here, I am providing a T-SQL Script which

• Identifies the respective database owners of all databases
• Detects invalid/missing database owners
• Indicates whether the owner directly possesses security-critical system-wide rights
• Indicates membership in high privilege Server Roles – including the user defined Server Roles (possible since SQL 2012)
• Indicates the critical database configurations “trustworthy” and “database chaining”.

Here you can find the script:

- Er sollte auf allen SQL Servern ab der Version 2005 funktionieren (getestet 2008-2014).

Zum Zwecke der Umfrage bitte ich Euch, die anonymisierten Ergebnisse (am Besten in Excel-Format) an die Email survey@SarpedonQualityLab.com zu senden, oder auch hier in den Kommentaren zu posten.
Zum Zwecke der Anonymisierung kann man einfach die letzten 3 Spalten aus dem Resultset auslassen – diese haben für eine statistische Erhebung auch keinen Nutzen sondern sind nur für Eure internen Zwecke bestimmt :-).

Hier seht ihr ein Beispiel-Ergebnis:

-           It should be working on all SQL Servers since the 2005 version (tested: 2008-2014).

For the purpose of the survey, I would like to ask you to send the anonymized results (preferably in excel-format) to the email survey@SarpedonQualityLab.com, or as well post them here in the comments.

For anonymization purposes, you can simply leave out the last three columns from the result set – these are not of use to a data collection and only meant for your internal usage :-).

Here, you can see a sample result:

Mehrere Einträge für dieselbe Datenbank entstehen, wenn der Datenbankbesitzer – oder seine Serverrolle(!) über mehrere, der von mir als sicherheitskritisch klassifizierten Rechte verfügt. Diese stehen dann in der Spalte login_permission bzw. role_permission. Hinter den Kürzeln verbergen sich:
ALLG = ALTER ANY LOGIN
ALSR = ALTER ANY SERVER ROLE
CL  = CONTROL SERVER
XA  = EXTERNAL ACCESS ASSEMBLY
(mehr dazu auch hier: CONTROL SERVER vs. sysadmin/sa: permissions, system procedures, DBCC, automatic schema creation and privilege escalation - caveats).

Die Inhalte der Spalten DatabaseNo, database_owner und external_owner sind absichtlich allgemein gehalten – die exakten Namen sind wie gesagt in den letzten 3 Spalten zu finden.

Die Spalte db_owner_valid zeigt an, ob die Datenbank einen gültigen Besitzer hat. In diesem Fall besteht ein match zwischen dem „externen Besitzer“ und dem in der Datenbank selber hinterlegten. In der Spalte external_owner steht nur ob dieser „externe Besitzer“ sa ist oder nicht – der genaue Login steht dann in *External_Owner.Der Script speichert keine Daten dauerhaft im System ab und beseitigt seine temporären Zwischenergebnisse selbst.

Ich hoffe, ihr findet die Auswertung hilfreich – und ich hoffe, ihr könnt die (anonymisierten) Ergebnisse mit der Community teilen. Ich werde keine Email speichern oder verwenden, sondern nur die anonymisierten Abfrageergebnisse.

Ich bedanke mich für eure Teilnahme und Unterstützung der Community!
Ich verspreche, die kumulierten Ergebnisse in den nächsten Monaten zusammen mit entsprechenden Hinweisen auf Best & Bad Practices sowie auf möglichen Einfallstoren für Privilegienerweiterungs-Angriffen zu veröffentlichen.

Multiple entries for the same database occur when the database owner – or his serverrole(!) possess multiple of the permissions which I classified as security-wise critical. These are listed in the column login_permission respectively role_permission. The codes stand for:
ALLG = ALTER ANY LOGIN
ALSR = ALTER ANY SERVER ROLE
CL  = CONTROL SERVER
XA  = EXTERNAL ACCESS ASSEMBLY
(you can read more on that here: CONTROL SERVER vs. sysadmin/sa: permissions, system procedures, DBCC, automatic schema creation and privilege escalation - caveats).

The contents of the columns DatabaseNo, database_owner and external_owner are left general on purpose – the exact names can be found in the last 3 columns s mentioned above.

The column db_owner_valid indicates, whether the database has a valid owner. In this case there is a match between the „external owner“ and the one stored within the database itself. The column external_owner only shows whether that „external owner“ is sa or not –the exact Login is shown in *External_Owner.

The script does not permanently save any data in the system and removes its temporary intermediary results by itself.

I hope you find the report useful and I hope you can share the (anonymized) results with the community.
I will not store or use any email but only use the anonymized Query-results.

 Thank you in advance for your participation and support of the community!
I promise to publish the cumulated results with according details on best & bad practices as well as on to possible gateways to elevation of privilege attacks in the next months.

(de)
Im Anschluss an die Vorträge aus meiner „Hacking SQL Server“-Reihe „SQL Server Sicherheit „SQL Attack..ed“ – Angriffszenarien auf SQL Server („SQL Server Hacken“)“, die ich bisher bereits auf den SQLSaturdays Rheinland, Istanbul, auf der SQLRally Amsterdam und in vielen Regionalgruppen der PASS Deutschland zeigte, kommt öfters die Frage auf, ob ich den gezeigten Code öffentlich verfügbar mache. Da Twitter sich als Diskussionsmedium nicht so eignet (schöne Grüße an @DirkHondong und @FrankGeisler ;-) ), das Thema aber doch etwas mehr Beachtung verdient, möchte ich darauf in einigen Sätzen eingehen.

(en)
Subsequent to the lectures from my “Hacking SQL Server” series “Security Session „SQL Attack..ed“ – Attack scenarios on SQL Server ("Hacking SQL Server")” which I have already given at the SQLSaturdays Rheinland, Istanbul, at the SQLRAlly Amsterdam and at many regional groups of PASS Germany, more often than not the question arises whether I make the presented code available to the public. With Twitter not being that suitable a medium of discussion (greetings to @DirkHondong and @FrankGeisler ;-)), yet the topic deserving some more attention, I will get into the matter in the following.

Der Hintergrund, das ich die dafür entwickelten Scripts nicht veröffentliche, ist eigentlich recht einfach: ich zeige darin unter anderem Angriffsvarianten und Techniken, die so noch nicht dokumentiert oder in der „Szene“ bekannt sind(?).

Und da ich die frei verfügbaren SQL-Injection- und allgemein „Hacking“/DoS -Tools ein wenig kenne, möchte ich vermeiden, denjenigen, die diese entwickeln, neue Ideen zu geben um Server in die Knie zu zwingen. Das bringt keinem (aus der SQL Server Community) etwas (- höchstens "Auftragshackern", aber "leider" habe ich da keine Aktien drinnen ;-) ).

-           Die meisten SQL-Injection-Varianten sind übrigens auch wirklich gut im Netz dokumentiert, und eine einfache Suche wird eine Vielfalt an Code-Beispielen zutage bringen. Es macht kaum einen Unterschied, welche Vorlage man verwendet, man muss so und so noch Anpassungen vornehmen. ;-)

Im Gegensatz zu landläufiger Meinung, glaube ich nicht daran, dass jeder alle „Hacking“-Techniken selber durchführen können muss. Ich denke das ist häufig ein Vorwand, sicherheitsbedenkliche Aktionen pauschal zu rechtfertigen.

Ich bin der Ansicht, dass es genügt, zu wissen/gesehen zu haben, wo man angreifbar sein kann, und das es wichtiger ist, die Zeit darauf zu verwenden, die Skills für die Sicherung zu entwickeln.

Um selber zu „Hacken“, ist das übrigens eine gute Voraussetzung (und der Unterschied zum sogenannten „Script-Kiddie“). Nur das man dann einfach noch mehr Kenntnisse benötigt.

In aller Regel sehe ich jedoch eher einen Mangel an Kenntnissen über die Zusammenhänge in der Sicherheitsarchitektur von SQL Server, auf den ich mich naturgemäß fokussiere, sowie natürlich dem darunterliegenden Windows-Server und der Domain-Architektur allgemein.
„Hacken“ zu können bringt für sich gesehen erst einmal gar nichts. Das kann man, wenn man alles bekannte abgesichert hat immer noch angehen. Wenn das nötig ist, befindet man sich in dem grauen Bereich von „Penetration Testing“.

The background to why I don’t make public the scripts developed for this purpose is actually quite simple: in the scripts, I am showing attack variants and techniques, among others, which have not been documented or are not known within the “scene” (?).

And since I am a little familiar with the discretionary SQL injection and “Hacking”/DoS tools in general I would like to avoid giving those parties developing these tools new ideas for bringing servers down. This wouldn’t be of use to anyone (from the SQL Server community) (- except maybe to “contract hackers,” but I’m “afraid” I don’t hold any stocks in there ;-)).

-           By the way, most of the SQL injection variants are very well documented in the internet, and a simple search will spill out a variety of code examples. It will hardly make a difference which template one is using, as one will need to make adaptions anyway. ;-)

In contrast to general opinion, I do not believe that everyone needs to be able to carry out all “hacking” techniques by themselves. I think this is often used as a blanket pretext for justifying security-wise questionable actions.

I am of the opinion that it is sufficient to know/have seen where one can be vulnerable, and that it is more important to invest the time into developing skills for protection.

And this is a good prerequisite for “hacking” oneself (and the difference to the so-called “script kiddie”). Only that even more knowledge will be required then. 

In principle, however, I am rather observing a lack of knowledge of the correlations in the security architecture of SQL Server on which I am by nature focusing, as well as, of course, the Windows Server beneath it and the domain architecture in general.

To be able to “hack” alone is of no avail. Once one has covered everything known, one can still get to that. If this is necessary, one will end up in the grey area of “penetration testing.”

Das eigentliche Ziel meiner Vorträge/“Shows“(?) ist die "Awareness/Wahrnehmung", und Verbesserung der Sensibilität für das Thema Sicherheit im Sinne von:

„Habe ich das alles schon einmal bedacht?“

„Könnte ich doch noch Lücken haben und ein leichtes Angriffsziel sein, ohne es bislang gemerkt zu haben?“

Nicht:

"Um meine SQL Server Umgebung sicherer zu machen, möchte ich mich selber im „Hacken“ versuchen."

Ich hoffe das macht Sinn für Euch :-)

In jedem Fall ist eine offene Diskussion zu diesem Thema durchaus in meinem Sinne.

The actual goal of my lectures/ “shows” (?) is the “awareness/perception,” and the enhancement of sensitivity for the topic of security in the sense of:

“Have I taken all this into consideration?”

“Could I still have gaps and be an easy target without having noticed up to now?”

Not:

“In order to make my SQL Server environment more secure I would like to dabble in ‘hacking.’”

I hope this makes sense to you J

PS: Aus diesem Grunde biete ich ja schon seit einigen Jahren immer wieder den Security Essential für die PASS Deutschland an – aber wie wir wissen, zieht das Thema „Sichern“ einfach weniger als „Hacken“ ;-)

Und für diejenigen, die die Grundlagen schon beherrschen, aber komplexere Anforderungen oder kritischere Umgebungen haben, kommen dann die Master-Classes zum Thema Sicherheit: www.sarpedonqualitylab.com/SQL_Master-Classes.htm

PS: For those who already know the basics, but have more complex requirements or critical environments, there are the Master-Classes on Security: en.sarpedonqualitylab.com/SQL_Master-Classes.htm

(de)
Zur Erinnerung: Extended Events sind seit SQL Server 2008 in SQL Server integriert. Und seit SQL Server 2012 SP1 sind alle Events verfügbar, die es in SQL Trace gibt. Zudem sind Extended Events seit SQL Server 2012 auch für Analysis Services verfügbar (Tracing Analysis Services (SSAS) with Extended Events – Yes it works and this is how).

Für alle, die noch mit dem alten Werkzeug SQL Server Profiler (Profiler ist das Frontend für SQL Trace, gestartet mit sp_trace_create) arbeiten, und sich noch nicht für die neue Technologie entscheiden konnten, hier eine kleine Entscheidungshilfe.

Was Extended Events (XEvents) besser als SQLTrace machen:

(en)
As a reminder: Extended Events have been integrated in SQL Server since SQL Server 2008. And since SQL Server 2012 SP1, all events existing in SQL Trace have been available. In addition, Extended Events have also been available for Analysis Services since SQL Server 2012 Tracing Analysis Services (SSAS) with Extended Events – Yes it works and this is how).

For those of you who are still working with the old tool SQL Server Profiler (Profiler is the frontend for SQL Trace, started with sp_trace_create) and have not quite been able to decide for the new technology, here is some decision guidance.

What Extended Events (XEvents) do better than SQL Trace:

1. Einzige Möglichkeit neue Features wie FileStream, FileTable, AlwaysOn, ColumnStore, Hekaton/XTP etc. zu Tracen
2. Viel mehr Events tracebar, auch bereits für ältere Releases (siehe *1, *2 unten)
3. Deutlich geringerer Beobachter-Overhead
   siehe auch: Performance overhead of tracing with Extended Event targets vs SQL Trace under CPU Load
4. Performance/Last lässt sich konfigurieren & tunen
5. Events und Filter lassen sich live anpassen – während aktiver Session also
6. Ofiziell 2 µs/Event gg. 4ms/Event in SQLTrace
7. Event-Verlust konfigurierbar
8. Effiziente Filterung durch Architektur
9. Komplexe Prädikate wie z.B. Zähler oder last_error, less_than_min_datatype oder greater_than_max_datatype
10. Korrelation von Events möglich
11. Möglichkeit Events vom Client bis in die Datenbank zu verfolgen
12. Einfache Automatisierung
13. Direkt in Management Studio integriert
14. Viele Analysen direkt in der GUI möglich (Um diese noch zu verbessern, bitte hier bei Microsoft Connect voten: Extended Events UI Export Display Settings: include grouping)
15. Query_hash zum Identifizieren von identischen Abfragen verfügbar
16. Keine 10 Klicks zum Aufsetzen einer simplen Session inkl. Filter
17. Unterschiedliche Speicher-Ziele für EventDaten zur Auswahl (6)
18. „Ergebnisorientierte“ Ziele wie Counter und Histogramm
19. Multiple Ziele lassen sich für “On the fly - Top-Down Analysen” kombinieren
20. Möglichkeiten für ganz neue Einblicke in Interna der Datenbank-Engine (Latching, Spinlocks, Multi-victim-Deadlock, Wait_Infos per session/query, Caching-Vorgänge, Ghost-cleanup, Analyse von Page Splits, Page-Compression Vorgänge, um nur einige zu nennen)
21. Stack Tracen eines einzelnen Prozesses möglich – anstelle eines vollständigen Server Dumps
22. Definition mit Standard DDL-Statements
23. API zur Integration in eigene Tools verfügbar
24. PowerShell-Unterstützung
25. Last but not least: Endlich ein Grund, XML & XQuery zu lernen? ;-)

1. The only possibility of Tracing new features like FileStream, FileTable, AlwaysOn, ColumnStore, Hekaton/XTP etc.
2. Many more Events traceable, even for older releases (see *1, *2 below)
3. Significantly less Observer-Overhead, also see: Performance overhead of tracing with Extended Event targets vs SQL Trace under CPU Load
4. Performance/Overhead can be configured and tuned
5. Events and Filters can be adapted live – meaning during active session
6. Official 2 µs/Event vs. 4ms/Event in SQLTrace
7. Event-loss is configurable
8. Efficient filtering through architecture
9. Complex predicates such as Counter or last_error, less_than_min_datatype oder greater_than_max_datatype
10. Correlation of Events possible
11. Possibility of following Events from Client into the Database
12. Easy Automation
13. Directly integrated in Management Studio
14. Many analysis directly inside the GUI possible (in order to improve them, please vote at Microsoft Connect: Extended Events UI Export Display Settings: include grouping)
15. Query_hash for identification of identical queries available
16. No 10 clicks to set up a simple session including filter
17. Choice of different destinations for storing EventData (6)
18. “Goal-oriented” destinations such as Counter and Histogram
19. Multiple destinations can be combined for “On the fly – top-down analyses”
20. Possibilities for entirely new insights into internal matters of database engine (Latching, Spinlocks, Multi-victim-Deadlock, Wait_Infos per session/query, Caching-processes, Ghost-cleanup, analysis of Page Splits, Page-Compression processes, to name just a few)
21. Stack Tracing of a single process possible – instead of a complete Server Dump
22. Definition with standard DDL-Statements
23. API for integration into one’s own tools available
24. PowerShell support
25. Last but not least: Finally a good reason to learn XML & XQuery? ;-)

Ich hoffe, das hilft dem einen oder anderen, die alte Gewohnheit abzulegen, und die kleine Lernphase in Kauf zu nehmen.

Eine Liste aller Extended Events in SQL Server 2012 SP1 samt Ihrem Gegenstück in SQL Trace, welche man für Migrationszwecke (SQLTrace -> XEvent Trace) verwenden kann findet sich in dieser Seite. (Aufgrund einer Größenbeschränkung passte sie nicht mehr hier hinein.)

I hope this helps some of you to unlearn the old habit and accept the little learning phase. 

A list of all Extended Events in SQL Server 2012 SP1 including its counter piece in SQL Trace that can be used for migration purposes (SQLTrace-> XEvent Trace) is available on this page. (Due to size restriction, it didn’t fit in here anymore.)

PS: Für 2014 befindet sich mit den SQL Server Master-Classes zum Thema „Tracing mit Extended Events“ auch die nächste Runde der Trainings zu diesem Thema in der Planung :-)

P.S. For 2014, the next round of training in this topic is being developed in conjunction with SQL Server Master-Classes on the topic “Tracing with Extended Events” :-)

(de)
Wie ich erwartet hatte, wurde heute am 16.10. auf dem SQL PASS Summit in Charlotte USA, die CTP 2 des SQL Server 2014 veröffentlicht. :-)
Die Final erwarte ich noch im ersten Quartal 2014 herauszukommen.

Hier ist der Link zum Download:

(en)
As I have expected, today, Oct. 16^th the CTP 2 of SQL Server 2014 was published at dem SQL PASS Summit in Charlotte USA. :-)
I am expecting the final to come along in the first quarter of 2014.

Here is the link to the download:

Ein kurzer Überblick über die Neuheiten im Bereich der Datenbank-Engine in diesem Release – zusätzlich zu den Neuerungen aus CTP1, über die ich hier schon berichtete:

• AlwaysOn
  • Bis zu 8 Sekundäre Replikas
  • Bei Quorum-Verlust bleiben read-only Replicas zum Lesen verfügbar
  • Failover cluster instances (FCIs) können Cluster Shared Volumes als cluster shared disks in Windows Server 2012 und höher verwenden
• Datenbank Engine
  • Single Partition Rebuilding
  • Lock Priority Management für Online-Operationen
  • Incrementelle Statistiken
  • Resource Governor Unterstützung für physical IO
  • Neue „Erweiterte Ereignisse“ (XEvents): 775 insgesamt, 152 mehr als SQL 2012 SP1, 12 seit CTP1
• In-Memory OLTP aka Extreme Transactional Processing (XTP, vormals Codename “Hekaton”)
  • B-tree Indexe (Hash-Indexe seit CTP1)
  • Delayed Transaction Durability

A short overview on the New Features in the Database-Engine part in this release – cumulative to the new features from CTP1, which I have listed here already before:

• AlwaysOn
  • Up to 8 secondary replicas
  • In case of loss of quorum, read-only replicas remain available for read-access
  • Failover cluster instances (FCIs) can use Cluster Shared Volumes as cluster shared disks in Windows Server 2012 and above
• Database Engine
  • Single Partition Rebuild
  • Lock Priority Management for Online-Operations
  • Incremental Statistics
  • Resource Governor support for physical IO
  • New Extended Events: 775 total, 152 more than SQL 2012 SP1, 12 since CTP1
• In-Memory OLTP  aka Extreme Transactional Processing (XTP, formerly Codename “Hekaton”)
  • B-tree indexes (Hash indexes since CTP1)
  • Delayed Transaction Durability

• Sicherheit:
  • Backup-Verschlüsselung
  • Neue Berechtigungen (mehr dazu bald in meinem Blog, speziell auch als Ergänzung zu der „CONTROL SERVER“-Thematik

 Security:

• Encrypted Backups
• New permissions (more on that soon in my blog, especially also in addition to the „CONTROL SERVER“-Topic

In Reporting Services und Integration Services gibt es keine Änderungen zu vermelden.

Die komplette Liste ist hier zu finden: msdn.microsoft.com/de-de/library/bb510411%28v=sql.120%29.aspx

Dazu kommen viele Neuerungen im Zusammenspiel mit SQL Azure und im BI & Information Services Bereich. Über diese in Detail zu Berichten, überlasse ich meinen geschätzten Kollegen. Ich werde hier auf die entsprechenden Blog-Posts verweisen sobald diese fertig sind.

Hinweis: Ein Upgrade der CTP1 zur CTP2 ist nicht unterstützt.

In Reporting Services and Integration Services there are no changes.

The complete list can be found here: msdn.microsoft.com/en-us/library/bb510411(v=sql.120).aspx

Added to that there are many new enhancements connected with SQL Azure and in the area of BI & Information Services. I will leave detailed reports on those to my valued colleagues and will link to the respective blog-posts once ready.

Note: Upgrading from CTP1 to CTP2 is not supported.