e-Government in Deutschland: Kritische Schwachstellen in zentraler Transportkomponente

vulnerability

Die „OSCI-Transport“ Java-Bibliothek ist eine Kernkomponente im deutschen e-Government. Schwachstellen in dieser Komponente erlauben es einem Angreifer, bestimmte zwischen Behörden ausgetauschte Informationen zu entschlüsseln oder zu manipulieren bzw. sogar Daten von Behördenrechnern auszulesen.

German E-Governement graph - SEC Consult

 

Weitere technische Details zu diesem Thema finden Sie im englischsprachigen Beitrag

OSCI-Transport ist ein Protokoll, das dazu dient Daten zwischen Behörden sicher auszutauschen. Es wurde 2002 definiert und gilt als obligatorischer Standard für die elektronische Kommunikation in der Bundesverwaltung [1]. Das Protokoll findet Einsatz in verschiedenen Bereichen der öffentlichen Verwaltung wie der Justiz (XJustiz), dem Gesundheitswesen (XÖGD) oder dem Meldewesen (XMeld) [2]. OSCI erhebt den Anspruch Integrität, Authentizität, Vertraulichkeit und Nachvollziehbarkeit bei der Übermittlung von Nachrichten zu gewährleisten [1]. Das bedeutet, dass ein Angreifer Nachrichten nicht mitlesen oder verändern, die Erstellung einer Nachricht abstreiten oder sich als ein gültiger Kommunikationsteilnehmer ausgeben können sollte. Dies gilt selbst dann, wenn die Kommunikation über ein nicht vertrauenswürdiges Netzwerk (z. B. das Internet) erfolgt [1].

Die OSCI-Transport Bibliothek ist eine häufig eingesetzte Java-Implementierung der Version 1.2 des OSCI-Transport Protokolls1. Diese wird von den Herausgebern dieses OSCI-Transport Protokolls bereitgestellt und ist in älteren Versionen bereits seit 2004 verfügbar [7]. Im Rahmen einer oberflächlichen Sicherheitsüberprüfung [3] dieser Komponente (Version 1.6.1) wurden mehrere Sicherheitslücken festgestellt. Mithilfe dieser Schwachstellen kann ein Angreifer bestimmte zwischen Behörden ausgetauschte Informationen u. U. manipulieren, entschlüsseln bzw. sogar Dateien von Behörden-Servern auslesen. Es wurde keine vollständige Sicherheitsanalyse durchgeführt und es kann daher nicht ausgeschlossen werden, dass weitere Schwachstellen oder Angriffsszenarien existieren.

OSCI protocol in German graph - SEC Consult

Einführung In OSCI-Transport 1.2

Um die gefundenen Schwachstellen verständlich zu machen, gibt folgender Abschnitt eine kurze Einführung in das OSCI-Transport Protokoll Version 1.2 [4].

Grundsätzlich versucht in einer OSCI Kommunikation ein Sender eine Nachricht an einen Empfänger zu übermitteln. Das Protokoll kann für jegliche Nachrichteninhalte verwendet werden. Das Nachrichtenformat ist XML. In der Regel sind an einer OSCI 1.2 Kommunikation drei Parteien beteiligt, da die Nachricht vom Sender über einen Intermediär an den Empfänger geleitet wird. Der Intermediär dient dazu die Kommunikation zu vermitteln, diverse Prüfungen durchzuführen sowie den Datenaustausch nachweislich zu protokollieren. Um die Kommunikation vor Angriffen zu schützen, werden u. a. folgende Sicherheitsmechanismen definiert:

  • Die Signatur von Inhaltsdaten erlaubt es einem Empfänger sicherzustellen, dass die empfangenen Daten tatsächlich vom angegebenen Sender stammen.
  • Die Verschlüsselung von Inhaltsdaten stellt sicher, dass der eigentliche Inhalt einer Nachricht nur vom Empfänger gelesen werden kann. Der Intermediär kann die Inhaltsdaten nicht entschlüsseln.
  • Die Signatur von Aufträgen ermöglicht dem Intermediär bzw. dem Empfänger sicherzustellen, dass die Nachricht tatsächlich vom angegebenen Sender bzw. Intermediär stammt und nicht verändert wurde.
  • Die Verschlüsselung von Aufträgen stellt sicher, dass die Kommunikation zwischen Sender und Intermediär bzw. die Kommunikation zwischen Intermediär und Empfänger von einem Angreifer nicht mitgelesen werden kann.

