Before we start we need to explain some frequently mentioned terms which are: QR Code, SSO and Clickjacking.
What is QR Code?
QR code (abbreviated from Quick Response Code) is the trademark for a type of matrix barcode (or two-dimensional barcode) first designed for the automotive industry in Japan. A barcode is a machine-readable optical label that contains information about the item to which it is attached. A QR code uses four standardized encoding modes (numeric, alphanumeric, byte/binary, and kanji) to efficiently store data; extensions may also be used.
The QR Code system became popular outside the automotive industry due to its fast readability and greater storage capacity compared to standard UPC barcodes. Applications include product tracking, item identification, time tracking, document management, and general marketing.
A QR code consists of black modules (square dots) arranged in a square grid on a white background, which can be read by an imaging device (such as a camera, scanner, etc.) and processed using Reed–Solomon error correction until the image can be appropriately interpreted. The required data are then extracted from patterns that are present in both horizontal and vertical components of the image.
-Source: “Wikipedia, Section A, QR code”
What is Single Sign On (SSO)?
Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in with a single ID and password to gain access to a connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system. This is typically accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on servers. A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain.
Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.
As different applications and resources support different authentication mechanisms, single sign-on must internally translate and store credentials for the different mechanisms, from the credential used for initial authentication.
Other shared authentication schemes not to be confused with SSO include OAuth, OpenID, OpenID Connect and Facebook Connect, which require the user to enter their login credentials each time they access a different site or application.
-Source: -“Wikipedia, Section A, Single sign-on”
What is Clickjacking Attack?
Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
-Source: -“OWASP, Section A, Clickjacking”
We are in an era where passwords are going to be an extinct term. Easy logins, Fingerprints and 2FAs techniques are taking over now. One of the most efficient methods that was presented in August 2013 is “Login using QR Code” which was patented by Google Inc. under the patent number (US20130219479 A1). This form of Login methods promised to combine both usability and security.
With QRLJacking attack vector we proved the opposite, Can QR codes be logged by a Keylogger, MITMed over network, or even stolen ? of course NO.
Quick Response code Login Jacking or (QRLJacking) is a simple-but-nasty attack vector affecting all the applications that relies 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. So simple isn’t it?
Attackers are able now to easily hijack user accounts in an efficient way even if the Login by QR 2FA is enabled which is considered a Single Sign On and the last defense line of authentication.
In this research paper we’re going to demonstrate how this could be done with a real life attack vector to prove how nasty and easy it is.
Security vs Usability
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 his 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 him 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 compromisation….
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 memorise, 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 he’s 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”
Login Using QR Code
Google Patents / US 20130219479 A1
Abstract 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
Smartphone Login Using QR Code
Google Patents / US 20130167208 A1
Abstract 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.
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 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.
QRLJacking Attack Flow
Here’s how the QRLJacking attack works behind the scenes:
1. The attacker initialize 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. (a lot of efficient attack vectors are going to be clarified later in the paper)
3. The Victim Scans the QR Code with a Specific Targeted Mobile App.
4. The Attacker gains control over the victim’s Account.
5. The service is exchanging all the victim’s data with the attacker’s session.
Figure(1) How QRLJacking Attack works
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.
When the victim scans the QR code he is giving the attacker much more information like for example (his accurate current GPS location, Device type, IMEI, SIM Card Information and any other sensitive information that the client application presents at the login process)
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 him the ability to alter or even remove it.
As an example, WhatsApp sends back the browser version, OS version and the current location of the browser. Thanks to QRLJacking attack, this data is now on the attacker’s side, Attacker can intercept and alter this data to poison the login logging date on the victim side. see figure (2) and figure (3)
Figure(2) WhatsApp Application logging data was manipulated on the victim side. Disclaimer: This issue was reported on Sep 28, 2015 under their Support website and we got no reply (Report Numbers: 22730155, 22808794 and 24029036)
Figure(3) Burpsuite Proxy intercepting the callback data in the attacker’s side while the QR is generated Disclaimer: This issue was reported on Sep 28, 2015 under their Support website and we got no reply (Report Numbers: 22730155, 22808794 and 24029036)
As we mentioned before one of the attack’s advantages relays in it’s simplicity, So all what the attackers need to do to initialize a successful QRLJacking attack is to write a script to regularly clone the expirable QR Codes and refresh the ones displayed on the phishing website which 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 didn’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) + a well crafted phishing web page/script and a Victim.
QRLJacker – QRLJacking Exploitation Framework
A customizable framework to demonstrate “QRLJacking Attack Vector” and shows How easy to hijack services that rely on QR Code Authentication!
Currently QRLJacker supports the following websites :
QRLJacking and Advanced Real Life Attack Vectors
As we all know, If we combine few attack vectors together we can have a greater result. QRLJacking attack can be combined with other powerful attack vectors and techniques to make it more reliable and trustworthy. Here are some examples:
Social Engineering Techniques (Targeted Attacks)
A skilled social engineer attacker will find it easy to convince the victim to scan the QR Code by cloning the whole web application login page with an exact one but with his own attacker side QR Code.
Highly Trusted Hacked Websites
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 his account will be hijacked.
SSL Stripping is an attack vector which is all about striping the SSL encryption of a website and forcing 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”.
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 themselves are sometimes stored on servers vulnerable to HTTPS Downgrading attacks. Attackers will find a way to downgrade these secure connections, redirect the CDN URLs to his 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 viewing it on the web application login page instead of the original one.
Non-secure Traffic over LAN
This is the coolest attack vector for attacking the local users which exploits the non secured websites over the Local Area Networks, The attacker here is performing MITM (Man in the Middle Attack) against his local area network, poisoning the traffic on the fly by injecting a JS file on every non secured web page resulting in what is clearly shown in figure(4) below.
Figure(4) – A simple lightbox injected in Amazon’s http website asking the user to scan the QR Code to get a 1 Year as a free service of WhatsApp. (Disclaimer: This issue was reported on Feb 18, 2016 under their Support website and we got no reply (Report Numbers: 24058882 and 24058883)
Bad Implementation / Logic
Bad implementation logic of the QR code logins may result in 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 his 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 we explained earlier in this paper, clickjacking is all about abusing the style of a sensitive web page by hiding, covering and manipulating some elements to convince the victim “for example” to change his account’s main email address and password to the attacker’s one, but what if the attacker succeeded in that and after a while he wants 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 becomes 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 defense line that gives 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 so obvious now why is QRLJacking attack is more severe than a regular Clickjacking one.
Vulnerable Web Applications and Services
There is a lot of well-known web applications and Services which are vulnerable to this attack till the date we wrote this paper. Some examples include but not limited to:
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 his qr code.
Figure(5) An illustration of the login process [QR code login + Sound authentication]
The Attack Scenario (with the mitigation):
1. Attacker visits the website and opens a session.
2. The Website Generates QR Code which holds a session key.
3. Attacker crafts a phishing website with the received QR Code and sends it to the user.
4. User scans the attacker’s QR Code in the phishing website.
5. The mobile App generates the authentication sound and play it to the phishing website.
6. The phishing website fails to process and capture the authentication audio as it requires additional browser permissions.
7. Even if the attacker tries to generate the authentication sound based on the (User ID) he still lacks the private key.
Figure(6) An illustration of the login process [QR code login + Sound authentication] attacks & mitigation