Tech

German eID card system vulnerable to online identity spoofing

Vulnerability in web library lets attackers spoof electronic ID card identities.

Written by Catalin Cimpanu, Contributor Nov. 21, 2018 at 8:59 a.m. PT

Security researchers have found a vulnerability in the backbone of the electronic ID (eID) cards system used by the German state. The vulnerability, when exploited, allows an attacker to trick an online website and spoof the identity of another German citizen when using the eID authentication option.

Security

There are some hurdles that an attacker needs to pass before abusing this vulnerability, but the researchers who found it say their eID spoofing hack is more than doable.

The vulnerability doesn't reside in the radio-frequency identification (RFID) chip embedded in German eID cards, but in the software kit implemented by websites that want to support eID authentication.

The vulnerable component is named the Governikus Autent SDK and is one of the SDKs that German websites, including government portals, have used to add support for eID-based login and registration procedures.

SEC Consult, the German cyber-security firm who discovered the flaw in this SDK, says it already reported the issue to CERT-Bund, (Germany's Computer Emergency Response Team), who coordinated with Governikus, the vendor, to release a patch --Autent SDK v3.8.1.2-- in August this year.

All websites who use the Autent SDK 3.8.1 and earlier are vulnerable to the vulnerability they've discovered, SEC Consult said today in a report, advising website owners to update their Autent SDK to the latest version, if they haven't done so already.

How the vulnerability works

According to the company's report, the vulnerability resides in the process of how websites deal with the responses they receive from users trying to authenticate via the eID system.

Under normal circumstances, this authentication procedure goes through the following steps:

A website sees a user initiating an eID card authentication process and requests a special response from the user.
User inserts his eID card into a card reader or places the eID card near a capable mobile phone. User enters his card's PIN code in the eID client app installed on his PC or smartphone.
The eID client app connects to one of the many authorized eID servers to verify the login request and produce a cryptographic verification signature for a response it intends to forward back to the website.
The eID client app sends an eID response (the signature and the user's personal data) to the initial website to complete the eID-based authentication procedure.
The website logs the user in or creates a new account if the user is using his electronic card to register on a site.

According to SEC Consult experts, websites using older versions of the Autent SDK accept eID client responses that contain one cryptographic signature, but multiple SAML parameters containing the user's data.

"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," SEC Consult experts explained.

"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," they added.

This sounds as an unsurmountable issue... but it actually isn't. SEC Consult says that multiple eID servers expose logs online [1, 2], and an attacker could just grab an old signed response and insert their spoofed eID data in the middle, like so:

[signature][data of fake user][real user data for signature check]

SEC Consult has published a YouTube video to showcase how an attack exploiting this vulnerability works.

But SEC Consult says this vulnerability doesn't work against all websites that support eID authentication. Experts say that online portals that have chosen to implement "pseudonyms" (instead of sending the actual user data with each authentication requests) aren't vulnerable.

Pseudonyms are randomly-looking strings that are used similarly to usernames, stored on both the website and inside the eID card's RFID chip. Unless attackers are able to guess pseudonyms in a consistent manner, they wouldn't be able to use this vulnerability to spoof the identity of other users.

Furthermore, because all eID authentication responses are logged, websites can review logs and detect when and if an attacker has ever exploited this vulnerability (by looking at eID responses with multiple repeating parameters). This also means attacks could be detected in real-time, blocking attackers trying to spoof their identity before they log in.

The good news is that SEC Consult privately disclosed this flaw over the summer, and only revealed it to the public today, giving German sites a three months head start to update the vulnerable --and very popular-- Autent SDK.

The bad news is that the Autent SDK was used in a demo app that many German websites might have downloaded and used as an example to build their own eID authentication systems, meaning the issue could be quite widespread in the German online space.

Earlier today, ZDNet has put a formal request for comment with the eID group at the German Federal Office for Information Security (BSI) and have inquired if German government portals --the vast majority of the sites using the eID authentication system-- have applied the SDK patch, and if there have been any concerted efforts to review the logs of government-managed websites for attacks that might have exploited the above vulnerability.

The issue discovered by SEC Consult is nowhere as problematic as the cryptographic issue discovered in over 750,000 Estonian eID cards in 2017. Some eID cards in Slovakia were also affected but to a lesser degree. Estonia sued Gemalto, the eID card maker, this fall. Gemalto eventually provided an update to all affected cards.

Update on November 23, 11:00am ET: Governikus, the German company behind the Autent SDK, have released a statement in which they explain that the attack scenario described by the SEC Consult team was carried out against a demo app and should not work against instances of their SDK in production-ready environments, were additional security systems are usually in place to prevent exploitation.