Vulnerability in the QR Code of the Izly Phone Application

Vulnerability in the QR Code of the Izly Phone Application

Speakers: Clément Gindrier, Independent Security Researcher

Conference: GreHack

YouTube: https://www.youtube.com/watch?v=E5vZr5fKt9U

Overview

In this GreHack talk, independent security researcher Clément Gindrier details a critical vulnerability he discovered and reported in the Izly mobile payment application. Izly, developed by Experian (a branch of BPCE, France's second-largest banking group), is an indispensable payment solution for over a million students across French university campuses, primarily used for purchasing meals in university restaurants and cafeterias. The core of the vulnerability lay in a fundamental flaw in the cryptographic integrity mechanism of the QR codes used for payments, specifically an improperly implemented HMAC (Hash-based Message Authentication Code). This allowed an attacker to generate fraudulent QR codes, enabling free and untraceable payments from any Izly user's account. Gindrier's presentation not only dissects the technical specifics of the flaw but also highlights the significant challenges faced during the vulnerability disclosure process and the ultimate success in prompting a comprehensive system overhaul by Izly. The talk serves as a compelling case study on the importance of secure cryptographic design, thorough security testing, and effective vulnerability reporting channels.

The vulnerability was particularly severe due to its ease of exploitation, requiring no advanced technical skills or specialized equipment beyond a mobile phone. Attackers could impersonate other users, making payments from their accounts without their knowledge or consent, and remain completely untraceable. Compounding the issue, the flaw had persisted for several years, dating back to at least 2017, underscoring a long-standing security oversight in a widely adopted financial application. Gindrier’s efforts led to a complete re-architecture of Izly’s payment system, replacing the flawed HMAC with a more robust digital signature scheme and improving overall application security, demonstrating the profound impact that independent security research can have on critical infrastructure.

Background

▶ Watch: Introduction to Izly: French student payment application (0:40)

Izly serves as a vital digital wallet for students in France, facilitating payments for essential services like meals. Launched approximately eight years ago by Experian, a subsidiary of the major banking group BPCE, Izly has garnered over a million downloads, making it a cornerstone of campus life. Its widespread adoption is partly due to practical necessities: many campus establishments struggle with cash payments, and roughly half of checkouts do not accept credit cards. Beyond convenience, Izly also provides critical benefits, such as subsidized or free meals for scholarship holders and students in precarious financial situations, further embedding it into the daily lives of its users.

The payment process in Izly appears straightforward: users create an account, top it up, and then generate a QR code on their phone, which is scanned at the point of sale. Crucially, these QR codes can be generated offline, meaning users can make payments even without an active internet connection on their device. The QR code's primary function is to identify the payer. Gindrier's initial investigation into the system began by examining the structure of these QR codes. He discovered that the QR code text was not just a simple identifier but a structured string containing several pieces of information: the user ID (which was the user's phone number), a date and time stamp, and, theoretically, an HMAC. The presence of the HMAC was intended to guarantee the integrity of the data within the QR code, ensuring that the user ID and transaction details had not been tampered with. This cryptographic mechanism was supposed to be a shared secret between the application and the server, allowing the server to verify the authenticity of the QR code upon scanning. However, as Gindrier uncovered, the implementation of this critical security component was fundamentally flawed, paving the way for the severe vulnerability.

Key Findings

▶ Watch: Demonstrating the attack by changing user ID (4:40)

Clément Gindrier's investigation revealed a critical flaw in Izly's QR code generation mechanism: the HMAC designed to ensure data integrity was effectively useless. Through reverse engineering the Izly Android application (downloaded from APK Pure and decompiled using Jadx), he discovered how the HMAC key was generated. The key was derived locally on the user's device, based on a sharedPreference value that was incremented each time a QR code was generated. This sharedPreference was updated only twice: once upon user login (initialized to zero) and subsequently upon each QR code generation.

The core problem was that this key generation process occurred entirely offline and locally on the user's device. There was no mechanism for the application to communicate this dynamically generated key to the Izly server. Consequently, the server had no way of knowing the correct HMAC key for any given user at any given time. Without this shared secret, the server was unable to reproduce or verify the HMAC provided in the QR code. This rendered the HMAC completely ineffective; it could not guarantee the integrity of the data.

The practical implication was profound: the data within the QR code was essentially unprotected. An attacker could modify any part of the QR code's textual content without detection. Gindrier demonstrated this by first altering the HMAC itself—removing it entirely, replacing it with arbitrary characters, or simply changing it—and found that the payment system still accepted the QR code. This confirmed the server was not performing any meaningful HMAC validation.

The next step was to exploit this lack of integrity. Gindrier successfully executed an attack by:

1. Obtaining a legitimate QR code from a friend.
2. Modifying the QR code's content to replace his friend's phone number (the user ID) with his own phone number.
3. Updating the date and time in the QR code to the current time, as QR codes have a short expiration window (a few minutes).
4. Presenting this modified QR code at a checkout, successfully paying using his friend's Izly account balance.

The impact of this vulnerability was deemed critical for several reasons:

• Ease of Exploitation: The attack was described as "very easy to do," executable "in a matter of seconds" on the spot with just a phone, requiring no specialized computer or tools.
• Untraceability: No information about the attacker was sent to the server, making it impossible to trace the fraudulent activity back to them. At checkout, only the balance and receipt were displayed, providing no indication of impersonation.
• Victim Helplessness: Victims did not need to perform any action to be targeted, only requiring their phone number linked to an Izly account. Their only recourse was to withdraw funds or stop using the application, which was often not feasible due to Izly's indispensable nature.
• Long-standing Presence: The vulnerability had been present since the application's inception, confirmed to exist in 2017 and potentially earlier, indicating a significant, long-term security oversight.
• Potential Real Victims: While Izly had not officially communicated on the matter, some user reviews on the Play Store complained about unauthorized deductions, suggesting that real-world exploitation might have occurred, though direct correlation to this specific vulnerability was unconfirmed.

Technical Deep Dive

▶ Watch: Vulnerability reported to ANSSI and successfully patched (8:50)

The technical core of this vulnerability lies in the predictable and locally managed nature of the HMAC key within the Izly application. Gindrier’s methodology began with reverse engineering the Izly Android application. He acquired the application’s APK file from a repository like APK Pure, then used the open-source decompiler Jadx to convert the compiled bytecode back into a more human-readable Java representation. This allowed him to inspect the application's internal logic, specifically focusing on the QR code generation function.

The structure of the QR code data, as revealed by Gindrier, was a simple concatenated string: USER_ID|DATETIME|HMAC.

• USER_ID: This was the user's phone number, serving as the primary identifier.
• DATETIME: A timestamp indicating when the QR code was generated, crucial for its short validity period.
• HMAC: The supposed integrity check.

Upon analyzing the code responsible for generating this string, Gindrier identified the function responsible for creating the HMAC. The critical discovery was how the HMAC key was derived: it was based on a sharedPreference variable. This variable was initialized to 0 upon a user's first login and then incremented every time a new QR code was generated. This meant the key was a simple counter, unique to each user's device, and directly tied to the number of QR codes they had generated locally.

The fundamental security flaw here is a principle of cryptographic key management: for an HMAC to be effective, the key must be a shared secret known only to the sender (the Izly app on the user's phone) and the receiver (the Izly server). Since the key was generated and managed entirely locally on the user's device, incrementing based on offline actions, the Izly server had no way to independently calculate or know what the current key was for any given user. Without the shared secret, the server could not re-calculate the HMAC for the received QR code data and compare it with the HMAC provided in the QR code. Therefore, any HMAC value, or even the complete absence of one, would be accepted by the server.

The steps for crafting a malicious QR code were straightforward:

1. Obtain a base QR code: An attacker could obtain any legitimate Izly QR code, for instance, by taking a photo of a friend's QR code.
2. Extract and parse data: The attacker would parse the QR code to extract the USER_ID, DATETIME, and HMAC fields.
3. Modify USER_ID: The attacker would replace the original USER_ID (the friend's phone number) with the phone number of the target victim whose account they wished to debit. This phone number could be easily obtained as it's often publicly available or guessable.
4. Update DATETIME: Since Izly QR codes have a short expiration (a few minutes), the DATETIME field needed to be updated to the current time to ensure the QR code was valid at the point of presentation.
5. Manipulate HMAC: Given the server's inability to verify the HMAC, the attacker could simply leave the original HMAC, replace it with arbitrary data (e.g., "recall" as Gindrier mentioned), or even remove it entirely. All these variations would be accepted.
6. Generate new QR code: The attacker would then concatenate these modified fields (VICTIM_PHONE_NUMBER|CURRENT_DATETIME|ARBITRARY_HMAC) and encode the resulting string into a new QR code.
7. Present for payment: This newly crafted QR code could then be presented at an Izly scanner, initiating a payment from the victim's account.

This detailed understanding of the flaw highlights a severe breakdown in basic security principles. The reliance on a client-side-only generated and managed "secret" for server-side authentication is a classic anti-pattern in secure application design, demonstrating a lack of proper validation at the trusted backend.

Demo / Proof of Concept

▶ Watch: Q&A: Private key unique per user, sent by server (14:10)

While Clément Gindrier did not perform a live, interactive demo during his talk, he thoroughly described the Proof of Concept (PoC) he developed and utilized to validate the vulnerability and demonstrate its ease of exploitation. His PoC evolved from a manual process to an automated application, emphasizing the practicality and discretion of the attack.

Initially, Gindrier manually tested the vulnerability:

1. He first verified that modifying the HMAC within a QR code (e.g., changing it, removing it, or inserting arbitrary text like "recall") did not prevent a successful payment. This confirmed the server's lack of HMAC validation.
2. To demonstrate the full impact without causing harm, he used a friend's legitimate Izly QR code.
3. He then manually edited the text string embedded in the QR code, replacing his friend's phone number (the USER_ID) with his own.
4. Crucially, he also updated the DATETIME field to the current time, as Izly QR codes expire within a few minutes.
5. After generating a new QR code with these modified details, he successfully used it to make a payment. This confirmed that he could effectively impersonate another user and debit their account.

Recognizing the need for greater discretion and efficiency, Gindrier then developed a custom Android application to automate this attack. This custom application was designed with an interface visually similar to the legitimate Izly app. Its functionalities included:

• Contact Selection: The application allowed the attacker to select a victim from their phone's contact list, whose phone number would then be automatically inserted as the USER_ID in the malicious QR code.
• Automated Time Update: The application would automatically generate the current date and time for the DATETIME field, ensuring the QR code's validity.
• QR Code Generation: It would then dynamically generate the fraudulent QR code based on the selected victim's phone number and the current timestamp.

This automated setup offered significant advantages over manual manipulation:

• Speed: It was "faster than with the real application" for generating a payment QR code.
• Discretion: The familiar interface of the custom app made the attack less conspicuous at a checkout, as it would appear to the cashier that the user was simply using the standard Izly application.
• Ease of Use: The process was "very easy," allowing anyone to perform the attack "in a matter of seconds" without needing a computer or specialized tools beyond a smartphone.

The development of this custom application served as a powerful demonstration of the vulnerability's practical exploitability and low barrier to entry, underscoring its critical severity.

Defensive Implications

▶ Watch: Q&A: Offline QR code generation still possible (15:20)

The discovery of this critical vulnerability in Izly prompted a significant security response and ultimately led to a comprehensive overhaul of the application's payment system. The journey from discovery to patch, however, highlighted challenges in vulnerability disclosure.

Gindrier's initial attempts to report the vulnerability directly to Izly were met with silence; he stated, "I contacted Izly and they never replied ever." This common hurdle in responsible disclosure—the lack of accessible and responsive contact channels for security researchers—can often hinder timely remediation. He eventually found a support email on the Play Store and noted a phone number embedded in a sample QR code on an Izly page (possibly a test number with unlimited debit, which he did not investigate further).

Following a teacher's advice, Gindrier then reported the vulnerability to ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information), the French national cybersecurity agency. ANSSI provides a legal framework for anonymous vulnerability reporting, protecting researchers. This approach proved highly effective: ANSSI "replied immediately" and, five months later, Izly implemented a patch. This was not merely a minor fix but a "big refund OB," implying a significant re-architecture of the entire application and its website, demonstrating the severity and breadth of the initial flaw.

Gindrier performed a post-patch analysis to assess the effectiveness of the remediation. He identified two key changes in the QR code generation:

1. User ID Replacement: The original USER_ID (the user's phone number) was replaced with a UUID v4 (Universally Unique Identifier version 4). UUID v4s are statistically random numbers, making it impossible to guess or predict a user's identifier. This change alone significantly raises the bar for impersonation, as an attacker would now need to know the target's specific UUID.
2. Introduction of a Real Signature: Instead of the flawed HMAC, Izly implemented a real digital signature. This is a robust cryptographic primitive where the application signs the QR code data with a private key, and the server verifies this signature using the corresponding public key. Unlike the previous HMAC, this signature scheme ensures both integrity and authenticity, as only the holder of the private key can generate a valid signature. The original HMAC field remained, but Gindrier noted it now functions more like a salt, adding minor entropy but no longer serving as the primary security mechanism.

While the patch significantly improved security, Gindrier explored hypothetical post-patch attack vectors, primarily focusing on how an attacker might still forge a valid signature:

1. Private Key Extraction via Frida: An attacker could potentially use dynamic instrumentation tools like Frida (which requires root access on Android or jailbreak on iOS) to hook into the Izly application's processes. By injecting JavaScript code, they might be able to intercept and display the private key as it's used or stored in memory. Gindrier confirmed he was able to use Frida with his own account to verify the signature generation, implying this method could theoretically recover the key if access to a device with a logged-in Izly account was obtained. This is complex and highly restrictive.
2. Compromising Izly's Database: An "excessive" but theoretically possible method would be to hack Izly's central database. If the server is capable of generating QR codes itself (e.g., for web-based payments), it must possess the private key. A compromise of the server-side infrastructure could expose these keys.
3. HTTPS Interception during Login: Gindrier speculated that the server might send the private key to the application during login, a highly insecure practice. If this were the case, intercepting HTTPS communication during the login process could potentially expose the private key. However, he acknowledged the difficulty of bypassing modern HTTPS encryption with certificate pinning and was unsure if this was feasible.

Despite these theoretical avenues, Gindrier concluded that the application had been "well patched" and that "this is not worth the effort to attack Izly anymore." The increased complexity and resource requirements for any post-patch attack render it impractical for the scale and type of fraud previously possible.

Furthermore, other security improvements were noted, such as restricting access to developer documentation and APIs that were previously unauthorized. This holistic approach to patching suggests that Izly took the vulnerability report seriously and used it as an opportunity to enhance overall application security.

Key Takeaways

• Critical Vulnerability in Payment Systems: The Izly case demonstrates how a fundamental flaw in cryptographic implementation (a broken HMAC) can lead to a critical vulnerability in a widely used payment application, enabling untraceable fraudulent transactions.
• Importance of Proper Cryptographic Design: The core issue was the local, predictable generation of the HMAC key without server-side knowledge or verification, rendering the integrity check useless. This underscores the necessity of shared secrets and robust server-side validation for any security mechanism.
• Reverse Engineering as a Key Tool: Gindrier's use of APK Pure and Jadx to reverse engineer the Android application was instrumental in uncovering the underlying mechanism and the flaw, highlighting the value of such tools in security research.
• Ease of Exploitation and Impact: The vulnerability allowed for extremely easy, fast, and untraceable exploitation using only a smartphone, posing a severe risk to over a million users, particularly students dependent on the service.
• Challenges and Success in Vulnerability Disclosure: Direct communication with the vendor (Izly) was unsuccessful, emphasizing the importance of established, trusted third-party channels like ANSSI for responsible disclosure, which ultimately led to a successful and comprehensive patch.
• Effective Patching Strategy: The remediation involved a significant re-architecture, replacing the phone number as a user ID with a random UUID v4 and implementing a robust digital signature scheme, drastically increasing the difficulty of exploitation and enhancing overall application security.

About the Speaker(s)

Clément Gindrier is an independent security researcher who, at the time of this GreHack talk, had just finished school. Driven by a personal interest in understanding how systems work, he dedicates his free time to exploring and identifying security vulnerabilities. His presentation on the Izly application showcases his practical skills in reverse engineering and vulnerability analysis, demonstrating the significant impact that individual researchers can have on improving the security of widely used applications.