An Introduction to Cloud Services
Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP) are the current leaders in Cloud Computing, and offer hundreds of services between them. The continuous expansion of features, inherent flexibility, and broad access offered by Cloud Computing are compelling reasons for its adoption, and organisations of all sizes are looking to migrate their workloads.
Cloud Services are essentially hosted resources that Cloud providers deliver to their consumers as software. Resources can be categorized as belonging to a Cloud Service model, with the most commonly adopted service models being IaaS, PaaS, and SaaS.
- Infrastructure as a Service (IaaS) such as Compute and Storage services.
- Platform as a Service (PaaS) such as AWS Elastic Beanstalk, Azure App Service, and Google App Engine.
- Software as a Service (SaaS) such as Salesforce, Office 365, and G Suite.
In regards to security, Cloud Service providers have adopted a shared responsibility model which is intended to define an organisation's responsibility for securing the Cloud Service models they adopt.
In simplified terms, the lower down the technology stack a Cloud service resides, the more responsibility for security and management controls are transferred from the provider to the organisation. An organisation's awareness and understanding of this shared responsibility as it relates to their cloud deployment model is critical, and may prevent introducing unnecessary risk.
As organisations internal Cloud capabilities mature, many will increasingly adopt so-called Cloud-native practices and supporting services. This further complicates the understanding of the shared responsibility model, and may require adjustments to an organisations Cloud security strategy.
In particular, the following cloud native services are being adopted with increasing frequency by organisations of all sizes, and with them, new attack surface and security challenges.
- Function as a Service (FaaS): such as AWS Lambda, Azure Functions, and Google’s Cloud Functions.
- Containers as a Service (CaaS): such as EC2 Container Service, Azure Container Service, and Google Kubernetes Engine.
The use of Cloud functions to create serverless architecture enables organisations to develop, execute, and manage application functionality while removing the complexity and management overhead associated with designing, building and maintaining the underlying infrastructure.
Container-based services provide a more granular and flexible implementation of traditional virtualization. Containers are orchestrated, deployed as microservices and then dynamically managed on elastic infrastructure. This supports agile processes such as DevOps.
While there are significant security benefits associated with Cloud Computing, organisations migrating their workloads to the Cloud should be aware that the visibility and control they are accustomed to in traditional infrastructure environments will change, sometimes significantly.
Security Assurance in the Cloud
So what does all of this mean for organisations trying to implement an effective security strategy in the Cloud?
Cloud Service providers integrate security controls into their Cloud Service offerings, and then expose those controls to organisations consuming the service as part of the shared responsibility model. Typically, the Cloud Service model to which workloads are deployed will affect the type of security controls made available to organisations.
Security conscious organisations should seek to gain technical assurance that the appropriate controls are exposed to them by the Cloud provider, and moreover, configured in a way that prevents them being bypassed or manipulated. As part of the wider Cloud security strategy, Cloud Penetration Testing should be performed to validate that the available controls are enabled, and configured effectively. This is typically a combination of activities split between passive enumeration of architecture, service configuration and vulnerabilities, and active exploitation of any identified attack paths.
As with more traditional on-premise Penetration Testing, discovery, intelligence gathering, threat modelling, initial compromise, lateral movement, privilege escalation, and persistence are all still considered relevant. However, the technical methods to perform them will, in some cases, significantly change.
Is Penetration Testing Permitted by Amazon, Microsoft, and Google?
The simple answer is yes, with caveats. Cloud Service providers have policies related to Penetration Testing by organisations of their own services hosted in the Cloud. The scope of Penetration Testing may vary slightly between providers, however, as a general rule of thumb, the underlying infrastructure for which the Cloud providers are responsible will always be considered out of scope.
The underlying infrastructure will be determined by the shared responsibility model as previously discussed. If an organisation is unsure where responsibility for security lies relative to a specific Cloud Service, they can consult the Cloud provider for clarification or obtain detailed guidance from both the Cloud Controls Matrix (CCM), and Consensus Assessment Initiative Questionnaire (CAIQ) provided by the Cloud Security Alliance (CSA), an organisation to which Amazon, Microsoft, and Google all subscribe.
While it may be good practice to notify Amazon, Microsoft, or Google before commencing any Penetration Testing activities against one of their tenants, it is not a requirement. However, note that other third-party PaaS and SaaS application providers which may be integrated into AWS, Azure, or GCP may have different requirements.
The Objectives of Penetration Testing in the Cloud
The objective of Cloud Penetration Testing is comparable to traditional infrastructure, in that it attempts to verify the security posture of the target environment. However, the scope and approach to testing must reflect significant differences in the way Cloud Computing is managed.
It is recommended that Cloud Penetration Testing is focused on scenario-based objectives, with clearly defined goals. The overall approach should seek to simulate the practical Cloud attack strategies and techniques executed by sophisticated adversaries.
Passive Enumeration of Cloud Services
Preparation for the active phase of Cloud Penetration Testing must be supported by broad passive enumeration that effectively identifies the exposed attack surface. Architectural design review, and threat modelling combined with a comprehensive review of the configuration of Cloud security controls is the recommended approach. While identifying insecure configuration is fundamental to performing Cloud Penetration Testing, it should not be the sole objective.
Passive enumeration of the target Cloud environment is typically performed using a custom service account provided by the organisation. The service account is used to authenticate scripts and tools that automate the gathering of configuration telemetry. While tools and scripts often include checks against Center for Internet Security (CIS) Benchmark best practices, output is manually reviewed and contextualized to identify potential attack paths.
In summary, passive enumeration of Cloud Services will look to identify weaknesses in the following technical control domains, which can then be targeted for active exploitation.
Exploiting Common Cloud Attack Vectors
Cloud Penetration Testing will use specific tactics, techniques, and procedures (TTPs) in order to compromise, escalate privileges, and create persistence in Cloud environments. These TTPs can be leveraged to exploit weak configuration identified within the target environment.
Exploiting Publicly Exposed Services
Exposed secrets such as access keys and tokens could lead to a full-scale breach of an organisation's Cloud environment. Publicly accessible buckets pose a risk not only from adversaries targeting the organisation but also opportunistic attacks where public buckets may have been listed in publicly available repositories or indexed by search engines.
Once an adversary has possession of a secret, they can simply authenticate to the organisation's environment using the Cloud SDK (Command Line Interface). The level of access will be determined by the IAM roles and permissions assigned to the compromised secret.
Secrets are often unintentionally leaked or exposed in a number of ways including hidden directories, source code or version repositories, packaging repositories, and web application debugging and logging messages.
Furthermore, secrets can be obtained through exploitation of web application vulnerabilities such as Server Side Request Forgery (SSRF), XML External Entity (XXE), and Local File Inclusion (LFI) to name just a few.
Cloud User Credentials Compromise
Organisations must assume that attackers will target their end users in order to obtain Cloud credentials. There are a multitude of attack techniques for compromising Cloud accounts:
- Credential Stuffing
- Password Spraying
- Phishing
Attacks against Cloud users are leveraging increasingly large credential dumps to improve the effectiveness of brute force account compromises. Such attacks often target Office 365 and G Suite accounts using tools that automate credential harvesting with password spraying attacks.
The scope of Cloud Penetration Testing should include a security review of the organisations on premise corporate systems. Compromise of a corporate workstation or laptop which are owned by privileged users such as developers or administrators is likely to provide a number of avenues for compromising Cloud user credentials, or service account keys and tokens.
Leveraging Permissive IAM Roles and Permissions
Many organisations fail to implement the principle of least privilege, leading to overly permissive policies which adversaries and malicious insiders can leverage to perform dangerous actions. Such actions may include viewing and exfiltration sensitive data, modifying or deleting data, start, stop and delete Cloud functions and services, deploy resources, and perform privilege escalation.
IAM roles and permissions affect almost all aspects of Cloud Computing and the attack surface exposed by overly permissive IAM assignments can be significant. Some examples of how a malicious user could leverage overly permissive IAM roles and permissions include:
- Enumerate access to Cloud Services for the current IAM role
- Create new Cloud users
- Extract credentials from metadata, configuration files, environment variables, and logs
- Clone databases and instances to access information stored in snapshots
While effective deployment of IAM roles and permissions may not prevent all attacks against Cloud resources and assets, they are an effective tool for limiting the blast radius (impact) of any such compromise.
Abusing Cloud Functions and Serverless Architecture
Serverless application architectures offer a number of security benefits, however, threats to applications could still persist. Microservices break applications up into smaller components that can be triggered from a diverse range of sources, including message queues, storage services, databases, and even other functions. This creates more targets, thereby increasing the overall attack surface of the environment.
- Cryptomining
- Execution of malicious Cloud functions
- Instance compromise via insecure error handling
It should be noted that Cloud functions don’t need to be insecure for attackers to abuse them. One of the more recent tactics used to exploit functions, is a spin off from the Denial of Service (DoS) attack, known as a Denial of Wallet attack. Rather than attempt to deny access to a service, the repeated triggering of a Cloud function takes advantage of Cloud auto scaling features to impact an organisation financially.
Exploiting Container Services
Much like serverless application architectures, the adoption of container technologies such as Docker and Kubernetes introduce a significant attack surface that organisations should be aware of. While the benefits of containerization technologies are numerous and well documented, just like other Cloud Services, they can be vulnerable to a broad range of attacks.
Attacks against container services can be initiated both externally by unauthenticated remote adversaries, and by malicious insiders, including via compromised Cloud user accounts. Some example of attack vectors includes:
- Insecurely configured container registries
- Namespace breakout vulnerabilities
- Use of vulnerable container images
- Exposed service ports
- Lack of Role-Based Access Controls (RBAC)
When implementing container services, organisations must ensure the security posture of individual containers within the cluster. Exploitation of a single container could lead to a complete compromise of the cluster and other Cloud Services.
Cloud Penetration Testing Summary
Organisations are increasingly migrating critical workloads and data to the Cloud. Such environments can be highly complex and expose attack surfaces in ways that are fundamentally different from traditional workloads.
Cloud Penetration Testing should be an essential component of an organisation's overall Coud Security strategy. Testing should include comprehensive enumeration of an organisation's attack surface, identification of configuration weaknesses and vulnerabilities, threat modelling, and goal-orientated exploitation activities.
For more information on Cloud Penetration Testing Services, please contact the LRQA team.