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.

Zena Intro

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: PlainText Cookie Credentials 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.

Stored XSS

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. Default Cred 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. stored xss - auth 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: unauth stored xss 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. unauth xss trigger 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: definition


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:

We built the POC using a Python script that would inject our large JavaScript XSS payload into the webconfig page. After some tinkering, the POC was successful and we had RCE on our test server that was registered as a Zena agent. The POC successfully injected our XSS payload into the WebConfig page. Upon triggering, it then stole the cleartext credentials, used them to authenticate to the Zena API and register a Task for an agent that instructed the agent to execute our local shell command. This POC accepts custom commands, so you can specify what that local execution will be.



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.