23.11.2018 – Diese Information dient der Klarstellung der aktuellen (November 2018) Berichterstattung zu einer Schwachstelle im Governikus Autent Software Development Kit (SDK) in der Version 3.8.1 und der daraus resultierenden und von der Presse aufgegriffenen Rückschlüsse zu unsicheren Implementierungen der eID-Funktion des deutschen Personalausweises.

Im vergangenen Jahr wurde im Rahmen eines Anwenderforums zur AusweisApp2 von Governikus ein Demobeispiel auf Basis des Governikus Autent SDK vorgestellt, um die unkomplizierte und schnelle Implementierung der eID-Funktion des Personalausweises bei Diensteanbietern zu verdeutlichen. Dieses Demobeispiel wurde auch öffentlich zum Download zur Verfügung gestellt, ohne das vollständige Governikus Autent SDK zu beinhalten.

Das Unternehmen SEC Consult hat anhand dieses Demoszenarios, das ausdrücklich zu keinem Zeitpunkt den Anspruch hatte, eine vollumfängliche Implementierung im Realbetrieb vorzunehmen, eine Prüfung auf Schwachstellen vorgenommen und im Juli d.J. dem CERT-Bund eine Schwachstelle gemeldet.

Das von SEC Consult beschriebene Angriffsszenario bedient sich des Umstandes, dass im Demoszenario des Autent SDKs die Prüfung einer „SAMLResponse“ zwar korrekt durchgeführt, anschließend aber ein weiterer angehängter Parameter mit dem Namen „SAMLResponse“ verarbeitet wird. Während die Prüfroutine aus dem Autent SDK kommt, handelt es sich bei der Verarbeitung der SAMLResponse um einen Standardaufruf auf der Servlet API (getParameter) und ist somit Teil der Beispiel-Implementierung und hat nichts mit dem Autent SDK zu tun.

Die im Autent SDK enthaltenen Demoszenarien sind, wie aus dem Namen ersichtlich, zur Demonstration der Bibliotheken gedacht. Sie hatten und haben allerdings nicht den Anspruch, weitere Sicherheitsmaßnahmen, die im Realbetrieb erforderlich sind, zu erwähnen oder gar zu implementieren. Diese müssen durch die jeweiligen Diensteanbieter bzw. Betreiber solcher Dienste ergriffen werden, zum Beispiel zum Schutz vor XSS-Angriffen, SQL-Injection, Replay-Angriffen usw. Diese URL-Prüfungen sind die Maßnahme, die den Angriff verhindert. Das von der OASIS spezifizierte und offene Protokoll „SAML Web Browser SSO Profil“ (Redirect Binding) findet hier Anwendung.

Das SAML Protokoll ist bewusst so offen, dass weitere Parameter übermittelt werden können, wenn das von der entsprechenden Anwendung benötigt wird. Die Prüfungsregeln für den Diensteanbieter ergeben sich u.a. aus dem Standard selbst (https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf, Abschnitt 3.4.4.1 „(…) the relying party MUST ensure that the parameter values to be verified are ordered as required by the signing rules above“).

Die zu ergreifenden Maßnahmen ergeben sich aus OASIS- und OWASP-Empfehlungen, welche von unseren Kunden im Rahmen der Integration beachtet und als Voraussetzung bei der Implementierung genannt werden. In diesem Fall sind besonders die Empfehlungen von OWASP (https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet) zu beachten. Aber selbstverständlich müssen anwendungsbezogen weitere Maßnahmen umgesetzt werden.

An dieser Stelle nochmals der Hinweis: Das Demo-Szenario enthält nicht das vollständige Autent SDK und kann so nicht für eine vollständige Implementierung einer im realen Betrieb durchgeführten Personalausweisintegration verwendet werden und sollte lediglich verdeutlichen, wie einfach eine Implementierung vorgenommen werden kann! Dass allerdings im Realbetrieb weitere Maßnahmen im Rechenzentrum durchgeführt werden müssen, war nicht Bestandteil des Demoszenarios.

