11/23/2018 - This information serves to clarify the current (November 2018) reporting on a vulnerability in the Governikus Autent Software Development Kit (SDK) version 3.8.1 and the resulting conclusions about insecure implementations of the eID function of the German ID card that have been picked up by the press.
Last year, a demo example based on the Governikus Autent SDK was presented by Governikus as part of a user forum on the AusweisApp2 to illustrate the uncomplicated and rapid implementation of the eID function of the ID card at service providers. This demo example was also made publicly available for download without including the full Governikus Autent SDK.
The company SEC Consult used this demo scenario, which explicitly did not claim at any time to be a full-scale implementation in real operation, to check for vulnerabilities and reported a vulnerability to the CERT Bund in July of this year.
The attack scenario described by SEC Consult makes use of the fact that in the demo scenario of the Autent SDK the check of a "SAMLResponse" is performed correctly, but subsequently another appended parameter with the name "SAMLResponse" is processed. While the checking routine comes from the Autent SDK, the processing of the SAMLResponse is a standard call on the servlet API (getParameter) and is thus part of the sample implementation and has nothing to do with the Autent SDK.
The demo scenarios included in the Autent SDK are intended, as is clear from the name, to demonstrate the libraries. 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 checks are the measure that prevents the attack. The open protocol "SAML Web Browser SSO Profile" (Redirect Binding) specified by OASIS is applied here.
The SAML protocol is deliberately open so that additional parameters can be transmitted if required by the corresponding application. The verification rules for the service provider result, among other things, 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 ordered as required by the signing rules above").
The measures to be taken are derived from OASIS and OWASP recommendations, which are observed by our customers in the course of integration and mentioned as a prerequisite during implementation. In this case, the OWASP recommendations (https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet) must be observed in particular. But of course, further measures must be implemented based on the application.
At this point, we would like to point out once again that the demo scenario does not contain the complete Autent SDK and cannot therefore be used for a complete implementation of an ID card integration carried out in real operations. However, the fact that further measures have to be carried out in the data center in real operation was not part of the demo scenario.
We agree with the assessment that an example is often adopted unintentionally, even if the attached readme file indicates that it is a demo, which also only runs on localhost. That's why we already added a quick fix to the corresponding routine in August 2018, which reports back an error if relevant URL parameters (SigAlg, SAMLResponse, RelayState) actually occur more than once. We immediately made this update available to our customers.
However, this content check is already performed in real scenarios by the above-mentioned implementation of the OASIS and OWASP recommendations even before processing in the SDK. Of course, the SDK only runs in Java environments and the online ID function is also only one possible application.
Furthermore, the SDK is a product of Governikus. Therefore, it cannot be representative for the online badge function.
The conclusion drawn by both SEC Consult and some reporters that all integrations of the eID function of the ID card implemented with Autent are insecure is therefore simply wrong.
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 centers 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.