SSP Wallet, Relay and Key - InFlux Technologies

The SSP-Key iOS app stores sensitive information in the iOS Keychain, which persists even after the app is uninstalled and reinstalled. Additionally, the application did not provide a logout functionality, which would allow users to clear sensitive data manually when they no longer need to use the app. Without a logout option, users have no way to explicitly remove stored credentials or tokens. Furthermore, since the keychain data remains intact across uninstalls, this could result in unauthorized access if the device is shared or compromised, as previously stored sensitive data (such as PIN and authentication tokens) can still be accessed after reinstalling the app.

• Install the SSP-Key iOS app and set up an account.

• Use a tool such as ios keychain dump to inspect keychain entries.

• Uninstall the SSP-Key app.

• Reinstall the app and observe that the previously stored sensitive keychain entries remain accessible without requiring re-authentication.

• Note that there is no logout button available in the app for users to manually clear sensitive data.

It is recommended to implement a logout feature that allows users to explicitly clear sensitive data, such as passwords and authentication tokens, from the keychain. This ensures users have control over their sensitive information and can actively secure their account if they suspect unauthorized access.

Additionally, sensitive data in the keychain should be stored using secure accessibility attributes, such as kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, to ensure it is only available when the device is unlocked and a passcode is set. This approach also ensures that sensitive data is deleted when the app is uninstalled. Lastly, avoid storing plaintext passwords directly in the keychain. Instead, store securely hashed and salted values using industry-standard cryptographic algorithms like PBKDF2 or bcrypt.

SOLVED: The InFlux Technologies team addressed the issue by implementing a delete feature, allowing users to manage and remove their data securely.

The Mnemonic Phrase of the wallet kept unencrypted in memory, even the wallet was locked. As a result, an attacker with access to the user’s machine could exfiltrate the Mnemonic Phrase. It was possible to retrieve the Mnemonic Phrase from memory in these three cases:

• When creating the wallet, it was possible to dump the mnemonic from memory

• When revealing the mnemonic after having logged in, mnemonics stayed in the memory as long as the process running.

• When recovering a wallet by copying the mnemonic and pasting it directly to the browser extension.

• When wallet was in locked state, mnemonics stayed in the memory as long as the process running.

It is crucial to recognize that the mnemonic risk extends beyond the application state; it could also be leaked into memory when the browser displays the mnemonic in clear text and as long as the process running. This potential leakage poses a significant security concern, emphasizing the need for careful handling of such sensitive information within the browser environment.

The identified vulnerability arises from the application's handling of sensitive data in plain text. To mitigate this, the team recommends the following strategies:

- Opt for storing the entropy on disk rather than the mnemonic itself. When the mnemonic is necessary in the code, consider breaking it into multiple variables. Alternatively, obfuscate the original phrase and subsequently dereference the variable holding the original phrase.

- For instances requiring Mnemonic Phrase handling, utilize the obfuscated variable with a function designed to reconstruct the original Mnemonic Phrase exactly at the point of need.

- Ensure that when the wallet is in a locked state, the mnemonic phrase is completely cleared from memory.

For the display and handling of the mnemonic phrase during wallet creation and when revealed to a logged-in user:

- Display the mnemonic phrase using an HTML5 canvas. This technique helps prevent users from copying the phrase, reducing the risk of it being unintentionally stored in memory via the clipboard.

- Limit the ability for users to copy the entire mnemonic from the extension. This approach is essential in minimizing the potential for the mnemonic to be accidentally leaked through the clipboard, thereby enhancing the security of the sensitive information.

Implementing these recommendations would significantly enhance the security of mnemonic phrase handling, reducing the risks associated with its exposure or misuse.

SOLVED: The InFlux Technologies team addressed the issue by splitting the seed phrase and private key into multiple parts during copying, which prevents direct exposure. Additional warnings and explanations have also been added to inform users about the associated risks.

The SSP-Key iOS application stores a sensitive PIN (ssp_key_pw) in plaintext within the iOS Keychain. This practice introduces a severe security vulnerability because plaintext storage of authentication data leaves it exposed to direct access if the Keychain is compromised. Since the PIN is neither hashed nor encrypted, an attacker with access to the device or Keychain can extract the PIN in its original form and use it for unauthorized access, impersonation, or decryption of other sensitive data. The accessibility level of WhenUnlocked further exacerbates the issue by allowing access to the PIN whenever the device is unlocked, increasing the risk of exploitation.

Sensitive authentication data, such as PINs, should never be stored in plaintext. Instead, use a secure, industry-standard cryptographic hashing algorithm to store a salted and hashed version of the PIN. This ensures that even if the Keychain is compromised, the PIN cannot be directly recovered or misused. Additionally, set the Keychain accessibility level to kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly to ensure data is only accessible when the device is unlocked with a secure passcode, adding another layer of protection.

SOLVED: The InFlux Technologies team addressed the issue by opting for kSecAttrAccessibleWhenUnlockedThisDeviceOnly, ensuring accessibility when the device is unlocked while balancing user experience with security.

