Race condition in nopCommerce gift cards enables repeated use

Outpost24 researchers have identified a race condition vulnerability in nopCommerce, an open-source eCommerce platform written in C#, which could enable attackers to exploit the platform's gift card system through a single-packet attack.

The vulnerability, tracked as CVE-2024-58248, was discovered during a manual penetration test under Outpost24's SWAT service. The flaw allows a user to redeem the same gift card multiple times, potentially enabling the unauthorised acquisition of goods at no cost.

Details of the flaw

The issue comes from the way nopCommerce processes gift card transactions during the checkout procedure. According to Outpost24, an attacker could initiate two separate sessions, add items to the cart in each, and then input the same gift card code in both sessions. By navigating to the checkout page in each session and preparing to confirm the order simultaneously, the attacker is able to intercept and manipulate requests made to the /checkout/OpcConfirmOrder/ endpoint.

Outpost24 described the exploitation method as follows: "When both requests get processed in parallel, they each check the gift card balance before it gets updated with the new value, resulting in a race-condition where the balance is overdrawn."

This oversight in transaction processing enables the attacker to redeem the same gift card more than once before the balance is decremented correctly in the system, effectively making repeated purchases using a single-use card.

Timeline and vendor response

The timeline provided by Outpost24 outlines the coordinated disclosure process, with discovery occurring in mid-2024 and subsequent contacts made with the nopCommerce vendor and MITRE. Outpost24 noted that "the vendor communicated that they patched the vulnerability in late 2024. When the patch was released, we analyzed it as a part of the responsible disclosure process. We found that vulnerability persisted with a slight modification to the recreation flow and have notified the vendor about our findings in line with our Responsible Disclosure Policy. In addition, we have decided to share the details in this blog to raise awareness."

Understanding race conditions

A race condition arises when multiple threads, processes, or actors concurrently manipulate the same resource without adequate coordination, causing unintended behaviour. Outpost24 described the technical background as follows:

"A race condition occurs when two or more threads, processes, or external actors access and manipulate the same shared resource (memory, file, hardware device, etc.) concurrently, and the final outcome depends on the exact interleaving of their operations. Because that interleaving is nondeterministic, you can get unexpected (or outright incorrect) behavior.

A race condition is fundamentally about timing and concurrency. Whenever multiple actors interact with the same mutable state without coordination, their actions can overlap in unpredictable ways, potentially leading to logic errors, inconsistency, crashes, or even security vulnerabilities. Proper synchronization (or better yet, designs that avoid shared mutable state altogether) are the keys to preventing them."

The consequences of such issues can vary, with some only occurring under particular timing or load conditions, making them difficult to reproduce consistently. Outpost24 further explains the challenges in detection, stating, "They often only occur under particular timing or load conditions, so tests may pass 999 times and then fail unpredictably on the 1000th." The very act of debugging or logging can also mask the bug, described as "Heisenbugs" by the researchers.

Single-packet attack explained

The single-packet attack method used to exploit the bug allows multiple requests to be completed almost simultaneously. Outpost24 expands on its mechanism:

"The single-packet attack is a technique initially brought forward by James Kettle at PortSwigger, which allows two or more requests to arrive at the server and be processed almost simultaneously. It does this by sending part of each request, while withholding the last bytes of each. Then in a single TCP packet (hence the name) the last bytes of each request are sent. This means that the server will not start to process the requests until the packet containing the final bytes is received. In turn, this allows the request to be processed in parallel.

With this technique, network jitter and other external factors become minimal, allowing requests to arrive almost simultaneously. This opens the door to timing attacks and race conditions that were previously not considered feasible."

According to Outpost24, the responsible disclosure process with the vendor continues following the discovery that a workaround still allowed the vulnerability to persist after the initial patch. The researchers have published details of this vulnerability to highlight the risks posed by race conditions and encourage further industry awareness and action.