Save Your Cloud: XSS in OpenStack Dashboard
Maximizing the effectiveness of compute power using an Infrastructure-as-a-Service (IaaS) cloud service is a common technique nowadays. Private (IaaS) clouds are often advertised as being more secure as public ones, simply because they are "provisioned for exclusive use by a single organization" (source). However, private and public clouds share the same technology; there is no fundamental difference in the techniques employed.
Differences between private and public clouds must therefore be defined through properties of the setup itself. The main difference is in the reachability of Cloud Control Interfaces (CCI): In a private cloud, access to a CCI may be limited through network perimeter controls (e.g. firewalls, NAT, VLANs), whereas in a public cloud it may not. Perimeter controls applied to other components of a cloud do not influence this definition, regardless if a cloud is public or private.
Virtually all Cloud Management Platforms (CMPs) on the market offer a web interface as CCI to control the virtual machines, and these web interfaces increasingly use novel HTML5 features. Other CCIs process XML based requests and therefore act as web-services.
In a series of blogposts labeled Save Your Cloud, we will explain how bugs we found in these rich interfaces can be exploited to gain control on a private cloud, including the data stored and processed in that cloud. Other bugs we found allow you to perform a Denial-of-Service (DoS) attack on a virtual machine or a CMP making these unavailable to users and admins.
The only prerequisite of an attack is that the victim must visit a (malicious) webpage of the attacker. In case of a private cloud, the URL of the CCI must also be known to the attacker (for public clouds, it is known to the public.) The URL can e.g. be retrieved by reading company documentation, emails, or public discussion forums. The attacker does not need to be able to resolve the CCI's domain name; the only requirement is that the browser of the victim is able to resolve it. No further control over the network is assumed; especially firewalls, network encryption, and other standard protection mechanisms may be deployed.
As part of our responsible research strategy, we informed all vendors of vulnerable CMPs and proposed mitigations. All bugs described here have been fixed by now and we strongly recommend using the latest releases.
After this short introduction, let's have a look on an XSS bug we found in OpenStack.
Our security tests showed that Horizon is robust and provides no attack-surface via content reflected from user-controlled GET parameters. The majority of data that a user can enter will be stored and reflected safely. This means, that a user can enter critical characters but upon displaying the result as part of the HTML of the OpenStack Management Interface, the data is encoded and escaped properly and no XSS attacks are possible. Therefore, we were not able to find an attack if OpenStack is used to set up a public cloud.
We did however identify a field where no adequate escaping is used. With this interface injecting persistent XSS payload such as the string <svg onload=alert(1)> was possible. The vulnerability resided in the interface where Host Aggregates could be created (see Figure 3). This interface is only available to administrators; thus, only an administrator could attack other administrators with it. For this reason, we think this XSS is not exploitable in practice.
There is a security advisory for this bug. It was filed under CVE-2014-3594 and affects the following versions of OpenStack Dashboard (Horizon):
Differences between private and public clouds must therefore be defined through properties of the setup itself. The main difference is in the reachability of Cloud Control Interfaces (CCI): In a private cloud, access to a CCI may be limited through network perimeter controls (e.g. firewalls, NAT, VLANs), whereas in a public cloud it may not. Perimeter controls applied to other components of a cloud do not influence this definition, regardless if a cloud is public or private.
 |
| Figure 1: In a private cloud, the CCI may be protected by network perimeters. |
Virtually all Cloud Management Platforms (CMPs) on the market offer a web interface as CCI to control the virtual machines, and these web interfaces increasingly use novel HTML5 features. Other CCIs process XML based requests and therefore act as web-services.
In a series of blogposts labeled Save Your Cloud, we will explain how bugs we found in these rich interfaces can be exploited to gain control on a private cloud, including the data stored and processed in that cloud. Other bugs we found allow you to perform a Denial-of-Service (DoS) attack on a virtual machine or a CMP making these unavailable to users and admins.
The only prerequisite of an attack is that the victim must visit a (malicious) webpage of the attacker. In case of a private cloud, the URL of the CCI must also be known to the attacker (for public clouds, it is known to the public.) The URL can e.g. be retrieved by reading company documentation, emails, or public discussion forums. The attacker does not need to be able to resolve the CCI's domain name; the only requirement is that the browser of the victim is able to resolve it. No further control over the network is assumed; especially firewalls, network encryption, and other standard protection mechanisms may be deployed.
As part of our responsible research strategy, we informed all vendors of vulnerable CMPs and proposed mitigations. All bugs described here have been fixed by now and we strongly recommend using the latest releases.
After this short introduction, let's have a look on an XSS bug we found in OpenStack.
Persistent XSS in OpenStack Dashboard (Horizon)
The OpenStack project seeks to offer an alternative to Amazon Web Services (AWS) and sees itself in direct competition. OpenStack tries to provide as much compatibility to Amazon's external interfaces as possible. It uses a modular architecture approach to support scalability as well as a broad variety of hypervisors, storage systems, network infrastructures, etc. The module that is primarily viewed at in this research is OpenStack Dashboard (Horizon), OpenStack's web interface component (see Figure 2). OpenStack is available under Apache-2 license terms. |
| Figure 2: Screenshot of OpenStack Dashboard (Horizon) and it's functionality to control a VM. |
Our security tests showed that Horizon is robust and provides no attack-surface via content reflected from user-controlled GET parameters. The majority of data that a user can enter will be stored and reflected safely. This means, that a user can enter critical characters but upon displaying the result as part of the HTML of the OpenStack Management Interface, the data is encoded and escaped properly and no XSS attacks are possible. Therefore, we were not able to find an attack if OpenStack is used to set up a public cloud.
We did however identify a field where no adequate escaping is used. With this interface injecting persistent XSS payload such as the string <svg onload=alert(1)> was possible. The vulnerability resided in the interface where Host Aggregates could be created (see Figure 3). This interface is only available to administrators; thus, only an administrator could attack other administrators with it. For this reason, we think this XSS is not exploitable in practice.
 |
| Figure 3: The field Availability Zone is not being filtered properly. This input triggers XSS. |
There is a security advisory for this bug. It was filed under CVE-2014-3594 and affects the following versions of OpenStack Dashboard (Horizon):
- 2013.2 (Havana) before 2013.2.4
- 2014.1 (Icehouse) before 2014.1.2
- Development versions of Juno before Juno-3
0 Response to "Save Your Cloud: XSS in OpenStack Dashboard"
Post a Comment