Sharing code publicly or privately could lead to inadvertently leaving secrets in the code, making them accessible to others. Repositories are frequently cloned and forked into new projects, giving new developers access to their complete history. Any secrets within the repository's history would exist in all new repositories, and if stored in plain text, could lead to potential misuse of the secrets. In the case of a breach or unauthorized access to the source code, it could lead to further exploitation of infrastructure.

During the security assessment, it was identified that the application contained a hardcoded Private Keys and other service account details. Due to public repositories, any unauthorized access to the source code could potentially lead to the misuse of these hardcoded secrets, compromising the security and integrity of the application and its associated infrastructure.

• Identified potential sensitive data in git history here:
  https://github.com/RunOnFlux/ssp-relay/commit/d87f1360f9a5854197de4fc5955a916c7ecaabae#diff-977e7becf2c7fbcd18511d0723659f79c7efb748f53bcf2f2d482b8afe013b89

NOTE: Further, test private keys and mnemonics were identified; confirmation was required that these were only used for testing purposes and never used anywhere else.

• https://github.com/RunOnFlux/ssp-wallet/blob/master/tests/lib/wallet.spec.ts

• https://github.com/RunOnFlux/ssp-key/blob/master/tests/lib/wallet.test.ts

To address the identified risks, the following measures would be appropriate:

• Extracted hardcoded secrets from the source code and the repository's commit history.

• Changed and invalidated exposed secrets, rotate them with new, secure credentials.

• Employed environment variables, secret management solutions, or encryption for secure secret storage and management.

SOLVED: The InFlux Technologies team confirmed that the credentials identified during the assessment were exclusively for testing purposes and were not used in production.

The scoped repository uses multiple third-party dependencies. Using vulnerable third-party libraries can result in security vulnerabilities in the project that can be exploited by attackers. This can result in data breaches, theft of sensitive information, and other security issues. However, some of them were affected by public-known vulnerabilities that may pose a risk to the global application security level.

SSP Relay outdated dependencies:

SSP Key outdated dependencies:

SSP Wallet outdated dependencies:

Update all affected packages to its latest version. It is strongly recommended to perform an automated analysis of the dependencies from the birth of the project and if they contain any security issues. Developers should be aware of this and apply any necessary mitigation measures to protect the affected application.

SOLVED: The InFlux Technologies team addressed the issue by updating the dependencies to the latest.

Commits:

• SSP Key: b1feed070b9eaeb74dba08b68d41abf9b04e7359

• SSP Wallet: 3693a45b56309c09df3dbfaf11dc2088a76b635f

• SSP Relay: 5ff4f49e739bfbeafe23514e802e2195e0a1c636

The application utilizes biometric authentication mechanisms, including older Touch ID and Face ID technologies, for authentication purposes. These mechanisms are often perceived as robust, leveraging the uniqueness of biometric data like fingerprints. However, vulnerabilities in local authentication implementations can undermine this trust.

Biometric authentication works by validating users locally with stored device credentials, such biometric data (face or fingerprint). This ensures secure and convenient access to app functionality, either by resuming a session with a remote service or performing step-up authentication for sensitive operations.

In this application, a bypass was identified using the Objection framework, which exploits the application’s reliance on the native fingerprint evaluation API. Specifically, Objection was used to manipulate the response of the fingerprint reading function (evaluatePolicy) to return a successful authentication result, even when the biometric validation had failed.

Objection shared overrides the return of the evaluatePolicy function so that it returns True even if the authentication was unsuccessful.

Video: [Proof of concept]

1. Anti-Hook and Anti-Debug Protections

• Implement runtime checks to detect and prevent hooking and debugging attempts using frameworks like Frida.

• Adopt the IOSSecuritySuite, an open-source solution offering anti-hook, anti-debug, and jailbreak detection functionalities.

Repository: IOS Security Suite

2. Custom Jailbreak Detection

• Incorporate additional checks tailored to your application to identify and mitigate tampering or execution on jailbroken devices.

3. Runtime Code Obfuscation

• Use runtime obfuscation tools to make reverse engineering and tampering attempts more challenging.

SOLVED: The InFlux Technologies team addressed the issue by implementing checks against the identified risk.

The application employs biometric authentication for critical functionalities, such as accessing sensitive operations like viewing a mnemonic phrase. This implementation, however, is vulnerable to bypass attacks due to improper handling of the BiometricPrompt class. Specifically, the application does not use the CryptoObject parameter during authentication to validate or decrypt critical information securely.

The issue lies in the improper reliance on the onAuthenticationSucceeded callback, which can be exploited to simulate a successful authentication. Attackers can hook the BiometricPrompt.authenticate() method and manipulate the response, bypassing fingerprint or facial recognition checks without valid biometric data. This vulnerability can expose sensitive application data and compromise its security.

The attack was demonstrated using Frida to hook the BiometricPrompt.authenticate() method and force the application to generate a successful authentication response.

The attack was demonstrated using Frida to hook the BiometricPrompt.authenticate() method and force the application to generate a successful authentication response.

To mitigate this vulnerability, the application should enforce proper usage of the CryptoObject during biometric authentication. Specifically:

1. Implement Secure Cryptographic Verification:

Initialize a CryptoObject using a key generated in the Android Keystore with the setInvalidatedByBiometricEnrollment property set to True. Use this object to encrypt or decrypt a secure key or token.

