Nym response to Cure53 security audit (July 2024)

Introduction

NymVPN is designed to ensure private, secure, and reliable protection for your online communications. At Nym, transparency and user trust are paramount, which is why Nym’s code is open-source and undergoes regular independent audits to ensure the highest standards of security and privacy.

In July 2024, Nym underwent an independent audit by Cure53, a Berlin-based cybersecurity firm with over 15 years of experience conducting software tests and code audits. Their extensive review covered key components of Nym’s infrastructure, including mobile and desktop applications, VPN infrastructure, cryptography implementations, and overall system architecture.

All identified critical and high-severity vulnerabilities were addressed. We are currently waiting for feedback from Cure53 on our report and fixes.

The full Cure53 reported is published here.

Summary of the Nym Audit by Cure53

Cure53 conducted a comprehensive security assessment of the Nym ecosystem, including penetration testing, source code audits, and code reviews. The audit focused on evaluating the security posture of Nym’s mobile and desktop applications, backend API, VPN software and infrastructure, and cryptography. The Nym team continuously supported the Cure53 team throughout the audit, ensuring smooth collaboration and a transparent process.

Cure53 employed a crystal-box strategy, leveraging full access to source code, builds, documentation, test environments, and supporting scientific papers. Spanning 56 working days, the audit involved a team of six senior cybersecurity experts. The work was divided into five work packages (WPs):

• WP1: Nym mobile apps
• WP2: Nym desktop apps
• WP3: Nym backend API
• WP4: Nym VPN software and infrastructure
• WP5: Nym cryptography

The audit achieved extensive coverage across the defined scope, identifying 43 findings, including 7 security vulnerabilities – comprising critical and high-severity issues – and 24 general weaknesses, categorized as medium or low exploitation potential and representing opportunities for further strengthening the system.

The NymVPN software and infrastructure were found to be in an excellent state from a security perspective, with no issues discovered during the audit. Cure53 concluded that all the investigated components had strong security foundations, demonstrating a robust posture overall. The desktop applications were assessed to be in a good state from a security perspective, with no significant security flaws identified. The audit team highlighted that the overall implementation was solid. Similarly, the Nym backend and API were assessed to be in a moderate state from a security perspective. Notably, the report acknowledged that several critical vulnerabilities had been effectively mitigated and prevented, underscoring our proactive approach to security and careful implementation.

Key findings

WP1: Crystal-box pentests against & source code audits of Nym mobile Apps

In WP1, Cure53 conducted both static and dynamic analyses combined with white-box testing on the NymVPN mobile applications for Android and iOS. The goal was to identify any weaknesses, misconfigurations, or security risks in the applications. Overall, the findings were of a lower severity, with no critical or high-risk vulnerabilities identified. The identified issues were primarily medium, low, or informational in severity and can be effectively addressed as part of a broader effort to harden the applications. The static analysis aimed to find suboptimal settings or misconfigurations in the applications that could lead to weaknesses. However, the analysis revealed no high-risk concerns.

Further, Cure53 conducted an in-depth investigation into common attack vectors for Android, including potential access to unexported components, authentication bypasses, faulty broadcast receivers, and insufficient validation of intent extras. No vulnerabilities were identified in any of these areas, reflecting the strength of the platform's security measures.

Cure53 also confirmed that neither the Android nor iOS apps contained hardcoded sensitive information or secrets, which is a key security consideration.

Overall, the mobile apps demonstrated a good security posture with a minimal attack surface. Apart from a few minor areas for improvement, such as the improper use of the iOS app’s native secure storage (NYM-01-024), no significant security flaws were identified in the apps.

WP2: Crystal-box pentests & source code audits against Nym desktop apps

WP2 focused on the NymVPN desktop apps for Windows, Linux, and macOS. The testing team conducted a thorough review of both the frontend components for client-side issues and the Rust backend communication layer. Overall, the desktop applications demonstrated strong security practices.

Key positive findings include the use of the React framework for frontend components, which significantly reduces the attack surface. The team did not identify any major client-side vulnerabilities, aside from a very specific scenario where a malicious repository URL could trigger arbitrary JavaScript execution (XSS) if clicked under certain conditions. This issue was categorized as low risk, with no sensitive data or critical vulnerabilities identified. On the backend side, communication with the daemon over Unix socket (Linux) and pipe (Windows) was carefully examined, and no major flaws or security risks were identified.

While a few minor issues were noted, these findings focused on further enhancing security rather than addressing critical flaws.

WP3: Crystal-box pentests & source code audits against the Nym backend API

