Easy $20,160 bug from hackerone

Photo by Azamat E on Unsplash

the security a researchers discovered some pretty scary vulnerabilities in Pulse Secure SSL VPN. These were not your average bugs. We’re talking critical issues like arbitrary file reading, command injection, and even session hijacking. Imagine all the secrets your organization is sitting on, and boom — someone gets easy access to it all. Here’s a breakdown of how they found these issues and how you can try (or rather, not try) to reproduce them. But, for the love of the internet, **don’t exploit this for evil**!

1. **CVE-2019–11510** — Pre-auth Arbitrary File Reading
2. **CVE-2019–11542** — Post-auth Stack Buffer Overflow
3. **CVE-2019–11539** — Post-auth Command Injection
4. **CVE-2019–11538** — Post-auth Arbitrary File Reading
5. **CVE-2019–11508** — Post-auth Arbitrary File Writing
6. **CVE-2019–11540** — Post-auth Session Hijacking

So, He wasn’t just sitting around playing video games — they were busy hunting for juicy bugs. Here’s how they found these specific CVEs in Pulse Secure SSL VPN:

Reconnaissance (aka. “Let’s see what’s out there”):
They started by scanning the web for exposed Pulse Secure SSL VPNs. Shodan Search: The team started by using Shodan, a search engine that scans the internet for devices connected to it. Shodan indexes services like webcams, IoT devices, routers, and, crucially, VPN services like Pulse Secure. He used Shodan’s search query functionality to look for specific Pulse Secure SSL VPN instances. They could do this by searching for: Common Headers: Every Pulse Secure SSL VPN sends unique HTTP headers. He looked for specific headers that were common in Pulse Secure SSL VPN responses. These headers were dead giveaways that the VPN was vulnerable. Port Scanning: They targeted typical SSL VPN ports (e.g., port 443) and performed a search specifically looking for SSL VPN systems running Pulse Secure.

2. CVE-2019–11510 (Pre-auth Arbitrary File Reading):
After discovering an exposed SSL VPN, they tried accessing files they probably shouldn’t have been able to — before even logging in. They sent simple HTTP requests and boom — files like `/etc/passwd`, `/etc/hosts`, and some other juicy server files popped up.

How they did it: “Hmm, let’s see if we can read these files without logging in. Yep, that worked. Hey, look at these password hashes!”

3. CVE-2019–11539 (Post-auth Command Injection):
After logging in (because, you know, we gotta make it look legit), they noticed a bit of weirdness in the user input handling. So, what do they do? Inject some payloads like a boss and guess what — they were able to run commands on the server.
How they did it: “Alright, now let’s mess with some fields in the interface. A little `; ls` here, a little `&& cat /etc/passwd` there… oh look, RCE!”

4. **CVE-2019–11542 (Post-auth Stack Buffer Overflow)**:
— For this one, it was more about testing how the system handled user input — spoiler: not great. They found that by sending too much input, they could overflow the stack and possibly execute arbitrary code.
— **How they did it**: “So, this form doesn’t check for input length? Let’s send a really long string and see if it crashes or does something even more fun. Oh, it’s doing something fun!”

5. **CVE-2019–11538 and CVE-2019–11508 (Post-auth Arbitrary File Reading and Writing)**:
— Once they logged in as an admin, they realized that reading and writing files wasn’t just possible — it was *too* easy. No permissions? No problem.
— **How they did it**: “Now that I’m logged in, let’s see if we can grab some files from the server. Yep, that’s too easy. Let’s try writing a file — why not?”

6. **CVE-2019–11540 (Post-auth Session Hijacking)**:
Once they had logged in, they noticed that session tokens were stored in a place that wasn’t too secure. So, what did they do? They snatched that session cookie and started browsing around like they owned the place.
**How they did it**: “Oh look, this session token is not stored properly. Time to hijack it and walk around as if I’m the admin. I mean, who’s going to stop me?”

