Intro

Hello, I'm Omid, a 22-year-old enthusiast diving into the world of web application hacking for nearly a year and a half now. I'm currently hunting for the Voorivex team, a group of people like me who have the same interests. You can read my first write-up about command injection here:

Today, I'm excited to share my journey as a full-time bug bounty hunter over the past three months. I'll discuss disappointments, challenges, notable events, and, of course, the successes that have shaped this exhilarating adventure.

Methodology

In my initial year of engaging in Bug Bounty programs, my primary approach revolved around extensive reconnaissance (Wide Recon), comprehending the company's infrastructure, and identifying private subdomains and IPs for vulnerability testing and bug discovery.

So much of my time was spent in terminals, procuring new servers, actively utilizing various tools like running Nuclei, DNS brute force techniques, and continuously learning and experimenting with new methods to effectively map the company's infrastructure.

With this methodology, I managed to earn around $6K in my first year. While it may not seem like a substantial sum, considering I started from a $0 salary, achieving this milestone brought me immense joy and a sense of accomplishment.

After a while, I realized I had gained a solid grasp of Wide Recon and decided it was time to shift my approach to Narrow Recon. This involved understanding specific applications and diving into various flows such as Authentication and Payment flows. In this phase, it was just me, Burp Suite, and the application, focusing on a more detailed and targeted analysis.

July, August

I began selecting targets with limited scope (something like *.target.com or target.com) and applied my narrow recon approach.

and this is the result of 2 months of working on various targets.

as you can see there are:

• Triaged: 6

• Duplicate: 8

• Informative: 4

• N/A: 7

• All: 25

• Bounty: $350

I've been putting in almost daily effort, but the results over these two months were not what I had anticipated. This can be attributed to encountering unexpected challenges.

Let me begin by explaining some of the reports in more detail:

Then, on the first day of July, I received a notification from my monitoring script that a program had added some assets to its scope.

So, I promptly opened Burp Suite and began working with the new assets. Within a span of 5 days, I identified 2 Critical, 1 High, and 2 Medium vulnerabilities. Let's cover the flow of a few of these findings:

• PII Leakage:

  1. During sign-up attempts in applications, HTTP requests were captured.

  2. If an email used for signing up already existed in the database, the application would respond by exposing the user's Personal Information.

• PII Leakage 2:

  1. The application featured a collaboration functionality allowing users to add collaborators to their accounts.

  2. Within this function, a suggested option was available, displaying a list of users based on the input (e.g., entering "victim").

  3. However, this endpoint not only loaded names and emails but also exposed addresses, phone numbers, and other personal information of the users.

• Reflected XSS:

  1. The application included a subdomain, admin.target.com, housing a sign-up functionality.

  2. I initiated fuzzing on the sign-up page using a wordlist of JavaScript variable names.

  3. During this process, I observed that a parameter name appURL was being reflected within a script tag.

  4. I took advantage of this reflection by injecting the payload </script><script>alert(origin)</script>, successfully triggering the desired alert.

• Reflected XSS Lead To ATO of Admins:

  1. Leveraging the Reflected XSS discovered in the previous report, I successfully executed an authenticated HTTP request to the subdomain named admin.target.com.

After submitting all of these findings to the program, they confirmed and acknowledged two of the vulnerabilities. However, they marked three of them as N/A (Not Applicable). Upon inquiring about the reason for this classification, I was informed that the asset on which these vulnerabilities were found was mistakenly added and did not belong to their scope.

I sent some messages to them about their mistake and emphasized that it was not my fault. However, they did not respond to my messages.

Even after approximately 3 months, they haven't paid for the two triggered reports. Regarding the reports marked as N/A, they sent a vague message, and I am still awaiting a clarification.

After this discouraging experience, I felt somewhat disheartened and decided to cease my work with Bugcrowd. I was optimistic about transitioning to HackerOne, hoping for a more positive experience. Unfortunately, my expectations were not met, and the experience there did not unfold as I had anticipated.

I engaged with multiple programs on HackerOne, dedicating evenings to testing and reporting vulnerabilities. Despite changing my target often, I encountered numerous duplicates and cases marked as "Not Applicable." Some of my reports were indeed valid, yet the program responses were not consistently prompt.