2. Require CryptoObject for Authentication:

Ensure the onAuthenticationSucceeded callback validates the cryptographic operation performed using the CryptoObject. Access to critical data or functions should depend on this validation.

3. Add Anti-Hooking and Root Detection:

Implement anti-debugging and anti-hooking mechanisms to prevent attackers from using tools like Frida. Root detection can also help protect the app from exploitation on rooted devices.

SOLVED: The InFlux Technologies team addressed the issue by implementing checks against the identified risk.

The SSP Key application allows users to copy sensitive information, such as mnemonics, to the clipboard. While this feature enhances usability, it poses a significant security risk, particularly in environments where clipboard data can be accessed by other devices or applications. For instance, within the Apple ecosystem, clipboard data is often shared across all devices logged into the same iCloud account, such as iPhones, iPads, and Mac computers. This increases the likelihood of unauthorized access to sensitive data if any linked device is compromised or accessed by an unauthorized user. If a mnemonic is intercepted or accessed through clipboard sharing or by malicious applications, attackers could gain control over the wallet, potentially leading to loss of funds and severe privacy breaches.

It is recommended to restrict the ability to copy mnemonics or other sensitive information to the clipboard. Instead, implement alternative, secure methods for sharing sensitive data, encourage users to write down these mnemonics, or implement such as encrypted files for importing/exporting data. If clipboard copying must be allowed, provide clear warnings to users about the risks associated with copying sensitive information and advise them to clear their clipboard immediately after use.

SOLVED: The InFlux Technologies team addressed the issue by splitting the seed phrase and private key into multiple parts during copying, which prevents direct exposure. Additional warnings and explanations have also been added to inform users about the associated risks of copying these sensitive data.

The SSP Key Android app implements biometric authentication for user convenience, allowing access to sensitive operations such as viewing mnemonic phrases and signing transactions. However, the app directly trusts the system’s biometric settings without requiring re-authentication via PIN after a biometric configuration change (e.g., disabling and re-enabling biometrics or enrolling new biometric profiles). This creates a potential security vulnerability because an attacker with temporary access to an unlocked device can add their biometric data, re-enable biometrics, and subsequently gain unauthorized access to the app without knowing the PIN. The lack of validation when biometrics are reconfigured results in reduced assurance that only the legitimate user can re-enable biometric access after changes to the device’s biometric settings.

1. Set up the SSP Key app with a PIN and enable biometric authentication.

2. Disable biometric authentication on the device.

3. Re-enable biometrics and enroll a new biometric profile (e.g., a new fingerprint).

4. Open the SSP Key app and use the newly enrolled biometric to authenticate without being prompted for the PIN.

5. Observe that access to sensitive features such as viewing mnemonics is granted without verifying the user’s PIN.

To mitigate this vulnerability, the app should enforce a one-time PIN re-authentication whenever biometric settings are changed on the device. This ensures that the legitimate user is present before granting access to sensitive actions. Additionally, implementing biometric enrollment detection using Android’s biometric APIs can enhance security by ensuring that any changes to the enrolled biometrics trigger a PIN re-authentication.

SOLVED: The InFlux Technologies team solved the issue by implementing checks on changes in the biometrics of the device.

The SSP Key iOS app provides biometric authentication for user convenience, allowing access to sensitive operations such as viewing mnemonic phrases and signing transactions. However, the app directly relies on the system’s biometric settings without requiring a PIN re-authentication when biometric configurations are changed (e.g., disabling and re-enabling biometrics or adding new biometric profiles). This creates a significant security risk because an attacker with temporary access to an unlocked device could add their own biometric data, re-enable biometrics, and gain unauthorized access to the app without knowing the original PIN. Since the app does not verify the user’s identity through a PIN re-entry after biometric settings are modified, the risk of unauthorized access increases substantially.

1. Set up the SSP Key app with a PIN and enable biometric authentication.

2. Disable biometric authentication in the device settings.

3. Re-enable biometrics and add a new biometric profile (e.g., a new Face ID or fingerprint).

4. Open the SSP Key app and use the newly added biometric to authenticate without being prompted for the PIN.

5. Confirm that access to sensitive operations, such as viewing mnemonics, is granted without verifying the user’s PIN.

It is recommended that the app enforces a mandatory PIN re-authentication after any changes to the device’s biometric settings are detected. This can be implemented using iOS’s LAContext API, which allows biometric enrollment state detection. If any change is detected, sensitive operations should require the user to re-enter their PIN before allowing access.

SOLVED: The InFlux Technologies team solved the issue by implementing checks on changes in the biometrics of the device.

The mobile applications permits users to set weak passwords with a minimum length of 4 characters, which significantly undermines password strength and increases the likelihood of unauthorized access. Additionally, the app does not implement any account lockout or rate limiting mechanism, allowing attackers to attempt unlimited incorrect password entries without being penalized or delayed. This makes the application vulnerable to brute-force attacks, especially in shared environments such as mobile devices and tablets that may be accessed by multiple users.

