Neu 1.6.40.0 Kritische Sicherheitslücke Fehlerhafte Rechtevergabe Zugriff auf sensible Daten ohne Berechtigung möglich

[Janine]

Wir wollen einem Externen Dienstleister Zugang zum Servicedesk geben. Das haben wir auch fast zu unserer Zufriedenheit konfiguriert.
Diese Externen Mitarbeiter sollen ausschließlich nur für diesen Bereich einen Zugang bekommen.
Trotz der konfigurierten Rechte können diese Mitarbeiter unter Zahlungen-Zugewiesene Zahlungen sämtliche Verkäufe, Beträge, TransaktionsIDs und Kundendaten für alle Jahre sehen.
Ich ordne solch einen Fehler, als schweren Sicherheitsfehler ein. Dadurch ist ein massiver Verstoß gegen die DSGVO möglich und der Verlust von hoch sensiblen Geschäftsdaten.
Solch eine kritische Sicherheitslücke muss schnellstmöglich über ein Update geschlossen werden und die Betreiber der Wawi informiert werden.
Das ist zumindest meine Einschätzung des Problems.

 

[Verkäuferlein]

Gibt ja schon seit Ewigkeiten "Wünsche" nach besserem Rechtemangement im Zahlungsmodul, wie an vielen anderen Stellen auch.

Woran es liegt, dass es nur sehr langsam vorwärts geht und in der Regel solche Rückmeldungen keine große / schnelle Berücksichtigung finden, kann ich Dir nicht sagen.

Aber gerade bei einem Bezahlprodukt wie dem Zahlungsmodul (im übrigen durch Umstieg von Kauf- auf Abo-Modell gerade erst ca. 20% teurer geworden), sollte eigentlich auch die finanzielle Ausstattung und der Anspruch vorhanden sein, um schnelle Verbesserungen umsetzen zu können.

 

[recent.digital]

Hast du ein Ticket zu dem Vorgang aufgemacht? ggf. einfach direkt auf den Thread hier verweisen. Danke für die Infos.

 

[Janine]

Ein Ticket habe ich aufgemacht, mal schauen ob und was für eine Antwort kommt.
Wenn sich etwas tut, informiere ich hier.

 

[Thomas_T]

Naja, das ist weder eine Sicherheitslücke noch ein Verstoß gegen die DSGVO von JTL.

Die Daten werden dir/euch vom Kunden zur Verfügung gestellt und nur du/ihr habt diese im JTL. Wenn nun beschlossen wird, Zugriff für einen Dritten auf JTL zu gewähren, dann verstößt Ihr gegen die DSGVO und ermöglicht die Sicherheitslücke. Die erwähnten Daten sind halt auch mal für einen Servicemitarbeiter nötig, damit er den Fall auch bearbeiten kann und nicht die anderen Abteilungen nerven muss.

Was soll denn der Dritte für Daten bekommen? Exportiert ihm doch einfach die Daten via Ameise oder programmiert eine einfache Schnittstelle (z.B. via PHP) mit der der Drittanbieter seine Daten abfragen kann.

Mal so nebenbei: Ich hätte größere Bauchschmerzen den Dritten erst mal in mein Netzwerk reinzulassen, damit er sich bei JTL überhaupt einloggen kann.

 

[Verkäuferlein]

Naja, das ist weder eine Sicherheitslücke noch ein Verstoß gegen die DSGVO von JTL.

Na ja, es gibt da z.B. den Grundsatz "Privacy by Design", dementsprechend sollte es die Möglichkeit geben, nur die Rechte einzuräumen, die auch zu 100% erforderlich sind. Das Problem trifft dabei ja nicht nur auf den hier beschriebenen Anwendungsfall zu.

Die erwähnten Daten sind halt auch mal für einen Servicemitarbeiter nötig, damit er den Fall auch bearbeiten kann und nicht die anderen Abteilungen nerven muss.

Genau das macht aber ein entsprechendes Rechtemanagement (technisch sowie organisatorisch) erforderlich. Nicht jeder Service-Mitarbeiter sollte pauschal Vollzugriff auf sämtliche Zahlungsdaten haben.

Was soll denn der Dritte für Daten bekommen? Exportiert ihm doch einfach die Daten via Ameise oder programmiert eine einfache Schnittstelle (z.B. via PHP) mit der der Drittanbieter seine Daten abfragen kann.

