Neu Sicherheitswarnung - Wawi Datenbank (sa) Passwort mit öffentlichem Tool entschlüsselbar

[John]

Moin,

heute wurde über einen öffentlichen Kanal ein Tool samt Quellcode durch einen Programmierer in die Welt entlassen, welches in der Lage ist, die in der Registry gespeicherten, verschlüsselten Wawi Datenbank Zugangsdaten zu entschlüsseln.
Als Konsequenz kann ein einfacher Wawi Anwender (z.B. Mitarbeiter) diese Zugangsdaten nun auslesen. Erweiterte Rechte zum Ausführen des Tools benötigt der Nutzer nicht.

Dies ist insb. dann problematisch, wenn die Datenbank Verbindung über den sa Benutzer aufgebaut wird, der Anwender aber aus Vertraulichkeitsgründen eigentlich weniger Rechte haben soll und ihm die Rechte lediglich per Wawi Rechteverwaltung zugeteilt wurden.

Mit den ausgelesenen Zugangsdaten kann man sich anschließend einfach per MS SQL Studio als sa Nutzer anmelden und hat die komplette Kontrolle über die Datenbank.

Es war bisher schon klar, dass dieses Problem theoretisch besteht, jedoch war das Wissen die Daten zu entschlüsseln nicht öffentlich verfügbar.

John

 

[recent.digital]

Danke für die Meldung. Das ist in der Tat problematisch. Eine kurzfristige Lösung gibt es wahrscheinlich aktuell nicht.

 

[recent.digital]

Kleine Ergänzung:
Das zeigt wie wichtig das Rollen-Rechte-Konzept ist.
Grundsätzlich ist es wichtig, dass niemand mit dem Admin unterwegs ist, außer er hat was zu administrieren und ist der Administrator.

 

[mh1]

Grundsätzlich sollte man den sa Login nicht auf den Client PC's speichern.
Ich würde empfehlen, einen Benutzer wawi anzulegen und diesen dann eben nicht der sysadmin Rolle hinzuzfügen, sondern diesem nur die Berechtigungen zu geben, die er braucht, um mit der Wawi zu arbeiten.

In Unternehmen, die auf dem SQL-Server auch noch andere Datenbanken haben, ist es sicherlich auch gängige Praxis, dass der sa nicht an die Anwender verteilt wird

Zur Frage nach einer kurzfristigen Lösung bzw. was tun wenn man den sa nun schon auf 72 PC's im JTL-DB-Profil eingestellt hat und die nicht alle ändern will:
Denkbar wäre, das Login sa aus der Serverrolle sysadmin zu entfernen und es nur in die für die Wawi benötigten Rollen aufzunehmen. Dann muss man aber auch unbedingt ein neues Login mit sysadmin Rechten erstellen (sonst hätte man sich ja ausgesperrt )

 

[Verkäuferlein]

Zur Frage nach einer kurzfristigen Lösung bzw. was tun wenn man den sa nun schon auf 72 PC's im JTL-DB-Profil eingestellt hat und die nicht alle ändern will:

Vielleicht könnte man (JTL ) auch eine Art "Gegentool" entwickeln, welches automatisch neue MSSQL-Zugangsdaten auf alle 72 Rechner verteilt.

Gibt es denn irgendwo ein Tutorial, welche Rechte/Rolle für den Datenbankzugriff der Wawi für den einfachen Nutzer respektive Worker erforderlich sind?

Es macht ja in dem Fall aus meiner Sicht auch Sinn, gar keiner Wawi sa als Nutzer zuzuordnen, selbst auf dem Server / Worker nicht.

Ich würde ehrlich gesagt für jeden Rechner dann einen eigenen Nutzer anlegen. Wie schaut es eigentlich bei der Verbindungsverschlüsselung zur DB aus? Auch dort ließe sich ja das Passwort sniffen/auslesen, sofern unverschlüsselt!?

