Tag: "sicherheit"

Security Session „SQL Attack..ed“ – Attack scenarios on SQL Server ("Hacking SQL Server")

Jul 16th

Posted by Andreas Wolter in Security

No comments

 

Vortrag SQL Server Sicherheit „SQL Attack..ed“ – Angriffszenarien auf SQL Server („SQL Server Hacken“)

(DE)

Auf dem diesjährigen SQLSaturday in Deutschland habe ich wieder einmal einen meiner Sicherheitsvorträge gehalten, in denen ich mich auf „Angriff“ konzentriere. Für mich eine gute Gelegenheit, mich wieder einmal intensiv mit SQL Server Sicherheit und einigen Penetrationstest-Tools auseinanderzusetzen, und SQL Server auf Fallstricke in Sachen Sicherheitskonfiguration zu untersuchen. Am Ende hatte ich eine lange Liste an möglichen Demonstrationen, worunter auch eine von mir frisch entwickelte DoS-Attacke via SQL Injection zählt (zumindest habe ich nirgends einen Hinweis auf eine Beschreibung dieser Art Angriff gefunden oder auf meine Nachfragen erhalten), sowie eine „privilege elevation“(Privilegienerweiterung)-Attacke, die in dieser Form auch noch unbekannt zu sein scheint. – Alles jedoch unter Ausnutzung von angepassten Einstellungen, und keine Schwächen in der Engine(!).

 

Da es speziell zu SQL Server kaum nennenswerte Sessions in Deutschland zu diesem Thema gibt (selbst auf den Summits in den USA war ich damit meist recht allein unterwegs), und mir das Thema in dieser Tiefe natürlich auch besonders Spaß macht, habe ich mich entschieden, hier meine möglichen Themen zu sammeln. Ich werde sie nicht nur auf weiteren kommenden Konferenzen in Europa oder USA präsentieren, sondern auch den Regionalgruppen der deutschen PASS anzubieten – die sich hier sozusagen im „Menü“ bedienen können :-)


An einem Abend schafft man vermutlich maximal ein Drittel der möglichen Themen. – Und damit wälze ich nun die Qual der Wahl auf die Kollegen RGVs ab ;-)

(EN)

At this year’s SQLSaturday in Germany I have shown one of my sessions again, in which I concentrate on “attack”. For me a great opportunity to dive deep into SQL Server Security and several penetration-test-tool, and to explore SQL Server for pitfalls and security configuration. At the end I had a long list of possible demonstrations. Among them a just recently developed DoS-attack via SQL Injection (at least I did not find any clue on a description for this kind of attack anywhere or got an answer on my inquiries), as well as a “privilege elevation”, which in this form seems to be quite unknown as well. – Everything is just done by exploiting customized settings and not by weaknesses in the engine (!).

 

Since there are barely any nameable sessions on this topic specifically for SQL Server in Germany (even at the Summits in the US I tended to be quite alone with my sessions on security), and I enjoy this topic in this a lot, I have decided to collect all possible topics here.
I will not only present them on upcoming conferences in Europe or the US, but also I am offering these to the regional chapter leaders in Germany  – “serve yourself” - style :-)

Session Beschreibung:

SQL Server kann als "secure by default" gelten, aber da das am häufigsten erfolgreich angegriffene Ziel die Daten, die in der Datenbank liegen, sind, möchte ich in dieser Session für das Thema sensibilisieren.
Die meisten der ausgenutzten Schwachstellen in einer SQL Server Umgebung sind auf Miss-konfiguration, schwache Sicherheitseinstellungen oder ungenügende Programmierpraktiken zurückzuführen.

In dieser rein Demo-basierten Session werden verschiedene Angriffsszenarien auf verschiedenen Ebenen gezeigt. Auf speziellen Wunsch auch einige Advanced SQL-Injection Beispiele. Des Weiteren zeige ich, wie eine „privilege elevation“ aufgrund einer nicht unüblichen Einstellung möglich ist und die Ausnutzung von Rechten mit einem Datenbank-Rootkit durch einen "Insider".

In dieser Art Vortrag gebe ich natürlich keine Anleitung "wie man hackt", sondern ich beleuchte häufige Schwachstellen - "Was kann unter welchen Umständen passieren".

(Fast) keine Folien: Demos Demos Demos

Session Description:

