The first step to use a mobile payment is the enrolment of the user’s credit cards into the app. The provider cannot, of course, know whether the card entered belongs to the user or not. This is something that only the card issuer can know. Providers facilitate issuer’s decision making by providing information. For example, Apple Pay passes on information to the card issuer including the user phone number, location (if Location Services are enabled), iTunes account information, etc. The issuer has to make a decision (based on an automated risk assessment) of whether the card is accepted or not.
A recent vulnerability exploited by fraud rings abuses a weakness in the way the risk assessment is performed and some issuers have accepted stolen cards to be added to Apple Pay accounts. Once accepted, they were used to buy products which were in turn sold online. By Apple’s rules, it’s up to credit card-issuing banks to verify the legitimacy of their cards when they’re added to Apple Pay, a process called “provisioning”. Apple Pay relies on fraud detection by the card issuer for fraudulent card enrolments with the digital wallet. Fraudulent transactions have been possible because of weaknesses in fraud traceability to track fraudulent card registrations back to the user that either registered the card.
In the case of payment fraud, liability for fraud might shift from the banks to merchants is based upon the network payment policies and the methods used to verify the user. Credit card entry another potential attack vector is when the credit card information is initially entered into Apple Passbook/Google Wallet / Samsung TEE, which uses the phone’s camera. If the phone is already infected with memory malware or other malware that has compromised the camera or passbook/wallet the information can be stolen using memory scraping, OCR recognition or even by sending the raw image capture for offsite analysis to C&C servers. Additionally the data may be eavesdropped in transit when the credit card information is sent from the device to servers in the cloud. Should the device be compromised an attacker may be able to gain access to the network traffic and therefore the credit card information. An attacker could exploit a social engineering attack by requesting a user to re-enter the credit card details.
A recent bug in iOS allows an attacker to replace a legitimate application with a clone developed by the attacker enabling a MITM(Man in the Middle)attack. The attacker could masquerade passbook and steal card information. User authentication providers rely on fingerprint biometrics for user authentication. Extensive research has proven that fingerprint authentication can be bypassed and has been shown to be breakable. If the user’s phone is stolen, it would not be hard to bypass the biometric authentication, which unlocks the entire phone and financial payment process. For example, in Google pay users can authorize payments just by entering the lock screen pattern. As this is a mechanism which can be easily eavesdropped, it may encourage opportunistic attackers to steal a device in order to perform payments on behalf of the victim. Fraudulent payment transactions Card issuers may not accept liability for fraud if their terms and conditions are not met. For example, Lloyds Terms and Conditions state “ensure you only register your own fingerprints and not anyone else’s” which would potentially invalidate a fraud claim if more fingerprints are registered on the device. Accountability for payment transactions Payment providers require fingerprint authentication to perform the payment. However, a number of individuals may have been enrolled in the fingerprint database and therefore anyone who can authenticate to the phone would be able to perform a payment. If a number of users have access to the device, it creates an accountability failure as it is not possible to uniquely identify the person who performed the payment. Third party trust regardless of the mobile payment provider, enrolling on the system requires a certain level of trust on the third party. Although, it is likely that the third party is doing due diligence and the required security mechanisms are in place, the consumer does not have full assurance that the data may not be compromised at some point in the future. Apple offers the functionality to integrate with Apple Wallet so that third party applications can perform payments, organize vouchers. This is done by an API called PassKit. A malicious application could be installed on the device which would in turn access PassKit to manage credit cards or perform unwanted inapp payments or misuse passes. Wider attacking surface on a stolen device should a mobile is stolen; attackers may be able to gain further access to payment cards, which would introduce a new incentive to steal the device.
Minimum Security Measures Mobile payment providers should make customers and merchants aware of the risks and consequences of running their application in a mobile environment. Customers should at least follow a number of minimum security measures that should be required to securely use their application:
- The customer should update the Operating System on a regular basis, as soon as the OS provider makes an update available.
- Network transport should be trusted: Performing mobile payment transactions from an untrusted network (such as public WIFI hotspot) could facilitate third parties intercepting the communication and potentially tampering with the payment.
- Customer authentication to the mobile device should always be enforced with the use of biometric controls or strong PIN/pattern.
- Effective configuration should be in place in case the device is lost or compromised, such as remote data wipe out. Merchants should also follow guidelines to ensure the security of the payment transactions.
- POS software should be updated as soon as the provider releases a security update. POS software has visibility of all payment transactions, and therefore sits on a privileged place for an attacker. POS have been targeted by malicious software and therefore providers should update the terminals to ensure that the software preserves its integrity.
- POS could be tampered with from a hardware perspective. Merchants should be made aware of potential attacks so that they can be efficiently remediated It is also required that the mobile payment application is built with security in mind, where appropriate secure software development should be adopted.
- Avoiding hard-coded sensitive information such as passwords or keys.
- When possible, verifying the integrity of the running code, to ensure that it has not been back-doored. This includes the importance of provisioning the application only through trusted application stores
- When possible minimizing at all times potential man-in-the-middle attacks by implementing effective certificate pinning to ensure that the application is communicating to the intended end points.
Last updated:
0 Comments