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.