P.s.: Falls Ihr noch auf der Suche nach einem sicheren Passwort seid, hier findet Ihr das sicherste Passwort 😁 : https://www.der-postillon.com/2014/04/sicherstes-passwort.html

 

[mh1]

Wie schaut es eigentlich bei der Verbindungsverschlüsselung zur DB aus? Auch dort ließe sich ja das Passwort sniffen/auslesen, sofern unverschlüsselt!?

Wenn man sich unverschlüsselt mit dem SQL-Server verbindet, kann der Sniffer den Verkehr natürlich mitlesen. Dann kann auch alles SQL im Klartext mitgelesen werden.
Nur wenn man den SQL-Server aktiv auf TLS umstellt wird TLS benutzt.
Meintest du das mit Verbindungsverschlüsselung?

 

[holzpuppe]

Es gibt wohl weniger „SA“-Nutzer als gedacht. Und weniger die ihren Mitarbeitern misstrauen. 😬
Allerdings frage ich mich, ob es wirklich nur die „SA“ betrifft, und nicht eventuell an der Kenntnis des korrekten DB-Nutzernamens liegt.
Also kennt man den Nutzernamen, kommt man auch an das Passwort?

 

[John]

Nein. Über das Tool kann man die Wawi Datenbank Verbindungsdaten (Server, Datenbannk Benutzername (z.b. sa) und Passwort) auslesen und zwar unabhängig von den Wawi Nutzernamen.
Hat man diese Daten ausgelesen, kann man sich direkt mit der Datenbank verbinden und sich zur Not selbst einen Wawi Nutzer anlegen oder das Passwort eines exisierenden Nutzers auf ein dem Angreifer bekanntes Passwort umbiegen.
Die Wawi Benutzer/Rechteverwaltung lässt sich komplett aushebeln.

Der Grund, warum das Thema hier wenige interessiert ist vermutlich, dass die allermeisten Anwender die sich bietenden Möglichkeiten und Probleme mit diesen Daten nicht abschätzen können bzw. es für Nutzer ohne tiefen Background auch keine Gegenwehr gibt.

 

[mh1]

Ich denke, dass hier im Thread und/oder vielleicht sogar bei dem ein oder anderen JTL Anwender zwei unterschiedliche Themen vermischt werden:
Das eine sind die Anmeldungen an der Wawi und das andere die Anmeldung für den SQL Server.

Das erste ist Herr Müller aus dem Verkauf und Frau Schmidt aus der Buchhaltung bzw. die x-beliebigen Mitarbeiter, die der admin in der Wawi anlegt und das Passwort fest in die Datenbank speichert.

Und das zweite ist der auf dem SQL-Server in der Datenbank angelegte User (der wiederum einem im Serverkontext angelegten Login zugeordnet wird). Hier haben die meisten JTL Anwender nur den einen Login, der der sysadmin Rolle zugewiesen ist und standarmäßig "sa" heißt.
Der SQL-Server "sieht" also in diesem Fall gar nicht, dass sich heute morgen um 8:00 Herr Müller angemeldet hat und um 8:20 Frau Schmidt. Er erkennt nur zwei Sessions vom Benutzer sa

Wenn auf dem SQL-Server sowieso ausschließlich nur die eazybusiness liegt, würd ich es nicht als kritisches Sicherheitsproblem sehen, auf den Wawi Clients im LAN den sa einzustellen.
Wenn der SQL Server aber auch noch andere unternehmenskritische Funktionen erfüllen muss (Zeiterfassung, DMS, Management/Statistik, Produktionssteuerung oder so), dann wird die IT-Abteilung den sa Benutzer nicht auf alle Clients verteilen, sondern für jede Anwendung eigene Logins und User anlegen.
Ähnlich wie beim Shared Hosting. Also ein SQL-Server auf dem mehrere JTL Datenbanken gehostet werden: Der Hoster wird auf keinen Fall jedem Kunden einen sa Zugang geben, sondern für jeden Kunden einen eigenen Login auf dem SQL-Server anlegen.

 

