Implementation of an universal forgery on the Austrian Bürgerkarte

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.

The vulnerability

Every modern Browser implements Java LiveConnect, an API to call Java methods from JavaScript and vice versa. As a signed applet has higher privileges than an unsigned applet, this API can introduce security issues. Fortunately, methods called from JavaScript run in a context which is very similar to the context of an unsigned applet. Therefore it is not possible to use the classes in the applet to access the card because those methods use certain privileged code. An attempt to use those methods from JavaScript would result in an Exception being thrown.

However, LiveConnect normally allows JavaScript to access user interface elements. With the Online-BKU applet it is was possible to read/write text-/password fields and simulate button clicks. As the applet implements a worker thread to communicate with the smartcard (and runs in a signed context), the UI thread does not need to have a privileged context. The worker thread obtains the PIN from the UI and executes the requested action (e.g. sign a document). Therefore a JavaScript is able to sign documents without user interaction.

simplified sequence diagram of an XmlRequest to an Online BKU installation with LiveConnect attack:

The 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.).
  • When Alice enters her signature-PIN Mallory’s script fetches the entered PIN (through JavaScript) and saves it (e.g. in a cookie). This is similar to a classic phishing attack and could also be completely implemented in JavaScript (by faking a BKU applet).
  • 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.
  • The JavaScript now enteres the previously captured PIN(s) and simulates a button press on the “Sign” button. The applet signs the signing request and sends the signing response (with the signed data) back to the server.
  • 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 “” 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 [1].

The “fix”

In the latest release of the Mocca project (1.3.7) this has been fixed (see [2]) .

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.




About these ads

9 Comments on “Implementation of an universal forgery on the Austrian Bürgerkarte”

  1. [...] Beschreibung des Angriffs zufolge lässt sich das auch mit einem selbstgemachten Applet erreichen, das sich mit den [...]

    • ettisan says:

      Das würde natürlich nicht funktionieren, da ein Applet mit einer gültigen Signatur benötigt wird. Hat Golem wohl falsch verstanden

  2. Franz Ackerl says:

    schon länger intern bekannt….aber du bist der erste ders öffentlich macht ;)

  3. [...] In this talk Wolfgang discussed some of the issues he discovered when testing the security of the Austrian Citizen Card. In Austria this card can be used to officially sign documents and prove the identity of the holder. This includes the ability to sign-in to online banking using the card and a pin to prove the holder is who they say they are. Wolfgang showed a number of vulnerabilities in the BKU (the Java based environment that deals with PIN authentication and card communication) and showed the ability for an attacker to steal the PIN and use it to sign documents or perform actions as the user. A more detailed write-up is available on Wolfgang’s blog. [...]

  4. [...] consultant Wolfgang Ettlinger has discovered a disadvantage in a Austrian Citizen Card that allows enemy to travesty a certification of their [...]

  5. [...] Die österreichische Bürgerkarte, die ähnliche Signierfunktionen wie hierzulande der nPerso hat, ist erneut angreifbar: Ein Angreifer kann die Java-basierte Online-Version der Bürgerkartenumgebung (BKU) missbrauchen, um etwa Banktransaktionen zu autorisieren oder PDF-Dokumente mit der qualifizierten Signatur des Opfers (gleichbedeutend mit einer Unterschrift auf Papier) zu unterzeichnen. Dies hat der Sicherheitsexperte Wolfgang Ettlinger herausgefunden. [...]

  6. rschz says:

    Eine Zuordnung eines elektronischen Dings zu einem Menschen ist nicht
    moeglich : Computer-/Kommunikationsnetzwerke sind (fast) beliebig
    Traditionelle Informationen koennen elektronisch kontaminiert sein.

  7. [...] Angriff beschreibt Wolfgang Ettlinger im Artikel “Implementation of an universal forgery on the Austrian Bürgerkarte“. (function() { var po = document.createElement('script'); po.type = [...]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.