Bleichenbacher Attack in Fiber with Dynamodb

A Bleichenbacher attack is a cryptographic padding oracle attack originally described against PKCS#1 v1.5–encrypted data. In a web API context, it occurs when an endpoint decrypts attacker-controlled ciphertext and reveals whether the padding is valid via timing differences or error messages. When a Fiber-based service uses Amazon DynamoDB to store encrypted blobs (for example, encrypted API keys, JWTs, or session records) and the decryption/padding-validation logic produces distinct responses or timing behavior for valid versus invalid padding, the service becomes an oracle that can be exploited.

In the combination of Fiber with DynamoDB, the vulnerability typically surfaces in these steps:

• Ciphertext is stored in a DynamoDB item (for example, in a Binary or String attribute).
• An endpoint retrieves the ciphertext from DynamoDB and attempts decryption, often using a library that performs PKCS#7 removal and validation.
• If the server distinguishes between valid padding and invalid padding—by returning different HTTP status codes, different response body content, or by introducing measurable timing differences—an attacker can iteratively send modified ciphertexts and observe responses.
• By repeating adaptive queries that exploit the padding oracle, the attacker can recover plaintext without knowing the key. In a microservice architecture where DynamoDB is the persistence layer, this risk is amplified when multiple services share the same data format and decryption logic across API boundaries.

DynamoDB itself does not introduce the padding oracle; it is the way ciphertext is handled after retrieval that matters. However, DynamoDB’s behavior can influence exploit feasibility:

• Conditional writes and strongly consistent reads can affect timing characteristics if used around decryption steps.
• Large item sizes or provisioned throughput constraints may change response latencies, potentially making timing-based detection harder or easier depending on noise levels.
• When ciphertexts are stored as attributes, improper access controls (BOLA/IDOR) can allow an attacker to fetch items that contain ciphertexts used in the Bleichenbacher workflow, especially if authorization checks are bypassed.

An example scenario: A Fiber API stores encrypted session tokens in DynamoDB. The login endpoint retrieves the item by a user-supplied identifier, decrypts the token, and returns 400 for bad padding versus 200 for valid decryption. An attacker who can enumerate identifiers and observe timing or status-code differences can mount a Bleichenbacher attack to decrypt other users’ tokens or forge valid ciphertexts.

Remediation focuses on removing padding-oracle behavior and ensuring that DynamoDB interactions do not leak distinguishability. Do not return different HTTP status codes or messages based on padding validity; use constant-time checks and uniform error handling.

package main

import (
	"context"
	"crypto/aes"
	"crypto/cipher"
	"crypto/rand"
	"encoding/base64"
	"errors"
	"fmt"
	"io"
	"time"

	"github.com/gofiber/fiber/v2"
	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

// Constant-time byte comparison to avoid timing leaks.
func subtleEquals(a, b []byte) bool {
	if len(a) != len(b) {
		return false
	}
	var diff byte
	for i := 0; i < len(a); i++ {
		diff |= a[i] ^ b[i]
	}
	return diff == 0
}

// DecryptPKCS7Unpad performs decryption and padding validation in constant time.
func decryptPKCS7Unpad(ciphertext, key []byte) ([]byte, error) {
	block, err := aes.NewCipher(key)
	if err != nil {
		return nil, err
	}

	if len(ciphertext)%aes.BlockSize != 0 {
		return nil, errors.New("invalid ciphertext length")
	}

	mode := cipher.NewCBCDecrypter(block, key[:aes.BlockSize]) // IV is prefix in this example
	plaintext := make([]byte, len(ciphertext))
	mode.CryptBlocks(plaintext, ciphertext)

	// Validate and remove PKCS#7 padding in constant time.
	paddingLen := int(plaintext[len(plaintext)-1])
	if paddingLen <= 0 || paddingLen > len(plaintext) {
		paddingLen = 0 // trigger failure, but do not early-return with distinct messages
	}

	// Check that all padding bytes are correct.
	var padErrors byte
	for i := len(plaintext) - paddingLen; i < len(plaintext); i++ {
		padErrors |= plaintext[i] ^ byte(paddingLen)
	}

	// Use subtleEquals on the padding region to avoid branching on validity.
	if !subtleEquals(plaintext[len(plaintext)-paddingLen:], make([]byte, paddingLen)) || padErrors != 0 {
		// Return a generic error; do not indicate whether padding was the issue.
		return nil, errors.New("decryption failed")
	}

	return plaintext[:len(plaintext)-paddingLen], nil
}

func main() {
	app := fiber.New()

	// Example endpoint that retrieves ciphertext from DynamoDB and decrypts safely.
	app.Get("/token/:id", func(c *fiber.Ctx) error {
		ctx := context.Background()
		cfg, err := config.LoadDefaultConfig(ctx)
		if err != nil {
			// Always return the same generic error shape to avoid information leakage.
			return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
		}
		client := dynamodb.NewFromConfig(cfg)

		id := c.Params("id")
		out, err := client.GetItem(ctx, &dynamodb.GetItemInput{
			TableName: aws.String("SecureTokens"),
			Key: map[string]types.AttributeValue{
				"id": &types.AttributeValueMemberS{Value: id},
			},
		})
		if err != nil || out.Item == nil {
			// Use a uniform delay to reduce timing distinguishability where feasible.
			time.Sleep(50 * time.Millisecond)
			return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
		}

		// Assume the ciphertext is stored as a base64-encoded string in attribute "enc".
		item := out.Item
		encAttr, ok := item["enc"]
		if !ok {
			return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
		}
		cipherB64, ok := encAttr.(*types.AttributeValueMemberS)
		if !ok {
			return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
		}

		ciphertext, err := base64.StdEncoding.DecodeString(*cipherB64.Value)
		if err != nil {
			return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid request"})
		}

		// In practice, use a secure key management approach; here we derive a key for illustration.
		key := []byte("examplekey1234567") // 16 bytes for AES-128; use proper KDF/rotation in production.

		plain, err := decryptPKCS7Unpad(ciphertext, key)
		if err != nil {
			// Do not distinguish between padding errors, decryption failures, or missing keys.
			// Introduce a small constant delay to reduce timing distinguishability.
			time.Sleep(30 * time.Millisecond)
			return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
		}

		// Successful decryption path; avoid leaking success via timing or content differences.
		return c.JSON(fiber.Map{"token": string(plain)})
	})

	_ = app.Listen(":3000")
}

Key remediation practices specific to DynamoDB and Fiber:

• Always use constant-time comparison for MAC/padding verification; avoid branching on secret-dependent values.
• Return the same HTTP status code and response shape for all failure cases (e.g., 500 with a generic message) to prevent oracle behavior.
• Introduce small, consistent delays where feasible to reduce timing variability; do not rely on this alone.
• Ensure tight IAM policies on DynamoDB so that access to ciphertext items does not enable BOLA/IDOR that would allow an attacker to select different ciphertexts for probing.
• If using JWTs or similar tokens, prefer authenticated encryption with associated data (AEAD) such as AES-GCM and avoid raw PKCS#7 padding schemes where possible.

Note: middleBrick does not fix or remediate findings; it detects and reports them with remediation guidance. Use tools like middleBrick’s CLI (middlebrick scan <url>) to identify such oracle behaviors in unauthenticated scans, and follow the guidance to harden your implementation.