Security assessment of mobile QR readers – Updated (30-Nov-2011)

Abstract:
Quick Response code, also known as QRCode has been around for several years, but in the last months there has been an incline in adoption of QRcodes as a marketing channel. A QRcode can encode a variety of information into a 2-dimentional barcode that is presented to the costumer. Customers are often referred by vendors into scanning QRCodes in order to receive coupons, discounts or other marketing media such as website, flash movie etc. The QRCode is parsed by QR-reader software on a mobile phone equipped with a camera. The true nature of QRcode content is an enigma until it is scanned; there is no possibility for the customer to authenticate the content of a QRcode without scanning it first. Because of the latter fact, an attacker with evil intent could craft a malicious QRCode (or evilQR) and lure an innocent customer to scan it. Once scanned the evilQR would be parsed by the customer mobile phone software and would initiate its’ attack. Attack vectors could vary from browser-based such as Cross-Site-Scripting (XSS) to specific buffer-overflow and command injection. The key for a successful attack lays in the default behavior of the mobile QRCode reader software. If as an example, a QRCode reader parses a link from a evilQR and preforms a URL redirection without proper confirmation of the customer – the attack would succeed. In this assessment we have compared the default behavior of several QR-readers for and noted their behavior upon the parsing of two evilQRs. Best practices for mobile users are also discussed.

The problem:

An innocent customer can be easily tricked into scanning a malicious-crafted QRCode (evilQR) by an attacker, upon scanning the customer mobile would be attacked by the encoded payload.

Motivation:

The motive for executing such attack is very clear – the mobile phone is a gold mine for an attacker, because today’s phone contains very sensitive information such that can be abused by an attacker in several ways:

Personal information compromised by an attacker could lead to impersonation, phishing and identity theft

Calendar and meetings compromised by an attacker could lead to business or other information disclosures.

Address book compromised by an attacker could lead to impersonation, phishing and identity theft

Private and Cooperative email access compromised by an attacker could threaten internal business IT infrastructure.

Geo-location compromised by an attacker could lead to harassment, surveillance and privacy loss

Connectivity – (3G, GPRS, Wi-Fi, Blue-Tooth, etc.) could enable the attacker to remote control his attack

Credit card information compromised by an attacker

Social networking accounts (Twitter, Facebook, Path, LinkedIn, etc.) compromised by an attacker could lead to defacement, impersonation phishing and identity theft

Assessment:

Our assessment goal was to verify that QRCode reader software will not process an evilQR payload without proper confirmation from customer. In order to perform the test two test cases were created:

a. JavaScript QRCode:

evilQR 1: QRCode with Java-script alert payload

In the first test case we have encoded a simple java-script code into an evilQR. The java-script that was used was very simple – an alert message that is shown upon parsing. This test demonstrates a simple case of a Cross-Site-Scripting web attack (XSS). In this kind of an attack the customer web-browser is lured into executing malicious code on behalf of the customer current context and permissions. The object of this test case was to test the autonomous parsing capabilities of the QRCode reader software. If the QRCode reader software executes the java-script code without proper confirmation of the customer – the test is regarded as failed, whereas if the QRCode reader software executes the java-script code only after customer notification – the test is regarded as success.

b. Web link to a malicious site:

evilQR 2: QRCode with payload: http://www.appsec-labs.com

In the second test case we have encoded a simple web link into an evilQR. The web link refers to http://www.appsec-labs.com as an example for an evil website. This test demonstrates a simple case of a phishing web attack. In this kind of an attack the customer web-browser is lured into visiting a malicious website that will attack the customer. The object of this test case was to test the autonomous website redirection capabilities of the QRCode reader software. If the QRCode reader software performs redirection to the encoded website URL without proper confirmation of the customer – the test is regarded as failed, whereas if the QRCode reader software executes the website redirection only after customer notification – the test is regarded as success.

In hope to shed light on the likelihood of this attack, we have chosen fourteen different QRCode reader applications, and kept their setting to the default. For each application we performed two scanning cycles. The first was aimed to test the autonomous java-script parsing of the QRCode reader application using the first test case. The second was aimed to test the autonomous parsing of website URLs by the application.

Results:

The QRCode reader assessment comparison chart is shown below (Table 1). We can learn that from the selected applications only one was found vulnerable to java-script evilQR (QuickMark). Furthermore, we can deduce that about 35% of the applications that were used were found vulnerable to direct website redirection. These results confirm our prior assumption that QRCode reader application may be used to introduce a malicious evilQR and to inflict an attack on an unaware customer. What more can be learned from the table below is the fact that the current QRCode reader applications parsing of java-script is not yet fully supported by the majority but could be but could be in the near future.