[JohnFrea]

@mh1 Natürlich ist das ein Sicherheitsproblem.

Wenn Herr Müller z.B. kein Wawi-Recht hat, Preise, Artikeldaten oder Bestände zu ändern oder Daten zu exportieren, so kann er dies mit den gewonnenen Login Daten zum Server ganz einfach umgehen.

Wie hier schon gesagt wurde: Das Rechtemanagement der Wawi ist ausgehebelt.

 

[mh1]

@mh1 Natürlich ist das ein Sicherheitsproblem.

ich habe nicht gesagt, dass es kein Sicherheitsproblem ist.
Ich bin auch generell der Meinung, dass Administrator Passwörter ausschließlich in die Hände von Systemadministratoren gehören.

Was ich aber geschrieben habe ist, dass ich es in der 08/15 Firma nicht als "kritisches Sicherheitsproblem" ansehen würde, wenn die Clients mit dem sa Login arbeiten.
Wenn man hier im Forum mit liest, stellt man fest, dass ein Großteil der JTL Anwender wahrscheinlich sowieso nicht wüßten, wie man sich mit einem sa Zugang am Server anmeldet und auf eine Datenbank zugreift.

Und in der Praxis kennt Herr Müller sowieso das Passwort von Frau Schmidt (wenn es nicht gerade "123", oder der Vorname ist, dann klebt höchstwahrscheinlich ein PostIt am Bildschirm 🤔 )

Wenn ich Angst haben muss, dass mein Mitarbeiter Herr Müller Daten abgreift, Bestände ändert, oder Waren aus dem Regal klaut, hab ich viel größere Porblem, an die ich ran müsste.
Und in diesem Fall gehört ein anständiges Sicherheitskonzept her (für IT Prozesse, aber auch für kohlenstoffbasierte Prozesse, Zugangskontrollen u.s.w).
Aber meiner Meinung nach, gehört das alles nicht in das JTL Forum.

 

[John]

@mh1 und was machst Du mit externen Mitarbeitern oder Dienstleistern, die z.B. nur Klickworkerei erledigen sollen und die man bisher durch nur notwendige Wawi Rechte beschränken konnte?
Die haben jetzt de facto Vollzugriff.

 

[Verkäuferlein]

Es gibt wohl weniger „SA“-Nutzer als gedacht. Und weniger die ihren Mitarbeitern misstrauen. 😬

Ehrlich gesagt würde ich mal davon ausgehen, dass wir irgendwo im 90%-Bereich liegen. Die meisten haben das irgendwann mal so installiert und verwenden sowieso auch das Standard-Passwort.

Da hat dann diese Sicherheitslücke auch keine Relevanz.

Und was hat das überhaupt mit Misstrauen gegenüber den Mitarbeitern zu tun!?
Zum einen ist der aktuelle Sicherheitsansatz "Zero Trust", also alles verbieten, was nicht zwangsläufig erlaubt sein muss.
Auch wenn man DSGVO-konform arbeiten will, sollte man ja sehr auf Datensicherheit und damit auch Nachvollziehbarkeit setzen und somit in zentralen Systemen der Datenverarbeitung auch entsprechend separierte Zugänge und Passwörter einrichten.

Es reicht ja aus, dass ein Mitarbeiter in einer e-Mail auf einen Link oder Anhang klickt und sich damit was nettes "installiert" und schon hat ein potenzieller Angreifer möglicherweise "administrativen Vollzugriff" auf die Datenbank.

Und ja, es gibt auch das Risiko von internen Angreifern (z.B. auch Besucher / Gäste).

Was ich aber geschrieben habe ist, dass ich es in der 08/15 Firma nicht als "kritisches Sicherheitsproblem" ansehen würde, wenn die Clients mit dem sa Login arbeiten.

Prinzipiell sicherlich richtig, wenn das ausgenutzt werden kann, liegt schon ein anderes Problem vor und der Falsche hat bereits Zugriff auf einen Rechner, auf den er nicht zugreifen können sollte.

