When hunting on a site I tend to just poke around, gauge the functionality and see logically what can be broken before I fuzz.
The target (www.REDACTED.com) was a large finance holding company. Almost all their domains were heavily locked down and required employee SSO credentials to use.
However, one of their sister websites I discovered by Google Dorking allowed verified authors worldwide publish articles on how to use the company’s financial software sold. However, publishing an article required strict manual approval by the site admins.
This is a common step missed by bug bounty hunters, make sure to read the scope and see if they allow third party websites to be tested. I typically refer to these as “sister sites”, after finding this domain I shifted my focus on attacking this third party as it was in scope and no longer the main domain.
I couldn’t find any vulnerabilities on the third party’s main website (www.Sister-REDACTED.com)
Recon
If you don’t have a recon methodology it may benefit you to read some bug bounty articles on Medium more frequently. What helped me was following users who wrote unique or practical blogs that weren’t generic or similar to ones I’d seen many times.
Critical Side Note in automated Fuzzing:
Always include a User-Agent header when fuzzing at the very least. I nearly missed a P1 vulnerability in another target by not doing this.
While using HTTPX to verify which subdomains were live, a few subdomains consistently returned as being unreachable. However, when I stumbled upon one of the supposedly unreachable subdomains when google dorking they were reachable, I almost missed a whole subdomain.
Turns out there was a reverse proxy in front of the domain silently dropping any request packets without a proper User-Agent header. Furthermore, the Windows server behind the proxy had ICMP replies disabled making it truly appear as an unreachable domain.
Even after adding proper headers, I still got inconsistent results with HTTPX. To this day, I haven’t found a reliable solution. Rate limiting was not the issue either, it loaded fine in the browser (even after 1000+ refreshes), but for some reason would fail in HTTPX.
- Fuzz subdomain VHOSTS viaFFUF
- PureDNS for direct DNS enumeration.
- I also went through passive collection of subdomains by using tools such as subfinder and google dorking (site:Sister-REDACTED.com ).
- Looked for related sister sites via:
- FOFA
- SHODAN (Via Favicon hash search)
- Fuzzing TLD via PureDNS (ex: REDACTED.FUZZ )
5. Scanning ports via Masscan & RustScan
- I stopped over-relying on one tool and lowered the maximum packet rate as it typically leads to inconsistent results.
6. Scrape endpoints from GAU , WayBackURLS , Dorking
- When dorking I use the URL Extractor extension to parse all the URLs from google searches as I dork.
7. Exposed secrets by searching target-specific keywords on Github , PostMan , etc.
Subdomain Analysis
After cleaning up and collecting the list I realized there weren’t many subdomains this company offered. However there were two that stuck out to me the most:
- staging.Sister-REDACTED.com
- testing-ignore.Sister-REDACTED.com
The testing-ignore subdomain was inaccessible and had no digital footprint as to what its purpose was or how the website looked (was not archived in the Wayback Machine).
I shifted my focus to the staging server, I realized account takeover (ATO) may be possible if I registered an account using an email address that existed in production but not in staging. This would only work if both servers were using the same JWT signing keys. This is a common technique explained more in-depth here: https://sandh0t.medium.com/the-bad-twin-a-peculiar-case-of-jwt-exploitation-scenario-1efa03e891c0.
Black Box Reverse Engineering
Unfortunately, when registering a new account there’s an email verification sent-I could not bypass this. But then I caught myself falling into autopilot. I was just following the same checklist everyone runs through.
Why was I even trying to register with someone else’s email on staging in the first place?
Well, I told myself my goal was to obtain a JWT from staging and replay it against production. But I was getting ahead of myself, I didn’t even examine the decoded JWT, what if there wasn’t even an email field at all?
I decoded a JWT from an authenticated login on staging and it looked like this:
Side Note: If you’re a penetration tester make sure to NEVER put a JWT into a public website, regardless of what their claims are.
All decoding or tedious tasks should be done on your own machine, you can use self-hosted services such as CyberChef.
Okay… so the JWT does have the email field, but what if the server isn’t even using it. If you look closely you’ll notice the id field, what if the server is relying on this over the email field?
I confirmed this by registering multiple accounts on production and noticed it go from 50,612to 50,613, 50,614, etc. For further verification, I logged in, changed my email and noticed my JWT still had my old email address in it even though my account settings displayed my new updated email address.
Okay-that confirms my suspicions, the server isn’t even querying the email claim in the JWT anyway, it’s querying the id claim.
Furthermore, when I did attempt to use the staging JWT on prod it was denied complaining about an invalid signature. Looks like prod and staging used separate signing keys for their JWT tokens.
Poor Isolation Breakthrough
Before I gave up I clicked around on the staging domain and everything pretty much looked the same-until I went to profile settings and realized it displayed someone else’s email !
So we have ATO? Not quite. If I sent a password reset request I would see my account details and the reset would be done on my own account (within staging).
I decided to poke at the tech stack being used by this company, some common techniques use the Wappalyzer chrome extension, reading response headers sent back from the web server, and skimming any specific keywords in the JavaScript files.
Turns out this website’s tech stack was using Kubernetes, Nginx, and Envoy proxies!
Why is this important you may be asking...? Well Kubernetes can get very complex and if you’re not careful, especially when isolating the workflows for prod and staging can lead to mixups.
So to understand what may have caused this vulnerability we need to see a simple example of how user requests are handled.
Envoy runs as a config alongside each pod, meaning every request in and out of the cluster passes through it first. It reads the routing rules defined in its sidecar profile and decides where to send the traffic such as to the staging or prod clusters. It’s great for service mesh control, but one bad route and you’re now leaking traffic across environments.
I think this company’s staging servers had separate envoy proxy configurations for different API routes.
For example, in the staging server when I sent the password reset it may have internally routed my request to an internal endpoint within the correct staging cluster.
However, in the staging server, when I tried to view my user information the envoy proxy handling my request may have routed the request internally to a prod cluster instead of a staging cluster.
Understanding the Internal Tech Stack
I also realized a huge gap many bug bounty hunters have in their methodology: they’re so quick to perform subdomain enumeration, ports, etc they forget to take a step back and look at the dead domains too.
The unreachable subdomains are sometimes scraped from the domain’s SSL certificates and may hint at internal subdomains that are used by the company internally.
When looking through subfinder’s output again of both the main website www.REDACTED.com and the third party (sister site) www.sister-REDACTED.com I noticed something that stuck out:
github.REDACTED.com
bitbucket.REDACTED.com
github-staging.Sister-REDACTED.com
Interesting… this hints at the possibility of the company using their own self-hosted Github servers.
This information came in handy down the road and without it I may have been unable to piece together what could’ve caused this vulnerability.
Theory
Remember earlier when we looked through subfinder’s output and spotted github.REDACTED.com and github-staging.Sister-REDACTED.com? That strongly suggests this company is running self-hosted GitHub instances for their development workflow. This is highly likely because we saw it on both the third party sister site AND the main domain.
This matters because companies that self-host their own Git infrastructure almost always have CI/CD pipelines tied directly to it. These can be Github actions, webhooks, or automated deployments.
For example, when a developer opens a PR and it gets merged into main, these pipelines typically spin up or redeploy staging environments automatically to mirror production.
I think that’s exactly what was happening here. The staging and production servers were being set up through some automated deployment pipeline that triggered whenever the production code changed. For example, let’s say a developer at this company made a simple change to an HTML file, opened a PR that got approved, and merged it into main.
I suspect these automated pipelines were spinning up staging environments correctly but failing to update all of the Envoy routing configurations for certain endpoints. Because of this, my staging user ID was being mapped to a production user ID due to poor isolation between the two environments.
For example, let’s say after a new PR was merged to the main branch a pipeline ran that went through the production sidecar profiles and ran simple .replace() on them but failed to do it correctly for one of the endpoints for some reason.
Impact
We now have leakage of mass PII of all accounts, we can create a script to register accounts on the staging subdomain, and then scrape the account information associated with it.
We also could mass create accounts on staging with an email address we own -> check account details -> check if there are any patterns such as [email protected] and use that JWT to fuzz in hopes of finding any that are admin-restricted to further our attack surface.
Hacking a Fortune 500 Finance Company via Envoy Proxy Misconfiguration was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.