Welcome to Level -3. At this level, we are tasked with finding secret content in one of the S3 bucket files (“.git file").

The next level is at Level 3 link

When you click on the level 3 link, you will find the list of git files as shown below on your browser.

Creating AWS CLI Profile

Now let’s access the .git files via AWS CLI

• On your Linux terminal, Sign-in to the AWS CLI with the Access keys credentials Created in Level-2

NB: if you already deleted the IAM user account created in Level-2, Refer to the Write-up and Create another IAM account + Access Keys Credentials.

READ MORE: Managing access keys for IAM users

Type the command : aws configure --profile flawS3_l3

Confirm profile is created using the command cat ~/ .aws/credentials

Listing the content in the Level-3 S3 bucket. Using the command aws s3 ls s3://level3-9afd. . . .flaws.cloud -- profile "Your-created profile name"

💡 From the above S3 content listed in the bucket, our goal is to find secret files in the ./git file

Download the entire S3 bucket locally

Let's download the entire s3 bucket locally to our computer.

• Firstly, before using the above command, let's create a Directory or folder where the downloaded S3 content will be located.

  • Navigate to the Linux terminal and type the following command:

    → cd Desktop (change location to Desktop)

    → mkdir <Any_name_of_your_choice> (create a directory on the desktop)

• On your terminal type:

aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud ~/Desktop/S3Flaws_gitfile/ --profile flawS3_l3

NB: the command syn downloads the file to the destination /Desktop/S3 . . .

• Once done, navigate to the Directory or Folder where the S3 files are downloaded.

Type the command: ls → cd <name of directory> → ls

Now, let's use the git log command to view the commit history of a Git repository.

What is the git log command ? The git log command is Git's basic tool for exploring a repository's history. it allows tracking development progress and understand the timeline of commits.

READ MORE on Git-log

• In your present working directory (The folder where you downloaded the .git files), Type the command git log

Note that the comment “Oops, accidentally added something I shouldn't have”

There are two commit in the repository and you will see the date, time, and Autor timeline on the S3 project

NB: From the above image, the lengthy scrambled alphanumeric text are the commit_hash, which we need to look into RIGHT !! WHY !!

Looking into a specific commit hash allows us to examine the exact state of the repository at that point in time, providing valuable information about the changes made, who made them, and when they were made.

We will use git checkout to view the details of each commit_hash

• Copy the first commit hash value and type the command: git checkout <commit hash value>

  

  

  As shown in the above image, there is nothing interesting we can work with. Now try for the second commit_hash

  

From the result, as shown above, let's do a breakdown of each line:

1. M index.html: This line indicates that the file index.html has been modified in the working directory.

2. The previous HEAD position was b64c8dc Oops, accidentally added something I shouldn't have: This line indicates that the previous commit that was checked out (referred to as HEAD) had a commit hash of b64c8dc. The message "Oops, accidentally added something I shouldn't have" suggests that there was a mistake in the previous commit.

3. HEAD is now at f52ec03 first commit: This line indicates that the HEAD has been updated to the commit with the hash f52ec03b227ea6094b04e43f475fb0126edb5a61. The message "first commit" suggests that this is the initial commit in the repository.

In summary, the command we executed switched to a different commit in the Git history.

• Now on your terminal type: ls in your present working directory

  

  VS

  

You will notice that “access_keys.txt” wasn’t listed in the content that we download initially. (check previous steps)

• Now, let's view the content of the “access_keys.txt” file. by typing: cat “access_keys.txt”

  

Yooy 🎊. . . We have access to an entity access credentials (either a user, group, or role)

access_key: AKIAJ366LIPB4IJKT7SA

secret_access_key: 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

Discovered Access Keys

• Now let's create a profile on AWS CLI and log in with the discovered access credentials

use the command and supply the necessary details as shown below

⇒ aws configure - - profile <any_name_of_your_choice>

• Once done, let's list the S3 bucket of the account to see if we can get anything.

Use the command: aws --profile <profile_name_created_by_you> s3 ls

Lesson learned

People often leak AWS keys and then try to cover up their mistakes without revoking the keys. You should always revoke any AWS keys (or any secrets) that could have been leaked or misplaced. Roll out your secrets early and often.

Key Note about S3 bucket

An interesting issue at this level is that it is not possible to restrict the ability to list only specific buckets in AWS. If you grant an employee the ability to list some buckets, they will be able to list all buckets in the account. This means that the key used to discover one bucket can also see all other buckets in the account, although the key cannot access the contents of the buckets. Additionally, it's important to note that bucket names in AWS have a global namespace, which means they must be unique across all customers. This implies that if you create a bucket with a sensitive or confidential name, there is still a possibility that someone could discover its existence.

Avoiding this mistake

To avoid potential security breaches, it is crucial to promptly take action if you suspect that your secrets have been compromised, made public, or mishandled. The recommended approach is to regularly roll your secrets, which involves revoking the existing keys or credentials associated with your AWS account and generating new ones. By rolling out secrets early and frequently, you can minimize the impact of any potential security risks and ensure the ongoing protection of your sensitive information.

READ MORE ON: Best practices for managing AWS access keys

NB: If you must create access keys for programmatic access to AWS, create them for IAM users, granting the users only the permissions they require.

How to deactivate an IAM User Access keys

• Navigate to IAM User Page and click on the security credentials Tab

  

• Scroll down to Access Key and Deactivate then Delete if you want to

Also, Delete your IAM User account to prevent Aws billing.

Level 4 📍🕵️‍♂️ Almost There!!