In den vergangenen Jahren durften wir uns, durch regelmäßige Erhöhung unserer Nutzerzahlen, häufig mit Strategien zur Skalierung von Serviceinteraktionen im BiPRO-Webserviceumfeld beschäftigen. Dabei stellen wir fest, dass die horizontale Skalierung von Kommunikationsprozessen hohe Risiken für Consumer mit sich bringen können und das aufrecht erhalten des erforderlichen Datenschutzniveaus häufig außerhalb unserer Einflussbereiche liegt, wie unsere Sicherheitsanalysten identifiziert haben.

‍

Vorwort

Wir halten es für sehr wichtig, vor Allem die Anbieter von BiPRO-Services, dahingehend zu sensibilisieren. Daher haben wir uns entschieden unser Wissen zu teilen und das Fehlerszenario in einem Beitrag zu veröffentlichen. Provider sollen hierdurch die Chance erhalten, Ihre Sicherheitslücken zu schließen bevor es zu Verstößen kommt.

Vorausgeschickt möchten wir klarstellen, dass dieses Problem nicht grundsätzlich vorliegt und nicht bei allen Providern existiert. Es muss für jeden Service in den Unternehmen jeweils überprüft und bewertet werden, ob derartige Sicherheitslücken vorhanden sind, in der Praxis vorkommen können und somit abgestellt werden müssen.

In der Praxis stoßen wir jedoch (leider) immer wieder auf produktive Problemstellungen und besprechen diese dann aktiv und individuell mit der betroffenen Gesellschaft. Für die Community ist es uns wichtig das Wissen über Fehlerpotenziale zu teilen und dies aktiv und intensiv gemeinsam zu prüfen sowie mit Ihrer Entwicklung, dem IT-Betrieb und der IT-Security das Vorkommen nachhaltig auszuschließen.

Einleitung

Einleitend möchten wir beschreiben worum es geht: Im BiPRO-Serviceumfeld gibt es Provider und Consumer. Der Provider bietet einen Webservice an (häufig Versicherer) und der Consumer (häufig Softwarehersteller) nutzt diesen in seinen Softwaresystemen. Beispielsweise werden diese Services häufig für die Dokumentenübermittlung der digitalen Maklerpost eingesetzt (sog. Transfer-Services der Normreihe 430).

Da an den meisten Cloud-/ Plattformsystemen der Branchensoftwarehersteller (Consumer) mehrere Kunden (Vermittler) angebunden sind, kann es vorkommen, dass viele Interaktionen mit den Webservices der Provider zeitgleich stattfinden müssen. Diese sind bei großer Kundenanzahl häufig auch zum gleichen Provider und unterschiedlichen Kunden (Vermittler) vollständig zeitgleich in Ausführung.

Sprich mehrere Kunden rufen eine Funktion im Consumer-System auf (z.B. „hole Dokumente ab“) und das Consumer-System fragt daraufhin verschiedene, aufeinander folgende, fachliche Funktionalitäten beim Provider ab (z.B. Anmeldung, Lieferungsliste holen, Dokument beziehen usw.).

In den Systemen der Provider sind die Verarbeitungen auf diese Anfragen der Consumer-Systeme und die darauf vom Provider zurückgegebene Service-Antwort in unterschiedlicher Weise abgebildet.

Es werden verschiedenste Programmiersprachen,Systemlandschaften, Datenspeicher und zudem auch verschiedenste Formen von Caching und/oder Temporärdatenspeicherung (z.B. in/aus Datalakes/ Datasilos) genutzt.

Da die BiPRO-Normen lediglich die fachliche Normierung und Beschreibung der Services und Übertragungen darstellt, steht es dem implementierenden Entwickler frei wie er die Serviceimplementierung und Datenbeschaffung abbildet.

Problemstellung

Wird bei einer Serviceinteraktion für mehrere eigenständige und für sich unabhängige fachliche Transaktionen, der auf die Millisekunde identische Zeitpunkt für Anfrage und Verarbeitung benutzt, kann es bei falscher Implementierung zu einer sogenannten schwerwiegenden Wettlaufsituation (eng. Race Condition) unter den unabhängigen Serviceantworten kommen. Ein Datenschutzverstoß ist häufig die direkte Folge.

"Eine Race Condition (ein Wettrennen um den Zugriff auf Ressourcen) ist eine unerwünschte Situation, die entsteht, wenn ein Gerät oder System versucht, zwei oder mehr Operationen gleichzeitig auszuführen."

Im Falle von Transfer-Services beobachten wir häufig Wettlaufsituationen von Dateianlagen und Dateiinhalten. Es kam in unseren Sicherheitsanalysen selten vor, dass eine Vermischung von Dateninhalten in XML-Nachrichten erkennbar war. Es kommt jedoch häufig vor, dass Dateien und Anlagen der XML-Nachrichten (sogenannte Binärdaten wie z.B. PDF-, CSV-Dateien) der falschen Serviceantwort vom Provider zugeordnet werden.

In diesen Fällen zeigt sich, dass beide unabhängigen Service-Anfragen mit unterschiedlichen XML-Dateninhalten, jedoch mit der identischen Dateianlage vom Provider ausgeliefert werden. Dabei bestätigt sich die Wettlaufsituation um die Dateiressourcen der zu sammelnden Anlagen. Dies ist der von uns häufigste festgestellte Fehlerfall.