SQL Server is considered "secure by default", but one of the most often successfully attacked targets is the data that resides in a Database Server.
Most of the exploited weaknesses in a SQL Server environment are due to misconfiguration weak security settings or inadequate coding practices.

In this purely demo-based security session, I am showing several attack scenarios on different layers. Due to special request this includes some special SQL Injection types. Furthermore I show how an evaluation of privileges attack is possible due to a not uncommon configuration as well as an “insider-exploit” with a database root kit.

Note that in this kind of session I do not give instructions on “how to hack” but rather I am highlighting common weaknesses - “what can happen and under which circumstances”.

(Almost) no slides: just Demos Demos Demos

                                                 Inhalte // Contents

(Web)Application Layer

  • Mein Formular und die WAF lassen nichts durch – oder doch?
    • Standard SQL Injection
    • Blind / Error-based /Time-based SQL Injection, Encoding Injection
    • 2nd Order SQL Injection
    • Privilege Escalation über SQL Injection und trustworthy
    • Automatisierte Attacken mit Tools, weitere „Features“ (sqlmap,...)
    • “Der Fall der nicht-terminierbaren Transaktion“ -  DoS Attack über SQL Injection (von mir "erfunden" für den SQLSaturday Germany 2013)

(Web)Application Layer

  • My form and the WAF don’t let anything pass through – or do they?
    • Standard SQL Injection
    • Blind / Error-based /Time-based SQL Injection, Encoding Injection
    • 2nd Order SQL Injection
    • Privilege Escalation via SQL Injection and trustworthy
    • automated attacks using tools, further “features” (sqlmap,...)
    • “case of the unkillable transaction” - DoS Attack via SQL Injection ("invented" by me for SQLSaturday Germany 2013)

 

Table names

Innerhalb des Netzwerk

  • Aufklärung: Erkennen von SQL Server Instanzen
  • SQL Authentifizierung
    • Beobachten von SQL Traffic (Login + Select)
  • Automatisierte brute-Force Attacke gegen sa-Passwörter

Inside the Network

  • Reconnaissance: Detecting SQL Server Instances
  • SQL authentication
    • Watching SQL Traffic (Login + Select)
  • Automated brute-Force Attack against sa-passwords

Network Monitor Capture TDS frame

Network Monitor TDS frame capture

Server & Datenbank-Ebene – Angriffe von Innen, Teil 1: der böse Consultant

  • SQL Authentifizierung
    • Cracken von Passwörtern – möglich? Wie?
    • Auslesen von Passwörtern aus dem Arbeitsspeicher
  • Was ein Consultant so hinterlassen kann
    • Automatisierte Einrichtung eines SQL Server Rootkits
  • „Wenn der Gast die Party wechselt“

Server & database-Level – attacks from inside, Part 1: evil Consultant

  • SQL authentication
    • Cracking Passwords – possible? How?
    • Reading passwords from memory
  • What a Consultant may leave behind
    • Automated install of a SQL Server rootkit
  • „When the guest switches the party“

Server & Datenbank-Ebene – Angriffe von Innen, Teil 2: der böse Entwickler

  • „Kenne Deine Rechte“
    • "Transfer-Schema Attack"
      – erstmalig gezeigt auf dem PASS Summit 2010 in Seattle :-)
  • „Alles meins“ – oder nicht?
    • Datenbankbesitzverkettung
    • Db_owner unterschätzt & ausgenutzt
    • Schema-ownership-chaining

Server & database-Level – attacks from inside, Part 2: evil Developer

  • „Know your rights“
    • "Transfer-Schema Attack"
      – first shown at PASS Summit 2010 in Seattle :-)
  • „Everything belongs to me“ – does it?
    • Database-ownership-chaining
    • Db_owner underestimated & exploited
    • Schema-ownership-chaining

 

Recent Security Reports:

PASS Essential "SQL Server 2012 Datenbank-Sicherheit, Best Practices & Fallstricke"

Security Workshops, 2014:


enjoy
and until soon - in your regional chapter, in your company, at a SQL Server Master-Class or at some conference - just say hello if you see me

 

Andreas

, , , , , ,

Conferences 2013: Frankfurter Datenbanktage und einige “Oracle-Momente”

Apr 11th

Eingetragen von Andreas Wolter in Conferences

No comments

Normalerweise versuche ich ja, meine Konferenz-Teilnahmen vorab bekanntzugeben, um dem Leser auch eine Chance zu geben, diese eventuell einzuplanen.

