Modern problems require modern solutions, this applies to the finance sector as well. So what problems am I talking about?

Digital Invoices in a Mixed Payment Slip Landscape

In Switzerland we are currently using multiple different variations of payment slips for invoices. There are four different types. Two of them are orange and the other two are red. One of each color is issued by banks, while the other one is issued by PostFinance. For most of them you need an E-Banking App on your phone that scans a special “ESR” Code on the slip. It can handle the four different types and turn them into a digital one to pay it (or you could go analogue and go pay it at the teller).

The QR code invoice aims to reduce the four types into one handy “Swiss QR Code” Invoice which would allow the use of existing and maintained technology (like the ZXing library) to read the code. This way, users can scan it with their smartphone (even without E-Banking App) and see the contents of it. It also means that developers do not need to handle different types of “ESR” codes, thus making development easier or at least more maintainable.

But is this solution reliable and secure?

In this article, we are going to examine, how I could read, manipulate and defraud payers and beneficiaries of the QR code invoice with a tool that I created in a morning.

The new QR Code Invoice

The QR code Invoice consists of multiple parts as described by the picture taken from the implementation guidelines[2].

The guidelines[2] are very detailed for each section, including font size and style, spacing between elements in mm and size of the different parts.

The interesting parts for us are:

  • “QR code area” (the QR code itself)
  • “Details area” which includes account, payer and payee information
  • “Amount area” which contains the amount in CHF or EUR

Both, the contents from the details and amount areas are included in the QR code.

The interesting bit about these parts is their relation to the QR code. The contents of the parts should be equal to what is in the QR code, yet they are not linked by any means. They are not protected by signatures, apps are not required to perform an OCR or any other methods to ensure that the data from the QR code matches the human-readable parts of the QR code Invoice.

This means, that an adversary could change the contents of the QR code, while leaving the other parts untouched to trick their victims into performing unwanted payments, if they don not double-check the amount and payment notes.

The question is, how could an attacker do this?

QR Invoice Editor

As mentioned at the beginning of the post, I built a tool to do this. It can be integrated into Greenshot as a plugin, and thus makes everything as easy as capture a screenshot, like you would normally do.

Let us take the example QR code from the implementation guidelines:

We can take a screenshot and open it up using my tool

Which will open a window, where we can read the data of the invoice, edit it and generate a new QR code from it:

It also offers the option to look at the raw data and generate QR codes for whatever you want:

We can now manipulate the raw data of the code via one of the editor options and generate a new one, that will “send” the money to our bank account:

You can now scan the code for yourself and see that we were able to create a new QR code.

That is not something special per se, since QR code generation is possible since QR codes are a thing, but an adversary could use this and trick victims.

Let us examine a potential scenario for that.

Wär häts erfunde? – A Swiss Attack Vector

In Switzerland we get billed an annual tax for radio and television (formerly collected by Billag AG, now done by Serafe AG). The new company that collects the taxes, makes use of the QR code Invoice.

This means that an attacker could create his own version of the Invoice and send it to every citizen in Switzerland. Usually the invoice is sent by (snail-) mail, but alternatively you can get it as a PDF in an email.

An unobservant citizen might open up the letter or email, read that it is about our radio and television tax and pay it. Additionally, this could be done for other taxes as well.

To automate the whole process, an adversary could write an Excel- Add-In, fill out a table and run the “generate QR Code” method.

Using the core-components of the QR Editor from above (A Swiss QR Code Engine if you wish), I created such an Add-In.

With my little PoC Add-In I was able to generate the QR code for the invoices for an entire list of users. The tool allows you to map certain table headers with fields of the QR code for easy configuration.

A more sophisticated tool would generate the entire Invoice for the attacker and send it via (e)mail.

How can we prevent this?

The same thing that applies to phishing and social engineering in general, can be helpful in this case: Awareness.

Make sure that the contents of the QR code Invoice matches the other areas. Usually when scanning Invoices with an e-banking app, it shows the content of it, so visual comparison between with the app and the Invoice letter/email is possible.

Banks and Banking App suppliers are well advised to correlate and check payee and IBAN information as well as applying OCR to run enhanced comparison between the human readable parts and the QR code to prevent their customers falling easy victims.

Another Option would be to add some kind of signature to each QR code, that would uniquely identify the invoice issuer and would make it possible to simplify approval of integrity protected invoices. Similar to JWTs and the tickets of the federal railways.

I sadly could not find the reference for the federal railways signing, but pbock has reverse engineered the German version of it, on this github repo.

References

  1. Die QR-Rechnung Merkblatt; PaymentStandards.ch; November 2018;
    https://www.paymentstandards.ch/dam/downloads/merkblatt-qr-de.pdf; Accessed 12.4.2019
  2. Swiss Payment Standards 2018Schweizer Implementation Guidelines QR-Rechnung; SIX,PaymentStandards.ch; Version 2.0;valid from 15. November 2018; https://www.paymentstandards.ch/dam/downloads/ig-qr-bill-de.pdf; Accessed 12.4.2019
  3. Serafe AG; Serafe AG; -; https://www.serafe.ch/en/; Accessed 24.4.2019

Credits

Hat tip to KRM for the inital idea and risk assessment work. Kompetenzzentrum Records Management, www.informationgovernance.ch