Please enable JavaScript.
Coggle requires JavaScript to display documents.
Cloud Penetration Testing - Coggle Diagram
Cloud Penetration Testing
Welcome
Methodology and Workflow for Penetration in Cloud Environments.
prepare you for the skills you need to have to perform a Cloud-based penetration test and assessment.
Learn and understand the mindset and methodology of offensive operations in a Public or Private Cloud env.
As penetration testers, or even those looking at offensive techniques, these new architecture pose challenges for both attacker-focused and defender-focused groups. The connectivity to cloud resources will change the way we approach a penetration test, and the sheer scalability of the problem may be magnified as elastic cloud services are more and more ubiquitous.
Unique properties of Cloud computing
Design choices around High Availability
Services can be directly and easily exposed to the internet
Tooling is provided for elasticity of the environments created
NIST defines cloud computing in SP-500-291
Self Service Capable
: Able to insatiate one's own service
Broadly Accessible
: Available from “anywhere”
Service Measurability
: Being able to measure resources without additional tools.
Resource Pooling:
Being able to group resources
Rapidly Elastic
: Having the capability to spin up new services and spin them down dynamically
Types of cloud
Platform as a Service
restrictions in escaping the env which may be shared
Infrastructure as a Service:
This architecture provides the
least amount of restrictions of these architectures
. What penetration testers need to understand with IaaS environments is how to find the Terms of Service, and
Acceptable Use Policies to understand demarcation and scoping.
Software as a Service:
In this scenario you can access the software itself through the appropriate channels,
highly restrictive
There is,however, few restrictions on authentication. If you can forge an authentication into an office365 user that is part of the scope of an engagement, then you can run tools in that environment such as MailRaider. With these tools you can harvest and extract mailboxes.
TRADITIONAL PENETRATION TESTING METHODOLOGY
will attempt to follow a methodology for conducting offensive operations in a cloud while trying to stay within the constructs of a standardized framework for penetration testing. From reconnaissance, to scanning (or alternatively to mapping), to discovery, and finally into an exploitation phase.
There are, however, differences in how we approach public cloud utilities. We need to change our approach to fit into the public utility space.
6 Steps:
Preparation
Recon
Scanning
Exploitation
Post Exploitation
Lessons Learned/ Remediations
Differences include:
Recon in public cloud env
will take many diff forms such as looking more broadly at open datasets & the vast array of publicly available that must exist in the cloud for many of the services to function.
Scanning, enumeration, or mapping a cloud environment
will happen at many different layers and will also potentially happen in a much different way than on premise,
we will not be relying on what is available on the network, but instead we may be relying on what the system knows about nodes that exists.
Discovery, Vulnerability Discovery, or Service Discovery, will also be different in a cloud
as many of the protocols that are used in the cloud may end up very different than what we may find on a LAN. This must be the case as many of the LAN protocols do where not designed to operate within the parameters of most of the Cloud Environments
Exploitation in the cloud will more than likely yield to additional pivots and additional footholds,
but the mechanisms in which we achieve those pivot points may move beyond just node to node and instead involve the attacker's machine
CLOUD PENETRATION TESTING METHODOLOGY
8 steps:
Recon / Data Collection
Data Analysis for Discovery
Scanning / Mapping
Vulnerability / Discovery
Exploitation / Elevation
Post Exploitation Recon
Persistence / Pivot
Lessons Learned / Remediate
One of the prerequisite items may be that our infrastructure, services, and applications are dynamic and fast moving, and as such the collection of data for surface scans and enumerations will be critical. This perquisite notion will drive our methodology.
1. Recon / Data Collection
available data that may exist in a target organizations data repository, for example, all the Amazon S3 buckets
that are publicly enumerable. We do this to potentially mine this data for information about our target in the next step.
In this step we are collecting data about not just our target, but potentially all the
2. Data Analysis for Discovery
to be able to properly enumerate the architecture of the system This analysis step is critical in
trying to understand what components or services our target has exposed or has available
In this step, we must sit and analyze all the public and privately available information that we have obtained
3. Scanning / Mapping
but there is a notion of interacting with service API to divulge additional information about a target infrastructure
AWS,GCP,Azure will know about an organizations resources and expose this through an API quicker than we can scan the infrastructure itself
In this step we may use traditional network scanning tools, or web enumeration tools,
4. Vulnerability / Discovery
While some of the vulnerabilities may be at an app layer, there could also be configuration problems.
This will address any known configuration, infrastructure, or application vulnerabilities that may exist in that target org
5. Exploitation / Elevation
Depending on the target system, the exploitation step could be the point in which remote exploitation exists, but it can be the step in which
remote exploitation is not the only mechanism afforded to us but being able to elevate privileges and move up to a more privileged position
6. Post Exploitation Recon
can make decisions about what they are seeing. It could be that the systems in this step are very small or tiny, which could mean they are in a lab environment
It could also be big expensive systems which would indicate their actual value to the organization.
This is a different type of reconnaissance step than the initial reconnaissance activities, given enough access an attacker
7. Persistence / Pivot
Once the internal or system recon is completed, an additional step toward maintaining access should be provided.
This step affords the attacker into inject standard access or persistent access to the system depending on what the environment is
8. Lessons Learned / Remediate
and assistance in hardening the environment and testing for weaknesses. This step is added to provide value back to the defenders of organizations
In many cloud environments these actions need to be fast and automated and inserted into existing builds
The final step in this methodology should be a remediate step. The purpose of the Red Team/ Attacker Team in many organizations is to provide feedback
PUBLIC CLOUD ASSESSMENTS
If we wish to model the attackers as well as perform excellent penetration assessments of cloud-based services and applications, this becomes a critical component. The capability to identify, discovery, and attack cloud- based applications will be essential to a penetration testing individual or team
The tools we will be using may be calling other tools that we are familiar with but in new and novel ways. The differences that you will find with what we are doing is:
- Capabilities to find and discover assets relating to companies at a larger scale than a traditional network
- Capabilities that leverage passive data collection techniques instead of active ones for initial discovery
- Capabilities that leverage large datasets that can be collected, stored, and mined for later use and analysis.
Cloud-based environments can be vast and complex at scale, not just because of automation, but also because he capability for any person at any company to quickly spin up new assets and services for an organization.
DEMARCATION POINTS IN A PUBLIC CLOUD ENVIRONMENT
The general rule for many service providers is once you leave an area of access and potentially gain or leverage access in a shared environment or on a different customer area, this is where you are no longer in
your scope. One limitation example includes leaving a container and accessing the container host. Many times, these container hosts are shared amongst different customer's and as such are considered out of bounds.
Cloud Service provider could provide testing of their orchestration toolkit in the public cloud in an avenue to do so in the form of a bug bounty, however your engagement with a customer may fall out of this scope
Make sure you read and understand the Terms of Service, Rules of Engagement, and Penetration Testing
guidance that the Cloud Service Providers have, in many cases, provided to you. Misunderstanding these
In the public cloud we need to start looking at what could potentially be in scope for our penetration test
documents could mean that you are put into a situation in which you will be facing potential jail time for infringing on other customers or the cloud service provider itself. Let’s look into a few of these
Points
Limitations:
Apps on platforms, Identity & access mgmt
Out of scope
Cloud Provider Software / Management Layer, Compute, storage,nw, hardware infra
In Scope
Cloud Virtualized OS , Cloud NW(VPC) Storage buckets
Attacks!!!
ATTACKING PLATFORM AS A SERVICE
Penetration testers can generally attack the applications, looking for flaws, and can at times find themselves with a shell in a ‘containered’ environment
. While any other customer owned container is in scope, the host,
and many other containers are not.
A penetration tester must be exact when conducting pivots in this environment to ensure that they have the appropriate scope to perform additional attacks
.
PaaS provides developers with a shared environment in which they can host their applications These shared environments are designed to facilitate the developer's deployment of applications
Attacking the application running on OpenShift that is owned by the customer is in scope.
PaaS is hybrid env between Iaas & Saas
Attacking OpenShift’s API’s looking for vulnerabilities would be out of scope as the customer is not RedHat who operates OpenShift.
PaaS service providers:
Open SHIFT, Engine yard, Google App Engine, Force.com, Salesforce
THE ATTACKERS VIEW OF IAAS
Other considerations for many of the testers.
Authentication / Active Directory as a service
Networking
: Limitations in the capability to deploy standard network security components provide a path for exploitation.
Databases as a Service
Storage
: Block Storage for storing of files without the necessity of a full operating system. These store environments can be loosely configured and allow for unauthenticated access to files
Load Balancers, Shared File Systems, Network Firewalls as a service & many more
Compute
: Virtual Machines which are typically in scope for attack. Their security is dictated by the administrator. Could range from full-service expose to limited access lists
THE ATTACKERS VIEW OF PUBLIC IAAS VISUALIZED
Cloud services like serverless compute may also be tested Serverless functions are deployable by a customer, the underlying hardware and software is customer shared. Performing any type of container escape function in a serverless environment would be out of scope from a penetration test
Compute functions should be inscope While an attacker could add their own EC2 Compute instances or change NATs as a regular administrator could do, finding exploits on the software would be restricted
the AutoScaling function and NAT Gateways would potentially be out of scope for attacks
ATTACKING SOFTWARE AS A SERVICE
Leverage user or administrative access to find & obtain data
Add user accounts or add additional accounts or tokens on the system
provide a shared software environment with many customers each having either their own instance of the software or their own accounts. Typically a penetration tester can:
The goal in this environment is typically to provide or obtain data of some sort. Consider the following scenarios:
SaaS are one of the most restrictive cloud services that you may encounter
The ability to obtain customer information or steal sensitive documents in Salesforce
The ability to read through company shares in Box, Dropbox, GSuite, SharePoint, 1Drive, and other locations.
The ability to obtain additional info about the target org through gaining access to email accounts in office365 or Gmail
This capability can provide attackers with insight into a corporation or, worse, leak sensitive information. Our job as penetration testers is to model this activity to see if Target Organizations can even see this level of
exposure or prevent attackers from accessing this data. Consider using Insider Threat or Theft/Espionage roles in this environment to model behavior instead of attacking the system itself
Recon at Cloud Scale
Increasing Attack surfaces
Cloud env can be vast & complex due to the capability for any person at any company to quickly spin up new assets and services for an organization
Creating assets in a public provider without consideration for basic security controls that are typically enforced. by a centralized department could lead to insecure assets with corporate information and data
Attackers cannot only identify these new and potentially vulnerable assets not only by actively interacting with them but also through passive identification methods
A capability to find and discover assets relating to companies at a larger scale than a traditional network Capabilities that leverage passive data collection techniques instead of active ones for initial discovery
SURFACE AREA INCREASE TIPS AND TRICKS – DOMAINS
If you consider a single corporation like Google, this one company has many numerous domains in which they could have services or systems spread across. Some of these are organic, others come from acquisitions.
Any one of these systems could be potential for a vulnerability and may not even have been scanned due to the naming of the environment. Google acquired several other companies over the year like Instagram, WhatsApp, and others
All of these links are related to one company. In the case of Facebook itself, it can be rather easy to enumerate these first few domains.
https://developers.facebook.com/docs/workplace/additional-configuration/domains/
TIPS AND TRICKS DOMAINS: INTERNET DATA DOWNLOAD
There are several at the bottom of this list, premiumdrops, and WhoisXMLAPI that provide the ability to download lists of Top-Level D
Having the data and being able to process it is the beginning of cloud-based domain level harvesting.
This script leverages several sources of information some of them are open source and free to use, while others require commercial licensing like Censys.
*Organization Domains must be in scope of a test.
https://github.com/hdm/inetdata
this provides a way to scale reconnaissance
HD Moore created a repository for enumerating domain names and IP addresses on GitHub titled inetdata
CERTIFICATES: REVIEW
Certificates have very specific properties that enable them to be used to validate the authenticity of a host or sys
In the instance where we would like to discover hosts, we can take advantage of both the Subject and Subject Alternative Names in the Certificate body.
Subject is typically set to the fully qualified hostname of the certificate.
There multiple types of certificate authorities in the wild, but the most common ones will have the subject common name (or CN) to FQDN
Automation is now a very common thing to see with the creation of the ACME protocol (Automatic Certificate Management Environment)
ACME AND LET’S ENCRYPT
Certbot is an automation tool created by EFF to help support Let’s Encrypt requests through ACME
You can find certbot at:
https://certbot.eff.org
Encrypt created a new protocol known as ACME that provides the tooling and automation to end users This provides a mechanism in which certificates can be re-issued without human intervention.
Certbot provides administrators the capability to:
Let’s Encrypt is a free Certificate Authority that allows administrators to have free, browser trusted, cert
Request their own certificates, automatically
Help automate http-based or DNS-based validations
Re-request their own certificates, can be automated through cron
CT - CERTIFICATE TRANSPARENCY
censys.io
To better understand how an attacker can use Certificate Transparency reports we can use
censys.io
censys.io uses known Certificate Transparency Logs and provides this feed in a searchable and indexable way
Consider every host that has a cert issued could potentially shop up in the list:
report will start to list out many numerous cert that are valid or even expired. Based on this, every host in the ORG ecosystem can be enumerated.
Host discovery can be done now through Certificate Transparency (CT) Reports. It can help us understand new and potentially unsecured
None of this data is necessarily secret, nor is it intended to be used in this manner, this is just a new way to perform reconnaissance that had to be discovered for the attackers to scale out how they uncover hosts.
DOMAIN ENUMERATION TOOLS
Using combination of CT report, cutom & generic wordlists, and common patterns we can now find hosts at scale
Two Domain harvesting tools,
the first of which is called
Gobuster
and the next of which is
DNSRecon.py.
More importantly we need to at least start becoming familiar with the power of a good wordlists. Wordlists become a critical component to the discovery of assets, directories and more.
A great wordlist will ideally provide us with an exact set of hosts and domains to match on. A less than ideal but complete wordlist can then be used to help us with further enumeration.
servers that are development exposed to the internet, or perhaps they are orphaned or discarded assets and with tools like these we can often find these servers. In finding these servers it may lead us to an entry point to further and further exploitation
Amazon
https://aws.amazon.com/security/penetration-testing/
Azure
https://docs.microsoft.com/en-us/azure/security/azure-security-pen-testing
https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement?rtc=1