WP3 focused on the API of Nym’s backend components, including gateways and mix nodes, while excluding validators. The testing process thoroughly examined serialization/deserialization, SQL injection, authentication and authorization mechanisms, SSRF vulnerabilities, timing attacks, and code execution sinks. Positively, the Nym backend demonstrated moderate security, with no direct code execution vulnerabilities, SQLi risks, or high-risk exploitable SSRF issues identified. The authentication and authorization mechanisms in our network are implemented following secure standards, effectively mitigating potential bypasses. ** While the **backend components exhibited strong security overall, a few notable issues were identified. Among these, two findings were categorized as high or critical severity (NYM-01-027, NYM-01-030, and NYM-01-032), which we address below.

NYM-01-027 WP3: Nonce-key reuse in AES-CTR in Nym gateways (Critical)

During a source code review of the Nym repository, it was identified that the communication between the gateway and clients suffers from a major cryptographic flaw. Specifically, it was discovered that the handshake between Nym gateways and clients had the following communication encrypt data using AES-CTR and a unique, non-rotating key, together with a constant zero nonce. This, in turn, puts all communication at risk if a single plaintext leaks to an attacker, since it enables the attacker to break the encryption in place by applying simple XOR operations between ciphertexts and the leaked plaintext.

Although the confidentiality of data transferred between the client and gateway is at risk only in the event of a plaintext leak, we fully acknowledge the severity of this issue. The Nym team responded promptly by replacing the AES-CTR encryption with the recommended AES-GCM-SIV scheme, significantly enhancing communication security in the 2024.12-aero release.

NYM-01-030 WP3: Gateway skips credential serial number check (Critical)

The absence of credential serial number checks at the gateway level does not compromise the security of the system. This is because the e-cash protocol, which enables ticketing functionality, is not yet active in the NymVPN app. Additionally, the e-cash protocol is designed with built-in offline double-spending detection, meaning that even without the local checks at the gateway, nym-api validators are still able to detect and prevent double-spending attempts when tickets are verified.

While the local gateway checks provide an additional layer of early detection and can enhance the speed of identifying potential issues, they are not essential to the core functionality of the protocol. The cryptographic guarantees embedded in the e-cash protocol ensure that double-spending can still be reliably detected at a later stage, allowing any malicious actors to be identified and blacklisted. As a result, the lack of local checks does not pose a security or financial risk to the system, and these checks should be considered an optional enhancement rather than a critical safeguard.

The Nym team is currently investigating efficient ways to implement serial number checks at the gateway nodes as an enhancement feature, while the existing protocol continues to function securely without it.

NYM-01-032 WP3: Bloom filter parameters yield false positives (High)

The Bloom filter issue did not pose any risk, as the affected code was not in use within the NymVPN app and was still under active development during the audit. While the problematic parameters could cause an increased rate of false positives in double-spending checks, this would only affect usability, not the security or integrity of the system. As Bloom filters are inherently subject to false positives, we are currently investigating alternatives, such as Binary Fuse filters, to minimize any potential issues and improve performance.

Beyond these high-priority issues, the audit also highlighted several medium-severity vulnerabilities, specifically related to potential Denial of Service (DoS) attack vectors. These findings underscore areas where the NymVPN backend can improve its resilience against service disruptions. We plan to address these as part of our 2025 roadmap.

Overall, the API and backend components showcased a commendable level of security, with vulnerabilities largely confined to specific cases or opportunities for hardening.

WP4: Crystal-box pentests & source code audits against Nym VPN software & infra

WP4 involved a comprehensive security assessment of the NymVPN software, focusing on:

• Core functionality: Protocol handling, encryption, network management, DNS resolution, and implementation of IP routing, tunnelling, and overall network stack integration.
• Frontend integration: The Tauri-based UI was assessed for design, usability, and efficient integration with the Rust core via FFI, as well as platform-specific performance across Windows, macOS, and Linux.
• Key security measures: Secure credential storage, leak prevention, key management, and mitigation of known VPN vulnerabilities.

The Rust-based implementation of protocol handling, encryption, IP routing, tunnelling, and network stack integration was confirmed to be reliable, with no vulnerabilities identified. Key security features, such as credential storage, leak prevention, and encryption key management, were judged to meet high-security standards and effectively mitigate risks.

The desktop frontend was found to successfully combine usability with efficient integration into the Rust core. Error handling and logging mechanisms were confirmed to be comprehensive and thoughtfully implemented, providing valuable troubleshooting information without exposing any sensitive data.

No vulnerabilities were identified during the WP4 analysis, and the NymVPN software was affirmed to demonstrate an excellent security posture.

WP5: Crystal-box pentests & source code audits against Nym cryptography