Application

Test a: java-script parsing

Test b: website redirection

TapReader (TapBase LLC)

No Parsing

User confirmation

QR+ (Alexandr Balyberdin)

No Parsing

User confirmation

QRReader (Tap Media Ltd)

No Parsing

Automatic Redirection

Scan (QR Code City, LLC)

No Parsing

Automatic Redirection

RedLaser (Occipital, LLC)

No Parsing

User confirmation

i-nigma (3GVision Ltd)

No Parsing

Automatic Redirection

BeeTagg (connvision AG)

No Parsing

User confirmation

QR Code Reader (ShopSavvy, Inc.)

No Parsing

Automatic Redirection

QuickMark (SimpleAct Inc.)

JavaScript Execution

Automatic Redirection

QR+Emoji (Ching-Lan Huang)

No Parsing

User confirmation

Bakodo (Dedoware Inc.)

No Parsing

User confirmation

Optiscan (Airsource Ltd.)

No Parsing

User confirmation

QR-Scanner (Grip’d LLC)

No Parsing

User confirmation

quiQR (Mark Tholking)

No Parsing

User confirmation

QR Code City, LLC (updated by Michael)

No Parsing

Optional confirmation

RedLaser eBay, Inc (updated by Michael)

No Parsing

User confirmation

ATTScanner (updated by TBone Steak)

No Parsing

User confirmation

QR Droid Private (DroidLa) (updated by Israel)

No Parsing

User confirmation

Bakodo (iOS) (updated by Steaven)

No Parsing

User confirmation

Posted (iOS) (updated by Steaven)

JavaScript Execution

User confirmation

NeoReader (X10 mini) (updated by mbr)

Parsing

User confirmation

Table 1: Comparison table of application performance in two tests

From these results we can confirm that the evilQR attack vector is indeed a widespread phenomenon, and it should be taken into consideration by customer and application vendors.

Recommendations:

Many QR-reader software are delivered with default setting of the QR reader to interact with URI links automatically. This behavior may expose the mobile user into scanning an evilQR which will be parsed and trusted by the user’s QR-reader software.
As a general security recommendation to our customers follow these thumb rules:

You should choose a configurable QR-reader software that enables you to confirm QR-code output prior to its’ acceptance.

Never scan a QR-code that has an unknown origin

You can check your mobile QR-reader vulnerability by scanning the two evilQR (you can postback your results so we can update the table)

Update for Scan (QR Code City, LLC)
-User confirmation is optional, but is turned off by default

One additional note: I see a privacy issue with the History Sync function. This is a completely optional function that saves your history to qrcodecity.com for later retrieval with any web browser. I don’t see a privacy policy anywhere on their web site.

The interesting thing about the first test you did was that the link isn’t a valid link, it’s just a payload. I just did a quick test with a complete URL and QR Code Reader (ShopSavvy, Inc.) does in fact launch the exploit.

Simply want to say your article is as amazing. The clearness in your post is simply nice and i can assume you are an expert on this subject. Well with your permission allow me to grab your RSS feed to keep updated with forthcoming post. Thanks a million and please carry on the gratifying work.

Good day, I can say thanks to you the exact autor with the online site. Practically all is obvious or precious. The looks could also be wonderful on behalf of me. You please tel all of us styles format ever incorporate? thanks a lot as soon as again and consequently resume favorable career.

Wonderful goods from you, man. I have consider your stuff prior to and you are simply extremely fantastic. I really like what you’ve bought right here, certainly like what you’re stating and the way by which you are saying it. You’re making it entertaining and you continue to take care of to keep it wise. I can not wait to learn far more from you. That is really a tremendous web site.

I do like the way you have presented this specific problem plus it really does offer us some fodder for consideration. On the other hand, through what precisely I have observed, I simply just hope when the reviews stack on that people keep on point and not embark on a soap box regarding the news du jour. All the same, thank you for this excellent point and though I can not really concur with it in totality, I respect your perspective.

NeoReader (default app with X10 Mini Pro Nordic); Parsing (as in it gives a dialogue with …) and confirmation required for URL redirection. Configurable whether or not to confirm first. Default setting is set to confirm before action.

I’m curious as to whether the optional preview available via QR Droid presents an additional risk. I can’t tell whether it’s being preloaded without user confirmation, or if it waits until the “Preview” button is pressed, nor do I know whether viewing the preview is functionally equivalent to visiting the site directly. Anyone care to confirm?