Cloud penetration testing is a critical process that assists in identifying possible security vulnerabilities in cloud-based applications and infrastructure.
In this blog article, we will discuss the ultimate guide for cloud penetration testing. We will cover the basics of cloud penetration testing, common methodologies, tools, and best practices to help protect your cloud-based systems from cyber threats. We will also share some open-source tools that help you in cloud pentesting.
Let’s start together!
1. What is Cloud Penetration Testing?
Cloud computing is the delivery of IT resources over the internet using the pay-as-you-go principle. Instead of buying, owning, and maintaining physical data centers and servers, we can access a variety of technology services, including computing power, storage, and databases. Many popular cloud computing providers, such as AWS, Google, Microsoft Azure, and Oracle, are used daily for workloads.
As the popularity of cloud services increases, attackers are focusing on cloud vulnerabilities. They are using sustained attacks against managed cloud service providers and their customers. This is why it is essential for companies using cloud technologies to ensure their systems are secure.
One way to accomplish this is through cloud penetration testing. Cloud penetration testing is an attack simulation used to identify vulnerabilities that can be exploited or misconfigurations in a cloud-based system. By performing cloud penetration testing, companies can learn about the strengths and weaknesses of their cloud systems to improve their overall security posture. This can help companies avoid costly data breaches and protect their sensitive information.
2. What are the Cloud Penetration Testing Benefits?
There are lots of cloud penetration testing benefits for our cloud-based environment. We’ve summarized them in the following figure:
3. Example Cloud Pentesting Tools
CloudBrute: AWS S3 is a cloud storage service. CloudBrute is an open-source tool that can help you enumerate the customer’s AWS S3 buckets. The tool is modular and customizable and is generally preferred because it is relatively fast. Features of the tool are:
- Cloud detection (IPINFO API and Source Code)
- Unauthenticated Black-box testing
- Ability to work cross-platform
- User-Agent Randomization
- Proxy Randomization
The tool supports all major cloud providers. The list of cloud providers supported by CloudBrute are:
- Microsoft: Storage, Apps
- Amazon: Storage, Apps
- Google: Storage, Apps
- DigitalOcean: Storage
- Vultr: Storage
- Linode: Storage
- Alibaba: Storage
CloudSplaining: Cloudsplaining is an open-source tool that helps you to find out the violation of least privilege on AWS IAM policies by scanning all the policies in the AWS account and giving you an HTML report.
It can scan all the policies in an AWS account or a single policy file. It helps prioritize the remediation process by flagging IAM policies that present risks. Cloudsplainig also can identify the IAM roles that can be assumed by AWS. Flagging these roles is particularly useful to penetration testers or attackers under various scenarios.
Enumerate-iam: If AWS credentials of customers are ever stolen or captured, it would take a lot of time to find which services those credentials are authorized for. To ease up this process, an open-source tool called enumerate-iam can be used. It tries to brute force all API calls allowed by the IAM policy, in a non-destructive manner. Another good part of this tool is that it can be easily integrated with other tools if needed.
4. Challenges of the Cloud Pentesting
- No standard approach: There is no classic or standard way of performing cloud penetration testing. The approach taken depends on the client’s requirements.
- Varied technologies, varied approaches: Cloud penetration testing is often performed on different cloud providers and different technologies depending on the client’s needs. Therefore, it is important to identify which cloud services are used, determine possible security misconfigurations, and identify vulnerabilities related to these services. Knowing all cloud services can be a challenge for penetration testers.
- Various pentesting policies: Every cloud provider has its own policy for penetration testing. As a result, the cloud penetration testing process may vary depending on the provider. For some services, we may need to notify the providers before performing penetration testing.
5. Step-by-Step Cloud Penetration Testing
Step 1: Understand the policies of the cloud provider
Every cloud provider has a pentesting policy that includes permitted and prohibited services and activities to test. Before we start, we need to be sure which cloud services are used in the customer’s environment, and which services can be tested by cloud pentesters.
For more information, check out the Microsoft Azure cloud pentest approach.
Step 2: Create a cloud pentesting plan
When we start cloud penetration testing, we need to check a couple of things:
- Talking with the customer: The first thing we want to do is to communicate with the customer to determine the start and end dates of the pentest. We should ask for a preview of the cloud platform, and gain information on topics such as which URLs will be tested, what is the cloud architecture of this platform, and its functions.
- Check the customer’s system: After getting the information, pentesters need time to analyze the system. Gain more information about the system; check the potential access points for any data to send or receive, check the source code, software versions, or if any leaked keys exist. The more data we gather, the more easily we identify the flaws.
Step 3: Select your cloud pentesting tools
Cloud pentesting tools should simulate actual attacks. Hackers often use automated processes to find vulnerabilities, such as repeatedly guessing passwords or searching for APIs that provide direct access to data. To effectively test for these types of scenarios, we need to simulate them using our cloud pentesting tools. If our current tools cannot meet our requirements, we can write our own systems, tools, or scripts for cloud pentesting.
Step 4: Analyze the responses
Without analyzing the findings and responses, cloud pentesting would be meaningless. After using the automated tools and performing manual tests, we need to analyze the responses. All responses should be documented. We should decide whether these results are false positives or expected cloud responses. If not, those findings should be reported. This step is one of those where our information and experience on the cloud are important.
Step 5: Find and eliminate vulnerabilities
This is the last step of the cloud pentesting process. After all cloud tests and checks are done, the severity and impact of vulnerabilities should be discussed and investigated with the cloud pentesting team. A final cloud vulnerability report should be prepared with recommendations and remediations.
6. Cloud Security Threats
Insecure APIs
Application programming interfaces or APIs enable companies to share their applications’ data and functions with third-party companies. API keys are used for identifying and authenticating between companies and third parties. If we don’t protect our API keys, someone can gain access to them. API services are commonly used, and insecure APIs can lead to severe data leaks. To prevent these cases, don’t embed API keys into code, and keep them in a safe place where unauthorized people can’t access them. In addition, for all our API services, there should be an authentication/authorization mechanism to prevent broken access control.
Outdated software
If our software is outdated, this may cause some major security issues like data leaks or credentials leaks. Make sure that the software in use is the latest version. One of the reasons to update these applications is to prevent getting damaged security flaws in the old versions that need to be solved. For this reason, the threat should be removed by updating your programs.
Misconfigurations on the cloud
According to the research, between February 2018 and June 2019, 90% of all Cloud-based security issues were due to misconfigurations. There is always a story in the news about a big company being subject to a data leak or disclosing a breach of privacy. While these may occur on the Cloud, the root cause is nearly always a case of human error on the company’s configuration side.
Stolen credentials
Credentials may leak in some way or can be hardcoded in the application. This may cause our credentials to be stolen. We should not share our credentials such as the access key, secret access key, or API keys in the codebase. That’s basically like giving our master key to a stranger.
Access privileges
There is a concept in the cloud called “the least privilege principle”. That means giving the user the least amount of privileges to do their job. If we give them excessive privilege and the account gets hacked or stolen, this may lead to serious problems. To prevent them, we should always give the least amount of privilege to the users. For more information, check out the Google Cloud Platform approach for the least privilege.
Also see: What is Cloud Security?
7. Cloud Shared Responsibility Model for Pentesting
Cloud service providers have to stick to a shared security responsibility model. We are responsible for security in the cloud, such as security for our operating environment, including our applications, servers, and user controls. The cloud service provider is responsible for the security of the cloud.
In the AWS shared responsibility model, AWS takes responsibility for protecting the infrastructure that runs all the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
8. Cloud Penetration Testing Authorization and Policies
We should always check the cloud providers’ service policies. The tables below visualize AWS’s policy on what we can and can’t test:
AWS allows penetration testing on:
- Amazon EC2 instances, NAT Gateways, and Elastic Load Balancers
- Amazon RDS
- Amazon CloudFront
- Amazon Aurora
- Amazon API Gateways
- AWS Lambda and Lambda Edge functions
- Amazon Lightsail resources
- Amazon Elastic Beanstalk environments
Users can perform penetration testing on these services without any issues. The activities that AWS does not allow are visualized in the table below:
Users cannot perform the following tests:
- DNS zone walking via Amazon Route 53 Hosted Zones
- Kinds of Denial of Service (DoS) attacks
- Port flooding
- Protocol flooding
- Request flooding (e.g. login request flooding, API request flooding)
Some of the prohibited activities can be performed after notifying AWS. For example, if a customer likes to perform a Network Stress Test or a DDoS simulation test, they should review AWS’s policy on Stress Test and DDoS Simulation Testing. After AWS authorizes the tests, they can be performed.
You may be interested in this article, too: How to Securely Share AWS S3 Files
Conclusion
In conclusion, we have explored the world of cloud penetration testing, a crucial aspect of ensuring the security of your cloud infrastructure. From understanding the cloud shared responsibility model to introducing the latest tools and techniques, we have covered a lot of ground.
We hope that you found this information insightful and valuable, and we look forward to joining you on your journey toward a more secure and resilient cloud environment.
Check out our Cloud Security and Penetration Testing services to stay secure!