The risk is further amplified in scenarios where devices are shared among different users or are left unattended without proper security controls. In such cases, an attacker with physical access to the device could exploit the lack of strong passwords and unlimited login attempts to gain unauthorized access to sensitive data stored within the app. Without a proper lockout mechanism, there is no safeguard against repeated guessing of PINs or passwords on shared or compromised devices.

  const setupKey = () => {
    if (password !== passwordConfirm) {
      displayMessage('error', t('cr:err_pins_no_match'));
    } else if (password.length < 4) {
      displayMessage('error', t('cr:err_pins_min_length'));
    } else {
      generateMnemonicPhrase(256);
    }
  };

To enhance the security of user accounts and mitigate the risk of brute-force attacks, it is crucial to enforce a minimum password length of 8 characters while requiring a combination of uppercase letters, lowercase letters, numbers, and special characters to ensure robust password complexity. Additionally, implementing an account lockout policy that temporarily disables login after a specified number of consecutive incorrect attempts, such as five failed attempts, can effectively prevent unauthorized access through brute-force methods. To further strengthen security, rate limiting with progressive delays between login attempts should be introduced to deter automated and repeated login attempts by attackers. These measures collectively help to reduce the risk of unauthorized access and enhance overall application security.

SOLVED: The InFlux Technologies team addressed the issue by updating the password complexity policy to include a recommendation for stronger passwords. Further, warnings for weak passwords were added, and users were now informed of the risks when selecting weaker passwords.

The application allows users to copy sensitive data, such as mnemonics or private keys, to the system clipboard. While this feature may provide convenience, it introduces significant security risks. Clipboard data can be accessed by other applications running on the same device, potentially allowing unauthorized access to sensitive information. This issue becomes even more critical in multi-device environments where clipboard contents can be shared across devices.

Copying mnemonics or private keys to the clipboard creates a risk of data leakage and unauthorized access, potentially leading to the loss of funds or compromise of user accounts. In Android environments, clipboard data is often accessible by other applications without requiring explicit user permissions, increasing the risk of exposure.

To mitigate this risk, the application should avoid copying sensitive data, such as mnemonics and private keys, to the clipboard. Instead, implement more secure alternatives, such as:

• Providing a secure in-app mechanism to temporarily view sensitive data without copying.

• Allowing users to input mnemonics or private keys directly without exposing them to the clipboard.

• If clipboard functionality is absolutely necessary, clear clipboard contents immediately after use or limit the ability to copy sensitive information only to trusted applications.

• Implement secure warnings to inform users of the risks associated with copying sensitive data.

Instead, implement alternative, secure methods for sharing sensitive data, such as encrypted files for importing/exporting data. By avoiding the use of the clipboard for sensitive data or implementing stringent controls, the risk of unauthorized access can be significantly reduced.

SOLVED: The InFlux Technologies team addressed the issue by splitting the seed phrase and private key into multiple parts during copying, which prevents direct exposure. Additional warnings and explanations have also been added to inform users about the associated risks of copying these sensitive data.

The wallet browser extension integrates a third-party iframe to facilitate cryptocurrency purchases. However, the iframe is granted extensive permissions, including access to scripts, same-origin content, popups, and sensitive APIs such as the camera, microphone, gyroscope, accelerometer, payment, and autoplay. Although these permissions are necessary for proper functionality as confirmed by the third-party service provider, they significantly expand the attack surface. If the third-party provider is compromised or malicious scripts are injected, it could lead to phishing attacks, user interface (UI) redressing, or unauthorized data capture. Without adequate control or monitoring of the iframe, the extension remains vulnerable to these risks. Additionally, the current Content Security Policy (CSP) configuration lacks frame-source restrictions, which could allow unauthorized iframes to be embedded, further increasing the risk of content injection and malicious activity.

It is recommended to strengthen the Content Security Policy (CSP) by explicitly limiting frame sources to trusted origins only. For example, use "frame-src 'self' https://buy.onramper.com" to ensure that only the intended iframe from a trusted origin is allowed, preventing rogue or unauthorized iframes from being loaded.

Additionally, consider implementing a kill switch mechanism that allows you to remotely disable the iframe functionality in case the third-party service is compromised. This can be achieved by checking a remote configuration file or flag before loading the iframe.

User awareness is also crucial in mitigating potential risks. Adding a clear warning to users about the nature of third-party integrations and encouraging them to trust the provider before proceeding will improve transparency and reduce the risk of phishing or malicious interaction.

SOLVED: The InFlux Technologies team resolved the issue by implementing the appropriate checks.

The relay server relay.ssp.runonflux.io supported outdated and deprecated versions of the TLS protocol, specifically TLS 1.0 and TLS 1.1. These versions are known to have vulnerabilities and are no longer recommended for secure communication. Additionally, modern browsers and client applications have discontinued support for these protocols due to their weak security features, potentially exposing the server and clients to attacks like protocol downgrade or MITM (Man-In-The-Middle).

These outdated TLS versions have been superseded by newer versions (e.g., TLS v1.3) which provide enhanced security features and address many of the vulnerabilities found in their predecessors. By supporting these older versions, the application not only endangers the integrity and confidentiality of data in transit but also risks non-compliance with modern security standards and regulations.

It is recommended to review and update the TLS configuration across all servers according to the following best practices:

- Disable support for outdated protocols such as TLS 1.0 and TLS 1.1.

- Remove support for weak cipher suites.

