Skip to content

Latest commit

 

History

History
184 lines (153 loc) · 14.9 KB

vulnerabilities-workflow-1.md

File metadata and controls

184 lines (153 loc) · 14.9 KB

Here is the combined list of vulnerabilities, formatted as markdown:

Combined Vulnerability List for django-rest-knox

This document consolidates identified vulnerabilities in the django-rest-knox project, aiming to provide a comprehensive view of potential security concerns.

1. Weak Token Entropy with Custom Token Prefix

Description: When the application is configured with a custom token prefix, the token string is built as a concatenation of the prefix and a random component. In the token‐creation routine the stored “token key” is computed as the first 15 characters of the final token. Thus, if a developer sets a custom prefix that is near the maximum allowed length (10 characters), only 5 (15 – 10) characters of the token come from the cryptographically secure random generator. This reduces the token’s effective randomness to approximately 20 bits (about 1,048,576 possible combinations). An attacker who is aware of such a configuration could use an automated brute‐force script against a publicly exposed authenticated endpoint to quickly guess a full token and thereby impersonate a valid user.

Impact: An attacker may successfully brute force the remaining token portion (especially when only 20 bits are available) to gain unauthorized access to user sessions. This could lead to unauthorized data access, account takeover, and further escalation of privileges.

Vulnerability Rank: High

Currently Implemented Mitigations:

  • The framework enforces that any custom token prefix must not exceed a defined maximum length (10 characters) as determined by the constant CONSTANTS.MAXIMUM_TOKEN_PREFIX_LENGTH.
  • The default configuration uses an empty token prefix, so in default deployments the full token randomness is used.

Missing Mitigations:

  • There is no check to ensure that the effective randomness (i.e. “random component length” retained after the prefix is prepended) is above a secure threshold.
  • No dynamic adjustment is performed on the token key length to compensate for a custom prefix.
  • A warning or error if a custom prefix reduces the random component below a secure minimum is missing.

Preconditions:

  • The application is configured with a custom token prefix that is nonempty and near the maximum allowed length.
  • The application is deployed publicly without additional rate limiting or brute-force protection on token‑protected endpoints.

Source Code Analysis:

  • In the AuthTokenManager.create() method (located in /code/knox/models.py), the token is generated by concatenating the custom prefix (obtained via self.get_token_prefix()) with the output of create_token_string().
  • Immediately afterward, the code computes the token key as: 
    token_key = token[:CONSTANTS.TOKEN_KEY_LENGTH]
    Since CONSTANTS.TOKEN_KEY_LENGTH is set to 15, a custom prefix of length 10 leaves only 5 characters from the random part.
  • Later in TokenAuthentication.authenticate_credentials() (in /code/knox/auth.py), the application queries for tokens using the first 15 characters of the token. This means that if an attacker can guess the remaining 5 characters of the token (which come from a 5‑byte hexadecimal string, i.e. about 20 bits), they may succeed in authenticating if the endpoint does not otherwise limit repeated requests.

Security Test Case:

  1. Deploy the application using a custom configuration where REST_KNOX["TOKEN_PREFIX"] is set to a 10‑character string (for example, "TESTPREFIX"[:10] or "1234567890").
  2. Trigger a login (for example, using the provided login API) and capture the returned full token. Verify that the token key (the first 15 characters) consists of the custom prefix plus only 5 random hexadecimal characters.
  3. Simulate an attacker scenario by writing a test script or using an automated tool that iterates through all 5‑character hexadecimal combinations (approximately 1 million possibilities) appended to the known 10‑character prefix.
  4. For each candidate token, make a request to a protected endpoint (e.g. the /api/ root view) with the HTTP header formatted as: 
    Authorization: Token {candidate_token}
  5. Monitor responses for a successful authentication (HTTP 200) rather than the expected HTTP 401 “Invalid token.”
  6. Confirm that the correct full token is eventually discovered by brute force. This demonstrates that the effective entropy is too low when a long custom prefix is used.

2. Insecure Default Django Settings (Hardcoded Secret Key and Debug Mode Enabled)

