How we breached a corporate network via Citrix XenMobile

During our adversary simulations we regularly find vulnerabilities in third-party applications used by our clients. Often these are well-known vulnerabilities that can be fixed by updating or reconfiguring the system, but sometimes they require some work by the third-party provider to produce a fix and an update.

Sometimes we find things that might not technically be vulnerabilities at all. For example, some systems include features that we can use in unexpected ways to compromise it.

In this post, we explain how we were able to exploit vulnerabilities in the Citrix XenMobile platform that allowed us to fully achieve the objective of our attack simulation. We’ll describe those objectives, which will give you some idea of what we were dealing with, and the nature of our client’s concerns.

All of the vulnerabilities discussed in this blog post were reported to Citrix, who at the time of writing have published updates to fix the ones they felt required action.

The objective

We were briefed to gain access to confidential personal data about vulnerable individuals held by our client.

We were asked to run a covert, blackbox simulation. In a covert simulation, we’re required to try to achieve the objective without anyone in the client organisation knowing or noticing what we’re doing. In blackbox simulations we’re given very little information about the client’s systems. All we could see was what anyone on the internet could find.

Why XenMobile?

We began by discreetly scanning the organisation’s externally-facing domains to identify a service that might allow us in. This was when we discovered the client used Citrix XenMobile for managing employee mobile devices. XenMobile allows organisations to manage large numbers of mobile devices, controlling installed apps and ensuring that updates and security settings are applied.

XenMobile wasn’t the only service we identified from outside the network, so why target it?

First, we knew that XenMobile is a large and complicated application with many ways for other applications or devices to talk to it. It was quite likely that it would be configured with multiple access points. In general, the bigger and more complicated a piece of software is, the more likely it is to contain vulnerabilities.

Second, we knew that XenMobile’s functionality would allow us to achieve our objectives, if we were able to gain control over it. For example, it has a feature that allows the silent installation of apps to all connected mobile devices, without the authorisation of the devices’ users and without notifying administrators.

What did we do?

We set up an instance of XenMobile on one of our own virtual machines, and began analysing its behaviour. By running it on our own infrastructure, we could perform tests that would be detected easily if we ran them on the actual target system.

We found lots of lovely bugs; in fact, we found so many that it was a challenge to find the right ones. But we persevered, and identified several vulnerabilities that could be combined to create a working exploit:

1. We discovered that we could download files containing administrator credentials
2. We discovered that we were able to upload zip files to a specific directory on the webserver, without having to log in
3. We logged in with the administrator credentials from step 1, and found we could unzip these uploaded files to any other directory on the webserver.
4. We uploaded and unzipped files that allowed us to capture the credentials of all user devices connecting to XenMobile

Downloading files containing administrative credentials

The version of XenMobile we tested supported authentication using Security Assertion Markup Language (SAML) via an endpoint that was enabled by default. This endpoint is used for single-sign on (SSO) integration with other services. For example, it could be configured so that when a user signed into their Google account, they would also be signed into XenMobile. However, although the endpoint was unused, it wasn’t disabled, which made it vulnerable to attack.

SAML is an XML-based markup language, so we tried launching XML-based attacks against this endpoint. As it happened, one of the simplest XML attacks — an XML External Entity (XXE) attack — allowed us to read files on the target host.

The first files we recovered were encrypted, so we continued reading files until we found the one containing the decryption keys. When a webserver protects data by encrypting it, it’s quite common to find the keys on the webserver itself. Without them, the webserver wouldn’t be able to decrypt the data again.

One of the encrypted files contained credentials that could be used to make administrative requests to the XenMobile API. This gave us access to a broad range of functionality that should only have been available to highly privileged users.

File upload vulnerability

With our administrator access, we started examining the API to see what we could do with it. We quickly found two API endpoints that were interesting.

The first was an endpoint for connected mobile devices to upload debug files. No authentication was required to upload these files, but they were placed in a specific location.

The second was an endpoint that could unzip uploaded files. This did require the administrator access we’d gained earlier on. Normally when a file is unzipped, all the files in it are created together in a single location near the zip file; but this is just by convention. We were able to craft a malicious zip file that, when unzipped, would place files in arbitrary locations on the webserver.

I’m sure you can guess where we’re going with this.

We uploaded our maliciously crafted zip file with the first API endpoint, and then unzipped it using the second one.

Why do this? Well, read on…

Gathering credentials

The XenMobile webserver was intentionally designed to be able to modify or overwrite its own source code. This is quite common as it allows applications to automatically upgrade themselves, but it does have an unhelpful side effect: if an attacker can control what the application writes to those files, they can alter the source code of the application and control its behaviour.

Using the two API endpoints discovered above, we put new code on the webserver that caused it to collect the credentials of any device connecting to it.

The result

Because all users in the organisation had managed mobile devices, this exploit was able to capture numerous administrator credentials.

This meant we could go on to achieve our primary objective easily: we could simply log into the systems necessary to download all of the confidential data we wanted.

What happened next?

All of our simulations end with a comprehensive report for our clients. The report outlines the story of the breach (one version for technical teams, and one for everyone) and details all the vulnerabilities that we found. Our clients use these reports to help their staff to understand how we were able to breach them, and their technical teams to fix the vulnerabilities that gave us access.

When we find vulnerabilities in third-party software, we responsibly disclose them. We alerted Citrix and — when an update became available — we published the advisories.

After this work was completed our client decided to discontinue their use of XenMobile, and reinforced existing efforts to move to commodity, cloud-based services instead of on-premise solutions.

When we’re working on an adversary simulation, we always start by taking a wide view of the client’s systems and infrastructure, to try to work out where we think the risk is. We often end up choosing something to focus on that the client doesn’t expect, and the vast majority of the time, we go on to achieve the objective.

This is not surprising, as maintaining an accurate picture of risk across a complex technology estate is very hard. Arguably, it’s most hard as an insider, where availability, optimism and shared information biases can easily bite.

It’s partly because of these sorts of biases that we advocate starting security processes by looking for tangible security problems, instead of by assessing risks in an abstract way. We’ll be writing more about this soon!