In June, Wiz engineers discovered and reported #AttachMe, a major cloud isolation vulnerability in Oracle Cloud Infrastructure (OCI), prompting Oracle to patch the vulnerability within hours and without requiring customer action.
Potential impact—Before it was patched, all OCI customers could have been targeted by an attacker with knowledge of #AttachMe. Any unattached storage volume, or attached storage volumes allowing multi-attachment, could have been read from or written to as long as an attacker had its Oracle Cloud Identifier (OCID), allowing sensitive data to be exfiltrated or more destructive attacks to be initiated by executable file manipulation.
Remediation—Within 24 hours of being informed by Wiz, Oracle patched #AttachMe for all OCI customers. No customer action was required.
Key conclusions— Cloud tenant isolation is a key element in cloud. Customers expect that their data isn’t accessible by other customers. Yet, cloud isolation vulnerabilities break the walls between tenants. This highlights the crucial importance of proactive cloud vulnerability research, responsible disclosure, and public tracking of cloud vulnerabilities to cloud security.
#AttachMe is one of the most severe cloud vulnerabilities reported since it could have impacted all OCI customers. Cloud isolation vulnerabilities usually impact a specific cloud service. However, in this case, the impact is related to a core cloud service.
Wiz engineers found that attaching a disk to a VM in another account didn’t require any permissions. This means a potential attacker could have accessed and modified data from any OCI customer, and in some cases could have even taken over the environment.
The potential attack flow was simple:
Discover the ID (OCID) of a target victim's volume by searching the web or by using a low-privileged user permission to read the volume OCID from the victim's environment.
Initiate a compute instance in an attacker-controlled tenant located in the same Availability Domain (AD) as the target volume.
Attach the victim's volume to the attacker's compute instance, thereby gaining read/write privileges over the volume.
From there, a potential attacker could have performed numerous serious actions:
Exfiltrate sensitive data stored on the volume.
Search the volume for cleartext secrets in order to move laterally through the victim’s environment and/or escalate privileges.
Alter existing block volumes and boot volumes—e.g. by manipulating binaries—in order to gain code execution when the volumes were mounted on compute instances.
Oracle responded extraordinarily quickly when Wiz responsibly disclosed its discovery of #AttachMe. As an Oracle partner and customer, Wiz appreciates Oracle’s collaboration and rapid attention to this issue. Oracle thanked Wiz for discovering this vulnerability as part of its July 2022 Critical Patch Update Advisory.
While building the OCI connector for Wiz, our software engineers noticed that it was possible to attach almost all block volumes and boot volumes to a compute instance, given their Oracle Cloud Identifier (OCID), without explicit authorization. After more testing, we realized that this was even possible when the volume and compute instance resided in different OCI tenancies! This meant that an attacker could gain access to a volume in another tenant (as long as they knew the OCID), and whoever owned the volume (the victim) would be totally unaware that someone else had read/write access to their data, since the compute instance and attachment would be in the attacker’s tenancy.
As described in the OCI documentation, a volume is a virtual disk that provides persistent storage space for compute instances. There are two types of volumes in OCI:
Block volume—A detachable block storage device that allows you to dynamically expand the storage capacity of an instance.
Boot volume—A detachable boot volume device that contains the image used to boot a compute instance and is usually created upon compute instance creation.
OCI supports multi-attachment of block volumes, meaning you can attach a single volume to multiple instances at the same time using the shareable feature with read/write or read only permissions.
Attaching a boot or block volume to a compute instance from the CLI is straightforward, requiring only the volume and instance IDs:
oci compute volume-attachment attach --type paravirtualized --instance-id <instance_ocid> --volume-id <volume_ocid>
Based on the policy reference, the required permissions for AttachVolume are VOLUME_WRITE, VOLUME_ATTACHMENT_CREATE, and INSTANCE_ATTACH_VOLUME. The instance and the volume do not necessarily need to be in the same compartment.
Volume attachment is an OCI resource that resides in the compute instance’s compartment and describes an attachment of a volume to a compute instance. Permissions are applied to a compartment (and its compartment tree). Therefore, VOLUME_ATTACHMENT_CREATE and INSTANCE_ATTACH_VOLUME are required in the instance’s compartment scope (in this case, the attacker’s compartment) and VOLUME_WRITE is required in the volume’s compartment scope (the victim’s compartment).
However, as we discovered, there was a gap in the validation of the VOLUME_WRITE permission when attaching a volume, which made it possible to attach any volume without authorization. In addition, attachment was possible across different tenancies: we managed to attach a volume from one tenancy to a compute instance in another tenancy.
When an unauthorized user attempts to perform any operation on a volume, the service (correctly) returns an error indicating the user lacks the required permissions:
Figure 1: Attempting to access a volume using the CLI without sufficient permissions
However, before #AttachMe was remediated, attempting to attach a volume to a compute instance succeeded whether the user had sufficient permissions or not:
Figure 2: Successfully attaching the same volume that we did not have permissions to access
Once the volume was attached, we could view and modify its content.
The detailed requirements to exploit #AttachMe were:
The attacker must know the OCID of the target volume—While OCIDs are generally private, they are not treated as secrets, so this is easily achieved.
The attacker’s compute instance must be in the same Availability Domain (AD) as the target volume—This condition can be easily met as the number of availability zones is relatively small (up to three in some regions) and can therefore be enumerated.
The target volume must be either detached or attached as shareable—Detached volumes are relatively common because by default the boot volumes associated with terminated compute instances are not deleted. In addition, backup data volumes are often not attached to a running compute instance.
When an attacker gains read access to your volumes, the main risk is data breach. Volumes may contain sensitive information such as Personally Identifying Information (PII), secrets, and more.
Another risk is data manipulation and intrusion into your cloud network. Attaching a volume provides write access that could be used to manipulate any data on the volume, including the operating system runtime (by modifying binaries, for example), thus gaining code execution over the remote compute instance and a foothold in the victim's cloud environment, once the volume is used to boot a machine.
The potential attack paths include:
Privilege escalation within the Compartment or Tenancy—If an attacker managed to get initial access to a victim’s OCI environment, #AttachMe could have been exploited to further escalate privileges. An attacker would have been able to query all available volumes in the compartment to obtain their OCIDs, mount them, and read any sensitive information stored on them.
Cross-tenant access—A more impactful scenario is if an attacker managed to obtain OCIDs of volumes in a remote tenant. #AttachMe could have been used to gain initial access to the victim’s environment by reading sensitive information and long-lasting secrets that were stored in the target volumes. In addition, the attacker could have manipulated existing block volumes and boot volumes in a way that would provide the attacker code execution when the volumes were mounted on compute instances.
We consider both potential attack paths quite feasible given that OCIDs are generally not treated as secrets. Numerous OCIDs of both block volumes and boot volumes of various environments, including those of major companies, can be found via a simple online search.
It is also possible to find OCIDs of volumes that were published on GitHub, indicating that these IDs are indeed not treated as secrets by developers. Low-privileged users and third-party vendors with read access to the environment could obtain OCIDs very easily.
Upon discovering #AttachMe, we immediately disclosed our findings to Oracle, who investigated and fixed this issue in less than 24 hours. We were happy to collaborate with such a professional team.
June 6th, 2022—Wiz discovers the vulnerability
June 9th, 2022—Vulnerability reported to Oracle
June 10th, 2022—Oracle acknowledges report
June 10th, 2022—The vulnerability is fixed
Insufficient validation of user permissions is a common bug class among cloud service providers. The best way to identify such issues is by performing rigorous code reviews and comprehensive tests for each sensitive API in the development stage. Oracle shared with us that they use static code analysis technology to detect such problems already in development and investigate known and reported issues to ensure the problematic pattern does not recur elsewhere in the codebase.
We also recommend performing service-specific penetration tests and participating in bug bounty programs, as these have proven effective with these types of issues.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。