Description: The project’s default settings file (/code/knox_project/settings.py) uses a hardcoded value for the Django SECRET_KEY (set to "i-am-a-super-secret-key") alongside DEBUG = True and an ALLOWED_HOSTS setting of ["*"]. If these settings are not overridden in production, an attacker accessing the publicly available instance could trigger detailed error pages that reveal stack traces and sensitive configuration details. In addition, a known secret key undermines the integrity of cryptographic signing used in session management and token generation, potentially enabling session forgery or replay attacks.

Impact:

  • Disclosure of sensitive internal information via detailed error pages.
  • The possibility of forged sessions or tokens if an attacker is able to obtain or guess the hardcoded secret key.
  • Overall compromise of the security of the authentication mechanism and potential further lateral movement within the application.

Vulnerability Rank: Critical

Currently Implemented Mitigations:

  • There is no dynamic or secure loading of sensitive secrets—the settings file simply hardcodes the SECRET_KEY, DEBUG, and ALLOWED_HOSTS values.
  • The documentation and migration instructions imply that this file is intended for development or testing rather than production, but no enforcement is in place to prevent deployment with these settings.

Missing Mitigations:

  • The application should load sensitive settings (such as SECRET_KEY) from environment variables or a secure configuration system in production.
  • The DEBUG setting must be set to False for all production deployments.
  • ALLOWED_HOSTS should be restricted to specific host/domain names rather than allowing all hosts.

Preconditions:

  • The application is deployed publicly using the default settings file without overriding these insecure defaults.
  • An attacker is able to cause an error (for example, by accessing a non‐existent URL or triggering an exception) that causes Django to display a debug error page.

Source Code Analysis:

  • In /code/knox_project/settings.py the following lines are present: 
    SECRET_KEY = "i-am-a-super-secret-key"
DEBUG = True
ALLOWED_HOSTS = ["*"]
  • These values are not conditionally set based on the environment (production vs. development). In a production scenario, a publicly known secret key and debug mode enabled may reveal sensitive details about the application internals and allow an attacker to forge tokens or sessions.

Security Test Case:

  1. Deploy the application using the default settings file (i.e. without overriding SECRET_KEY, setting DEBUG=False, and correctly setting ALLOWED_HOSTS).
  2. As an external attacker, cause an error by, for example, visiting a URL that does not exist or sending an invalid payload to an API endpoint.
  3. Observe whether the server returns detailed debug information (including stack traces and configuration details) on the error page.
  4. Additionally, if the source code is publicly accessible (or if the hardcoded secret key is leaked via the error messages), attempt to use the known secret key to test whether forged cookies or tokens are accepted.
  5. Confirm that sensitive information is disclosed and that the application behavior is inconsistent with secure production practices.
  6. This test will demonstrate that the insecure default settings could be exploited in a production environment.

3. Predictable Token Key leading to potential Brute-Force Attack

Description: An attacker attempts to log in or use a Knox token to access a protected resource.

  1. The TokenAuthentication class in knox/auth.py is used to authenticate the request.
  2. The authentication process retrieves tokens from the database using the first 15 characters of the provided token (token_key) for efficiency.
  3. While the full token is hashed, the initial 15 characters (token_key) are used for direct lookup in the database.
  4. Due to the relatively short length of the token_key (15 hexadecimal characters), the search space for brute-forcing the token_key is reduced.
  5. If an attacker can successfully guess a valid token_key for a user, they can then attempt to brute-force the remaining part of the token or try to exploit other weaknesses.
  6. Although guessing the full token is still computationally expensive due to hashing, knowing a valid token_key significantly reduces the search space and increases the likelihood of a successful brute-force attack, especially if combined with other attack strategies or lack of rate limiting.

Impact:

  • Account Takeover: If an attacker successfully brute-forces a valid token_key and potentially the full token or exploits other weaknesses, they could gain unauthorized access to user accounts.
  • Data Breach: With unauthorized access, attackers can potentially access sensitive user data and application data.
  • Reputation Damage: Successful attacks can damage the reputation of the application and the organization using it.

Vulnerability Rank: High

