Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Im Jahr 2019 hat sich die Gesamtzahl der veröffentlichten Open-Source-V CVEs (968) im Vergleich zu den Vorjahren mehr als verdoppelt. Die Zahl der Schwachstellen stieg zwischen 2018 und 2019 um 130 % (421 CVEs auf 968 CVEs) und lag um 127 % höher als 2017 (435), das die zweitmeisten CVEs in der Studie aufwies. Dieser Anstieg scheint kein Strohfeuer zu sein, da die Entdeckung neuer CVEs auch in den ersten drei Monaten des Jahres 2020 auf einem historisch hohen Niveau bleibt. Dieses Volumen erhöht die Komplexität der Verwaltung der Angriffsfläche eines Unternehmens für Entwickler, IT- und Sicherheitsteams gleichermaßen. Der Jenkins-Automatisierungsserver wies mit 646 die meisten CVEs auf, dicht gefolgt von MySQL mit 624. Ebenso wiesen diese Projekte mit 15 die meisten als Waffe genutzten Schwachstellen auf (Schwachstellen, für die ein Exploit-Code existiert). Dieser Artikel untersucht die Gründe für diese Software-Schwachstellen und zeigt, wie man MySQL-Datenbanken vor potenziellen Sicherheitsvorfällen schützen kann.
Inhalte:
-
Ein kurzer Überblick über MySQL und seine Bedeutung auf dem Markt für relationale Datenbanken
- Schwachstellen in MySQL
- Gefahren von ungepatchten Datenbankservern
Ein kurzer Überblick über MySQL und seine Bedeutung auf dem Markt für relationale Datenbanken
Es gibt mehrere Datenbanken auf dem Markt, aber MySQL ist eine der bekanntesten, die sowohl für interne Backend-Prozesse als auch für öffentliche Anwendungen wie Websites und Kundenportale verwendet wird. Obwohl es sich um eine Open-Source-Datenbank handelt, wurde MySQL von Sun Microsystems übernommen, das später von Oracle aufgekauft wurde. Sie wurde erstmals in den 1990er Jahren eingeführt, entwickelte sich aber schnell zu einer beliebten Alternative zur bis dahin dominierenden Datenbank Microsoft SQL Server. Die Syntax von MySQL ähnelt der anderer SQL-Sprachen (z. B. Oracle und Microsoft), so dass es für Entwickler und Unternehmen, die eine kostengünstigere Datenbank benötigen, eine gute Wahl ist.
Derzeit ist MySQL eines der am häufigsten verwendeten relationalen Datenbankmanagementsysteme (DBMS) auf dem Markt. Eine Studie aus dem Jahr 2019 zeigte, dass MySQL einen Marktanteil von 38,9 % hatte, gefolgt von MongoDB mit 24,6 % und PostgreSQL mit 17,4 %. Die Verfolgung von Meilensteinen im Lebenszyklus, wie beispielsweise das EOL von PostgreSQL 13, hilft Teams dabei, den Betrieb nicht mehr unterstützter Datenbankversionen zu vermeiden, wenn sie Patches und Upgrades planen. Ebenso wichtig ist es, die Lebenszyklusphasen anderer Systeme zu überwachen, wie beispielsweise die End-of-Life-Termine von MySQL, um sicherzustellen, dass ältere Datenbanken nicht zu leichten Zielen werden. Open-Source-Datenbanksoftware dominiert einen Großteil der Websites, Backend-Systeme und anderer von Unternehmen betriebener Datenspeicherserver.
Open-Source-Software für den Betrieb von Infrastruktur bietet zahlreiche Vorteile, darunter eine Community, die zu Updates, der Fehlerbehebung und der Entwicklung neuer Funktionen beiträgt, Sicherheitsforscher, die Schwachstellen aufdecken können, bevor Hacker sie finden und ausnutzen, sowie ein gemeinsames Repository, das von anderen Entwicklern geforkt und angepasst werden kann. Diese Vorteile haben jedoch auch eine Kehrseite. Wenn ein Angreifer einen Fehler findet, kann er diesen ausnutzen, anstatt ihn zu melden. Die Folge könnte die Ausnutzung der Software sein sowie eine Zero-Day-Sicherheitslücke, die dem Entwickler erst dann bekannt wird, wenn der Exploit oder die Code-Schwachstelle entdeckt wird. Es kann unter Umständen Jahre dauern, bis eine derzeit ausgenutzte Sicherheitslücke identifiziert wird. Umso wichtiger ist es für Unternehmen, MySQL-Software zu patchen, sobald ein Update veröffentlicht wird. Diese Updates beheben Sicherheitslücken, die möglicherweise schon seit Monaten oder sogar Jahren bestehen. Wenn der Exploit eine MySQL-Produktionsdatenbank betrifft, in der sensible Informationen gespeichert sind, ist es unerlässlich, dass das Unternehmen das System so schnell wie möglich patcht.
Schwachstellen in MySQL
Aufgrund der langen Zeit, die MySQL der Öffentlichkeit zur Verfügung steht, und seiner Open-Source-Codebasis weist die Datenbanksoftware zahlreiche CVEs (Common Vulnerabilities and Exposures) - insgesamt 1308. Einige dieser CVEs beziehen sich auf Anwendungen oder Software, wie z. B. PHP-Anwendungsdateien, die SQL-Injection zur Manipulation von Webinhalten und zur Ausführung von persistentem Cross-Site Scripting (XSS) ermöglichen, andere wiederum zielen auf den Kern der Datenbank-Engine. Einige Schwachstellen aus dem Jahr 2020 ermöglichen die Ausweitung von Privilegien, Netzwerkzugriff, um den MySQL-Client zu kompromittieren, und Remotecodeausführung (RCE).
Eine kompromittierte Datenbank ist ein kritisches Sicherheitsereignis, da durch den Zugriff von Angreifern auf die Datenbank eine Reihe weiterer Probleme entstehen können. Je nach Exploit können Angreifer Daten von einem kompromittierten Server exfiltrieren, sich selbst administrative Rechte auf dem Server verschaffen oder ihre eigenen Daten in Tabellen einspeisen. Bei einem persistenten XSS-Angriff kann jede Anwendung, die Datenbankdaten nicht verschlüsselt, für den Diebstahl von Daten oder Cookies anfällig sein. Wenn ein Angreifer in der Lage ist, seine Rechte auf dem Server zu erweitern, kann er Daten manipulieren, Daten auf einen von einem Angreifer kontrollierten Server exfiltrieren oder Querbewegungen in Unternehmensdatenbanken durchführen. Die Ausführung von Remotecode ist besonders gefährlich, da ein Angreifer seine eigene Malware auf dem Server ausführen kann, die von Keyloggern bis hin zu Ransomware reichen kann.
Gefahren von ungepatchten Datenbankservern
Als Beispiel siehe CVE-2020-2934. Es gibt mehrere andere CVEs im Zusammenhang mit dieser Schwachstelle, die alle MySQL-Konnektoren, Clients und Netzwerksitzungen betreffen. Die erfolgreiche Ausnutzung dieser Schwachstelle könnte es einem Angreifer ermöglichen, CRUD-Befehle (Create, Read, Update oder Delete) auf dem Datenbankserver auszuführen oder eine Denial-of-Service-Attacke (DoS) zu starten. Ein Angreifer, der CRUD-Befehle ausführen kann, kann Ihre Daten lesen oder ändern. In ähnlicher Weise könnte das Ende der Lebensdauer von PostgreSQL14 Schwachstellen für Unternehmen mit sich bringen, die kein Upgrade durchführen, wodurch sie aufgrund nicht unterstützter Versionen dem Risiko von Ausnutzungen und Angriffen ausgesetzt sind.
Informationen zu bewährten Verfahren für die Sicherheit von PostgreSQL finden Sie in unserer speziellen Anleitung zur Absicherung von Datenbankkonfigurationen.
Datenschutzverletzungen in einer Datenbank gelten als kritisch und haben langfristige Auswirkungen auf Kundenbindung, Vertrauen, Umsatz und Produktivität. Die meisten Unternehmen verfügen nicht über ein internes Notfallteam, so dass externe Berater erforderlich sind, die Hunderte von Dollar pro Stunde verlangen. In einigen Fällen entscheiden sich die IT-Administratoren dafür, kritische Systeme abzuschalten, um den Einbruch einzudämmen und den Zugriff der Hacker auf den Datenbankserver zu verhindern. Diese vorübergehende Abhilfemaßnahme hält den Angreifer davon ab, weitere Daten zu stehlen, unterbricht aber auch Anwendungen, die für ihren Betrieb Zugriff auf die Datenbank benötigen.
Schwere Sicherheitsverletzungen, bei denen ein Angreifer Ransomware einsetzt, um Daten zu verschlüsseln oder Dateien zu beschädigen, erfordern Backups und einen Datenwiederherstellungsplan. Selbst in großen Unternehmen können Wiederherstellungspläne versagen und erfordern die Unterstützung durch externe Berater. Solange die Datenbank nicht verfügbar ist, entgehen dem Unternehmen Einnahmen durch Ausfallzeiten, die in großen Unternehmen Tausende von Dollar pro Stunde betragen können.
Die Kosten einer Datenpanne auf einem Datenbankserver hängen in hohem Maße von der Art des Angriffs, der Menge der gestohlenen Daten und der Effizienz der Reaktion auf den Vorfall ab. Ein Beispiel hierfür ist das kanadische Kreditinstitut Desjardins Group 53 Millionen Dollar aus, nachdem bei einem Datenleck personenbezogene Daten von 2,9 Millionen seiner Mitglieder offengelegt worden waren. British Airways und Marriott mussten jeweils 100 Millionen Dollar zahlen, nachdem sie im Zuge von Datenlecks gegen die Vorschriften der DSGVO (Datenschutz-Grundverordnung) verstoßen hatten.
Anfällige Datenbanksoftware muss schnell gepatcht werden
Eine Gemeinsamkeit aller CVEs, die in der MITRE-Datenbank für MySQL aufgeführt sind, besteht darin, dass jede Anwendung, die mit Schwachstellen aufgeführt ist, gepatcht werden muss. Bei den CVEs könnte es sich um Software von Drittanbietern handeln, die SQL-Injection und andere Exploits ermöglicht, oder es könnten Schwachstellen in der MySQL-Datenbank-Engine selbst gefunden werden. Sie dürfen die Anwendung des Drittanbieters nicht verwenden, aber alle Schwachstellen in der MySQL-Datenbank sollten so schnell wie möglich gepatcht werden.
Da MySQL eine so wichtige Infrastrukturkomponente ist, planen Administratoren und Datenbankadministratoren (DBAs) das Patchen oft für einen späteren Zeitpunkt. Es kann auch vorkommen, dass sie mit dem Patchen des Systems mehrere Wochen warten, damit gründliche Tests durchgeführt werden können und um Ausfallzeiten auf einem Produktionsdatenbankserver zu vermeiden. Jeder Tag, der verstreicht, bietet einem Angreifer die Möglichkeit, die ungepatchte MySQL-Server-Software auszunutzen.
Mit mehr als 1300 CVEs, Tendenz steigend, scheint es für Administratoren und DBAs ein aussichtsloser Kampf zu sein, mit dem Patching des Servers Schritt zu halten. Jede Ausfallzeit eines Produktionsservers bedeutet Produktivitäts- und Umsatzeinbußen und ist in der Regel schwer zu planen, da Administratoren die Dienste während der Geschäftszeiten nicht unterbrechen können.
Schlussfolgerung
Um Server auf dem neuesten Stand zu halten und vor den aktuellsten Sicherheitslücken zu schützen, ist der Einsatz von Live-Patching die Lösung, damit der Server kontinuierlich Updates erhält, ohne neu gestartet werden zu müssen. KernelCare+ wird in Kürze eine neue Funktion veröffentlichen, mit der Administratoren ihre Datenbankserver ohne Neustart patchen können. Mit KernelCare+ können Administratoren kostspielige Datenlecks und Ausfallzeiten vermeiden und dennoch kritische Daten schützen.