Replay Attack on Aws

A replay attack occurs when an attacker captures a valid request — such as an AWS‑signed API call, a pre‑signed S3 URL, or an STS token exchange — and resends it later to gain unauthorized access or perform unintended actions. In AWS environments the attack surface is shaped by the way requests are authenticated and authorized.

• AWS Signature V4 (SigV4) requests: The SigV4 process includes a timestamp (x-amz-date) and an expiration window (typically 15 minutes). If a service does not reject requests whose timestamp falls outside a tight skew tolerance, an attacker can replay the captured request within that window.
• Pre‑signed S3 URLs: These URLs embed a signature, an expiration (Expires parameter), and the HTTP method. An attacker who intercepts a URL before it expires can reuse it to download or upload objects until the expiration time passes.
• STS AssumeRole / GetSessionToken: Temporary credentials returned by STS have a configurable session duration (up to 12 hours for roles). If an application stores these credentials and does not enforce short‑lived use or rotation, an attacker who obtains the credentials can reuse them for the full session length.
• Amazon API Gateway without request validation: When API Gateway is configured to pass requests straight to a backend Lambda or HTTP integration without validating required headers (e.g., x-amz-date, Authorization) or without enabling usage‑plan throttling, a captured request can be replayed.
• Amazon SQS and SNS without deduplication: Messages that lack a MessageDeduplicationId (SQS FIFO) or MessageGroupId (SNS FIFO) can be resent, causing duplicate processing that may trigger unintended side‑effects.

Real‑world examples include CVE‑2020-10309, where insufficient validation of the x-amz-date header in a custom Lambda authorizer allowed replayed SigV4 requests to bypass authentication, and AWS Security Advisory 2021‑003, which highlighted the risk of long‑lived pre‑signed S3 URLs in public‑facing web apps.

Detecting replay‑prone configurations does not require agents or credentials; it can be done by observing the unauthenticated attack surface that middleBrick scans. The scanner looks for missing or weak replay mitigations across the 12 parallel checks, especially in the Authentication and Input Validation categories.

• Timestamp validation: middleBrick checks whether the endpoint rejects requests with a stale x-amz-date header (outside a configurable skew, e.g., ±5 minutes). If the service accepts such requests, it flags a missing replay protection.
• Pre‑signed URL expiration: For S3 pre‑signed URLs, the scanner verifies that the Expires parameter is present and set to a short duration (≤ 15 minutes). Longer expirations trigger a finding.
• Temporary credential lifetime: When scanning STS endpoints, middleBrick notes whether the returned Credentials.SessionToken is accompanied by a short Expiration window; long‑lived sessions are reported.
• Idempotency / deduplication headers: For POST/PUT endpoints that modify state, the scanner looks for use of idempotency tokens (e.g., Idempotency-Key header) or AWS‑specific deduplication fields (MessageDeduplicationId for SQS FIFO, MessageGroupId for SNS FIFO). Absence of these mechanisms is flagged.
• API Gateway request validation: If API Gateway is in use, the scanner detects whether request validation is enabled (required query parameters, headers, and body schemas). Lack of validation increases replay risk.

Because middleBrick performs these checks in real time against the live endpoint (5–15 seconds per scan), developers can quickly see whether their AWS‑exposed APIs are susceptible to replay without needing to deploy agents or write custom test scripts.

Mitigating replay attacks in AWS relies on built‑in service features and proper configuration rather than custom blocking logic. The following code snippets illustrate how to harden common AWS integrations.

1. Short‑lived pre‑signed S3 URLs (JavaScript v3 SDK)

import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({});

async function getShortLivedUrl(bucket, key) {
  const command = new GetObjectCommand({ Bucket: bucket, Key: key });
  // 5‑minute expiration (300 seconds) – well below the default 15 min
  const url = await getSignedUrl(s3, command, { expiresIn: 300 });
  return url;
}

// Usage
getShortLivedUrl('my-bucket', 'report.pdf').then(console.log);

2. Validate SigV4 timestamp in a Lambda authorizer (Node.js)

export const handler = async (event) => {
  const dateHeader = event.headers['x-amz-date'] || event.headers['X-Amz-Date'];
  if (!dateHeader) {
    return generatePolicy('user', 'Deny', event.methodArn);
  }
  const requestTime = new Date(dateHeader);
  const now = new Date();
  const skewMs = Math.abs(now - requestTime);
  // Allow at most 3 minutes skew
  if (skewMs > 3 * 60 * 1000) {
    return generatePolicy('user', 'Deny', event.methodArn);
  }
  // Additional verification of signature can be delegated to API Gateway
  return generatePolicy('user', 'Allow', event.methodArn);
};

function generatePolicy(principalId, effect, resource) {
  return {
    principalId,
    policyDocument: {
      Version: '2012-10-17',
      Statement: [{ Action: 'execute-api:Invoke', Effect: effect, Resource: resource }]
    }
  };
}

3. Enforce short STS session durations (AWS CLI / SDK)

# Request a role session limited to 15 minutes
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session \
  --duration-seconds 900   # 15 minutes

4. Use idempotency keys for state‑changing API calls (Python, Boto3)

import boto3
import uuid

sqs = boto3.client('sqs', region_name='us-east-1')
queue_url = 'https://sqs.us-east-1.amazonaws.com/123456789012/my-fifo.fifo'

response = sqs.send_message(
    QueueUrl=queue_url,
    MessageBody='Process order #12345',
    MessageGroupId='order-group',          # Required for FIFO
    MessageDeduplicationId=str(uuid.uuid4())  # Guarantees uniqueness
)
print(response['MessageId'])

5. Enable API Gateway request validation and usage‑plan throttling

In the API Gateway console:

• Under "Method Request" enable "Request Validator" (e.g., validate query string parameters and headers).
• Create a Usage Plan, set throttle (e.g., 10 req/sec) and burst, and associate the API stage.
• Optionally enable AWS WAF rate‑based rules to block excessive repeated requests.

By combining short expiration times, strict timestamp checks, idempotency tokens, and throttling, you eliminate the window an attacker needs to successfully replay a captured AWS request.