Cloud Attack Vectors
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, 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 PenTest
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.
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:
CloudSplaining: 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.
WeirdAAL: An AWS attack library. Why We Like It: One thing I love about infosec is the names people come up with for tools and talks, this being an example. That aside, Gates describes one of WeirdAAL’s two overarching goals to be a repo of useful defensive and offensive security functions for AWS, making it a resource you’ll want to bookmark. And if you find yourself in a more black-box testing scenario, WeirdAAL is a perfect choice.
ScoutSuite: A multi-cloud security-auditing tool. It supports the major cloud computing providers: AWS, Azure, Google Cloud, Alibaba Cloud, and Oracle Cloud. That means this is one extremely versatile tool. Plus, ScoutSuite was designed to make assessing cloud environments much easier, providing the user “a clear view of the attack surface automatically,” saving significant time.
GitOops: All paths lead to clouds. As teams scale, it becomes more difficult for security departments to monitor GitHub repos. This is where GitOops comes in, as the tool leverages the literal GitHub “oops.” Another well-named tool, you can use GitOops to find privilege escalation paths as well as for lateral movement in GitHub.
Pacu: An AWS exploitation framework. This automated tool has many modules that allow enumeration of permissions, listing of internal AWS resources in all AWS regions, and privilege escalation attacks. Think of it like a Metasploit for the cloud. Check out the modules for more information. And a note: We recommend testing an automated tool like this in a lab environment before using it during testing.
S3Scanner: Scan for open AWS S3 buckets. You can use this tool during a black-box assessment to dump AWS S3 buckets, which are bound to contain valuable information. S3Scanner allows the user to automate the search for public resources available in different clouds and dump the information, not just in AWS but in other cloud services like DigitalOcean, too.
Microburst: Assorted scripts for Azure security. This is your one-stop shop for everything Azure related. You can use it for Azure services discovery, configuration auditing, and post-exploitation. This handy toolkit was created by Karl Fosaaen, an expert in cloud pen testing and an excellent resource when it comes to testing Azure environments.
SkyArk: Discover the most privileged cloud users. Available for Azure and AWS, this is a useful tool for identifying additional attack surface. Specifically, the tool is designed to detect the presence of cloud shadow admins, a very real threat to cloud environments (making it worthwhile for defenders to keep around, too.)
ROADTools: Framework for interacting with Azure Active Directory (AD). This entry is both a library and an exploitation tool. The library is meant to authenticate with AD; alternatively, you can use it to build tools that integrate with a database containing ROADrecon data. The tool meanwhile is for deeper exploration of AD; there’s a lot of data to sift through in AD, and ROADTools can help you make sense of it. Other similar tools you can check out are PMapper, which is designed for AWS environments, and this Google Cloud privilege escalation toolkit by Rhino Security Labs.
PowerZure: PowerShell framework for Azure security. It’s multifaceted: It can be used for reconnaissance and post-exploitation. So, you can use it to kick off an engagement and bring things to a close. Couple this with AzureHound and your testing should go seamlessly!
Additional Resources for Cloud PenTesting
- AWS, Azure, and Google Command Line Interfaces.
These aren’t pen testing tools per se, but they are incredibly useful and robust resources. The shared purpose of all three of these interfaces is to act as a “mission control” for their specific cloud platform, providing all kinds of tools for interacting with the platform.
This is a volunteer-run encyclopedia for helping security professionals learn various cloud security attacks, techniques, and tactics.
Not only does this website contain a vast array of information (like cheat sheets) on cloud security technologies, but it’s also solid for resources related to security culture and leadership.
Finally, this site aims to be the place to go for all things cloud security. So, we couldn’t do a proper cloud security blog without giving a shoutout!
Challenges of the Cloud Pentesting
- 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.
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 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.
Step 3: Select your cloud pentesting tools
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.
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.
Step 6. Cloud Security Threats
- * 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.
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, 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.
The diagram that explains the general structure of the shared responsibility model.
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:
