Introduction

If we look at bug bounty programs, the applications’ attack surface is roughly divided by free/easy-to-obtain and paid/hard-to-gain access. Bug bounty hunters and pentesters (if access isn’t provided) often cover the first one since the testing doesn’t require additional investments such as money or an unreasonable amount of time/effort. While the second type of attack surface mostly remains untapped, especially if it requires financial investments, it’s often believed that such an investment might be a risk due to unguaranteed ROI. As a full-time bug bounty hunter, I believe that access to the unexplored attack surface is often an advantage in a competitive environment such as bug bounty. Buying access might be worth considering if the potential ROI (👀bounty table👀) greatly exceeds the money investments. In this article, I will cover one such access type, gift cards. I acquired >30 gift cards for this research and revealed 9 vulnerabilities I discovered by unlocking new features, which granted me $6,500.

Bug #1: Race condition at gift card code redeeming and money transfer to the creator leads to financial loss for a company

The bug bounty program’s in-scope application is basically a marketplace with fans and creators as two core user types. Fans can buy products from creators through the checkout and pay in a classic way using a credit card. It’s also possible to top up the account’s balance and pay for products with the balance alternatively. Since one of the balance top-up methods is a gift card, we can register the creator account and pay ourselves from the fan account using the balance. Thus, any TOCTOU-related vulnerabilities in gift card redemption would potentially allow the manipulation of the creator’s balance and create a financial loss for the company.

The interface at /giftcard allows us to set a minimum gift card amount of $5, which is fine with me. After going through the checkout process, I was prompted with an error message about my credit card’s country not being suitable and that only US cards are accepted. However, refusing to give up (and feeling slightly discriminated against payment privilege), I reached out to my fellow colleagues on the Bug Bounty Forum Slack, one of whom kindly provided a virtual US credit card. I applied it along with additional payloads and granted myself a valid $5 gift card I could play with.

By navigating to /redeem from 2 fan accounts, sending the redeem requests, intercepting them and applying in Turbo Intruder, I topped up $10 worth of in-site balance for the price of $5 gift card!

The Turbo Intruder script in question looked like the following:

### Add a request to the turbo intruder, erase the request, enter %s.
### Don't forget to change a path in a and b vars

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=2,
                           requestsPerConnection=2,
                           pipeline=False
                           )
    a = open("/Users/max/intruder1.txt", "r")
    b = open("/Users/max/intruder2.txt", "r")
    # the 'gate' argument blocks the final byte of each request until openGate is invoked
    for i in range(1):
        engine.queue(target.req, a.read(), gate='race1')

    for i in range(1):
        engine.queue(target.req, b.read(), gate='race1')

    # wait until every 'race1' tagged request is ready
    # then send the final byte of each request
    # (this method is non-blocking, just like queue)
    engine.openGate('race1')

    engine.complete(timeout=60)

def handleResponse(req, interesting):
    table.add(req)

The attack model:

1. The attacker registers a single creator and hundreds of fan accounts.
2. The attacker buys a large quantity of gift cards and spreads them across fan accounts, multiplying their monetary value by many times.
3. The attacker buys the product using the in-site balance from fan accounts.
4. The attacker withdraws the money from the creator dashboard, inflicting severe financial damages.

An issue was accepted with a Critical severity and remediated within 1 day.

Bug 2: Email HTML injection in gift card notification email via /giftcard

The title is self-explanatory—we can render HTML tags in the gift card notification email via recipient name and message. While initially I intended to see if there was template injection, the HTML tags I sent along were also rendered. While such a bug’s potential severity is None-Low, depending on the company’s threat model, I dropped a quick report, and the bug was accepted with a Low severity (with a bonus for a gift card-related report) where remediation time was 6 months.

The impact is insignificant here: it consists of using the email’s substantial authenticity level and message overlay to send phishing messages from the company’s email to achieve various outcomes such as stealing login;password pair, spreading malware, etc. It’s worth remembering that AC might be High here due to the need to buy a gift card to send each email, so the campaign should be highly targeted.

Bug #3: Race condition at promo code redeeming leads to getting free items on an unlimited amount of orders

Promo codes are very similar to gift cards; they are code-based, often unique, and mostly one-time, so I decided to include them here. The bug bounty program’s in-scope asset is a subscription-based razor-selling app, and they kindly provided a $9 promo code we can use to create an order. It would be a waste not to use it, right? I added a single, one-time promo code in two different $9 checkouts in the single account, intercepted two final checkout requests, added them into Turbo Intruder with my classic script, started an attack, and discovered that two orders were accepted and assigned the same promo code! This means that one of them was assigned an invalidated promo code, which is totally free, implying we can spawn multiple orders with a single code depending on implementation and network quality.

