Where are the scripts to the session „SQL Attacked/Hacking SQL Server“ ? ;-)

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.

The background as to why I’mnot making 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.”