CentreStack Disclosure

Note: Updated 6/9/2023 to update official CVE IDs

White Oak Security discovered an instance of Gladinet’s CentreStack server which was vulnerable to an authentication bypass and an arbitrary file upload resulting in remote code execution.

This issue has been remediated as of release 13.5.9808 – June 13, 2022 (1). These issues were tracked as S-8238.

CentreStack Vulnerability Disclosure Timeline

White Oak Security (WOS) followed responsible disclosure guidelines by giving Gladinet time to remediate this vulnerability and allow customers ample time to patch their instances. Once we were able to establish contact with Gladinet, we appreciated their quick response to remediating the reported issues.

4/16/22: Attempted to contact Gladinet via online support ticket.

4/22/22: Second attempt to contact Gladinet via online support ticket.

5/10/22: Attempted to contact Gladinet via generic cold email methods.

5/12/22: Successfully contacted Gladinet via customer support phone number and follow-up emails.

5/16/22: Vulnerabilities disclosed to Gladinet via online support ticket.

6/13/22: Patch made available by Gladinet, identified by ID S-8238.

2/2/23: White Oak Security publicly discloses the finding according to our vulnerability disclosure policy.

CentreStack

CentreStack is an on-premise solution that provides file share, backup services, and remote file access which can be managed by a web application.

CentreStack Exposure

Using Shodan, the CentreStack web server can be found exposed on the internet on a handful of servers.

screenshot provided by White Oak Security shows centrestack login is exposed on the internet on a handful of servers.

CVE-2023-26829 – Analysis: Unauthenticated Password Reset

White Oak Security identified an access control violation where unauthenticated attackers can access the change password controller and, without providing the original user account password, force an update for an existing user account. The result is a full authentication bypass which allows a malicious user to gain access to an administrator account.

As a demonstration, an invalid login attempt for the account admin@test.com was performed using the password: “fakepassword!.

a demo by White Oak Security shows an invalid login attempt with admin@test.com as email and password as fakepassword!

The application denies the login request as expected due to an invalid password:

this screenshot by White Oak Security shows that attempt to login failed, was unauthorized

Next, the unauthenticated malicious actor forcefully navigates to the password reset application page. A form is created which prompts the user to attempt a password reset.

The malicious actor intercepts this request, modifies the hfTicket value to contain a username, in this case, the victim user admin@test.com, and sets a new password for the account “fakepassword!”.

screenshot of code by White Oak Security reveals the fakepassword! and admin@test.com in the modified hfticket value

The application successfully processes this request:

White Oak Security shares the code that shows the application process was successful

Lastly, the malicious actor once again navigates to the main login page and attempts to login as the admin@test.com user with the newly forced password.

again, White Oak Security attempts to login with admin@test.com and fakepassword! values on Centrestack

The application successfully authenticates the user since the account password had been changed, and the malicious actor gains the permissions of any account that had been reset, in this case, full administrative privileges.

White Oak Security screenshot shows that the application successfully authenticated the user since the code was changed and now has full administrative priliveges.

CVE-2023-26830 – Analysis: Unrestricted File UploadAnalysis: Unrestricted File Upload

Now that White Oak Security established a valid authentication bypass, WOS focused its efforts on obtaining code execution. An unrestricted file upload vulnerability was discovered within the Cluster and Tenant branding functionality, accessible by an administrator of the application. When chained together with an abuse of the Anti-Virus engine, the result is code execution.

The branding image upload functionality does not limit what file types that can be uploaded to the server, which allows a malicious actor to upload a custom executable file. In this example, a reverse shell binary is uploaded in the Logo handler:

Once the binary has been uploaded, the application reveals a broken image as expected since the content is not actually an image indicating that our upload has been successful:

White Oak Security screen grab shows Once the binary has been uploaded, the application reveals a broken image as expected since the content is not actually an image indicating that our upload has been successful - broken image highlighted here.

Upon inspecting the network traffic, we can see that the download for the logo image does return the binary program:

In order to achieve command execution, the full path of the uploaded image is required in order to be exploited with the Anti-Virus engine. On the filesystem, we can observe that a random GUID has been created within the C:/CentreStack directory.

While this GUID is random, the GUID can be leaked by interacting with the local file image editor or local application editor with any uploaded file:

The network traffic for this request leaks the full GUID in the LocalEditPage.aspx application response:

Next, the filename of the raw binary also contains a GUID with a fixed name “Brand_LogoImg” appended to the GUID that is generated.

White Oak Security's filename of the raw binary also contains a GUID with a fixed name “Brand_LogoImg” appended to the GUID that is generated.

However, this value is simply the y-glad-brid session value which can easily be found throughout any authenticated request:

White Oak Security shares the value is simply the y-glad-brid session value which can easily be found throughout any authenticated request:

Now that the full path of the uploaded binary has been discovered through the application’s own components, the Anti-Virus engine scanner location can be modified to the full path of the binary:

White Oak Security shares the full path of the uploaded binary has been discovered through the application’s own components, the Anti-Virus engine scanner location can be modified to the full path of the binary:

Since the Anti-Virus engine does not limit the path of the potential programs that can be executed, any arbitrary binary on the system can be executed as the Anti-Virus engine.

Lastly, a malicious actor simply has to upload any file to the CentreStack server which will trigger the Anti-Virus scan to execute and run the custom binary:

On the attacker-controlled machine, the reverse shell is executed and a successful connection is observed. The process is additionally being executed with the highest permissions of NT AUTHORITY\SYSTEM.

On the attacker-controlled machine (by White Oak Security's pentester), the reverse shell is executed and a successful connection is observed. The process is additionally being executed with the highest permissions of NT AUTHORITY\SYSTEM.

Upon inspecting the executing processes on the server with ProcessExplorer (2), the execution path is observed as the GladinetCloudMonitor.exe service executing the binary as NT AUTHORITY\SYSTEM compared to the web server permissions of IIS APPPOOL. This is due to the Anti-Virus programs requiring a higher permission to scan local files, however, this gains an attacker full administrative privileges over the underlying server.

White Oak Security screen inspecting the executing processes on the server with ProcessExplorer (2), the execution path is observed as the GladinetCloudMonitor.exe service executing the binary as NT AUTHORITY\SYSTEM compared to the web server permissions of IIS APPPOOL. This is due to the Anti-Virus programs requiring a higher permission to scan local files, however, this gains an attacker full administrative privileges over the underlying server.

While the unrestricted file upload vulnerability was used to upload arbitrary files to the server, White Oak Security could have alternatively uploaded a malicious file to the server using the built-in file storage mechanism, and simply pointed the Anti-Virus engine to execute that program and obtain a shell in that fashion.

However, it was more interesting to identify a vulnerability rather than built-in functionality to chain together this attack path.

More From White Oak Security

White Oak Security is a highly skilled and knowledgeable cyber security and penetration testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion.

Sources

1. https://www.centrestack.com/p/gce_latest_release.html – CentreStack Release History

2. https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer – ProcessExplorer