Save Your Cloud: Exploiting Eucalyptus 4.0.0 and 4.0.1

In a previous post of this series, we showed why a private cloud is not necessarily more secure than a public one and presented a vulnerability in OpenStack. This post focuses on XSS vulnerabilities we found in Eucalyptus, a well-known Cloud Management Platform. We also demonstrate an exploit for these vulnerabilities.

The Infrastructure-as-a-Service platform Eucalyptus emerged from a research project at the University of Santa Barbara and was commercialized in 2009 by Eucalyptus Systems Inc. Eucalyptus mimics Amazon Web Services (AWS), therefore Eucalyptus can manage either Amazon or Eucalyptus VMs.

VM instances can also be moved between the Amazon Elastic Compute Cloud and an Eucalyptus private cloud. Eucalyptus is being used by a wide range of commercial and academic clients, including defense contractors and institutions such as Raytheon and the US Department of Defense. Only the recent versions of Eucalyptus are fully open source (GPLv3); older versions used proprietary components such as support for certain hypervisors or network storage systems.

Architecturally, the web interface of Eucalyptus (see Figure 1) is interesting as it employs most modern JavaScript Model View Controller libraries to render the content that is being sent to the user's browser. This architectural aspect guarantees for a security model that is robust against XSS attacks as none of the user-controlled content is actually reflected but delivered from static data files and later being woven into static templates.

Figure 1: Eucalyptus Management Console with a VM and it's control options

Our security tests however showed, that this seemingly well-thought concept of rendering and securing user-controlled data was flawed because of a string reliance on the security promises the AngularJS library gives. AngularJS applications often mix user-controlled content into so-called AngularJS expressions. Those expressions execute a limited and scoped subset of JavaScript and are thought to be secure from injections.

The security of AngularJS expressions is built upon the AngularJS sandbox — a combination of a string-parser and several object checks that assure that the code to be executed does not violate any constraints and is considerably save to be evaluated. However, Eucalyptus 4.0.0 used an outdated and thus vulnerable version of AngularJS (v1.2.9). Based on a contribution by J. Horn, a bypass for this sandbox was tested against that AngularJS version. We found that the vulnerability of the AngularJS version in place was indeed exploitable. By injecting the following AngularJS expression an attacker can gain full control over the client-side code that is executed:

{{'abc'.sub.call.call(({})['constructor'].getOwnPropertyDescriptor(('abc').sub.__proto__,'constructor').value,0,'location=name')()}}

The expression essentially bypasses two different checks installed by the AngularJS sandbox and manages to get access to the JavaScript Function constructor — a function that in return accepts arbitrary strings to be executed in the global scope of the loaded document. This is being done by taking an arbitrary string, accessing one of its methods and accessing the call() method. Given the used parameters this returns the mentioned Function constructor. By indirectly accessing the constructor the sandbox is being bypassed, as it does not check return values. The returned Function constructor is then again called indirectly to avoid the sandbox checks a second time. The length restrictions the Eucalyptus platform imposes can be bypassed by using window.name to store the payload.

VM-Control & Privilege Escalation in Eucalyptus 4.0.0

Since the above sandbox bypass is a persistent XSS that has to be deployed manually, the attack is not applicable to a private cloud. However, if Eucalyptus is used to build a public cloud, attacks are possible. Once the attacker can execute arbitrary JavaScript code, it is possible to create new VMs as well as start or stop existing ones. Furthermore, a rogue user may inject the code in a data field that can also be read by an administrative user. If the user lures an administrator into opening a prepared page, the payload could add an admin policy to the user's account turning it into an administrative account as well. This way, a non-administrative user can illegitimately gain access to elevated privileges.

Steal Data from an Eucalyptus VM

Eucalyptus offers a feature to read the console output of a VM for debugging. One cannot send commands to a VM this way, but if the VM outputs sensitive information (e.g. content from config files or default login credentials) to the console, they can be stolen. We implemented a proof of concept exploit that demonstrates the attack. A video of the attack can be seen here:



There is a security advisory for this bug. It was filed under CVE-2013-4770. It has been fixed with Eucalyptus 4.0.1.

Expression Injection in Eucalyptus 4.0.1

With Eucalyptus 4.0.1, AngularJS has been updated to version 1.2.20. As an additional protection, '{{' in user input is replaced by '{ {' which defuses AngularJS expressions. However, we found out that this does not happen platform-wide. Some input field such as the name of a keypair remained unprotected. Using an AngularJS sandbox bypass discovered by Mathias Karlsson, we were again able to execute code in the context of the Management Console to e.g. perform the attack shown above. Since the name of a keypair is also used in URLs (like https://server/keypairs/[keyname]) the XSS can be used in a reflected way so that a private cloud setup could be attacked with it.

This vulnerability also has a corresponding security advisory and was filed under CVE-2014-5039. It has been fixed with Eucalyptus 4.0.2.

This result is a collaborative work together with Mario Heiderich.

Share on FacebookPlus on Google+

SUBSCRIBE MORE CONTENTS