Bug Bounty Nightmare: Company Banned Me to Avoid Paying

I've been an avid bug bounty hunter for the past few years, and I've found my fair share of bugs from all classifications. One thing I've noticed along my journey is that some companies pay better than others, and some treat their hunters better than others. One thing we often overlook as bug bounty hunters is that until we get the bounty, we are essentially working for free.

Now you may say "Well that's just part of the job, companies don't pay until you find something." That's true, but what happens when they don't pay?

The Discovery

Imagine you are me for a second. You have spent 10+ hours doing passive recon on a target you selected from HackerOne, testing with handwritten scripts and manual testing in the browser, and finally you stumble across a high severity security flaw in a companies system. The next step is to verify the finding, in my experience I double and triple check before reporting. You then write a report about what you found, and include any and all evidence showing how you found it, then you pass it off to the triagers.

This is the process I followed when testing a popular adult cam site. I had found an authorization flaw, which with my skill level I was able to to gain unauthorized access to a private, paywalled stream. Before finding this exact flaw, which was the key aspect of my submission, I was able to enumerate 9,548 users with information like country, visibility status, username, user ID and more. All without any rate limiting and just by soley interacting with the API by querying it and using pagination. After that, I wrote up a basic shell script that would send requests searching for a models private stream, and alert me when one was found. Key thing to note here is that the shell script only searched for private models. I went out of my way when writing it to make sure it wasn't returning any results for public model streams.

The script would run on a loop, and provided me with a link to the broadcast, which was streaming over a CDN service, and included a media player. I opened it in my browser without needing to log into the website, meaning I was unauthenticated since I used an Incognito tab to make sure none of my stored browser cookies were being used to authenticate my access. Some inexperienced people may think that this isn't a security flaw, so let me explain a bit further why it is.

What made it a security flaw is what I mentioned before, my shell script searched for URL's, and it was querying only private model ID's. I tested both public and private shows, and what I found was that in both cases, the media player would show, but only the public streams would play after I clicked the play button, the private ones would still show the media player on the page with no other content, but upon looking in the Console tab in Developer Tools, it would show a 403 status, which wasn't the case for public streams.

Any competent security tester would look at this and go "Yep, that shouldn't be happening." Not just the ability to play private streams unauthenticated without payment, but the ability to enumerate that much user data without authentication or rate limiting, which led to this discovery in the first place. An attacker could take all of those usernames, and throw them into a password cracker and perform credential spraying/stuffing. The possibilities if this was to fall into the wrong hands are endless.

I do also want to mention that this particular platform has been involved in multiple data breaches in the past, which they decided not to disclose to their users, and has been fined by the Cyprus Authority for failing to protect user data. This just goes to show that this platform does not care about privacy and is shady and unethical!

The Report

Now back to the vulnerability, after finding this I spent a few hours putting together my evidence and writing a detailed report, including steps to locate and replicate the vulnerability. I want to note that this specific program is not triaged by HackerOne, it's the security team of the website doing the triaging. That being said I made sure to leave nothing out, used technical terms but also translated them into terms someone who isn't familiar would understand, and I even provided them with the exact scripts I wrote that aided my discovery of this vulnerability. I felt very confident submitting this and figured I'd hear back quickly considering the severity, which had a CVSS of 8.5.

Then I heard back:

"Please, provide a video PoC of you repeating the steps from your submission and successfully playing private stream."

I noticed my original report didn't contain a video file, so before I recorded it and reproduced it again, I also confirmed with them if they wanted me to record the user enumeration as well, and I got this response:

"User enumeration is not a security issue as information about models is public. We are interested in your demonstration of a private stream playback."

Okay, totally fair. I tried to reproduce the vulnerability so I could record it, but that's when I noticed something weird, the CDN resolver was not the same as it was at the time of initial discovery. This made it impossible to replicate.

I replied to their comment with this:

"While verifying today, I noticed a partial fix seems to have been pushed. The media CDN now correctly returns a 403 in the browser console tab for private streams, blocking the video playback. However, the edge-hls playlist is still accessible, video playback window is still showing, and the API is still leaking the private model data without authentication."

I was a little frustrated with them at this point, I've found many similar bugs in systems before and provided less evidence than this and been paid in less than a week. Nonetheless, I waited for their response.

This was their response to that comment:

"There were no changes made to the code base. Please, provide us a video proof where you demonstrate that private stream is going on our website, and then you accessing private via your exploit. Otherwise we can't verify if your video demonstrates an actual private stream."

Loud and wrong. You did change it, I have photo proof that is timestamped.

Here was my response:

"Thanks for the clarification. I understand there were no code base changes, but upon trying to reproduce the finding today and being unsuccessful, I checked what the original URL pattern was and noticed something worth mentioning.

At the time of discovery, the private stream URLs were resolving through "edge-hls.growcdnssedge.com", and the stream segments played successfully in my original timestamped PoC. As of today, the same private stream URLs are resolving to "edge-hls.saawsedge.com", which now returns 403 on segment requests, which is different than before at the time of initial discovery. I've attached screenshots showing this change in URL resolution.

