On December 17, Citrix issued a Security Bulletin on an unauthenticated remote code execution vulnerability (CVE-2019-19781) affecting its Citrix Application Delivery Controller (ADC) – formerly known as NetScaler ADC – and its Citrix Gateway – formerly known as NetScaler Gateway.
At the time of the security bulletin release, there was no official information available on what the exact vulnerability was, although Citrix did release Mitigation Steps for CVE-2019-19781 which shed some light on how the vulnerability was exploited.
The mitigation offered was to create a responder policy that would prevent HTTP requests with ‘/../’ and ‘/vpns/’ in the URL which would trigger a 403 response code.
At that point it was assumed the vulnerability would most likely take advantage of some sort of directory traversal flaw to upload malicious files to the /vpns/ path, leading to remote code execution. We created several research rules to detect HTTP requests to the suspicious path, but weren’t able to capture any kind of malicious requests at that time.
On January 3, the SANS Internet Storm Center (ISC) tweeted that they’d observed the “first exploit attempt” for this vulnerability in the wild, although they didn’t include any additional details. At that point in time, no malicious requests were detected on any sites protected by Imperva.
From January 7 onwards, several blog posts were published that gradually started to reveal the nature of the attack, until a POC and exploit was published on January 10.
As attack activity rose immediately following the release of the POC/exploits, we found that the first stage of the attack was blocked out-of-the-box using existing directory traversal signatures – thus Imperva provided a mitigation for a zero day exploit.
In addition, the research rules that were set up prior to the POC/exploits both detected and blocked the second stage of the attack. What’s more, they were able to block recon attempts by attackers trying to detect vulnerable Citrix ADC/GW by directly accessing the following paths, in an effort to retrieve the ‘smb.conf’ configuration file or reach the writeable script ‘newbm.pl’:
From that point onwards we saw a surge in attack attempts on sites protected by Imperva, as shown in the graphs below:
After the two initial exploits were published – a simple Bash script and a more detailed Python script – numerous other variations of the exploit appeared in several GitHub repositories. Below we can see the spread of various clients that were identified based on client verification tests, as sources of exploitation and scanning attempts on Imperva-protected sites:
From the graph above we can see that, from January 11 onwards, most exploit attempts were executed using the Bash script – this was identified by cURL User-Agent as the script uses cURL to send the malicious request – followed by the Python scripts (there were two variations of the exploit, one using the Python urllib library, the other using the python-requests library).
In the last 24 hours (at the time of writing this post) we also noticed a sudden increase in requests from various vulnerability scanners, mainly WhiteHat Vulnerability Scanner.
Below you can see the amount of Imperva-protected sites targeted since the exploit attempts were detected in the wild, and the total number of sites attacked:
At the end of the day, our customers were protected right out-of-the-box in the Cloud and the On-prem WAF. The Threat Research team will keep tracking this and other zero-day vulnerabilities and their exploits, as well as constantly updating our WAF engine to provide the best mitigation to newly released vulnerabilities.
Get the latest from imperva
The latest news from our experts in the fast-changing world of application, data, and edge security.