Self-Assessment & Debugging the Mindset

After investing two months of hard work without receiving any significant rewards, I became increasingly disappointed. My mental fatigue reached a point where my cognitive abilities seemed to diminish, making it challenging for me to cope with the situation effectively.

In this challenging situation, I decided to take a few days off, during which I refrained from opening my laptop.

After a few days, I returned to work, but this time I shifted my focus away from web applications. I resolved to investigate the root of the problem. Several pressing questions weighed on my mind:

• Do I know enough for bug hunting?

• Can the platform affect my success? if the answer is Yes, Why hasn't it gotten better with a new platform?

• Am I doing okay, or just unlucky?

I turn my problems into questions, then seek answers by asking experienced hunters and searching through resources like YouTube, Twitter, and more. I'll share some of the very helpful resources.

• I found a helpful YouTube playlist by Grzegorz Niedziela where he discussed his transition from a pentester job to bug bounty hunting. He shared the challenges he faced and how he successfully handled them. Link.

• I came across a tweet by Hazem, a skilled hacker, where he shared the outcomes of his bug bounty efforts for August, focusing on a single program.

  

  • I sent a message to Justin Gardner, and without much introduction needed, I explained the situation to him. He responded with a message.

• I sent a message to Mohammad Zaheri, another skilled hacker, to gain insights into their mindset and how they manage high-pressure situations. Mohammad shared some valuable tips on setting goals, avoiding burnout, and staying productive, and some useful tips like that.

So, the takeaway from learning from them is to:

• Focus on a single program.

• Set a clear goal.

• Begin a specific challenge.

• My knowledge might not be perfect, but it's sufficient to discover things based on previous findings."

• Sometimes it's just a matter of luck, but you can enhance your odds.

September

I learned something new and decided to start a 30-day challenge in September. I set clear goals and began by choosing a good program.

I'm often afraid of programs with attractive bounties because I think skilled hackers are already working on them, leaving me with little chance to find vulnerabilities.

After a few days, I found a program that looked promising based on its bounty table and response time. I chose to focus on that one.

after that set clear goals for myself based on bounty and reputation.

and this is the result of the 30-day challenge:

• Triaged: 9

• Duplicate: 3

• Informative: 1

• N/A: 1

• All: 14

• Reputation:

• Bounty: $9240

As you can see, my debugging works and finally my dedication is paying off, and I'm thrilled about it. I've even started rewarding myself by investing in upgrades for my workspace. As a result, I've decided to write an article about my experience and share it with the community.

So let me explain some flow of vulnerabilities I have found for you:

1. CORS Misconfiguration

   • The hosting allowed to register an arbitrary subdomain, arbitrary.targetsite.com

   • There was an API on api.target.com with CORS-trusted .*.arbitrary.targetsite.com

   • Exploited the PII information leakage → JavaScript PoC provided

   • The program denied it since the Cookies were Lax on Chrome + Firefox protection was ON by default

2. Cache Deception

   • An endpoint was vulnerable to Cache Deception, https://dashboard.target.com/my-profile/username/.css

3. Business Login Error

   • I found a subdomain called payment.target.com where I could buy a new domain

   • The site was checking if the domain had already been registered or not

   • By response manipulation, I could make an invoice for a registered domain

   • However, after purchase, I could not change the DNSs (if I could, it would be a critical domain takeover)

   • I couldn't find a significant impact, so I reported it as having no serious consequences, marking it as a "Best Practice issue"

4. CSV Injection

   • There was weblog-builder.targer.com subdomain to connect my domain and create web pages

   • The website had a feature that allowed users to send messages to the admin through a content form

   • The admin could export the messages from users as a CSV file

   • When an attacker sends the payload =4+4 to the admin, the exported CSV file would print 8

   • There wasn't any significant impact. However, I reported it to the team

5. HTML Injection

   • There was weblog-builder.targer.com subdomain to connect my domain and create web pages

   • The website had a feature that allowed users to send messages to the admin through a content form

   • After each submission, the admin received an email containing the name of the user who submitted the contact form

   • If an attacker sent a value with HTML tags like <a>, the admin received a rendered version of HTML in their email

   • So I reported the vulnerability as "HTML Injection in Email"

