Bleichenbacher Attack in Rocket with Basic Auth

A Bleichenbacher attack is a cryptographic padding oracle attack originally described against PKCS#1 v1.5–based RSA encryption. When an authentication mechanism such as HTTP Basic Auth is implemented without care, it can create conditions that allow an adaptive timing-based oracle to be observed indirectly via authentication responses. In Rocket, a common pattern is to decode and validate credentials in a request guard or handler before routing. If the credential validation logic performs decryption or signature verification and its timing or error behavior differs based on whether a decryption or padding check fails, an attacker can infer information about the ciphertext even when the API surface only exposes an authentication success/failure response.

Consider a Rocket endpoint that accepts an Authorization header with Basic Auth, where the password is an encrypted blob that must be decrypted using RSA PKCS#1 v1.5. A naive implementation might decrypt the password and compare it in constant time to a stored value, but if the decryption or padding check leaks timing differences or specific error classes (e.g., padding errors versus invalid password), the endpoint can act as a padding oracle. An attacker can automate chosen-ciphertext requests, observing timing differences or error message variations to gradually recover the plaintext password without ever having a valid credential pair. This turns what appears to be a simple Basic Auth flow into a practical Bleichenbacher attack surface.

In a black-box scan using middleBrick, this manifests as findings in multiple parallel checks: the Authentication check may flag inconsistent responses or timing anomalies on 401 paths; Input Validation may flag lack of ciphertext integrity checks; and the LLM/AI Security checks may detect indirect information leakage through error handling that could aid an adaptive oracle. Even when no LLM endpoint is involved, the scan’s cross-referencing of the OpenAPI spec with runtime behavior can highlight discrepancies between declared authentication schemes and observed server responses, emphasizing the presence of an oracle-prone authentication flow.

Concrete Rocket code that is vulnerable might look like this, where the password is base64-encoded ciphertext decrypted with RSA:

use rocket::http::Status;
use rocket::request::{self, FromRequest, Request};
use rocket::Outcome;
use base64::Engine;
use rsa::{RsaPrivateKey, PaddingScheme};
use std::time::Duration;

struct AuthenticatedUser { /* fields */ }

#[rocket::async_trait]
impl<'r> FromRequest<'r> for AuthenticatedUser {
    type Error = ();

    async fn from_request(req: &'r Request<'_>) -> request::Outcome {
        let headers = req.headers();
        if let Some(auth_header) = headers.get_one("authorization") {
            if let Some(creds) = auth_header.strip_prefix("Basic ") {
                let decoded = base64::engine::general_purpose::STANDARD.decode(creds).map_err(|_| ())?;
                let parts: Vec<&[u8]> = decoded.splitn(2, |&b| b == b':').collect();
                if parts.len() != 2 {
                    return Outcome::Error((Status::Unauthorized, ()));
                }
                let ciphertext = parts[0];
                let username = parts[1];

                // Vulnerable: RSA decryption with PKCS#1 v1.5 may leak padding errors
                let padding = PaddingScheme::new_pkcs1v15_encrypt();
                let private_key = RsaPrivateKey::from_pkcs1_der(include_bytes!("key.der")).map_err(|_| ())?;
                let clear = private_key.decrypt(padding, ciphertext).map_err(|_| ())?;
                let password = std::str::from_utf8(&clear).map_err(|_| ())?;

                // Timing-sensitive comparison and error path differences can act as an oracle
                if username == b"admin" && password == "supersecret" {
                    return Outcome::Success(AuthenticatedUser { /* fields */ });
                }
            }
        }
        Outcome::Error((Status::Unauthorized, ()))
    }
}

In this example, if private_key.decrypt raises distinct errors for padding failures versus other decryption issues, and if the request handler does not mask those differences in timing or status, an attacker can craft a Bleichenbacher-style adaptive attack against the Basic Auth endpoint. middleBrick would highlight the Authentication and Input Validation findings and map them to relevant portions of the OWASP API Top 10 and known attack patterns such as adaptive chosen-ciphertext attacks.

Remediation focuses on removing any oracle behavior from the authentication path and ensuring that all credential verification steps execute in constant time, regardless of input validity. The safest approach is to avoid decrypting secrets on every request and instead use a secure, constant-time comparison method. Prefer token-based flows where possible, but if Basic Auth is required, ensure the password verification does not expose timing or error oracles.

One concrete remediation is to validate credentials using a constant-time comparison after a fixed-duration operation to mask timing differences, and to avoid returning distinct errors for decryption versus authentication failures. Below is a revised Rocket snippet that decodes the credential, performs a constant-time check using a cryptographic hash comparison, and returns a uniform unauthorized response without leaking internal errors:

use rocket::http::Status;
use rocket::request::{self, FromRequest, Request};
use rocket::Outcome;
use base64::Engine;
use subtle::ConstantTimeEq;

struct AuthenticatedUser { /* fields */ }

#[rocket::async_trait]
impl<'r> FromRequest<'r> for AuthenticatedUser {
    type Error = ();

    async fn from_request(req: &'r Request<'_>) -> request::Outcome {
        let headers = req.headers();
        if let Some(auth_header) = headers.get_one("authorization") {
            if let Some(creds) = auth_header.strip_prefix("Basic ") {
                let decoded = match base64::engine::general_purpose::STANDARD.decode(creds) {
                    Ok(d) => d,
                    Err(_) => return Outcome::Error((Status::Unauthorized, ())),
                };
                let parts: Vec<&[u8]> = decoded.splitn(2, |&b| b == b':').collect();
                if parts.len() != 2 {
                    return Outcome::Error((Status::Unauthorized, ()));
                }
                let username = parts[0];
                let password = parts[1];

                // Use a constant-time comparison against a precomputed hash of the expected password
                // For example, store hash of "supersecret" and compare using subtle::ConstantTimeEq
                let expected_password_hash = hash_password(b"supersecret"); // implement or use a proper KDF in production
                if username.ct_eq(b"admin").unwrap_u8() == 1 {
                    let password_ct_eq = constant_time_password_check(password, &expected_password_hash);
                    if password_ct_eq {
                        return Outcome::Success(AuthenticatedUser { /* fields */ });
                    }
                }
            }
        }
        // Always return the same status and no internal error information
        Outcome::Error((Status::Unauthorized, ()))
    }
}

// Example helper: constant-time password check using a hash comparison.
// In production, use a proper key derivation function (e.g., argon2, scrypt, or PBKDF2).
fn constant_time_password_check(input: &[u8], expected_hash: &[u8]) -> bool {
    use sha2::{Sha256, Digest};
    let mut hasher = Sha256::new();
    hasher.update(input);
    let input_hash = hasher.finalize();
    input_hash.ct_eq(expected_hash).unwrap_u8() == 1
}

fn hash_password(password: &[u8]) -> Vec {
    use sha2::{Sha256, Digest};
    let mut hasher = Sha256::new();
    hasher.update(password);
    hasher.finalize().to_vec()
}

This approach ensures that the server’s response and timing do not reveal whether a username exists or whether a decryption or padding failure occurred. middleBrick’s Authentication and Input Validation checks will still run, but the findings related to oracle behavior should be absent when the implementation avoids branching on secret-dependent data and uses constant-time operations.

Additionally, consider moving away from embedding encrypted passwords in application code and instead use secure secret management and short-lived tokens. If you must use asymmetric encryption, prefer RSA-OAEP over PKCS#1 v1.5 to eliminate padding oracle risks entirely. middleBrick’s LLM/AI Security checks can help detect accidental leakage of secrets or improper error handling in verbose responses that could aid an attacker in adaptive attacks.