iOS and Android apps fail coding best practices, are susceptible to reverse engineering, and share sensitive user data

Executive Summary

Top banks and mobile payment providers are putting their customers at risk for security and privacy by failing to adhere to coding best practices and continuing to share sensitive customer data with advertisers.

According to our latest research of both iOS and Android banking applications from 150 of the top banks and mobile payment providers, most failed Open Web Application Security Project for Mobile (OWASP) reverse engineering checks, secure communication methods, or implement in-app self-protection.

Zimperium scanned and scored 300 public mobile finance apps available in the Apple App Store and Google Play for security, privacy, and data leakage risks using its zScan™ application scanning service.

Zimperium is providing the anonymous results on the mobile app risks to the banks, analysts, users and the market under responsible disclosure. If you are a banking leader responsible for the mobile or digital channels, please contact us and we will assist you in identifying your app in the report and consult with you on the findings.

Some compelling and disconcerning facts to follow in this research include:

• Banks are failing to adhere to coding best practices, despite banks increasingly encouraging customers to use mobile banking apps and acknowledging cybersecurity as the biggest threat to the financial system. Not adhering to application development best practices exposes both customer and bank data and increases the chances for fraud as banks implement more third-party mobile and cloud services.
• Banks continue to share sensitive customer data with advertisers. This practice increases the chances of data leakage if a mobile banking app is reverse engineered or a third-party library or service vulnerability is exploited. If there is a data breach and personally identifiable information is exposed, banks could suffer severe brand damage and regulatory fines.
• Most banks fail OWASP reverse engineering checks, secure mobile device data, or implement in-app self-protection for mobile apps. Failing reversing engineering checks allows anyone to reverse engineer an app to identify weaknesses and identify an attack surface. One such example is how cybercriminals reverse-engineered a mobile app to identify vulnerabilities and stole millions of dollars overnight from thousands of users all without being detected.

Methodology

This research discloses the security and privacy risk exposure and whether or not each passes or fails the OWASP Mobile Top 10 practices for the top 300 US mobile banking and mobile payment apps (150 iOS and 150 Android).

The scores are calculated using Zimperium’s application analysis engine. Zimperium zScan is an application reputation scanning service that continually evaluates risks posed by mobile apps.

zScan provides deep intelligence about app behavior, including content (the app code itself), intent (the app’s behavior), and context (the domains, certificates, shared code, network communications, and other data). zScan also provides privacy and security ratings, enabling enterprises to create security policies that limit or remove risks from apps they develop.

This research scanned and scored 300 mobile banking apps available in the Apple App Store and Google Play for security, privacy, and data leakage risks.

The security summary focuses on application risks. These risks include functionality and code use, application capabilities, and critical vulnerabilities.

The privacy information focuses on the application’s access to private user data, unique device identifiers, SMS, communications, and data storage.

The security and privacy scores are on a 0-100 scale. Lower aggregate scores indicate apps containing many privacy and security risk conditions.

The OWASP summary contains testing results performed on the applications against the OWASP Top 10 Mobile categories.

OWASP Mobile Top 10 Results

OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. OWASP publishes a top 10 list of application development best practices applying to web applications and a set applying to mobile apps.

Part of our research into the mobile banking applications includes providing a passing or failing mark for each of the OWASP Mobile Top 10. The table below summarizes the overall passing and failing rates amongst all of the apps on each platform.

[table id=7 /]

Security Risks

iOS Security Risks

Some of the critical security issues we found during our iOS analysis are alarming. These issues greatly contribute to apps high risk scores:

• 134 (97%) implement swizzling API calls
  • This may impact the app’s ability to trust security decisions that are based on manipulated/swizzled output.
• 123 (89%) have an authentication method that can be used to override SSL and TLS chain validation.
  • Lower versions (older encryption standards) make it easier to attack the encryption algorithm and gain access to the communication channel in the app.
• 39 (28%) allow unsecure and unverified connections to servers with lower TLS versions.
  • Lower versions (older encryption standards) make it easier to attack the encryption algorithm and gain access to the communication channel in the app.
• 8 (5%) implement an over-the-air app installation method which circumvents Apple’s review process and can install unapproved functionality.
  • A developer could potentially add any desired functionality, including malicious updates, and bypassing the Apple App Store review process.

App security issues we deem dangerous and should be investigated further include the following. These issues carry a lower weighted score to an app’s overall risk grade.

