Preparing Our First Vulnerable Cloud Lab Environment

In Chapter 1, Getting Started with Penetration Testing Labs in the Cloud, we discussed several key topics that are essential to building intentionally vulnerable lab environments in the cloud. At this point, you are probably eager to get your feet wet and very excited to start working on some hands-on exercises. The good news is that we won’t have to wait much longer since we will be working on our first penetration testing cloud lab environment in this chapter.

We will start the hands-on section of this chapter by creating an empty Amazon Simple Storage Service (S3) bucket and configuring it for static website hosting. We will then make the bucket misconfigured by modifying its access control settings accordingly. We will complete the setup by uploading a few sample files into our S3 bucket and make the setup a bit more realistic. Of course, setting up the vulnerable cloud lab environment is just the first part! The second...

Technical requirements

Before we start, we must have the following ready:

• An AWS account, which will serve as the target account that contains the vulnerable environment and resources
• A second AWS account, which will serve as the attacker’s account

Feel free to create these AWS accounts by going to https://aws.amazon.com/free/. You may proceed with the next steps once these accounts are ready.

Note

This chapter primarily focuses on building a sample vulnerable lab environment on AWS. Of course, we need to have our Microsoft Azure and Google Cloud Platform (GCP) accounts ready once we reach the hands-on portion of the succeeding chapters of this book. In the meantime, setting up two AWS accounts should do the trick for now.

Designing our first cloud penetration testing lab environment

In Chapter 1, Getting Started with Penetration Testing Labs in the Cloud, we discussed how modern cloud applications are designed, developed, and deployed. We took a closer look at how distributed multi-tier architectures and horizontal scaling strategies make it possible to independently scale specific tiers to handle increased user traffic:

Figure 2.1 – Generic multi-tiered architecture diagram from Chapter 1

Here, we have designed the system to have separate tiers for the web servers, application servers, and databases. Given that this is one of the common cloud architecture implementations, you might be wondering, how would this look like when implemented on a cloud platform such as AWS? The answer to this question is simple! It would look more or less the same when implemented on AWS! For one thing, the resources in Figure 2.1 would simply have their own corresponding set of resources...

Preparing our first vulnerable environment

As discussed in the previous section, our first vulnerable environment will be composed of a single misconfigured Amazon S3 bucket containing a few sample files. There are a variety of ways to create an empty S3 bucket. In this chapter, we’ll use the AWS Management Console to create our bucket.

This section is composed of four subparts:

• Creating an empty S3 bucket
• Configuring the S3 bucket to host a static website
• Updating the S3 bucket configuration settings
• Uploading files to the S3 bucket

Important note

Since we’ll be preparing an intentionally vulnerable S3 bucket, make sure you don’t use this S3 bucket to store production data (or files that contain sensitive information).

Creating an empty S3 bucket

We will start by creating an empty S3 bucket. Make sure that you are logged in using the “target account” (the first AWS account).

Important note

You may also...

Testing and hacking our first vulnerable environment

In this section, we’ll try to emulate how an attacker might behave when trying to hack our vulnerable S3 bucket. Attackers might use a specialized set of automated tools, but we should do just fine without those tools in this chapter.

Inspecting and verifying the S3 bucket’s security

We will start by verifying the security configuration of the S3 bucket we created using a series of manual checks.

Important note

It is unethical and illegal to attack cloud resources owned by another user or company. Before we start, make sure you read the Examining the considerations when building penetration testing lab environments in the cloud section of Chapter 1, Getting Started with Penetration Testing Labs in the Cloud, since we will be simulating the attack process to validate whether the misconfigurations and vulnerabilities and present are exploitable.

With that out of the way, we can proceed with testing and...

Cleaning up

Cleaning up the cloud resources we created or deployed is a crucial step when working with vulnerable cloud applications and environments. If we don’t clean up the resources we created right away, we might end up having our resources attacked by malicious users. That said, let’s proceed with deleting the resources we created in this chapter:

1. Let’s start by logging in to the AWS Management Console using the account we used to create the S3 bucket. Remember that we have two accounts – the “target” AWS account and the “attacker” AWS account. We’ll proceed with signing in to the “target” AWS account as we used that account to create the S3 bucket.
2. Type shell in the search bar and select CloudShell from the list of results, as shown in Figure 2.33:
   

   Figure 2.33 – Navigating to the CloudShell console

   Click the Close button when you see the Welcome to AWS...

Summary

In this chapter, we designed and prepared our first intentionally vulnerable lab environment in the cloud. We started by creating an empty S3 bucket using the AWS Management Console. After that, we configured the bucket for static website hosting. We also modified the access control settings of the S3 bucket and allowed other authenticated AWS users to list and retrieve objects from our bucket. To complete the setup, we uploaded sample files to our S3 bucket.

We proceeded by testing our setup by inspecting and verifying the S3 bucket’s security configuration using a series of steps, which included several terminal commands. After confirming that we could download files from the S3 bucket using a second AWS account (not used to create the bucket), we proceeded with downloading and inspecting all the files stored in the bucket. Finally, we wrapped things up by cleaning up and deleting the resources we created in this chapter.

In the next chapter, we will focus on...

Further reading

For more information on the topics covered in this chapter, feel free to check out the following resources:

• IAM Policies and Bucket Policies and ACLs (https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/)
• S3 – Managing access with ACLs (https://docs.aws.amazon.com/AmazonS3/latest/userguide/acls.html)
• Heads-Up: Amazon S3 Security Changes Are Coming in April of 2023 (https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/)
• Controlling ownership of objects and disabling ACLs for your bucket (https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)
• Default settings for new S3 buckets FAQ (https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-faq.html)