How Does The Attack Work?
The affected software component (Governikus Autent SDK) allows organizations to easily integrate id card authentication into a web application. For example, it implements the checks required to establish the validity of an authentication result received from an eID client. This verification process is conducted in two steps:
- To verify that the result has not been manipulated, its digital signature is verified. If the result is not correctly signed by the authentication server, the authentication process is aborted.
- Next, the data itself is inspected. For example, the expiration date of the data is checked. Then the data is further processed by the web application.
The identified vulnerability allows an attacker to provide different data for each of these verification steps. For the first step, an attacker can send a response with a valid signature. As the signature would be verified correctly, the second step is executed. For this step, the attacker can send a manipulated response without a signature. This response is considered valid and is further processed by the web application.
Technical Details
The authentication process can either employ a SOAP-based protocol (eID) or a SAML-based variant. The vulnerability affects the SAML-based protocol. In essence, SAML authentication works as follows (for details see BSI TR-03130):
- The user selects to authenticate using an id card in the web application. The web application then redirects to a loopback address. When using the demo application the accessed URL would look like this:
127.0.0.1/eID-Client - On this local port, the eID client listens for incoming connections. After the browser navigates to the URL, the eID client initiates authentication. It communicates with the web application, the authentication server and the RFID chip in the id card.
- When the user’s identity has been established, the eID client sends a SAML response containing the data read from the id card to the web application using a HTTP GET request:
<host>/<pfad> Response>&RelayState=[...]&SigAlg=<Signatur-Algorithmus>&Signature=<Signatur>
Often SAML authentication schemes require the assertion in the SAML response to be signed using an XML signature. The id card authentication implements the Web Browser SSO Profile as specified by OASIS. This scheme does not require the Assertion to be signed. Instead, a signature over the query string (all HTTP parameters) is generated and appended to it (as parameter “Signature”). - Up until this step, the browser has been waiting for a response to the request sent in step 1. The eID client now responds to this request with a redirect back to the web application (HTTP 302). The user is now authenticated within the web application.
To verify the signature sent in step 3, the Governikus Autent SDK offers the method HttpRedirectUtils.checkQueryString. The following excerpt from the demo application demonstrates how this method is meant to be used:
// check the signature of the SAML response. There is no XML signature in this response but the // parameter are signed. if (!HttpRedirectUtils.checkQueryString(request.getQueryString(), SamlExampleHelper.SERVER_SIG_CERT)) { storeError(request, response, "Signaturprüfung der SAML-Response fehlgeschlagen!"); return; }
The method receives the query string, parses it, creates a canonical version of the query string and verifies the signature.
Afterwards, the SAML response is parsed:
// get the parameter value String samlResponseBasee64 = request.getParameter(HttpRedirectUtils.RESPONSE_PARAMNAME); [...] // parse the SAML Response. ParsedResponse parsed = parser.parse(samlResponse);
The vulnerability abuses the fact that HTTP allows multiple parameters having the same name. When the method HttpRedirectUtils.checkQueryString creates a canonical version of the query string, it parses the parameters from it and generates a new query string with the parameters placed in a specific order. The case that a parameter can occur multiple times, is not considered.
The behavior of the Servlet API differs from the behavior of this method: While HttpServletRequest.getParameter according to the Servlet specification always yields the first parameter of a given name, the method HttpRedirectUtils.checkQueryString uses the last occurrence of a parameter.
If an attacker supplies multiple parameters named SAMLResponse, the signature is verified against the last occurrence of the parameter, while the SAML response that is processed further, will be taken from the first occurrence.
Exploit Scenarios
To exploit this vulnerability, an attacker requires at least one valid query string signed by the authentication server. It does not matter for which citizen or at which time the signature for the query string has been issued. Of course, such a query string is only valid for a very short time. However, the expiration check is conducted on the manipulated data.
An authentication server may be dedicated to a single web application or it can serve multiple applications. In practice, a shared instance is often used (the server eid1.eid-service.de is e.g. used by at least the BStU, the Justice Department and the German Pension Fund). A query string signed by an authentication server can be used against any associated web application.
The easiest way for an attacker to obtain a signed query, is to conduct an authentication with his own id card. This means that the SAMLResponse with the attacker’s information appears in the web server’s access log during an attack thus making it trivial to identify the attacker. An attacker could also obtain signed query strings from sever logs or a log from the eID client such as the AusweisApp or the alternative Open Ecard. Logs for these applications can easily be found online, conducting a simple Google search (e.g. “richclient_info.log SAMLResponse” or “AusweisApp2 filetype:log”).
Demo
This video demonstrates how an attacker could authenticate as a fictitious person “Evil Attacker” against the demo application.
Attack Restrictions
The described attack works only partially for services that require an initial registration. The id card authentication specification includes the concept of pseudonyms. A pseudonym is a random-looking string generated by the id card. For each web application, the id card generates a different pseudonym. When the user creates an account, the pseudonym is stored by the web application. During login, the web application only requires to request the pseudonym string from the id card and compare it with the values stored in its user database.
As another user’s pseudonym is not easily guessable, an attacker cannot login as another user. The account creation step, however, is still affected by this vulnerability as the attacker could simply generate a random pseudonym.
Moreover, this attack is only applicable to web applications that use the method HttpServletRequest.getParameter. If an application rejects multiple parameters with the same name, the vulnerability cannot be exploited. A web application firewall (WAF) configured to reject multiple parameters of the same name would also prevent this attack.
Who Is Affected?
Affected are web applications that use versions less or equal to 3.8.1 of the Governikus Autent SDK for SAML authentication and handle duplicate HTTP parameters as described above.
SEC Consult does not have detailed information which web applications were vulnerable to this attack. We expect a large number of web applications to be vulnerable, assuming that
- many applications typically handle HTTP parameters as described above (i.e. they use the method HttpServletRequest.getParameter), especially since we expect many applications to be developed with demo application being used as a template.
- such requests would not be blocked since there are several legitimate cases where multiple parameters with the same name are used (e.g. passing arrays in PHP).
As this component was available through ausweisapp.bund.de during our research, a large number of web applications (maybe all) might be using this library. The demo application, which also included the affected SDK, is no longer available for download anymore on Governikus’ website.
The Fix
We have informed the CERT-Bund about this vulnerability in July 2018. The CERT-Bund (BSI) took on further communication and coordination with the vendor. In August 2018, Governikus released a patched version (3.8.1.2) of the Autent SDK and informed affected customers.
We recommend organisations that still use the vulnerable version to upgrade to the latest version immediately. As the described attack leaves distinct traces in the web server’s access log, we also recommend affected organisations to conduct a forensic analysis of the relevant log files.
Update 2018-11-26
In an official statement and on Twitter, Governikus KG recently suggested that SEC Consult and media outlets misrepresented a vulnerability that has been published in our blog. As the SEC Consult Vulnerability Lab always strives to be as precise and accurate as possible, including all public communication, Governikus received both the technical advisory and the blog post beforehand (see “Vendor Contact Timeline” in our advisory).
Our security consultants have been in contact with Governikus via CERT-Bund since July 2018 and incorporated Governikus’ feedback into the final version of our blog post before it was released. Up to this point we experienced the communication with Governikus to be very professional and solution oriented.
As Governikus states that the attack is not possible with real applications, we want to disclose the circumstances of the vulnerability identification: The mentioned authentication bypass vulnerability was identified during a 3rd party project of an internet-facing web application. In order to simplify communication with both Governikus and the public, we opted to replicate the vulnerability with a publicly available software component (i.e. the Governikus Demo application which was publicly available then) instead of the actual implementation of the 3rd party.
Through that, we are aware that at least this application and the demo application were indeed vulnerable to the attack. We did not (and would never) conclude in our publication that all applications that facilitate the Governikus Autent SDK are vulnerable. However, we thoroughly analyzed the technical details of this vulnerability and described the attack preconditions and limitation to the best of our knowledge as described in our blog post.
This research was conducted by Wolfgang Ettlinger (@ettisan) on behalf of SEC Consult Vulnerability Lab and has been published as a security advisory.
