Before we address the title’s question, let’s roll back a few months.
In January 2020, a high impact vulnerability (CVE-2020-19781) landed on the cybersecurity scene. It impacted Citrix Netscaler devices and gave full remote code execution – which is pretty much as bad as it gets in terms of security vulnerabilities on a critical piece of an organization’s network infrastructure. It wasn’t looking good.
It was just another day in the office for the team at Immersive Labs, so we jumped straight in to assess what the vulnerability involved, how it worked, and whether we could replicate it as a practical lab for our users.
As we didn’t have any infrastructure to go on, Kev Breen, Director of Cyber Threat Research, took to Amazon Web Services (AWS) and checked their marketplace. Sure enough, Citrix had images listed for these devices.
As there was no patch, it was extremely likely that the devices were still at risk. Within a few minutes of start up, our PoC confirmed the vulnerability.
With this in place, we knew we could make a lab on the topic, so we started to look into deployment. It was here that we discovered the default AWS instance nsroot (the highest level of privileged access) password was set to the instance ID. Unfortunately, that instance ID could be viewed by anyone with access to that AWS panel, anyone who could run curl, or anyone who could read a specific file on the host. The admin wasn’t prompted to change the password at any point, which means that if exploited, an attacker could get the root password in just seconds, assuming it hadn’t been reset.
You can find more details on this exploit and its metadata URLs in our Citrix Offensive lab.
This is all old news, but with it in mind, we wanted to see if it was possible to gain access to either the file or the metadata URL from the web application. If so, it could lead to a privilege escalation vulnerability should a non-admin user gain access to the instance ID. We spent some time playing around with the application and eventually found a bug that had the potential to give us what we needed.
There is an option under System Diagnostics that allows you to run a backtrace. Without going into the technicalities of this command, interestingly, it asks for a file path but does not actually check that the user submits a valid file name. Using Burp, we were able to intercept and modify the request, which resulted in command execution as the root user. Ding ding!
By this point we were pretty excited, so started to take a closer look at exactly what was happening. We realized it was just calling the inbuilt CLI, but as an admin, we had the permissions to do this anyway. We tried again from the beginning, creating a new user account that didn’t have CLI or Shell access. Failure. We were unable to gain command execution as a non-privileged user.
So what?
While this is definitely a bug, it isn’t necessarily a security vulnerability. The web application, as described above, is not correctly sanitizing the input taken from the user and is trusting it blindly. Luckily, there are other mitigations in place that prevent this from being vulnerable in its default configuration.
This could be abused by someone with a lower level of access, but it would require a security misconfiguration in partnership with the bug.
Although not a default configuration, admins can create custom commands that non-admin users are allowed to run. This is done using regular expressions (regex). Normal regex is difficult to read, but these are even harder.
The Configure Command Policy showed us that it was possible for an admin to create a permission set that could accidentally give a non-admin user this level of access without realising (unless they were a regex ninja)!
Final note
This is not unique to Citrix. There are many other applications that suffer the same design flaws. One example is WordPress plugins that have SQLi or XSS, where you must be an admin in order to use them in an attack (at which point you effectively have full control of the application anyway). So on the one hand, yes; we have a bug here. On the other hand, no; it’s not necessarily a security issue.
Despite not being a security bug, this is bad code practice and needs to be resolved. Take a look at our secure code labs below and see if you can identify and resolve this kind of issue in your code before it makes it into production. This information was responsibly disclosed to Citrix before releasing this blog post.
Timeline
- April 23rd 2020 – Sent report to Citrix.
- April 28th 2020 – Citrix acknowledged issue.
- May 11th 2020 – Citrix closed the issue as a product bug.
