Cross-Site-Scripting in the Online Citizen Card Environment

The Austrian Citizen Card (Bürgkerkarte) is a smart card which allows citizens to authenticate against E-Government (web-)applications, sign online forms, log in to online banking and even sign banking transactions. In order to use the Bürgerkarte a BKU software (Bürgerkartenumgebung, Citizen Card Environment) is needed. The BKU provides a web server with a standardized programming interface. To make the BKU software platform independent and more convenient to use, the Technische Universität Graz implemented the MOCCA OnlineBKU1. A few months ago I have found a Cross-Site-Scripting vulnerability in this software, allowing an attacker to inject JavaScript code into the browser origin of the OnlineBKU installation and consequently in the origin of many web applications using the OnlineBKU. This issue has been fixed after it has been reported to the developers. Updated and properly configured applications are not vulnerable anymore.

The vulnerability

The OnlineBKU consists of a Java Applet that runs on the clients browser, a Java Servlet component and the actual application. The Applet is used to communicate with the smart card and the user, while the server component handles the communication to the application. The application is the component that then processes the data signed by the users citizen card. A successful signing procedure happens as following:

  1. The clients browser sends (HTTP POST) a request to a servlet. This requests contains the request to the Citizen Card Environment (XMLRequest), some Applet parameters (appletGuiStyle, appletWidth, appletHeight, etc.) and the DataURL.
  2. The Servlet responds with an HTML document that embeds the Java Applet. This document is normally shown in an iframe.
  3. The clients browser loads the Applet. The Applet then communicates with a Servlet.
  4. The user interacts with the Applet (e.g. signes a document).
  5. The Applet sends the signed data to a Servlet. The Servlet posts the signed data to the DataURL defined by the application (see step 1).

The application now has several options to respond to the DataURL request 2. Depending on the HTTP status code and the response data, the Citizen Card Environment behaves differently. This allows the application to e.g. send consequent XMLRequests. One of the options available is to return plain HTML with status code 200. The Citizen Card Environment should in this case show the document in the clients browser. Therefore, the Applet redirects the browser to a Servlet that responds the HTML document. As the document originates from a Servlet in the Citizen Card Environment, JavaScript on that page also runs in the context of the Citizen Card Environment. As many providers install the Citizen Card Environment on the same host as the actual application (often as https://server/bkuonline), this flaw also allows to steal session cookies of many applications. One problem may still be obvious: the victim has to sign a document. However, the specification of the Citizen Card Environment defines aNullOperationRequest, that only sends aNullOperationResponseto the DataURL → no user interaction needed to inject JavaScript code (XSS).

The attack

An attacker can do the following:

  1. The victim visits an attacker controlled web page while being logged in on an application that uses a vulnerable Citizen Card Environment.
  2. The attacker prepares (and submits using JavaScript) an HTML form that sends a NullOperationRequest with a forged DataURL to the this Citizen Card Environment.
  3. The clients browser shows the response document with the Java Applet (e.g. hidden in an invisible iframe), the Servlet send the NullOperationResponse to the attacker controlled DataURL.
  4. The attackers server responds to this request with an HTML document containing a malicious JavaScript.
  5. The Applet running on the victims browser redirects to the HTML document (retrieved from the attacker) that is now shown in the origin of the Citizen Card Environment. The JavaScript is executed by the victims browser and may now steal session cookies (Cross-Site-Scripting).

The proof of concept

To demonstrate this issue I have written a tiny HTML page that demonstrates this issue: It sends a forged request to a specified OnlineBKU installation and prints cookies of the that are visible in the origin of the OnlineBKU installation. As many installations have been updated now (and the proof of concept does not work any more on those installations) i have made a short video demonstrating the issue:

The fix

Beginning with version 1.3.8 of the MOCCA OnlineBKU4 the allowed DataURLs have to be specified in a configuration file (as regular expressions). When configured correctly, that fixes this issue.






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.




Software-Update for Austrian Citizen Card vulnerable to MITM

TL;DR: Update-Mechanism of A-Trust BKU did not check SSL-Server-certificate before version

Long story:

The Austrian Citizen Card (Bürgerkarte) is a Smartcard that allows every citizen to make qualified digital signatures, which should be equivalent to handwritten signatures. In order to use the Bürgerkarte a Software (Bürgerkartenumgebung, BKU) is needed, either a locally installed or a Java applet (Mocca). The most widely spread locally installed BKU is the “A-Trust BKU”, which has been around since November 2008.

I was wondering how the update mechanism worked and found that it uses HTTPS to fetch an “update.ini” which contains information about the latest version. I was curious and created an update.ini file, altered the hosts-file and…. it worked.

When A-Trust BKU thinks it has found an update it shows this window:

After the update has been downloaded it simply gets executed (UAC elevated!):

An update to version fixes this problem.