Alle diese Sicherheitsmechanismen von OSCI sind optional.

Padding oracle script excerpt - SEC Consult

Schwachstellen

Aus Sicht eines Angreifers bestehen prinzipiell zwei Möglichkeiten für Angriffe auf OSCI-Transport:

  • Angriffe gegen die Kommunikationsteilnehmer: Ein Angreifer versucht vom Standard abweichende Protokollnachrichten an Kommunikationsteilnehmer zu senden, um diese zu kompromittieren.
  • Angriffe auf die Kommunikation: Ein Angreifer hat Zugriff auf die verschlüsselten und signierten OSCI-Nachrichten. Der Angreifer versucht diese zu entschlüsseln bzw. zu manipulieren.

SEC Consult konnte in der Version 1.6.1 der OSCI Bibliothek für Java Schwachstellen feststellen, welche beide Angriffsszenarien betreffen. Die gefundenen Schwachstellen wurden in zumindest einem OSCI Kommunikationsszenario verifiziert3.

Der folgende Abschnitt bezieht sich auf die Version 1.6.1 der OSCI-Transport Bibliothek für Java. Eine tiefergehende technische Beschreibung der Schwachstellen ist in der englischen Version des Blogposts zu finden.

 

Angriffe gegen die Kommunikationsteilnehmer

Das OSCI-Transport Protokoll basiert auf dem XML-Format. Eine häufig identifizierte Schwachstelle bei XML-verarbeitenden Komponenten ist XML External Entity Injection (XXE). Neben anderen Auswirkungen, wie z.B. Denial-of-Service, kann es dieser Angriff erlauben Dateien des Systems auszulesen6.

Wir konnten feststellen, dass die OSCI-Bibliothek verwundbar auf XXE Angriffe ist. Ein Angreifer muss eine manipulierte Protokollnachricht an einen OSCI-Teilnehmer senden, um z.B. Konfigurationsdateien mit Passwörtern, private Schlüssel oder andere interne Informationen auszulesen. In zumindest einem OSCI Kommunikationsszenario muss ein Angreifer dazu lediglich eine manipulierte Nachricht an einen OSCI Server senden. Für einen Angreifer ist es nicht nötig eine originale Nachricht abzufangen, sondern Voraussetzung ist lediglich die Erreichbarkeit eines OSCI-Teilnehmers welcher in einem bestimmten Kommunikationsszenario agiert (passiver Empfänger)4. Es ist auch nicht erforderlich, dass ein Angreifer für die Kommunikation verwendete Zertifikate oder private Schlüssel kennt.

 

Angriffe auf die Kommunikation

 

SEC Consult hat keine gesamtheitliche Sicht auf die Auswirkungen, da lediglich die OSCI-Bibliothek, nicht jedoch verwendende Anwendungen zum Test zur Verfügung standen. Mögliche hier nicht berücksichtigte mitigierende Faktoren oder nicht betrachtete OSCI-Features könnten dadurch in OSCI-Anwendungen oder deren Infrastruktur eingesetzt werden um Angriffe zu verhindern. Wir konnten die beschriebenen Szenarien jedoch mit einer geringfügig veränderten Version5 des Beispielcodes für einen passiven Empfänger nachvollziehen. Weiters wurde keine vollständige Sicherheitsanalyse durchgeführt und es kann daher nicht ausgeschlossen werden, dass weitere Schwachstellen oder Angriffsszenarien existieren.

Da OSCI-Transport den Anspruch erhebt, dass Kommunikation auch dann sicher erfolgen kann, wenn diese über unsichere Netzwerke erfolgt [1], muss man davon ausgehen, dass ein Angreifer Protokollnachrichten beliebig abfangen bzw. verändern kann. Erhält ein Angreifer eine Protokollnachricht, so ist diese i. d. R. auftragsverschlüsselt. Der Angreifer muss also im ersten Schritt diesen Sicherheitsmechanismus überwinden.