Aufgrund akutem Zeitmangel, und auch dem Umstand gewidmet, das ich erst eine Woche vor der Konferenz spontan für einen ausgefallenen Sprecher eingesprungen bin, ist mir das diesmal nicht gelungen.

Ich hatte das Vergnügen, einen Vortrag über “Hochverfügbarkeitstechniken mit SQL Server 2012” zu halten, und auch in einem Interview zu diesem Thema befragt zu werden.

Ich möchte über die diesjährigen (ersten) Frankfurter Datenbanktage (der Termin für das nächste Jahr steht bereits fest: 26. - 28. März 2014) gerne noch im Nachhinein schreiben, da mir das Konzept mit gleichzeitigen Tracks & Sessions zu Oracle, DB2, MySQL, NoSQL und SQL Server sehr gefällt.

Es ist z.B. immer wieder interessant - aber auch bedauerlich, festzustellen, wie unbekannt Snapshot Isolation & RCSI in SQL Server eigentlich ist.
Das geht soweit, das in einer Session, in der es um die Fähigkeiten der verschiedenen Datenbanksysteme, während des Schreibens von Datensätzen, dennoch gleichzeitig einen konsistenten Zustand lesen zu können zu der Aussage kam, das nur Oracle dies beherrscht.
Das ist sehr schade.
Denn abgesehen davon, das diese Aussage so nicht richtig ist - SQL Server bietet 2 Varianten (eben Snapshot Isolation und Read Committed Snapshot Isolation), auf die das ebenso zutrifft; das Hintergrundwissen, das Microsoft den Entwicklern die Wahl zwischen vielen verschiedenen Isolationsstufen gibt, und warum dieses Konzept auch besser ist, als keine Wahl zu haben (oder zumindest so sehr auf nur eine festgelegt zu sein, das selbst Oracle-Admins meinen, es gäbe keine), scheint nicht so weit verbreitet zu sein, wie man es sich erhoffen würde.

Eine andere Session, die ich nur lesenderweise mir ansah, hat mich als Security Spezialist für SQL Server schon fast geschockt: Es ist zwar kein Geheimnis (auch wenn es interessanterweise gerade im Bankenbereich gern ignoriert wird), wie umfangreich die Anzahl der Sicherheitslücken in ORACLE ist (Beim "NIST" kann man sich darüber informieren: nvd.nist.gov), aber in welchem Ausmaß man selbst ohne spezieller Betrachtung derer eine sogenanntes Sicherheits-“Härtung” durchführen muss, um einigermaßen sicher vor den gröbsten Einfallstoren zu sein, hat mich als seit SQL Server 2005 “secure by default” gewohnter doch sehr überrascht. - Möglichst “sanft" (Session-Untertitel "Sanftes Härten"), damit danach auch noch alles funktioniert - und wir wollen die Angreifer ja auch nicht völlig vergraulen, oder? :) (Nachtrag: natürlich ist es nachvollziehbar, das man nicht einfach so alles "dicht" macht, und danach auch die validen Anwendungen nicht mehr funtionieren. Die Essenz ist: es muss ein Mittelweg gefunden werden, welcher die Angreifbarkeit und Verletzbarkeit zumindest mindert. Und das ist natürlich schon viel Wert!)
Welche meiner Daten so "geschützt" in Oracle-DBs liegen, wäre vielleicht gut zu wissen... ganz ohne Häme, denn der einzelne Kunde kann dafür meistens gar Nichts. - Nur wenn er informiert ist und gar nicht handelt (Und nicht einmal mildernd eingreift).

Um es aber auch klar zu sagen: auch einen SQL Server kann man angreifen, wenn Applikationen oder andere Verbindungen mit zu viel Rechten laufen, Service Accounts geshared werden, etc.. Deswegen hier noch einmal die beiden wichtigsten Sicherheitsprinzipien: "Separation of duties/roles" und "Principle of least privilege". Also Aufgaben/Rollen (Dienstkonten!) trennen und immer mit den geringstmöglichen Rechten arbeiten. Und oben drauf ein Auditing, damit man mitbekommt, wenn man einen Weg übersehen hat.

Und nicht zuletzt wegen der Möglichkeit solche Missverständnisse oder Vergleiche einmal live zu erfahren, oder auch einfach ganz andere Möglichkeiten, die es bei anderen DBMS ja auch gibt, kennenzulernen, empfinde ich die Frankfurter Datenbanktage als Bereicherung in der Konferenz-Landschaft.