- Use strong encryption methods, ensuring key lengths of at least 256 bits for symmetric encryption and 4096 bits for RSA. For ECC algorithms, use a minimum key size of 512 bits.

SOLVED: The InFlux Technologies team resolved the issue by disabling the support for outdated TLS versions.

The API service is currently returning cacheable HTTPS responses on certain endpoints. This behavior is risky because sensitive information sent over HTTPS can be cached on the client side, potentially exposing it to unauthorized users who have access to the client's device.

Caching behavior observed indicates that HTTP response headers from the API service do not adequately prevent caching, missing headers like:

- Cache-Control: no-store, no-cache, must-revalidate, private

- Pragma: no-cache

- Expires: 0

The absence of these headers allows client-side caching of potentially sensitive information, leading to risks such as data breaches and unauthorized access.

It is advised to include the necessary HTTP headers on all sensitive endpoints to prevent caching of any sensitive information or responses that should not be stored on the client side. Specifically:

- Set Cache-Control to "no-store, no-cache, must-revalidate, private"

- Add Pragma: no-cache

- Use Expires: 0

These headers will instruct the client's browser not to store the sensitive content, reducing the risk of data exposure.

SOLVED: The InFlux Technologies team resolved the issue by implementing the appropriate headers as per the recommendations.

The iOS application lacks anti-jailbreak mechanisms, exposing it to potential exploitation by adversaries. Jailbreaking allows attackers to bypass the inherent restrictions of the iOS operating system, enabling actions such as reverse engineering, application modification, and unauthorized use of modified app versions. While no anti-jailbreak solution is entirely foolproof against a determined adversary, such mechanisms significantly increase the effort required to exploit an application and serve as a critical component of a defense-in-depth strategy.

1. Add Open-Source Jailbreak Detection Libraries

• Integrate tools such as IOSSecuritySuite or other frameworks to detect common jailbreak indicators like unauthorized files, processes, or libraries.

2. Custom Jailbreak Detection

• Implement tailored checks to identify specific jailbreak artifacts or behaviors, such as:

• Existence of known jailbreak files (e.g., Cydia.app, MobileSubstrate).

• Writable access to system directories (e.g., /private/var).

• Presence of dynamic libraries loaded into the app.

3. Frida Detection

• Add runtime detection for debugging and hooking tools such as Frida to prevent runtime tampering or reverse engineering.

SOLVED: The InFlux Technologies team addressed the issue by detecting rooted/jailbroken devices, notifying users about the security risks while ensuring minimal impact on user experience.

Anti-root mechanisms was not used in the Android applications. 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.

The application should detect rooting methods to prevent modifications to the app. 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.

SOLVED: The InFlux Technologies team addressed the issue by detecting rooted/jailbroken devices, notifying users about the security risks while ensuring minimal impact on user experience.

Certificate pinning is a security practice that binds an application to a specific X.509 certificate or public key, ensuring that it only connects to the designated server. By bypassing the need to trust external Certificate Authorities (CAs), this technique helps reduce exposure to man-in-the-middle (MitM) attacks. However, if not properly implemented, attackers can intercept communications by bypassing SSL pinning, exposing sensitive data like user credentials and session IDs.

In the case of target, although SSL pinning is implemented, it is vulnerable due to the use of methods with predictable names and a lack of anti-hooking mechanisms. This allows attackers to bypass SSL pinning, potentially leading to unauthorized interception of sensitive data and communication between the application and its backend services.

To mitigate this vulnerability, implement jailbreak/root detection by checking for known files, directories (e.g., Cydia, su, Magisk), and rooting services. Integrate anti-hooking and anti-tampering mechanisms to strengthen SSL pinning and prevent data interception. Additionally, obfuscate the SSL pinning logic using tools like ProGuard or DexGuard to hinder reverse engineering and increase security robustness.

FUTURE RELEASE: The InFlux Technologies team will address the issue in the future builds of the applications.

Certificate pinning is a security measure that binds a mobile app to a specific X.509 certificate or public key for backend communication, rather than relying on certificates from any trusted certificate authority (CA). This reduces the risk of man-in-the-middle (MitM) attacks that exploit compromised or forged CAs by ensuring the app only trusts a pre-defined certificate.

In this case, the target application has implemented SSL pinning to verify server authenticity during network communications. However, it uses methods with commonly identifiable names and lacks anti-hooking mechanisms, allowing attackers to bypass certificate pinning through runtime modifications. This vulnerability enables attackers to intercept sensitive information, such as authentication tokens, by circumventing the app’s SSL pinning protection. Although certificate pinning is an effective defense mechanism, without proper tamper resistance, it becomes vulnerable to manipulation and may not prevent determined attackers from intercepting HTTP traffic.

To mitigate this vulnerability, implement jailbreak/root detection by checking for known files, directories (e.g., Cydia, su, Magisk), and rooting services. Integrate anti-hooking and anti-tampering mechanisms to strengthen SSL pinning and prevent data interception. Additionally, obfuscate the SSL pinning logic using tools like ProGuard or DexGuard to hinder reverse engineering and increase security robustness.

FUTURE RELEASE: The InFlux Technologies team will address the issue in the future builds of the applications.