After I sent the report, the team mentioned that the checkout flow relies on a third-party subscription and payment provider, to which they transferred my report. The provider has thousands of customers, meaning an issue exists in many applications, and discoverability is scalable. The bug was accepted with a High severity and fixed within 8 days.

Bug #4: Same same but different

After further examining a fix for the previous vulnerability, I found that the synchronization mechanism lock is only triggered when a promo code is used at different checkouts in the same account. This indicates that the fix was potentially built upon exactly the same process my report initially described. If we apply promo codes in checkouts from different accounts and send the checkout finalization requests simultaneously, it’d bypass the fix. The report was accepted and fixed within two months.

Bugs #5 and #6: IDORs at gift card view and edit endpoints

An application represents a clothing e-commerce platform that supports gift cards. I couldn’t confirm the race condition, but after purchasing the gift card, we can view and edit it using additional endpoints. The view and edit endpoints looked like GET /gifts/in_progress?g_id=680297 and POST /gifts/buy/email/edit\nHost:www.example.com\n\ngift_purchase_form_id=680297 and after a trivial id decrementation, an IDOR was confirmed. I used a reliable “wait for fix and report later” approach to avoid duplication, and both endpoints were deemed to belong to unique separate submissions. The submissions were fixed within a month after reporting.

The impact was the disclosure of 680,000 email addresses, messages, names, and gift card prices. Gift card numbers aren’t returned by executing the vulnerable endpoint and are sent in email separately; hence, the severity was assessed as High for both issues.

Bug #7: Race condition at gift card code redeeming and money transfer to the developer leads to financial loss for a company

The application is an adult gaming platform that supports gift cards sold only by 3rd party resellers. I purchased a gift card worth 500 units of in-game currency, registered two accounts, intercepted a gift card redeeming request at /redeem-gold for both accounts, started a Turbo Intruder attack, and… it didn’t work. As I later discovered, the endpoint for gift card redeeming I used isn’t the final that actually redeems the code and I missed the finalization request since Burp Suite didn’t intercept it for some reasons.

I did one more run with a freshly bought gift card, and the gift card was successfully topped up for only one account. When I checked the delay, it was quite significant, and considering the nature of race conditions, it’s worth giving it one more try. Suspecting latency is affected by the quality of the internet connection in my rented apartment, I rented a day in a coworking space where the internet is better. After one more run, I was able to reproduce the vulnerability and successfully topped up 500 golds on both accounts for the price of 500 golds.

The attack model is as follows:

1. The attacker registers a single developer and hundreds of user accounts. Although publishing a game is required to get a developer account, it is still a viable scenario considering the earnings per effort.

2. The attacker buys a large quantity of gift cards and spreads them across user accounts, multiplying their monetary value by many times.

3. Attacker buys the game from developer using gold on user accounts.

4. The attacker withdraws the money from the developer dashboard, inflicting severe financial damages.

An issue was assessed as a critical severity and fixed shortly.

Bugs #8 and #9: Email HTML injection in gift card notification email

I acquired gift cards for two online stores, and race conditions weren’t present, but email HTML injections were. Although it’s not what I expected, those are still bugs, so I reported them to call it break-even.

Final thoughts

• Ensure you enable out-of-scope logging and all MIME types in your MITM proxy tool to catch the checkout finalization request. I wasted quite a few gift cards to learn this lesson! It doesn’t hurt when it’s a $5 gift card, but it’s a big ouch moment when it’s $50.

• It’s worth considering buying access to additional features if there’s a high ROI, especially if you found patterns of potential bugs there. As we can conclude from IDOR examples, the attack surface(s) I targeted were untapped since IDORs are the most trivial vulnerability types that can be identified even by people unfamiliar with application security.

• Race conditions depend highly on network quality, and reproducing one might take multiple shots. The success rate for VPNs is lower due to latency and request relays—that’s the reason why I tend to avoid reproducing race conditions in staging VPN-protected envs.

• Analyzing the attack scenario from an attacker standpoint and considering as many attack opportunities as possible is crucial for an accurate severity assessment. In the first example, I could’ve explained the impact of buying creator products for free and called it a day. However, after analyzing the application user types and mentioning the possibility of money draining via the creator account, I backed up the Critical severity vs High severity.