DΛΣMӨП

// HackTricks · Network Services

5439 - Pentesting Redshift

5439 - Pentesting Redshift

Basic Information

This port is used by Amazon Redshift (AWS managed data warehouse). Redshift wire protocol is a slightly modified PostgreSQL protocol, so most Postgres client tooling works (psql, psycopg2, JDBC/ODBC) but auth and TLS requirements differ.

For more information check:

Aws Redshift Enum.Html

Enumeration & Connectivity

  • Default port: 5439/TCP (customizable). Serverless workgroups also default to 5439.
  • Public endpoint pattern: <clusterid>.<random>.<region>.redshift.amazonaws.com (public) or .redshift.amazonaws.com.cn (China). Serverless: <workgroup>.<random>.<region>.redshift-serverless.amazonaws.com.
  • TLS: Redshift requires TLS 1.2+ and perfect-forward-secrecy ciphers. Old clients may fail; force modern TLS: 
    psql "host=<endpoint> port=5439 user=awsuser dbname=dev sslmode=require"
# or using redshift-psql wrapper
  • Parameter group require_ssl controls if plaintext is allowed. New clusters/workgroups use default.redshift-2.0 with require_ssl=true, so downgrade/mitm is harder.[2]

Quick enum with psql

# basic banner/version
psql "host=<endpoint> user=<u> dbname=dev" -c 'select version();'
# list dbs, users, privileges
\l
\du
select * from pg_user;
select * from svv_redshift_sessions;

Errors differentiate bad password vs missing user → potential username enumeration during brute force.

Authentication paths to test

  • Database password for master user (often named awsuser) or created DB users.
  • IAM temporary database credentials: Redshift JDBC/ODBC drivers can use settings such as authMech=IAM and provider plug-ins such as plugin_name=com.amazon.redshift.plugin.OktaCredentialsProvider; the CLI/API can call redshift:GetClusterCredentials (or newer IAM/serverless credential operations). This is distinct from RDS IAM authentication and does not use rds-db:connect. Test whether compromised IAM principals can call the applicable Redshift credential action and whether CreateClusterUser/JoinGroup permissions expand the resulting database access.[1][5] 
    aws redshift get-cluster-credentials --cluster-identifier <id> \
    --db-user pentest --db-name dev --duration-seconds 900
psql "host=<endpoint> user=pentest password=<token> dbname=dev sslmode=require"
  • IAM Identity Center / SAML / Azure AD plugins: JDBC plugin_name may spin up local webserver for SSO; captured loopback callback can leak SAML assertion or temp creds.

Common misconfigurations (network)

  • Cluster marked PubliclyAccessible=true with wide-open SG (0.0.0.0/0) exposes Postgres-like surface for brute force or SQLi exploitation.
  • Default port 5439 plus default SG allows easy discovery (Shodan/Censys). Changing port is minor obscurity but sometimes overlooked in hardening checklists.
  • No enhanced VPC routing → Redshift routes COPY/UNLOAD traffic through the internet, including traffic to other AWS services. An attacker who already has database and IAM permissions may be able to UNLOAD data to an allowed S3 destination; the routing setting does not itself grant bucket access.[6]

Attack notes

  • If login succeeds, Redshift lacks superuser in serverless; in provisioned clusters the master user has broad rights including creating UDFs (Python), external schema to Spectrum, COPY from attacker S3, and UNLOAD to exfil data.
  • Check cluster parameter group for max_concurrency_scaling_clusters, require_ssl, enable_user_activity_logging – logging disabled aids stealth.
  • Serverless workgroups still reachable via TCP; same SQL attack surface as provisioned clusters.
  • Client-side metadata SQLi (Dec 2024): JDBC 2.1.0.31, Python connector 2.1.4 and ODBC 2.1.5.0 build metadata queries with unquoted user input in getSchemas/getTables/getColumns (CVE-2024-12744/5/6). If an app lets attackers control catalog or pattern arguments, you can inject arbitrary SQL that runs with the DB user used by the connector.[3] 
    # exploit vulnerable python connector 2.1.4 via metadata API
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--")
  • UDF execution model change: Redshift stopped allowing creation of new Python UDFs after October 30, 2025, but existing Python UDFs continue to function. Python UDFs cannot access the network or filesystem, so treat them as database-compute primitives rather than generic host RCE. Lambda UDFs execute in Lambda and inherit that function’s IAM role and network reachability; an overprivileged or VPC-connected function may therefore become a pivot to AWS, Internet, or private VPC endpoints, but it does not provide direct access to the Redshift host filesystem.[4][7]

Recent security changes (offense impact)

  • Public access disabled by default on new clusters/snapshots (Jan 10, 2025 change). Legacy ones may still be public.[2]
  • Encryption at rest + enforced TLS by default means sniffing/mitm harder; need valid credentials or SSRF into VPC path.
  • Serverless VPCE rollout change (Jun 27, 2025): workgroup endpoints created in up to 3 AZs at creation time. Discovery tools should enumerate all workgroup VPCE DNS names per AZ to find reachable IPs.

References