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

Janine

Sehr aktives Mitglied
9. November 2015
214
49
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

Sehr aktives Mitglied
29. April 2012
1.683
537
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.
 

Janine

Sehr aktives Mitglied
9. November 2015
214
49
Ein Ticket habe ich aufgemacht, mal schauen ob und was für eine Antwort kommt.
Wenn sich etwas tut, informiere ich hier.
 

Thomas_T

Sehr aktives Mitglied
19. Dezember 2019
189
39
Werdau
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.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: fdits und aadursun

Verkäuferlein

Sehr aktives Mitglied
29. April 2012
1.683
537
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

Sehr aktives Mitglied
4. Oktober 2020
439
94
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

Sehr aktives Mitglied
19. Dezember 2019
189
39
Werdau
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

Sehr aktives Mitglied
4. Oktober 2020
439
94
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

Sehr aktives Mitglied
29. April 2012
1.683
537
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.
 
  • Gefällt mir
Reaktionen: mh1

Thomas_T

Sehr aktives Mitglied
19. Dezember 2019
189
39
Werdau
@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

Sehr aktives Mitglied
29. April 2012
1.683
537
@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/
 
  • Gefällt mir
Reaktionen: Janine