Da es aber nur einmal (am Besten bei der Erst-Installation) eingerichtet werden muss, hält sich der Aufwand in Grenzen und es wäre die richtigere Lösung mit Arbeitsplatz- oder Nutzer-bezogenen Zugängen zu arbeiten.

Aber es ist natürlich eher eine Präventivmaßnahme von vielen, die zu einer Erhöhung des potenziellen Sicherheitsniveaus führt.

 

[mh1]

@mh1 und was machst Du mit externen Mitarbeitern oder Dienstleistern, die z.B. nur Klickworkerei erledigen sollen...

Da du jetzt mich persönlich fragst und eben nicht den JTL Anwender der die Standardeinstellungen verwendet hat, sage ich dir, wie ICH das handhabe:
bei mir bekommt jeder externe Dienstleister einen eigenen Login, den ich dann auch wieder lösche wenn dessen Klickworkerei beendet ist.
Genauso wie jeder Homeoffice bzw. Vetriebslaptop mit einem jeweils eigenen Login konfiguriert wird. Wenn der Vetriebler seinen Laptop verliert, kann ich dann wenigstens den Zugang zu unserer eazybusiness löschen.
Die PC's im LAN arbeiten bei uns aber alle mit dem gleichen Login. Sysadmin kriegt bei mir aber niemand, ausser denen, die diese Rechte auch wirklich brauchen.
Die Logins für die Wawi Nutzung nehme ich dann jeweils in die Serverrollen public, dbcreator und processadmin auf. Diese Logins haben dann aber auch immer denselben Zugriff auf die Datenbank. Daran ändert auch die Rechtvergabe in der Wawi nichts.

@mh1...und die man bisher durch nur notwendige Wawi Rechte beschränken konnte? Die haben jetzt de facto Vollzugriff.

Wenn man dem externen Dienstleister den sa Zugang gibt, hat der Dienstleister Vollzugriff auf den Server - das kann man dann nicht in der Wawi einschränken. Das konnte man bisher nicht und das kann man auch jetzt nicht - die Veröffentlichung dises Tools ändert daran nichts.

Nochmals:
Die Benutzerverwaltung der Wawi ist vollkommen getrennt von der Nutzerverwaltung des SQL-Servers.

 

[Verkäuferlein]

Gibt es denn irgendwo ein Tutorial, welche Rechte/Rolle für den Datenbankzugriff der Wawi für den einfachen Nutzer respektive Worker erforderlich sind?

Im JTL-Guide bin ich jetzt fündig geworden:
https://guide.jtl-software.de/jtl-w...zer/#einen-neuen-nutzer-fuer-jtl-wawi-anlegen

Wenn man sich unverschlüsselt mit dem SQL-Server verbindet, kann der Sniffer den Verkehr natürlich mitlesen. Dann kann auch alles SQL im Klartext mitgelesen werden.
Nur wenn man den SQL-Server aktiv auf TLS umstellt wird TLS benutzt.
Meintest du das mit Verbindungsverschlüsselung?

Ja, im Endeffekt meinte ich das. Ich war mir nicht sicher, ob der aktuelle MSSQL-Server nicht eine native Verbindungsverschlüsselung mitbringt.

Aber scheinbar ist der einfachste / richtige Weg über TLS / SSL.

Was haltet Ihr von einer Verschlüsselung mittels selbstsigniertem Zertifikat (über eigene Root CA / OpenSSL)?
Zum Schutz vor einfachen Sniffern und im lokalen Netzwerk sollte das ja eigentlich ausreichend sein!?

 

[mh1]

Ja, im Endeffekt meinte ich das. Ich war mir nicht sicher, ob der aktuelle MSSQL-Server nicht eine native Verbindungsverschlüsselung mitbringt.

