DB Attacks | Datenbanken sind ein attraktives Ziel für Hacker

Im Fadenkreuz der Angreifer: Warum Datenbanken ein attraktives Ziel mit DB Attacks für Hacker und APTs sind.

Mit ihrer Konzentration wertvoller und sensibler Informationen stellen Datenbanken ein wichtigen Mehrwert in der IT dar. Eine Kompromittierung dieser Systeme und ihrer Informationen stellen für Angreifer ein lukratives Ziel aus finanzieller, aber auch aus Sicht der Informationsbeschaffung dar.

In unserem Artikel wollen wir einen Einblick auf typische Angriffe geben, denen Datenbankmanagementsysteme (DBMS) wie Microsoft SQL, MariaDB/MySQL und PostgreSQL von Angreiferseite ausgesetzt sind und Möglichkeiten aufzeigen, wie man dies Angriffe unterbinden oder einschränken kann.

Wir haben 3 Datenbanken (MYSQL, POSTGRESQL, MSSQL) nachgestellt und Angriffe simuliert.

Inhaltsverzeichnis

MYSQL

DB Attacks mit Brute Force-Angriff

Die Methode des Brute-Force-Angriffs auf die direkte Netzwerkauthentifizierung ist vergleichsweise einfach, da sie keine umfassenden Kenntnisse über die zugrundeliegende Datenbankstruktur oder komplexe Exploits erfordert. Dabei versucht der Angreifer, systematisch verschiedene Benutzernamen und Passwörter, um sich Zugriff auf die Datenbank zu verschaffen. Dies geschieht, indem Tools, wie Ncrack, Medusa, Hydra, Patator oder Frameworks wie Metasploit mit ihren entsprechenden Login-Modulen der betroffenen Datenbanken verwendet werden, die eine große Anzahl von Kombinationen ausprobieren, bis korrekte Anmeldeinformationen gefunden sind.

DB Attacks
Erfolgreicher Brute-Force Angriff gegen MYSQL Instanz. Umgesetzt mit Patator

Voraussetzung

Die hier zugrunde liegende “Schwachstelle” liegt in der Wahl schwacher oder auch häufig verwendeter Passwörter, dass der Angreifer sich überhaupt anmelden konnte. Der Remote login sollte zusätzlich immer nur von manuell freigegebenen IP Adressen möglich sein. Default ist der Zugriff bei allen von uns nachgestellten Datenbanktypen (MySQL und POSTGRESQL, MSSQL) nur vom localhost möglich.

Voraussetzung für den Brute-Force Angriff ist ein aktiver Remote-Login von der Angreifermaschine, darum sollten die Hostslisten so klein wie möglich gehalten werden und ein ‘%’ in jedem Fall vermieden werden, da dies den Zugang von jedem Endgerät ermöglicht.

Hier wird ein Nutzer ‘sammy' mit ‘password’ für den Zugang von 'localhost’ freigegeben
Hier wird ein Nutzer ‘sammy' mit ‘password’ für den Zugang von 'localhost’ freigegeben
Hier sieht man eine Übersicht der Benutzer über welchen Host diese Zugriff haben. Das '%' bedeutet von jedem Host.
Hier sieht man eine Übersicht der Benutzer über welchen Host diese Zugriff haben. Das '%' bedeutet von jedem Host.
Du willst Dir die Folgen eines erfolgreichen Hackerangriffs auf
Dein IT-System ersparen?
Teste jetzt deine IT durch einen professionellen Penetrationstest!
Zum Penetrationstest

Solution

Daraus leitet sich folgende Solution ab: Die Hostliste, welche den Zugang zur Datenbank verwaltet hat so klein wie nötig halten!

POSTGRESQL

Brute Force-Angriff

DB Attacks Ein Brute-Force Angriff mittels Potator umgesetzt
Ein Brute-Force Angriff mittels Potator umgesetzt

Voraussetzung

Vorausetzung für einen solchen Angriff von einem externen Gerät ist auch hier ein freigebener Remote-login von der Angreifermaschine aus. Dieser wird über ide pg_hba.conf gesteuert. Default steht hier nur ‘localhost’ bzw. ‘127.0.0.1/32’ drin.
Hier sieht man eine Übersicht der Benutzer über welchen Host diese Zugriff haben. Die '0.0.0.0' bedeutet dass. Zugriff von jedem Host möglich ist.
Hier sieht man eine Übersicht der Benutzer über welchen Host diese Zugriff haben. Die '0.0.0.0' bedeutet dass. Zugriff von jedem Host möglich ist.

Solution für die DB Attacks

Auch hier leitet sich die folgende Solution ab: In der pg_hba.conf, welche den Zugang zur Datenbank verwaltet wird, sollten explizit IP Adressen/Subnetze für den Remote-Zugriff freigegeben werden. Bitte hier starke Passwörter verwenden!
Unter # CUSTOM werden hier z.b. explizit Nutzer von einzelnen IP Adressen oder Adressbereichen freigegeben.
Unter # CUSTOM werden hier z.b. explizit Nutzer von einzelnen IP Adressen oder Adressbereichen freigegeben.

MSSQL

Brute Force-Angriff

DB Attacks Möglicher Brute-Force Angriff - mit Erfolg - auf eine MSSQL Instanz
Möglicher Brute-Force Angriff - mit Erfolg - auf eine MSSQL Instanz

Voraussetzung

