Qrljacking

Thank you for visiting OWASP.org. We have migrated our community to a new web platform and regretably the content for this page needed to be programmatically ported from its previous wiki page. There’s still some work to be done.

Overview

QRLJacking or Quick Response Code Login Jacking is a simple social engineering attack vector capable of session hijacking affecting all applications that rely on “Login with QR code” feature as a secure way to login into accounts. In a simple way, In a nutshell victim scans the attacker’s QR code results of session hijacking.

Login With QR codes, a feature or a bug? (Security vs Usability)

When it comes to authentication, any given system that doesn’t attain the state of balance between being sufficiently usable and secure is basically an impractical authentication system. Since the very beginning, the traditional credentials-based authentication system has taken dominance over any other alternatives. But not without many shortcomings, from risks like replay and phishing attacks to intrinsic problems like the “password fatigue” problem (in which a user is burdened with the need to remember an excessive number of passwords as part of their daily routine), we are left with non-trivial design flaws that need to be addressed.

Later on, new approaches have emerged to address these problems. One approach is the single sign-on system (a.k.a SSO), where a user can simply have one single account that enables them to authenticate to multiple services. This somewhat resolves the aforementioned “password fatigue” problem as a user no longer needs to burden himself with too many passwords to remember and no longer is tempted to develop bad habits like reusing the same password over and over again. But still it doesn’t come without its own shortcomings, as in this case, losing the one password will prevent access to all services associated with the SSO system; let alone the potential risk of mass account compromising.

Another approach that has been introduced is what’s called “one-time password (OTP)”, which tries to mitigate many risks such as replay attacks and any potential of phishing attacks to some extend. But on the downside, these passwords are typically hard to memorize, and therefore, they require additional technology to be deployed.

Recently, a new SSO model that relies on QR-code-based one-time passwords has been introduced to further address such flaws. In a QR-code-based login, a user may only need to scan a QR code generated by the service they’re trying to authenticate to, and then a client app on a trusted device such as a smartphone would scan and transmit the QR code to an identity provider in order to validate it and further authenticate the user to the destination service. Hence conducting a seamless and safe login process even on a potentially compromised device. But as we explain in detail later––depending on the implementation––such approach can be easily abused to fool a user into authenticating a malicious attacker on behalf of himself to sensitive web services, defeating the whole point of such an approach!

Related researches and projects about “Login by QR Code”

1. Login Using QR Code (Google Patents / US 20130219479 A1)

Systems and methods are disclosed herein for a user to use a trusted device to provide sensitive information to an identity provider via QR (Quick Response) code for the identity provider to broker a website login or to collect information for the website. A user may securely transact with the website from unsecured devices by entering sensitive information into the trusted device. The identity provider may generate the QR code for display by the website on an unsecured device. A user running an application from the identity provider on the trusted device may scan the QR code to transmit the QR code to the identity provider. The identity provider may validate the QR code and may receive credential information to authenticate the user or may collect information for the website. Advantageously, the user may perform a safe login to the website from untrusted devices using the trusted device

2. Smartphone Login Using QR Code (Google Patents / US 20130167208 A1)

Systems and methods are disclosed for a user to use a mobile device such as a smart phone to scan a QR (Quick Response) code displayed on a login webpage of a website. The QR code may encode a server URL of the website. The mobile device decodes the QR code and transmits a device ID and other decoded information to a service provider. The service provider locates login credentials of the user linked to the device ID and communicates the login credentials to a website server for user authentication. Alternatively, the mobile device may transmit its device ID to the website server for the website server to locate a user account linked to the device ID for user login. Alternatively, the mobile device may transmit stored login credentials to the website server. Advantageously, a user may access a website without the need to provide any login credentials.

3. SQRL Project

SQRL or Secure, Quick, Reliable Login (pronounced “squirrel” /ˈskwɝl/ About this sound en (help·info)) (formerly Secure QR Login) is a draft open standard for secure website login and authentication. The software solution typically uses a QR code, which provides authentication, where a user identifies anonymously rather than providing a user ID and password. This method is thought to be impervious to a brute force password attack or data breach. It shifts the burden of security away from the party requesting the authentication and closer to the operating system implementation of what is possible on the hardware, as well as to the user. SQRL was proposed by Steve Gibson of Gibson Research Corporation in October 2013 as a way to simplify the process of Authentication protocol, without revealing any information about the transaction to a third party.

What is QRLJacking Attack?

QRLJacking or Quick Response code Login Jacking is a simple-but-nasty attack vector affecting all the applications that relays on “Login with QR code” feature as a secure way to login into accounts, In a simple way, It’s all about convincing the victim to scan the attacker’s QR code.

QRLJacking Attack Flow

Here’s how the QRLJacking attack works behind the scenes:

  1. The attacker initial a client side QR session and clone the Login QR Code into a phishing website. “Now a well-crafted phishing page with a valid and regularly updated QR Code is ready to be sent to a Victim.”

  2. The Attacker Sends the phishing page to the victim. (refer to QRLJacking real life attack vectors)

  3. The Victim Scans the QR Code with a Specific Targeted Mobile App.

  4. The Attacker gains controls over the victim’s Account.

  5. The service is exchanging all the victim’s data with the attacker’s session.

QRLJacking Attack Flow

QRLJacking Implications

1. Accounts Hijacking

QRLJacking attack gives attackers the ability to apply a full account hijacking scenario on the vulnerable Login with QR Code feature resulting in accounts stealing and reputation affection.

2. Information Disclosure

When the victim scans the QR code they are giving the attacker much more information like for example (their accurate current GPS location, Device type, IMEI, SIM Card Information and any other sensitive information that the client application presents at the login process)

3. Callback Data Manipulation

