Citrix ADC Vulnerability: Immunity through Security
A remote code execution vulnerability CVE-2019-17981 has been reported in Citrix Application Delivery Controller (ADC) and Gateway in December 2019. If exploited, it could allow unauthenticated attackers to gain remote access to a company’s network and execute arbitrary remote commands. The ease of exploitability recently caught attackers’ attention and is the reason for the high 9.8 CVSS v3.1 base score. Citrix announced mitigation steps but a permanent fix was not available until late January 2020 thus prolonging the amount of time Citrix customers remained at risk.
Citrix ADC is an application delivery and load balancing solution that accelerates application performance, enhances application availability and claims to shield applications from attacks regardless of where they are hosted. ADCs have gained traction within the last decade and are widely deployed in enterprises leaving tens of thousands of firms exposed to hacking.
On January 7, SANS ISC indicated that attackers were scanning their honeypots for vulnerable systems. In the blog, they reference requests looking for a file called smb.conf in the “/vpns/cfg/” path. Requesting this file from a vulnerable Citrix ADC or Gateway returns the configuration file without authentication and fuels subsequent deeper penetration.
On January 8, Craig Young, principal security researcher on Tripwire’s Vulnerabilities and Exposures Research Term (VERT), published a blog discussing how he achieved arbitrary command execution on a vulnerable ADC host. According to Young, he places and loads a handcrafted XML file through a Perl Template Toolkit on the ADC without authentication. This allows him to subsequently enumerate usernames, active administrative sessions and run commands.
On January 10, Rio Sherri, senior security consultant at MDSec, published a blog with more details on Perl files accessible on the ADCs without authentication. He highlights code in various files that can be used and modified to effect file creations and their inappropriate use. To execute commands, he relies on a Perl Template Toolkit trick, which can run arbitrary code if the code is embedded in a template variable. He uses that Perl template’s public ‘new’ function to pass commands as parameters to it. Another approach Rio explains is to invoke a datafile plugin with specific parameters. By using a specifically created template that uses this plugin and prepending a parameter with the pipe ‘|’ character, it leads to executing code following that pipe character.
ProjectZeroIndia published a Proof of Concept Exploit Code on github on January 9, 2020, which used just 11 lines of bash code. Subsequently, more exploits started popping up and the exploitation activity elevated.
Several actors have used the vulnerability to exploit organizations. In January 2020, a criminal group behind the Sodinokibi ransomware attack claimed to have used the exploit to attack Gedia Automotive Group. Purportedly, it was used to plant ransomware, with the group claiming to disclose sensitive data.
Another report from FireEye describes bizarre exploitation attempts. It suggests implanting backdoors as part of post-exploitation payload, named NOTROBIN. Once a threat actor gains access to a vulnerable NetScaler device, the payload cleans up known malware, deploys malware that prevents further exploit attempts. However, the actor maintains backdoor access to the device, which can be leveraged for subsequent cyber-attack campaigns.
Citrix Netscaler on AWS:
As of January 12th, all Citrix Netscaler AMIs on AWS are vulnerable by default. The default root (nsroot) password is set to the instance ID.
A simple search for the product on shodan shows up a few results:
Since Netscaler listens on port 80, which is open to everyone in the default deployment, the exploit could easily help gain root access. Once access is obtained, AWS meta-data is exposed. This would provide vital information for the attacker to move laterally.
ShieldX customers are protected from this exploit through our threat prevention engine. With ShieldX deployed in front of Citrix ADC in any cloud deployment, they are protected from many more vulnerabilities and attack exploitations. Additionally, ShieldX helps track attacks as they progress deeper into clouds or datacenters by deploying comprehensive visibility and protection from lateral movement. Using automated policy generation, the attack surfaces are reduced to the required business function ports and thus lateral movement is limited.