First published on the company’s official account:https://mp.weixin.qq.com/s/gKXoms9DTkdT73u7UkgW-Q
Preface
This article will deeply explore cloud security knowledge and its practical application scenarios on both offense and defense ends, and comprehensively analyze the potential applications of BAS technology in these scenarios. By reading this article, Party A's security personnel will be able to use simulated attack testing and repair technology to effectively strengthen the organization's security defense line, and accurately adjust security control strategies and resource allocation based on test results, thereby significantly improving the efficiency and results of security management. At the same time, for learners or professionals who have a strong interest in the field of cloud security, this article will help you enhance your understanding of cloud security architecture and learn to implement effective cloud security measures. For passionate learners or professionals in the BAS field, this article will also lead you to a comprehensive understanding of and familiarity with BAS technology, thereby improving your professional skills and comprehensive capabilities in security testing, security operations, and risk assessment.
Structure diagram of this article:
0x2 introduced
1.1 Cloud native security risks
In today's digital era, cloud computing platforms such as AWS, Google Cloud Platform (GCP) and containerization technologies such as Kubernetes have become the preferred infrastructure for enterprises and developers to deploy applications and services. The widespread adoption of these technologies not only brings unprecedented flexibility and scalability, but also introduces new security challenges. As more and more sensitive data and key business processes are moved to the cloud, the importance of cloud security has become increasingly prominent.
Wiz conducted a Kubernetes security situation analysis on 200,000 cloud accounts and found that 85% of the clusters are hosted by cloud vendors, among which AWS's EKS is the most popular. Regarding initial access, the public cluster accounted for 69%, and of all exposed Pods, 52% contained container images with known vulnerabilities. In terms of lateral movement and privilege escalation, 8% of Pods have RBAC permissions that exceed operational requirements, 18% of Pods have sensitive paths mounted on the host, and about 18% of Pods run with Root permissions. In terms of network isolation, only 9% of clusters use network policies. At the impact level, 19% of Pods do not have resource quota limits set, and 15% of Pods have permission to leave the cluster. In terms of security controls and mitigation measures, only 6% of clusters do not use PSP, external admission controller or PSS.
As enterprises move to the cloud, many large enterprises have built private clouds and hybrid clouds internally to meet compliance and other needs. Different types of customers choose public, private or hybrid clouds based on their business needs, and each choice presents unique security challenges and considerations. Startups and SMEs tend to use public clouds because of their cost-effectiveness and scalability, but they must also rely on the security practices of the cloud service provider and be concerned about the risks of data leakage and permission misconfiguration. In contrast, industries such as finance, medical and government, due to their high requirements for data privacy and compliance, usually choose private clouds to obtain stricter data control and security protection, but this also means that they need to bear higher security management responsibilities and costs themselves. Hybrid cloud users, such as large enterprises seeking flexibility while maintaining control of critical data, face challenges with security policy consistency and data transmission security across environments. Although there are differences in the sharing of security responsibilities between public and private cloud users, all customers are required to implement basic security measures such as encryption, access control and malware protection, while adhering to the principle of least privilege to protect sensitive data and resources.
1.2 Validity verification in cloud native
In cloud security scenarios, security threats emerge in endlessly. As one of the technologies of Lizhu-Security Verification Platform, BAS helps enterprises identify and respond to specific security threats by simulating potential attack behaviors. The core advantage of this technology is its ability to detect threats and risks in advance, thereby enabling proactive protection and reinforcement of the enterprise. Gartner defined the BAS technology category in 2017, emphasizing that it verifies the effectiveness of security protection by continuously simulating attacks against different assets. This method not only helps enterprises get rid of the "defender trap" of passive defense, but also systematically evaluates the current status of actual combat protection capabilities, thereby systematically understanding their own actual combat security capability indicators.
Cloud-native BAS helps enterprises discover and patch potential security vulnerabilities in advance by simulating real attack scenarios, ensuring the security of the cloud environment and avoiding data leaks and other security incidents. The introduction of this technology not only improves the limitations of traditional security testing tools in cloud environments, but also achieves more comprehensive and accurate security protection through integration with existing security architecture.
2.3 Summary
As enterprises transform from digital to cloud-native, the cloud computing market is dominated by giants such as AWS and Azure. Enterprise cloud architectures are diversified, covering hybrid clouds, private clouds, etc., each with its own characteristics. Hybrid cloud is favored both domestically and internationally for its security compliance and cost-effectiveness. The evolution of cloud application architecture promotes microservices and containerization technologies, improving application agility and reliability, but it also brings security challenges. Cloud security has become the focus of enterprises, including protecting data integrity, preventing unauthorized access and network attacks. BAS technology helps identify weaknesses and prevent potential risks in advance by simulating attack behaviors.
In the face of cloud security attacks, enterprises need to be wary of account utilization at the network layer, SSRF permission bypass, container escape at the application layer, intra-domain lateralization, API spoofing at the service layer, etc. A comprehensive security strategy must be adopted to minimize granular account control, such as implementing end-to-end encryption, strengthening authentication, and conducting security audits to ensure that the cloud environment is safe and reliable. The security capabilities of cloud service providers are also important factors that enterprises must consider when selecting them. Next, we will discuss several typical examples of cloud security and expand the attack surface.
0x3 Attack
Having finished talking about the current situation of enterprise cloud security environment above, we will ask what are the specific intersections between network security offense and defense and enterprise cloud security? Next, let’s explore the attack scenarios we often encounter in actual combat. (PS: This is just my personal experience on the attack surface of cloud native. There are still many attack surfaces to be added, and teachers need to consider and provide guidance.)
3.1 Attack surface in AK/SK
With the rapid development of cloud native technology, more and more organizations are migrating their businesses to the cloud. During the process of migrating to the cloud, some special security risks will also appear. Among them, the most dangerous security risk is AK/SK attacks. There is a special credential on the cloud, which is called a cloud credential, SecretKey, access key, etc. by major cloud vendors. Using this credential to attack the cloud is called an AK/SK attack. Its characteristic is that when you have a SecretKey with permissions, you can use the SecretKey to add, delete, modify and check services such as buckets, security groups, domain names, containers, and serverless functions on the cloud. You can even execute commands on the server without relying on the server's SSH password. The following are some attack methods using AK/SK:
3.2 Kubenets attack surface
The origin of Kubernetes can be traced back to Google's internal Borg system. Borg is a large-scale internal cluster management system that runs hundreds of thousands of jobs from thousands of different applications. Kubernetes originally originated from Borg within Google. Later, Google rewrote it into Kubernetes using the Go language based on the Borg system, removing exactly 8 characters from the beginning and the end. The name comes from Greek, meaning "helmsman" or "navigator". It aims to become the "helmsman" in the field of container orchestration and provide unified deployment, management and scheduling services for containerized applications. Kubernetes is designed to remove the burden of orchestrating physical/virtual compute, network and storage infrastructure and enable application operators and developers to focus entirely on container-centric primitives for self-service operations. In addition, Kubernetes also supports horizontal automatic scaling, which automatically increases or decreases the number of running application instances as needed to respond to load changes.
3.2.1 API Server attack
When we obtain the Admin Token, we can operate the API Server to control the cluster.
curl -H "Authorization: Bearer $TOKEN" $APISERVER/api --insecureYou can also place the Admin Token in the ~/.kube/config file, and then use the command line tool for subsequent operations:
kubectl get namespaceskebectl get pods -n {namespaces}kubectl exec -it -n {namespace} {podname} /bin/sh3.2.2 Kubelet 10250 port attack
Kubelet, as a basic component of Kubernetes, plays the role of running as an agent on each node and is responsible for managing the life cycle of the container in accordance with the PodSpec (the container's operating specification). It ensures that the containers defined in the PodSpec are running correctly and in a healthy state. Due to Kubelet's role in containers, hackers will exploit vulnerabilities in Kubelet to attack the cloud. Here we introduce a Kubelet information leakage attack. Port 10250 is the HTTPS port of the Kubelet API. This port provides Pod and Node information. If the port is open to the outside world, the attacker can use the public API to obtain sensitive information and even execute commands.
curl -k https://host:10250/podsExecute the command in the container based on the information obtained above:
curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} \-d 'input=1' -d 'output=1' -d 'tty=1' \-d 'command=whoami'The above command gets the WebSocket address, and connects to the WebSocket to get the command result:
wscat -c "https://host:10250/websocket" --no-checkAfter obtaining the Admin Token, you can also use the service port to execute commands in the Pod:
curl -k -H "Authorization: Bearer $TOKEN" https://host:10250/run/{namespace}/{podname}/{containername} -XPOST -d 'cmd=whoami'3.3 Etcd attack surface
3.3.1 2379 port attack
The original intention of the design of Etcd is to meet the data consistency problem in distributed systems. It uses the raft protocol as the consistency algorithm to solve the problem of data consistency of multiple nodes. With the development of cloud computing technology, the traditional way of running Etcd on physical machines has gradually exposed the problem of low efficiency. In order to cope with this challenge, companies such as Alibaba began to migrate the etcd operating environment to the cloud, using cloud services such as ECS, SSD or ESSD storage to achieve rapid vertical and horizontal expansion of the etcd cluster, as well as the convenience of fault migration2. This comprehensive cloud approach not only improves the availability and scalability of the etcd cluster, but also significantly reduces the upgrade time, allowing etcd to more stably carry the demand during peak business periods. Etcd stores Kubernetes cluster data. If you can successfully access the service port, you can obtain sensitive information in the cluster, including Kubernetes Secrets, Admin Token, AKID, etc.
etcdctl --endpoints=https://host:2379 lsAccess Etcd with Cert:
etcdctl --endpoints=https://host:2379 --cacert=ca.crt --key=etcd.key --cert=etcd.crt endpoint health3.4CI/CD攻击面CI/CD (Continuous Integration/Continuous Deployment) is a software development practice designed to frequently integrate code changes into a shared repository in an automated manner and ensure that software versions can be quickly and safely deployed to production. The CI/CD pipeline automates the process of coding, building, testing, and deployment, aiming to improve development efficiency, reduce deployment risks, and ensure high-quality software releases. The following is an introduction to several CI/CD attack scenarios:
Extract the GitHub key used by your organization
Supply chain attacks: By adding malicious code to one of the other private or public repositories used by the organization, or by injecting malicious code or exploiting security vulnerabilities in third-party dependencies, an attacker can tamper with the software package during the software build or deployment process, impacting end users.
Security vulnerabilities of automation tools: CI/CD processes rely on various automation tools and platforms, and security vulnerabilities in these tools themselves may be exploited to perform attacks such as code execution, privilege escalation, or data leakage.
3.5 Docker Swarm attack surface
Docker Swarm is a container orchestration tool officially provided by Docker, which allows users to manage containers on multiple Docker hosts and automatically deploy, expand and manage container applications in the form of a cluster. Swarm leverages the Docker API to provide users with a simple yet powerful platform to achieve high availability and load balancing of containers. However, as with any technology platform, Docker Swarm environments may face specific security threats and attack scenarios.
Such as Dump Swarm Secrets, Abuse Networks Features, Swarm node intrusion, service attacks, lateral movement, the following are some Docker Swarm attack scenarios.
Docker Swarm management node: After Docker Swarm obtains the token, it can manage the metadata permissions owned by the token. Then carry out attacks such as information collection, authority maintenance, and lateral movement.
Docker Swarm privilege escalation Node if it uses Promote permissions or abuses Promote permissions to escalate the corresponding Docker privileges
DUMP Docker Swarm Key An attacker may attempt to exploit the key to perform malicious operations or gain access to the swarm network. A common attack surface is through illegally obtaining or "dumping" (exporting) Docker Swarm's encryption keys, which are used to encrypt cluster communications and data.
Swarm obtains log information. Viewing the real-time logs of the Docker service is a common operation and maintenance operation. It is very useful for monitoring and diagnosing the running status of the service. However, this operation may also introduce some potential security risks, especially if permissions are improperly managed or configured incorrectly. The following is the attack surface and corresponding risks that this command may bring:
docker service logs --follow hellogoogle3.6 Kernel eBPF attack surface
Container escape using eBPF is an advanced network security technology that allows attackers to perform malicious operations inside the container, thus bypassing traditional security measures. eBPF (Extensible Berkeley Packet Filter) is a powerful kernel extension that provides a mechanism to monitor and modify system calls, network packets, etc. With eBPF, attackers can perform container escapes without being detected.
The picture shows the abuse process of eBPF Cross Container Attacks (CVE-2022-42150)
eBPF can also achieve: eBPF hijacks Kubelet for container escape\uses the sys_bpf_admin account used by HIDS for container escape\eBPF uses Static Pod for container escape\SYN backdoor, etc. Zhiqian is continuing to develop relevant security verification use cases.
3.7 Cloud domain attack surface
Consent Grant Attacks：
Abuse of the Microsoft Entra Connect synchronization service account mainly includes the following scenarios:
3.8 Virtualization attack surface
3.8.1 In the virtual machine:
Sandbox confrontation scenario: Attackers identify and circumvent the sandbox environment by detecting the characteristics of the virtual machine environment (such as the existence of specific files, hardware pointer behavior, CPU temperature, or accessing BIOS information through WMI) and modifying underlying data structures such as IDT, LDT, and GDT to avoid malicious behavior being analyzed.
PWN scenario:
Escape series:
3.8.2 Other attack and defense aspects of virtualization:
VMTools poisoning: Attackers tamper with or exploit vulnerabilities in virtual machine tools (such as VMware Tools) to execute malicious code or operations and disrupt the normal functions of the virtual machine.
NAS system storage virtualization attacks: In a network-attached storage (NAS) virtualized environment, attackers may launch attacks against shared storage resources, destroying data integrity or availability. Example: "Using the Cloud Attack Surface to Invade Any NAS Device" in Blackhat 2023. By analyzing the vulnerabilities of two NAS devices, Innolux and Western Digital, the attacker discovered a vulnerability that lacked device access verification and could be bypassed. With the team's discovery of unauthorized access to GUIDs and arbitrary command execution vulnerabilities on millions of NAS machines open in the cloud, attackers can remotely invade these NAS devices, causing serious security risks.
Vmvare vSphere Offense and Defense, KVM, XEN, Vmware Esxi, Rhev Hypervisor, Hyper-v Server VirtualBox Paralles Desktop: Perform batch use case testing on different hypervisors such as Vmware vSphere, KVM, XEN, Vmware Esxi, Rhev Hypervisor, Hyper-V Server, VirtualBox, Parallels Desktop, etc. to discover platform-specific security vulnerabilities and flaws.
Hardware virtualization attack and defense: In hardware virtualization technology, attackers may exploit vulnerabilities in hardware-assisted virtualization functions (such as Intel VT-x, AMD-V) to perform attacks, affecting the security of the virtualized environment.
OpenStack attack and defense: For OpenStack, an open source cloud computing platform, attackers may explore APIs, configuration errors, or interaction vulnerabilities between components to achieve unauthorized access to or interfere with cloud resources.
3.9 Terreform attack surface
Terraform can call the cloud vendor's AK/SK to create and obtain cloud service resources. Tecent-Terreform-yaml supports local-exec parameter execution command permissions, etc. If the parameters are controllable, we can use this account to execute our malicious code. For details, see YAML as shown below:
3.10 Summary:
Based on the above attack surfaces and methods, cloud security defense strategies need to comprehensively consider aspects such as the reinforcement of authentication mechanisms, the principle of minimizing permissions, security monitoring and response, supply chain security, and security reinforcement of containers and virtualized environments. Specifically include but not limited to:
Reinforce authentication mechanism: Strengthen the protection of sensitive information such as AK/SK, implement multi-factor authentication, etc. This can be achieved through IDaaS and access control RAM/IAM.
Implement permission minimization: Refined permission management to ensure that each service and user only has the minimum permissions required to complete its tasks. This can be achieved through services such as CIEM (Cloud Infrastructure Entity Management) and CASB (Cloud Access Security Broker).
Security monitoring and response: Establish a comprehensive monitoring system to conduct real-time monitoring and rapid response to abnormal behaviors. Servers, virtual machines, containers and other workloads can be protected through real-time monitoring and security policy management through services such as CWPP (Cloud Workload Protection Platform).
Supply chain security: Strengthen the audit and management of third-party components to ensure the security of the CI/CD process. Here, IAC scanning can be used to detect security issues in cloud code and configuration files. For example, in the CI/CD process, Terraform, CloudFormation, and Kubernetes configurations are reviewed to ensure the security of third-party components.
Container and virtualization security hardening: Take measures to prevent container escape and the exploitation of virtualization technology vulnerabilities. Container scanning and virtualization technology monitoring can be used for protection here.
In addition, in the cloud computing environment, the security responsibility sharing model is a framework for sharing security responsibilities between cloud service providers (CSP) and cloud service users (customers). This model clarifies which security measures are the responsibility of the cloud service provider and which need to be implemented by the user. Understanding this model is critical to ensuring the security of your cloud environment. Cloud service providers are mainly responsible for protecting the security of cloud computing infrastructure, which includes but is not limited to: physical security, network security, hardware and software infrastructure, virtualization security, operational security, etc. Users' responsibilities mainly focus on the security of their own data and applications deployed on the cloud, including: data security, access control, operational security, monitoring and response.
Then I will discuss with you some existing services and methods on the defense side.
0x4 Defense
Cloud security products at this stage reflect the increasingly complex and diverse security requirements of cloud computing environments. Their designs and functions reflect the trend of comprehensive protection of cloud workloads, cross-platform integration capabilities, and automated security operations and maintenance. The following are some comprehensive features shared by these cloud security products: full life cycle protection, automated security operation and maintenance, comprehensive security protection capabilities, compliance and regulatory support, real-time monitoring and early warning, and multi-level security strategies. The following is an introduction to relevant elements based on different defense perspectives on cloud security products.
(PS: This is just my personal experience on cloud native defense. There are still many defense perspectives to be added, and teachers need to consider and provide guidance.)
4.1 Basic defense
4.1.1 Mitigation method based on responsibility sharing model
Picture taken from: Microsoft's "Responsibility Sharing Model in the Cloud"
Strengthen cooperation: Cloud service users should make full use of the security tools and services provided by cloud service providers, such as AWS's CloudTrail, Azure's Security Center, etc., to strengthen security monitoring and incident response capabilities.
Regular security assessment: Users should conduct regular security assessments, including penetration testing and vulnerability scanning, to discover and fix potential security vulnerabilities.
Data encryption: Users should encrypt data stored on the cloud and use security protocols such as SSL/TLS for data transmission.
Multi-factor authentication: Implement multi-factor authentication (MFA) to increase account security.
Security awareness training: Train employees on cloud security best practices and increase awareness of social engineering attacks such as phishing attacks.
Follow security standards and compliance: Comply with industry security standards (such as ISO 27001, GDPR) and cloud security best practices.
4.1.2 Key Defense
Adapted from: Alibaba Cloud-AK and account secret leakage prevention best practices
Leak prevention level: Choose time-sensitive temporary tokens for product use. Major platforms add AK/SK feature detection rules, such as Github’s token-scan function, to automatically detect AccessKeys leaked on Github efficiently and accurately.
AK leak detection: Similar to Chrome's browser key detection, it uses the intelligence collected by the platform itself to match the rules to see if the AK is leaked to the public network.
Hacker utilization detection: When hackers use AK/SK to carry out abnormal behavior attacks, such as "creating cloud functions to execute malicious code", feature matching is performed, and a scoring mechanism is used to detect.
4.1.3 Severless protection:
Severless-WAF (AWS service combines WAF with API Gateway to provide protection by defining WAF rules through AWS CloudFormation templates. In addition, Imperva's Serverless Protection provides an additional layer of protection that can be deployed through the AWS Lambda layer to achieve WAF-like effects)
4.1.4 IAC scan:
(During the construction of Terraform, CloudFormation, Kubernetes, Serverless Framework and other infrastructure, if you need to configure YAML files, you can detect cloud code security issues based on string matching and other functions.) IAC scanning often includes IAC code scanning of various public clouds, code scanning of Kubernetes Mainfest, Dockerfile and other files. Unsafe configuration items are found in the files and users are reminded to repair them. Since IAC files often adopt a declarative method and the coding method is relatively fixed, it goes further than traditional code scanning and can effectively detect during the construction of container security and cloud security-related applications. Therefore, major manufacturers such as Paloalto provide one-click repair function of IAC code.
Open source IAC scanning tool Checkov
4.1.5 Container scanning and image vulnerability scanning:
Container scanning is a security practice used to identify vulnerabilities and configuration issues in container images to ensure the security of containerized applications. This process is crucial to cloud security. For example, image vulnerability detection is applied in the CI/CD link in DevSecOps because it helps prevent malware or attackers from using these vulnerabilities to attack cloud infrastructure.
Adopting key defense methods can effectively detect attacks such as AK/SK exploitation and Terriform exploitation or the leakage of related keys.
4.2 Comprehensive platform
4.2.1 CSPM (Cloud Security Posture Management):
Continuously monitor and evaluate the cloud environment through automated tools to ensure the security and compliance of cloud configurations, and promptly discover and repair configuration errors. CSPM is becoming increasingly integrated. For example, Paloalt-CSPM uses machine learning-enhanced threat detection, network threat detection, and user entity behavior analysis (UEBA) to supplement traditional security strategies and improve the efficiency of threat discovery. Ultimately, by integrating data security functions, CSPM provides enterprises with a comprehensive solution to protect against Kubernets attacks, CI/CD attacks, and cloud domain attacks to deal with complex security challenges in cloud-native environments.
This picture is taken from Palo Alto Networks - Security Compliance Perspective
This picture is taken from Palo Alto Networks - Security Manager Supervision Perspective
4.2.2 CWPP (Cloud Workload Protection Platform):
CWPP usually includes a variety of security functions and tools, such as firewalls, intrusion detection systems (IDS), intrusion prevention systems (IPS), endpoint detection and response (EDR) tools, etc., all to build a comprehensive security line of defense in the cloud computing environment. Through this layered security strategy, enterprises can fight against various network attacks and insider threats from the infrastructure to the application layer, ensuring business continuity and data confidentiality. It is designed to protect workloads such as servers, virtual machines, and containers in the cloud and reduce security threats through real-time monitoring and security policy management.
As can be seen from the figure, CWPP adopts a layered defense strategy:
Infrastructure protection layer: This layer focuses on basic network and host-level security, usually involving network segmentation, host baseline security configuration, virtualization platform security control, and system vulnerability management. This layer of security is designed to prevent unauthorized access and reduce the attack surface for operating system and physical hardware vulnerabilities.
Platform protection layer: Focuses on the security of containerization and service orchestration frameworks such as Kubernetes. At this layer, security practices include container image scanning, container runtime security, and access control and configuration management of orchestration systems.
Application and data protection layer: This layer focuses on application code security and data protection. This involves security auditing at the application layer, such as code static analysis and dynamic analysis, as well as data encryption and key management strategies to ensure the confidentiality and integrity of sensitive data.
Identity and Access Management: This is the top layer and involves user authentication, authorization, and auditing. It includes multi-factor authentication, role-based access control (RBAC), and the principle of privilege minimization to ensure that only necessary and authorized operations can be performed.
When implementing a CWPP policy, organizations usually integrate a series of security tools and services, as follows:
Endpoint Detection and Response (EDR): Monitors and responds to threat activity on endpoint devices.
Host Intrusion Prevention System (HIPS): Protects against unauthorized or malicious behavior at the host level.
Security Information and Event Management (SIEM): Collect, analyze and report security-related data for centralized visibility and incident response.
Configuration management and vulnerability assessment: Continuously monitor configuration changes and potential security vulnerabilities.
Network traffic analysis and firewall: used to detect abnormal network traffic and restrict network access.
API Security and Web Application Firewall (WAF): Protect APIs and web applications from attacks.
The figure shows the multi-layered protection mechanisms from infrastructure to data and applications from bottom to top, as well as the relationships between them. At the bottom of the diagram is the infrastructure layer, which contains physical devices and virtualization layers. In this layer, security measures include, but are not limited to, network isolation, host protection, operating system security, and protection of virtualized infrastructure. Next is the platform layer, which involves the security of containers and orchestration tools, such as Kubernetes security policy and container security. The next layer up is the application and data layer, where security measures focus on protecting data stored in the cloud, as well as ensuring the security of application code, including API security and performing data encryption. The top layer is user identity and access management, which is an important mechanism to ensure that only authorized users can access and manage cloud resources.
The entire structure is flanked by levels of risk, gradually rising from lower risk at the bottom to high risk at the top. This means that as you move from the infrastructure to the data layer, the threats to combat become more complex, and the need for security measures increases accordingly.
4.2.3 CIEM (Cloud Infrastructure Entity Management):
Focus on identifying and managing identities and access rights in cloud environments to ensure the principle of least privilege and prevent risks caused by inappropriate access. With CIEM solutions, security teams can manage cloud identity, authorization, and enforce the principle of least privilege access to cloud infrastructure and resources. CIEM solutions help enterprises reduce their cloud attack surface and reduce the risk of access caused by excessive permissions.
This diagram shows the conceptual architecture of a Cloud Infrastructure Entitlement Management (CIEM) system. Starting from "NEW IDENTITIES" on the left, different types of new identities (such as users, service accounts, etc.) gain access to different cloud service resources through a centralized authentication and permission allocation system.
The center of this system is a permission data storage and processing service, responsible for authentication and permission distribution. It connects to multiple cloud services such as storage, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), mirrors, and databases, each connected to the hub through multiple wires representing different access rights. Different colored lines in the diagram represent different levels of access, or different types of permissions, illustrating how the system precisely manages and audits permissions for each identity. This reflects the functions of permission discovery, optimization, anomaly detection and policy management in the CIEM system. Through such a system, organizations can ensure that each identity has only the minimum permissions it needs to perform its tasks, helping to reduce security risks and ensure compliance.
4.2.4 CASB (Cloud Access Security Broker)
CASB covers three areas: SaaS, PaaS, and IaaS, but the main coverage area is reflected in SaaS. The core value of CASB is to solve four types of problems: deep visualization, data security, threat protection, and compliance.
Deep Visibility—CASB provides shadow IT discovery, a unified view of an organization’s cloud service landscape, and detailed information about users accessing data in cloud services from any device or location.
Data Security - CASB can implement data-centric security policies to prevent harmful activities based on data classification, data discovery, and monitoring of user activities such as access to sensitive data or escalation of privileges. Policies are typically enforced through controls such as auditing, alerting, blocking, quarantine, deletion, and read-only. DLP (Data Loss Prevention) capabilities are common and are the single most used control after visualization.
Threat Protection - CASB prevents harmful devices, users and application versions from accessing cloud services by providing AAC. Cloud application functionality can be changed based on signals observed during and after login. Other examples of such CASB capabilities include identification of anomalous behavior through embedded UEBA, threat intelligence, network sandboxing, and malware identification and mitigation.
Compliance - CASB can help organizations demonstrate that they are managing the use of cloud services. CASB provides information to determine cloud risk appetite and determine cloud risk tolerance. Through a variety of visualization, control and reporting capabilities, CASB helps meet data residency and legal compliance requirements.
Cloud Access Security Broker (CASB) has two working modes: API mode and proxy mode. These two modes are common methods for protecting data in enterprise environments and achieving compliance management of cloud services.
API mode
In API mode, CASB monitors and controls data usage and security by directly integrating with the cloud service provider's API. Three different cloud services are shown here: BOX, Office 365 and Salesforce, all connected to CASB via API. In this mode, CASB can implement the following functions:
Data security: Monitor and protect data stored in cloud services, such as through data loss prevention (DLP) policies.
Threat Protection: Detect and prevent potential threats by analyzing user activity and configuration settings.
Compliance governance: Ensure the use of cloud services complies with industry standards and regulatory requirements, such as GDPR.
Identity management: Monitor and manage user identities and permissions to implement the principle of least privilege.
Visibility and reporting: Provides detailed reporting on data access and user activity.
proxy mode
In proxy mode, CASB acts as an intermediary between users and cloud services. All traffic passes through CASB's proxy servers, which allows CASB to enforce real-time data security and compliance policies. Unlike API mode, proxy mode can control real-time conversations and transactions, so it can provide:
Real-time data and threat protection: Prevent data breaches and immediate threats by intercepting and analyzing data in transit.
Access control: Enforce access policies based on the user's role and context, such as restricting access from untrusted devices.
Encryption and tagging: Encrypt data before transmitting it to the cloud service, or tag sensitive data.
Visibility: Provides visibility into all traffic passing through CASB proxies to monitor and analyze user behavior.
Data and application firewall: Acts as a security barrier to protect internal networks from external threats.
It can also be seen in this diagram that different types of devices (mobile and enterprise) can be integrated with CASB through both modes, ensuring that data is protected both inside and outside the enterprise.
summary:
After understanding various cloud security technologies (such as CSPM, CWPP, CIEM, CASB), we have clarified their unique roles in cloud environment security protection. These technologies cover multiple levels from cloud configuration, workload protection, identity management to access control, providing enterprises with a comprehensive protection system. However, Party A still faces many challenges when implementing these security strategies, mainly focusing on resource consumption of continuous monitoring, protection of diverse attack surfaces, security assurance of internal resources, and high security operation costs.
0x5 Zhiqianyun security effectiveness verification measures
As above, we have learned about the various attack surfaces and defense perspectives related to cloud security and container security. So how do we improve our security capabilities to detect, intercept, and provide emergency services to these attacks in a timely manner? Participating in internal organizational drills is a good method, but it will consume a lot of manpower, energy, and time costs, and may even cause damage to internal resources or systems. So how can we conduct attacks without affecting business and security and verify these attacks to reduce security operation costs and improve security operation capabilities? At this time, security effectiveness verification came into being. The sub-module of security effectiveness verification, BAS, uses its unique simulated attack and verification technology to verify various cloud security scenarios. It also provides round-the-clock automated assessment and self-inspection functions and provides security reinforcement recommendations to ensure the efficient operation of the security defense system.
The verification of BAS in a cloud environment usually involves several key steps and strategies, which can be divided into the following points:
Virtual attack:
Attack method: Use BAS tools to simulate various attacks, such as application vulnerability exploitation, Web Shell upload, malware download, etc.
Product Correspondence: Use LiZhu-Security Verification Platform to simulate these attacks and test your organization’s defense capabilities.
Infiltration:
Attack method: Application vulnerability transmission, Web Shell transmission and malware downloading through the Internet.
Product correspondence: Li Zhu-Security Verification Platform can simulate these attacks to verify the effectiveness of firewalls, intrusion detection and defense systems in cloud environments.
Server Zone:
Attack methods: including Docker escape, file system bypass, resource abuse, system information collection, secret/credential theft, etc.
Product correspondence: Li Zhu-security verification platform can perform simulated attacks on these areas to test the security of the cloud infrastructure and whether the relevant security controls are configured correctly.
Lateral Movement:
Attack methods: including brute force cracking, malware propagation, local exploitation of vulnerabilities, remote control, network information collection, etc.
Product correspondence: Li Zhu-Security Verification Platform can simulate these attacks to verify the effectiveness of network isolation and internal security controls.
Data Exfiltration:
Attack method: Data leakage through legal channels and covert channels.
Product correspondence: Lizhu-security verification platform can test data leakage prevention measures to ensure that sensitive data will not be accessed without authorization through network transmission.
Attack route simulation
Attack method: The focus is on obtaining high-value assets and data after lateral movement.
Product correspondence: Use LiZhu-security verification platform to simulate the attacker's action route to verify the protection of the most sensitive and critical resources.
Based on many years of experience in Party A's security attack and defense by the team's leaders, verification scenarios are distinguished from different security perspectives, such as terminal security, host security, and container security. Then distinguish various attack methods from different attack perspectives, such as brute force cracking scenarios and cloud security key leakage scenarios. Finally, the label granularity of a single use case is distinguished from different attack points and verification methods, such as container escape. To put it simply: "A scenario is a verification topic, which is a collection of use cases that answer "How well is the protection capability of a certain piece of technology?"
The following scenarios are currently online:
5.1 Container Security Matrix
The MITER ATT&CK Matrix for Containers provides a comprehensive overview of behavioral patterns and techniques used by malware attackers to exploit container (such as Docker and Kubernetes) environments. This matrix is designed to help security professionals better understand and defend against attacks in container environments. Although I can't provide the latest content, here are some of the key areas that the ATT&CK matrix typically covers for container environments based on my last updated knowledge (as of April 2023):
Initial access: Describes how an attacker could gain initial access to a container environment, possibly through means such as exploiting a public service, phishing attack, or using a valid account.
Execution: Techniques involving attackers executing malicious code within a container environment, including direct code execution, script exploitation, or exploiting characteristics of the container itself to perform malicious actions.
Persistence: Describes how attackers maintain their presence in a container environment, possibly by modifying container configurations, creating new or malicious container images, etc.
Privilege Escalation: Techniques covering how an attacker can escalate from their initial access point to a higher privilege level, which may include exploiting container escape vulnerabilities, exploiting system vulnerabilities, etc.
Defense bypass: includes measures taken by attackers to avoid detection by security tools or monitoring measures, such as modifying container images to hide malware, utilizing encryption or obfuscation techniques, etc.
Beacons: A technique that involves an attacker communicating with an external server or control system to take control of a compromised container or transfer data.
Information collection: Describes how an attacker collects information in a container environment, which may include searching for sensitive files, collecting configuration information, or enumerating network resources.
Lateral movement: Involves how attackers move within a container environment or between external systems to expand their attack scope, possibly by exploiting network connections, stealing credentials, etc.
Impact: Describe how the attacker affected the container environment, including data destruction, service interruption, or resource abuse.
Retrieved from: MATRICES Container Security Matrix Diagram
Zhiqian has covered 85% of relevant use cases in scenarios such as initial access, execution, permission maintenance, privilege escalation, defense avoidance, credential access, discovery, lateral movement, and impact in the container ATT&CK matrix. Since many scenarios have their own unique hazards, defense methods, and implementation methods, we will provide customized development methods for various scenarios and use cases while minimizing code refactoring (reducing resource consumption).
The following is an example of the container privilege escalation vulnerability CVE-2024-1086, which was discovered at the end of March 2024. This vulnerability is a double release vulnerability in the sub-function of Linux's Netfilter network kernel control, which allows for privilege escalation. Due to the popularity of Netfiler, this vulnerability affects most high-version kernels (v5.14 – v6.6). Its feature is to add a session channel to the process file to elevate the privileges for the current window.
We will use an automated method to start the recurrence environment, perform privilege escalation simulation behavior in the environment, and automatically verify the detection capabilities of the security capability device based on the results of this simulation behavior. By starting the simulation environment, we can not only solve the problem that the vulnerability environment may not exist on the host machine, but also ensure that the entire processing process is harmless. In addition, we also solved the issue in CVE-2024-1086 that caused session instability due to the network environment (such as ssh or rebound shell) when netfiler escalates privileges. Finally, the relevant effects are cleaned up and the closed loop is completed through the agent's automatic deletion of the container and the agent's automatic cleaning process.
There are also use cases such as CVE-2024-21626. After the vulnerability was exposed, we responded quickly, not only completed the internal implementation, but also investigated a variety of development solutions. We have simultaneously developed and launched two types of use cases, namely the Docker version and the Kubernetes version for simulating and verifying the exploit, to support users in conducting security testing in different environments. Detailed vulnerability information and verification information are given: In the affected RunC version, some internal file descriptors are leaked during the initialization process, including the handle to the host's /sys/fs/cgroup. At the same time, RunC failed to properly verify that the directory was within the container's mount namespace when setting the container's final working directory. An attacker can modify the process.cwd configuration item to /proc/self/fd/7, or pass a specific path (such as a symbolic link to /proc/self/fd/7/) through the --cwd parameter when calling runc exec, so that the process in the container can access and operate the host's file system. This operation bypasses the container's isolation mechanism, allowing attackers to execute unauthorized commands or access sensitive information, causing security isolation to be breached.
We will customize and develop a lightweight container with this vulnerability, and use the principle of the vulnerability itself to directly verify whether we have successfully exploited the escape vulnerability. Finally, the relevant impacts are cleaned up through the agent's automated deletion of containers and agent's automated cleanup process. And provide relevant security capability points that can be enhanced.
5.2 Kubernetes Matrix
The Kubernetes ATT&CK Matrix is inspired by the MITER ATT&CK framework and specifically classifies security threats and attack methods in the Kubernetes environment. It provides security researchers, system administrators, and security teams with a reference framework for identifying and defending against potential attacks against Kubernetes clusters.
The Kubernetes attack matrix covers attack techniques at different stages from initial access to execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, etc. Here is an overview of some of the main content:
Initial access: How an attacker gains initial access to a Kubernetes cluster, such as through an exposed unauthenticated Kubernetes API server, exploiting weak or default credentials, through phishing attacks, etc.
Execution: How an attacker can execute malicious code or commands within a Kubernetes cluster after gaining access to the cluster.
Persistence: How an attacker maintains access to the cluster, for example by creating or hijacking Kubernetes resources (such as Deployments, Pods, CronJobs) to ensure that malicious payloads can still execute after system restarts.
Privilege escalation: How an attacker can escalate his or her privileges in a cluster, such as by exploiting vulnerabilities or misconfigurations in a Kubernetes cluster.
Defense evasion: How attackers circumvent security mechanisms in the cluster, such as modifying log files to hide their activity, or disabling security plug-ins.
Credential access: How attackers access and steal Kubernetes cluster authentication information, such as API keys, service account tokens, etc.
Discovery: How an attacker can explore and identify the architecture of a Kubernetes cluster and the applications running after gaining access to the cluster.
Lateral movement: How an attacker moves from one resource to another, such as from one infected Pod to access other Pods or services.
Collection: How an attacker collects and extracts targeted data or information, such as sensitive files or data from a Kubernetes cluster.
Command and Control (C2): How attackers control and manage malware deployed in a Kubernetes cluster, such as communicating with malicious pods through external servers.
Impact: Describe how an attacker could achieve their goals through disruption, data exfiltration, or control of cluster resources.
Taken from: MATRICES Kubernetes matrix diagram
Zhiqian has covered the initial access, execution, permission maintenance, privilege escalation, defense avoidance, credential access, discovery, lateral movement, impact and other scenarios in the Microsoft Kubernetes cloud ATT&CK matrix. Since many scenarios have their own unique hazards, defense methods, and implementation methods, we will provide customized development methods for various scenarios and use cases while minimizing code refactoring (reducing resource consumption).
The following is an example of a typical Kubernetes escape vulnerability, CVE-2021-25741, which exploits Symlink's link symbol exchange vulnerability to mount host container directories and other attacks. This vulnerability is difficult to exploit and requires creating a race condition attack to bypass the repair patch of the previous version.
Therefore, we will start the reproduction environment in an automated way and perform privilege escalation simulation behavior in it. In order to verify the detection capability of security-capable devices, we will evaluate the escape situation by determining whether the host file is successfully mounted. Starting the simulation environment not only solves the problem that the host machine may not have the vulnerability environment, but also ensures that the entire process is harmless. In addition, we also solved the problem of difficulty in verifying escape due to too long conditional competition time during the exploitation process. Finally, we will use agents to automatically delete pods and clean up processes to thoroughly clean up related impacts. At the same time, we will also provide enhanced security capability points to further improve the system’s security protection level.
5.3 ATT&CK Cloud Matrix
The MITER ATT&CK Cloud Matrix is an expansion of attack behavior patterns targeting cloud environments (including Infrastructure as a Service IaaS, Platform as a Service PaaS, and Software as a Service SaaS). It provides a series of attack techniques and tactics targeting cloud platforms. This matrix covers techniques from initial access to execution, persistence, privilege escalation, defense bypass, credential access, discovery, lateral movement, collection, command and control, and impact. The Cloud Matrix specifically highlights the unique attack vectors and tactics that may be encountered in a cloud environment.
Here are some key attack scenarios in the cloud matrix:
Exploiting cloud service misconfigurations: Attackers may exploit cloud service misconfigurations (for example, misconfigured buckets or databases) to gain unauthorized access to data or disclose sensitive information.
Credential access and abuse: Cloud environments rely on complex credential management systems, and attackers may attempt to obtain these credentials to gain access to cloud resources or leverage legitimate credentials for cloud services for lateral movement.
Leverage cloud-native technologies: Attackers may target vulnerabilities or misconfigurations in container management systems (such as Kubernetes) or serverless architectures (such as AWS Lambda).
Creation and abuse of resources: An attacker may create malicious resources, such as virtual machines, containers, or functions, in a cloud environment to perform offensive activities or serve as a springboard for further attacks.
Cross-tenant attacks: In a multi-tenant cloud environment, attackers may try to escalate privileges or steal data from other tenants.
Metadata service abuse: Metadata services of cloud services contain rich environmental information and credentials. Attackers may try to access these services to escalate privileges or obtain sensitive information.
API Abuse: Since cloud environments rely heavily on APIs for operation and management, attackers may exploit insecure APIs to perform unauthorized operations or obtain sensitive data.
Taken from: MATRICES ATT&CK cloud matrix diagram
Zhiqian has covered scenarios such as initial access, execution, permission maintenance, privilege escalation, defense avoidance, credential access, discovery, lateral movement, and impact in the Microsoft ATT&CK cloud matrix. Since many scenarios have their own unique hazards, defense methods, and implementation methods, we will provide customized development methods for various scenarios and use cases while minimizing code refactoring (reducing resource consumption). The following introduces use cases such as using cloud functions to execute dangerous command attacks.
Li Zhu-security verification platform will have the following implementation logic: (SupportAttack chain perspectiveandDirect use of perspective)
Deploy malicious function:
If an attacker controls customer accounts or permissions, they can deploy malicious Lambda functions.
These functions may avoid cloud platform management and operating system and network configuration security measures because they work at the application level.
Malicious functions may perform dangerous operations on cloud storage and database resources, such as deleting data or stealing information.
Trigger execution:
Malicious functions can be executed via Internet access, event triggers, or direct calls.
For example, if an attacker can upload a file to a cloud storage bucket, the upload of the file can trigger the execution of a Lambda function.
Verification closed loop:
At this time, BAS will check network logs, API call records, etc. to verify whether the attack is successful.
Cleanup phase:
Remove the malicious function and the required associated new roles.
And restore any temporarily increased permission settings.
0x6 Summary
The diversity of cloud security attack surfaces requires enterprises to adopt a comprehensive defense strategy. Attack scenarios such as AK/SK exploitation, Kubernetes attacks, Etcd violations, CI/CD process attacks, Docker Swarm vulnerabilities, eBPF container escapes and virtualization platform vulnerabilities show the complexity of attack and defense. BAS can effectively detect, intercept and respond to security threats without affecting business and security. The BAS module of Lizhu-security verification platform can be used to simulate cloud functions to execute dangerous command attacks and verify the effectiveness of protective measures in security tests. This practice not only reduces security operation costs, but also improves security operation capabilities, providing strong support for the formulation and execution of enterprise cloud security strategies.
0x7 reference link
Cloud native security attack and defense｜Analysis and practice of using eBPF to escape container technology
Everyone Shows Their Talents - "IDC Technology Assessment: Cloud Infrastructure Technology Capability Assessment, 2023" report released
Implementation principle of highly available distributed storage etcd
Wiz: Kubernetes security situation analysis
Key Takeaways from the 2023 Kubernetes Security Report | Wiz Blog
New Class of CI/CD Attacks Could Have Led to PyTorch Supply Chain Compromise
AzureAD-Attack-Defense
Cross Container Attacks: The Bewildered eBPF on Clouds
https://landscape.cncf.io/?group=projects-and-products&view-mode=grid
Key Takeaways from the 2023 Kubernetes Security Report | Wiz Blog
https://www.securityweek.com/new-class-of-ci-cd-attacks-could-have-led-to-pytorch-supply-chain-compromise/
https://github.com/Cloud-Architekt/AzureAD-Attack-Defense/blob/main/ReplayOfPrimaryRefreshToken.md
https://www.blackhat.com/html/webcast/05162024.html
https://www.bilibili.com/video/BV1QH4y1W7Jd/
https://lonegunmanb.github.io/introduction-terraform/
https://attack.mitre.org/matrices/enterprise/containers/
Comments (0)
Login to post a comment.