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

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT

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…