Introduction
During an internal challenge, I found a business logic flaw in an employee rewards platform that allowed points to be spent and then reclaimed through comment edits, effectively creating an “infinite money” bug.
This was not a deeply technical exploit, but it was a good example of how simple workflow assumptions can turn into exploitable logic flaws.
What this post covers
- How the rewards workflow handled points and comments
- Why comment editing created the flaw
- How the initial fix was bypassed
- The disclosure timeline
My employer had recently rolled out a corporate rewards program where points could be redeemed for items like gift cards.
One slow day in the Security Operations Centre (SOC), my manager put out a “call to pwn.”
I work with a lot of very smart people, so by the time that Slack message landed during lunch I knew others were already digging in. Unfortunately for them, I am very competitive, so lunch ended early and I went looking for the easiest route to “infinite money.”
Initial Reconnaissance
With the scope narrowed to “find a bug that gets me infinite money,” the app really boiled down to three areas:
- Send Points
- Receive Points
- Redeem Points
I started by looking at the redemption flow. I made a test purchase while capturing requests in Burp and tried modifying values in transit. That went nowhere. The redemption side of the app was more complex than I expected, and with my virtual balance running low I decided to move on.
One odd note: changing the account region to the United States exposed different prices and reward quantities.
Sending and receiving points required another person for testing, and thankfully Austin (@0xffaraday) volunteered.
We started sending points back and forth. Public point transfers were visible to everyone in the company, and anyone could “add on” with a comment that included extra points.
Those posts allowed comments to be edited or deleted within a five-minute window, and that edit flow also let you change the number of points attached to the comment. That looked promising.
Discovery
I began by sending points and then editing my comment to remove them just to see what would happen. Surprisingly, it worked. The recipient did not keep the points after the edit, but the sender got their points back if the amount was changed to zero. That raised a much more interesting question: what happens if the points are spent before the edit?
Austin and I jumped into a Zoom call and started testing. A short while later we had a working PoC. In under an hour and a half, the challenge was solved.
While I was busy celebrating, we noticed one detail we had not accounted for: negative balances. I may have had a working PoC, but it came at the cost of sending Austin into virtual debt.
Disclosure
After disclosing the issue to the vendor, I found I could still bypass the initial patch. Instead of editing the value to zero, I deleted the child comment entirely. The same behavior also worked when deleting the parent comment, provided the comment itself no longer contained points.
This was not the most technically complex bug I have found, but I liked how simple and clean the logic flaw was.
Disclosure timeline
- 05/09/2024 - Initial discovery and disclosure
- 06/09/2024 - Vendor requested meeting
- 11/09/2024 - Vendor confirmed fix was in place
- 16/09/2024 - Found a bypass using the child comment flow
- 20/09/2024 - Bypass fixed
Special thanks to Dray Agha (drayagha.uk) for the challenge and Austin Worline (@0xffaraday) for helping test it.