Das Protokoll, das der SQL-Server nutzt heißt TDS und ist standardmäßig unverschlüssselt (also "Klartext"). Wenn man die Verbindung verschlüsseln will, muss man am SQL-Server TLS aktivieren (und natürlich ein entsprechendes Zertifikat installiert haben).

Wenn der Wawi Client dann TLS serverseitig erkennt, nutzt er TLS.
Wenn aber keine TLS erkannt wird, stellt der Client eine unverschlüsselte Verbindung her.
Dadurch ist sichergestellt, dass der Client in jedem Fall eine Verbindung herstellen kann.

Was haltet Ihr von einer Verschlüsselung mittels selbstsigniertem Zertifikat (über eigene Root CA / OpenSSL)?
Zum Schutz vor einfachen Sniffern und im lokalen Netzwerk sollte das ja eigentlich ausreichend sein!?

Klar wäre das in dem von dir beschriebenen Szenario prinzipiell ausreichend. Die Verschlüsselung ist ja diesselbe, ob self-signed oder öffentliches Zertifikat.
Meine Erfahrung mit anderen Serverdiensten unter Windows ist aber, das Windows generell sehr hohe Ansprüche an zu ladende Zertifikate stellt und mit selbstsignierten bin ich nie so richtig zum Erfolg gekommen.
Vielleicht kannst du jamal testen, ob der SQL-Server ein selbstsigniertes Zertifikat akzeptiert. Ich habe hier keinen Zugriff auf SQL-Server auf Windows. Aber es würd mich interessieren, ob das geht.

Aber damit wäre ja dann noch nicht sichergestellt, ob der Wawi Client, dieses selbstsignierte akzeptiert. Ich würde das eher mal anzweifeln...
Im Management Studio z.b. muss man ja in den Einstellungen ein Häkchen bei "Serverzertifikat vertrauen" machen. Beim Wawi Client wüsste ich jetzt auf Anhieb aber nicht, ob es so ein Häkchen gibt.

 

[Linario]

Relativ einfach zu lösen:

DB SA User nach dem neuanlegen eines anderen löschen > Nutzer dem Zweck entsprechend anlegen > Netzwerk im Unternehmen auf Privat setzen > Nur einen Accesspoint für Datenverbindungen > Idealerweise keine Fritzbox sondern separates Modem und Router (wir nutzen Modem und Asus AX11000 Router, kann auch internes VPN) der Router kann auch hinter die Fritzbox geschaltet werden zur Not > VPN einrichten > Vielleicht auch Proxychain > WLAN nur mit einem separaten Netzwerk, welches NICHT auf die produktive Umgebung zugreift.

In der WAWI nur die Rechte verteilen, die nötig sind.

Niemand ausser dem Sysadmin braucht Sysadminrechte. Gibt es keine 2 Meinungen.

Ist die DB auf einem anderen Server......diesen natürlich ebenfalls entsprechend schützen.

Klingt erstmal viel, doch auch der gemeine nicht IT-ler kriegt das hin.

 

[John]

Relativ einfach zu lösen:

(...) In der WAWI nur die Rechte verteilen, die nötig sind.

@Lina Danke für die Tips. Sicherlich sinnvoll aber gegen das Problem nutzen Sie gar nichts.

Wenn Du z.B. einem Wawi User nicht das Recht in der Wawi Rechteverwaltung erteilst, Arikel zu löschen, so kann der Nutzer mit den Ausgelesenen Verbindungsdaten trotzdem in die Datenbank gehen und dort löschen.
Dafür muß der Nutzer auch kein sa sein, denn jeder normale Wawi Nutzer hat auf Datenbank Ebene das Recht Tabellen zu ändern. Ohne dies wäre die Wawi nicht funktionsfähig.

 

[Linario]

@Lina Danke für die Tips. Sicherlich sinnvoll aber gegen das Problem nutzen Sie gar nichts.

