CookieMonsteRCE17 Jun 2022
Credits: James Barnett and Jeff Green
CookieMonsteRCE - XSS to RCE Exploitation in Zena 4.2.1
It can often be overlooked just how impactful medium or low severity vulnerabilities truly are. They lack the persuasive punch that High and Critical severity vulnerabilities carry and this often leads to them being ignored or dismissed. Given the right circumstances, these vulnerabilities can wreak havoc, especially when chained together. This is our story of how even a simple vulnerability like stored XSS, can lead to a worst-case scenario such as RCE (Remote Code Execution) on the hosting server and lateral movement through the network.
Zeke and Zena are two enterprise IT orchestration tools by ASG Technologies (a Rocket Software Company) that we conducted our research on. Our research focused primarily on Zena, but Zeke played a part by contributing a very important vulnerability to this exploit chain that we later developed. Both of these applications allow you to run agents on endpoints that listen to a scheduler/controller for commands. From the scheduler, jobs can be created that are pushed to these agent endpoints. These jobs can entail running a script, program, or even executing direct system shell commands. You can already see the power that this application has and if someone was able to abuse this functionality, the situation could be dire for an organization.
Our journey started when we were tasked with testing this software for any potential business logic manipulation vectors that could allow this application to be used maliciously. We quickly discovered that this application had other glaring security issues that required our immediate attention.
Cleartext Storage of Sensitive Information in a Cookie
We had initially logged into the Zeke application and about to transition over to testing the Zena application when we noticed something peculiar in the Cookie storage: After successfully logging into Zeke, the plaintext username and password are stored as cookies. These cookies lack samesite and httponly security protections and we found we were able to access these values from the Zena application running on the same IP/Domain. Since administrators are likely bouncing between the Zeke and Zena applications, this was very interesting. This is not necessarily a huge red flag, but it did pique our interests to keep digging deeper.
The prior discovery prompted us to start testing some user input fields within the application to see if input was being properly sanitized and if there were any XSS vulnerabilities laying around. Finding an XSS vulnerability would allow us to take advantage of that credential cookie storage.
We began by looking at the webconfig page for the Zena application, which is where our first XSS vuln was uncovered. On the webconfig page, we were presented with a login page requiring only a password. A quick Google search told us this had a “very complex” default password according to the online ASG documentation. Once logged in, we were presented with a database connection configuration menu that was full of input fields. So, being offsec people, we start dropping XSS payloads into these input fields hoping something sticks and detonates. There were some filters in place, but after some HTML tag escaping, we successfully found our first XSS vulnerability; stored XSS. Now we were cooking with fire! Something told us this wouldn’t be the only stored XSS vulnerability and we decided to push deeper and try to find a purely unauthenticated XSS vuln within the site.
This was rather quickly found when inspecting the logging mechanism integrated into Zena. Zena was logging the username field from both successful or failed login attempts and incorrectly sanitizing that input before storing it in the log. This meant that anyone navigating to an injected log in the Zena application logs would trigger the exploit…
This could be exploited by just injecting the payload into the username field on an unsuccessful login attempt: When a user in the application navigates to the log, the exploit is triggered. This is a ticking timebomb and an attacker could expedite this execution with some social engineering to coerce an admin to navigate to the logs thus triggering the waiting payload. To make matters even worse, there was no character limit to what our stored XSS payload could be. This meant that we could inject a rather large and sophisticated payload.
Putting it All Together - Unleashing the CookieMonsteRCE
Okay, so you have an unauthenticated XSS vulnerability, who friggin cares? Right, well this is where things get interesting. We now have cleartext credentials being stored in cookies that are accessible across applications, authenticated and unauthenticated stored XSS vulnerabilities, and two determined researchers who wanna pop dem shells.
Zena’s backend is essentially a RESTful API and thanks to their swagger documentation, we were able to educate ourselves on its capabilities. Zena uses what are called Defintions to define jobs that the agent endpoints will perform. These Definitions can be created and executed via the RESTful API as long as you pass valid and authorized credentials in the request headers. So, what can these Definitions do? Just about everything. A Definition task can be configured to run a local script, program, or just execute arbitrary shell commands:
Knowing that we have cleartext credentials stored as cookies, a stored XSS vulnerability, and now a full fledged RESTful API backend, we had a solid plan on how to achieve the ultimate goal of RCE. We decided to build a POC that would take advantage of the credential cookie storage, the authenticated stored XSS, and the RESTful backend. The payload would perform RCE on not only the hosting server, but any agent endpoints on the network. This would be accomplished by a stored XSS payload stealing the cookie credentials, building Definition tasks using the API that would execute arbitrary commands on the agent endpoints, and then immediately executing the created Definition task.
This POC involves a few steps:
- First, the stored XSS payload must be delivered through the webconfig page
- Second, the payload must be triggered by some privileged user/administrator navigating to the webconfig page
- Third, the payload is executed and subsequent REST API calls are made using the stolen credentials. These API calls build a Definition task with an arbitrary system command.
- Fourth, the newly created task is executed and RCE is achieved
CVE Vulnerability Details:
These vulnerabilities have been remediated by Rocket Software and a new patch is available:
Our lesson learned was to never underestimate the impact a lower severity vulnerability might have. A highly motivated threat actor is likely to find a way to conjure up something nasty given enough time.