Digital wallets can allow purchases with stolen credit cards

Digital wallets like Apple Pay, Google Pay, and PayPal can be used to conduct transactions using stolen and cancelled payment cards, according to academic security researchers.

These flaws – some of which have been addressed since responsible disclosure last year – allow an attacker armed with limited personal information to add an active stolen payment card number to a digital wallet and make purchases, even if the card is subsequently canceled and replaced.

A group of infosec boffins – Raja Hasnain Anwar (UMass Amherst), Syed Rafiul Hussain (Penn State), and Muhammad Taqi Raza (UMass Amherst) – described their findings in a paper presented last week at the Usenix Security 2024.

The paper, titled "In Wallet We Trust: Bypassing the Digital Wallets Payment Security for Free Shopping," explores "critical flaws in the authentication, authorization, and access control mechanisms of major digital wallet apps and US banks," Anwar, a doctoral candidate in electrical and computer engineering and lead author, told The Register.

"We demonstrate how attackers can exploit these weaknesses to add stolen cards to their digital wallets and make unauthorized transactions."

"A plausible attack scenario goes like this: An attacker steals a credit card from a person. Using the cardholder name (which is printed on the card) the attacker determines a victim’s address using online databases.

"Now, the attacker tries to add the card to different digital wallets. Since different wallets have different authentication methods in place, any wallet that requires an address or ZIP code for authentication is suitable for the attack to proceed.

"Once the attacker adds the card to their wallet, the cardholder may lock the card or ask the bank to send a replacement. This will have no effect on the attacker's wallet, which will continue to enjoy access to the card for transactions."

The scenario assumes the attacker has stolen a credit card or obtained the stolen card's primary account number (PAN) and that the owner of the card has not yet canceled it.

The attacker – let's use the name Eve – must first add a card number to her digital wallet. To do so, she needs to downgrade the authentication process between the issuing bank and the digital wallet. Doing so involves choosing a knowledge-based authentication (KBA) scheme instead of a more secure multi-factor authentication (MFA) scheme – like a one-time password sent via SMS, email or phone call. Banks often allow this because it's convenient.

"The end-user, but not the bank, decides the authentication method to be used," the paper explains. "For example, an attacker can make the bank fall back to KBA when MFA is mandated. They do so by using the 'call-based' authentication option. The attacker dials the bank's automated helpline for adding the card to the wallet. The helpline prompts the attacker to provide the KBA-related information: date of birth and the last four digits of SSN [social security number] associated with the victim's card."

Some KBA schemes don’t require both data points. It may be just one of several possible values: the billing ZIP code, billing street address, date of birth, and/or the last four digits of the social security number.

The authors acknowledge that obtaining such personal information is usually "non-trivial." However, they argue that such information is often accessible online, thanks to people search services, public records, and data dumps.

"The recent SSN leak shows how easy it is to acquire KBA information for such PII-based verification," explained Anwar, who added, "I know someone who has been a victim of such an attack, which actually inspired this research study."

Once the stolen card has been added to Eve's wallet, she's free to use it to make purchases. Canceling the card doesn't help – because when the card is authenticated, the bank issues a token that authorizes purchases and is stored in the digital wallet. And that token in the attacker's wallet is re-associated with the replacement card when the bank reissues it.

"When the user reports the card loss, the bank blocks the lost card and issues a new card (with a new personal account number) to the user," the paper explains. "However, it does not update the associated token; instead, it links the old token with the new PAN."

Basically, the bank does not verify that the wallet receiving the updated token is owned by the cardholder.

Compounding the situation, banks do not require point of sale terminals in stores to verify the identity of the cardholder – verifying the identity of the device-holder is enough.

The researchers also found that recurring transactions – such as monthly charges – are treated in a way that allows abuse. Merchants dictate what transactions recur, but an attacker can deceive the merchant into labeling a transaction as "recurring" – and as such it will be processed even if the relevant payment card has been locked.

The paper explains a possible scenario:

This applies at other websites, such as Apple.com, according to the researchers, who reported "we have successfully purchased a $25 Apple gift card, and $179 AirPods" using a locked card. Banks allow recurring payments on locked cards to honor the contract between user and merchant, so that subscription services continue and negative credit events for missed subscription payments don't occur. But this special treatment of recurring payments can be abused.

The researchers explained they disclosed their findings to relevant US banks and digital wallet providers in April 2023. Chase, Citi, and Google reportedly responded.

"At the time of writing this paper, Google is working with the banks from its end to address the reported issues on Google Pay," the paper notes. "The banks, however, reported to us that the disclosed attacks are not possible anymore … We did not yet receive responses from AMEX, BoA [Bank of America], US Bank, Apple, and PayPal."

Apple, Google, and PayPal did not immediately respond to The Register's requests for comment.

The authors recommended several mitigations: Adopting push notifications (Bank App, Duo Mobile, Microsoft Authenticator), or pass codes (Google Authenticator) over traditional one-time passwords; using continuous authentication in token management; and having banks check recurring transactions to make sure they're labeled correctly. ®