Wenn Du z.B. einem Wawi User nicht das Recht in der Wawi Rechteverwaltung erteilst, Arikel zu löschen, so kann der Nutzer mit den Ausgelesenen Verbindungsdaten trotzdem in die Datenbank gehen und dort löschen.
Dafür muß der Nutzer auch kein sa sein, denn jeder normale Wawi Nutzer hat auf Datenbank Ebene das Recht Tabellen zu ändern. Ohne dies wäre die Wawi nicht funktionsfähig.

Hi John,

Du hast natürlich Recht, es ist nichts unmöglich und es ist kritisch zu sehen. Jeder mit fundierten SQL Kenntnissen ist sich aber bewusst, dass es diese Wege schon immer gegeben hat. Das nun natürlich (auch durch Chatgpt) vermehrt Programme in die Welt gelassen werden um möglichst viel Schaden anzurichten, ist sehr kritisch und erfordert entsprechende Maßnahmen, welche zum Teil in allen Bereichen erst eruiert werden müssen (betrifft aber nicht das hier behandelte Problem).

Mein Weg zeigt keinen umfassenden Schutz, jedoch können durch Schutz der Server, Clients und Verbindungen (VPN, Proxy, SA entfernen etc.) schon einmal die größten Attacken abgewehrt werden.
Selbst ein MITM kann hier nahezu ausgeschlossen werden. (Ich versuche mich möglichst ohne große Fachbegriffe zu bewegen, damit alles nachvollziehbar bleibt)

Für die meisten Nutzer hier sollte es durchaus praktikabel sein, da die meisten nicht interessant genug sind, dass sich jemand die Arbeit macht um alle diese Sicherungen zu durchbrechen.

Denn halten wir fest, die DB liegt auf einem entfernten Server, geschützt durch Cloudflare mit einem extremen Passwort, die Clients greifen nicht über SA zu, Die Verbindung zum Server erfolgt nur über Proxy / VPN in einem mehrfach gesicherten Netzwerk, der Router ist nicht via WLAN anzugreifen, da dieses Netzwerk keine WLAN-Verbindungen zulässt, somit müsste schon jemand mit einem LAN einbrechen und bekommt da sicher schönere Dinge in den Lagern als Daten.

Der hier aufgezeigte Weg beinhaltet nahezu nur noch die Möglichkeit über einen internen Angriff durch einen Nutzer selbst und den kann man nie ausschließen, egal welche Vorkehrungen getroffen werden.

Hiermit wird der Angriff von außen erst einmal minimiert. Interne Angriffe durch den Faktor Mensch sind natürlich nie ausgeschlossen, deswegen niemanden in die Nähe dieser Geräte lassen, der nichts damit zu tun hat. Es fängt damit an, dass einige ihre Rechner einfach nie sperren, Tablets zum picken offen und ungeschützt herumliegen etc. pp.

Ich finde es jedoch sehr gut, dass Du dieses Thema angeschnitten hast, mögen alle ihre eigene Infrastruktur kritisch beleuchten.

 

[Verkäuferlein]

@Lina Danke für die Tips. Sicherlich sinnvoll aber gegen das Problem nutzen Sie gar nichts.

Wenn Du z.B. einem Wawi User nicht das Recht in der Wawi Rechteverwaltung erteilst, Arikel zu löschen, so kann der Nutzer mit den Ausgelesenen Verbindungsdaten trotzdem in die Datenbank gehen und dort löschen.
Dafür muß der Nutzer auch kein sa sein, denn jeder normale Wawi Nutzer hat auf Datenbank Ebene das Recht Tabellen zu ändern. Ohne dies wäre die Wawi nicht funktionsfähig.

Vor allem sehen die unterschiedlichen Nutzerrollen im SQL-Server recht umfangreiche Rechte vor, damit die Wawi korrekt funktioniert.

Dazu gehört auch immer das Recht, die komplette Datenbank / Tabelle zu löschen. Also selbst wenn der SA-Nutzer nicht verwendet wird, kann damit ein deutlicher Schaden angerichtet werden und alle Daten der DB problemlos ausgelesen, verfälscht oder (automatisiert) gelöscht werden.