S3- Exploit Weak Bucket Policies for Privileged Access

During a red team engagement for Huge Logistics, your team found the IP address 13.43.144.61 and hardcoded AWS credentials in a shipping application. Your primary objective is to access sensitive data

1. Accessing the IP

1. Viewing the source code and discovering link to the S3 bucket

1. Basic enumeration commands:

aws s3 ls s3://hugelogistics-data # This would send a signed call
aws s3 ls s3://hugelogistics-data --no-sign-request # This would send an unsigned call
aws s3 cp s3://hugelogistics-data . --recursive # This would try to copy all contents in the s3 bucket

But everything failed.

1. Trying to fetch the bucket's ACL. Bucket ACLs are older and less flexible than bucket policies. They grant read or write access to the bucket (or objects in the bucket) to predefined Amazon S3 groups. aws s3api get-bucket-acl --bucket hugelogistics-data

1. Trying to see bucket's policy instead! aws s3api get-bucket-policy --bucket hugelogistics-data

1. We can make it more readable using sed but I used GPT.

{
  "Policy": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "PublicReadForAuthenticatedUsersForObject",
        "Effect": "Allow",
        "Principal": {
          "AWS": "*"
        },
        "Action": [
          "s3:GetObject",
          "s3:GetObjectAcl"
        ],
        "Resource": [
          "arn:aws:s3:::hugelogistics-data/backup.xlsx",
          "arn:aws:s3:::hugelogistics-data/background.png"
        ]
      },
      {
        "Sid": "AllowGetBucketPolicy",
        "Effect": "Allow",
        "Principal": {
          "AWS": "*"
        },
        "Action": "s3:GetBucketPolicy",
        "Resource": "arn:aws:s3:::hugelogistics-data"
      }
    ]
  }
}

1. Here we see that any user (represented by AWS: *) can access only background.png and backup.xlsx files in the bucket (resource tag specifies the ARN) aws s3 cp s3://hugelogistics-data/backup.xlsx .

This is encrypted. I verified this with msoffcrypto tool

1. There is no way to know the password. So using office2john makes sense

1. I removed the "backup.xlsx" name in front of the hash and saved it.

1. Used john to get password john hash.txt --wordlist=<path>/rockyou.txt

1. Used msoffcrypto-tool to decrypt msoffcrypto-tool -p summertime backup.xlsx backup_opened.xlsx

1. Open it up in excel viewer

1. By utilizing dirb I find different login portals.

1. I logged in to CRM using admin credentials, viewed invoices, exported the data, and found the flag.

Mitigation

Several factors contributed to allowing us to achieve our objectives. Firstly the bucket policy was overly permissive and allowed all AWS users (in any AWS account) to read the policy, read file ACLs, and also download them (as long as they know the file names). It is recommended to design policies in line with the principle of least privilege, providing resource access to only those that need it. The spreadsheet sitting exposed in the S3 bucket was encrypted with a password but it was found to be very weak and in a common wordlist. Instead of storing login details in a spreadsheet it would be better to use a password management solution like LastPass or Dashlane, a PAM solution or AWS SecretsManager, where the credentials can be provided as needed only to those authorized to access them. The company was also found to be storing unencrypted customer credit card details. Additionally, for a public facing website it is recommended to enable MFA for all users. This adds an extra layer of security, ensuring that even if a user's credentials are compromised, an attacker won't gain access without the second factor.