Cloud computing is the delivery of IT resources over the Internet with the pay-as-you-go principle. We can access lots of technology services such as computing power, storage, and databases instead of buying, owning, maintaining physical data centers and servers. As we know, there are lots of popular cloud computing providers such as AWS, Google, Microsoft Azure, and Oracle that we use every day for our workloads. As the popularity of cloud services increases, attackers focus on cloud services and cloud vulnerabilities. Attackers use lots of sustained attacks against managed cloud service providers and their customers. If companies are using cloud technologies, they need to make sure it is secure. At this point, they need cloud penetration testing. Cloud penetration testing is an attack simulation performed to find vulnerabilities that can be exploited or to find any misconfigurations in a cloud-based system. With cloud penetration testing, companies learn about the strengths and weaknesses of their cloud system to improve its overall security posture. Today, we will summarize what you need to know about cloud penetration testing. We will also share some open source tools that help you in cloud pentesting. Let's start together!
There are lots of cloud penetration testing benefits for our cloud-based environment. We’ve summarized them in the following figure:
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.
- No classic way: There is no standard way of performing cloud pentesting. It all ties to the client and what they want.
- Different technology, different cases: Cloud pentesting process is often performed on different cloud providers and different technologies depending on the clients. That’s why we need to know which cloud services are used and what are possible security misconfigurations, and the vulnerabilities related to these services. Knowing all cloud services can be challenging for pentesters.
- Different pentesting policy: Every cloud provider has their own policy for pentesting. Because of that, the cloud pentesting process could change depending on the provider. For some of the services, we may have to notify the providers before pentesting.
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.
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 the 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.
Cloud pentesting tools should simulate an actual attack. Many hackers use automated processes to find vulnerabilities, such as guessing passwords repeatedly or looking for APIs that provide access directly to the data. What we should do is to try and simulate those types of procedures. If our cloud pentesting tools can’t meet our requirements for attack scenarios, we could write our own systems, tools, or scripts for cloud pentesting.
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.
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.
* Insecure APIs: Application programming interfaces or APIs enables 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 least privilege.
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, 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.
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.
In this blog post, we’ve talked about cloud penetration testing. We provided information about cloud pentest and revealed the cloud shared responsibility model for pentesting. We’ve introduced different tools that could be useful in cloud pentesting. We hope you enjoyed it!