When the attacker receives the data which we clarified in the “Information Disclosure” point, Some of this data is used to communicate with the service servers to clarify some information about the user which can be used later in the user’s application. Unfortunately sometimes this data is exchanged over insecure network connection which makes it easy for this data to be controlled by the attacker giving them the ability to alter or even remove it.

QRLJacking Requirements

As mentioned before one of the attack’s advantages relays in it’s simplicity, So all what the attackers need to do to initial a successful QRLJacking attack is to write a script to regularly clone the expirable QR Codes and refresh the ones that is displayed in the phishing website they created because as we know a well implemented QR Login process should have an expiration interval for the QR codes (during our tests some services doesn’t have that).

So all what we need here is: Attacker (Script kiddie as a minimum required skills) + QR Code Refreshing Script (on the attacker side) + well crafted phishing web page/script and a Victim.

QRLJacking and Advanced Real Life Attack Vectors

As we all know, If we combined more than one attack vector together we can have a great result. QRLJacking attack can be combined with a powerful attack vectors and techniques to make it more reliable and trustworthy. Here are some examples:

1. Social Engineering techniques (Targeted Attacks)

A skilled social engineer attacker will find this mission easy to convince the victim to scan the QR Code by cloning the whole web application login page with an exact one but with their own attacker side QR Code.

2. Hacked highly-trusted websites and services

Hacked websites are prone to be injected with a script that displays an Ad or a newly added section displays a cool offer if the user scanned this QR Code with a specific targeted mobile application their account will be hijacked.

3. SSL Stripping

SSL Stripping is an attack which is all about strip the ssl website and force it to work on a non secured version. Web sites without “HSTS Policy” enabled are prone to be stripped which gives the attacker multiple choices to manipulate the content of the website pages by for example, “altering the QR Code login sections”.

4. Content Delivery Networks (CDNs Downgrading)

A well implemented Login by QR Code feature uses a base64 QR code image generated and well placed in a secured page which will make it very difficult to be manipulated if this website is working over HTTPS and forcing HSTS, but unfortunately a lot of web applications and services uses a CDN based QR image generation process. These CDNs itself are sometimes stored on a servers vulnerable to HTTPS Downgrading attacks. Attackers will find a way to downgrade these secure connections, redirect the CDN URLs to their own QR Code, and since the QR Code is an image this will result in a “passive mixed content” hence the browser will not find any problems by viewing it on the web application login page instead of the original one.

5. Non-secure Traffic over LAN

This is the most suitable attack vector for attacking users over Local Area Networks by exploiting the non secured websites and manipulate traffic, The attacker here is performing MITM (Man in the Middle Attack) against their local area network, poisoning the traffic on the fly by injecting a JS file on every non secured web page.

6. Bad Implementation / Logic

Bad implementation logic of the QR code logins may result into a more easy accounts takeover scenarios. During our research we found a specific example: A chat app asks you to scan other people’s QR code to add them as friends, until here it’s normal and there are no problems, but when it comes to the login process it’s a big problem. Unfortunately, the application implemented the “login by QR code” feature on the same screen that you’re using to add a friend, so imagine that someone cloned their login qr code and told you “Hey, This is my QR Code, scan it to be my friend, you scanned it, Boom” you lost your account.

QRLJacking vs Clickjacking

As known, clickjacking is all about abusing the style of a sensitive web page hiding and covering and manipulating some elements to convince the victim “for example” to change their account’s main email address and password to the attacker’s one, but what if the attacker succeeded in that and after a while they want to login to the victim’s account and found that this account has 2 Factor Authentication feature enabled!!! Of course the attack is ruined and the whole thing became useless.

QR Login feature was presented to be Single Sign-On and a 2 Factor Authentication layer and because of that reason it is considered the final defence line that give the users both security and usability. “Scan me to login” it’s so easy, secure and efficient way to login on a daily basis. QRLJacking is here to mess that usability and security implementation.

It’s obvious now why is QRLJacking attack is more severe than a regular Clickjacking one.

Defending against QRLJacking (Recommendations and Mitigations)

Our top recommendation is to just stop using Login with QR code except when it is necessary also there is a lot of ways to mitigate such issue and here is some ways to be used together or standalone:

  1. Session Confirmation, We recommend implementing a confirmation message/notification displaying characteristic information about the session made by the client/server.

  2. IP Restrictions, Restricting any authentication process on different networks (WANs) will minimize the attack window.

  3. Location-based Restrictions, Restricting any authentication process based on different locations will minimize the attack window.

  4. Sound-based Authentication, One of the techniques to mitigate this kind of attack [And maintain the same usability level as to not require any additional interaction from the user other than scanning the QR ] is to add sound-based authentication step to the process , we have seen this kind of technology where it is possible to generate unique data and convert it to audio that can be recognized back into its original form [SlickLogin and Sound-Proof] so it is possible to include this technology in the process.

The purposes of this added step is to make sure that scanned QR code is generated in the same physical location as the mobile device that is doing the scan and therefore eliminating the possibility of a remote attacker deceiving the user into scanning their qr code.

Nomal Login Scenario

The Attack Scenario (with the mitigation): Attacker visits the website and opens a session.

  1. The Website Generates QR Code which holds a session key.

2. Attacker crafts a phishing website with the received QR Code and sends it to the user.

  1. User scans the attacker’s QR Code in the phishing website.

  2. The mobile App generates the authentication sound and play it to the phishing website.

  3. The phishing website fails to process and capture the authentication audio as it requires additional browser permissions.

  4. Even if the attacker tries to generate the authentication sound based on the (User ID) they still lack the private key.

Mitigation Scenario

Related Vulnerabilities

  • Clickjacking

More information

For more information on QRLJacking tools and extra, please visit the QRLJacking on Github

References

Proof of Concept examples (Videos)

Watch Star