The Million Dollar IDOR

Read on to find out how I was able to leverage a simple IDOR + Authorization vulnerability to expose thousands of Visa gift cards on a leading gift card company’s website + Bonus: Found a way to redeem them more than once.

Monetary websites have a high need for the best grade security as they protect valuable assets that shouldn’t easily be accessible to anyone. Very recently we all heard the news of Tremendous, another gift card company which was hacked and a lot of user data and gift cards were stolen :

The Recon

I stumbled on this site [redacted.com] randomly and was keen to understand the technology they were using and the kind of data that was being passed in the background, very quickly it was clear that the website was making use of a GraphQL-based API where the API requests were in the form of. “queries” requesting exactly the amount of data it needs.

What does this mean to hackers? The endpoint for all API communications in a GraphQL API remains the same usually /graphql and the queries and the methods to run in the body define the kind of operation which has to be performed which is backed by a Schema.

There are a few ways by which you can fetch all the available queries, and mutations and also return the entire schema which includes everything which has been defined, popularly known as the Retrospection Query.

Fetch all available queries

{
__schema {
queryType {
fields {
name
}
}
}
}

Fetch all available mutations

{
__schema {
mutationType {
fields {
name
}
}
}
}

Note that Retrospection Queries are sensitive and are usually disabled on serious production graphql servers and by default on the Apollo GraphQL server. But you will find that very often they are still available.

The Hack

The platform made use of very simple queries to retrieve and show all the gift cards owned by a user. Right after login, a query for getUserStipends was made which basically fetched all the cards which belonged to a specific user, listed out the visa card number, the CVV and the expiry for each card and each card had an id which was guessable and incremental like 45,46,47.

query getUserStipends {
myStipends {
id
status
stipend {
amount
canAccrue
colorHex
colorHex2
currency
currentIntervalStart
emoji
endDate
id
interval
logoUrl
name
nextIntervalStart
recurrenceStart
startDate
createdAt
}
}
}

After clicking on a specific card there was yet another request this time for getUserStipend with the id of the specific card I had clicked on:

query getUserStipend($id: Int!) {
stipendUser(id: $id) {
activeUserAddressId
id
personalCardEnabled
status
isTestCard
redemptionType
endDate
endDateExtension
stipend {
amount
canAccrue
colorHex
colorHex2
company {
id
allowParticipantBillingAddress
allowParticipantPersonalCC
}
currency
currentIntervalStart
emoji
endDate
id
interval
logoUrl
name
nextIntervalStart
recurrenceStart
startDate
createdAt
address {
city
country
id
line1
line2
phone_number
postal_code
state
}
merchantCategory {
categoryId
categoryName
merchantId
merchantName
url
logoUrl
networkId
}
}
userAddresses {
city
country
id
line1
line2
phone_number
postal_code
state
}
card {
stripeCardId
currentBalance
accruedBalance
number
cvc
expiry
status
donated
categories {
displayTitle
title
}
cardholder {
name
address {
city
country
line1
line2
postal_code
state
}
}
}
reimbursement {
history {
status
occurredAt
}
amount
targetCurrency
totalFee
wiseQuoteId
wiseRecipientId
wiseTransferId
}
}
}

{
"id": 100000
}

This query, in turn, returned more in-depth data about the specific card, the amount which was available the currency and so on, the first thing that came to my mind was to change the id parameter to something else as it was very easily guessable.

Changing the id parameter caused the query to execute successfully and it returned the entire card details of some other user! Just to be sure I tried the same request with another id and every time it returned a new visa gift card which did not belong to me. I now had access to 1000s of valid visa gift cards with varying values and unhinged access to all of them, all with a simple IDOR which resulted in exposing extremely confidential details valued in millions.

I immediately took to the platform’s helpline and reported the vulnerability and within hours this was fixed and acknowledged by the company’s co-founder:

The Bonus Hack

This was not it, the platform offered another very interesting feature where if you have been issued a gift card in some other currency, you can get it cashed out in the currency of your choice, in this case, they offered direct conversions between USD and INR where the money would be paid directly to an UPI id instantly.

There existed a very interesting vulnerability in the redemption form known as Race Condition.Quoting from Google:

In simpler words, if you simultaneously ask the server to process 2 or more similar requests which lead to very similar results it may either behave unexpectedly or result in double outputs.

When a redemption process was initiated the platform used to generate a quotationID with the converted amount of the card in the requested currency and then proceeded to ask for more details like the UPI Id to be paid. Once redeem was clicked a request was sent using the quotationID to mark it paid and after which the card would no longer be useful. I intercepted the redemption request and duplicated it a couple of times and sent them all at once, it resulted in the converted amount being credited multiple times to my bank account!

Imagine it like a group of slingshots tied to a single lever, when the lever is pulled all the requests are sent simultaneously to the server, and before the server can mark the quotation id as “used” the server has placed multiple redemption requests which in turn sends multiple reimbursements to the user. Its explained a little better in the following figure :

So now not only did I have unlimited visa gift cards, but I also had a way to redeem them into my local currency multiple times/card! How could something like this be avoided?

1) Queries leading to actions: On modules where critical systems are involved do not talk to the Database on a multi-query basis. Instead of asking about the gift card in one query and then issuing a second query to change its status, perform both in one query: ‘If not paid set to paid and payout’.

2) DB Acid Properties: Depends on what kind of database you are using, Databases have a very interesting take on ACID properties where most scalable databases place a temporary “lock” on the part of data you are accessing through one request so until one operation is completely done that part of the data is not accessible by other queries.

This report lead to another bounty + a security contract with the company :)

Closing notes and conclusions

1)Do not hesitate to change id parameters to various values especially if they are not unique like a UUID and are incremental like in this case.

2) Always check for race conditions, any action which may lead to a critical action must be double-checked to be race-condition safe. These are more common in single-use assets like vouchers, coupons etc.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store