Oviva epa4all-rest-service
Unauthentifizierte REST-API für Schreibzugriffe auf Patientenakten
Der epa4all-rest-service stellt Endpunkte zum Schreiben und Ersetzen von Dokumenten bereit, ohne jede Authentifizierungs-Middleware in der Handler-Kette, bindet standardmäßig an 0.0.0.0 und übernimmt die KVNR der Ziel-Betroffenen vom Aufrufer. Jeder Aufrufer, der den Dienst erreicht, schreibt mit den SMC-B-Credentials der Einrichtung beliebige Dokumente in jede ePA.
Beschreibung
Die Handler-Kette umhüllt das Routing mit Cache- und Error-Handling, ohne jede Authentifizierungsschicht in der Komposition:
Main.java:224-272
new DisableCacheHandler(new BlockingHandler(withErrorHandling(routing)))Der Dienst bindet standardmäßig an 0.0.0.0 (Main.java:150), und das Produktions-Docker-Beispiel der README veröffentlicht den Port ohne localhost-Bindung (-p '8080:8080'), sodass eine Standard-Bereitstellung aus dem lokalen Netz erreichbar ist. Die OpenAPI-Spezifikation (openapi.yaml) definiert null securitySchemes, und das Repository enthält weder eine SECURITY.md noch eine Dokumentation, die eine Netzwerkisolierung verlangt.
Die Ziel-Betroffene ist die KVNR, die der Aufrufer liefert; die einzige Prüfung ist auf null:
Epa4allClientService.java:44
Objects.requireNonNull(insurantId);Während eines Testlaufs lieferte ein einzelner unauthentifizierter POST an den Dokument-Endpunkt mit einer synthetischen KVNR den Status 200 und eine Dokument-ID zurück, was bestätigte, dass der Schreibvorgang ohne Credentials im Request den Patientenakten-Pfad erreichte:
Unauthentifizierter Schreibzugriff (PoC-Ausgabe, KVNR geschwärzt)
POST /documents (kein Authorization-Header, kein API-Key) insurant_id: X000000000-> 200 OK {"id":"<document-id>"}Auswirkung
- Ein Angreifer, der den Dienst erreicht, schreibt ohne jede Authentifizierung mit den SMC-B-Credentials der Einrichtung beliebige Dokumente in jede ePA. Da die KVNR aufruferkontrolliert ist, ist das Ziel jede Betroffene, für die die SMC-B-Karte tätig werden kann, nicht nur eine.
- Eine Auswirkung auf die Vertraulichkeit wird hier nicht geltend gemacht (es geht um den Schreib-/Ersetzungspfad); die Auswirkung auf die Integrität ist das Einfügen oder Ersetzen von Dokumenten in einer Patientenakte, die ein nachgelagerter Behandler oder ein System später als authentisch lesen kann.
Abhilfe
Es ist kein behobenes Release verfügbar. Oviva empfiehlt, eine Authentifizierung zwischen Diensten (zum Beispiel mTLS) über Netzwerkrichtlinien oder einen Proxy zu erzwingen und den Dienst in einem isolierten Netzwerk-Namespace zu betreiben (etwa als Kubernetes-Sidecar oder über ein Service-Mesh mit entsprechenden Richtlinien); Oviva hat in Pull Request #43 einen Dokumentationshinweis zur API-Autorisierung ergänzt. Bis ein Release eine Authentifizierung ergänzt, behandeln Sie den Dienst als unauthentifizierte Vertrauensgrenze: binden Sie ihn an 127.0.0.1, veröffentlichen Sie den Docker-Port nur auf localhost (-p '127.0.0.1:8080:8080') und setzen Sie einen authentifizierenden Proxy vor jeden nicht-lokalen Zugriff.
Checkliste für Betreiber
Den REST-Dienst als unauthentifiziert behandeln.
Kein veröffentlichtes Release ergänzt eine Authentifizierung. Gehen Sie davon aus, dass jeder Aufrufer, der den Port erreicht, in Patientenakten schreiben kann, und gestalten Sie die Bereitstellung entsprechend.
An localhost binden und den Port nur auf localhost veröffentlichen.
Ändern Sie die Bind-Adresse von
0.0.0.0auf127.0.0.1und verwenden Sie-p '127.0.0.1:8080:8080'im Docker-Run statt des-p '8080:8080'der README.Einen authentifizierenden Proxy vor jeden Remote-Zugriff setzen.
Wenn der Dienst über localhost hinaus erreichbar sein muss, stellen Sie ihm einen mTLS- oder Token-prüfenden Reverse-Proxy voran und beschränken Sie den Netzwerkpfad per Richtlinien, sodass nur der vorgesehene Aufrufer ihn erreicht.
Auf ein Release mit API-Authentifizierung achten.
Pull Request #43 ergänzt einen Dokumentationshinweis zur API-Autorisierung; kein veröffentlichtes Release ergänzt eine Auth-Prüfung auf den Dokument-Endpunkten. Verfolgen Sie das Projekt auf ein Release, das eine solche einführt, und aktualisieren Sie, sobald verfügbar.
Bewertung im Detail
Referenzen
So können wir helfen
Wer wir sind
Die Sicherheitsforscher hinter diesem Sicherheitshinweis.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec-Forscher
Ich evaluiere Ihr SaMD mit derselben branchenprägenden Sicherheitsexpertise, die ich dem BAK MV für die Überarbeitung des B3S-Standards beigetragen habe.
- Promotion über Krankenhaus-Cybersicherheit
- Kritische Schwachstellen in Krankenhaussystemen gefunden
- Alumni der THB MedSec-Forschungsgruppe
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
Als ehemaliger CTO und Entwickler, der zum Pentester wurde, arbeite ich mit Ihrem Team zusammen, um Schwachstellen aufzudecken und Lösungen zu finden, die zu Ihrer Architektur passen.
- 20+ Jahre als CTO, 50+ Mio. App-Downloads
- Architektur und Absicherung großer IoT-Flotten
- Certified Web Exploitation Specialist
- gematik Security Hero
Penetrationstest gesucht?
Machine Spirits ist spezialisiert auf Sicherheitsbewertungen für Medizinprodukte und Gesundheits-IT. Von MDR-Penetrationstests bis C5-Cloud-Compliance helfen wir MedTech-Unternehmen, regulatorische Anforderungen zu erfüllen.