Bug Bounty Challenge Update #1

Hi everyone.

Almost a month has passed, so it is time to update how is the challenge going.

Honestly, it is not going so great. I was doubting if I should even share my progress. However, I decided to be transparent as I realized that any outcome is still an outcome.

I spent a total of 15 hours hunting.

This is a little bit less than I was hoping to spend. But the first obstacle I faced was the lack of motivation as soon as I started the challenge. The main reason is that doing this after a 9-5 job is hard psychologically. Especially when you are not finding anything, and you feel like you are wasting your “rest time”.

However, I am not giving up yet, and hope it will get better soon. But for now let’s see what I’ve tried during the first challenge hours.

Choosing My First Target

I’ve already mentioned in my previous article that I am going to hunt on Intigriti platform. The first step, and the most important step was to choose a target.

And the program that I’ve decided to work on is…

Innovapost/Canada Post + Purolator – Responsible Disclosure Program

This is a program of the Canada Post, that has no payouts for the accepted vulnerabilities.

I had a few criteria for choosing the company I was going to hunt for:

• No payouts – I wanted a program that has no monetary rewards. There are normally less security researchers working on the program without payouts.
• Number of the exposed systems – I wanted the program to have more than a few systems available.  This way the attack surface would be bigger and there would be more chances of finding a bug.
• Previous submissions – I wanted the program to have potential. If a program has just a few submissions accepted, it means that either the systems are very secure, or they are really picky about the vulnerabilities and reject most of the submissions.
• Newest submission in the last few days – I wanted to be sure that the program is still active, and the vulnerabilities are being found.

And the program of Canada’s Post seems to meet all of my criteria:

1. It pays no bounties.
2. Has three domains (I’ve also checked the subdomains, and all the domains have plenty of them), and 2 Android, and 2 iOS applications.
3. At the time I was choosing the program, it had more than 140 submissions
4. Last submission was 4 days ago.

Also a few other programs caught my eyes: Tomorrowland, Nestle, Red Bull, Bpost.

However, I’ve decided to start with one at the time.

Things, That I’ve Already Done

I performed subdomain enumeration as the first thing when I just started. For this purpose I used Sublist3r, Amass, and Subdomain Finder to make a list of available subdomains.

Subdomains of the three targets that were in scope:

• *.purolator.com
• *.postescanada-canadapost.ca
• *.canadapost-postescanada.ca

I’ve also tried the brute-force module of the Sublist3r, however, strangely during the process the internet connection had disappeared for every device connected to the same network. My guess is that DNS servers that are set in my router settings (I am using DNS servers of the ISP) have some kind of protection for DNS brute force. The internet connection was restored soon after the brute-force attack was canceled.

Each of the tools provided different results. In total I found over 100 active subdomains. 

Some of the subdomains had resulted in the timeout, some of them required logging in with Okta SSO, others were there for displaying the status of one or another application, and the others were public web applications.

I used Notion.io for making the notes of found subdomains. This is how my notes looks like:

Firstly I checked if the identified subdomains responded. If so, I’ve checked them and made short notes about what the subdomain is about.

Then I decided what I should do next. If I found a custom business website on the subdomain (ex. Parcel sending website), I tested it with Burp Suite and checked for the vulnerabilities, such as XSS, SQL injection. 

If I identified that a product or a software component was on the subdomain (ex. Okta SSO login,  default Red Hat Enterprise Linux Test Page), I’ve tried to identify version and check for the known CVEs.

For the custom websites I’ve also tried directory brute force, inspected the cookies and headers.

What Are the Results?

There are some vulnerabilities that I’ve found, but according to the program rules, these are out of scope. 

I found out that one of the applications leaks technical information in case of the server error. 

And another vulnerability that I’ve found, might be treated as a sensitive information leakage. There is a status page that shows utilization of the specific systems. This could help the malicious hackers to execute the DDoS attacks as it shows how the system reacts to increased load. Normally such a page should be accessible to the system owners only.

I might still submit them, for learning purposes, just to see how the communication goes, but these are unlikely to be accepted. 

While I would normally include them in the penetration testing report, it seems that the rules are stricter while hunting in the assets of bug bounty programs.

But again, I’ve only spent 15 hours working on the program, and part of the time was spent choosing the program. I might still be able to find bugs on this one.
Also, I’ve written an article about the problem I faced when I ran Burp Suite with my antivirus software enabled. This can be considered as a small milestone of the challenge.

What’s Next?

It looks that the approach I am currently using, is not very effective with the systems faced in the bug bounty platforms. Typical approach helps to find the vulnerabilities in typical systems, but not in the systems that are battle-tested.

Next I am going to check what type of vulnerabilities are being found in bug bounty programs. There are many public HackerOne reports, so it will help.I am also going to continue with the same scope, dig deeper, and check for these vulnerabilities (I am guessing it will be IDORs, XSS injections in complicated places).

Also, I will try to dig deeper, especially with the custom applications.

Stay tuned.

Planning the challenge – https://bughacking.com/the-160-hours-bug-bounty-hunting-challenge/