Mobile App iOS & Android Blackbox - Sol Strategies

The application lacks several important HTTP security headers, which are instrumental in enhancing the security posture of web applications by instructing browsers on how to behave when handling the site's content. The absence of these headers leaves the application vulnerable to various attack vectors, including Man-in-the-Middle (MITM) attacks, Cross-Site Scripting (XSS), clickjacking, and MIME-type sniffing.

Missing Security Headers:

• Strict-Transport-Security: the lack of the HTTP Strict Transport Security (HSTS) header exposes the application to MitM attacks by allowing the use of insecure HTTP connections.

In the images below, it is possible to observe the security headers returned by the servers in the response:

• https://mobile-api.orangefin.ventures/api/v1/delete-user: the server does not return the Strict-Transport-Security security header:

It is recommended to implement the missing HTTP security headers with appropriate policies. Implementing these security headers will significantly enhance the security of the application by preventing various web-based attacks and ensuring safer interactions with the user's browser.

SOLVED: The vulnerability was fixed by the SOL Strategies team by adding Strict-Transport-Security security header.

The application did not have any security features or mechanisms to prevent malicious actions, Anti Hook and Anti Debug mechanisms.

- Install Frida on the rooted phone (https://frida.re/docs/android/)

- Use the Objection Tool to investigate the Anti-Hook mechanisms in the application (https://github.com/sensepost/objection)

- Use the following command in the objection tool to investigate the rooted device.

objection -g <package-name> explore

Launching the app with objection attached:

The application did not terminate; therefore the application did not have anti-hook or anti-tampering mechanisms.

Anti-Debug, Anti-Hook and Integrity Check mechanism (completed in the native code), will protect against injection of various types of scripts into it, i.e., Frida Gadgets. The application should not allow modifications in its operation.

PARTIALLY SOLVED: A new alert was shown to the user when operating the app from a rooted device. The app can continue afterwards.

WebViews are allowed to load content from any origin, bypassing security restrictions. Allowing WebViews to load any origin means the app does not restrict which external domains can be loaded within its WebView, but it does not imply that the app arbitrarily loads these domains itself; rather, it opens the possibility for malicious content to be loaded if able to be exploited by an attacker.

Edit a web page loaded by the app by using a intercepting proxy. Then, for example, add a link pointing to another domain. By following that domain, the WebView does not restrict the domains that can be loaded.

Observe the app WebView loading the Halborn web page:

Implement strict origin whitelisting within the WebView by using shouldOverrideUrlLoading() to restrict which URLs the WebView can load.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

Anti-jailbreak detection mechanisms were not implemented in the iOS application. These mechanisms could help mitigate reverse engineering, application modification, and the installation of unauthorized versions of the mobile application to some extent. While these measures may not completely stop a determined adversary, they can still play a critical role in deterring attacks and increasing the effort required to successfully compromise the app. Implementing jailbreak detection can provide an additional layer of security by detecting unauthorized access to the device, helping to safeguard sensitive data and app integrity.

Check the app running in a jailbroken device:

As a security best practice, it is recommended to implement a mechanism to check the jailbroken status of the iOS device. This can be done either manually by developing a custom solution or by using pre-built libraries designed for this purpose. Jailbreak detection can involve searching for commonly known files and directories associated with jailbreaking, checking file system permissions, and identifying common jailbreak tools like Cydia, Substrate, or OpenSSH, for example. Implementing such a mechanism helps to detect tampered devices and mitigate potential security risks arising from jailbreaking.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

Anti-debug mechanisms are security measures implemented within applications to deter or prevent reverse engineers and attackers from using debugging tools to analyze the app's behavior, code, and data. Debugging allows an attacker to pause the application's execution, inspect its state, modify its memory, and step through its instructions. This capability could lead to the discovery of sensitive information, bypassing of security features, or even the introduction of malicious behavior.

Crypto wallets are prime targets for attackers due to the financial value they protect. Without anti-debug mechanisms, the wallet application becomes an accessible for hackers, providing them a clear path to decipher its workings, extract cryptographic keys, and compromise the user's digital assets. Implementing anti-debug features ensures that the wallet's integrity remains intact and that users' assets are safeguarded from unauthorized access or manipulation.

Attach a binary instrumentation tool, such as Objection, to the running application:

For applications dealing with critical data or operations, it is crucial to implement robust anti-debug mechanisms. These measures can include detecting debugging tools, interrupting the debugging process, obfuscating code, or even terminating the application when a debugging attempt is detected. By incorporating these mechanisms, the application can significantly reduce its vulnerability to reverse engineering attempts and potential exploits.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

The iOS SDK's NSURLSession framework stores data such as HTTP requests and responses in the Cache.db* database by default. If sensitive data, such as API keys or auth tokens, are cached in clear text, it can be accessed and stolen by an attacker.

The iOS application stored sensitive information related to user's login authentication tokens and data in cache.db in clear text. The encrypted HTTPs based traffic was cached and stored in cache.db file in clear text.

1. To find the cached information, open the data directory of the app (/var/mobile/Containers/Data/Application/<UUID>)

2. Go to /Library/Caches/<Bundle Identifier>

Add "no-cache, no-store" headers in the web server response, which prevents all types of native HTTP frameworks' servers from caching the requests. Additionally, sensitive information, such as API keys and auth tokens, should never be stored in clear text in the cache.

Developers should review their iOS applications and ensure that sensitive data is not stored in clear text in the cache. If sensitive data needs to be cached, it should be encrypted and stored securely in the Keychain or other secure storage mechanisms provided by iOS.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

WebViews are allowed to load content from any origin, bypassing security restrictions. Allowing WebViews to load any origin means the app does not restrict which external domains can be loaded within its WebView, but it does not imply that the app arbitrarily loads these domains itself; rather, it opens the possibility for malicious content to be loaded if able to be exploited by an attacker.

Edit a web page loaded by the app by using a intercepting proxy. Then, for example, add a link pointing to another domain. By following that domain, the WebView does not restrict the domains that can be loaded.

Observe the app WebView loading the Halborn web page:

Implement strict URL origin whitelisting in iOS WebViews by using the WKNavigationDelegate to control which URLs are allowed to load.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

The application can use biometric controls for the authentication process while is enabled.

During local authentication, an app authenticates the user with the credentials stored locally on the device. In other words, the user “unlocks” the app or some inner layer of functionality by providing a PIN, password or valid biometrics such as face or fingerprint, that are verified by referencing local data. Generally, this is done so that users can more conveniently resume an existing session with a remote service or as a means of step-up authentication to protect some critical function.

In most of the Android cases, this bypass can be achieved because of a lack of controls on BiometricPrompt class, called at the moment of the authentication. This class implements the authenticate method, which is implemented using one of the following schemas:

public void authenticate (BiometricPrompt.CryptoObject crypto,

CancellationSignal cancel,

Executor executor,

BiometricPrompt.AuthenticationCallback callback)

public void authenticate (CancellationSignal cancel,

Executor executor,

BiometricPrompt.AuthenticationCallback callback)

This method uses an AuthenticationCallback which is called when the OS scans a fingerprint or face. The second method uses CryptoObject object at the time of managing the callback onAuthenticationSucceed. In most of the cases, a bypass exists because of a misuse of this crypto object. In this specific case, it appears that the crypto object is missing, since it is being used in the first function prototype. This authentication process relies uniquely on the calling of the callback but not in the check, decrypt, and use of the crypto object. If onAuthenticationSucceed is called, then the app understands that it must be a successful authentication process.

Note: Frida has been used to bypass Biometric Authentication. Our goal is to hook the response that the native fingerprint-reading function gives to the application and alter its value so that the application believes we succeeded.

1. Victim user enable the fingerprint for security reason.

2. Malicious actor run the frida attached to the current PID:

frida -U -p <PID> -l fingerprint-bypass.js

3. The fingerprint is successfully bypassed with the script from Frida.

4. Wallet application account can be accessed without using the fingerprint.

Use the second overload of the authenticate method, using a crypto object to decrypt some asymmetric or symmetric key stored on the device and use that key to allow access or show (decrypt) mnemonic phrase:

1. Initialize Crypto object using a secure Keystore key created with setInvalidatedByBiometricEnrollment set to True

2. Create CryptoObject using the initialized object from step 1.

3. Make BiometricPrompt.AuthenticationCallback.onAuthenticationSucceeded uses crypto object for decrypting the critical app values, such as a mnemonic or a session key.

• https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.CryptoObject

Furthermore, Anti-Hook, Anti-Debug and Root detection mechanisms will prevent a feature from being hooked. This can be done in one of the following ways:

• Frida detection should be added to the application. The implementation must be completed with Custom Root detection mechanisms.

• Use SafetyNet, Firebase and other third-party frameworks to detect hooking or rooted devices

PARTIALLY SOLVED: The app could still be opened, but the main entrypoint would not load unless fingerprint unlocked. The vulnerability has lowered severity because of this.

The vulnerability allows new fingerprints to be added to the system without requiring re-authentication from the original user, potentially enabling unauthorized access. This weakens the integrity of biometric authentication, as an attacker with brief access to the device could register their own fingerprint and later gain unrestricted entry.

Add a new fingerprint to the system after the fingerprint lock has been activated on the app. Then, the app can still be unlocked with this new fingerprint.

Implement a re-authentication process whenever a new fingerprint is added, requiring the original user's biometric data to verify their identity.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

An endpoint that is not protected by an app secret key is vulnerable to unauthorized access, allowing anyone to make API calls without proper authentication. This lack of protection can lead to unauthorized modifications, or abuse of the system. Ensuring that sensitive endpoints are secured with an app secret key or other authentication methods is important for maintaining the integrity and security of the application.

Observe that the endpoint https://mobile-api.orangefin.ventures/api/v1/delete-user can be called publicly without any measures:

Ensure that all sensitive API endpoints are protected by app secret keys.

SOLVED: The vulnerability was fixed by adding a secret key needed to perform requests to the endpoint.

The iOS app allows insecure connections by disabling ATS protections. This can expose sensitive data to interception, Man-in-the-Middle (MitM) attacks, and other security risks.

Observe the application Info.plist:

<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSAllowsArbitraryLoads</key>
		<true/>
	</dict>

Ensure ATS is fully enforced by allowing only HTTPS connections. Avoid disabling ATS exceptions unless absolutely necessary.

SOLVED: The vulnerability was fixed by the SOL Strategies team by allowing only HTTPS connections

Certificate pinning is the process of associating the backend server with a particular X.509 certificate or public key, instead of accepting any certificate signed by a trusted certificate authority (CA). After storing ("pinning") the server's certificate or public key, the mobile app will subsequently connect only to the known server. Withdrawing trust from external CAs reduces the attack surface (after all, there are many cases of CAs being compromised or tricked into issuing certificates to impostors).

The certificate can be pinned and hardcoded in the app or retrieved at the time the app first connects to the backend. In the latter case, the certificate is associated ("pinned" to) the host when the host is first seen. This alternative is less secure because attackers intercepting the initial connection can inject their certificates.

The target application has not correctly implemented SSL pinning when establishing a trusted connection between the mobile applications and the back-end web services. Without enforcing SSL pinning, an attacker could man-in-the-middle the connection between mobile applications and back-end web services. This allows an attacker to sniff user credentials, session ID, etc. Certificate pinning is used in modern applications to prevent users from intercepting and analyzing HTTP traffic. Using this method, an application can verify the server's certificate and, in case there is a Man-in-The-Middle, not trust any other certificate than the one stored as default. There are many ways to perform this security countermeasure, and taking it in place does not ensure that a motivated attacker will be able to bypass it in time, but it does represent the first wall of defense against HTTP attacks.

In the following image, interception of the app communications can be seen:

The application should implement a certificate pinning to only trust known certificates, to prevent as much as possible attackers with high privileges over the device to capture the traffic.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.

The mobile application is found to be allowing data backups, as indicated by the android:allowBackup="true" setting in the AndroidManifest.xml file. This can lead to potentially sensitive information being exposed if the backup data is mishandled or accessed by malicious parties.

The application's data backup setting is configured to permit data backups. This can lead to the unintended exposure of sensitive data if the backup is not securely stored or if it is shared across different contexts that have varying security levels:

Indicate the android:allowBackup="false" setting in the AndroidManifest.xml file.

SOLVED: The vulnerability was fixed by the SOL Strategies team by disallowing backups of the app.

Anti-root mechanisms were used in the Android applications. However, these mechanisms can help mitigate reverse engineering, application modification, and unauthorized versions of mobile applications to some extent, but few if any will be completely successful against a determined adversary. However, they can be used as part of a defense-in-depth strategy that seeks to minimize the impact and likelihood of such an attack, along with binary patching, local resource modification, method hooking, method swizzling, and heap modification.

Check the app running in a rooted device:

As a security best practice, it is recommended to implement a mechanism to check the rooted status of the mobile device. This can be done either manually by implementing a custom solution or using libraries already built for this purpose. This can be done by searching for commonly known files and locations, checking file permissions and attempting to find common rooting services like SuperSU, Magisk or OpenSSH, for example.

PARTIALLY SOLVED: A new alert was shown to the user when operating the app from a rooted device. The app can continue afterwards.

Certificate pinning is a security measure that involves hardcoding the certificate or public key of a known server into the client application to prevent Man-in-the-Middle (MitM) attacks. This measure ensures that the client establishes connections only with the designated server, even in the presence of a seemingly valid certificate from a trusted Certificate Authority (CA).

Bypassing this security control can be achieved through various methods, such as exploiting vulnerabilities in the client-side implementation of pinning, manipulating the mobile device environment (e.g., root or jailbreak exploits), or leveraging control over a root CA to issue deceptive certificates. Flaws in the implementation of pinning, such as inadequate validation of the certificate chain, reliance on intermediate CAs, or insufficient coverage across all communication channels, further exacerbate the risk. This bypass can lead to successful MitM attacks, allowing attackers to intercept, modify, or redirect data transmitted over supposedly secure connections.

Launch the app with SSL Kill Switch 3 enabled and inspect the network activity:

- Robust implementation of certificate pinning: ensure that certificate pinning is correctly and securely implemented. This involves pinning the server's certificate or public key directly within the application, rather than relying solely on the Certificate Authority (CA). This approach helps prevent Man-in-the-Middle (MitM) attacks even if a CA is compromised.

- Regular updates and management of pinned certificates: regularly update the pinned certificates in your application. This is crucial to respond to potential changes in the server's certificates and to manage the expiry of certificates. A process should be in place to update these certificates with minimal disruption to the application's functionality.

- Multi-layered security approach: do not rely solely on certificate pinning for security. Implement a layered security approach that includes SSL/TLS, strong authentication and authorization mechanisms, input validation, and encryption of sensitive data both in transit and at rest.

- Compliance with best practices: follow industry best practices and guidelines for secure communication and certificate handling. Regularly review and update your practices in line with evolving security standards and threats.

FUTURE RELEASE: The SOL Strategies team will solve this issue in a future release.