Im Ergebnis äußert es sich dann so, dass die unabhängigen Anfragen mit einem gleichen Anteil ausgeliefert werden. Im schlimmsten Fall werden beide Kunden zwar die jeweils richtigen Nettodaten in der Antwort erhalten, jedoch einer der beiden erhält eine Dateianlage die nicht zu Ihm gehört.

Sofern in der betroffenen Anlage personenbezogene Daten enthalten sind, liegt schnell ein meldepflichtiger Datenschutzverstoß für den Versicherer vor. Hinzu kommt der Aufwand für das Beweissicherungsverfahren des Consumers (Softwareanbieter), da er zunächst im Fokus für den betroffenen Kunden als Systemanbieter steht.

Lösungsansätze

Bei den betroffenen Implementierungen liegt häufig ein Bezug einer Anlage aus einem der Umsysteme neben dem BiPRO-Webservice vor. Werden diese Anlagen beim Bezug zwischengespeichert und dabei keine ausreichenden transaktionssicheren/ eindeutigen Identifikatoren genutzt, kommt es in Folge zu einem mehrfachen Zugriff auf die selbe Ressource oder zur Überschreibung von temporären Ressourcen unterschiedlicher Transaktionen.

Unsichere Identifikatoren sind z.B. Zeitstempel, Hashes oder Identifikatoren die aus dem Anfragesystem stammen.

Die Lösung für diese sogenannten Wettlaufsituationen ist die Gewährleistung der Transaktionssicherheit und die damit verbundene Vergabe von systemweiten eindeutigen Identifikatoren. Auch Zeitstempel und Hashes können unterstützend verwendet werden, sollten jedoch niemals als einziger eindeutiger Identifikator genutzt werden.

Test und Analyse

Auf Grund der Vielfältigkeit der Programmiersprachen in den Umsetzungen verzichten wir an dieser Stelle auf Codebeispiele. Sie können jedoch programmatisch leicht prüfen ob einer Ihrer Webservices für eine solche Sicherheitslücke anfällig ist.

1. Sie benötigen ein Skript, welches mittels Multithread-Anfrage zeitgleich (Millisekunden identisch ist erforderlich für den Test) auf Ihrem BiPRO-Service eine Datenauskunft mit Dateianlagen in der Antwortnachricht abruft. Stellen Sie sicher, dass die Anfragen zeitgleich laufen.

2. Die Anfragen sollten unterschiedliche Vermittler betreffen und ggf. gleichartige Geschäftsvorfälle berücksichtigen (damit die gleichen Umsysteme angefragt werden).

3. Lassen Sie das Skript ohne Schwellwertgrenzen für eine ausreichend hohe Anzahl an Anfragen laufen und speichern sich die Anfrage-ID und Binärdaten der Anlagen in eine Datenbank (o.Ä.).

4. Vergleichen Sie ob im Verlauf der Laufzeit eine identische Anlage bei unterschiedlichen Anfrage-IDs vorkommt.

5. Ist ein Eintrag vorhanden, ist Ihr Service von einer Wettlaufsituation betroffen und Sie sollten überprüfen ob eine solche Auslieferung bereits produktiv in der Praxis stattgefunden hat, sowie die Lücke umgehend schließen.

Praxisfälle

In unseren Überprüfungen haben wir leider, bei mehreren deutschen Versicherungsgesellschaften, in produktiven Webservices der Normreihe 430, ein derartiges Szenario feststellen können.

Auch in der Praxis kam es zu uns bekannten Datenschutzverstößen bei denen die Meldepflicht, Klärungsverpflichtung und technische Behebung nachweislich beim Versicherungsunternehmen lag. Fast alle diese Fälle ließen sich auf Wettlaufsituationen (oder vergleichbare Muster) beim temporären Speichern und/oder asynchronen Sammelvorgang während der Servicebeantwortung zurückführen.

Fazit

Festzuhalten ist, dass BiPRO-Services nicht grundsätzlich für Wettlaufsituationen anfällig sind. Die marktverbreiteten Normen sind bewusst vom beliebten Normungsinstitut fachlich gehalten und bilden fachlich geprägte Prozessabläufe ab ohne Implementierungsanweisungen zu geben.

Dies gibt dem einzelnen Entwickler im Providerunternehmen leider jedoch auch den Freiraum bei der Implementierung nicht alle Szenarien bedacht zu haben.

"Sofern Entwickler, Daten aus asynchronen Datalakes beziehen oder beim synchronen Bezug auf Zwischenspeicherungen der Binärdaten angewiesen sind, müssen Wettlaufsituationen berücksichtigt und ausreichend getestet werden. Entwickler sollten unbedingt auf technische Transaktionssicherheit und bedingungslos eindeutige Identifikatoren achten."

Unser Fazit ist daher leider, dass wir nach unseren Erfahrungen auf Multithread-Zugriffe bei Transfer-Services in unserem BiPRO-Client verzichten müssen und stattdessen in eine Versicherer-, Service-und Versionsteilung mit verbundener horizontaler Skalierung auf Server-Cluster investieren werden.

Innerhalb dieser Betrachtung, bleibt nach aktuellem Stand der vorgefundenen Implementierungen der Versicherungsgesellschaften, sowie dem daraus resultierenden Dafürhalten unserer Sicherheitsanalysten, keine andere Wahl als zunächst gleichzeitige Verbindungen auf identische Services pro Gesellschaft in der Breite zu unterbinden.