Implementation of an universal forgery on the Austrian BürgerkartePosted: February 29, 2012
The Austrian Citizen Card (Bürgkerkarte) is a smartcard which allows citizens to authenticate against E-Government (web-)applications, sign online forms, log in to online banking and even sign banking transactions. The Citizen Card contains 2 keypairs: one to create advanced signatures (RSA, e.g. e-mail signatures) and another one to create qualified signatures (ECDSA). A qualified signature is the electronic equivalent to a handwritten signature.
In order to use the Bürgerkarte a BKU software (Bürgerkartenumgebung). The BKU provides a webserver with a standardized programming interface. To make the BKU software platform independent and more convenient to use, the Technische Universität Graz implemented an online BKU. This software consists of a signed Java applet and a Java servlet component (which communicates through a web service called STAL). The Java applet is vulnerable to an attack which I am going to explain here.
simplified sequence diagram of an XmlRequest to an Online BKU installation with LiveConnect attack:
This allows Mallory to implement the following attack:
- Mallory sets up a web page wich implements a Citizen Card login (e.g. age verification, identity verification for web shops, etc.).
- After Alice has authenticated using her Bürgerkarte, she is redirected to the page she was expecting. This page however, contains a neat little script that fetches signing requests (an XML document) from the attackers webserver (e.g. through XMLHttpRequests) and invokes the signed applet. The applet can be loaded to a position off the screen, which makes it completely invisible to Alice. As the user already has accepted the signature of the signed applet (during login) and the signed applet has not been modified, no dialog is shown to ask the users permission.
- Bang! Mallory was able to sign arbitrary data using Alice’s Citizen Card without her noticing it!
This attack now allows Mallory to create qualified signatures on PDF documents (e.g. contracts), sign in to online banking services and sign transactions (e.g. Raiffeisen ELBA) . When trying to sign on to e-government applications this attack normally does not work, because the Java applet checks whether the webserver uses an SSL-certificate issued to an “.gv.at” domain when requesting the “IdentityLink” InfoBox.
The proof of concept
During my research I have implemented a PoC that demonstrates this attack.
Music: Chrome – Werdegang from (free) Paranoia EP
Note that this code has PoC quality. A faster and more reliable way to implement this attack could be changing the servlet or implement command chaining .
In the latest release of the Mocca project (1.3.7) this has been fixed (see ) .
However, since the signatures on the old applets are still valid and java does not check OCSP and CRLs by default, the attacker can still implement this attack by using an outdated version of the applet. In order to really fix this issue the applet has to be added to the applet-blacklist of the JRE.