A week before the 2019 holidays Citrix announced that an authentication bypass vulnerability was discovered in multiple Citrix products. The affected products are the Citrix Application Delivery Controller (formerly known as NetScaler AD), Citrix Gateway NetScaler ADC (formerly known as NetScaler Gateway), and Citrix SD-WAN WANOP appliance. Exploiting the vulnerability could allow an unauthenticated attacker to perform arbitrary code execution on the Citrix appliance. In the initial advisory, Citrix did not mention many details about the vulnerability which let many system administrators wondering if they are affected and how to identify attacks. At that time, over 80.000 organizations were affected by the vulnerability, including government organizations and many Fortune-500 companies.
The vulnerability has been assigned CVE ID CVE-2019-19781 and affects the following supported product versions on all supported platforms:
- Citrix ADC and Citrix Gateway version 13.0 all supported builds before 13.0.47.24
- NetScaler ADC and NetScaler Gateway version 12.1 all supported builds before 12.1.55.18
- NetScaler ADC and NetScaler Gateway version 12.0 all supported builds before 12.0.63.13
- NetScaler ADC and NetScaler Gateway version 11.1 all supported builds before 11.1.63.15
- NetScaler ADC and NetScaler Gateway version 10.5 all supported builds before 10.5.70.12
- Citrix SD-WAN WANOP appliance models 4000-WO, 4100-WO, 5000-WO, and 5100-WO all supported software release builds before 10.2.6b and 11.0.3b
Citrix advised taking the suggested mitigation steps in the initial advisory until patches to fix the problem are released which was not the case until late January 2020. Meanwhile, according to FireEye research threat, actors were actively targeting vulnerable Citrix installations to install malware and perform the mitigation steps to prevent subsequent exploitation attempts. The payload used by the threat actor is named NOTROBIN. By the end of January 2020, Citrix has released patches for all products: “The fixed builds can be downloaded from Citrix Downloads pages for Citrix ADC and Citrix Gateway. It is strongly recommended to apply the appropriate patches as soon as possible.
Analyzing the Citric RCE vulnerability
Now that we have a better understanding of the affected products, let’s have a look at the available exploits. We will test the exploits on the Citrix ADC 13.0-47.2 appliance that we have installed for testing purposes. At the time of writing several exploits have already been released to the public, such as:
- https://www.exploit-db.com/exploits/47901
- https://www.exploit-db.com/exploits/47902
- https://www.exploit-db.com/exploits/47913
When looking at the various exploits on Exploit-DB, we can see that only two requests are required to exploit the vulnerability. The first request is a POST request with four parameters calling a Perl script named newbm.pl. The four parameters are url, title, desc and UI_inuse. The vulnerable parameters are the title and desc parameter, and this is where you will find the payload. As we will learn from analyzing the code on the Citrix appliance, these values are not sanitized by the Perl script and written to an XML file that is created on the local file system. While writing to an XML file does not directly have to lead to remote code execution injecting Perl Template Toolkit instructions and parsing the file as a template does lead to code execution. The first request looks like this:
The directory traversal happens in the NSC_USER header which contains the file path where the XML file will be stored. The NSC_NONCE header is not relevant for exploiting the vulnerability, but it is required to include with the request. If we replace the <<Command>> placeholder with a system command, such as id, and send the request to the server we get the following response:
When looking at the local file system in the directory that we have specified earlier in the NSC_USER header (/netscaler/portal/templates), we can see that the HT.xml file was successfully created:
As we can see on the screenshot, the values for all four parameters are stored in the XML file, including the template instructions with the id command in the description field. We can also see that none of the user input was sanitized in any way as the file contains the same values as submitted with the request. If the values were sanitized, we would not expect to see special characters here, such as quotes and brackets.
With the second request, we will request the XML file parsing it as a template file. This request causes the injected Perl Template Toolkit instructions to be executed which leads to code execution on the Citrix server. The second request looks like this:
After sending the request to the Citrix server, we get the following response that contains the command output:
As we can see on the screenshot we got code execution on the Citrix appliance. We can see that the system command that we injected in the XML file was executed in the context of the webserver (nobody). As there is no limitation of characters we can use in the system commands, turning this code execution into a shell is just one easy step away.
Another important take away that we’ve learned from this vulnerability is that even devices and appliances that are generally ‘considered’ secure can contain critical vulnerabilities which are relatively simple. When looking at the affected product versions it appears that this vulnerability has been around for a long time already. Also, after going through the code related to this vulnerability I would not be very surprised if other (publicly accessible) scripts contain similar vulnerabilities.
Hacking Courses on Udemy
Bug Bounty – An Advanced Guide to Finding Good Bugs
Real World Bug Bounty Techniques
Website Hacking / Penetration Testing & Bug Bounty Hunting
Become a bug bounty hunter! Hack websites & web applications like black hat hackers and secure them like experts.
