I decided to start a series about the experiences I’ve had with bug bounty programs. I wanted to first start off with the written story so that everyone could follow along with the Chapters and see the hard evidence associated to the narrative. These stories all have a crazy twist to them.
I’ll be recording a podcast for each Chapter as well so be sure to look out for Chapter 1 soon on https://www.youtube.com/jonathandata1
My name is Jonathan Scott, I’m a Computer Science PhD Student with a primary research focus on mobile malware/spyware.
I started writing code before my teens, and worked as a web developer throughout college. After college I focused on mobile app development, and then specialized on mobile security engineering.
The next few sections are part of your crash course in bug bounty programs, so just hang in there, its all needed for the story!
For all that do not know what Hackerone.com is, in short it is a platform in which security researchers are able to submit vulnerabilities or “security bugs.” HackerOne’s clients allow a safe harbor for researchers to perform penetration tests on systems, applications, api’s, etc. If a vulnerability is accepted, the hacker can be rewarded in several ways:
Name in the clients hall of fame
Swag (hats, shirts, stickers, bags, mugs, and more)
Thank you letter
Money (USD or Crypto)
There are clients that offer monetary rewards, and there are clients that do not offer rewards. For example The Department of Defense does not offer a monetary reward for valid security vulnerabilities, but doing your part to help harden the security of The United Stated of American, can be rewarding enough.
Hackerone.com is what is known as a BBP (Bug Bounty Program/Bug Bounty Platform).
Another large and well known BBP is BugCrowd. I mention them because they play a role in this True Life series.
Every 90 Days hackerone.com refreshes their 90 Day Leaderboard. This refresh gives researchers a chance to compete with other researchers around the world. The leaderboard is based on a point system. The more valid vulnerabilities you submit the more points you receive from the bug bounty platform’s clients.
A vulnerability that has been validated = +7 points
An invalid vulnerability = -7 points
My leaderboard ranking on hackerone.com for Q3 of 2021 is as follows:
From July,2021 — August, 2021, I was the #4 Hacker in the World
From July,2021 — September, 2021 I was the #1 Hacker in the USA
You will not be able to go directly to my user profile since I have been removed from the platform for disclosing what you are reading.
You will see my name as Jonathan Villarreal, but I have had a Legal Name change to Jonathan Scott.
I started hacking on hackerone.com Feb, 2020. When I was removed from the bug bounty program September, 2021 I had submitted 687 Validated Vulnerabilities.
I had only earned a total of $5,200 USD because I chose to focus on submitting vulnerabilities to the US Department of Defense. I was the #4 Ranked hacker for the Department of Defense. My overall points on the DoD program were ~4800. The screenshot below is the last one I had taken.
Aside: I was the #1 Hacker for several private programs, one of which now employs me full-time.
I am providing a bit more background about my accomplishments because I want to make it clear that finding vulnerabilities was not a new thing for me. In fact the very first vulnerability I submitted on hackerone.com was a critical for GoodRx.com.
Triage: The first post-detection incident response process any responder will execute to open an incident or false positive (Rockett,2020)
Vulnerability Severity Levels
Reports are marked with a severity rating to show how severe the vulnerability is in the report submission form. The severity rating can be seen on reports, hacktivity, and in the inbox. On HackerOne, severity is particularly useful for structuring bounty ranges and is used when offering bounty recommendations. The severity level can be marked as:
HackerOne utilizes the Common Vulnerability Scoring System (CVSS) — an industry standard calculator used to determine the severity of a vulnerability. The CVSS enables a common language around the severity of vulnerabilities (hackerone.com,2021)
I only had 1critical vulnerability validated during my time on hackerone.com. This is where it gets rather interesting though. There were many times that my vulnerability was upgraded in severity, and then later downgraded to “informational.”
GoodRx was the strangest cases of validating a vulnerability, but then closing it out as a known issue. Let’s get into it.
February 3, 2020–3:45pm CST
The Vulnerability: iOS App API Key exposure and successful server side User Data POST Request without additional authentication
In short: GoodRx’s API key was exposed and allowed me to GET/POST data for any user on their platform.
Some may say, that’s a really big claim Jonathan, but if you’re reading this, you came here because reality is stranger than fiction.
At the time my hacker handle was cleanc0de so this is what you will see in the next communications.
After reporting the vulnerability, HackerOne triage asks for more information, and I gladly provide it. I don’t have the full report, but the communications sent to my email, will be more than enough to tell this story.
February 6, 2020–12:25pm CST
GoodRx security team reaches out to let me know they will have an update on the vulnerability I submitted soon.
February 11, 2020 –9:49am CST
GoodRx sends a message letting me know that my vulnerability is not eligible for a bounty because:
“This was discovered internally before the researcher reported it to us. As such, this will be closed as resolved without a bounty.”
Hold on, wait, stop the train! Did you just message me and tell me a critical vulnerability is going to be closed as resolved because someone discovered this internally before me?Where is the change log?What is the patch version?When did you resolve this?The App version is still the sameThe vulnerability still existsWait, what?
February 11, 2020 –9:51am CST
GoodRx sends another message further stating that they had discovered this issue with internal tools prior to having a public bug bounty program. They also wrote me to let me know that again they were marking this report as resolved, and they wanted to make sure I at least earn a “Thanks” and reputation points.
As you can imagine, I was not buying this, and I was determined to fight it. I asked for disclosure if the vulnerability has already been resolved.
According to HackerOne’s own rules, if the vulnerability has been resolved it defaults to disclosure.
“Note: Reports must be in the Resolved state to default to disclosure.”
Keep in mind, my vulnerability was closed as resolved, I was given a thank you for a critical vulnerability, I was given reputation points for having a critical vulnerability resolved, and here is the TWIST.
My resolved vulnerability picked up an attribute…that attribute was DUPLICATE.
So let’s break it down now. I have a critical bug resolved, I was given a “thank you,” from GoodRx, but now my reputation points have now been taken away, because my report has been marked as a duplicate.
This screenshot is pubic and available in on my profile, but be sure to follow the directions I gave you because I have been booted and you can’t go directly to my profile.
1/9 = 1 valid vulnerability , 9 Submissions
0 = reputation points
91 = ranking for the GoodRx program
February 17, 2020 –5:20am CST
After being denied disclosure, and threatening to go public about this report, I receive a message from HackerOne triage.
They proceed to tell me that GoodRx has internal pen-tests as well, and fixing a bug takes time with all the changes, reviews, and all that jazz. They also said that it’s not wise for GoodRx to make internal bugs public. Lastly, they tell me this:
“I can understand getting duplicate for a bug is not a good feeling, but I can assure you that everything is fair.”
At this point I am in disbelief. How is this ethical? Alas, I centered myself and chalked this up as a snafu, and continued to hunt for bugs on the GoodRx Program.
I was submitting bugs on the GoodRx program one after the other. It was clear they didn’t have any mobile security engineers auditing their application, but that’s ok. The reason you become a client of a Bug Bounty Platform such as HackerOne is because you want to make sure you have a different set of security eyes on your product right? You also want to reward the hackers who helped discover the flaw right? For some clients this is true, but for others this is south and to the left of truth.
The Vulnerability: Clear Text User Data Exposure Through Error in the UI — GoodRx iOS Application
In short: GoodRx was generating error logs that contained clear text information about their user.
Name: John Doe
Medications: prescription x, prescription z
Last Fill Date: 12/25/2021
Phone Number: 555–555–555
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Likelihood Of Exploit: High
I regard the leaking of PHI (Personal Health Information) as a really big issue that needs to be resolved. Logs can cross contaminate especially when dealing with a UI error. The possibility for those error logs to be sent to another developer unaffiliated with GoodRx is very likely.
TestFlight is a good example of how a developer can request a full dump of the devices error logs, and gather all data unrelated to the app they are developing.
“[TestFlight]Collects crash logs from apps and app extensions running on user devices”
Feb 7, 2020–4:53 AM
My vulnerability was closed as informative by a HackerOne triage member. They stated:
“Thanks for your report. Based on your initial description, there do not appear to be any security implications as a direct result of this behavior.”
When triage asked me for a working proof-of-concept, I was pretty shocked. I had presented a proof of concept in my original report, but ok i’ll further exploit this vulnerability and add more definitive evidence.
Feb 10, 2020 — 1:27 PM
I would love to see the look on everyone’s face after you read this next part.
After 3 days of evaluation time GoodRx security team response with the following:
“I hope all is well. We have reviewed this report, we noticed that our internal tools discovered the issue described by the report you have submitted a few weeks before you have reported it to us.”
At this point I am facepalming, and on my knees now hands extended saying WHY!
This part of the story speaks for itself…
May 11, 2020–1:28 AM
bugseeker closed your report
LDAP Injection — Arbitrary Data Exposure as N/A
The HackerOne triager was so upset with this vulnerability, they proceeded to say the following:
Before submitting the results from a scanner, please take a moment to confirm that the reported issues are valid and exploitable with business impact.
I was scratching my head as to why this triager would be so rude and act as if I had no idea how to search for security vulnerabilities? Reading through the next email that was sent to me, i’m pretty confident I snapped back, and said something along the lines of do you even know what an LDAP injection is?
This response will go down in True-Life history.
“I am well aware of LDAP injection. The first thing the internal team informed us that they don’t use LDAP anywhere so, I don’t think it would be possible.”