Cloud Security Pentesting Tools

 

Intro

Security testing is crucial to the security assurance of cloud environments, systems and services. In this document, we discuss the most predominant form of security testing in relation to cloud environments — penetration testing.

Penetration testing, as defined by NIST, is a specialized type of technical assessment conducted on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Such testing can be used to either identify vulnerabilities or determine the degree of resistance organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills). ENISA’s definition is conceptually similar to NIST.

Traditionally, the primary objective of penetration testing is to identify technical security weaknesses and systems resilience. However, a broader application of security testing also serves to assess an organization’s implementation of security policy, compliance requirements, the effectiveness of employees’ security awareness and ability to identify and respond to security incidents.

Hence, penetration testing is essential to any holistic cyber defense effort as it provides visibility into system security, its assurance (or lack thereof), and produces highly actionable mitigations to drive the security of the systems and environments involved. As cloud services continue to enable new technologies, see massive adoption and become foundational for many businesses, there is a need to extend the scope of penetration testing into public cloud systems and components.

The process described here aims to provide the foundation for a public cloud penetration testing methodology and is designed for current and future technologies that are hosted on public cloud environments or services. In particular, this document focuses on penetration testing of applications and services hosted in the cloud. It addresses the methodological and knowledge gaps in the security testing of information systems and applications in public cloud environments.

Target Audience

The target audience of this document are penetration testers and cloud / cloud-based systems security practitioners. However, the first few pages will provide CIOs, CISOs and Senior Management an understanding of what cloud penetration testing is, its scope, its context, its objectives and how it fits within a cybersecurity strategy. Developers and Architects will also find this document useful while designing a secure (public cloud based) system.

Cloud Penetration Testing In Context

Penetration testing, also referred to as dynamic testing is commonly performed after code has been developed and deployed, even if not in production. It’s critical to remember that penetration testing is not necessarily the best or most efficient form of testing. Its appropriateness can be determined based on context and purpose.

For example, when security assurance of a live cloud-based product or feature is required, penetration testing by the methodology described in this is advised, but, when the feature is just being designed — threat modelling practices are the best fit. The Microsoft Secure Development Lifecycle places Security Testing in the Verification Phase, including Dynamic Testing and verification of threat model/attack surface.

Threat Modelling

Perform Threat Modelling on the scope:

1. Consider relevant cloud service provider specific, deployment and consumption models threats
2. Consider industry standard/best practice on cloud threats (top threats)

Reconnaissance and Research

Conduct standard reconnaissance (records, web, network, IP fingerprinting, osint, people, social & media):

1. Leverage DNS records (N, MX, NS, SPF, TXT, CName, A) to determine cloud providers and
   services of a targeted domain/organization and potentially mismanaged or hijackable ones
2. Leverage identity federation servers reconnaissance via google dorking and DNS records for adfs, auth, fs, okta, ping, sso, sts, oauth, openID, saml, ws, technologies and services providers etc.
3. Look for cloud credentials in code and text repositories (such as API keys, federations service private certificates and storage account keys/sas, Azure publish setting file certificates)
4. Identify cloud administration, operation, user and chain of supply personnel targets via Linkedin, company website
5. Identify scope and related cloud storage instances, accounts and services
6. Enumerate account, user and/or role via service API calls (such as AWS enumeration with a known or common resource identifier within the account or blindly with UpdateAssumeRolePolicy)

Test for Spoofing of user identity and other entities

1. Steal hardcoded serverless workloads function (a workload implemented as a function) credentials and secrets (like hardcodedAzure function code or by pulling a lambda deploy package)
2. Attempt load balancer MiTM for session hijacking (elb) by cloud service configuration or load balancer instance compromise
3. Attempt domain transfer to another registrar for domains not transfer prohibited (Route53, aka domain hijacking)
4. Compromise default privileged service and user accounts in legacy cloud environments and services (likeAzure old ASM co-administrator accounts or Azure Storage Account keys)

Test for Tampering

1. Alter data in datastore for fraudulent transactions or static website compromise (s3, rds, redshift)
2. Alter a serverless function, logic app or otherwise a business logic implementation for action on objective or escalation (AWS lambda or Azure logic apps)
3. Alter billing threshold and alerts (AWS expenditure, fluctuation custom threshold and cloudwatch alerts)
4. Change application, website or otherwise code integrity for resource abuse, persistence, exfiltration or other (AWS s3 static websites orAzure websites)

Test for Repudiation

1. Operate in regions where logging is not enabled or disable global logging (like CloudTrail)
2. Alter log files in a non-validated log store or disable validation (like cloud trail log validation)
3. Disable network traffic analysis / logging (VPC flowlogs)

Test for Denial of service (D.o.S)

1. Destroy / encrypt data in datastores not backed up or destruction protected (s3, rds)
2. Deny servicers or operability of servers and clients by flooding email or sms messages from a cloud environment (AWS sns, ses)
3. Destroy cloud services configuration, datastores and/or accounts (sufficient to use — dryrun AWS cli flag or prove you have the privileges to)

Test for Elevation of privilege

1. Trigger Cloud Orchestration Automation with higher privileges (for instance, Cloud formation stack with highly privileged roles assumed)
2. Run or deploy a workload with an assigned/passed service or role, export instance credentials for those privileges (such as ec2 passed role and meta credentials)
3. Leverage policy write capability to change or create an unrestricted policy assigned to a user (like am:CreatePolicyVersion)
4. Change the default policy for a user or new users to include additional privileges (like setdefault-policy-version)