American Express prepaid holiday cards vulnerable to enumeration attack

This a 0-day bug announcing a vulnerability with certain prepaid credit cards distributed by American Express.

Nature of bug

Having access to one prepaid credit card, such as a vendor may have, it is possible to successfully guess additional valid credit card numbers and expiration dates. This can be used to extract funds from other people’s cards.

Potential bug impact:

• Loss of funds
• Difficult to track fraud patterns

A unique set of circumstances contributes to this bug, however this unique set is common in a situation that we describe.

Steps required

1. Login to the American Express member login and prepare to purchase a holiday-themed prepaid gift card.
2. Select a multitude of gift cards (quantity > 1).
3. Purchase and receive the cards.
4. Distribute the cards to multiple, different people.
5. “Employee A” uses “card A” to make a purchase online (which requires only the card number and expiration date).

At this point, the vendor will have access to the card number and expiration date. The vendor may identify that this is prepaid AmEx holiday gift card by comparing the first six digits to a Issuer Identification Number (IIN) database. Or, during the holiday season, they may assume all prepaid gift cards are holiday gift cards.

Now the vendor will make several assumptions to successfully exploit this vulnerability:

1. Assume that cards were purchased in multitude (common during holiday season to distribute to multiple employees).
2. Assume that cards were purchased with similar dollar values (again, due to prior assumption).
3. Assume that the expiration date of “card A” is equal to the other cards (this is true if they were purchased at the same time).
4. Assume that another valid card exists incrementally (explanation below).

Now the vendor has used a set up assumptions to guess, with a high degree of likelyhood, a valid card number, including the expiration date and the amount of funds available on that card to spend.

Enumeration

The cards are produced sequentially using the following pattern. The vendor can therefore guess the card numbers using the same pattern.

• The card numbers are 15-digits in length
• The first 6 digits are the IIN
• The next 8 digits are the Account Identifier
• The last digit is the LUHN checksum

Therefore simply increment or decrement the 14th digit and recalculate the 15th digit. This can be done manually by trying all digits (0…9) in the 15th location and using an online credit card number checker.

This process can be repeated until a card is reached which is no longer active.

Tools used to discover bug

I have seen a specimen of the affected gift cards.

Test date

December 2018

Disclosure schedule

• 2018-12-21: Discovery
• 2018-12-21: Publicly requested vendor to provide responsible contact
• …: Several rounds of back-and-forth to find responsible contact
• 2018-12-28: Received invitation to official private American Express HackerOne program
• 2019-01-23: Disclosed privately to vendor on HackerOne
• 2019-01-24: Vendor replies that this is not a security issue and closed the submission
• 2019-01-30: Disclosed publicly on Privacy Log

Recommendations / bounty program

The American Express responsible disclosure policy is hoping to invite participants to a private HackerOne channel. They request that details of the HackerOne program be kept private, and I will respect this wish at the moment. However I will say that identical wording is used on their public website.

This program is an unpaid bug bounty where participants are requested to provide well-documented vulnerability reports directly to AmEx. They request that participants never disclose findings publicly, even after they are resolved. Also they have set up the HackerOne program specifically so that valid reports which are accepted DO NOT contribute to the sender’s profile. In other words, I can see which HackerOne users contributed reports. But if you load the same web page then these HackerOne users will look indistinguishable from new user accounts. In other words, it is not going to help those people professionally in their career in any way.

The program details also report that maybe, in certain situations, they will not report you to the police for doing security research.

I have experince disclosing security vulnerability to financial institutions. When the institution expects that vulnerability reports will come to them, and they will never be published, then there is a strong incentive to do nothing about it. In fact, that is why I started this blog. You can read the ten-year story of the first non-disclosure agreement I broke by starting at post one and skipping ahead ten years.

American Express would do well to keep this existing program in place (no public disclosure, no payment for individual reports) for its paid full-time employees. It may also apply to teenage suckers that will work for free and may be afraid of police without reason.

Going forward, for the public responsible disclosure program, I recommend that AmEx adopt terms that are more enticing for professional security researchers. Specifically, AmEx should contribute a printed letter, or public recognition in a way that is beneficial to the researcher’s career and resume. Apple does this by posting a brief issue description and the name of the submitter on www.apple.com, this is a unique distinction I have earned. Also, cash is nice.

▧

Comments

I reported a bug directly to FB thru their own helpdesk's "paid" bug-reporting system. They responded that it was a bug and they were going to fix it, but because they didn't consider it a "security bug" they decided not to pay me anything at all for filing disclosure. "Ethical Hacking" is clearly just a scam perpetuated by capital interests with no interest in actually fixing their own shit.

OwenF

Please discuss this topic anywhere and let me know any great comments or media coverage I should link here.