**Step 1: Pre-auth Arbitrary File Reading (CVE-2019–11510)**
First thing’s first — unauthenticated attackers shouldn’t be able to access sensitive files, right? But here’s what they found:

- **What they found**: Files like `/etc/passwd` (hello user info!) and `/etc/hosts` (can’t hack without knowing the hosts) were accessible. It’s like finding the keys to the kingdom — without even knocking.
- **How to reproduce**: Send a simple HTTP request to vulnerable Pulse Secure endpoints. Boom — files you shouldn’t see. Guess what’s inside? Password hashes and plain-text passwords from logged-in users. Nice.

**Step 2: Bypassing 2FA**
After discovering the pre-auth file reading, they used the captured information to bypass Duo’s two-factor authentication (2FA) mechanism. Double-secured? More like single-secured.

- **What they found**: With the integration keys and secrets from those files, they bypassed 2FA like it was a tiny speed bump.
- **How to reproduce**: Grab the integration key, secret key, and API host from the exposed files. Now you can authenticate without needing 2FA. It’s like skipping ahead in line at a concert.

**Step 3: Session Hijacking (CVE-2019–11540)**
So, after logging in, He started poking around the session management. Why? Because when it’s bad, it’s very, very bad. They found that sessions weren’t properly invalidated, which meant an attacker could steal a session token and use it for their own login.

- **What they found**: User session data was stored in `randomVal/data.mdb`, and this file could be reused by attackers. It was like sitting in the VIP section without a wristband.
- **How to reproduce**: Steal the session file and reuse it to authenticate as the original user. Enjoy the free access.

**Step 4: Command Injection (CVE-2019–11539)**
Once they had admin access, they noticed an opportunity for command injection. Where’s the fun in a web app if you can’t inject a few commands?

- **What they found**: Unfiltered user input allowed them to inject commands directly into the system. Hello, RCE!
- **How to reproduce**: Send a crafted payload in an admin field (think `; ls` or `&& cat /etc/passwd`). If it executes, congratulations — you’ve got a command injection.

**Step 5: Post-auth Arbitrary File Writing (CVE-2019–11508)**
With admin privileges, He found that they could write arbitrary files to the server. It’s like being given the keys to the server and told, “Do whatever you want.”

- **What they found**: Admins (and attackers) could write files to any location, even ones they shouldn’t have access to.
- **How to reproduce**: Upload a malicious file or overwrite an important file via the admin interface. Voilà, the server’s compromised.

**Step 6: Stack Buffer Overflow (CVE-2019–11542)**
After authentication, user input was processed with little regard for size, so they sent in huge strings of data that overflowed the stack, making it possible to execute arbitrary code. Classic buffer overflow.

- **What they found**: Long inputs triggered a buffer overflow, leading to potential code execution.
- **How to reproduce**: Input a long string (really, really long) into the vulnerable field. See what happens next.

If you want hunt down vulnerabilities in Pulse Secure (or similar products), here’s what you need to do:

1. Look for File Access: If you can access files like `/etc/passwd` or anything that has sensitive data, then you’re on the right track.
2. Test Session Management: If you find session tokens that aren’t properly invalidated or stored, you’ve got a potential jackpot for session hijacking.
3. Command Injection: Always test input fields for command injection. If they’re not properly sanitized, you could execute arbitrary commands.
4. Buffer Overflow: Look for places where user input is not checked for size or length — perfect setup for a buffer overflow.
5. File Writing: Check if users can upload files or overwrite server files. If yes, they might be able to run malicious code.
6. 2FA Bypass: Look for improper handling of 2FA credentials. If you find them stored insecurely, you might just be able to bypass it altogether.

If you made it this far, congrats! You’ve just taken a crash course in how Pulse Secure SSL VPN fell from grace in 2019. And hey, if you find similar issues in any VPN, don’t be a villain — report it, get your bounty, and become a hero. Because, honestly, who doesn’t love a good security story with a happy ending?