The demand for cloud security professionals continues to increase as the number of cloud-related threats and incidents rises significantly every year. To manage the risks involved when learning cloud penetration testing and ethical hacking, security engineers seeking to advance their careers would benefit from having a solid understanding of how to set up penetration testing environments in the cloud.
In this introductory chapter, we will quickly go through the benefits of setting up penetration testing labs in the cloud. We will explore how modern cloud applications are designed, developed, and deployed as this will be essential when we build penetration testing labs in the succeeding chapters. In the final section of this chapter, we’ll delve deeper into several relevant factors to consider when designing and building vulnerable cloud infrastructures.
That said, we will cover the following topics:
With these in mind, let’s get started!
At some point in their careers, security professionals may build penetration testing labs where they can practice their skills safely in an isolated environment. At this point, you might be asking yourself: What’s inside a penetration testing lab environment?
Figure 1.1 – Penetration testing lab example
In Figure 1.1, we can see that a penetration testing lab environment is simply a controlled environment that hosts several vulnerable-by-design applications and services. These applications have known vulnerabilities and misconfigurations that can be exploited using the right set of tools and techniques. These vulnerabilities are incorporated to provide a realistic environment for penetration testers to practice and simulate real-world attack scenarios. In addition to this, security researchers and penetration testers can dive deeper into various attack vectors, explore new techniques for exploitation, and develop countermeasures.
Before going over the benefits of setting up our penetration testing labs in the cloud, let’s discuss why having a penetration testing lab environment is a great idea. Here are some of the reasons why it is recommended to have a penetration testing lab environment:
Now that we have discussed why it is a good idea to have a penetration testing lab environment, it’s about time we talk about where we can host these hacking labs. In the past, most security practitioners set up their lab environments primarily on their local machines (for example, their personal computer or laptop). They invested in dedicated hardware where they can run virtual lab environments using VirtualBox or other alternative virtualization software:
Figure 1.2 – Running penetration testing lab environments on your local machine
In Figure 1.2, we can see that a common practice in home lab environments involves creating snapshots (used to capture the current state) before tests are performed since certain steps in the penetration testing process may affect the configuration and stability of the target machine. These snapshots can then be used to revert and restore the setup to its original state so that security professionals and researchers can perform a series of tests and experiments without having to worry about the side effects of the previous tests.
Note
In the past, one of the common targets that was set up in penetration testing lab environments was an intentionally vulnerable Linux image called Metasploitable. It contained various vulnerable running services mapped to several open ports waiting to be scanned and attacked. Practitioners would then set up an attacker machine using BackTrack Linux (now known as Kali Linux) that had been configured with a variety of tools, such as Nmap and Metasploit, to attack the target machine.
Of course, setting up a vulnerable-by-design lab environment on our local machines has its own set of challenges and limitations. These may include one or more of the following:
Note
In some cases, we may also encounter licensing issues that prevent us from using certain virtual machines, operating systems, and applications in our hacking lab environment.
To solve one or more of the challenges mentioned, it is a good idea to consider setting up our penetration testing labs in the cloud. Here are some of the advantages when setting up cloud penetration testing labs:
Note
In addition to these, learning penetration testing can be faster in the cloud. For one thing, downloading large files and setting up vulnerable VMs can be significantly faster in the cloud. In addition to this, rebuilding cloud environments is generally easier since there are various options to recreate and rebuild these lab environments.
At this point, we should know why it is a great idea to build our penetration testing lab environments in the cloud! In the next section, we’ll quickly discuss how cloud computing has influenced and shaped the modern cybersecurity landscape.
In the past, companies had to host their applications primarily in their data centers. Due to the operational overhead of managing their own data centers, most businesses have considered migrating their data and their workloads to the cloud. Some organizations have moved all their applications and data to the cloud, while others use a hybrid cloud architecture to host their applications in both on-premises data centers and in the cloud. Cloud computing has allowed companies to do the following:
With more companies storing their data in the cloud, there has been a significant increase in cloud attacks in the last couple of years. The attack surface has changed due to the rise of cloud computing, and along with it, the types of attacks have changed. Hackers can take advantage of vulnerable and misconfigured cloud resources, which could end up having sensitive data stored in the cloud stolen.
What do we mean by attack surface?
Attack surface refers to the collective set of potential vulnerabilities within a system that can be exploited by attackers. It encompasses various elements, including network interfaces, APIs, user access points, operating systems, and deployed cloud resources. Understanding and managing the attack surface is crucial for assessing and mitigating security risks in the cloud as it allows organizations to identify and address potential weak points that could be targeted by malicious actors.
With this in mind, here is a quick list of relevant cyberattacks on cloud-based data and applications:
Over the years, the quantity and quality of tools focusing on cloud security have increased as cloud security threats have evolved and become more widespread. More security tools and utilities became available as the number of disclosed vulnerabilities increased every year. These tools ranged from simple scripts to sophisticated frameworks and modules that can be configured to suit the needs of an attacker. Security professionals have seen tools and products evolve over time as well. In the past, cloud security products needed to be installed and set up by the internal teams of companies. These past few years, more managed cloud-based tools and services became available, most of which can be used immediately with minimal configuration. Here are some of the more recent security solutions that have become available for cloud security:
At this point, we should have a better understanding of how cloud computing has shaped and influenced the cybersecurity landscape. In the next section, we will dive deeper into how modern applications are designed, developed, and deployed in the cloud.
One of the primary objectives when building our penetration testing labs is to prepare a vulnerable-by-design environment that mimics real cloud environments. That said, we must have a good understanding of how modern cloud applications look as this will equip us with the knowledge required to build the right environment for our needs.
Years ago, most applications that were deployed in the cloud were designed and developed as monolithic applications. This means that the frontend, backend, and database layers of the application’s architecture were built together as a single logical unit. Most of the time, multiple developers would work on a single code repository for a project. In addition to this, the entire application, along with the database, would most likely be deployed together as a single unit inside the same server or virtual machine (similar to what’s shown in the simplified diagram in Figure 1.3):
Figure 1.3 – Deployment of monolithic applications (simplified)
From a security standpoint, an attacker that’s able to get root access to the virtual machine hosting the application server would most likely be able to access and steal sensitive information stored in the database running on the same machine.
What do we mean by root access?
Root access refers to having complete administrative privileges and unrestricted control over a computer system or virtual machine. It grants the user the highest level of access and authority, enabling them to modify system files, install or uninstall software, and perform actions that are typically restricted to other users. In the context of security, if an attacker obtains root access to a virtual machine hosting an application server, it implies they have gained full control of the system. This can potentially lead to unauthorized access to sensitive data stored in databases residing on the same machine.
Of course, there are modern applications that are still designed and architected as monolithic applications due to the benefits of having this type of architecture. However, as we will see shortly, more teams around the world are starting with a distributed microservice architecture instead of a monolithic setup. One of the notable downsides of having a monolithic architecture is that development teams may have problems scaling specific layers of the application once more users start to use the system. Once the application starts to slow down, teams may end up vertically scaling the virtual machine where the application is running. With vertical scaling, the resources of a single server, such as CPU and RAM, are increased by upgrading its hardware or adding more powerful machines. This approach allows the server to handle higher workloads and demands by enhancing its capacity. In contrast, horizontal scaling involves adding more servers to distribute the load, allowing each server to handle a portion of the overall traffic. Given that vertical scaling is generally more expensive than horizontal scaling long-term, cloud architects recommend having a distributed multi-tier setup instead since horizontal scaling involves scaling only the infrastructure resources hosting the components of the application that require scaling.
For instance, in a distributed e-commerce application, instead of vertically scaling a single monolithic server to handle increased user traffic, the system can be designed with separate tiers for the web servers, application servers, and databases. By separating different tiers, it becomes possible to independently scale each tier based on its specific resource demands. For example, while the application server layer can scale horizontally to handle increased user traffic, the database layer can scale vertically to accommodate growing data storage requirements. This way, when traffic surges, the infrastructure can horizontally scale by adding more web servers to handle the increased load, resulting in a more cost-effective and scalable solution:
Figure 1.4 – Autoscaling setup
In addition to this, a distributed multi-tier setup can easily support the autoscaling of resources due to its inherent architectural design. This flexibility allows the system to automatically adjust resource allocation without manual intervention, ensuring optimal performance and resource utilization. If the traffic that’s received by the application is spiky or unpredictable, a cloud architect may consider having an autoscaling setup for specific layers of the application to ensure that the infrastructure resources hosting the application are not underutilized.
Note
Security professionals must take into account that the downsizing operation of an autoscaling setup may delete resources automatically once the traffic received by the application goes down. It is important to note that misconfigured or incomplete autoscaling implementations generally do not have the recommended log rotation setup configured properly in production environments. This would make investigation harder since the logs stored in the compromised infrastructure resources or servers might be deleted during the automated downsizing operation.
At this point, we should have a good idea of how the initial cloud applications were designed and deployed. Fast forwarding to the present, here’s what a modern application may look like:
Figure 1.5 – What a modern cloud architecture looks like
Wow! That escalated quickly! In Figure 1.5, we can see that in addition to what was discussed already, modern application architectures may have one or more of the following as well:
There has also been an observable shift in the use of more managed services globally as more companies migrate their workloads to the cloud. The managed services provided by cloud platforms have gradually replaced specific components in the system that were originally maintained manually by a company’s internal system administration team. For instance, companies are leveraging managed services such as Google Cloud Pub/Sub instead of setting up their own messaging systems such as RabbitMQ. This approach allows organizations to focus their valuable time and resources on other critical business requirements.
With managed services, a major portion of the maintenance work is handled and automated by the cloud platform instead of a company’s internal team members. Here are some of the advantages when using managed services:
Note
Security professionals need to have a good idea of what’s possible and what’s not when managed services are used. For example, we are not able to access the underlying operating system of certain managed services as these were designed and implemented that way. A good example would be the managed NAT Gateway of the AWS cloud platform. In addition to this, security professionals need to be aware of other possible mechanisms available when using managed services. For example, in Amazon Aurora (a relational database management system built for the cloud), we also have the option to do passwordless authentication using an Identity and Access Management (IAM) role. This means that if an attacker manages to exfiltrate AWS credentials with the right set of permissions, the database records can be accessed and modified even without the database’s username and password.
There has been a significant increase in the usage of containers these last couple of years. If you are wondering what containers are, containers are simply lightweight, isolated environments that package applications and their dependencies to guarantee consistency and portability. Container images, on the other hand, act as self-contained executable packages, comprising the necessary files and configurations for running specific applications. Companies opt for containers because they offer quicker launch times and the capability to host multiple containers in one virtual machine and ensure consistent environments throughout various development stages. Initially, companies were hesitant in using Docker containers for deployment in production. However, due to the latest advances and release of production-ready tools such as Kubernetes, Docker Compose, and other similar container frameworks, more companies around the world have been using containers to host applications.
At this point, you might be wondering, What are the advantages of using containers? Here are a few reasons why companies would opt to utilize containers:
In addition to these, nowadays, more managed cloud services already provide support for the usage of custom container environments, which gives developers the flexibility they need while ensuring that minimal work is done on the maintenance end. By leveraging these managed cloud services, developers can focus on application development and innovation while offloading the burden of infrastructure maintenance and ensuring optimal performance, scalability, and security for their containerized applications.
Note
Imagine a company developing a microservices-based application. By leveraging containers, they can encapsulate each microservice within its own container, allowing for independent development, testing, and deployment. This modular approach enables teams to iterate and update specific services without impacting the entire application stack. Furthermore, containers facilitate seamless scaling as demand fluctuates. When the application experiences increased traffic, container orchestration platforms such as Kubernetes automatically spin up additional instances of the required containers, ensuring optimal performance and resource utilization. This scalability allows businesses to efficiently handle peak loads without overprovisioning infrastructure.
That said, having a solid understanding of container security is critical due to the growing popularity of containers. Containers present unique security challenges that must be addressed to protect applications and data. By implementing effective container security measures, organizations can mitigate risks (such as unauthorized access, data breaches, and container breakouts) to ensure the security of critical systems and sensitive information.
Similar to containers, there’s also been a noticeable increase in the usage of FaaS services in the past couple of years. FaaS options from major cloud platforms, including AWS Lambda Functions, Azure Functions, and Google Cloud Functions, allow developers and engineers to deploy and run custom application code inside isolated environments without having to worry about server management. Previously, developers had to handle server provisioning and configuration. However, with serverless functions, developers can focus on writing and deploying custom application code without worrying about infrastructure, resulting in a more efficient and streamlined development process. This shift enables rapid iteration, scalable deployments, and reduced operational overhead, significantly simplifying the lives of developers. Using these along with the other building blocks of event-driven architectures, developers can divide complex application code into smaller and more manageable components. To have a better understanding of how these services work, let’s quickly discuss some of the common properties of these cloud functions:
Important note
The terms FaaS and serverless computing are sometimes used interchangeably by professionals. However, they are two different concepts. FaaS primarily focuses on having a platform that speeds up the development and deployment of application code functions. On the other hand, serverless computing refers to the cloud computing execution model, which is generally characterized by the usage of event-driven architecture, managed services, along with per-usage billing. That said, it is possible to have a serverless implementation without utilizing a FaaS service (for example, a frontend-only single-page application (SPA) hosted using the static website hosting capability of a cloud storage service).
How is this relevant to cloud security and penetration testing? The design and implementation of cloud functions impact and influence the offensive and defensive security strategies of professionals. Developers and engineers need to make sure that the code that’s deployed inside cloud functions is safe from a variety of injection attacks. For one thing, creating a file and saving it inside a storage bucket with a filename that includes a malicious payload may trigger command execution once an event triggers the cloud function. In addition to this, security professionals must find alternative ways of maintaining persistence (after a successful breach) when dealing with cloud functions since the runtime environment gets created and deleted in seconds.
At this point, you should have a good idea of what modern cloud applications look like! There is a lot more we could discuss in this section, but this should do the trick for now. With everything we have learned so far, we can now proceed with diving deeper into what we should consider when designing and building penetration testing lab environments in the cloud.
In the succeeding chapters of this book, we will be designing and building multiple vulnerable-by-design labs in the cloud. After setting up each of the lab environments, we will simulate the penetration testing process to validate if the vulnerabilities present are exploitable. Before performing a penetration testing session in our cloud environments, we must be aware of the following:
In addition to these, we must be aware of the activities and actions prohibited by the cloud platforms. Here are a few examples of what’s not allowed in cloud environments:
Note that there’s a long list of prohibited actions and activities in the relevant documentation pages available online for each of the cloud platforms. You can find the relevant links to resources on the succeeding pages and the Further reading section of this chapter.
We must also notify and contact the respective support and security teams of the cloud platform when needed. This will guarantee that we will not be breaking any rules, especially if we are unsure or if it is our first-time performing penetration tests in the cloud.
Note
The best practice is to notify the cloud platform ahead of time to get authorization and approval. In some cases, an approval or notification is not required but filing a support ticket before performing penetration tests on your resources won’t hurt.
On some occasions, you might think that you no longer need to get authorization from the cloud provider since your penetration testing session will not harm other customers. However, this is not always the case as there might be actions that still require authorization from the cloud provider. Figure 1.6 shows a sample penetration testing lab environment on AWS:
Figure 1.6 – Sample penetration testing lab environment setup
This lab environment has the following components:
Performing penetration tests on an application running inside an EC2 instance requires no approval. On the other hand, performing penetration tests on your own S3 bucket in your AWS account is not allowed unless you get approval from AWS. Why? Performing penetration tests on an S3 bucket you own differs from penetration tests on an application hosted on S3. You must complete the Simulated Events Form and provide the required information to get authorization from AWS before performing penetration testing simulations on Amazon S3, along with other services not listed under Permitted Services of the Customer Service Policy for Penetration Testing information page. Make sure you check out the following links before performing penetration tests on AWS:
It is important to note that penetration testing policies and guidelines differ across cloud platforms. Here are some of the resources and links you need to check before performing penetration tests on Azure:
Here are the relevant resources and links for GCP:
Note
Note that these policies and guidelines may change in the future, so make sure you review the guidelines before doing penetration tests on applications running in a cloud environment. Make sure you reach out to the support and security teams of the cloud platforms for guidance if you have questions and need clarification.
In addition to what has been discussed already, there are other things we need to consider, particularly in terms of security and engineering:
We could add a few more to this list, but these considerations should do for now. We will discuss these security and engineering considerations in detail in the next few chapters as we build a variety of vulnerable-by-design lab environments across the different cloud platforms.
In this chapter, we started with a quick discussion on the advantages of setting up a penetration testing lab in the cloud. We took a closer look at how cloud computing has influenced and shaped the modern cybersecurity landscape. We also explored how modern cloud applications are designed, developed, and deployed. We wrapped up this chapter by diving deeper into several important considerations when designing and building vulnerable environments in the cloud.
In the next chapter, we will proceed with setting up our first vulnerable lab environment in the cloud. After setting up our penetration testing lab, we will validate whether the vulnerabilities are exploitable using various offensive security tools and techniques.
For more information on the topics covered in this chapter, feel free to check out the following resources:
Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.
If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.
Please Note: Packt eBooks are non-returnable and non-refundable.
Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:
If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:
Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.
You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.
Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.
When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.
For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.