Skip to content

Latest commit

 

History

History
52 lines (45 loc) · 6.17 KB

threat-modeling.md

File metadata and controls

52 lines (45 loc) · 6.17 KB

Threat Model Analysis for keepassxreboot/keepassxc

Threat: Malicious Library Modification (Supply Chain Attack)

  • Description: An attacker compromises a dependency of the keepassxc library (e.g., a cryptographic library like libgcrypt, or a build tool) or the library itself before it reaches the developer. The attacker inserts malicious code that will be executed when the web application uses the library. This could be done via a compromised package repository, a compromised build server, or a malicious pull request that is merged into the keepassxc repository.
    • Impact:
      • Complete compromise of user data stored in KeePass databases. The attacker could steal decrypted passwords, modify database entries, or even replace the entire database with a malicious one.
      • Potential for remote code execution on the server, allowing the attacker to take control of the entire web application.
    • Affected KeePassXC Component: Potentially any component, as the entire library or its dependencies could be compromised. Most critically, components involved in:
      • KdbxFile class (for database loading/saving)
      • Crypto module (for encryption/decryption)
      • Kdf module (for key derivation)
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strict Dependency Pinning: Use precise version pinning for all dependencies (including transitive dependencies) using lockfiles (e.g., package-lock.json, poetry.lock, Pipfile.lock). Do not use version ranges.
      • Dependency Hash Verification: Verify the cryptographic hashes of downloaded dependencies against known-good hashes. Many package managers support this (e.g., pip with --require-hashes, npm with integrity attributes).
      • Software Bill of Materials (SBOM): Generate and maintain an SBOM to track all dependencies and their versions.
      • Regular Dependency Audits: Perform regular security audits of all dependencies, including checking for known vulnerabilities and suspicious code changes.
      • Vendor Security Notifications: Subscribe to security notifications from the KeePassXC project and the maintainers of its dependencies.
      • Static Code Analysis: Use static analysis tools to scan the keepassxc library and its dependencies for potential vulnerabilities.

Threat: Weak Key Derivation Function (KDF) Configuration

  • Description: The web application allows users to create or upload .kdbx files with weak KDF settings. This could be due to allowing users to choose low iteration counts, small memory parameters, or using an outdated KDF algorithm (e.g., AES-KDF instead of Argon2). An attacker who obtains a copy of the .kdbx file can then launch an offline brute-force or dictionary attack against the master password.
    • Impact:
      • Significantly increased likelihood of successful brute-force attacks against the database's master password, leading to complete compromise of the database contents.
    • Affected KeePassXC Component:
      • Kdf module (specifically, the functions related to configuring and applying the KDF, such as Argon2Kdf, AesKdf).
      • KdbxFile::create and KdbxFile::open methods, where the KDF parameters are used.
    • Risk Severity: High
    • Mitigation Strategies:
      • Enforce Strong KDF Defaults: The web application should only allow the creation of new databases with strong KDF settings (e.g., Argon2id with high iteration count, memory usage, and parallelism, as recommended by current best practices). Do not provide options for weaker settings.
      • Reject Weak Databases: The web application should reject any uploaded .kdbx files that use weak KDF settings. This requires parsing the database header to extract the KDF parameters and comparing them against a minimum acceptable configuration.
      • Automatic KDF Upgrade: Consider implementing a feature to automatically upgrade the KDF of existing databases to stronger settings (with user consent, of course, as this requires re-encrypting the entire database).
      • Educate Users: Provide clear guidance to users about the importance of strong KDF settings and why weaker options are not allowed.

Threat: Denial of Service (DoS) via KDF

  • Description: An attacker uploads a .kdbx file with extremely high KDF parameters (e.g., a very large iteration count or memory requirement). When the web application attempts to open this file using keepassxc library, it consumes excessive server resources (CPU and memory), potentially causing a denial-of-service condition for other users.
    • Impact:
      • Server resource exhaustion, making the web application unavailable to legitimate users.
    • Affected KeePassXC Component:
      • Kdf module (the key derivation process is the target of the attack).
      • KdbxFile::open method, where the KDF is applied.
    • Risk Severity: High
    • Mitigation Strategies:
      • KDF Parameter Limits: Enforce strict limits on the KDF parameters (iterations, memory, parallelism) for any .kdbx files uploaded to the server. Reject any files that exceed these limits.
      • Resource Monitoring: Monitor server resource usage (CPU, memory) and implement alerts or automatic scaling to handle increased load.
      • Rate Limiting: Implement rate limiting to prevent a single user from making too many requests that involve database decryption, especially for potentially expensive operations.
      • Timeout Decryption Attempts: Set reasonable timeouts for decryption operations. If a decryption attempt takes too long, terminate it to prevent resource exhaustion.
      • Separate Decryption Service (Optional): Consider offloading database decryption to a separate service or worker process. This can help to isolate the impact of DoS attacks and prevent them from affecting the main web application.