Direkt zum Hauptbereich

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.

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
This result is a collaborative work together with Mario Heiderich.

Beliebte Posts aus diesem Blog

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…