Finding Description

Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. A malicious app installed on the device can attempt to send broadcast intents that trigger the unprotected broadcast receiver. These intents can modify the runtime of the app, making the app a potential phishing vector. If the sender app's broadcasts contain sensitive information, a malicious app may be able to perform intent sniffing, leaking sensitive data. Furthermore, a malicious app can register itself with high priority, if the broadcast is an ordered broadcast, to receive the broadcast first. If the malicious app is the first to receive the broadcast, it could cancel the broadcast causing a denial of service, or it could inject a malicious data into the broadcast.

Steps to Reproduce

The app is not following secure best practices when handling data. This could lead to sensitive information being exposed to other apps on any device.This test statically audits the app binary for any manifest declared broadcast receivers that have not been protected with permissions.

Business Impact

The app is not following secure best practices when handling data. This could lead to sensitive information being exposed to other apps on any device.

Remediation Resources

If the broadcast receiver handles sensitive information, specify Signature or SignatureorSystem level permissions to restrict access to only certain applications. When there is no requirement to send broadcasts across apps on the device i.e when the receivers are in the same app as the sender, use local broadcasts instead. Details and code snippets can be found at (https://developer.android.com/guide/components/broadcasts)

Risk and Regulatory Information

Severity: medium
CVSS: 4

• CWE: CWE-925: Improper Verification of Intent by Broadcast Receiver

Application

• Platform: android
• Package: com.bpi.ng.mobilebanking

See more detail in the NowSecure Report

Finding Description

Your application is using addJavascriptInterface().
This may allow an attacker to execute arbitrary code on Android devices.
The vulnerability is exploited by injecting JavaScript into a WebView which then would be loaded by the application and executed.

Steps to Reproduce

This test statically checks reverse engineered code for the usage of addJavascriptInterface().

Business Impact

The app is using a 3rd party library to communicate which is not secure.
A malicious actor could remotely see and modify information coming to and from the app, potentially from multiple users at once.

Remediation Resources

Disable JavaScript and Plugin support if they are not needed.
They are disabled by default but it is good practice to explicitly set these.
Disable local file access. This restricts access to the app's resource and asset directory and mitigates against an attack from a web page which seeks to gain access to other locally accessible files.
Prevent loading content from 3rd party hosts.
This is tricky to completely prevent from within an app but a developer can override shouldOverrideUrlLoading and code shouldInterceptRequest to intercept, inspect, and validate most requests initiated from within a WebView.
A whitelist scheme can also be implemented by using the URI class to inspect the components of a URI and ensure it matches a whitelist of approved resources.
Google provides remediation steps at https://support.google.com/faqs/answer/9095419?hl=en and sample code can be found on GitHub.

This method can be used to allow JavaScript to control the host application.
This is a powerful feature, but also presents a security risk for apps targeting JELLY_BEAN or earlier.
Apps that target a version later than JELLY_BEAN are still vulnerable if the app runs on a device running Android earlier than 4.2.
The most secure way to use this method is to target JELLY_BEAN_MR1 and to ensure the method is called only when running on Android 4.2 or later.
With these older versions, JavaScript could use reflection to access an injected object's public fields.
Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application.
Use extreme care when using this method in a WebView which could contain untrusted content.

Risk and Regulatory Information

Severity: low
CVSS: 3.1

• CWE: 545
• FISMA MED: SC-18 MOBILE CODE, SC-8 TRANSMISSION CONFIDENTIALITY AND INTEGRITY
• Risk OWASP: Mobile Top 10: M10-Extraneous Functionality
• GDPR: Risks violating Article 25, Risks violating Article 32
• FFIEC: May violate D3.PC.Im.I.6
• PCI: May violate requirement 6.5
• HIPAA: May violate §164.312(c)(1): Standard: Integrity., May violate §164.312(a)(1): Standard: Access control.
• CCPA: Risks violating CCPA: exfiltration, theft, or disclosure of PII
• Google App Store Blockers: SC-W1 - JavaScript is disabled in all WebViews (unless required)., SC-W3 - WebViews do not use addJavaScriptInterface() with untrusted content.

Application

• Platform: android
• Package: com.bpi.ng.mobilebanking

See more detail in the NowSecure Report

Finding Description

Whilst the application runs, cryptographic APIs are monitored to identify any insecure usage of cryptographic algorithms or primitives.
In this case, insecure cryptographic hashing algorithms are monitored.

Steps to Reproduce

Whilst the application runs, cryptographic APIs are monitored to identify any insecure usage of cryptographic algorithms or primitives.
In this case, insecure cryptographic hashing algorithms are monitored.

Business Impact

Remediation Resources

Utilize cryptographic hashing algorithms that are considered secure and advocated for in best practice recommendatiosn.
Guidance can be found for Android and from Apple.

For more guidance on best practices in picking strong cryptography, please see OWASP's Cryptographic Storage Cheat Sheet.

Risk and Regulatory Information

Severity: low
CVSS: 3.7

• CWE: 312
• ioXt: VS3
• FISMA MED: SC-28 PROTECTION OF INFORMATION AT REST
• Risk OWASP: Mobile Top 10: M2-Insecure Data Storage
• GDPR: Risks violating Article 25, Risks violating Article 32
• FFIEC: May violate D3.PC.Am.A.1
• PCI: May violate requirement 3.1 through 3.4
• HIPAA: May violate §164.312(a)(1): Standard: Access control.
• CCPA: Risks violating CCPA: exfiltration, theft, or disclosure of PII
• CWE Top 25: 2019 CWE Top 25 Most Dangerous Software Errors

Application

• Platform: android
• Package: com.bpi.ng.mobilebanking

See more detail in the NowSecure Report

Finding Description

The app is using SslErrorHandler.proceed().

Apps that use this unsafe implementation of WebViewClient.onReceivedSslError usually receive a security alert from Google that prevent them from being uploaded to the Play Store.
Using SslErrorHandler.proceed() is an unsafe implementation of the WebViewClient.onReceivedSslError handler that ignores all SSL certificate validation errors, making the app vulnerable to man-in-the-middle attacks.
An attacker could modify the affected WebView's content, steal sensitive transmitted data (such as login credentials), and execute code inside the app using JavaScript.

Steps to Reproduce

The Android WebviewClient class can notify the host application whenever a recoverable SSL certificate error occurs while loading a resource using the onReceivedSslError method call. On receiving this error, the host application can do one of two things - call SslErrorHandler.cancel() or SslErrorHandler.proceed(). The default (and recommended) behavior is to cancel the load. Applications can choose to proceed past the SSL error however using SslErrorHandler.proceed(). This test checks for instances where the application proceeds past SSL errors received by the WebViewClient.

Business Impact

The app is ignoring a warning that a connection is insecure and proceeding anyways. This can expose sensitive information to interception and modification by remote attackers.

Remediation Resources

It is strongly recommended to always call SslErrorHandler.cancel() to cancel the load when a SSL error is received by the WebviewClient. Never allow proceeding past errors using SslErrorHandler.proceed(). Apps are also advised not to prompt the user about SSL errors, since the user is unlikely to be able to make an informed security decision (WebView does not provide any UI for displaying the details of the error in a meaningful way).

In certain cases, it might be possible to instead change the app's code to only invoke SslErrorHandler.proceed() when the certificate presented by the server meets expectations, in order to properly handle SSL certificate validation. For further details, visit https://support.google.com/faqs/answer/7071387?hl=en.

Risk and Regulatory Information

Severity: medium
CVSS: 5.9

Application

• Platform: android
• Package: com.bpi.ng.mobilebanking

See more detail in the NowSecure Report

Finding Description

Android apps can dynamically register broadcast receivers and specify permissions to restrict access to them. Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. This test detects any context-registered broadcast receivers that have not been protected with permissions.

Steps to Reproduce

Android apps can dynamically register broadcast receivers and specify permissions to restrict access to them. Broadcast receivers that are registered without specifying any permissions can potentially leak sensitive info to all other applications on the device. This test detects any context-registered broadcast receivers that have not been protected with permissions.

Business Impact

A malicious app installed on the device can attempt to send broadcast intents that trigger the unprotected broadcast receiver. These intents can modify the runtime of the app, making the app a potential phishing vector. If the sender app's broadcasts contain sensitive information, a malicious app may be able to perform intent sniffing, leaking sensitive data. Furthermore, a malicious app can register itself with high priority, if the broadcast is an ordered broadcast, to receive the broadcast first. If the malicious app is the first to receive the broadcast, it could cancel the broadcast causing a denial of service, or it could inject a malicious data into the broadcast.

Remediation Resources

If the broadcast receiver handles sensitive information, specify Signature or SignatureorSystem level permissions to restrict access to only certain applications. When there is no requirement to send broadcasts across apps on the device i.e when the receivers are in the same app as the sender, use local broadcasts instead.

Risk and Regulatory Information

Severity: medium
CVSS: 4

• CWE: CWE-925: Improper Verification of Intent by Broadcast Receiver

Application

• Platform: android
• Package: com.bpi.ng.mobilebanking

See more detail in the NowSecure Report

Finding Description

The information specified has been found within local application folders or external storage locations on the device. Data written to device storage can be accessed through several attack vectors. An attacker who is able to access the charging port may be able to access this data if the user acknowledges the trust or with a rooted/jailbroken device. Often, data backup utilities can also export local files with its backup and, if not encrypted, can be then accessed by an attacker. While malware is also a concern, it is less common than attacks concerning physical device access. In the case of the data shown in the finding, the password should be treated as high value data and especially damaging if leaked. If these values are exposed they can be used to track and phish users, access their account, or circumvent protections within the app.

Steps to Reproduce

Static analysis of the compiled binary determines locations where data that could be secure keys are located.

Business Impact

The app is storing the user's password on the device insecurely. Anyone with access to the device would have access to the information.

Remediation Resources

Sensitive data should be transmitted and displayed but not persisted to memory. This is typically achieved by storing sensitive data in RAM (clear at application close) or encrypting the data using strong encryption.

If sensitive data must be persisted on the device, it should be protected appropriately. See https://developer.android.com/topic/security/data for details and code snippets to implement these protections.

The context table below gives the location on the device that the specified information was stored insecurely.

Risk and Regulatory Information

Severity: medium
CVSS: 4.4

• CWE: 312, 321, 798
• ioXt: PC1
• FISMA MED: SC-28 PROTECTION OF INFORMATION AT REST
• Risk OWASP: Mobile Top 10: M2-Insecure Data Storage
• GDPR: Risks violating Article 25, Risks violating Article 32
• FFIEC: May violate D3.PC.Am.A.1
• PCI: May violate requirement 3.1 through 3.4
• HIPAA: May violate §164.312(a)(1): Standard: Access control.
• CCPA: Risks violating CCPA: exfiltration, theft, or disclosure of PII
• CWE Top 25: 2019 CWE Top 25 Most Dangerous Software Errors

Application

• Platform: android
• Package: com.bpi.ng.mobilebanking

See more detail in the NowSecure Report