Wenn der SQL-Server versucht, das Unternehmen zu erpressen

Cyberkriminelle finden immer wieder Wege, unbemerkt in Systeme einzusteigen, um von der Ferne aus Schadcode auszuführen. Beliebt als Einstiegsluken hierfür sind beispielsweise RDP oder SSH. Nun rückt auch SQL als Zugriffsmöglichkeit in den Fokus. Ein Sophos-Honeypot konnte kürzlich einen typischen Angriff über MySQL dokumentieren. [...]

Hacker haben verschiedene Möglichkeiten, in Systeme zu gelangen. Sie können etwa Schwachstellen und Exploits für ausgeklügelte Hackerangriffe verwenden, um vorhandene Sicherheitsüberprüfungen zu umgehen und Server dazu zu bringen, Schadsoftware auszuführen. Sie können aber auch versuchen herauszufinden, wie man ohne viel Aufwand über einen offiziellen Eingang und mit offiziellen Systembefehlen illegal und unbemerkt in fremde Systeme einsteigen kann.

RDP oder SSH als „übliche“ Einstiegsluken für Remote-Hacking

Windows Remote Desktop Protocol (RDP) zum Beispiel ist eine solche beliebte Einstiegsluke für Eindringlinge – so wurde in den letzten Jahren leider immer wieder über RDP-Sicherheitslücken berichtet, die es Hackern ermöglichen, in Ihr Netzwerk zu kommen, als wären sie echte Systemadministratoren. Tatsächlich aber ging es hierbei natürlich nicht darum remote etwas zu reparieren, sondern vielmehr darum, Schaden anzurichten und für die Schadensbeseitigung einen guten Batzen Geld zu verlangen. Und RDP ist nicht der einzige beliebte Weg für Cyberkriminelle, um sich in fremde Systeme zu schleichen. Sophos hat kürzlich eine Honeypot-Studie veröffentlicht, die sich mit SSH-Angriffen beschäftigt. SSH steht dabei für Secure Shell, ein Remote-Zugriffssystem, das unter Linux und Unix noch weiterverbreitet ist als RDP unter Windows. Die Studie zeigte deutlich, wie viel Energie Cyberangreifer auch hier darauf verwenden, unbemerkt in Netzwerke zu gelangen. (Zur Studie: „Exposed: Cyberattacks on Cloud Honeypots“)

MySQL als unorthodoxes neues Einfallstor

Mittlerweile begnügen sich cyberkriminelle Angreifer jedoch nicht mehr damit, SSH und RDP als Allzwecktools zu verwenden. Es gibt viele andere Online-Dienste, die geradezu eine Einladung zum Eintreten darstellen, sobald es erst einmal gelungen ist, sich mit ihnen zu verbinden. So ist ein unsicherer MySQL–Server zum Beispiel nicht nur der potenzielle Weg zu einer Datenverletzung – er kann auch zu einer hochwirksamen (wenn auch unorthodoxen) Alternative zu RDP oder SSH werden, um Schadsoftware aus der Ferne auszuführen. Ein Honeypot der SophosLabs, der auf dem TCP-Port 3306, dem Standardzugriffsport für MySQL, installiert war, hat hierfür kürzlich ein spannendes Beispiel dokumentiert. Der Fake-Server gab sich als eine unsichere Instanz von MySQL aus, die Hacker auffinden und mit der sie sich verbinden konnten. Bei dem so erfassten SQL-basierten Angriff versuchten Angreifer, den MySQL–Server des Honeypots in einen Remote-Code-Ausführungsroboter umzuwandeln.

Sie gingen dabei folgendermaßen vor

• Sie stellten eine Verbindung zum Server her.
• Sie errieten die Anmeldeinformationen eines autorisierten Benutzers durch simples Ausprobieren und meldeten sich an.
• Es wurde eine unverdächtig aussehende Datenbanktabelle erstellt und ein Datensatz hinzugefügt, der vermeintlich aus Text besteht, tatsächlich aber eine ausführbare Windows-Datei in hexadezimaler Schreibweise ist.
• Die Angreifer dekodierten die hexadezimalen Daten und speicherten sie als lokale Datei namens cna12.dll.
• Sie wiesen den Server an, die neue DLL als MySQL-Plugin, bekannt als User Defined Function (UDF), zu laden,
• Sie riefen eine Funktion im neuen Plugin auf, um Malware über HTTP zu laden und auszuführen.

Den Angreifern war es also gelungen, mithilfe des offiziellen UDF-Plug-in-Systems von MySQL, mit dem zusätzliche Funktionen in den Server integriert werden können, MySQL für eine Codeausführung von Remote-Standorten aus zu verwenden. Wäre der Angriff ausgeklügelter gewesen als er tatsächlich war – so bemerkten die Gauner nämlich nicht, dass der Honeypot unter Linux lief, sie aber ausführbaren Code hochgeladen hatten, der speziell für die Windows-Version von MySQL bestimmt war – hätten sie mit ihrem Angriff eine Ransomware namens GandCrab auslösen können.

Wie kann man sich gegen solche Angriffe schützen?

Der massive weltweite Ausbruch des SQL Slammer-Virus im Jahr 2003 hätte eigentlich lehren sollen, SQL-Server besser vom Internet zu isolieren. Zudem ist das Missbrauchspotenzial der UDF-Funktion von MySQL etwa ebenso lange und gut dokumentiert. Die Tatsache, dass trotzdem immer noch unkomplizierte, automatisierte Einbruchsversuche über internetfähige SQL-Ports erfasst werden können, zeigt, dass tatsächlich immer noch alte Fehler gemacht werden.

Das kann zur Sicherheit getan werden

• Sicherstellen, dass SQL-Server nicht direkt aus dem Internet erreichbar sind. Wenn ja, ist das mit ziemlicher Sicherheit ein Versehen. Wenn es kein Fehler ist, ist es unbedingt ratsam einen anderen Weg zu finden, um aus der Ferne auf sie zuzugreifen. Eine Möglichkeit ist es, stattdessen ein VPN oder SSH als ersten Einstiegspunkt zu verwenden, und für alle Benutzer eine Zwei-Faktor-Authentifizierung einzurichten.
• Die richtigen Passwörter. Der hier beschriebene Angriff kann von einem nicht authentifizierten Benutzer nicht durchgeführt werden, also besser kein Risiko mit schwachen Passwörtern eingehen. Auch wenn der SQL-Server nur intern zugänglich ist, ist es besser, dass sich nicht einfach jeder anmelden kann, insbesondere nicht als privilegierter Benutzer.
• Überprüfung der MySQL-Zugriffskontrolleinstellungen. Nur Benutzer mit INSERT-Rechten in die zentrale mysql-Datenbank können neue UDFs laden, so dass jeder, der diesen Angriff starten könnte, bereits genügend Rechte hat, um viele andere schlechte Dinge zu tun. (Es wäre schön, die Option zu haben, UDFs auszuschalten, wenn man sie nie benutzt, aber es gibt keinen Weg, das zu tun. Der einzige Trick, den wir anwenden können, um das Laden von UDFs zu verhindern, ist, eine eigene statisch verknüpfte Version von mysqld aus dem Quellcode zu erstellen.)
• Penetrationstests. Es lohnt sich immer zu überprüfen, ob Verteidigungsstrategien richtig angewendet werden. Fehler passieren, und wenn man sich nicht selbst um sie kümmert, wird es womöglich jemand anderes tun.

*Michael Veit ist Security-Experte bei Sophos.