Das OSCI-Transport Protokoll sah bis zur Korrektur, welche aufgrund unserer Analysen durchgeführte wurde [5], folgende mögliche Verschlüsselungsalgorithmen vor:

  • 3DES-CBC
  • AES-128-CBC
  • AES-192-CBC
  • AES-256-CBC

Das W3C (World Wide Web Consortium) ist der Herausgeber des Standards auf dem die Verschlüsselung beruht. Es empfiehlt seit 2013 diese Algorithmen nicht mehr zu verwenden [6]. Der Grund dafür ist, dass der Verschlüsselungsmodus (CBC) in bestimmten Szenarien anfällig auf diverse Angriffe ist. Wir konnten einen dieser Angriffe (Padding Oracle) in der OSCI-Transport Bibliothek nachvollziehen. Einem Angreifer ist es so möglich, durch wiederholtes Senden besonders gewählter Nachrichten, den Empfänger oder Intermediär dazu zu bringen den Klartext preiszugeben. Dieser Angriff erlaubt es einem Angreifer an die Metadaten des Auftrags zu gelangen.

Ein bekannter Angriff, um das bei der Auftragssignatur verwendete Signaturschema (XML Signatur) zu manipulieren, ist XML Signature Wrapping. Bei einem solchen Angriff können signierte Daten durch beliebige Daten ersetzt werden. Wir konnten ein Szenario konstruieren, welches einem Angreifer erlaubt XML Signature Wrapping Angriffe gegen die OSCI-Transport Bibliothek erfolgreich durchzuführen.

Mit diesen Angriffsmitteln sind sämtliche Sicherheitsfeatures auf Auftragsebene (Signatur von Aufträgen, Verschlüsselung von Aufträgen) umgehbar. Die Sicherheitsmechanismen auf Inhaltseben sind, so diese aktiviert sind, von diesem Angriff nicht betroffen.

Da sämtliche Sicherheitsmechanismen von OSCI-Transport 1.2 optional sind, sind weitere Angriffsszenarien denkbar:

  • Ist die Inhaltsdatensignatur deaktiviert, hat ein Angreifer die Möglichkeit unter Beibehaltung einer gültigen Signatur verschlüsselte Inhaltsdaten durch beliebige andere verschlüsselte Inhaltsdaten zu ersetzen. Da asymmetrische Verschlüsselung eingesetzt wird, muss der Angreifer nicht in der Lage sein die originale Nachricht zu entschlüsseln. Dieser muss lediglich das Zertifikat des Empfängers besitzen und da dieses in jeder OSCI-Nachricht mitgesendet wird, ist es dem Angreifer bekannt2. Ähnlich kann ein Angreifer vorgehen, um die Auftragsverschlüsselung auf die manipulierte Nachricht anzuwenden.
  • Ist die Inhaltsverschlüsselung deaktiviert, so erhält der Angreifer nach einem Padding Oracle Angriff den eigentlichen Inhalt der Nachricht.
  • Wenn eine OSCI-Kommunikation ausschließlich auf die Sicherheitsfeatures auf Auftragsebene vertraut, kann ein Angreifer beliebige Nachrichten mitlesen oder verändern.

SEC Consult ist nicht bekannt ob diese Bedingungen in der Praxis tatsächlich gegeben sind. Eine genauere technische Auswertung ist hier zu finden.

 

Wer Ist Betroffen?

Das Protokoll bietet die technische Basis von E-Government in Deutschland und wurde als obligatorischer Standard für elektronische Transaktionen mit der Bundesverwaltung gesetzt [1]:

OSCI-Transport in der Version 1.2 ist Grundlage für einige der erfolgreichsten Projekte im deutschen E-Government. Auf Grund von Verordnungen des Bundes zur länderübergreifenden Datenübermittlung ist die flächendeckende Verbreitung sichergestellt.

Aufgrund der Rolle des OSCI-Transport Protokolls in der deutschen e-Government Strategie gehen wir davon aus, dass mehrere Behörden dieses Protokoll und die betroffene Bibliothek einsetzen.

