A Complete Guide on Cloud Penetration Testing

Today, using various cloud-based services is the preferred choice for businesses due to its low initial cost, scalability, and speed. However, security should be of utmost concern while using cloud services as the saying goes, “it’s not the cloud it’s just someone else’s computer”. There have been numerous instances of massive data breaches due to misconfigured cloud services. To protect your business from such embarrassment, cloud penetration testing should be performed routinely. However, since cloud services have their own policies regarding penetration tests, the situation can become complex in some cases.

The book, ‘Cloud Computing: Implementation, Management, and Security’ puts forward the argument in a more convincing manner by saying:

For example, in the cloud, you lose control over assets in some respects, so your security model must be reassessed. Enterprise security is only as good as the least reliable partner, department, or vendor. Can you trust your data to your service provider? This article explains what is cloud penetration testing and some of the common vulnerabilities found in cloud services. Also, mentioned are some challenges and steps to perform cloud penetration testing.

James F. Ransome and John W. Rittinghouse

What is cloud 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, it is just penetration testing your cloud services. The prime purpose of this is to find security issues in your cloud service before the hackers do. Different types of manual methods and automatic 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.

Why is your cloud vulnerable? (Common vulnerabilities in cloud computing)

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, lack of input sanitization are also 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 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 in a large number.

5. Insecure coding practices

Most businesses try to get their cloud infrastructure built for as cheap 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.

Challenges in cloud penetrating testing

1. Lack of transparency

In the case of some of the not-so-well-known cloud servicers, the datacenters 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 penetration testing policy of the 3 most popular cloud service providers:

3.1. AWS

There are 8 permitted services for Amazon web services on which penetration tests 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.

Also read: Learning AWS Security Audit is Not Difficult at All!

3.2. Azure

Azure allows penetration testing 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 penetration tests 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.

Also read: Azure Penetration Testing Guide – Policies, Tools & Tips

3.3. GCP

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 as are as follows:

• Piracy or any other illegal activity.
• Phishing.
• Spamming.
• Distributing trojans, ransomware, etc during the tests.
• Violating 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 tests 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.

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:

1. Map out all the endpoints like user interface, APIs, subnetworks, etc for which testing is to be done.
2. Decide which endpoints to exclude based on policy restrictions, user permissions, etc.
3. Decide the route for performing the pentest i.e. from application or database.
4. Figure out how well the application server and VMs can take the load of the tests that you wish to perform.
5. Find out the laws that need to be followed while performing tests.
6. Figure out which tools to be used and what types of tests will be performed on which endpoints (Automated or Manual).
7. 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 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, GCP, 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 pentester 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 Pentesting – FAQs

How much does a cloud security audit cost?

A security audit can cost anywhere from $500 to $2000 depending on various factors like the type of audit, size of your website, and frequency of the audit. For estimation, given below is a table for the cost, frequency, and types of tests performed during a security audit by Astra.

How long does a cloud security audit take to complete?

Generally, a cloud security audit takes anywhere from two to three weeks depending on the scale of cloud service, type, and frequency of tests. However, when it comes to cloud security audits done by Astra, you can expect the preliminary results within 48 hours so that you can start with fixing bugs.

How often does a cloud security audit need to be performed?

Ideally, a security audit should be performed quarterly and minimally twice a year. This also depends on the nature of your cloud service and the certification that you wish to be compliant with. For example, in the case of PCI DSS, level 4 merchants need to get the network scanner quarterly.

Who is involved in a cloud security audit?

A cloud security audit is performed by a team of professionals who run a variety of tests to determine vulnerabilities in your cloud service. At its very basic, a security audit is done by two types of teams: internal and external. In the case of internal, people from your own company perform the security audits. The external category is further divided into second-party and third-party security audits. In the case of second-party security audits, the audit is performed by the supplier of the cloud service like Amazon for AWS. Whereas a third-party security audit is done by independent contractors who are not associated with your company through any means.

Tags: syndicate

Share this...

Facebook

Pinterest

Twitter

Linkedin