The application lack anti-tampering and anti-hooking mechanisms to detect and mitigate unauthorized modifications, runtime manipulations, and hooking attempts. These features enhance application security by ensuring file integrity, blocking execution in untrusted environments, and identifying tools like Frida or dynamic frameworks. Properly implemented, these mechanisms protect sensitive components and prevent data exposure.

To enhance the security of the application, implement cryptographic checksum validation to ensure the integrity of application files and resources at runtime. Enforce signature verification to detect unauthorized modifications or re-signing of the app. Integrate runtime integrity checks to monitor for debugging, hooking tools, or unauthorized tampering during the app’s execution. For iOS, implement jailbreak detection to identify unauthorized environments.

FUTURE RELEASE: The InFlux Technologies team will address the issue in the future builds of the applications.

The application lack anti-tampering mechanisms, emulator detection, and anti-hooking features to protect against runtime manipulation, reverse engineering, and unauthorized modifications. These measures enhance the app’s resilience by detecting unauthorized file changes, blocking execution in emulator environments, and mitigating the use of hooking tools like Frida. Proper implementation of these features ensures the security of sensitive application components and data.

To enhance the security of the application, implement cryptographic checksum validation to ensure the integrity of application files and resources at runtime. Enforce signature verification to detect unauthorized modifications or re-signing of the app. Integrate runtime integrity checks to monitor for debugging, hooking tools, or unauthorized tampering during the app’s execution. Android, utilize root detection mechanisms to restrict functionality on rooted devices.

FUTURE RELEASE: The InFlux Technologies team will address the issue in the future builds of the applications.

The browser extension had verbose logging enabled, which outputs information such as internal application data, actions, and key interactions to the browser console. While logging can be helpful during development, leaving verbose logging enabled in production poses a security risk, as it may expose sensitive details such as wallet IDs, transaction data, and other internal logics. Verbose logs can potentially be exploited by malicious actors who have physical or remote access to a user’s device. They can gain insights into the internal workings of the application, user interactions, and potentially sensitive data, which can lead to targeted attacks, data theft, or unauthorized access.

It is recommended to disable verbose logging in the production builds to prevent any data from being exposed. If logging is necessary for debugging or monitoring purposes, ensure that:

• Only minimal and non-sensitive information is logged.

• Debug logs are conditionally enabled only in development environments.

SOLVED: The InFlux Technologies team resolved the issue by disabling the logs for production builds.

The browser extension enforces only a minimal password length of 8 characters without requiring additional complexity, such as a combination of uppercase and lowercase letters, numbers, or special characters. Additionally, it lacks a robust password policy with essential security measures, such as checking for commonly used or weak passwords, or lacks a lockout mechanism. This inadequate password enforcement increases the risk of unauthorized access to sensitive extension data, including encrypted private keys and seed phrases, as simple passwords are more susceptible to brute-force or guessing attacks.

if (values.password.length < 8) {
  displayMessage('error', t('cr:err_pw_min_char'));
  return;
}

It is recommended to implement a stronger password policy that enforces greater complexity requirements, such as a mix of uppercase and lowercase letters, numbers, and special characters. Additionally, the extension should incorporate mechanisms to check for commonly used or weak passwords and temporary lockout after multiple incorrect login attempts to mitigate the risk of brute-force or guessing attacks. 

SOLVED: The InFlux Technologies team resolved and updated the password complexity policy to include a recommendation for stronger passwords. While strict enforcement is not applied, users are now informed of the risks when selecting weaker passwords. Additionally, progressive delay mechanisms have been considered to prevent excessive brute-force attempts while maintaining user convenience.

Background screen caching occurs when an iOS application’s screen is captured and displayed as a preview in the App Switcher view. While this feature provides a smooth user experience, it poses a potential security risk when sensitive information, such as user details, transaction details, or private data, is displayed. If an attacker gains access to the cached preview (e.g., via a compromised or shared device), they may extract this sensitive data, violating user privacy and security expectations.

To protect sensitive information from being visible in the App Switcher, implement measures to obscure or block sensitive screens when the app transitions to the background. Use a placeholder or blurred background to mask private data, ensuring it is not exposed to unauthorized access. This enhances privacy and security, particularly on shared or unattended devices.

SOLVED: The InFlux Technologies team addressed the issue by adding a blurred overlay.

Background screen caching refers to the process where an application’s screen is captured and displayed as a preview in the recent apps/task manager view. While this feature provides a seamless user experience, it poses a potential security risk when sensitive information, such as user details, transaction details, or other private data, is displayed. If an attacker gains access to the cached preview (e.g., via a compromised or shared device), they can extract this sensitive data.

To reduce the risk of sensitive information being exposed when the app transitions to the background, implement mechanisms to obscure the app screen. Use the FLAG_SECURE window flag for sensitive activities or fragments to prevent their content from being captured or displayed in the Android Overview (Recent Apps) screen. Additionally, override the onPause() or onStop() methods to display a placeholder view, blur sensitive content, or show a blank screen when the app moves to the background.

SOLVED: The InFlux Technologies team addressed the issue by implementing checks against the identified risk.

The application logs sensitive information, including wallet metadata and push notification tokens, in plaintext within the device logs. Logging such information introduces a potential security risk, particularly in shared or compromised environments. If a device is rooted, or if an attacker gains physical or logical access to the device, these logs could be accessed to retrieve sensitive data. Such exposure may allow attackers to impersonate push notifications, monitor user activity, or compromise the wallet, leading to unauthorized access and potential financial loss.

Although modern Android versions restrict third-party applications from accessing logs directly, this does not eliminate the risk entirely. Rooted devices, development builds with debugging enabled, or shared test environments may still expose logs to unintended parties. Therefore, logging sensitive information unnecessarily increases the attack surface and weakens the overall security posture of the application.

To reduce the risk of sensitive data exposure, avoid logging confidential information such as private keys, wallet identifiers, and authentication tokens. Ensure logs are sanitized to remove sensitive fields and disable verbose logging in production environments.

SOLVED: The InFlux Technologies team addressed the issue by implementing appropriate checks against the identified risk.

The iOS application currently allows users to take screenshots of sensitive screens, such as those displaying private keys, seed phrases, or other confidential data. This behavior poses a security risk as screenshots can be inadvertently shared, stored in cloud backups, or accessed by unauthorized parties. On shared or compromised devices, an attacker could gain access to sensitive information by reviewing stored screenshots.

A user can take a screenshot of sensitive data displayed in the application, such as the seed phrase or private key, without any restriction. These screenshots are stored in the device’s photo gallery and potentially synced with cloud services, making the data more vulnerable to unauthorized access.

To prevent sensitive data from being captured via screenshots or screen recordings, implement screen security features in the application. Use UIApplication.shared.isScreenCaptured to detect when the screen is being captured and take appropriate action, such as displaying a warning or obscuring sensitive content. Additionally, implement privacy protections such as blurring sensitive views using UIWindowLevelSecure when the app goes into the background or during app switching. These measures will help reduce the risk of sensitive information being exposed through screenshots or recordings.

FUTURE RELEASE: The InFlux Technologies team will address the issue in the future builds of the applications.

The application currently allows users to capture screenshots of sensitive screens displaying confidential information such as mnemonic seed phrase, private keys. This poses a security risk, as such screenshots can expose private financial information that could be misused if shared or accessed by unauthorized parties. This risk is particularly critical in scenarios where devices are shared, stolen, or compromised, as screenshots stored on the device can be accessed by rogue applications or attackers. Allowing screenshots increases the potential for sensitive financial data to be inadvertently leaked, resulting in a compromise of user privacy and security.

1. Open the application and navigate to a screen displaying sensitive information, such as mnemonic phrase or private key.

2. Capture a screenshot using the device’s screenshot feature.

3. Observe that the screenshot allowed without any restrictions.

To prevent sensitive information from being captured through screenshots, enable the FLAG_SECURE flag on windows displaying sensitive content. This can be done by calling getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE) in the onCreate() method of relevant activities. This ensures that screenshots, screen recordings, and streaming are disabled for the protected screens, safeguarding user data.

SOLVED: The InFlux Technologies team addressed the issue by implementing checks against the identified risk.

The SSP Relay server facilitates communication between the SSP Wallet and SSP Key by relaying requests for synchronization, signing, and other wallet operations. The SSP Wallet can function offline, and critical wallet operations, including signing transactions and synchronizing keys, can be completed without relying on the SSP Relay server. This reduces the reliance on the relay server, minimizing the potential impact of abuse. However, despite the reduced risk, the absence of rate-limiting leaves the endpoints theoretically susceptible to denial-of-service (DoS) or brute-force attacks, potentially impacting availability.

Implementing rate limiting on critical SSP Relay endpoints is still recommended to prevent potential abuse or denial-of-service attacks. Applying a reasonable request rate limit (e.g., X requests per minute per IP or per wallet identity) can help mitigate the risk of endpoint overloading.

SOLVED: The InFlux Technologies team resolved the issue by implementing the rate limitation protection.

The SSP relay API endpoint have insufficient data sanitization and lack of proper input size validation. Specifically, the parameters can accept excessively large input without any restrictions. This absence of data validation poses a potential risk, as it may lead to potential denial-of-service (DoS) attacks or resource exhaustion by sending large payloads, impacting the availability and performance of the service.

Attackers can exploit this weakness by crafting large payloads to consume excessive server resources, degrade the user experience, or even crash the service. Additionally, the lack of input sanitization might expose the application to further risks, such as injection-based attacks.

It is recommended to implement robust input validation and sanitization for all incoming data at the server level. Specifically:

• Enforce strict size limits on all fields to prevent excessively large payloads from being processed.

• Validate the data type and format of all parameters to ensure they meet expected criteria.

• Sanitize input data to mitigate potential injection attacks and ensure safe handling of user-provided data.

• Return appropriate error messages for inputs that exceed the defined limits, and log such attempts for further investigation.

• Consider implementing rate limiting to prevent abuse through high-frequency requests with large payloads.

SOLVED: The InFlux Technologies team addressed the issue by implementing limit and checks on the parameters.