Currently Implemented Mitigations:

  • Hashing of the full token: The complete token is hashed using a strong algorithm (SHA512 by default) before being stored in the database. This prevents direct token theft from database breaches and makes full token brute-force computationally expensive.
  • compare_digest for hash comparison: The compare_digest function is used to compare hashes, mitigating timing attacks during token verification.
  • Token expiry: Tokens have a configurable expiration time (TOKEN_TTL), reducing the window of opportunity for attackers to use compromised tokens.
  • Optional token limit per user: The TOKEN_LIMIT_PER_USER setting allows administrators to limit the number of active tokens per user, which can reduce the impact of token compromise.

Missing Mitigations:

  • Rate limiting on login attempts and token verification: There is no explicit rate limiting mechanism to prevent brute-force attacks on the login endpoint or token verification process. Implementing rate limiting would significantly increase the difficulty of brute-force attacks.
  • Increasing TOKEN_KEY_LENGTH: Increasing the length of TOKEN_KEY_LENGTH from the current 15 characters would exponentially increase the search space for brute-force attacks on the token key. While this might have a slight performance impact on token lookup, it would significantly improve security.

Preconditions:

  • Publicly accessible login endpoint or API endpoint protected by Knox Token Authentication.
  • No rate limiting mechanism in place for login attempts or token verification.
  • Attacker has knowledge of a valid username in the system.

Source Code Analysis:

  • File: /code/knox/auth.py
  • Function: authenticate_credentials(self, token) 
    def authenticate_credentials(self, token):
    '''
    Due to the random nature of hashing a value, this must inspect
    each auth_token individually to find the correct one.

    Tokens that have expired will be deleted and skipped
    '''
    msg = _('Invalid token.')
    token = token.decode("utf-8")
    for auth_token in get_token_model().objects.filter(
            token_key=token[:CONSTANTS.TOKEN_KEY_LENGTH]): # Vulnerable code: Using short token_key for lookup
        if self._cleanup_token(auth_token):
            continue

        try:
            digest = hash_token(token)
        except (TypeError, binascii.Error):
            raise exceptions.AuthenticationFailed(msg)
        if compare_digest(digest, auth_token.digest):
            if knox_settings.AUTO_REFRESH and auth_token.expiry:
                self.renew_token(auth_token)
            return self.validate_user(auth_token)
    raise exceptions.AuthenticationFailed(msg)
  • Visualization: 
    Attacker -> Login/API Request with Token -> TokenAuthentication.authenticate() -> TokenAuthentication.authenticate_credentials(token)
                                                                    |
                                                                    V
TokenAuthentication.authenticate_credentials() -> Query DB for AuthToken using token_key (first 15 chars of token)
                                                                    |
                                                                    V
DB Lookup (WHERE token_key = first_15_chars(token)) -> Returns potential AuthToken objects
                                                                    |
                                                                    V
TokenAuthentication.authenticate_credentials() -> For each AuthToken:
                                                                        Hash provided token
                                                                        Compare hash with stored digest using compare_digest()
                                                                        If match, Authenticate user
  • The code efficiently uses token_key for database lookup, but the short length of token_key (defined by CONSTANTS.TOKEN_KEY_LENGTH = 15 in /code/knox/settings.py) reduces the search space for brute-force attacks.

Security Test Case:

  1. Setup:
    • Create a user account in the Django application.
    • Ensure Knox authentication is enabled and protecting an API endpoint.
    • Disable any rate limiting mechanisms if present to clearly demonstrate the vulnerability.
  2. Procedure:
    • Obtain a valid username for the target application.
    • Write a script to brute-force the token_key (first 15 characters of the Knox token). This script would iterate through possible hexadecimal combinations of length 15.
    • For each generated token_key, construct a full token by appending random hexadecimal characters to reach the expected token length (64 characters as per default AUTH_TOKEN_CHARACTER_LENGTH).
    • For each generated full token, send an authenticated request to the protected API endpoint using the "Token <full_token>" authorization header.
    • Monitor the API responses. A successful authentication (HTTP 200 OK or similar) would indicate a successful brute-force of a valid token.
  3. Expected Result:
    • By iterating through a significant portion of the token_key space, the attacker should be able to find a valid token_key and subsequently a valid token that authenticates successfully against the API endpoint, demonstrating the vulnerability.
    • The time taken to find a valid token should be significantly less than a full brute-force of a 64-character hexadecimal token, highlighting the reduced security due to the short token_key.