So wie ich das verstehe, geht es hier quasi um ein externes "Call-Center", das Kundenanfragen beantwortet. Also eine Teil-Auslagerung des Kundenservices an einen Dienstleister. Das ist ja bei vielen (vor allem größeren) Unternehmen nicht ungewöhnlich, um z.B. eine bessere Erreichbarkeit zu gewährleisten.

Mal so nebenbei: Ich hätte größere Bauchschmerzen den Dritten erst mal in mein Netzwerk reinzulassen, damit er sich bei JTL überhaupt einloggen kann.

Da würde ich Dir zustimmen, das klingt nicht optimal. Allerdings wissen wir ja gar nicht, wie das Hosting aussieht und wie der Server abgesichert ist. Auch dort gibt es ja Möglichkeiten der "Trennung".

 

[mh1]

Wir wollen einem Externen Dienstleister Zugang zum Servicedesk geben. Das haben wir auch fast zu unserer Zufriedenheit konfiguriert.

Mit dem Gedanken haben wir uns auch mal befasst, ist aber z.Zt. wieder in den Hintergrund geschoben....
Wie habt ihr denn den Zugang realisiert? Geht der Dienstleister per VPN in euer LAN und dann per RDP auf die WAWI?

 

[Thomas_T]

Naja, man muss aber auch berücksichtigen, dass das Servicedesk noch in den Kinderschuhen steckt und noch nicht "final" ist.

Bleiben momentan nur 2 Möglichkeiten:
1. Anderes Ticketsystem nutzen
2. AGB und Datenschutztexte anpassen (ist ja nicht verboten mit externen Dienstleisten zu arbeiten, mann muss es nur transparent machen)

Wie gesagt, in meinen Augen braucht eine vernünftige Servicedesk-Lösung Vollzugriff!

• Wann wurde es gekauft?
• Wohin wurde es geliefert?
• Wohin ging die Rechnung?
• Wann ist das Geld mit welchem Zahlungsdienstleister eingegangen? ("Warum ist die Ware immernoch nicht da?")
• Sind die Kontaktdaten noch aktuell?
• Stimmt das was der Kunde sagt: "Ich hab den Artikel schon 5 mal bestellt, aber diesmal ist was anders..."

Das sind mitunter häufige Fragen/Probleme eines Servicedesks / Supports. Da kann man doch nicht jedes mal sagen: "Moment, ich frage mal nach" bzw. beim externen Dienstleister "Der Kunde will das und das von mir wissen. Ich darf es ja nicht sehen, also schau du mal für mich nach und sag es mir dann, damit ich dem Kunden das sagen/schreiben kann. Da macht man sich die Arbeit doppelt und dreifach.

Daher: Transparente Datenschutzvereinbarung und seriösen Servicepartner nehmen. Einem serösen Partner sind die vertraulichen Daten ausserhalb der Fallbearbeitung eh egal.

 

[mh1]

Wie gesagt, in meinen Augen braucht eine vernünftige Servicedesk-Lösung Vollzugriff!

• Wann wurde es gekauft?
• Wohin wurde es geliefert?
• Wohin ging die Rechnung?
• Wann ist das Geld mit welchem Zahlungsdienstleister eingegangen? ("Warum ist die Ware immernoch nicht da?")
• Sind die Kontaktdaten noch aktuell?
• Stimmt das was der Kunde sagt: "Ich hab den Artikel schon 5 mal bestellt, aber diesmal ist was anders..."

Ach um so etwas geht es hier 🤦‍♂️
....ich wusste garnicht das JTL so ein Ticketsystem mitbringt.

@Janine
Bleibt aber die Frage, wie der externe Dienstleister an die Daten kommt.
Wenn du dem einen sa Zugang auf euren SQL Server gibst, liegen doch eh alle Daten offen (und wenn der SQL Server mit Admin Rechten läuft, hat der Externe Zugriff auf die gesamte Domäne)

 

[Verkäuferlein]

Naja, man muss aber auch berücksichtigen, dass das Servicedesk noch in den Kinderschuhen steckt und noch nicht "final" ist.

