Detectify Crowdsource hacker, Alyssa Herrera, is a full-time bug bounty hacker and web application security researcher who works to protect organizations. They are one of several Crowdsource hackers to submit a working proof of concept for File Disclosure in Pulse Secure Connect (CVE-2019-11510). This guest blog post will walk through how they developed an exploitable-payload for this vulnerability.
Introduction to research
Our research began when Orange Tsai and Meh Chang published some amazing research focusing on SSL VPNs at Black Hat USA 2019, where they talked about exploiting a vulnerability in Pulse Secure Connect that gave them total access to Twitter’s infrastructure. This piqued my interest as Tsai didn’t publish a proof of concept for the exploit he found in Pulse Secure Connect (CVE-2019-11510) and being a curious researcher I wanted to work on reverse engineering the exploit from the clue they gave.
We’ll be focusing on how we reversed engineered it to develop an exploit for CVE-2019-11510 in Pulse Secure, what caused the vulnerability, its impact, and additionally the importance of patching for organizations and companies.
Determining the scope
This project initially focused on developing a proof of concept that we could use in our engagements against bug bounty targets or clients, though this later turned into also wanting to create a larger awareness of these vulnerabilities, their impact and further helping the security community by expanding on the capabilities of what was shown.
What resulted was a collaborative project among Mimir, Justin Wagner, and myself to develop an exploitable proof of concept for CVE-2019-11510 and subsequently develop tools to make exploitation of it easier. We also focused on the exploitation of CVE-2019-11539, a post-auth RCE, and ways an attacker or red team could abuse built-in features of Pulse Secure connect to attack users.
But first, why is a VPN client interesting to hack?
A Web VPN acts as a gateway between internal services and the internet, and allows users to securely access corporate resources from their computer or mobile device without needing to install extra software such as a VPN client. This provides an attack surface that is appealing to malicious actors; gaining access to a user’s log-in information could allow an attacker to access sensitive internal resources, or gaining access to the server itself could allow total compromise of a company’s assets that would normally be gated behind the service.
The original research on hacking SSL VPNs
Orange Tsai began research on the security of several popular web VPN services back in December 2018, including Fortigate SSL VPN, Palo Alto, and Pulse Secure Connect. His research revealed several critical vulnerabilities in these popular and heavily used corporate Web VPNs, and the first patches for Pulse Secure Connect went out in April 2019.
Orange Tsai, at the time of writing this, has released details on it that matched the proof of concept we developed. In this article, we focused on Pulse Secure Connect.
Our research took place four days after the release of the presentation slides from Black Hat USA and it only took us about a day to finish the creation of the exploit. From there we started targeting various companies we knew had bug bounty programs, or vulnerability disclosure programs to have the vulnerabilities patched. I additionally reached out to another researcher named Streaak, who also helped provide more websites that we could report to as well. Justin Wagner and I then developed a Metasploit module to make the automation of the exploit much easier and then subsequently released the exploit on August 21.
Escalating the research from Black Hat
In Tsai’s original slides he gave very sparse details pertaining to the actual exploit for the Pulse Secure VPN. His slides also gave a good bit of information into how the exploit would work and a proof of concept which demonstrates retrieving a js file from a vulnerable instance.
This wasn’t interesting for most security researchers, myself included, and I was more interested in how I could turn that into something that could be used to exploit websites and show an impact to the website itself. Most clients or bug bounty programs won’t see the impact of the fact you’re retrieving a JS file, whereas if you’re able to show you’re retrieving internal files that could leak sensitive data, then they’ll understand that this issue needs to be handled immediately.
Black Box or White Box?
Initially the first attempts at reversing the exploit was through manually playing with the proof of concept that Tsai provided in his slides, as well as attempting a Black Box approach to the exploit. Our first challenge was simply getting access to a copy of Pulse Secure Connect and setting it up. This took us quite a bit of time but we found that the Azure Marketplace has a copy we could then implement into an Azure instance. From here we started looking at the initial proof of concept that Tsai, which was provided in the presentation slides as mentioned before.
The proof of concept that Tsai provided look like this: "https://pulse-secure/dana-na///css/ds.js?/dana/html5acc/guacamole/"
This was interesting as it demonstrated the behavior of the magic string being used to make the normally strict path validation, which would have rejected the double forward slash characters, relaxed enough to accept these normally disallowed characters. The guacamole string was the key focus as it was the only solid clue we had on how we could possibly exploit it. We initially tested this from a Black Box approach trying variations of the proof of concept to see if we could simply discover it through tinkering and modifying the initial exploit. This didn’t result in anything for us so we took a different approach.
We tried a White Box approach instead: reversing the code then manually working out the exploit from there. This also took a bit of time as getting the source code was tricky since we needed to SSH into the box to be able to access it. We first needed to interrupt the boot sequence, get to the serial console somehow and lastly enable SSH. After this, getting the source code was trivial. It took us more time to get the source code than to develop the exploit.
After getting the source code we began to analyze how the guacamole string worked out and how it handled input. In normal cases, any form of directory traversal through a ./ string would be stripped and sanitized due to the security rules in place that would validate whether a given url path contained a traversal string, but due to a flaw in the way Pulse Secure handles static files we can disable this path validation and enable the ability to arbitrarily request internal server files.
It all starts with a magic string, this string is called /dana/html5acc/guacamole/ which, if seen at the end of the request, will relax the security rules and allow for a case of accessing local files on the instance. In the code snippets above we can see how the code handles a request with this magic string, and how it handles the validation of these paths specifically. At this point you could access certain file paths that had specific white listed extensions, specifically .html, .js, .png, etc.
An example of how this would look like this: curl -I
https://pulse-secure/dana-na///css/ds.js?/dana/html5acc/guacamole/
We use curl specifically as browsers would “helpfully” strip out the traversal characters when they parsed the URL.
In order to get around this whitelist extension, we can again use the magic string, /dana/html5acc/guacamole/. If the string is seen in the middle of the request, the web server will relax the need for a whitelisted extension, thus allowing you to access files that don’t have a specific file extension like /etc/passwd.
The crafted exploit would look like this: curl --path-as-is -k -D-
Breaking it down and summarizing how it works is simply like this, /dana-na/ is a non-authenticated end point. Then we traverse up the folder, insert our magic string to relax the path validation, followed by several path traversals, and finally we input target file which in this case is /etc/passwd with an additional magic string at the end to allow it to access files with extensions that aren’t whitelisted.
What can we do with this path traversal?
Well with path traversal we can traverse the entire filesystem of the folders and access various internal files that may contain sensitive data which wouldn’t normally be accessible. With Pulse Secure Connect, there are several files which are very interesting:
The first file is /data/runtime/mtmp/system. This file houses weakly encrypted hashed passwords which can be easily cracked.
The second file, /lmdb/dataa/data.mdb/lmdb/dataa/data.mdb is by far the most interesting one as this one contains cleartext passwords, usernames, NTLM hashes, and other security-critical data. This is because Pulse Secure will cache log-in data to this file.
The third file, /lmdb/randomVal/data.mdb is also curious as it enables us to grab a session token which we can re-use to login into the pulse secure instance. From here an attacker would use the credentials or session to log in to the instance and then access resources that would normally be inaccessible.
The attacker’s options
Companies use VPNs to gate-off internal network resources, which could be anything from administrative panels, source code repositories, or analytics panels. An attacker could use the looted credentials and compromise the company by gaining access to the administrative panel. Subsequently they can exploit a feature of Pulse Secure Connect that allows administrators to set a program for users to execute upon login and re-use it to launch malware on all users who use the VPN.
Another option is an attacker could exploit a separate vulnerability in Pulse Secure Connect which allows you inject commands into the VPN server itself, which can then be used to gain direct server access through an SSH shell. You can find more in depth information about this in a separate blog I wrote here.
The instances found
This vulnerability was reported and patched several months ago in April, though current reports from other security researchers showed that over 14k instances were using vulnerable versions of this software! Thankfully, this number has dwindled down to nearly 9k vulnerable instances over the course of writing this article.
We discovered and reported to around 25 companies that were vulnerable to this vulnerability, many of these companies were major companies or organizations that could have had serious damage inflicted if they weren’t properly patched. A bulk of the ones we discovered were Fortune 500 companies, financial institutions, US Defense, or military contractors.
How can you make sure you’re protected?
With the release of the exploit for CVE-2019-11510, many malicious attackers are now subsequently scanning the Internet for vulnerable instances to compromise, so it is important for companies using the affected software to update their instances immediately to protect their users, staff, and data. This is a major issue as many prominent data breach incidents exploit known-vulnerable, outdated software like an unpatched VPN rather than finding novel vulnerabilities.
In general, you should keep on top of patching web applications and appliances used for your organizations. Doing so removes much of the attack surface and makes it easier to focus on other areas such as the security of your own in-house web applications as well.
Written by:
Alyssa Herrera
Bug Bounty Hunter
Twitter: @Alyssa_Herrera_
Blog: https://medium.com/@alyssa.o.herrera
With Detectify you can check your website against CVE-2019-11510 and other related vulnerabilities impacting SSL VPNs including Pulse Security and Fortigate. Our testbed has 1500+ security tests for known vulnerabilities submitted by the Detectify Crowdsource community, as well as our in-house research. Sign up today for a 14-day free trial.