Last Updated: 2020-01-07 13:16:10 UTC
by Johannes Ullrich (Version: 1)
For the last week, I have been monitoring our honeypot logs for evidence of exploits taking advantage of CVE-2019-19781. Currently, I have not seen an actual "exploit" being used. But there is some evidence that people are scanning for vulnerable systems. Based on some of the errors made with these scans, I would not consider them "sophisticated." There is luckily still no public exploit I am aware of. But other sources I consider credible have indicated that they were able to create a code execution exploit.
The most basic scan I have seen is a simple "GET" request for "/vpns/." For example:
GET /vpns/ HTTP/1.1
Host: [redacted ip address of host]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Accept-Encoding: gzip, deflate, br
For a Citrix ADC appliance, this request will return a 403 Forbidden status, even if the workaround was not applied. For most other web applications, it will return a 404 error. This request can be used to identify a Citrix ADC server, but it does not show if the server is vulnerable.
A more exciting request:
GET /vpns/cfg/smb.conf HTTP/1.1
Host: [ redacted IP address of honeypot ]
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept-Encoding: gzip, deflat
Interestingly, this client first hit the index page and downloaded all related assets, including favicon. The initial requests used a different user agent, and it kind of looks like the individual did first some manual pre-qualification of the honeypot before hitting this URL. But the real shocker (or not... if you looked at the code for a while) is that yes, smb.conf is exposed and can be retrieved without authentication. I tested it on an "unconfigured" virtual appliance (meaning I just downloaded it and didn't set up any features on it). The "NCS" headers are also typical for "Netscaler" but not required for this particular request. smb.conf is the only file in this directory.
Other requests show fewer skills (or I just don't understand what they are trying to accomplish):
GET //vpns/script/vista/*.exe HTTP/1.1" 404 493 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0"
Yes, there is an executable in this directory. But the wildcard URL doesn't work. Does it ever? This may be someone who red the advisory but didn't quite understand that part.
Another more dangerous request:
POST //vpns/portal/scripts/newbm.pl?url=[source IP redacted]&title=1232&desc=12312&UI_inuse=RfWeb HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Accept-Encoding: gzip, deflate
Cache-Control: max-age=0, no-cache
Origin: http://[honeypot ip redacted]
This request doesn't trigger an exploit the way it is written, and wouldn't work "as is" (parts missing). But it does hit one of the vulnerable URLs. So far, I only saw two requests, and they appeared to come from the same source (different source IPs, but close to each other in time and similar requests overall).
Source IPs scanning the honeypot for any of these URLs so far:
18.104.22.168 China Mobile
22.214.171.124 BACloud (Europe/US colo servers)
126.96.36.199 CHINA UNICOM Shanghai city network
188.8.131.52 OpenIP (France DSL)
A quick note on signatures I have seen: At least partial exploitation (file upload, data leakage) is possible without a "/../" pattern in the URL. Signatures should only look for the "/vpns/" pattern in the URL.