Das hat aber nichts mit dem Rechtemanagement in der Wawi und im Zahlungsmodul zu tun. Und der DSGVO ist das auch egal, ob das noch in den Kindeschuhen steckt oder nicht. Erfolgt darüber eine Datenverarbeitung bzw. besteht die Möglichkeit dazu, müssen aus meiner Sicht die Anforderungen der DSGVO erfüllt sein (auch das ist wieder Privacy by Design).

Daher: Transparente Datenschutzvereinbarung und seriösen Servicepartner nehmen. Einem serösen Partner sind die vertraulichen Daten ausserhalb der Fallbearbeitung eh egal.

Der Kern der Aussage ist zwar richtig, aber
1.) schreibt die DSGVO meiner Ansicht nach bereits vor, dass man die Partner auf Seriösität zu prüfen und danach auszuwählen hat
und
2.) entbindet das ja nicht davon, seinen sonstigen Pflichten nachzukommen und dafür zu sorgen, dass nicht benötigte Daten nicht zugänglich sind (auch wenn dies auf fehlende / fehlerhafte Funktionen der Wawi zurückzuführen ist).

Das sind mitunter häufige Fragen/Probleme eines Servicedesks / Supports. Da kann man doch nicht jedes mal sagen: "Moment, ich frage mal nach" bzw. beim externen Dienstleister "Der Kunde will das und das von mir wissen. Ich darf es ja nicht sehen, also schau du mal für mich nach und sag es mir dann, damit ich dem Kunden das sagen/schreiben kann. Da macht man sich die Arbeit doppelt und dreifach.

Es gibt ja bei einigen die Überlegung, dass es besser ist, der Kunde erreicht überhaupt jemanden, als dass er niemanden erreicht und auch in der Mailbearbeitung geht es ja manchmal nur um Pillepalle und manchmal um Fachthemen. So dass es vielleicht einfach nur um die Reduzierung der Gesamtzahl der Mails geht, die von Fachabteilungen bearbeitet werden.

 

[Thomas_T]

@Janine
Bleibt aber die Frage, wie der externe Dienstleister an die Daten kommt.
Wenn du dem einen sa Zugang auf euren SQL Server gibst, liegen doch eh alle Daten offen (und wenn der SQL Server mit Admin Rechten läuft, hat der Externe Zugriff auf die gesamte Domäne)

Genau das macht mir Bauchschmerzen. Im Endeffekt bräuchte man für sowas einen eigenen Client, der nur freigegebene Servicedesk-Funktionen bietet, der mitteils Portfreigabe am Router mit dem Server kommuniziert (eigner Port) und somit ein externes Zugreifen ohne zu viel Rechte ermöglicht. Alles Andere ist Sicherheitsrisiko hoch 10. Da ist der Datenschutz zwar wichtig aber Nebensache, weil wir so ganz andere Probleme kriegen (werden).

 

[Verkäuferlein]

@Michael Spaltmann
Dieser Thread ist vielleicht auch ein interessanter Ansatz / Input für Euch, in welchem Use Case der Service Desk möglicherweise auch zum Einsatz kommt bzw. womit dieser kompatibel sein müsste.

Genau das macht mir Bauchschmerzen. Im Endeffekt bräuchte man für sowas einen eigenen Client, der nur freigegebene Servicedesk-Funktionen bietet, der mitteils Portfreigabe am Router mit dem Server kommuniziert (eigner Port) und somit ein externes Zugreifen ohne zu viel Rechte ermöglicht. Alles Andere ist Sicherheitsrisiko hoch 10. Da ist der Datenschutz zwar wichtig aber Nebensache, weil wir so ganz andere Probleme kriegen (werden).

Es gab ja mal den Vorschlag, die Daten des Service-Desk in eine eigene DB auszulagern bzw. auch den Servicedesk quasi IMAP-kompatibel zu machen.

Das wäre aus meiner Sicht genau das Thema, was für diesen Ansatz nochmal weitere Argumente liefert bzw. wie man das Problem von @Janine umschiffen könnte.

Siehe auch:
https://forum.jtl-software.de/threads/speicherung-in-sql-db.128733/

 

[MLR]

Hallo zusammen,