• 112 (81.16%) have additional compiled libraries embedded in the app which could unintentionally introduce additional risk because the compiled code is from another developer.
• 84 (60.87%) contain ‘Bearer’ related OAuth (Open Authorization) tokens.
  • An adversary can gain access to unencrypted tokens and access the resources and services as the authenticated user.
• 25 (18.12%) of apps Access Private iOS Frameworks
  • Private frameworks are the opposite of System Frameworks that are provided by the operating system. A developer may be unaware of all the risks that a private SDK introduces into the app especially when collecting private data like location.
• 15 (10.87%) of apps contain the Facebook access token vulnerability.
  • This means the authentication token key is being saved unencrypted to the file system and can be accessed by an adversary.
• 14 (10.14%) of apps are using Non-secure HTTP Proxies
  • Proxies re-route the communication traffic. An unsecure proxy allows the proxy owner complete access to all the data in the communications.
• 13 (9.42%) of apps contain CFNetwork Framework Proxy API
  • An unsecure proxy allows the proxy owner complete access to all the data in the communications.The Apple system framework cannot control which proxy a user chooses, but does control the code to facilitate proxy channeling.
• 8 (5.8%) of apps contain Remote Server Reputation Risks
  • Lower versions (older encryption standards) make it easier to attack the encryption algorithm and gain access to the communication channel in the app.
• 1 (1%) of apps contain Self-signed SSL/TLS Hosts
  • Lower versions (older encryption standards) make it easier to attack the encryption algorithm and gain access to the communication channel in the app.

Android Security Risks

Common security issues we found during our Android analysis are very similar to its iOS counterparts. Several apps are using unsecure data storage, components not protected by a permission, WebView, and using WebKit to download information from the internet.

• 134 (91.78%) of apps enables WebView to execute JavaScript code.
  • Mobile apps should avoid JavaScript when possible. That said, if the app is connecting to the bank’s website to show pages in the app, and the bank’s website uses JavaScript, then the app also has to be configured to ‘allow’ JavaScript. However, it is best not to use JavaScript. The banks should use APIs to pull in required data without JavaScript as an alternative.
• 19 (13%) of apps contain exported components not protected by a permission.
  • If a component such as a service is exported and not protected with strong permissions, then any application can start and bind to the service. Depending on the duties of a particular service, it may leak information or perform unauthorized tasks.
• 7 (4.8%) of apps access (yara: andro_world_access).
  • These apps use insecure storage data mode (WORLD_READABLE, WORLD_WRITABLE).
• 8 (5.48%) of apps do not check the validation of the CN (Common Name) of the SSL certificate.
  • This is a critical vulnerability and allows attackers to perform MITM attacks with a valid certificate without the user’s knowledge.
• 2 (1.37%) mobile banking apps have an additional Android application bundled with this Android application.
  • This is not an acceptable or standard developer practice and often used with malicious intent with repackaged applications.

Privacy Risks

Privacy assessments focus on each of the banking apps’ access to privacy data, including (but not limited to): user data, contacts access, unique device identifiers, adware, SMS, and insecure storage of data and communications.

iOS Privacy Risks

Each of the apps is scanned for risks to user privacy. Individual risks are classified as “Critical” or “Dangerous” based on Zimperium’s default settings. “Critical” issues are those that should be immediately addressed to prevent imminent data leakage (e.g., PII) or app rejection due to violating Apple App Store policies. “Dangerous” issues clandestinely expose users to ad networks or can be abused to capture data, recordings, photos, etc. Below is a summary of the most critical and dangerous privacy and data leakage risks found in our mobile banking app dataset.

Critical privacy Risks

• 97% of the apps log information into the system console.
  • System log files (which may include PII) are accessible to any app and could be exploited.
• 80% of the apps are monitoring the iOS pasteboard.
  • Monitoring the iOS Pasteboard is available to apps; however, it is best to limit this in mobile banking applications since apps can capture passwords or SMS security codes used in user authentication.
• 70% of the apps are capable of taking screenshots.
  • This could possibly lead to data leakage by removing unencrypted text and private data from a user’s device.

Dangerous Privacy Risks

• 64.5% of apps include advertising frameworks.
  • These apps are clandestinely collecting information about the user, the device and the app.
• 83.3% of apps retrieve the device’s MAC address.
  • Capturing MAC addresses can be used by advertisers to track users across multiple applications without permission.
• 58.7% of apps can view and import saved photos and videos.
  • Access to photos in the user’s library, often without user consent.
