Cyber Security Technical Blog

CentreStack Disclosure

Written by Admin | Oct 11, 2024 5:18:28 PM

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. 

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!.

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

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!”.

The application successfully processes this request:

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.

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.

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:

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.

However, this 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:

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.

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.

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.

 

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