Ich habe das gleiche Problem entdeckt. Allerdings geht es bei uns um die Einsicht der Artikeldaten durch einen Partner. Im Endeffekt sollte er nur die Lagerbestände und Netto-VK's einsehen können, allerdings kann der Nutzer auch unsere zugewiesenen Zahlungen einsehen.
Mal abgesehen von der Tatsache, dass es sich um jemanden Externes handelt, das sollte auch nicht jeder Mitarbeiter sehen können. Im Lager haben Zahlungen von Kunden, Lieferanten, usw. keinerlei Relevanz und sollten auch nicht angezeigt werden. Dafür sollten die Rechte ja da sein, um diese Zugänge einzuschränken.

Na ja, es gibt da z.B. den Grundsatz "Privacy by Design", dementsprechend sollte es die Möglichkeit geben, nur die Rechte einzuräumen, die auch zu 100% erforderlich sind. Das Problem trifft dabei ja nicht nur auf den hier beschriebenen Anwendungsfall zu.

Stimme ich voll und ganz zu.

 

[mh1]

Im Endeffekt sollte er nur die Lagerbestände und Netto-VK's einsehen können,

exportiere ihm am besten nur genau die Daten, die er sehen soll/muss/darf.

allerdings kann der Nutzer auch unsere zugewiesenen Zahlungen einsehen.

wenn du ihm Zugriff auf die Datenbank gibst, kann er auch immer alles einsehen.

 

[Verkäuferlein]

wenn du ihm Zugriff auf die Datenbank gibst, kann er auch immer alles einsehen.

Nicht nur das, wenn ich das Rechte- und Rollen-Konzept von MSSQL und der JTL-DB korrekt verstehe, kann er sogar sämtliche Daten überschreiben oder löschen, sobald er einen Datenbankbenutzer mit den niedrigst-notwendigen Rechten hat, die die Wawi benötigt.

Das muss dann nichtmal böse Absicht sein, sondern kann ja auch durch einen Hacker-Angriff ungewollt auf Euch übergreifen.

@MLR
Oder kommt der externe Partner zu Euch in den Betrieb und hat da einen Benutzer an der Wawi für seine Aufgaben?

Ansonsten wie @mh1 sagt am besten per Export, über einen Shop bzw. eine Kundengruppe im Shop oder über das FFN die Daten zur Verfügung stellen, je nachdem, was der genaue Zweck ist.

 

[MLR]

exportiere ihm am besten nur genau die Daten, die er sehen soll/muss/darf.


wenn du ihm Zugriff auf die Datenbank gibst, kann er auch immer alles einsehen.

Das behebt das Problem temporär. Für unsere internen Mitarbeiter ist es aber immer noch vorhanden.

 

[DJScyper]

Ich bin gerade eben erst auf das Problem gestoßen, als mir ein Mitarbeiter aus unserem Lager mitgeteilt hat das er da was sehen kann. Ich ging nicht davon aus, dass wenn ich ein Berechtigungssystem habe und für den Reiter "Zahlung" keine Rechte vergebe, dass ein Mitarbeiter im Haus trotzdem was sehen kann.

Daher sehe ich schon die JTL in der Verantwortung hier zu handeln. Zumindest nur das Sichtbar zu machen was ich auch einstelle. Selbst ein Mitarbeiter im Haus darf ohne Berechtigung doch nicht in "Zahlungsabgleich" alle Kundendaten sehen. Der Lagermitarbeiter in meinem Fall hat ja nichtmal Zugriff auf Kunden.

 

[mh1]

Ich bin gerade eben erst auf das Problem gestoßen, als mir ein Mitarbeiter aus unserem Lager mitgeteilt hat das er da was sehen kann.

Was genau funktioniert denn nicht?
Bei uns haben die Lageristen auch eingeschrängte Sichtbarkeiten und in unserem Falle funktioniert das wie gewünscht.

...aber natürlich nur solange der Lagerist sich nicht zum Hacker berufen fühlt und sich die entsprechenden Zugangsdaten besorgt, um direkt auf die Datenbank zuzugreifen

 

[DJScyper]

Hallo anbei die Rechtevergabe und das was der Mitarbeiter sehen kann. Getestet mit einer neuen Benutzergruppe und einem neuen User:

 

[Enrico W.]

Probier dahingehend mal bitte die Sharp- Wawi. Damit ist in meinem Testsystem ohne entsprechendes Recht nicht mal mehr die Kachel für Zahlungen anklickbar.