6. Weak Implementation of Password Protect Function

   • The website weblog-builder.targer.com had another feature that allowed the admin to protect some pages with a password

   • This feature uses client-side protection, making the data accessible in the DOM

   • I submitted this vulnerability as HIGH impact, but the program downgraded the severity to LOW and they sent me this message:

     

   • I responded with this message:

     

   • They accepted my message and responded:

     

7. Access to Unpublish blog posts

   • The website, weblog-builder.target.com had an additional feature that enabled the admin to create a weblog post and publish the article

   • The feature had two viewing options: public or private. Private articles were not accessible to other users.

   • I was able to send a request directly to the private posts, which then loaded and became accessible to me

   • The private addresses were guessable, so I reported the vulnerability

8. 2FA Bypass with Authenticate Cookie

   • Let me describe the authentication flow:

     • Upon opening the login page, an anonymous session is initiated

     • After entering the credentials, the session is upgraded, and you are redirected to a "converter page" (I named it this because the page serves as a session-to-token converter)

     • The page converts the session ID into a JWT token

   • Now let me describe the authentication flow + 2FA:

     • Upon opening the login page, an anonymous session is initiated

     • Entering credentials leads to a redirect to a page at /login/key/random_key

     • After entering the credentials, the session is upgraded, and you are redirected to a "converter page"

     • The page converts the session ID into a JWT token

   • Now, let me explain the vulnerability and attack scenario:

     • Browser A: The attacker opens the login page and enters credentials for an account without 2FA

     • Browser B: The attacker opens the login page and enters credentials for the victim who has 2FA enabled. Consequently, they are redirected to /login/key/random_key

     • Browser B: The attacker substitutes the session ID with Browser A's session ID and refreshes the page

     • Browser B: The converter page generates a JWT for the attacker, enabling successful authentication as the victim who has 2FA enabled

9. Pre-Account Takeover

   • On the website's registration, you can register an account without the email verification process

   • So I could create an account with an arbitrary email address, for example victim@gmail.com

   • When the victim first attempts to sign up with victim@gmail.com, they receive an error message stating that the account already exists

   • If they then try to sign up using Google OAuth, as an attacker, we can access the account with the previously saved token

10. Reflected XSS Leads To Account Takeover

    • Enabling 2FA authentication for an account

    • Extracting the parameters in the 2FA page, /login/key/random_key → some parameters

    • I re-used the parameters in the previous page /login/key/random_key and got the reflection

    • I broke the tag and got a reflected XSS

    • I coded an exploit code to grab the JWT token of the victim

11. Account Takeover with Grant Access

    • Let me describe the normal flow of a feature:

      • The target.com website featured a function that enabled users to request access to another account and manage it

      • Upon entering a victim's email, they receive an email confirmation

      • If they click on the link, the attacker can access and manage their account

    • Now let me describe the vulnerability:

      • By entering into the victim's account, the attacker can grab their authentication token and save it (normal behavior)

      • Sadly, if the victim revokes the access to their account, the previously authenticated token will still grant you access

12. 2FA Bypass with Grant Access

    • Considering the previously granted access flow, please continue reading

    • If an attacker requests access to another user of the website, they get an email (previous flow)

    • If an attacker requests a non-registered email, an email is sent to that address. Upon clicking the email link, the user is automatically redirected to the panel, and an account is created for them

    • The attacker enters an email address with an extra dot, like victi.m@gmail.com and the backend treats it as a new user. Instead of sending a confirmation email, it sends a link, and when clicked, it redirects the attacker directly to the panel

    • What is the impact? The attacker must gain access to the victim's email for successful exploitation. However, in this scenario, the attacker could log in directly to the victim's account and bypass 2FA enabled feature (Goole Authenticator)

Conclusion

From my experience three months ago in bug bounty, I realized that it's not just about technical knowledge. While that's important, mental growth and development are equally essential, In this article, I was trying to talk about both of them.

Another valuable lesson I've learned is the importance of connecting with experienced individuals and seeking their guidance. I'm grateful to be part of a community where such people exist, helping each other.