Skip to content

Latest commit

 

History

History
119 lines (78 loc) · 8.61 KB

aws-redshift-enum.md

File metadata and controls

119 lines (78 loc) · 8.61 KB
Raw

AWS - Redshift Enum

Support HackTricks and get benefits!

Amazon Redshift

Redshift is a fully managed service that can scale up to over a petabyte in size, which is used as a data warehouse for big data solutions. Using Redshift clusters, you are able to run analytics against your datasets using fast, SQL-based query tools and business intelligence applications to gather greater understanding of vision for your business.

Redshift offers encryption at rest using a four-tired hierarchy of encryption keys using either KMS or CloudHSM to manage the top tier of keys. When encryption is enabled for your cluster, it can't be disable and vice versa. When you have an unencrypted cluster, it can't be encrypted.

Encryption for your cluster can only happen during its creation, and once encrypted, the data, metadata, and any snapshots are also encrypted. The tiering level of encryption keys are as follows, tier one is the master key, tier two is the cluster encryption key, the CEK, tier three, the database encryption key, the DEK, and finally tier four, the data encryption keys themselves.

KMS

During the creation of your cluster, you can either select the default KMS key for Redshift or select your own CMK, which gives you more flexibility over the control of the key, specifically from an auditable perspective.

The default KMS key for Redshift is automatically created by Redshift the first time the key option is selected and used, and it is fully managed by AWS.

This KMS key is then encrypted with the CMK master key, tier one. This encrypted KMS data key is then used as the cluster encryption key, the CEK, tier two. This CEK is then sent by KMS to Redshift where it is stored separately from the cluster. Redshift then sends this encrypted CEK to the cluster over a secure channel where it is stored in memory.

Redshift then requests KMS to decrypt the CEK, tier two. This decrypted CEK is then also stored in memory. Redshift then creates a random database encryption key, the DEK, tier three, and loads that into the memory of the cluster. The decrypted CEK in memory then encrypts the DEK, which is also stored in memory.

This encrypted DEK is then sent over a secure channel and stored in Redshift separately from the cluster. Both the CEK and the DEK are now stored in memory of the cluster both in an encrypted and decrypted form. The decrypted DEK is then used to encrypt data keys, tier four, that are randomly generated by Redshift for each data block in the database.

You can use AWS Trusted Advisor to monitor the configuration of your Amazon S3 buckets and ensure that bucket logging is enabled, which can be useful for performing security audits and tracking usage patterns in S3.

CloudHSM

Using Redshift with CloudHSM

When working with CloudHSM to perform your encryption, firstly you must set up a trusted connection between your HSM client and Redshift while using client and server certificates.

This connection is required to provide secure communications, allowing encryption keys to be sent between your HSM client and your Redshift clusters. Using a randomly generated private and public key pair, Redshift creates a public client certificate, which is encrypted and stored by Redshift. This must be downloaded and registered to your HSM client, and assigned to the correct HSM partition.

You must then configure Redshift with the following details of your HSM client: the HSM IP address, the HSM partition name, the HSM partition password, and the public HSM server certificate, which is encrypted by CloudHSM using an internal master key. Once this information has been provided, Redshift will confirm and verify that it can connect and access development partition.

If your internal security policies or governance controls dictate that you must apply key rotation, then this is possible with Redshift enabling you to rotate encryption keys for encrypted clusters, however, you do need to be aware that during the key rotation process, it will make a cluster unavailable for a very short period of time, and so it's best to only rotate keys as and when you need to, or if you feel they may have been compromised.

During the rotation, Redshift will rotate the CEK for your cluster and for any backups of that cluster. It will rotate a DEK for the cluster but it's not possible to rotate a DEK for the snapshots stored in S3 that have been encrypted using the DEK. It will put the cluster into a state of 'rotating keys' until the process is completed when the status will return to 'available'.

Enumeration

# Get clusters
aws redshift describe-clusters
## Get if publicly accessible
aws redshift describe-clusters | jq -r ".Clusters[].PubliclyAccessible"
## Get DB username to login
aws redshift describe-clusters | jq -r ".Clusters[].MasterUsername"
## Get endpoint
aws redshift describe-clusters | jq -r ".Clusters[].Endpoint"
## Public addresses of the nodes
aws redshift describe-clusters | jq -r ".Clusters[].ClusterNodes[].PublicIPAddress"
## Get IAM roles of the clusters
aws redshift describe-clusters | jq -r ".Clusters[].IamRoles"

# Endpoint access & authorization
aws redshift describe-endpoint-access
aws redshift describe-endpoint-authorization

# Get credentials
aws redshift get-cluster-credentials --db-user <username> --cluster-identifier <cluster-id>
## By default, the temporary credentials expire in 900 seconds. You can optionally specify a duration between 900 seconds (15 minutes) and 3600 seconds (60 minutes).
aws redshift get-cluster-credentials-with-iam --cluster-identifier <cluster-id>
## Gives creds to access redshift with the IAM redshift permissions given to the current AWS account
## More in https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-access-control-identity-based.html

# Authentication profiles
aws redshift describe-authentication-profiles

# Snapshots
aws redshift describe-cluster-snapshots

# Scheduled actions
aws redshift describe-scheduled-actions

# Connect
# The redshift instance must be publicly available (not by default), the sg need to allow inbounds connections to the port and you need creds
psql -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U admin -d dev -p 5439

Privesc

{% content-ref url="../../aws-privilege-escalation/aws-redshift-privesc.md" %} aws-redshift-privesc.md {% endcontent-ref %}

Persistence

The following actions allow to grant access to other AWS accounts to the cluster:

Support HackTricks and get benefits!