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.
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.
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.
Daraus leitet sich folgende Solution ab: Die Hostliste, welche den Zugang zur Datenbank verwaltet hat so klein wie nötig halten!
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.
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.
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.
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.
Microsoft Entra Connect (ehem. Azure AD Connect) unterstützt die Nutzerfreundlichkeit, wenn gleichzeitig ein On Premise Active Directory und Microsoft Entra
203 Milliarden Euro Schaden entstand der Wirtschaft in Deutschland 2022 durch Cyberangriffe – zu diesem Ergebnis kommt der aktuelle Report
Welche Rechte darf ein normaler Nutzer in Microsoft Entra Admin Center haben? „So wenig wie möglich, so viel wie nötig“