Wir stimmen insofern mit der Einschätzung überein, dass ein Beispiel häufig ungewollt übernommen wird, auch wenn die beigelegte Readme-Datei darauf hinweist, dass es eine Demo ist, welche zudem nur auf localhost läuft. Deswegen haben wir bereits im August 2018 einen Quick-Fix in die entsprechende Routine aufgenommen, die einen Fehler zurückmeldet, wenn relevante URL-Parameter (SigAlg, SAMLResponse, RelayState) tatsächlich mehr als einmal vorkommen. Diese Aktualisierung haben wir unseren Kunden umgehend zur Verfügung gestellt.

Diese inhaltliche Prüfung wird in Realszenarien durch die o.g. Umsetzung der OASIS- und OWASP-Empfehlungen allerdings auch vor der Verarbeitung im SDK bereits durchgeführt. Selbstverständlich läuft das SDK nur in Java-Umgebungen und die Online-Ausweisfunktion ist auch nur eine Anwendungsmöglichkeit.

Darüber hinaus ist das SDK ein Produkt der Governikus. Daher kann es nicht stellvertretend für die Online-Ausweisfunktion stehen.

Der sowohl von SEC Consult als auch von einigen Berichterstattern aufgegriffene Rückschluss, sämtliche mit Autent realisierten Integrationen der eID-Funktion des Personalausweises wären unsicher, ist damit schlicht und ergreifend falsch.

Statement to reports of a vulnerability in the Governikus Autent SDK

This information is intended to clarify the current coverage (November 2018) concerning a vulnerability in the Governikus Autent Software Development Kit (SDK) version 3.8.1 and the resulting conclusions drawn from the press about insecure implementations of the eID function of the German ID card:

Last year, Governikus KG presented a demo sample based on the Governikus Autent SDK, in the context of a Governikus AusweisApp2 user forum, to illustrate the straightforward and rapid implementation of the eID function of the German ID card for service providers. This demo example was also publicly available for download without including the full Governikus Autent SDK.

SEC Consult has used this demo scenario, which at no time was expressly intended to carry out a full implementation in real operation, to check for vulnerabilities and in July of the previous year reported a vulnerability to the CERT-Bund.

The attack scenario, described by SEC Consult, makes use of the fact that in the demo scenario of the Autent SDK, the inspection of a “SAMLResponse” performs correctly, but then a further attached parameter by the name “SAMLResponse” is processed.

While the check routine origins from the Autent SDK, processing the SAML response is a standard call to the servlet API (getParameter) and is thus part of the example implementation and has nothing to do with the Autent SDK.

The demo scenarios included in the Autent SDK are intended to demonstrate the libraries, as the name implies. However, they did not and do not claim to mention or even implement further security measures that are required in real operation. These must be taken by the respective service providers or operators of such services, for example to protect against XSS attacks, SQL injection, replay attacks, etc. These URL inspections are the measure that prevents the attack. Here, the open “SAML Web Browser SSO Profile” protocol (Redirect Binding) specified by OASIS is used.

The SAML protocol is deliberately open so that further parameters can be transmitted, if needed by the respective application. The inspection rules for the service provider arise among others from the standard itself (https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf, section 3.4.4.1 “(…) the relying party MUST ensure that the parameter values to be verified are as required by the signing rules above “). The measures to be taken result from OASIS and OWASP recommendations, which are taken into account by our customers as part of the integration and are cited as a prerequisite for their implementation. In this case, especially the recommendations of OWASP are to be considered (https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet).

Nevertheless, additional measures have to be implemented on an application-related basis. Again, the note: The demo scenario does not include the full Autent SDK, so it cannot be used to fully implement a German ID card integration in a live operating environment and should just clarify how easy an implementation can be! However, that further measures must be carried out in a live operating environment in data processing centres was not part of the demo scenario.

We agree with the assessment that an example is often taken over unintentionally, even if the included readme file indicates that it is a demo, and besides that only runs on localhost. That is why we included a quick-fix in the corresponding routine in August 2018 that returns an error if relevant URL parameters (SigAlg, SAMLResponse, RelayState) actually occur more than once. We have made this update available to our customers immediately. This content inspection is indeed carried out in real scenarios prior to processing within the SDK, by implementing the OASIS and OWASP recommendations Of course, the SDK only runs in Java environments and the online identification function is just one possible application.

Furthermore, the SDK is a product of the Governikus KG. Therefore, it cannot act on behalf of the online identification function.

The conclusion drawn up by both, SEC Consult and some of the journalists that all integrations of the eID function implemented by Autent would be insecure, is quite honestly wrong.

Beitrag teilen