Tatsächlich versucht die PASS Deutschland e.V. eine kleine Variante solcher Mixtur auch für den geplanten SQLSaturday #230 in Rheinland, auf welchem ich sicherlich auch anzutreffen sein werde, mit einzubringen. Ich bin gespannt, was daraus wird, und wie es aufgenommen wird.

 

vielleicht sieht man sich auf der nächsten Konferenz,

 

Andreas

, , , ,

Sessions auf der SQLCon 2011

Mai 15th

Eingetragen von Andreas Wolter in Conferences

No comments

Auch dieses Jahr bin ich wieder mit bis dato zwei Sessions auf der SQLCon 2011 – 26. – 29. September in Mainz vertreten.

Update (09/2011): Den Vortrag “Reporting Services in SQL Server Denali” habe ich zugunsten eines mir noch mehr am Herzen liegenden Themas gestrichen. (Außerdem werden die Reporting Services selber kaum viele Neuereungen in Denali erfahren)
Dafür halte ich eine Session zu den Sicherheits-Features & Techniken von SQL Server für Entwickler:

“Schutz gegen SQL Injection sollte mittlerweile zum Repertoire jedes Entwicklers gehören. Jedoch gibt es noch andere Wege, an sensible Daten zu gelangen oder sie zu manipulieren. In dieser demointensiven Session (Achtung: Code, Code) werden wir uns vor allem anderen Techniken widmen, die man im Repertoire haben sollte, die Sicherheit seiner Daten zu stärken. Dazu gehören Basics wie Schema-Design für Security, Besitzerketten und ihre Fallstricke, Codesignierung und Verschlüsselung für die kritischsten Daten.“

”Wer Berichte mit Reporting Services erstellt, wird feststellen, dass ganz schnell nach weiteren verlangt wird. Und früher oder später kommt der Ruf nach einem einheitlichen Aussehen. Die Unterstützung dafür out of the box ist eher schwach. Dennoch kann man mit geschickter Kombination der zur Verfügung stehenden Möglichkeiten eine starke Effizienz-Steigerung beim Erstellen neuer Berichte erreichen.“

 

Ich würde mich freuen, den einen oder anderen persönlich, “offline”, begrüßen zu können.

Andreas Wolter

Sarpedon Quality Lab

, , , , , , , , , , ,

Security-issue: guest-guest impersonation

Sep 24th

Posted by Andreas Wolter in Security

No comments