Die XOEV Webseite führt zahlreiche öffentliche Standards auf, von denen einige das OSCI-Transport Protokoll einsetzen. Das OSCI-Transport Protokoll in Version 1.2 wird zum Beispiel von folgenden Standards unterstützt bzw. vorgeschrieben:

 

SEC Consult liegen keine genauen Daten über die konkrete Verwendung der OSCI-Transport Bibliothek in der Praxis vor3.

 

Behebung

Die KoSIT hat am 13.3.2017 eine fehlerbereinigte Version (1.7.1) der Bibliothek und am 30.3.2017 eine Korrektur des Standards veröffentlicht und arbeitet daran alle ihnen bekannten Nutzer der Bibliothek darüber zu informieren. SEC Consult hat keine Daten über den aktuellen Behebungsstatus.

Im Zuge der Behebung wurde eine Korrigenda der Spezifikation veröffentlicht [5]. Diese erlaubt u. A. die Verwendung verbesserter Verschlüsselungsalgorithmen.

Im Rahmen der Zusammenarbeit mit der KoSIT, dem BSI und der Governikus KG wurde die Veröffentlichung des Security Advisories abgestimmt. KoSIT, BSI, Governikus KG sowie SEC Consult empfehlen allen betroffenen Parteien die verwundbare Version der OSCI-Transport Bibliothek schnellstmöglich auszutauschen.

SEC Consult empfiehlt darüber hinaus OSCI-Kommunikation ausschließlich über etablierte gesicherte Verbindungen (z. B. IPSec, TLS) durchzuführen.

Die erste Version der OSCI Bibliothek wurde bereits 2004 veröffentlicht [7]. SEC Consult geht daher davon aus, dass verwundbare Versionen der Bibliothek seit mehreren Jahren im Einsatz sind. SEC Consult empfiehlt eine mögliche Kompromittierung im Rahmen einer forensischen Analyse zu untersuchen. SEC Consult hat keine Informationen dazu, ob Angriffe auf die OSCI-Bibliotheken bereits stattgefunden haben.

 

Diese Forschungsergebnisse wurde von Wolfgang Ettlinger (@ettisan) und Marc Nimmerrichter (@mnimmerrichter) im Auftrag des SEC Consult Vulnerability Lab erarbeitet.

 

 

Quellen

[1] http://www.xoev.de/detail.php?gsid=bremen83.c.3355.de
[2] http://www.xoev.de/die_standards/xoev_standards_und__vorhaben-11430
[3] https://www.sec-consult.com/fxdata/seccons/prod/temedia/advisories_txt/20170630-0_KOSIT_XOEV_OSCI-Transport_library_critical_vulnerabilities_german_egovernment_v10.txt
[4] http://www.xoev.de/sixcms/media.php/13/osci_spezifikation_1_2_deutsch.pdf
[5] http://www.xoev.de/sixcms/media.php/13/2017-03-30_OSCI12_Korrigenda5.pdf
[6] https://www.w3.org/TR/xmlenc-core1/
[7] http://www.osci.de/bibliothek/

1 Es werden derzeit die Versionen 1.2 sowie 2.0 des OSCI-Transport Protokolls unterstützt und eingesetzt.
2 Element CipherCertificateAddressee
3 OSCI-Transport kann in verschiedenen Kommunikationsszenarien eingesetzt werden. Im Rahmen unserer Analyse wurde nur ein Szenario betrachtet (Passiver Empfänger). Viele Sicherheitsfeatures von OSCI (z.B. Inhaltsdatenverschlüsselung) sind optional. Unter Umständen ist bei Deaktivierung bestimmter Features ein erhöhtes Risiko gegeben.
4 Das Kommunikationsmodell des passiven Empfängers wird hier genauer erklärt.
5 Wir veränderten den Beispielcode um Inhaltsverschlüsselte Nachrichten zu akzeptieren und unsignierte Aufträge zurückzuweisen.
6 Auf die angeführten Beschränkungen werden hier genauer erklärt.

Zurück