{"id":6923,"date":"2012-11-15T20:06:05","date_gmt":"2012-11-15T19:06:05","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/?p=6923"},"modified":"2012-11-17T18:01:15","modified_gmt":"2012-11-17T17:01:15","slug":"jtl-wawi-und-das-veroffentlichte-sa-passwort","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2012\/11\/15\/sql-talk\/sql-server\/jtl-wawi-und-das-veroffentlichte-sa-passwort","title":{"rendered":"JTL-Wawi und das ver&#246;ffentlichte SA-Passwort"},"content":{"rendered":"<p><img decoding=\"async\" loading=\"lazy\" src=\"http:\/\/www.glorf.it\/blog\/wp-content\/uploads\/2011\/11\/Analyse-Lupe-300px.jpg\" alt=\"\" title=\"Analyse Lupe 300px\" width=\"300\" height=\"198\" class=\"alignright size-full wp-image-6550\" \/>Durch die installation der Software JTL-Wawi-Full holt man sich ein gravierendes Sicherheitsproblem aufs System, wenn man einfach nur die Standard-Installation gem&#228;&#223; <a href=\"http:\/\/wiki.jtl-software.de\/index.php?title=Kategorie:JTL-Wawi:Installation\">Anleitung<\/a> durchf&#252;hrt: Man hat dann einen SQL Server 2005 SP2 (Express Edition), der im Systemkontext l&#228;uft und ein <strong>fest vorgegebenes SA-Passwort<\/strong> hat. Das SA-Kennwort steht zudem &#246;ffentlich in der erw&#228;hnten Anleitung.<\/p>\n<p><strong>Warum ist das ein Problem?<\/strong><\/p>\n<p>Der SQL Server-Dienst l&#228;uft im Systemkontext. Alle Aktionen, die &#252;ber ihn ausgef&#252;hrt werden, haben daher potentiell Windows-Admin-Rechte. Die installierte SQL-Server-Instanz hei&#223;t auch auf jedem System gleich und der Kunde wird angeleitet den n&#246;tigen Port in der Firewall freizugeben. Daher kann jeder drittklassige Hacker sich &#252;ber die g&#228;ngigen Ports mit dem SQL Server als SysAdmin verbinden (Instanzname, Name des SA und dessen Passwort sind ja gut dokumentiert).<\/p>\n<p>Damit kann der Angreifer allerlei Schabernack anstellen:<\/p>\n<ul>\n<li>Er kann alle Daten &#228;ndern und l&#246;schen.<\/li>\n<li>Er kann sogar den Gastrechner komplett &#252;bernehmen: heimlich oder destruktiv. Dem Angreifer sind im Prinzip keine Grenzen gesetzt.<\/li>\n<li>Er kann beispielsweise Windows-Benutzer mit Windows-Admin-Rechten anlegen,<\/li>\n<li>Software aus dem Internet nachladen und installieren oder<\/li>\n<li>einfach nur zerst&#246;rerisch wirken (Festplatten formatieren, &#8230;).<\/li>\n<\/ul>\n<p>Leider ist es f&#252;r einen Anwender fast unm&#246;glich alle L&#252;cken zu stopfen, weil laut Anleitung der <a href=\"http:\/\/wiki.jtl-software.de\/index.php?title=Kategorie:JTL-Wawi:Installation#erweiterte_ODBC_Einstellung\">SA f&#252;r die normale Arbeit der Anwendung<\/a> genutzt  wird. Offensichtlich gibt es kein SQL-Benutzer- und -Rechtekonzept. Ein verantwortungsvoller Admin m&#252;sste in der Datenbank selber eine Gruppe mit den n&#246;tigen Rechten anlegen. Dazu muss er per Try&#038;Error ausprobieren, welche Rechte auf welche Objekte im laufenden Betrieb mindestens ben&#246;tigt werden. In der Anwendungsdatenbank &quot;eazybusiness&quot; sind jedenfalls keine Rollen oder Benutzer angelegt und damit auch keine dedizierten Rechte.<\/p>\n<p><strong>Was jetzt?<\/strong><\/p>\n<p>Weil die oben genannten Angriffspunkte von dem Hersteller ganz unschuldig bereits im Internet kommuniziert wurden, hilft die &#252;bliche Geheimhaltung auch nicht mehr weiter. Au&#223;erdem machte einer der Gesch&#228;ftsf&#252;hrer auf meinen sehr ausf&#252;hrlichen Hinweis hin deutlich, dass er seine Firma hier nicht in der Pflicht sieht. Aus seiner Sicht k&#246;nnen sie den Admin nicht ersetzen. Das verstehe ich so, dass der Admin des jeweiligen Kunden daf&#252;r verantwortlich sei die problematische Installation zu erkennen und Gegenma&#223;nahmen zu treffen. Als Beispiel wird in der Mail das &#196;ndern des SA-Passwortes genannt. Immerhin wurde daraufhin eine Woche sp&#228;ter, am 12.11.2012, ein entsprechender <a href=\"http:\/\/wiki.jtl-software.de\/index.php?title=Kategorie:JTL-Wawi:Installation#Datenbankserver\">Hinweis in die Anleitung<\/a> aufgenommen (vorher fand ich das auf deren Web-Seite nur tief vergraben in der FAQ): <\/p>\n<blockquote><p>F&#252;r maximale Sicherheit sollte auf jeden Fall das Standard Datenbankpasswort &quot;[Anm.: Passwort entfernt]&quot; ge&#228;ndert werden.<\/p><\/blockquote>\n<p>Au&#223;erdem solle &#8211; laut dem neuen Hinweis &#8211; der Zugriff via Firewall auf bestimmte Clients eingeschr&#228;nkt werden. Aus meiner Sicht ist das aber eher die minimale Sicherheit, nicht die maximale &#8230;<\/p>\n<p>Die Antwort der Firma n&#246;tigte mir Respekt vor deren Kunden ab. Nur wenige Admins, die ich kenne, haben die n&#246;tigen Kenntnisse, um die minimalen Rechte zu erforschen (z.B. mit Profiler) und zu vergeben. Au&#223;erdem ist das Benutzerkonzept des SQL Servers nicht gerade trivial. Ich w&#228;re froh, wenn unsere Kunden alle solche Admins h&#228;tten, die mit SQL-Experten mithalten k&#246;nnen. Normale Anwender w&#228;ren damit jedenfalls hoffungslos &#252;berfordert.<br \/>\nAnhand der Beitr&#228;ge in den Foren kann man erkennen, dass aber nicht alle Kunden derartig gut ausgebildete Admins haben, sondern sich sogar f&#252;r einfache Dinge wie Backups durchwurschteln und bei der Problembeschreibung deren Batches inkl. SA&#038;Passwort ins Forum stellen. Daher d&#252;rften diese Kunden vom Anspruch des Herstellers &#252;berfordert werden, die Probleme alleine zu erkennen und zu l&#246;sen. Ich finde es schade, dass diese Kunden mit den durch die Standard-Installation verursachten gravierenden Sicherheitsproblemen alleine gelassen werden. <\/p>\n<p>Wenn man lange sucht, findet man einzig den Hinweis, wie man das <a href=\"http:\/\/wiki.jtl-software.de\/index.php?title=Kategorie:JTL-Wawi:Hinweise_FAQ#Datenbankpasswort_.C3.A4ndern\">SA-Passwort &#228;ndert<\/a>. Direkt darunter steht &#252;brigens aus welcher Tabelle man die Namen und Passw&#246;rter der Anwendungsbenutzer im Klartext auslesen kann, die f&#252;r die Anmeldung am System genutzt werden. Kein Witz.<\/p>\n<p><strong>Welche Ma&#223;nahmen w&#228;ren aus meiner Sicht f&#252;r eine minimale Sicherheit des SQL Servers n&#246;tig?<\/strong><\/p>\n<ul>\n<li>Der Hersteller sollte in der Installation des SQL Server kein festes SA-Kennwort mehr vergeben. Au&#223;erdem eine Anleitung ver&#246;ffentlichen, wie bestehende Kunden die gemischte Authentifizierung nachtr&#228;glich ausschalten k&#246;nnen.<\/li>\n<li>Wenn f&#252;r den Admin die Windows-Authentifizierung genutzt wird, dann kann man sich das ganze Theater mit dem &#246;ffentlichen SA-Passwort sparen. Alle Batches k&#246;nnen wir bisher ver&#246;ffentlicht werden ohne das Schaden entsteht. <\/li>\n<li>Au&#223;erdem sollten mit der Datenbank die ben&#246;tigten Gruppen und User bereits angelegt werden oder wenigstens entsprechende Skripte ver&#246;ffentlicht werden. Die Doku sollte beschreiben, wie man einen  Windows-Benutzer f&#252;r die Anwendung im SQL Server anlegen kann, dass der Zugriff m&#246;glich ist. Dann muss kein SQL-SysAdmin f&#252;r den laufenden Betrieb genutzt werden.<\/li>\n<\/ul>\n<p>Als K&#252;r k&#228;me dann noch ein echtes Benutzerkonzept mit einer dedizierten Rechtevergabe. Offenbar gibt es schon die M&#246;glichkeit im System Benutzer anzulegen. Wenn die Benutzer nur auf Views zugreifen d&#252;rften, die deren Rechte gegen eine Rechtetabelle pr&#252;fen, dann w&#228;re das nochmal erheblich n&#228;her an einem sicheren System.<\/p>\n<p><strong>Warum reicht es nicht aus, einfach nur das SA-Passwort zu &#228;ndern?<\/strong><\/p>\n<p>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&#228;hen. (Nein, eine Anleitung werde ich nicht geben.)<br \/>\nSo (oder, falls er es umst&#228;ndlich mag, mit einer der &#252;blichen Injection-Attacken) k&#246;nnte ein Mitarbeiter den Server &#252;bernehmen oder einfach nur l&#246;schen. Das gilt freilich auch f&#252;r Remote-Angriffe via Trojaner oder pr&#228;parierte Webseiten.<br \/>\nAber auch das ist nicht wirklich n&#246;tig, weil die Zugangsdaten (ODBC-DSN, User und Passwort) in der Registry unter HKCU gespeichert werden, immerhin leicht verschl&#252;sselt. Ich habe kurz &#252;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&#246;glichkeiten gibt&#8230;<\/p>\n<p><strong>Welche Sofortma&#223;nahmen w&#228;ren f&#252;r betroffene Nutzer sinnvoll?<\/strong><\/p>\n<p>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&#252;hrliche Anleitung gibt, wie der Kunde den SA disablen und Windows-Authentifizierung nutzen kann. Dazu kann man unter &quot;Dienste&quot; auf den Dienst &quot;SQL Server (JTLWAWI )&quot; rechtsklicken und in den Eigenschaften den Starttyp &quot;Deaktiviert&quot; konfigurieren.<\/p>\n<p>Wenn er SQL-m&#228;&#223;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&#246;tigten Tabellen &#228;ndern d&#252;rfen, nicht aber Admin-Rechte haben (auch nicht DBO). Sie m&#252;ssen auch sehr lange PAssw&#246;rter haben, um Brute-Force-Attacken zu bestehen (>20 Zeichen). Dazu ist der Einsatz des <a href=\"http:\/\/www.microsoft.com\/de-de\/download\/details.aspx?id=8961\">SQL Server Management Studio Express<\/a> 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&#246;tigten Rechte erforschen. Dabei k&#246;nnte es man bemerken, dass manche Funktionen nicht klappen, falls diese doch SysAdmin-Rechte ben&#246;tigen. <\/p>\n<p>Wer rettet die unkundigen Betroffenen?<\/p>\n<p>Der <a href=\"http:\/\/wiki.jtl-software.de\/index.php?title=Kategorie:JTL-Wawi:Installation#.C3.9Cbersicht_der_Downloadpakete\">Download<\/a> der Software ist frei. Es ist Freeware, aber offenbar nicht Open Source. Was hei&#223;t das in Bezug auf Sicherheit? Einem geschenktem Gaul schaut man nicht ins Maul?<br \/>\nWer sich fragt, wovon die Firma lebt, wenn sie die Software verschenken: Sie verkaufen Zusatzmodule unter dem Motto &quot;Professionelle Softwarel&#246;sungen f&#252;r Ihren Erfolg im E-Business&quot;. Den Spruch finde ich unter den gegebenen Umst&#228;nden beachtlich.<\/p>\n<p>Naja, durch den kostenlosen Download kann das immerhin jeder von Euch selber nachschauen. Bei dem Paket &quot;<a href=\"http:\/\/www.jtl-software.de\/downloads\/?dp=13&#038;new=1\">JTL-Wawi-Full<\/a>&quot; 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&#246;chte, kann ja mal erforschen, was zur tats&#228;chlichen &quot;maximalen Sicherheit&quot; n&#246;tig w&#228;re und die Skripten dort im Forum ver&#246;ffentlichen. Es schaut nicht so aus, als ob die Firma das machen w&#252;rde. Wobei mir unklar ist, warum sie die Situation so gelassen sehen. Meine Warnung hat daran nur wenig ge&#228;ndert.<\/p>\n<p>Freiwillige vor&#8230; Das w&#228;re auf jeden Fall eine gute Tat.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Durch die installation der Software JTL-Wawi-Full holt man sich ein gravierendes Sicherheitsproblem aufs System, wenn man einfach nur die Standard-Installation gem&#228;&#223; Anleitung durchf&#252;hrt: Man hat dann einen SQL Server 2005 SP2 (Express Edition), der im Systemkontext l&#228;uft und ein fest vorgegebenes SA-Passwort hat. Das SA-Kennwort steht zudem &#246;ffentlich in der erw&#228;hnten Anleitung. Warum ist das [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[19,16],"tags":[891,779,591],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/6923"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=6923"}],"version-history":[{"count":50,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/6923\/revisions"}],"predecessor-version":[{"id":6972,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/6923\/revisions\/6972"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=6923"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=6923"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=6923"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}