Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

30. November 2012 um 17:17

SQL Server Management Studio mit Parametern starten

Auf meinem Privatrechner mag ich den SQL Server nicht dauernd laufen haben. Daher richtete ich einen Batch ein, der den SQL-Browser, den SQL Server und das SQL-Server-Managment-Studio (SSMS) auf einen Schlag startet.
Dabei kann man dem Management-Studio mittels Parametern sagen, zu welchem Server er sich verbinden soll:
"C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe" -S MYPC\SQL2012 -E -nosplash
Man könnte hier auch Username/Passwort (-U und -P) angeben, aber das würde ich eher nicht in einen Batch schreiben.

26. November 2012 um 15:31

Geschenke zu Weihnacht

… kurbeln die Wirtschaft an. Und sonst? Sonst offenbar nicht viel, wenn man dem Sketch von Ralph Ruthe glauben mag:

25. November 2012 um 13:11

Michael Davis jongliert

Alt, aber immer wieder gut…

24. November 2012 um 15:12

Was weißt Du über Afrika?

Tatsächlich basieren viele Bilder in der Köpfen der Menschen auf den Bildern, die durch Spendenaufrufe verbreitet werden. Das stört einige Afrikaner so sehr, dass sie dagegen ein Video gedreht haben. Darin werden die Afrikaner aufgerufen Heizkörper für Norwegen zu spenden. Das Video ist ein Selbsttest: Was würdest Du über Norwegen denken, wenn Du vorwiegend solche Videos sehen würdest?

Die Macher erklären die Details und Hintergründe hier (englisch).
Spiegel.de hat auch schon darüber geschrieben (deutsch).

24. November 2012 um 12:56

Auch die Zukunft war früher schon mal besser

… soll Carl Valentin so oder ähnlich mal gesagt haben. Das hörte ich neulich zumindestens. Daher sprach mich das Video von Dr. Allwissend mit dem Titel "Früher war alles viel besser" besonders an:

21. November 2012 um 21:33

Druckfahne für SQL-Thinking

Heute erklärte mir meine Tochter, die in der 9ten Klasse ein Praktikum beim Erlangen Michael Müller-Verlag machen durfte, warum die zwei Versionen von PDFs, die ich letzten Freitag und gestern bekam, Satzfahnen heißen: Die werden wohl auf großen Bögen gedruckt, die erst danach geschnitten werden. Und dann sehen die Dinger offenbar wie Fahnen aus.

Naja, jedenfalls waren die Anhänge im zweiten Anlauf auch im Buch drin. Weitere Infos werde ich aus die neue Seite zum Buch stellen, die ich am Wochenende aufgebaut habe: http://sql-thinking.de

21. November 2012 um 21:23

Der wiederkehrende Absturz des Thunderbird 17

… trieb mich fast in den Wahnsinn. Jedesmal bei Schreiben einer Mail stürzte Thunderbird nach dem heutigen Update auf Version 17 ab. Erst als ich das Add-In QuickText deaktivierte, hatte ich Ruhe. Eine Internet-Recherche ergab, dass ich da wohl nicht der einzige war…

17. November 2012 um 11:02

Gib der Zukunft eine Chance, verwende das Futur

… schreibt mein Kollege Clemens seit einiger Zeit in seiner E-Mail-Signatur. Er hat festgestellt, dass es für die eigene Einstellung und für das Herangehen an Dinge einen Unterschied macht, wie man sich sich ausdrückt, weil das Ausdrücken die eigene Haltung und die der Zuhörer beeinflusst. Er hat das auch irgendwo gehört oder gelesen. Ich habe vergessen wo.

Hier ein Beispiel für eine geläufige Ausdrucksweise:

Wir müssen unbedingt die Performance von Anfang an bei dem Release 1.0 berücksichtigen.

Was passiert mit mir, wenn ein Kollege zu mir kommt und das so ausrückt? Das ist Druck, deutet aus ein Problem hin und auf (innere?) Widerstände. Wenn wir das wirklich ernst meinen, dann können wir uns etwas von dem inneren Druck nehmen.

Wenn wir das hingegen auf die Zukunft ausrichten, dann schauen wir nach vorne:

Wir werden die Performance von Anfang an bei dem Release 1.0 berücksichtigen.

Das drückt eine Haltung aus, keinen Zwang. Natürlich löst sich die Aufgabe dadurch nicht einfacher, aber die Haltung ändert sich in meinen Augen wirklich. Auch das Empfinden Zuhörer ist leicht anders.

Zwei andere Beispiele, die sich vorwiegend auf den Sprecher beziehen:

  • Ich muss noch den Tabellen-Entwurf des neuen Moduls beenden, bevor ich die Indexe für das Auswertungsmodul überprüfen kann.
  • Ich werde erst den Tabellen-Entwurf des neuen Moduls beenden, danach werde ich die Indexe für das Auswertungsmodul überprüfen.

Vielleicht haltet Ihr mich für verrückt, aber für mich macht das einen deutlichen Unterschied. Daher werde ich zukünftig das Futur öfter verwenden. Mal schauen, ob es sich bewährt … 😉

Disclaimer: Genau wie bei guten Vorsätzen ist es auch hier wichtig das ernst zu meinen und zu tun. Damit ist nicht gemeint, dass über die Aussage vorher und nachher nicht mehr diskutiert werden darf. Es darf und sollte weiterhin diskutiert, geplant und priorisiert werden. Es verschiebt lediglich den Blick von Problem/Zwang hin zu Zukunft/Vorsatz.

16. November 2012 um 19:17

Gängige Schwachstellen in Software

Die Liste der bekannten Sicherheitsprobleme (Common Vulnerabilities and Exposures, CVE) von erhältlicher Software kannte ich schon, aber erst kürzlich erfuhr ich, dass es auch konkrete Tipps gibt, was man besser nicht in seiner Anwendung falsch machen sollte: Common Weakness Enumeration (CWE).

Die seite enthält eine sehr große Anzahl von gängigen Schwachstellen und Tipps, wie man es besser machen kann. Leider ist die Seite ausgesprochen unübersichtlich. Hier ein paar gute Einstiegspunkte:

Wenn ich mal viel Zeit habe, dann lese ich das alles durch….

16. November 2012 um 06:05

kostenloses eBook: SQL Server 2012 Transact-SQL DML Reference

Wer die Transact-SQL Data Manipulation Language (DML) Reference schon immer mal gerne als eBook haben wollte, der kann nun zugreifen:

Es enthält wirklich (einfach nur) den Text aus den Books Online. Aber halt als eBook zum mitnehmen.

15. November 2012 um 20:06

JTL-Wawi und das veröffentlichte SA-Passwort

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.

15. November 2012 um 06:24

kostenloses eBook: Introducing Microsoft SQL Server 2012

Wer sich für den SQL Server 2012 interessiert, der sollte das kostenlose eBook "Introducing Microsoft SQL Server 2012" mal anschauen. Erhältlich als PDF, mobi und epub (und damit auch für den Kindle geeignet).