During the pandemic, mobile apps became increasingly used for payment as people moved even faster towards cashless and contactless payment. On top of that increase in mobile payments, consumers demand higher levels of security. In Appdome’s 2021 Mobile Consumer Survey, 67% of consumers say that apps used for payments (e.g. ewallet, payment, rideshare, food ordering, banking) should have the highest level of security. Along with the increased use of mobile apps, 4 major mobile payment risks became apparent. These risk areas involve vulnerabilities to protect against, compliance and security implementations with dependencies beyond your control.
- Malware
- Elevated privileges
- Changes in PCI standards
- Security implementations with dependencies beyond your control
Let’s talk about these areas in more detail.
Mobile Payment Security: Malware
It’s reported that in 2021, 46% of organizations had at least one employee download a malicious mobile application. As published by the World Economic Forum, “As mobile wallets and mobile payment platforms are used more frequently, cyber crimes will evolve and adapt their techniques to exploit the growing reliance on mobile devices.”
Cybercriminals have used malware for years to target mobile apps that deal with money. While many still use banking apps for payments, a rapidly growing group of people use apps with credit card and even cryptocurrency as payment options. These cybercriminals are constantly changing, making it challenging for app makers to keep up. In 2020 alone, security firm Kapersky report over 156,000 new mobile banking trojans and 5.6 million malicious packages installed by unsuspecting mobile users. What’s particularly alarming is that mobile users are unknowingly downloading malware onto their devices—because they are being tricked to so.
EventBot is an example of a malicious program that is hidden within a seemingly valid app. The user downloads the app thinking it will help him/her. For example, it’s been reported that EventBot often masquerades as a legitimate Android app — like Adobe Flash or Microsoft Word for Android. Once installed, Eventbot harvests unprotected data from the victim’s other apps on the same Android device. EventBot also expands its permissions, gaining access to the accessibility options in the Android operating system and enabling more damage.
ZDnet warns that EventBot is specifically targeting apps used for payment across Europe and the United States, looking for user credentials, one-time-passwords (OTPs) and account details. EventBot steals usernames, passwords and intercept two-factor authentication codes sent as text messages by these apps.
Sharkbot is another particular malicious form of malware because it avoids Google Safety Net detection, intercepts MFA/2FA text messages, abuses Accessibility Services, performs overlay attacks and auto-populates fields in apps. For more information on Sharkbot, see this article.
Mobile Payment Security: Elevated Privileges
Cybercriminals use elevated privileges to gain illicit access of elevated rights, or privileges, beyond what is intended or entitled for them. Cybercriminals using elevated privileges can be internal or external. There are many ways to gain elevated privileges:
- Credential exploitation
- Vulnerabilities and exploits
- Misconfigurations
- Malware
- Social engineering
What are some examples?
Recently a number of cryptocurrency exchanges and companies have lost over $300M to cybercriminals. In the case of Celsius Network, several users complained about receiving unusual requests for additional permissions in their accounts. The attacker added a script to the frontend that tricked users into providing access to the hacker. The hacker then drained the funds from their wallets.
In the case of xHelper, the mobile malware tricked users into opening backdoors that elevated privileges for the attacker. Through the backdoor, the attacker delivered additional malware to update the existing version of xHelper with more capabilities. XHelper also tricked users into giving permissions to hackers to download and install other malicious apps.
Changes in PCI Standards
Standards like PCI DSS were created to enhance cardholder data security for organizations that store and process credit card data. All organizations that store, process or transmit cardholder data must comply with PCI DSS. In addition to PCI DSS, PA DSS Standards were introduced to help organizations achieve compliance and secure cardholder data.
PA-DSS is a standard managed by the PCI SSC and was established to help software vendors secure payment applications. PA-DSS is for Payment applications that are sold, distributed, or licensed to third parties. Things change on October 28, 2022. At this time, PA-DSS v3.2 will be formally retired and replaced by the PCI Software Security Framework.
Couple of things to note regarding PA-DSS:
- In-house payment applications developed by merchants that are not sold to a third party are not subject to the PA-DSS requirements but need to adhere to the PCI DSS Compliance Standard.
- Regardless of this change, if an organization stores, processes or transmits credit card information, they are required to comply with PCI DSS.
Security Implementations with Dependencies Beyond Your Control
To protect against tampering, PCI DSS has the following requirement:
The PIN CVM Application must offer tamper-resistance measures around the handling of code, application/monitor interface code and any code that is involved in the use or security of cryptographic keys (both public and private/secret keys) for all the supported platform and protection methods (such as TEE, white-box cryptography).
To protect against tampering and comply with PCI DSS generally requires some combination of the following key security requirements:
- App Shielding – which entails some combination of Anti-tampering, anti-debugging, and protection against dynamic reverse engineering
- Code Obfuscation – which entails some combination of obfuscating native code/libraries, non-native code/libraries/frameworks, obfuscating control flows, obfuscating app logic (control flows), renaming or relocating classes, objects, resources, package names, variables, function or method calls, and stripping symbols or other debug information
- Encryption – encrypting application strings, XML strings, app preferences, user or system default settings, resource files and folders
A major challenge developers face when attempting to achieve PCI compliance or implement mobile app security using SDKs, open source libraries, or specialized compilers stems from the fact that these methods all rely on source code and require changes to the application code. As a result of that, each of these methods is explicitly bound to the specific programming language that the application is written in, and are also exposed to various programming language or package ‘dependencies’ between those languages and frameworks. In software development, a dependency is a broad term used to describe a program or piece of code that relies on another program in order to run or to perform a function. For instance, if Program A requires Program B to be able to run, Program A is dependent on Program B (and vice versa this makes Program B a “dependency” of Program A). For a real world example of this problem, check out this Stack Overflow post by a developer who needs to build code obfuscation into an iOS app where there are multiple dependencies between React Native (a non-native framework) and Objective C (a native coding language). Because there is no built-in library in the iOS project that will obfuscate React Native code, the developer needs to use an external package (dependency #1). Furthermore, that external package has an additional downstream dependency on yet another npm package in order to obfuscate the JavaScript code (dependency #2).
In addition to all of the operational, resource, manual coding, and timing issues that this entails, the most pressing issue with respect to PCI is the loss of control that comes with these dependencies. If those third party libraries become deprecated, are no longer supported, or cease to stop working for any reason, the companies may fall out of compliance with PCI DSS and will need to find another solution. This issue highlights the growing challenge developers face in building in security for the diversity of apps and the frameworks used to build them. An SDK or library should work inside all native and non-native apps. But when that is not the case, the risk of attack and non-compliance increases.
How Appdome Can Help
To learn more about how Appdome can help your organization:
- Protect against malware like xHelper, see this article.
- Protect against rooting and elevating privileges, see this article.
- Comply with PCI DSS standards, see this article.
- Avoid security implementations with dependencies beyond your control, see this article.
