Vulnerability In EU Cross-Border Authentication Software (eIDAS Node)

research vulnerability

During a short crash test SEC Consult identified a critical vulnerability in the eIDAS-Node software component that could allow an attacker to impersonate any EU citizen.

Image of GOETHE with tagline "Target identified" - SEC Consult

Last year SEC Consult demonstrated an attack against a software used for identifying German citizens online where anyone could assume an arbitrary identity. Now it was time to think a lot bigger and have a look at a similar software that is used all across the European Union.

In June SEC Consult had a look at eIDAS-Node. This is a software library that allows Member States to take part in the cross-border authentication scheme eIDAS. Each Member State has its own mechanism to authenticate its citizens – eIDAS interconnects these national eID schemes. For instance, this allows any EU/EEA citizen to use a national idenfication scheme to authenticate against a service in another Member State. SEC Consult again found a critical vulnerability that allowed an attacker to authenticate as the famous writer “Johann Wolfgang von Goethe” – or any living citizen.

My Name Is Johann Wolfgang Von Goethe – I’m Back To Prove It (Again)

eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation that (among other things) defines a way for citizens to authenticate using their national electronic identification scheme (eID) when accessing services from other member states. It is intended to allow citizens to file tax declarations, enroll in a university, open bank accounts, pay online etc.. Citizens can still use their existing national eID schemes – eIDAS provides the regulation and standards for attaching national eID schemes into the European eIDAS network.

The following blog post provides an overview about the critical security vulnerability. For further technical details and proof of concepts see our security advisory here.

eIDAS overview

As an example, if an Italian citizen wants to authenticate against a German online service, first the German eIDAS-Node (eIDAS-Connector) is directed by the web application to initiate the authentication process. It sends a request to the Italian eIDAS-Node (eIDAS-Service). The Italian eIDAS-Node forwards the user to a system that is equipped to authenticate the Italian citizen using the national eID scheme. After authentication, the German eIDAS-Connector receives the citizen’s information which it forwards to the web application.

Image shows schematic sequence of an authentication - SEC Consult
Schematic sequence of an authentication

eIDAS relies on SAML for communication between the eIDAS-Connector and eIDAS-Service (collectively called eIDAS-Nodes). Anyone who’s had a closer look at SAML knows that it’s a very complex protocol which makes it very flexible, but also somewhat fragile and prone to implementation errors. The fact that SAML is used for eIDAS communication piqued our interest to find out whether there might be implementation flaws in the software used.

As each Member State must provide its own eIDAS-Node, the European Commission has provided the eIDAS-Node Integration Package, which can be used as a basis for implementing such a service. As SEC Consult expected many Member States to use this software, we had a closer look and specifically looked at its SAML parsing code. SEC Consult found a vulnerability that basically allowed an attacker to bypass the signature verification, allowing an attacker to send any SAML message to an affected eIDAS-Node. The attacker could therefore e.g. send a manipulated SAML response to an eIDAS-Connector to authenticate as anybody.

Visualization of trust store attack - SEC Consult
Visualization of the attack

On a technical level, the vulnerable code was used to verify the trust of the certificate the SAML response was signed with. The code works as follows:

  1. The certificate is accepted if it is in the local trust store
  2. Otherwise, the issuer certificate of the entity certificate is retrieved from either the local trust store or from the supplemental certificates in the SAML message.
  3. If a trust path can be established between the issuer certificate and a certificate in the trust store, the entity certificate is accepted.

In step 2, the issuer certificate is retrieved from the trust store solely by matching the Issuer DN of the entity certificate with the Subject DN of the certificates in the trust store. Therefore, the entity certificate signature is not verified against the public key in the issuer certificate. An attacker can create a certificate with an arbitrary public key whose Issuer DN matches one of the Subject DN’s of the trusted certificates.

Banner of eIDAS-Node Authentification Bypass - SEC Consult

The following video demonstrates this issue by, as in tradition, authenticating as “Johann Wolfgang von Goethe”:

As SEC Consult explored other versions of the eIDAS-Node software, it was found that version 2.1 contained a similar vulnerability (see official advisory). As this version is no longer supported, SEC Consult highly recommend anyone using it to upgrade as soon as possible.

The Fix

SEC Consult contacted the CEF eID team in July 2019. They have since released an updated version 2.3.1 that has been distributed to Member States in advance during the responsible disclosure process. The patched version is now available for public download.

SEC Consult like to thank the European Commission CEF team for their quick and professional handling of this vulnerability report!

Interestingly, in 2018 the Ruhr University Bochum conducted a large scale test of common vulnerabilities in eID schemes. Their efforts would probably also have identified this vulnerability if the vulnerable version would have been deployed by then.

This research was conducted by Wolfgang Ettlinger (@ettisan) on behalf of SEC Consult Vulnerability Lab.

Back