The application uses insecure Keychain accessibility attributes for storing sensitive data, such as cryptographic keys, Firebase tokens, and PINs. Attributes like AlwaysThisDeviceOnly, AfterFirstUnlockThisDeviceOnly, and WhenUnlocked do not provide the necessary security for critical data. This allows access to sensitive information under less secure conditions, such as when the device is locked or after a single unlock, increasing the risk of data compromise.

It is recommended to review the keychain accessibility attributes, sensitive data such as cryptographic keys, tokens, and PINs should be stored using the kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly attribute. This ensures that data is accessible only when the device is unlocked and protected by a secure passcode. Avoid using weak attributes like AlwaysThisDeviceOnly or WhenUnlocked for critical information where necessary.

SOLVED: The InFlux Technologies team addressed the issue by opting for kSecAttrAccessibleWhenUnlockedThisDeviceOnly, ensuring accessibility when the device is unlocked while balancing user experience with security.

The wallet application facilitates copying sensitive data, specifically mnemonic and private key passphrases, to the clipboard. This functionality presents a significant security risk, as clipboard data can be accessed both locally and remotely by unauthorized processes or malicious web pages. Attackers can exploit this vulnerability by leveraging scripts or pages designed to capture clipboard contents, thereby compromising the confidentiality of critical information.

Furthermore, in multi-device environments where clipboard sharing is enabled (such as between smartphones, tablets, and laptops), sensitive data copied to the clipboard can be inadvertently exposed across multiple devices. This significantly increases the attack surface, as an attacker gaining access to any linked device can retrieve the copied mnemonic or private key. The resulting risk of unauthorized access or asset theft underscores the need for stringent handling of sensitive data within the application.

It is recommended to avoid providing a direct copy-to-clipboard feature for sensitive information such as mnemonic and private key passphrases. Instead, consider implementing a secure display mechanism that requires users to manually input or write down the passphrase. If clipboard functionality is essential for user experience, implement automatic clipboard clearing after a short period to reduce exposure time. Additionally, display a warning when sensitive information is copied, advising users to clear their clipboard and avoid copying data in shared or multi-device environments where clipboard data can sync across devices. These measures will significantly reduce the risk of unauthorized access to sensitive information.

SOLVED: The InFlux Technologies team addressed the issue by splitting the seed phrase and private key into multiple parts during copying, which prevents direct exposure. Additional warnings and explanations have also been added to inform users about the associated risks of copying these sensitive data.

The wallet browser extension has a partially restrictive declared Content-Security-Policy (CSP) that could be improved to enhance security. Specifically, it fails to define a default-src directive, which acts as a fallback policy ensuring that no malicious resources are loaded from untrusted sources that have not been explicitly declared. The absence of this fallback increases the risk of loading unintended content from unauthorized origins.

Moreover, the object-src directive is currently set to 'self', which permits the use of legacy HTML elements such as <object>, <embed>, and <applet>. These elements are prone to security risks and are no longer receiving new standardized security features (such as the sandbox or allow attributes for <iframe>). Therefore, it is recommended to explicitly set object-src 'none' to eliminate this potential attack vector unless explicitly required.

Lastly, several important directives that do not inherit from default-src are not defined, leaving additional areas unprotected. These missing directives include:

• base-uri

• form-action

• plugin-types

• report-uri

• sandbox

• reflected-xss

• referrer

  "content_security_policy": {
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'self'; frame-ancestors 'none';"
  },

It is recommended to add the default-src 'none' directive to your CSP as a fallback. It is also recommended to set the object-src directive to none if possible since the elements it controls are considered legacy, and to set the missing directives which do not inherit from the default-src directive.

SOLVED: The InFlux Technologies team addressed the issue by implementing checks against the identified risk.

Overlay attacks exploit the ability to display a user interface element on top of other applications, which malicious apps can use to trick users into performing unintended actions. This is often achieved by displaying a fake UI or dialog over a legitimate app, leading to risks such as credential theft, like user password and PIN, or unauthorized actions.

For instance, a malicious app could display a login form over a legitimate app, tricking users into entering their credentials, mnemonics, and Private keys. Android’s SYSTEM_ALERT_WINDOW permission enables apps to display overlays, and without proper protections, your application could become vulnerable to these attacks.

To prevent overlay attacks, implement the following best practices:

1. Detect and Block Overlays: Use the TYPE_APPLICATION_OVERLAY or TYPE_SYSTEM_ALERT APIs to detect overlays when sensitive screens are displayed. In critical workflows (e.g., entering credentials), validate that no overlays are active by checking for apps with SYSTEM_ALERT_WINDOW permissions.

2. Secure Sensitive UI: Protect sensitive screens by detecting active overlays and preventing interaction if any are present. Use the getWindow().setFlags() method to set secure flags:

getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE,
                     WindowManager.LayoutParams.FLAG_SECURE);

3. User Awareness: Warn users if overlays are detected while performing sensitive actions, such as entering credentials or completing a transaction.

4. Limit Clickable Areas: Employ clickjacking prevention techniques by disabling onClick events when overlays are detected.

5. Restrict Permissions: Encourage users to limit the SYSTEM_ALERT_WINDOW permission for untrusted apps via device settings.

PARTIALLY SOLVED: The InFlux Technologies team partially addressed the issue by implementing security flags, and further communicated that edge cases related to this will be further addressed in future builds of the application.