German ID Spoofing with Online Authentication and Refugee Financing in Germany

German ID

Security Specialist Wolfgang Ettlinger of the SEC Consult Vulnerability Lab described data fraud techniques (including name and address) in an online verification of German state IDs.

German ID cards are issued from November 1, 2010. Each card contains an RFID chip that stores information about the owner, including name, date of birth, and biometric photo. If the owner wants, he can record a scan of fingerprints.

New maps are machine-readable and can be used as travel documents in most European countries, as well as for authentication in online public services (tax, postal) or for checking age. They are used to authenticate users in some online services, including the tax return filing portal .

RFID authentication is performed using a card reader and eID client application (for example, AusweisApp 2 ), which communicates with the RFID chip and authentication server (eID-Server or SAML-Processor) to verify login data.



To prevent falsification of identity data, the authentication server verifies the accuracy of the information and then signs the response that is sent to the web service from the client so that the web service can trust the legitimacy of the received data.

Wolfgang Ettlinger found a way to trick the web application by sending him changed data. The screenshot shows how he successfully authenticated in the official application under the name of Johann Wolfgang von Goethe, a famous German writer. The form contains the address where the writer lived for 50 years, where the Goethe Museum is located today.



The vulnerability appeared in the Governikus Autent SDK, a software component for integrating the authentication feature into web applications. Including it implements the authentication verification function from the eID client. The point is that the check is performed in two independent steps . At the first stage, the validity of the authentication server signature is verified, and at the second stage, the data itself, including the identity of the owner. As a result, it is possible to send two independent SAML responses to the application: the first with a valid signature, and the second with fake data and without a signature.

The exploit exploits the fact that the Governikus Autent SDK verifies the signature using the methodHttpRedirectUtils.checkQueryStringwhich does not consider using the same parameter several times. Thus, after checking the parameter, other instances are analyzed as if they had already passed the test.

Here is how this method is used in a real application:

// 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 retrieves the query string, analyzes it, creates a canonical version of the query string, and verifies the signature.

Then 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);

As already mentioned, HttpRedirectUtils.checkQueryStringdoes not consider the possibility of using the parameter several times, always using the last value of the parameter.

To successfully exploit this vulnerability, an attacker needs a query string signed by an authentication server. Details such as the time of signing or the person for whom it was requested do not matter. Even if the query string is valid for a short period, validation is performed on the data on the identification card. According to the researcher, getting a valid query is not difficult if you know where to look, since they are available using Google search through eID client logs.

Researchers show their results in the video:


Vulnerable web applications running under Governikus Autent SDK 3.8.1 and earlier versions that handle repeated HTTP parameters. Vulnerability can be used, for example, to register in online services under an assumed name.

Why might need such a fake name? We can give such an abstract example. Recently, the German Interior Ministry launched the initiative “Voluntary Return” , under which it finances any foreigner who wishes to go home voluntarily. Payment of a ticket and accommodation costs less to the government than forced deportation of a refugee ( 700 versus 1500 euros ), that is, funding makes sense.


An advertising campaign in the Berlin subway: to refugees who had notified the German authorities of their voluntary departure home by December 31, is compensated for the annual rent of housing in their home country.

Theoretically, any foreigner can come to Germany, apply for refugee status, be refused - and immediately financed by this program. The only problem for a fraudster is that you can do this trick only once. Obviously, the services will then check that no benefit has been issued in his name yet. But if you register in the program under a different name, you can receive money many times (theoretically).

Of course, the state's German eID spoofing doesn’t help a fraudster with a foreign passport to arrive in Germany under a new name. But this example shows that in every security system there are necessarily vulnerabilities. The only question is the desire and resources to find them.