When testing Java thick applications, it is beneficial to attach a debugger to enable you to step through the application logic and bypass front end validation. Often vendors rely only on front end validation on the client to secure themselves from malicious input, but by having a debugger attached an adversary can change variable values during run time. It is then up to the server to validate the user input. Having a functional client that can be manipulated in this manner is far more efficient than reverse engineering and writing a malicious client.

How to Attach a debugger to a Java thick application

We will use the free to use community edition of IntelliJ. In the installation folder of the Skybox application, find all the associated jar files. Once all of them are located, import these into a new project.

With Skybox running, make use of Process Explorer to determine how the application can be run from the command line, this will enable us to restart the application with a listener to enable us to attach to it with the IntelliJ debugger.Using Process Explorer this is what we found:

Authenticate as a low privileged user and change the value of this.loginName to that of a another valid user. Below we replaced the user lowpriv with the default administration account, skyboxview:

A response is then received by the client that contains the hashed password of the substituted user (skyboxview). The server should not return this password hash during password authentication, the password should be validated on the server. This issue has been assigned CVE-2017-14770 – Password Hash Disclosure.

Further inspection of the application code revealed that a predictable salt value of 123username45 is used when hashing the password. This code is in the PasswordUtil class:

GDS observed that the executable jps.exe is periodically run by the Skybox server and thereafter replaced this file with our reverse shell.

Once an upload to the Skybox server is initiated the debugger will pause the client side component and we are able to specify an absolute path for the uploaded file to be saved on the server. The server does not validate the location of the file to be uploaded.

Specifying a file to upload

In the debugger

Note the application enforces a relative path of Temp\[file name]’for the variable destinationFileName. However, a threat actor can manipulate this value with a debugger attached.By changing the destinationFileName value to: C:\Skybox\thirdparty\jdk1.8.0_66b\bin\jps.exe the threat actor will overwrite the original jps.exe with their malicious version.

Edited file path

The user is then presented with a dialog stating that the file was successfully uploaded to /data/temp.

Successful upload

The threat actor will then need to listen on their machine for the incoming connection as seen below.

Ncat listening for the incoming connection on port 4443

In summary, from a low privileged user GDS has manged to elevate their privileges to that of an administrator, with an added bonus of retrieving this user’s password hash for later cracking. This allowed uploading of arbitrary files to the Skybox server. By abusing the server’s trust that the client validated user input, GDS has overwritten an existing file that is executed periodically to gain remote shell access to the Skybox server. A special thanks to Elliot Ward who helped during the early stages of exploitation that lead to the arbitrary file upload vulnerability.

Remediation

GDS recommends that affected users update immediately to version 8.5.501 or later of the application. For more information please see:Skybox Product Security Advisory