WP5 focused on a thorough assessment of the cryptography utilized in the Nym platform. This included key components such as the Coconut crate, zk-nyms (ecash) crate, the Sphinx protocol, the Outfox protocol, and other commonly used cryptographic primitives. The source code for all cryptographic schemes, written entirely in Rust, was praised for its excellent organization, allowing auditors to quickly familiarize themselves with the implementation.

The Coconut and e-cash protocol was extensively reviewed and demonstrated the effective use of blinding mechanisms to protect sensitive information, with no unintentional information leaks identified. The two NIZKPs utilized in the protocol showed no exploitable vulnerabilities that could allow bypassing or tricking the verifier. Additionally, the selection of underlying cryptographic libraries, particularly bls12_381, ensured strict membership checks, preventing attacks using invalid curve points or incorrect subgroups. Furthermore, randomness generation for cryptographic keys and nonces was confirmed to use strong, cryptographically secure methods, supporting the integrity of key generation across the platform.

Despite these strengths, the audit also identified several issues which were classified as critical or high risk. We address each one of them individually below.

NYM-01-009 WP5: BLS12-381 EC signature bypasses in Coconut library (Critical)

Cure53 observed that the verify_partial_blind_signature function, intended to verify partial blind signatures during the issuance phase, does not include all the necessary checks for the provided signature, potentially allowing an attacker to bypass signature validation using infinity points on the elliptic curve. However, we want to clarify that within the Coconut protocol, the function verifying credential spending includes the necessary checks and reliably rejects invalid credentials. As a result, given the protocol’s design, any attempted attack would be unsuccessful, as forged credentials are detected and rejected at a later stage. This ensures the system’s security and integrity are not compromised in practice.

That said, we acknowledge that the additional checks suggested by Cure53 could enhance the robustness of these functions if they were to be used outside the specific context of Coconut. Since our code is open source and we aim to provide reusable components for the broader community, we have implemented the recommended signature checks for infinity points as an added precaution in the 2024.13-magura release. This ensures that the functions can be used reliably in other contexts while maintaining the highest standards of security.

NYM-01-014 WP5: Partial signature bypass in offline eCash (Critical)

This issue is similar to the one described above but applies to the e-cash scheme instead of Coconut. As with the Coconut implementation, all necessary checks were already implemented during the spending phase of the protocol, ensuring that any attempted attack would be rendered unsuccessful. This means that, in practice, the security and integrity of the system were never endangered, despite the issue being classified as critical.

Nevertheless, as in the case of Coconut, we have proactively implemented the additional signature checks recommended by Cure53 in all relevant functions in the 2024.13-magura release. While these checks were not required to secure the existing protocol flow, they enhanced the robustness of the code and ensured that these functions could be reliably reused in other contexts. This approach underscores our commitment to maintaining high standards of security, both for our system and for the broader open source community.

NYM-01-033 WP5: Signature forgery of Pointcheval-Sanders scheme (Critical)

Cure53 identified a vulnerability in our implementation of the sign function within the Pointcheval-Sanders signature scheme. Specifically, the vulnerability arises because, in our implementation, the random value h in the signature tuple (h, s) is not selected randomly. As a result, if we were to sign only public attributes, the signature would be susceptible to forgery.

However, it's important to emphasize that this signature forgery vulnerability does not present any risk in the context of the Coconut or e-cash protocols. Both of these protocols rely on private attributes by design, thus using the blind issuance process for signature computation. In the blind issuance protocol, the use of a commitment to the messages as an input to the hash function ensures that different tuples of messages will generate unique values for h. As a result, the vulnerability would only manifest if the Coconut or e-cash protocols were used with only public attributes, which is not the case in the Nym network. Therefore, the risk identified by Cure53 does not apply to our system, as the protocols in-use inherently mitigate this issue.

NYM-01-042 WP5: Faulty aggregation to invalid offline eCash signatures (Critical)

This issue is similar to issues NYM-01-009 and NYM-01-014, where the stand-alone aggregation function for signatures could produce an invalid signature if the adversary can manipulate the partial signatures to result in the infinity point. However, in both the Coconut and e-cash protocols, the verification process explicitly rejects any signature that results in the infinity point, so this issue does not compromise the security or integrity of either protocol. Nevertheless, in line with the actions taken for issues NYM-01-009 and NYM-01-014, we have implemented additional checks in the aggregation function to further strengthen our codebase and prevent any potential misuse in other contexts (https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md).

NYM-01-005 WP5: No infinity point check reveals plaintext for ElGamal (High)

The current implementation of Coconut and e-cash does not utilize ElGamal encryption (nor was it used during the audit). Instead, we use more efficient Pedersen commitments, which do not present the same risks. Therefore, the issue related to ElGamal does not pose any security risks within our existing system.