Flaw allowing identity spoofing affects authentication based on German eID cards
23.11.2018 securityaffairs Vulnerebility

The authentication process via German eID cards with RFID chips is flawed, an attacker could impersonate any other citizen.
The nightmare comes true, the authentication process via German eID cards with RFID chips is flawed and a flaw could allow an attacker to allow identity spoofing and changing the date of birth.

The situation is very serious, the new cards are accepted as an ID document in most countries in Europe and allow the German citizens to access online government services (i.e. tax service).

The German ID cards issued since November 1st, 2010, store holder’s information (i.e. name, date of birth, a biometric picture, and optionally fingerprints) in the embedded radio frequency identification (RFID) chip.

The cards could be used to authenticate the holder via the RFID chip, in this scenario, it is possible to use an eID application (i.e. AusweisApp) along with an RFI smartcard reader.

The mutual authentication leverages a PKI infrastructure, the authentication process starts with the web application sending a request to the eID client that initiates all further steps needed for the authentication, and requests it a PIN.

The web application communicates with an authentication server (eID-Server or SAML-Processor) providing it the data contained in the RFID chip (i.e. the name or date of birth of the citizen).

To prevent eavesdropping, the response is digitally signed by the authentication server.

Security researchers at SEC Consult Vulnerability Lab demonstrated that is possible to spoof the identity of a German eID card holder and alter data.

The security expert Wolfgang Ettlinger at SEC Consult Vulnerability Lab discovered a flaw in the Governikus Autent SDK that could be used by companies to implement the ID card authentication to a web service via German eID cards.

The expert devised a method to alter the digitally signed response from the server making it still valid for the client, it was able to authenticate with an arbitrary name (he used the name of the popular writer Johann Wolfgang von Goethe and his address) against a demo version of the AusweisApp eID client.

The expert discovered that Governikus Autent SDK verifies the signature doesn’t implement the management of a parameter with same name occurring multiple times. This implies that the parameter is validated just one time, other instances are parsed as if they already passed verification.

“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.” reads the analysis published by the expert.

“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.”

All the attacker needs is a query string signed by the authentication server, no matter how long it is valid because the expiration check is conducted on the manipulated data. According to the expert, this information could be easily obtained using a Google search for eID client logs.

Ettlinger published a video PoC of the attack:

The vulnerability affects Web applications running Autent SDK 3.8.1 and earlier that handle duplicate HTTP parameters.

SEC Consult privately reported technical details of the issues to CERT-Bund in July and Governikus released the version 3.8.1.2 its SDK to fix the flaw.

Experts pointed out that the 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.” conclude the experts.

“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.”