Die Voraussetzungen für die DB Attacks sind – wie bei MYSQL – dass ein aktiver Remote-Login von der Angreifermaschine vorliegt. Auch hier muss man sich die Schwachstelle selbst konfigurieren. Standardmäßig ist zwar der Remote-login an, allerdings ist der Port über die Windows Firewall eingeschränkt und ein Zugriff von außen dadurch nicht möglich.

Da wir den SQL Server Brute-forcen möchten, haben wir die Server Authentifizierung auf “SQL Server and Windows Authentication mode“ gesetzt
Da wir den SQL Server Brute-forcen möchten, haben wir die Server Authentifizierung auf “SQL Server and Windows Authentication mode“ gesetzt
Der Haken “Allow remote connections to this server“ muss gesetzt sein
Der Haken “Allow remote connections to this server“ muss gesetzt sein

Solution

Hier sollte den Zugang von externen Nutzern über die Windows Firewall beschränkt werden. Die angelegten Benutzer selbst dürfen sich nur von bestimmten Hostlisten an der Datenbank anmelden. Der Zugriff auf die Datenbank durch externe Benutzer sollte hier ebenfalls mittels Hostlisten eingeschränkt werden. Da Windows hierfür kein direktes Rollenkonzept vorsieht, müssen hier Firewall-Regeln verwendet werden. Der Port kann wie folgt eingeschränkt werden:
Im Regelassistent wählen wir ‘Port’
Im Regelassistent wählen wir ‘Port’
Wählen den Port '1433' für MSSQL
Wählen den Port '1433' für MSSQL
da wir whitelisten möchten, wählen wir 'Verbindung zulassen'…
da wir whitelisten möchten, wählen wir 'Verbindung zulassen'…
…wählen die 'SQL_RESTRICTET'- Regel aus
…wählen die 'SQL_RESTRICTET'- Regel aus
und schreiben in Remote-IP_Adresse die freigegebenen Hosts rein
und schreiben in Remote-IP_Adresse die freigegebenen Hosts rein
DB Attacks
DB Attacks - Die obere Maschine wurde nun freigegeben und kann auf den Port zugreifen
Die obere Maschine wurde nun freigegeben und kann auf den Port zugreifen

Angriff: xp_cmdshell

Die xp_cmdshell ist eine erweiterte Transact-SQL-Befehlsfunktion, die in Microsoft SQL Server-Datenbanken zur Verfügung gestellt wird. Ihre Hauptfunktionen besteht darin, die Ausführung von Befehlen auf Betriebssystemebene aus der SQL-Server Umgebung heraus zu ermöglichen.
Ein Bespielbefehl “ipconfig“ über die xp_cmdshell abgesetzt
Ein Bespielbefehl “ipconfig“ über die xp_cmdshell abgesetzt
Entwickelt wurde diese Funktion, um Administratoren bei der Automatisierung von verschiedensten Aufgaben zu unterstützen, die eine Interaktion mit dem zugrunde liegenden Betriebssystem erfordern. Typische Aufgaben wären beispielsweise die Ausführung von Skripten, die Verwaltung von Dateien und dich Durchführung von Systembefehlen direkt aus der Datenbankumgebung heraus.

Zugriff und Berechtigungen

In der Regel hat man mit einer xp_cmdshell bereits verloren, da das unterliegende “SeImpersonatePrivilege” für den Betrieb des Dienstes zwingend erforderlich ist und die xp_cmdshell nicht zu 100% deaktiviert werden kann. Generell gilt: MSSQL als sa = RCE = NT\SYSTEM auf der Maschine.

Wichtiger ist ez zu verhindern, dass es überhaupt zur Nutzung einer xp_cmdshell kommt. Dementsprechend gilt: Datenbanken sollten nie im Kontext des Datenbankbesitzers oder systemadministrators (db_owner bzw. sa) laufen, die Zugangsdaten hierfür sollten sicher sein und nicht z.B. auf SMB-Shares geteilt werden. Remote-Anmeldungen, falls sie wirklich benötigt werden, sollten über die Host Based Firewall nur von zulässigen Systemen gewährt werden. Weiterhin ist es extrem wichtig, dass falls Domain Accounts für den Betrieb der SQL-Instanzen genutzt werden (Erkennbar am SPN MSSQLSvc/), dass diese im idealfall GMSA-Accounts sind oder zumindest ein starkes Passwort haben. Weil nach erfolgreichem Kerberoasting dieser Accounts ein Silver-Ticket Angriff auf den SQL Dienst möglich ist.

Voraussetzung

Die Voraussetzung hier dass einem entweder nicht administrativen Nutzer manuell die Berechtigungen auf die xp_cmdshell gewährt wurden,

				
					GRANT exec ON xp_cmdshell TO N'<some_user>';
				
			

oder dass ein administrativer Nutzer ein schwaches Passwort hatte und er somit die xp_cmdshell selbst an & aus schalten kann.

Standardkonfiguration - xp_cmdshell ist nicht aktiviert
Standardkonfiguration - xp_cmdshell ist nicht aktiviert
Die SQL Abfragen um die xp_cmdshell zu aktivieren
Die SQL Abfragen um die xp_cmdshell zu aktivieren

Solution

Die xp_cmdshell nicht aktivieren und wenn nicht anders möglich nur einem eingeschränktem Benutzer die nötigen Berechtigungen geben und diesen mit einem ausreichend starken Passwort versehen und gleichzeitig Kontoaktivitäten loggen und zusätzlich sollte der MSSQL für wenige Hosts erreichbar sein.

Steigere jetzt die Sicherheit Deines IT-Systems!
Von uns erhältst Du eine ausführliche Beratung!
Jetzt kontaktieren
ANDERE BEITRÄGE

Inhaltsverzeichnis