EvilQR – When QRCode goes bad

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:

Figure 1: QRCode with Java-script alert payload

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:

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

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:

  1.  You should choose a configurable QR-reader software that enables you to confirm QR-code output prior to its’ acceptance.
  2. Never scan a QR-code that has an unknown origin
  3. You can check your mobile QR-reader vulnerability by scanning the two evilQR (you can postback your results so we can update the table)


39 replies
  1. Michael
    Michael says:

    RedLaser (eBay, Inc.; portions licensed from ZXing; available for iPhone and Android)
    No parsing
    User confirmation

    Reply
  2. Michael
    Michael says:

    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.

    Reply
    • Chilik
      Chilik says:

      Thanks for the update Michael, will be updated in the table soon.
      The issue with sending information to outer server without proper user acknowledgement is a pain point in today mobile applications

      Reply
  3. Ari Elias-Bachrach
    Ari Elias-Bachrach says:

    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.

    In other words, make a QR code for the a full URL which includes an exploit and payload. (IE http://www.victim.com/page?var=alert(123)), and it will execute just fine.

    Reply
    • Chilik
      Chilik says:

      Agree that is the disturbing feature of an advanced QR code reader, you don’t need any hosting for the payload; you can encode it directly into the QRCode

      Reply
    • Chilik
      Chilik says:

      That is correct Ari, and it is strongly linked to the session management functionality of the mobile browser

      Reply
  4. Mylene
    Mylene says:

    Good article, but asking for user confirmation does not solve much, when people just confirm (as they most of the times do)…

    Reply
  5. Dave
    Dave says:

    I agree with Mylene in that many people will simply confirm w/o much thought.

    Perhaps a QR “checksum” of sorts which can be verified against a public whitelist is the answer?

    Reply
    • Chilik
      Chilik says:

      That is a good idea, the only problem is that if it had been tampered – how would you tell? What will prevent the attacker from spoofing the content and the checksum as well ?

      Reply
  6. Michael
    Michael says:

    Ari, isn’t that then just dependent on the site and the browser? I think that the original test is valid to determine if the code reader itself will execute Javascript.

    Reply
  7. camping gear
    camping gear says:

    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.

    Reply
  8. jeux wii pas cher
    jeux wii pas cher says:

    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.

    Reply
  9. Google QR Code Generator
    Google QR Code Generator says:

    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.

    Reply
  10. outlet store abercrombie
    outlet store abercrombie says:

    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.

    Reply
  11. mrb
    mrb says:

    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.

    Reply
  12. Steven
    Steven says:

    Posted (iOS):
    I would say N/A for both but just to be sure I tested.
    No Parsing and doesn’t use URL.

    Reply
  13. Dog Boy
    Dog Boy says:

    Good article, nice test of current QR readers.

    Please ensure that you update the table as more User Generated tests come in and have you contacted the various “failed” QR reader providers to let them know of your testing?

    If you are going to publically claim their products offer a potential security flaw, they should be notified and given the opportunity to reply, rectify or both.

    Reply
  14. Mark
    Mark says:

    ZXing’s Barcode Scanner 3.72 (Android):
    No parsing
    User confirmation

    QR Droid:
    No parsing
    User confirmation WITH PREVIEW

    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?

    Reply
  15. Lucy Martin
    Lucy Martin says:

    Great piece of info! I just impressed to read this helpful article. I’m really enriched my knowledge from this site. Thanks for this allocation.

    Reply
  16. Bruno Ferreira
    Bruno Ferreira says:

    Just crossed this, sorry about posting on an old post, but I need to update that the Windows Phone 7.8 built-in QR scanner does not executes JavaScript but automatically redirects on a link

    Reply

Trackbacks & Pingbacks

  1. […] cet article de AppSec Labs, ils comparent le comportement par défaut de plusieurs lecteurs de QRCodes par rapport à leur […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *