SQL Server & BI Blog by Andreas Wolter

(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” :-)