Bleichenbacher Attack in Adonisjs with Basic Auth

A Bleichenbacher attack is a cryptographic padding oracle attack originally described against PKCS#1 v1.5–based RSA encryption. When an API uses HTTP Basic Auth over TLS and performs asymmetric decryption or signature verification on the credentials, a server that exposes different timing or error behavior for valid versus invalid padding can become vulnerable. In Adonisjs, this typically arises when developers implement custom authentication logic that decrypts or verifies a token (for example, an encrypted API key or JWT) using RSA and returns distinct errors for padding failures versus other validation failures.

Consider an Adonisjs route that expects an encrypted credential (e.g., an encrypted API key) in a Basic Auth password. If the server uses Node.js’s crypto.privateDecrypt with PKCS1 padding and does not use constant-time padding verification, an attacker can iteratively craft ciphertexts and observe differences in response times or error messages. A correct padding check may result in a further validation step (e.g., checking the decrypted API key against a database), while an incorrect padding check yields an immediate error. Over many requests, the attacker can decrypt data or recover a signing key without possessing valid credentials, effectively bypassing the intended protection that Basic Auth is meant to augment.

In a black-box scan, middleBrick’s authentication and input validation checks can flag endpoints where timing or error behavior suggests a potential oracle. For example, if an endpoint responds with 500 errors for malformed encrypted credentials and 401 for invalid but well-formed credentials, this differential may indicate a padding oracle. The scan also checks for unsafe consumption patterns and LLM security risks; if the API returns stack traces or verbose errors that include cryptographic operation details, it further assists an attacker in distinguishing padding failures from other issues. Even when Basic Auth is used only as a transport-layer guard (username/password sent over HTTPS), a server-side cryptographic implementation flaw in Adonisjs can undermine the entire scheme.

To illustrate, the following Adonisjs code shows a route that decrypts an encrypted password from Basic Auth using RSA private key decryption with PKCS1 padding. Without constant-time comparison and proper error handling, this endpoint can leak information through timing or error messages:

import crypto from 'crypto';
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext';

export default class AuthController {
  public async decryptKey({ request, response }: HttpContextContract) {
    const authHeader = request.headers().authorization; // 'Basic dXNlcjpwYXNz'
    if (!authHeader || !authHeader.startsWith('Basic ')) {
      return response.status(400).send({ error: 'missing_basic_auth' });
    }
    const base64 = authHeader.split(' ')[1];
    const plain = Buffer.from(base64, 'base64').toString('utf8'); // user:encryptedPassword
    const [user, encryptedB64] = plain.split(':');
    if (!user || !encryptedB64) {
      return response.status(400).send({ error: 'malformed_basic_value' });
    }
    const encrypted = Buffer.from(encryptedB64, 'base64');
    const privateKey = process.env.RSA_PRIVATE_KEY!; // PEM string
    try {
      const decrypted = crypto.privateDecrypt({
        key: privateKey,
        padding: crypto.constants.RSA_PKCS1_PADDING,
      }, encrypted);
      const apiKey = decrypted.toString('utf8');
      // Simulated lookup; in a real app this validates the key
      if (apiKey !== 'expected-secure-key') {
        return response.status(401).send({ error: 'invalid_key' });
      }
      return response.send({ authenticated: true, user });
    } catch (err) {
      // Returning distinct errors can aid a Bleichenbacher oracle
      return response.status(500).send({ error: 'decryption_failed', details: (err as Error).message });
    }
  }
}

In this example, an attacker can send modified encrypted blobs and measure response times or inspect error details to infer padding correctness. If the decryption error is distinguishable, the oracle becomes exploitable. middleBrick’s checks for authentication and input validation aim to surface such risky patterns by identifying non-constant-time operations and overly verbose error reporting.

Remediation focuses on ensuring that cryptographic operations do not leak information via timing or error messages. When using Basic Auth in Adonisjs, treat the password (or a derived token) as an opaque value and avoid performing variable-time cryptographic operations on user-controlled data. If you must use RSA decryption, use constant-time comparison and generic error messages.

Below is a hardened version of the previous route. Key changes include:

• Using crypto.timingSafeEqual for comparing fixed-length values.
• Avoiding early returns that distinguish between padding failures and other errors.
• Returning a uniform error response to prevent information leakage.
• Validating and parsing inputs before any cryptographic work to ensure consistent code paths.

import crypto from 'crypto';
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext';

export default class AuthController {
  public async decryptKey({ request, response }: HttpContextContract) {
    const authHeader = request.headers().authorization;
    if (!authHeader || !authHeader.startsWith('Basic ')) {
      return this.unauthorized(response);
    }
    const base64 = authHeader.split(' ')[1];
    let decoded: string;
    try {
      decoded = Buffer.from(base64, 'base64').toString('utf8');
    } catch {
      return this.unauthorized(response);
    }
    const [user, encryptedB64] = decoded.split(':');
    if (!user || !encryptedB64) {
      return this.unauthorized(response);
    }
    let encrypted: Buffer;
    try {
      encrypted = Buffer.from(encryptedB64, 'base64');
    } catch {
      return this.unauthorized(response);
    }
    const privateKey = process.env.RSA_PRIVATE_KEY!;
    let decrypted: Buffer;
    try {
      decrypted = crypto.privateDecrypt({
        key: privateKey,
        padding: crypto.constants.RSA_PKCS1_PADDING,
      }, encrypted);
    } catch (err) {
      // Always return the same error to avoid oracle behavior
      return this.unauthorized(response);
    }
    // Constant-time comparison against expected key; in practice, compare a key identifier/hash
    const expected = process.env.EXPECTED_API_KEY_BYTES;
    if (!expected) {
      return this.unauthorized(response);
    }
    const expectedBuf = Buffer.from(expected, 'base64');
    const isValid = expectedBuf.length === decrypted.length && crypto.timingSafeEqual(expectedBuf, decrypted);
    if (!isValid) {
      return this.unauthorized(response);
    }
    return response.send({ authenticated: true, user });
  }

  private unauthorized(response: any) {
    return response.status(401).send({ error: 'unauthorized' });
  }
}

Additional recommendations:

• Prefer symmetric keys or JWTs with strong algorithms (e.g., HS256/RS256) and use libraries that implement constant-time verification.
• Ensure TLS is enforced so credentials are not exposed in transit.
• Standardize error responses to avoid leaking stack traces or internal details that could aid an attacker in distinguishing padding failures.
• If you rely on an OpenAPI/Swagger spec, ensure the spec accurately documents authentication requirements; middleBrick’s OpenAPI/Swagger analysis can help verify that security schemes are correctly declared and that $ref resolutions do not obscure risky endpoints.

These steps reduce the risk that an attacker can exploit timing differences or error behavior, aligning your Adonisjs Basic Auth implementation with secure cryptographic practices.