Durch die installation der Software JTL-Wawi-Full holt man sich ein gravierendes Sicherheitsproblem aufs System, wenn man einfach nur die Standard-Installation gemäß Anleitung durchführt: Man hat dann einen SQL Server 2005 SP2 (Express Edition), der im Systemkontext läuft und ein fest vorgegebenes SA-Passwort hat. Das SA-Kennwort steht zudem öffentlich in der erwähnten Anleitung.
Warum ist das ein Problem?
Der SQL Server-Dienst läuft im Systemkontext. Alle Aktionen, die über ihn ausgeführt werden, haben daher potentiell Windows-Admin-Rechte. Die installierte SQL-Server-Instanz heißt auch auf jedem System gleich und der Kunde wird angeleitet den nötigen Port in der Firewall freizugeben. Daher kann jeder drittklassige Hacker sich über die gängigen Ports mit dem SQL Server als SysAdmin verbinden (Instanzname, Name des SA und dessen Passwort sind ja gut dokumentiert).
Damit kann der Angreifer allerlei Schabernack anstellen:
- Er kann alle Daten ändern und löschen.
- Er kann sogar den Gastrechner komplett übernehmen: heimlich oder destruktiv. Dem Angreifer sind im Prinzip keine Grenzen gesetzt.
- Er kann beispielsweise Windows-Benutzer mit Windows-Admin-Rechten anlegen,
- Software aus dem Internet nachladen und installieren oder
- einfach nur zerstörerisch wirken (Festplatten formatieren, …).
Leider ist es für einen Anwender fast unmöglich alle Lücken zu stopfen, weil laut Anleitung der SA für die normale Arbeit der Anwendung genutzt wird. Offensichtlich gibt es kein SQL-Benutzer- und -Rechtekonzept. Ein verantwortungsvoller Admin müsste in der Datenbank selber eine Gruppe mit den nötigen Rechten anlegen. Dazu muss er per Try&Error ausprobieren, welche Rechte auf welche Objekte im laufenden Betrieb mindestens benötigt werden. In der Anwendungsdatenbank "eazybusiness" sind jedenfalls keine Rollen oder Benutzer angelegt und damit auch keine dedizierten Rechte.
Was jetzt?
Weil die oben genannten Angriffspunkte von dem Hersteller ganz unschuldig bereits im Internet kommuniziert wurden, hilft die übliche Geheimhaltung auch nicht mehr weiter. Außerdem machte einer der Geschäftsführer auf meinen sehr ausführlichen Hinweis hin deutlich, dass er seine Firma hier nicht in der Pflicht sieht. Aus seiner Sicht können sie den Admin nicht ersetzen. Das verstehe ich so, dass der Admin des jeweiligen Kunden dafür verantwortlich sei die problematische Installation zu erkennen und Gegenmaßnahmen zu treffen. Als Beispiel wird in der Mail das Ändern des SA-Passwortes genannt. Immerhin wurde daraufhin eine Woche später, am 12.11.2012, ein entsprechender Hinweis in die Anleitung aufgenommen (vorher fand ich das auf deren Web-Seite nur tief vergraben in der FAQ):
Für maximale Sicherheit sollte auf jeden Fall das Standard Datenbankpasswort "[Anm.: Passwort entfernt]" geändert werden.
Außerdem solle – laut dem neuen Hinweis – der Zugriff via Firewall auf bestimmte Clients eingeschränkt werden. Aus meiner Sicht ist das aber eher die minimale Sicherheit, nicht die maximale …
Die Antwort der Firma nötigte mir Respekt vor deren Kunden ab. Nur wenige Admins, die ich kenne, haben die nötigen Kenntnisse, um die minimalen Rechte zu erforschen (z.B. mit Profiler) und zu vergeben. Außerdem ist das Benutzerkonzept des SQL Servers nicht gerade trivial. Ich wäre froh, wenn unsere Kunden alle solche Admins hätten, die mit SQL-Experten mithalten können. Normale Anwender wären damit jedenfalls hoffungslos überfordert.
Anhand der Beiträge in den Foren kann man erkennen, dass aber nicht alle Kunden derartig gut ausgebildete Admins haben, sondern sich sogar für einfache Dinge wie Backups durchwurschteln und bei der Problembeschreibung deren Batches inkl. SA&Passwort ins Forum stellen. Daher dürften diese Kunden vom Anspruch des Herstellers überfordert werden, die Probleme alleine zu erkennen und zu lösen. Ich finde es schade, dass diese Kunden mit den durch die Standard-Installation verursachten gravierenden Sicherheitsproblemen alleine gelassen werden.
Wenn man lange sucht, findet man einzig den Hinweis, wie man das SA-Passwort ändert. Direkt darunter steht übrigens aus welcher Tabelle man die Namen und Passwörter der Anwendungsbenutzer im Klartext auslesen kann, die für die Anmeldung am System genutzt werden. Kein Witz.
Welche Maßnahmen wären aus meiner Sicht für eine minimale Sicherheit des SQL Servers nötig?
- Der Hersteller sollte in der Installation des SQL Server kein festes SA-Kennwort mehr vergeben. Außerdem eine Anleitung veröffentlichen, wie bestehende Kunden die gemischte Authentifizierung nachträglich ausschalten können.
- Wenn für den Admin die Windows-Authentifizierung genutzt wird, dann kann man sich das ganze Theater mit dem öffentlichen SA-Passwort sparen. Alle Batches können wir bisher veröffentlicht werden ohne das Schaden entsteht.
- Außerdem sollten mit der Datenbank die benötigten Gruppen und User bereits angelegt werden oder wenigstens entsprechende Skripte veröffentlicht werden. Die Doku sollte beschreiben, wie man einen Windows-Benutzer für die Anwendung im SQL Server anlegen kann, dass der Zugriff möglich ist. Dann muss kein SQL-SysAdmin für den laufenden Betrieb genutzt werden.
Als Kür käme dann noch ein echtes Benutzerkonzept mit einer dedizierten Rechtevergabe. Offenbar gibt es schon die Möglichkeit im System Benutzer anzulegen. Wenn die Benutzer nur auf Views zugreifen dürften, die deren Rechte gegen eine Rechtetabelle prüfen, dann wäre das nochmal erheblich näher an einem sicheren System.
Warum reicht es nicht aus, einfach nur das SA-Passwort zu ändern?
Der Anwender startet die Anwendung bei sich lokal auf dem PC. Wenn die Anwendung generell mit SysAdmin-Rechten arbeitet, dann kann man mit idiotensicheren Werkzeugen das Passwort des SA ausspähen. (Nein, eine Anleitung werde ich nicht geben.)
So (oder, falls er es umständlich mag, mit einer der üblichen Injection-Attacken) könnte ein Mitarbeiter den Server übernehmen oder einfach nur löschen. Das gilt freilich auch für Remote-Angriffe via Trojaner oder präparierte Webseiten.
Aber auch das ist nicht wirklich nötig, weil die Zugangsdaten (ODBC-DSN, User und Passwort) in der Registry unter HKCU gespeichert werden, immerhin leicht verschlüsselt. Ich habe kurz überlegt, ob ich mal mit einem API-Tracer schaue, ob ich sehe, welche Methoden genutzt werden, aber dazu hatte ich dann keine Lust, weil es einfachere Möglichkeiten gibt…
Welche Sofortmaßnahmen wären für betroffene Nutzer sinnvoll?
Ein Nutzer ohne tiefe SQL-Kenntnisse hat in meinen Augen keine Chance das System effektiv abzusichern. Daher sollte er sofort den SQL Server-Dienst deaktivieren, bis es eine ausführliche Anleitung gibt, wie der Kunde den SA disablen und Windows-Authentifizierung nutzen kann. Dazu kann man unter "Dienste" auf den Dienst "SQL Server (JTLWAWI )" rechtsklicken und in den Eigenschaften den Starttyp "Deaktiviert" konfigurieren.
Wenn er SQL-mäßig fit ist, dann muss er wenigstens den SA disablen (oder umbenennen oder gigantsich langes Passwort geben) und andere SQL-Benutzer anlegen, die nur die Werte in den benötigten Tabellen ändern dürfen, nicht aber Admin-Rechte haben (auch nicht DBO). Sie müssen auch sehr lange PAsswörter haben, um Brute-Force-Attacken zu bestehen (>20 Zeichen). Dazu ist der Einsatz des SQL Server Management Studio Express zu empfehlen. Besser sollte er die Vollversion des SQL Servers kaufen, dann kann er mit dem SQL Profiler die Anwendung aufzeichnen und dann damit die benötigten Rechte erforschen. Dabei könnte es man bemerken, dass manche Funktionen nicht klappen, falls diese doch SysAdmin-Rechte benötigen.
Wer rettet die unkundigen Betroffenen?
Der Download der Software ist frei. Es ist Freeware, aber offenbar nicht Open Source. Was heißt das in Bezug auf Sicherheit? Einem geschenktem Gaul schaut man nicht ins Maul?
Wer sich fragt, wovon die Firma lebt, wenn sie die Software verschenken: Sie verkaufen Zusatzmodule unter dem Motto "Professionelle Softwarelösungen für Ihren Erfolg im E-Business". Den Spruch finde ich unter den gegebenen Umständen beachtlich.
Naja, durch den kostenlosen Download kann das immerhin jeder von Euch selber nachschauen. Bei dem Paket "JTL-Wawi-Full" wird die SQL Server 2005 Express Edition mit besagter Konfiguration mitgebracht, seltsamerweise nicht die Ausgabe mit erweiterten Diensten (also mit Management Studio Express). Wer sich Lorbeeren verdienen möchte, kann ja mal erforschen, was zur tatsächlichen "maximalen Sicherheit" nötig wäre und die Skripten dort im Forum veröffentlichen. Es schaut nicht so aus, als ob die Firma das machen würde. Wobei mir unklar ist, warum sie die Situation so gelassen sehen. Meine Warnung hat daran nur wenig geändert.
Freiwillige vor… Das wäre auf jeden Fall eine gute Tat.