• 7.25% of apps are implementing-point location functionality.
  • Apple only allows the pin-point location function in navigation apps.
• 42.1% of apps can programmatically send SMS messages.
  • This could potentially lead to unintentional data leakage or SMS spam.

Android Privacy Risks

Android apps fared better for privacy risk than their iOS counterparts. The analysis of Android apps reveals 24 different major privacy issues, of which two are considered “Critical.”

Critical Privacy Risks

• 10.3% of apps grant access to content provider data
  • The permission to one or more content provider’s data is granted. This could potentially lead to the disclosure of information.
• 7.53% of apps use beacons to provide and receive information from nearby devices.
  • This could result in the ability to track users across apps and locations. Geolocation is now considered PII under the California Consumer Privacy Act.

Dangerous Privacy Risks

• 19 (13%) Contain exported components that are not protected by a permission.
  • By starting and binding to the service, any app can leak information or perform unauthorized tasks.
• 78.8% of apps retrieve the device’s last known GPS coordinates.
  • Geolocation is now considered PII under the California Consumer Privacy Act.
• 87% of apps implement the Intent ‘StartService.’
  • This can cause information leakage if not configured correctly.
• 45.9% includes the Crashlytics SDK which can collect PII such as UUID, IP Address, name and email.
  • This risk could potentially lead to data leakage.
• 30.1% of apps can programmatically send SMS messages.
  • Access to messages could potentially lead to unintentional data leakage or SMS spam.
    Solution

To combat fraud and mobile threats, developers need to arm their apps with app shielding, harding and self-protection. Zimperium provides its Mobile Application Protection Suite to application development organizations to measure risk and compliance, protect against reverse engineering, and to detect and remediate real-time attacks. zScan™ inspects apps for vulnerabilities and security and privacy risks during development. zShield™ obfuscates your apps code and assets to protect against reverse engineering. zDefend™ is a secure and straightforward SDK enabling organizations to deliver self-protecting iOS and Android apps to detect mobile threats and remediation on unmanaged devices.

“Combating fraud is a major focus for our bank. We selected Zimperium’s zDefend to protect millions of online customers, and billions of transactions, against malicious apps like BankBot, device exploits and rogue WiFi networks.”

-CSO, Global 100 Financial Institution

Example automated remediations include but are not limited to the following models:

• When a man-in-the-middle (MITM) attack is occurring, the app can automatically establish a VPN to create a secure tunnel.
• When a device has malware like BankBot installed, the app can trigger immediate steps to freeze mobile access until the user resets their password online.
• When a user Jailbreaks or Roots a device, the app can allow the session to continue but raise the user’s fraud score to account for the additional risk.
• When an external actor compromises a device, the app can display a dialog box asking the user to complete their transaction offline.
• If an attacker attempts to tamper with the app, the app can become “read only” and will be unable to send data to the back end.

Conclusion

Mobile banking transactions will continue to increase as services reach more underbanked users and more mobile commerce services become available. Given the growth and the acknowledged risks from all of the stakeholders, banks need to increase mobile banking security ensuring safe and secure banking.

• Despite banks increasingly encouraging customers to use mobile banking apps and acknowledging cybersecurity as the biggest threat to the financial system, banks fail to adhere to coding best practices. Not adhering to application development best practices exposes both customer and bank data and increases the chances for fraud as banks implement more third-party mobile and cloud services.
• Banks continue to use shared code in production apps that are infrequently updated or retired. If shared code is no longer supported or is vulnerable, all apps containing this code are impacted after an incident occurs. Furthermore, shared code means that anyone (especially open source code) has the opportunity to review and probe the code for vulnerabilities and weaknesses to identify the attack surface and exploit it.
• Banks continue to share sensitive customer data with advertisers. This practice increases the chances of data leakage if a mobile banking app is reverse engineered or a third-party library or service vulnerability is exploited. If there is a data breach and personally identifiable information is exposed, banks suffer severe brand damage and regulatory fines.
• Most banks fail OWASP reverse engineering checks, secure mobile device data, or implement in-app self-protection for mobile apps. Failing reversing engineering checks allows anyone to reverse engineer an app to identify weaknesses and identify an attack surface. One such example is how cybercriminals reverse-engineered a mobile app to identify vulnerabilities and stole millions of dollars overnight from thousands of users all without being detected.

Zimperium Can Help

If you would like to identify if your app is in our data set or learn more about how Zimperium can help you measure and limit your mobile app risk, please contact us for more information.