Visa and Other Gift Card Transactions Exposed by GoWallet Vulnerability

I recently received a Visa Gift Card and decided to use GoWallet to manage it, as advertised on the card’s packaging. GoWallet offers the ability to manage most types of gift cards, allowing a user to view their card’s current balance and past transactions.

I signed up on their website and associated the card to my account. Next, I downloaded the app and started to review the API requests while exploring the card management features.

Most of the requests looked normal, but the process for reviewing transactions seemed interesting. Though my transactions didn’t actually appear in the app (an issue in the app I assumed), I noticed the API requests were still returning them behind the scenes.

In order to request a card’s transactions, the app first authenticates the card and receives a usertoken; this was in addition to the user having already authenticated to the app itself (identified by the BHN-User-Token ). The user’s zip code, card number, and last four of their phone number were required in order to receive the token (the user is not prompted for these).

Below is the what a valid token response looked like:

Using the returned usertoken , a request was then made to get the transactions for the specified card.

And here’s an example response:

Using a two factor authentication scheme is certainly a best practice when dealing with highly sensitive information. The problem is that the other required pieces of information (phone number, zip code) were already being returned by a previous API request, making it useless as a 2FA method. I decided to investigate this endpoint a bit further by creating a test account and attempting to access the transactions of the card under my real account.

Using the same workflow as above, I added an old gift card to my test account and attempted to view the transactions of the card. I then performed the same request, but changing the specified card.id to the one of my real account above. The request successfully returned the transactions, meaning I was able to use my test account’s credentials and token to access a card that didn’t belong to it. This means an attacker could have presumably accessed the transactions of any card in the system by altering the numerical card.id.

I wrote up a proof-of-concept to demonstrate the vulnerability for GoWallet’s engineering team.

I immediately attempted to reach out to GoWallet (owned by Blackhawk Network) to responsibly disclose the vulnerability. I searched for some security contacts on LinkedIn and got in touch with their CISO, who was extremely responsive. I was kept up-to-date throughout the process; they quickly acknowledged the vulnerability and released a fix.

Disclosure Timeline

2015-02-18: Initial attempt to reach LinkedIn contact
2015-02-23: Response received, direct contact established
2015-02-24: Issue reported and PoC sent
2015-02-25: Vulnerability acknowledged, fix in progress
2015-02-27: Fix pushed live and resolution confirmed

Blackhawk was extremely grateful for the report and sent me a gift card as a token of their appreciation.

Share this: Facebooktwittergoogle_pluslinkedin
  • tyloman

    How much you have got on giftcard 😉 ?

  • Antoan At

    May I ask, what did you use to review the Apps post requests and everything else.

    • Michael O

      I don’t know what Randy uses, but you would perform a man in the middle attack on your own device. I like to use mitmproxy. This will route and log all traffic through your computer so you can view and alter the requests from your device.

  • Jennifer S

    Thank you for this post. I just came across this app on a sticker attached to my B&N GC. Since I am NOT a security expert and have NO programming skills, I decided to do a little research and your post was the first hit. I am very wary of electronically storing any CC information & I am still not sure how i feel about uploading GC info.
    Anyway, thanks again.