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 einen 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.
(Letztes Update: 18.06.2024)
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 probiert der Angreifer systematisch verschiedene Benutzernamen und Passwörter durch, 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.
Die hier zugrunde liegende “Schwachstelle” liegt in der Wahl schwacher oder auch häufig verwendeter Passwörter. Diese ermöglichen dem Angreifer sich überhaupt anmelden zu können. 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 Host-listen so klein wie möglich gehalten werden und ein ‘%’ in jedem Fall vermieden werden, da dies den Zugang von jedem Endgerät ermöglicht.
Daraus leitet sich folgende Solution ab: Die Host-liste, welche den Zugang zur Datenbank verwaltet hat, so klein wie nötig halten!
Voraussetzung für einen solchen Angriff von einem externen Gerät ist auch hier ein freigegebener 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.
Auch hier leitet sich die folgende Solution ab: In der pg_hba.conf, welche den Zugang zur Datenbank verwaltet, sollten explizit IP Adressen/Subnetze für den Remote-Zugriff freigegeben werden. Hier bitte starke Passwörter verwenden!
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.
Hier sollte den Zugang von externen Nutzern über die Windows Firewall beschränkt werden. Die angelegten Benutzer selbst dürfen sich nur von bestimmten Host-listen an der Datenbank anmelden. Der Zugriff auf die Datenbank durch externe Benutzer sollte hier ebenfalls mittels Host-listen 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:
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 die Durchführung von Systembefehlen direkt aus der Datenbankumgebung heraus.
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 es 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/), 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.
Die Voraussetzung hier ist, dass entweder einem nicht administrativen Nutzer manuell die Berechtigungen auf die xp_cmdshell gewährt wurden,
GRANT exec ON xp_cmdshell TO N'';
oder dass ein administrativer Nutzer ein schwaches Passwort hatte und er somit die xp_cmdshell selbst an & aus schalten kann.
Die xp_cmdshell nicht aktivieren oder, 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. Zusätzlich sollte der MSSQL für nur wenige Hosts erreichbar sein.
