Cloud Foundry is a popular open source PaaS (platform as a service) on which developers can easily build, deploy, run and scale their applications on the cloud. Several Cloud Foundry Certified Platforms such as Pivotal CF and IBM CF add enterprise-level features (e.g. improved web interface, support) to open source Cloud Foundry and are used by organizations worldwide, including some of our customers.
Cloud Foundry is comprised of various smaller projects, each with a dedicated role. I’ve recently looked into Cloud Foundry UAA (User Account and Authentication server) and found two vulnerabilities:
- CVE-2019-11268 – An SQL injection vulnerability in UAA’s identity zones implementation, which can be exploited by a client with reading privileges in a given identity zone to acquire private information of users, clients and groups in all other identity zones.
- CVE-2019-11270 – A second vulnerability, which I’ll describe in a follow-up post as the Cloud Foundry team is still working on a fix.
Cloud Foundry in a nutshell
The Cloud Foundry Foundation offers multiple PaaS solutions aimed at easing deployment of applications to the cloud. Cloud Foundry Application Runtime (CFAR) is the flagship solution and is generally what people mean when referring to running apps on Cloud Foundry.
Simplifying a bit, CFAR takes your application source code, builds it, runs it on containers, and regularly checks your application’s health, alongside providing other neat features (e.g. logging, routing, Oauth2 authorization, and more).
CFAR itself is composed of several components, each running on dedicated VMs.
Let’s review the components in the image above:
- CF CLI – the command line tool for interacting with the Cloud Foundry deployment through the API exposed by the Cloud Controller.
- Cloud Controller – the API endpoint to the Cloud Foundry deployment.
- Diego – the container orchestration component. Plays a somewhat comparable role to Kubernetes. The Diego brain distributes the workload of containers (running user applications) between Diego cells (similar to Kubernetes nodes).
- BOSH – a separate CF tool used to deploy jobs to VMs. Usually used to deploy the CFAR components themselves to a cloud provider (e.g. AWS) and then monitor their health.
Cloud Foundry UAA (User Account and Authentication) is an Oauth2 server providing identity management and fine-grained access control, which can be used as an authentication server in any environment. In the context of a CFAR environment, UAA authenticates and authorizes entities in the deployment (such as the CFAR components, applications, users and more) by granting them access tokens which are respected by other entities in the deployment.
Before we dive into the vulnerability, we need to go over a few UAA concepts. If something is unclear, try reading UAA’s explanation here.
UAA implements the widely used Oauth2 authorization protocol. Most of you have probably used Oauth2 based authorization, for example when signing up to a website (e.g. eBay) using your Facebook account, and authorizing the website to have some permission over the account, like reading your email address or posting on your behalf. In this example Facebook it the Oauth2 server.
The UAA server works in a similar manner, allowing authenticated users to approve clients (applications like eBay) to act on their behalf. Upon approval, the client is granted an access token embedded with scopes (basically permissions), which define the scope of access the token allows. These scopes are set according to the requesting client and approving user permissions. The client can then present their access token to the UAA or to other resource servers governed by it and act based on the scopes encoded in the token.
In the example above, eBay could have been granted an access token embedded with the ’email.read’ scope.
Some clients can act on their own without the need for user approval, according to a set of permissions called authorites*. These are useful for resources which aren’t related to users. In the Facebook example, eBay could have the ‘advertise.put’ authority, allowing it to push ads to Facebook or to other sites governed by it.
* Note this is UAA terminology, not Oauth2.
UAA is built to support a multi-tenant architecture, where each tenant is referred to as an identity zone. An identity zone is a logical boundary around the entities UAA manages, and thus each entity (such as users, clients, and groups) belongs to an identity zone. According to Cloud Foundry documentation, having two identity zones is equivalent to setting up two separate UAA deployments, but using fewer resources.
Clients’ and users’ permissions are limited to the boundary of an identity zone. For instance, a client in zone ‘abcd’ with the ‘groups.update’ authority should only be allowed to update groups in zone ‘abcd’.
Each zone is registered with a subdomain. For a UAA server that is accessible at “uaa.cf.domain.com”, a zone registered with subdomain ‘abcd’ is accessible at “abcd.uaa.cf.domain.com”.
Identity zones are commonly used for two purposes:
- Separating the development/testing entities from the production entities.
- Using one UAA server to manage multiple environments.
CVE-2019-11268 – information exposure across identity zones
The UAA server exposes several endpoints for clients with reading privileges to query on entities in their identity zone. Specifically, ‘/oauth/clients’, ‘/Users’, and ‘/Groups’ are used for querying on clients, users, and groups, respectively. The scope required for querying on users and groups is ‘scim.read’ and the scope required for querying on clients is ‘clients.read’.
Those endpoints allow specifying a filter in the request, to search for entities with specific attributes. For example, using the uaac CLI, the following command queries the UAA server for users whose username starts with ‘yuval’:
uaac curl "/Users?filter=userName sw 'yuval'"
Currently, the UAA’s users, groups and clients database tables contain entities from all identity zones. To ensure searchable queries only return entities in the relevant identity zone, the UAA modifies each provided filter:
“(“ + filter +” ) and identity_zone_id eq ” + zoneId, where ‘zoneId’ is substituted with the relevant identity_zone_id. For the example above, the filter will be modified into:
“(userName sw 'yuval') and identity_zone_id eq \“zone1\””
Using a specially crafted filter, a client from a certain identity zone can view all entities from all other identity zones. For example, the following filter will return all users from all identity zones (‘pr’ in the filter’s syntax means present):
“id pr ) or identity_zone_id pr or ( id pr”
The modified filter UAA will construct for this input is:
“(id pr ) or identity_zone_id pr or ( id pr) and identity_zone_id eq \“zone1\””
Since ‘or’ operators are evaluated last in SQL, the modified filter constructed by the UAA server will return all users from all identity zones. This filter can achieve the same results for the “/Groups” endpoint. A similar filter can be used for the “/oauth/clients” endpoint to get all clients from all identity zones:
“client_id pr ) or identity_zone_id pr or ( client_id pr"
This vulnerability can be exploited by a client with reading privileges in a specific identity zone to extend those reading privileges to all other identity zones and obtain private information on the users, clients, and groups in them. This includes:
- users’ username, id, email addresses, and phone numbers
- clients’ id, clients’ permissions (scopes and authorities), and authorized token grant types
- Groups’ id
An attacker, for instance, can exploit this vulnerability to acquire email addresses of users in other identity zones and then target those email accounts in a variety of methods to try and take control of one. If an attacker gained access to one of the accounts, he can reset the password of the associated UAA user and compromise it.
An attacker can also find clients with weak configurations and target them, such as clients registered with privileged permission (such as the ‘clients.admin’ scope) and the relatively insecure implicit token grant type.
Let’s see an exploit in action! The following video shows an attacker with reading privileges in zone ‘abc’ obtaining private information on users and clients in zone ‘uaa’:
The identity zone feature is often used to create testing/development zones. Developers tend to configure such testing environments with weak security defaults and weak credentials, and therefore they present an entry point for attackers into the system. Vulnerabilities in the identity zones implementation could allow an attacker who compromised the testing zone an opportunity to try and compromise the production zone as well.
The Cloud Foundry security team were prompt and cooperative in their response to my original advisory and shortly after released a fix for the issue. If you are using either Cloud Foundry Application Runtime or UAA, don’t forget to update to the patched version, UAA-release v73.3.0.
In a follow-up post, I’ll dive into a second, rather severe vulnerability I found in CF UAA, CVE-2019-11270, which is currently still under embargo.
Stay tuned for the announcement on CVE-2019-11270, and follow @TwistlockLabs for live updates.
Recent Kubernetes vulnerability exposed pprof interfaceRead the Blog
Privilege Escalation in Cloud Foundry UAA – CVE-2019-11270Read the Blog
Finding a DoS vulnerability in NATS with go-fuzz – CVE-2019-13126Read the Blog
Vulnerabilities in Nexus Repository left thousands of artifacts exposedRead the Blog