Citrix ADC and Gateway Vulnerability Update

By |Published On: January 13th, 2020|Tags: , |

CVE-2019-19781 Overview

On Friday, January 10th, 2020–right around the end of the work-day for most–a group calling themselves “Project Zero India” released a proof of concept (PoC) vulnerability for Citrix Application Delivery Controllers (ADC) and Gateways. This vulnerability is known as CVE-2019-19781.

Since the PoC has gone public, internet-wide scans have begun. So, what can you do to defend yourself?

Citrix has been aware of this vulnerability since Mid-December, but even with all of that lead-up time, there is currently no patch available. There won’t be a patch available until later this month. Depending on what product and release you are running, you may be able to patch on January 20th at the earliest; in other cases, you may be required to wait until January 31st.

Thoughts on Citrix’s Official Mitigation

Fortunately, Citrix has provided a mitigation that allows customers to stem off the tide of vulnerability scanners complete with a wide array of backdoors and payloads. I am not a Citrix expert; however, I interpret this mitigation as essentially telling the ADC/Gateway:

if an HTTP request for a non-VPN client contains the “/vpns/” in the URI, OR if an HTTP request comes from a non-vpn client and the URI contains “../”, to respond with a 403 Forbidden HTTP response code and page to the requestor.

If this is a correct interpretation, there are a couple questions at play here that currently have no answers:

  1. Is there a mitigation to prevent VPN clients from attempting to exploit this vulnerability?
    The mitigation seems to only be concerned with non-VPN clients making requests. While this stems the tide of mass-exploitation, it’s still a large issue.
  2. Do Citrix ADCs and Gateway appliances perform any sort of normalization or decoding before attempting to parse HTTP traffic and/or enforce policies?
    Methods like double encoding, ampersand encoding, URL encoding, and HTTP session splicing could be used to obfuscate exploitation attempts. Unless the ADC or Gateway decodes these requests prior to processing them, Citrix users may still be vulnerable in spite of the mitigation.

Other Available Prevention and Detection Methods

Aside from Citrix’s official mitigation, what other options are available to you?

Fortunately, security researchers have been scrambling to answer that, and there are a number of methods you can use to determine whether or not you are vulnerable as well as detect possible exploit attempts.

Suricata Signatures

https://doc.emergingthreats.net/bin/view/Main/2029206https://doc.emergingthreats.net/bin/view/Main/2029255

Please note that since the vast majority of Citrix traffic is over HTTPS, you may need to have some method for decrypting SSL connections to your Citrix ADC or Gateway in order to effectively utilize these rules.

Sigma Detection

https://github.com/Neo23x0/sigma/blob/master/rules/web/web_citrix_cve_2019_19781_exploit.yml

Sigma is described as a “Generic Signature Format for SIEM systems. In essence, it is a way to scan the logs ingested in your SIEM for various purposes. In this case, a sigma rule exists that you can use detect requests to:

-’*/../vpns/*’

-’*/vpns/cfg/smb.conf’

-’*/vpns/portal/scripts/newbm.pl*’

Yara Detection

https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

Yara is best described as Snort or Suricata, except for endpoint file systems. You can scan filesystems and use Yara signatures to detect badness. The Yara signature can be ran against citrix ADCs, Gateways, etc. to detect payloads dropped as a result of exploiting CVE-2019-19781.

Alienvault OTX

https://otx.alienvault.com/pulse/5e1c293e07c770f36d232489

This OTX “pulse” is a collection of observed payload file hashes, IP addresses of attackers, and so forth.

NMAP NSE

https://github.com/cyberstruggle/DeltaGroup/blob/master/CVE-2019-19781/CVE-2019-19781.nse

The popular port scanner NMAP features some vulnerability scanning capability through NSE, the NMAP Scripting Engine. This particular NSE script attempts to perform a GET request against /vpn/../vpns/cfg/smb.conf. If it’s successful, it informs you that the scanned host is vulnerable. As you might imagine, this script may be prone to false positives.

Metasploit Module

https://github.com/rapid7/metasploit-framework/blob/a64b0fa9e75befc3ffdb6129e88a6f6dd4c31208/modules/exploits/unix/webapp/citrix_dir_trasversal_rce.rb

In case your pentesters need access to the code, it’s been added to the Metasploit Framework.

SSH Command Check

ssh -tt [netscaler-ip] ‘find /netscaler/portal/templates /var/tmp/netscaler/portal/templates -mtime -5 -type f’

This command, provided by security researcher Florian Roth, is looking for newly added template files to the /netscaler/portal/templates/var/tmp/netscaler/portal/templates directory, and listing them. This search was formulated from a TrustedSec blog post on performing forensics on your Netscaler to determine if you may or may not have been exploited by this vulnerability.

To Sum Up

With these mitigations and detection methods, you will be able to defend your users and assets. We hope this blog post helps to keep you informed and protected until an official patch is available.

About Hurricane Labs

Hurricane Labs is a dynamic Managed Services Provider that unlocks the potential of Splunk and security for diverse enterprises across the United States. With a dedicated, Splunk-focused team and an emphasis on humanity and collaboration, we provide the skills, resources, and results to help make our customers’ lives easier.

For more information, visit www.hurricanelabs.com and follow us on Twitter @hurricanelabs.