Building a cloud-based business or migrating information assets to the cloud makes a lot of sense in terms of operational efficiency as well as cost-effectiveness. Most of the third-party applications or plugins you are using may also be operating off of the cloud. Cloud providers are bound by certain security regulations and have some policies in place to protect your data privacy, but it isn’t enough by any stretch of the imagination. Hence, we are going to talk about Cloud Penetration Testing.
What is Cloud Penetration Testing?
Cloud Penetration Testing is the process of detecting and exploiting security vulnerabilities in your cloud infrastructure by simulating a controlled cyber attack. Cloud pentest is performed under strict guidelines from the cloud service providers like AWS, and GCP.
How Does Cloud Penetration Testing Differ from Penetration Testing?
In layman’s terms, penetration testing is the process of performing offensive security tests on a system, service, or network to find security weaknesses in it. So, when it comes to cloud penetration testing, it is just performing a simulated attack on your cloud services to test their security.
What is the Purpose of Cloud Penetration Testing?
The prime purpose of this is to find security issues in your cloud service before hackers do. Different types of manual methods and cloud penetration testing tools may be used depending on the type of your cloud service and the provider. However, since you do not own the cloud infrastructure/platform/software as an entity but rather as a service, there are several legal and technical challenges to performing cloud penetration tests. We shall read about them later in this article.
Most Common Cloud Vulnerabilities
There are quite a few vulnerabilities that can lead to a compromised cloud account. Mentioning each one is beyond the scope of this article so, the most prominent ones are mentioned below:
1. Insecure APIs
APIs are widely used in cloud services to share information across various applications. However, insecure APIs can also lead to a large-scale data leak as was seen in the case of Venmo, Airtel, etc. Sometimes using HTTP methods like PUT, POST, DELETE in APIs improperly can allow hackers to upload malware on your server or delete data. Improper access control and lack of input sanitization are also the main causes of APIs getting compromised which can be uncovered during cloud penetration testing.
2. Server misconfigurations
Cloud service misconfigurations are the most common cloud vulnerability today (misconfigured S3 Buckets, in particular ). The most famous case was that of the Capital One data leak which led to the compromise of the data of roughly 100 million Americans and 6 million Canadians. The most common cloud server misconfigurations are improper permissions, not encrypting the data and differentiation between private and public data.
3. Weak credentials
Using common or weak passwords can make your cloud accounts vulnerable to brute force attacks. The attacker can use automated tools to make guesses thereby making way into your account using those credentials. The results could be disastrous leading to a complete account takeover. Since people tend to reuse passwords and use easily rememberable passwords, these attacks are fairly common. This fact can be verified during cloud penetration testing.
4. Outdated software
Outdated software contains critical security vulnerabilities that can compromise your cloud services. Most of the software vendors do not use a streamlined update procedure or the users disable automatic updates themselves. This makes the cloud services outdated which hackers identify using automated scanners. As a result, cloud services using outdated software are compromised by a large number.
5. Insecure coding practices
Most businesses try to get their cloud infrastructure built for as cheaply as possible. So, due to poor coding practices, such software often contains bugs like SQLi, XSS, CSRF. The ones which are most common among them are labeled as OWASP top 10. It is these vulnerabilities that are the root cause for the majority of cloud web services being compromised.
|Type of Cloud Service||Security Responsibilities of Cloud Providers||Security Responsibilities of Clients|
|Infrastructure as a Service (IaaS)||Virtualization. Network, Infrastructure, Physical||User Access, Data, Application, Operating System|
|Platform as as Service (PaaS)||Operating System, Virtualization, Network, Infrastructure, Physical||User Access, Data, Application|
|Software as a Service (SaaS)||Application, Operating System, Virtualization, Network, Infrastructure, Physical||User Access, Data|
Based on the Service Level Agreement (SLA) between the client and the cloud service provider certain aspects of cloud security are controlled and handled by the cloud provider and the client is responsible for the others. For instance, the cloud provider will not be held responsible for security errors related to user identity.
Similarly, the client is not responsible for the physical security of the data centers managed by the cloud providers. This shared model of cloud security is termed ‘security in the cloud’ and not ‘security of the cloud’. The scope of the cloud pentest is dictated by this shared model.
What are the Challenges in cloud penetrating testing?
1. Lack of transparency
In the case of some of the not-so-well-known cloud services, the data centers are managed by third parties. As a result, the user may be unaware of where the data is stored and what hardware or software configuration is being used. This lack of transparency exposes the user data to security risks on a cloud service. For instance, the cloud service provider may be hoarding sensitive data without the knowledge of the user. Moreover, popular CSPs like AWS, Azure, GCP, etc are known to conduct in-house security audits.
However, a lack of transparency in these services means that these resources cannot be audited by the security auditor of your choice. As a result, you may be unable to respond if those underlying resources are hacked.
2. Resource sharing
It is a well-known fact that cloud services share resources across multiple accounts. However, this resource sharing can prove to be challenging during cloud penetration testing. Sometimes the service providers do not take adequate steps for segmentation of all the users.
In those cases, if your business needs to be PCI DSS compliant, the standard says that all the other accounts sharing the resource and the cloud service provider should be PCI DSS compliant too. Such complex scenarios are present because there are multiple ways to implement the cloud infrastructure. This complexity hinders the process of cloud penetration testing.
3. Policy restrictions
Each cloud service provider has its own policy regarding conducting cloud penetration testing. This defines the endpoints and types of tests that can be conducted. Also, some require you to submit an advance notice before conducting the tests. This disparity in policies poses a significant challenge and limits the scope of conducting cloud penetration testing. Now let us take a brief overview of the cloud pentesting policy of the 3 most popular cloud service providers:
|Cloud Provider||Prohibited Attacks|
|AWS||Denial of Service (DOS) and Distributed Denial of Service Attacks (DDOS), DNS zone walking, Port, Protocol, or Request flooding attacks|
|Azure||DOS and DDoS attacks, intensive network fuzzing attacks, Phishing or any other social engineering attacks,|
|GCP||Piracy or any other illegal activity, Phishing, Distributing trojans, ransomware, Interfering|
There are 8 permitted services for Amazon web services on which cloud pen testing can be performed without giving prior notice. Those are mentioned in the Permitted Services of the policy. Also, while penetration testing, the following attacks are not permitted:
- Denial of Service (DOS) and Distributed Denial of Service Attacks (DDOS).
- DNS zone walking.
- Port, Protocol, or Request flooding attacks.
However, if you wish to perform a network stress test, there is a separate policy for that. What constitutes DOS attacks and what does not is later explained in more detail at the end of this article.
Azure allows cloud pentesting on eight Microsoft products which are mentioned in its policy. Anything beyond that is out of scope. Moreover, the following types of tests are prohibited:
- Conducting cloud pen testing on other azure customers or data other than yours.
- DOS and DDoS attacks or tests create a huge amount of traffic.
- Performing intensive network fuzzing attacks on Azure VMs
- Phishing or any other social engineering attacks against Microsoft’s employees.
- Violating Acceptable Use Policy.
For Google Cloud Platform, there is no special cloud penetration testing policy as such, you just need to follow their Acceptable Use Policy and Terms of Service. Moreover, there is no need to inform Google before conducting tests. However, the Acceptable Use Policy mentions a few things that you should not perform which are as follows:
- Piracy or any other illegal activity.
- Distributing trojans, ransomware, etc during the tests.
- Violating the rights of other GCP users or conducting penetration tests on them.
- Violating or trying to circumvent terms of service.
- Interfering with the equipment supporting GCP.
4. Other factors
Due to the sheer scale of cloud services, one machine can host multiple VMs, this adds to the scale of cloud penetration testing. Also, the scope for such tests can vary from user software (CMS, Database, etc.) to service provider software (VM Software, etc). Both these factors combined further add to the complexity of cloud penetration testing. When encryption is added to this list, it can further worsen the situation for auditors as the company being audited may not be willing to share encryption keys.
Performing Step-by-Step Cloud Penetration Testing
Step 1: Understand the cloud service provider’s policies
Before beginning with the tests, it is important to formulate a testing plan based on the policy of the cloud service provider. This is because each CSP has its own policy regarding:
- Types of cloud pentest that can be performed.
- Endpoints that can be tested.
- Permissions to perform the tests.
- Scope of the tests.
So, if your testing plan is not in accordance with that, the cloud provider can penalize you. For example, if you try to test your account for DDOS and the CSP does not allow that, there are automatic systems in place that can detect that. Thereafter, the CSP can lock your account for some time and you will have a lot of explanation to do before you get your account back. The crux of the get matter is to get familiar with your CSP policy.
Also, read Penetration Testing Services
Step 2: Create a cloud penetration testing plan
Now comes the second part, which is to create a plan for performing cloud penetration testing. There is no set formula for creating a plan as it varies from auditor to auditor. But, some of the steps you can take to formulate a plan are:
- Map out all the endpoints like user interface, APIs, subnetworks, etc for which testing is to be done.
- Decide which endpoints to exclude based on policy restrictions, user permissions, etc.
- Decide the route for performing the pentest i.e. from application or database.
- Figure out how well the application server and VMs can take the load of the tests that you wish to perform.
- Find out the laws that need to be followed while performing tests.
- Figure out which tools to be used and what types of tests will be performed on which endpoints (Automated or Manual).
- Finally, get the approval for your plan from the client and inform them when you wish to begin.
Step 3: Execute the plan
Now, it is time to execute your plan. Run the tools as you wished and observe the responses for vulnerability. Although some tools like Nmap, Sqlmap, OpenVAS, etc are well-known, there are some CSP-specific tools too which you can add to your plan. Some of the tools that you can include in your plan for cloud penetration testing are as follows:
- AWS Inspector: A customized security solution for AWS. It can be used as a basic minimum or preliminary testing tool.
- S3Scanner: An open-source tool to scan S3 buckets for misconfigurations and dump their data.
- MicroBurst: A collection of PowerShell scripts to scan Azure services for security issues. So, to use them you need to have PowerShell installed which is present by default on Windows OS.
- Azucar: This is another popular Azure scanning tool built using PowerShell just like MicroBurst.
- Cloudsploit: This is a popular open-source tool that can scan multiple types of cloud service providers like Azure, AWS, Google Cloud Platform, OCI, etc.
Step 4: Detect and fix vulnerabilities
Some of the automated tools may generate false positives. So, it is necessary to verify that each one is exploitable before adding it to the report. Repeat this process for each layer (network, database, application, etc) that you are testing.
Next comes the most underrated activity of cloud penetration testing, the report generation. It is important for the cloud penetration testers to present the vulnerabilities to the client in an understandable manner. The presentation is the difference between the client taking vulnerabilities seriously or not seriously. So, make sure the reports are well organized and categorized based on the type and level of threat.
After the vulnerabilities have been found, get in touch with your developers to patch them. Else what was the use of cloud penetration testing in the first place if you ignore the bugs? Some of the vulnerabilities can be fixed while making minor changes to the code while some may require a significant overhaul. However, if your tests were unable to detect any vulnerability, maybe you need to change your plan and perform more elaborate security tests.
Cloud Penetration Testing with Astra’s Pentest
Astra’s Pentest is a complete penetration testing service for mobile and web applications as well as cloud infrastructure. It combines a vulnerability scanner with manual pentest to offer a well-rounded picture of the security posture of your cloud-hosted application.
With3000+ tests, CI/CD integration, zero false positives, and collaborative remediation, Astra’s pentest suite can be a one-stop solution for your cloud pentest needs.