Wegen vieler Termine komme ich erst heute dazu auf die neue Beschreibung von JTL hinzuweisen: In der Standard-Installation von Wawi-Full wird ein SQL Server 2005 mit einem festen Passwort vergeben, dass im Internet veröffentlicht wurde. Bislang musste der SysAdmin für den laufenden Betrieb der Anwendung verwendet werden. Das ist nun nicht mehr nötig.
Folge Schritte zur Absicherung des System sind nun möglich:
- Passwort des Benutzers "sa" ändern oder besser einen anderen SysAdmin-Benutzer einrichten (besser mit Windows-Authentifizierung) und den sa-Benutzer disablen. In höheren Versionen kann man den "sa" auch löschen.
- Einen DB-Administrator anlegen und den für den Zugriff mittels JTL-WAWI eintragen (–> Anleitung von JTL)
Für das JTL-WAWI muss nun nicht mehr mit dem SysAdmin-Benutzer "sa" gearbeitet werden.
Was ist der Unterschied zwischen einem SysAdmin und einem Datenbank-Admin (eigentlich "DBOwner")?
Sollte das Kennwort des SysAdmins "sa" erspäht werden, dann kann der Angreifer (z.B. ein böswilliger Mitarbeiter) alle Daten in allen Datenbanken des SQL Servers lesen und manipulieren. Er kann außerdem über verschiedene eXtended Procedures den File-Server übernehmen, weil der SQL Server in der oben beschriebenen Installation im Systemkontext ausgeführt wird. Der Prozess hat daher Admin-Rechte am Server.
Die Rechte eines DB-Admin (eigentlich "DbOwner") sind zwar immer noch weitreichend. Er kann ebenso wie der SysAdmin die Daten in der betroffenen Datenbank lesen und manipulieren, z.B. die Tabelle mit den Benutzern und dessen Passwörtern. Beide können Datenbank-Objekte löschen oder erweitert: komplette Tabellen, Prozeduren, … Der DB-Admin bietet aber keine Möglichkeit aus dem SQL Server auszubrechen (wenigstens ist mir keine bekannt). Außerdem sind die anderen Datenbanken vor ihm sicher.
Daher ist es zwar nicht das Optimum, aber ein erheblicher Schritt in Richtung Sicherheit, wenn für den laufenden Betrieb ein DB-Admin genutzt wird. Daher ist es empfehlenswert der Anleitung zu folgen.
Hinweis zu den Voraussetzungen für einen Angriff
Mails entnehme ich, dass immer noch einige Entwickler denken, dass man unter Windows zum Debuggen Administrator-Rechte benötigt. Wenn man das annimmt, dann kommt man freilich bei der Einschätzung von potentiellen Sicherheitslücken zu anderen Ergebnissen als ich. Offenbar reichte mein Hinweis nicht aus, um die eigene Meinung praktisch zu überprüfen. Daher schaue ich zu, dass ich mal eine kleine, aber ungefährliche Anleitung poste, wie man auch ohne Admin-Rechte debuggen kann.
"Debuggen" nennt man das detaillierte, schrittweise Beobachten einer Anwendung. Dabei kann man die einzelnen Maschinenbefehle der betreffenden Anwendung schrittweise oder auch wie im Kino untersuchen. Dazu muss der Angreifer Maschinensprache können, also typischerweise Informatiker sein und/oder Hacker. Die gleichen Mechanismen (allerdings nicht so tiefgehend) nutzen sogenannte "Tracer": sie protokollieren Aktionen mit, meist auf Funktionsebene sogenannter API-Schnittstellen. Die Ausgaben sind sehr viel leichter zu verstehen, mit einer guten Anleitung oder einem komfortablen Tracer könnte auch ein Laie hier brauchbare Informationen herausholen.
Wo man debuggen kann, da kann man auch tracen, umgekehrt nicht unbedingt. Daher ist die Frage so wichtig, ob ein normaler Benutzer debuggen kann. Bis ich zu einer Anleitung komme, können die Gläubigen der Windows-Security das ja einfach mal ausprobieren… 😉
Update 3.2.2013: Die angesprochene Anleitung steht nun zur Verfügung.