Almost a year ago I discovered an issue with SQL Server (all Versions from 2005 – 2008 R2, haven't tested 2000) regarding the usage of the guest-account and impersonation.

It also was presented by Ralf Dietrich and me at the SQL Server PASS Summit 2009 in Seattle where we informed Microsoft about it. - Thanks to Jack Richins from Microsoft for helping me find the root cause. (MSDN-blog post)

Unfortunately, a fix hasn’t been provided for SQL Server yet. As I was informed it will only be fixed in the next major version, Codename “Denali”. Here is the Connect-Item: https://connect.microsoft.com/SQLServer/feedback/details/509379/guest-activated-in-2-databases-leads-to-inconsistent-behaviour-and-may-also-compromise-security

Recently I demonstrated this technique again at the SQLCon in Mainz/Germany and now feel that I should blog about this.

 

This issue applies in a couple of scenarios, a more common of which I want to show here.

 

One scenario is, that sometimes or even often, developers, whether external or not, are given excessive rights in a certain database – on the same Server, where other databases exists, which may contain “public” data. But “public” maybe only for internal usage and not for external developers.

This is accomplished the following way: the database, let’s call it “InternalPublicData” will have the guest account enabled, and guest has permissions to see whatever is of interest for internal stuff.

In order to prevent access to this database for a certain Login, a database-user will be explicitly created in this database, so the Login does not match to guest and will be denied any resources in this database. One could even deny Connect-permission to the database, to secure it even more.

But this doesn’t help either, as you will see.

Also there is the database where the developer will have full permissions so he can work in his database and do anything inside. He might be dbo or member of the db_owner-role. (Unfortunately quite common because of the restrictions when using db_ddladmin etc.)

And now the trouble begins: The developer, let's call him “Dev0” cannot successfully connect to the InternalPublicData-database and act as guest there. But what he can do is the following: he can enable guest in his very own database.

Doing that, he can impersonate his local guest and then, not being “Dev0” any more, go to the InternalPublicData-database and successfully connect.

At that stage, he already has all permissions that the remote guest-account already has directly attached to it. But that’s not all. He can then do a second impersonate and gain role-memberships of the guest at the InternalPublicData-database!

No "Deny" for Dev0 can prevent that!

 

As a second option, he could, with permissions of creating a “User without Login“, impersonate that User and use it to jump to other databases where guest-is active…

 

The following is a script to demonstrate:

--Login:
CREATE LOGIN Dev0
    WITH PASSWORD = 'Pa$$w0rd'
GO

/* setup DBs*/
create database InternalPublicData;
create database DevelopmentDB;
GO

--Target-DB
use InternalPublicData;
grant connect to guest;

create table t1(c1 int)
insert into t1 values(1)

create table t2(c1 int)
insert into t2 values(2)

GRANT SELECT
ON dbo.t1
TO guest    -- and only guest

exec sp_addrolemember 'db_datareader', 'guest'    -- just to point out the fact that these guest-accounts are actually different even further

CREATE USER Dev0 FOR LOGIN Dev0    -- no memberships, so denied everything and not matching to guest automatically

DENY CONNECT TO Dev0    -- to make SURE!

-- DB 2
use DevelopmentDB;

CREATE USER Dev0 FOR LOGIN Dev0

EXEC sp_addrolemember N'db_owner', N'Dev0'
GO

GO

/* Setup finish */

/* Session as Dev0 */

EXECUTE AS LOGIN = 'Dev0'

-- Who and Where am I
SELECT CURRENT_USER AS CURRENT_USER_Name
    , SYSTEM_USER AS SYSTEM_USER_Name
    , ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
    , DB_NAME() AS Current_Database

use InternalPublicData;    -- not possible with Deny Connect

SELECT * FROM t1    -- with no Deny connect he gets denied here

execute as user = 'guest';        -- he can NOT do this at the remote DB (good so far)

-- Part One:

-- go back
USE DevelopmentDB

execute as user = 'guest';        -- not active

grant connect to guest;    -- but as a "Dev" with excessive permissions he can do what he wants
exec sp_addrolemember 'db_datawriter', 'guest'    -- just so that one can differentiate the guest accounts easier

execute as user = 'guest';        -- now we are in the game

-- Who and Where am I
SELECT CURRENT_USER AS CURRENT_USER_Name
    , USER_NAME()    AS DBUser
    , SYSTEM_USER AS SYSTEM_USER_Name
    , ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
    , DB_NAME() AS Current_Database

select * from sys.user_token;    -- now he became guest in DevelopmentDB for real

-- End of Part One

-- Part Two: using guest for executing as guest

USE InternalPublicData;        -- we connected as guest - no Deny for Dev0 Applying!!

SELECT CURRENT_USER AS CURRENT_USER_Name
    , USER_NAME()    AS DBUser
    , SYSTEM_USER AS SYSTEM_USER_Name
    , ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
    , DB_NAME() AS Current_Database
select * from sys.user_token;    -- he became guest in the remote-DB

SELECT * FROM dbo.t1        -- permissions at User(guest)-Level already working!

SELECT * FROM dbo.t2        -- not working because permission for role not applying

-- BUT: switch to InternalPublicData guest explicitely
execute as user = 'guest';        --NOW "Dev0" can do it in the Target-DB

SELECT CURRENT_USER AS CURRENT_USER_Name
    , USER_NAME()    AS DBUser
    , SYSTEM_USER AS SYSTEM_USER_Name
    , ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
    , DB_NAME() AS Current_Database
select * from sys.user_token;    -- he became guest with group-membership in Target-DB

SELECT * FROM dbo.t2            -- can now also read datathrough role-membership

-- End of Part Two: using guest for executing as guest
/* back off step by step */

USE InternalPublicData
revert;

USE DevelopmentDB
revert;

revert;

USE InternalPublicData
revert;

/* Finished */

USE master;
DROP DATABASE InternalPublicData;
DROP DATABASE DevelopmentDB;
DROP LOGIN Dev0

 

There is just one option to be sure that your system is safe from developers: don’t mix production with development – not even on server-level!

This should be absolutely clear, but I’ll repeat that, as long as I see mixed environments at customers' sites. Unfortunately, this is very common.

And secondly: never use the guest account for data that is not really supposed for everyone.

, , ,
1 2