Wawa Rewards Gift Card Takeover Vulnerability

Wawa stores are a favorite among customers in Pennsylvania, New Jersey, Delaware, and beyond. When the company recently announced a new Android app to launch with their rewards program, I was interested in installing it and researching how it worked. Soon after registering and associating a gift card to my account, I discovered a serious vulnerability that would allow an attacker to arbitrarily associate gift cards to his account. Since the app does not require physical access to the card in order to be used at the register, the attacker could then use the remaining balances on the cards.

I signed up for the rewards program, purchased a gift card in the store, and installed the app to begin monitoring its API requests. As I navigated the app, I immediately hit a roadblock: I noticed that I wasn’t seeing any of the web requests in my proxy after performing actions that obviously required API communication. My next thought was that certificate pinning was likely being used. Though pinning is a great idea, it only temporarily impedes the ability to capture traffic, so I set out to reverse engineer the app in order to disable the pinning.

After decompiling the app and grepping the source for references to SSL, certificates, X509TrustManager, etc., I found the following class that seemed to enforce the pinning:

Since the verify method seemed to return a boolean as to whether the public keys (server’s and locally hard-coded) matched, I altered this method to simply return true  in all cases, effectively disabling the pinning. Below is part of the patched smali representation of this method:

Lines 13 and 14 create and return the true  value. After recompiling and installing the patched app, I verified I was then able to proxy the requests made within the app.

Now that the API requests were being captured, I began the process of associating the card to my account. In order to link a card, customers are first asked to provide the card number and the PIN, found by scratching off an area on the back of the card.

After entering these values, the app validated the card by checking the balance. Below is the request and response:

Once the card is validated, another request is made to actually link the card to the user.

Note that only a giftCardID  is required to link a card to a user’s account. Further, the giftCardID  resembles an internal primary key, which is likely sequential. Using this request, an attacker could iterate through giftCardIDs and arbitrarily assign them to his account, allowing him to spend the balances in-store without requiring physical access to the cards. This also would allow “inactive” cards to be added to an attacker’s account, which conceivably would allow him to use the card after it had later been activated at the register.

Realizing the potential impact of this vulnerability, I reached out to Wawa’s information security team. I tried connecting via LinkedIn, but ended up reaching someone by guessing the CTO’s email address. Their team was very responsive and appeared to take the vulnerability seriously.

Disclosure Timeline

2015-03-25: Initial email to CTO
2015-03-26: Receive response, report details of vulnerability
2015-03-27: Acknowledgment of issue
2015-03-27: Vulnerability mitigated (informed on 2015-04-01)
2015-03-31: Follow up for update
2015-04-01: Call to discuss limited patch details

While Wawa’s team reacted quickly, they could have been more thorough in follow-up regarding the status of the issue. Per Wawa’s team, the vulnerability, or design flaw, was corrected server-side. I communicated my concerns regarding this, as the “fix” did not seem to address the lack of authentication when adding cards. Though their team could not share details of the patch, I believe all cards are now flagged as “unlinkable” by default until a balance check request is performed. Presumably, the card is then made “linkable,” and then, under ideal conditions, is immediately associated to the user’s account. This dramatically mitigates the risk of the vulnerability being exploited for malicious intent but still leaves a small window in which an attacker could “snipe” the card, depending on the amount of time between the balance check and the link request.

Despite this outstanding concern, Wawa affirmed that the issue was resolved from their perspective and thanked me for working with them in reporting the vulnerability.

Share this: Facebooktwittergoogle_pluslinkedin
  • Matt Botsford

    This is high quality work. Well done

  • The Rainmaker

    Nice job.

  • kaleem shaik

    Hi
    Nice Write up, Instead of reverse engineering it’s a good idea to use ssl killer app.It will save lot of time

    • Randy Westergren

      Good suggestion. I’ve used it before and it’s not always effective. In this case, I don’t think it would have worked since this app seemed to be using a custom pinning implementation.