Signature validation vulnerability in German ID card allows impersonating any

The German government-issued identity card (nPA) allows German citizens to not only prove their identity in person, but also against online services (by using the embedded RFID chip). SEC Consult conducted a short security test on a software component commonly used to implement this authentication mechanism. Acritical security vulnerability was found during this security test,allowing an attacker to impersonate arbitrary users against affected web applications.

Since November 1 st , 2010 the German government issues identity cards that contain an RFID-chip. These chips enable German citizens to authenticate against a range of online services. As the authentication allows citizens to prove their real identity, web applications no longer need to verify the data a user enters during registration in a separate step (e.g. a manual id card check). Several public and private organisations allow this login mechanism (e.g. the online tax filing portal , several De-Mail services, several insurance companies ), as it offers a more user-friendly experience.

To use the online authentication functionality, a citizen requires a suitable smartcard reader as well as a client software (an eID client, e.g. the AusweisApp 2 ). To start an authentication, the web application sends a request to the eID client, which then initiates all further steps needed for the authentication. It requests a PIN from the user, communicates with an authentication server (eID-Server or SAML-Processor), the web application and the RFID chip and finally sends a response to the web application. This response contains the data retrieved from the id card, e.g. the name or date of birth of the citizen.

To prohibit an attacker from manipulating this data, the response is digitally signed by the authentication server (which takes on the role of a trusted third party). If an attacker would attempt to manipulate the data being sent, the web application would not be able to verify the signature and abort the identification process.

The SEC Consult Vulnerability Lab identified a vulnerability that allows an attacker to arbitrarily manipulate the response without invalidating the signature. An attacker could therefore abuse this vulnerability e.g. toalter data coming from the id card,fool age verification or authenticate as any other citizen.

Successful authentication as “Johann Wolfgang von Goethe” against a demo application (previously available for download at: https://www.ausweisapp.bund.de/fuer-diensteanbieter/diensteanbieter-werden).

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 thedemo applicationthe accessed URL would look like this:
http://127.0.0.1:24727/eID-Client?tcTokenURL=https%3A%2F%2Flocalhost%3A8443%2FAutentSAMLDemo%2FNewRequesterServlet 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:
https://<host>/<pfad>?SAMLResponse=<SAML 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 canonicalversion 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 behavi