Missing Tls in Dynamodb
How Missing Tls Manifests in Dynamodb
Missing TLS in DynamoDB contexts creates several unique attack vectors that differ from standard HTTP API vulnerabilities. When DynamoDB clients connect without TLS, the most common manifestation occurs through the AWS SDK's default configuration, which may fall back to HTTP endpoints in certain network configurations or when credentials are misconfigured.
The primary attack pattern involves credential interception during DynamoDB API calls. Without TLS, AWS access keys travel in plaintext across the network, allowing attackers on the same network segment to capture credentials and gain full database access. This is particularly dangerous in multi-tenant environments where DynamoDB endpoints might be accessible through internal networks without proper segmentation.
Another critical manifestation occurs during DynamoDB stream processing. Applications that consume DynamoDB streams without TLS can expose sensitive data modifications to network observers. Attackers can monitor these streams to reconstruct business logic, identify high-value records, or track user behavior patterns based on database changes.
DynamoDB's Global Tables feature introduces additional TLS risks. When configuring cross-region replication without proper TLS enforcement, data synchronization between regions can expose sensitive data across geographical boundaries. This creates compliance violations for organizations subject to data residency requirements.
The AWS SDK for JavaScript provides a concrete example of how missing TLS manifests:
// Vulnerable: No TLS enforcement
const dynamodb = new AWS.DynamoDB({
region: 'us-east-1',
This configuration explicitly disables TLS, making all DynamoDB operations susceptible to man-in-the-middle attacks. The SDK's default behavior attempts to use HTTPS, but explicit HTTP endpoints override this security.
Lambda functions accessing DynamoDB present another manifestation vector. Cold starts in Lambda can sometimes establish connections through cached HTTP endpoints if the function's network configuration allows it, creating intermittent TLS failures that are difficult to detect in production.
Dynamodb-Specific Detection
Detecting missing TLS in DynamoDB environments requires examining both configuration and runtime behavior. The AWS SDK configuration files often contain the first indicators of potential TLS issues. Look for endpoint configurations that specify HTTP rather than HTTPS protocols.
Network-level detection involves monitoring DynamoDB traffic patterns. Tools like Wireshark can identify unencrypted DynamoDB API calls by examining the protocol headers. DynamoDB's API uses specific HTTP methods and headers that make unencrypted traffic identifiable even without deep packet inspection.
middleBrick's DynamoDB-specific scanning examines several critical areas. The scanner tests DynamoDB endpoints by attempting connections with various configurations to identify endpoints that accept unencrypted connections. It specifically checks for:
- DynamoDB endpoint configurations that allow HTTP connections
- Lambda function IAM roles that might permit unencrypted DynamoDB access
- API Gateway integrations with DynamoDB that lack TLS enforcement
- Application code that explicitly sets HTTP endpoints in AWS SDK configurations
The scanner also examines DynamoDB stream configurations, testing whether stream consumers can be accessed without TLS. This is particularly important for applications using DynamoDB streams for real-time processing or change data capture.
Configuration analysis includes examining CloudFormation templates, Terraform configurations, and AWS CloudFormation stacks for DynamoDB resources. The scanner looks for:
# Vulnerable configuration - no TLS enforcement
resource "aws_dynamodb_table" "example" {
name = "example-table"
billing_mode = "PROVISIONED"
write_capacity = 20
# Missing TLS configuration
middleBrick's LLM/AI security module also checks for DynamoDB configurations in AI/ML applications, as these often handle sensitive training data that requires encryption in transit.
Runtime detection involves monitoring DynamoDB API calls through CloudTrail logs, looking for any API operations that might indicate unencrypted connections or misconfigured endpoints.
Dynamodb-Specific Remediation
Remediating missing TLS in DynamoDB requires a multi-layered approach that addresses both configuration and code-level issues. The foundation is ensuring all DynamoDB client configurations explicitly require TLS.
For AWS SDK implementations, the remediation starts with proper endpoint configuration:
// Secure configuration with TLS enforcement
const dynamodb = new AWS.DynamoDB({
region: 'us-east-1',
This configuration ensures that any attempt to use HTTP endpoints will fail, preventing accidental exposure of credentials and data.
Lambda functions require special attention. The remediation involves adding VPC configurations and security group rules that only allow HTTPS traffic to DynamoDB endpoints:
// Secure Lambda DynamoDB access
export const handler = async (event: any) => {
const dynamodb = new AWS.DynamoDB({
region: process.env.AWS_REGION,
For infrastructure-as-code configurations, remediation involves updating resource definitions to enforce TLS:
# Secure DynamoDB configuration
resource "aws_dynamodb_table" "secure_table" {
name = "secure-example-table"
billing_mode = "PROVISIONED"
read_capacity = 20
write_capacity = 20
point_in_time_recovery {
# TLS is enforced by default for AWS services
server_side_encryption {
Application-level remediation includes implementing certificate pinning for DynamoDB connections in high-security environments:
import boto3
from botocore.client import Config
# Secure DynamoDB client with TLS verification
secure_config = Config(
signature_version='v4',
dynamodb = boto3.resource('dynamodb',
For applications using DynamoDB streams, remediation requires implementing TLS for all stream consumers and ensuring that stream endpoints are only accessible through secure channels.
middleBrick's CLI tool can verify these remediations by scanning your deployed APIs:
# Scan DynamoDB API endpoints for TLS compliance
middlebrick scan https://dynamodb.us-east-1.amazonaws.com --category TLSThe GitHub Action integration allows automated TLS verification in CI/CD pipelines:
- name: DynamoDB TLS Security Scan
uses: middleBrick/middlebrick@v1
with:
target: https://dynamodb.us-east-1.amazonaws.com
category: TLS
fail-on-severity: highThese remediations ensure that DynamoDB communications remain encrypted, protecting both credentials and sensitive data from network-based attacks.
Related CWEs: encryption
| CWE ID | Name | Severity |
|---|---|---|
| CWE-319 | Cleartext Transmission of Sensitive Information | HIGH |
| CWE-295 | Improper Certificate Validation | HIGH |
| CWE-326 | Inadequate Encryption Strength | HIGH |
| CWE-327 | Use of a Broken or Risky Cryptographic Algorithm | HIGH |
| CWE-328 | Use of Weak Hash | HIGH |
| CWE-330 | Use of Insufficiently Random Values | HIGH |
| CWE-338 | Use of Cryptographically Weak PRNG | MEDIUM |
| CWE-693 | Protection Mechanism Failure | MEDIUM |
| CWE-757 | Selection of Less-Secure Algorithm During Negotiation | HIGH |
| CWE-261 | Weak Encoding for Password | HIGH |