This appears to be a CDN resolver or delivery-path change rather than a code base change, and it now enforces stricter access controls than what was present at discovery, making it not possible to reproduce. I feel that it is both best and fair that this report be evaluated based on the environment and behavior present at the time of initial discovery, as reflected in the timestamped evidence I have already provided.

This vulnerability still meets High/Critical criteria. I have already provided video evidence showing the original exploit result, and I have now also provided screenshots showing the CDN resolver change. At this point, I have provided all evidence available from the original discovery, so please advise on the next review step."

To which they replied with:

"Hello,

All CDNs are identical. Domain depends on what CDN was used by the model yet it does not affect the business logic. At this point you haven't proved your claim from original submission. Are you able to access private streams or not?"

My reply to this nonsense was:

"Yes, I was able to access private streams at the time of discovery, and my original PoC shows that if you watch the video and read the report. The API command directly queried live private models and displayed their links as shown in my PoC, so please clarify what part you still consider unproven.

I also don't agree that "all CDNs are identical." If the CDN host depends on the model, then the behavior is not identical in practice. In my testing today, one hostname blocked access while another still allowed it, which shows the security behavior differs across models. If sawedgecdn now returns 403 for private streams in the browser, that should be applied consistently. That is exactly why the original playback evidence matters."

The last reply I recieved from them after this was as follows:

"Hello,

We believe you have accessed public stream during your first discovery. There are no differences between CDNs and no changes to codebase were made. Are you able to access private streams? Describe us step by step how you access it and how you obtain access key to access stream."

Weird how before you said the CDN depends on which one the model connects to but now there is no difference in the CDN's? Mhm.. Okay buddy.

The New Proof

At this point I was pissed off, so I took a week to cool down and read some write ups about companies with similar infrastructure, and what documented vulnerabilities exist for the particular system they hosted their streams on. I've been doing bug bounty long enough to know that in order to get big payouts, you have to fully understand the attack surface and think outside of the box sometimes when you are stuck, and that's exactly what I did.

A few nights ago, I came across an article online that was talking about the possibility of injecting a JavaScript payload into the browser console to bypass 403 status for streams hosted on a CDN resolver. I wrote up a payload, and ran my original script again to find the link to a private models stream. I even verified that this model was in a private show by visiting their actual URL and including the user ID. All of this was recorded on video. It worked, and I bypassed the 403 and was able to play the stream. I let them know about this, and posted this comment to the report:

"Following up on my previous report, I was able to capture a proof-of-concept video demonstrating unauthorized access to a private stream via the exposed stream URL, except this time I tried something a bit different to get the result.

Here is video proof, showing a 403 status and a payload i've written to gain access to a private stream without payment or authentication. I have a shell command that pagnates for private models, and excludes public stream links so there is no possible way I am accessing a public stream. I wrote a Javascript payload which you will see me paste into the browser console that loads the video and bypasses the 403 status.

I believe this clearly demonstrates the issue. Please let me know the next steps."

The Ban

Overjoyed and ready to put this entire situation to bed, I submitted the new evidence. Within a few hours, I was notified by email by HackerOne that the program has "elected to ban me from submitting new reports to the program" with this nice message included from the company:

"Liars are not tolerated. You were trying to trick the system by misdirecting triage team via id substitution."

I'm literally laughing so hard…ID substitution had nothing to do with my report. This is very clearly an excuse to not pay me, the researcher. It's very convenient that I was banned hours after submitting exactly what they asked for, especially after the back and forth and moving goalpost I had to endure for almost a month. This just goes to show you that this company cannot be trusted. I also took a look at their Hacktivity tab on HackerOne, and noticed they haven't made a payout larger than $500. This would have been eligible for their top payout, which was $3,000.

What's Next

I have since escalated this issue to HackerOne, with all of my evidence and correspondence with this program. I intend to keep fighting them on their decision not to pay me until I either get paid or come to a resolution. This is a real security flaw that not only makes their users lose money, it violates regulatory privacy laws set by the GDPR (EU), PIPEDA (Canada), and CCPA (California). Sadly, there is still a chance that I will not be paid for this finding. If that happens, I will move on and never engage with a small, sleazy program like this one again. This is not an uncommon occurrence in bug bounty, and almost every hunter who has made a respectable amount of money has experienced this at least once, and I suppose it was my turn this time.

To Other Companies

To any programs out there who don't want to pay their hackers properly, you should think twice. Most if not all hackers are intelligent, and it's not wise to insult our intelligence by low-balling or scamming us after we find bugs, then banning us when you can't afford to pay according to the severity. Bug bounty programs aren't a way to get free labor. If you think they are, you're wrong. One day, you will piss off the wrong ethical hacker and pay for that mistake with your business's reputation and more. Nobody will want to hunt for you anymore, and word spreads fast in this space about programs that scam people or treat their hackers unfairly.

Has this happened to you? Share your experience in the comments. If you're a hunter dealing with a shady company, let's talk about how to handle it.