My methodology during Firstblood

Hello everyone
From the 9th to the 16th of May the first live event of BugBountyHunter took place, namely Firstblood.

Of course I participated. For this first event I was in collaboration with my bugbounty mate Serizao, but I greatly thank's all hunters I exchanged with during the event. I strongly believe that collaboration is the key, and the proof is that this is a team that finished on the podium.

To return to the target, it was only 1 domain. The website was rather simple, not 10 000 pages nor 200 features but had 17 bugs (16 voluntary and 1 involuntary).

• 1 open redirect
• 5 Reflected XSS
• 3 Stored XSS
• 2 IDOR
• 2 Business logic error
• 3 Auth issue
• 1 information leak

Before starting the event I set myself 2 goals

• Find all the bugs except XSS (this is not my favorite bug)
• Don't use any tool except burp and don't use any "active" extension

For those who are curious, here is what I disabled :

Although I did not finish first, having accomplished my goals, I wanted to share my method of approaching the target in hopes of helping some and also attracting others to come participate in the next event !

No specific instructions were mentioned outside the application and an administrator account provided to access the authenticated area. So during the first hours I didn't try any injections, while some people submitted their first reports I wanted to understand how the target works, to play with each feature and to understand the connections between each of them.

I think exploiting a vulnerability is only the smallest part and as you can access the target and all the reports, we will not dwell on the discovery of each bug but rather the process that led me to discover them.

I'm not someone who takes notes, I simply browse the target with my eyes open and I retain things, for this article I made the effort to create an schema of what represents my methodology of recognition of the application that can be divided into 4 parts:

• Step 1 - Directly navigable pages (without the pages accessible by Fetch/XHR requests or hidden links)
• Step 2 - The secondary pages (visible from a Fetch/XHR request or a hidden link)
• Step 3 - The connections between its pages
• Step 4 - Identify features on which I already have test ideas to do

This diagram does not contain all my notes and does not allow to find all the bugs but the idea is there and by applying this methodology with my mate we could find all the bugs (except XSS) without too much difficulty.

Many people said they didn't know what to test or do after only a few hours, for my part I spent about 15 hours hunting on the target during the event without having 1 second where I didn't have an idea of something to test, to retest, or to retest. Each time differently

Some bugs are related to privileges, for example I played with each feature using different privileges or different headers/cookie that the application applied at times.

More bugs explaination

As said, we are not going to dwell on all the bugs, let's keep some mystery for those who would like to try the challenge after reading this article.

1. The simple but critical bug: If we go back to the diagram, in point n°0 I noted to check if interesting public information is available on the taget. As I had identified the use of an API I first started my research on Github to see if it was possible to find a code leak or a secret key.

Not having found anything, I simply typed the name of the site on Google.

The first results concern a Reddit post, a user named JollyHack has created a post indicating that he can not create an account on the site despite having an API key and that contains the message of the user ? the API key in question.

This key allowed to register on the site and to have access to the administration area. A simple but critical bug.

2. Understand the application and bugs you will find : One of the main features of the site is obviously the possibility to make an appointment for a patient and to visualize it for a doctor.

The most important features are naturally the ones that normally have the most security on a site but also the ones that will be considered as high/critical in terms of impact if a bug is detected.

After creating my first appointment, I was given a number, this number could be used to view/modify/cancel my appointment, so I already had in mind the idea of wanting to modify or view another user's appointment and thus access PII.

The generated ID was long and complex, so bruteforce or guessing was not possible and I did not find any unauthenticated place to get this ID.

Using the information from this article (which I advise everyone to read, several times) :

"First of all, the problem is not with the object reference (the ID), but the lack of an authorization mechanism that validates whether an object should be accessed by the logged in user.

Secondly, there were some ideas to implement a “Secure Indirect” mechanism that wraps the application and solves the problem by replacing raw IDs with unique IDs.
The idea says that the backend needs to maintain a table that translates between raw IDs and random, user-specific IDs"

By observing the display of reservations on the admin panel, we find ourselves in exactly the second case. The application has a mapping between the complex ID and the simple ID. So the idea is to use this simple ID on which you can easily iterate rather than the complex ID.

So I replayed my query by replacing the complex ID with the corresponding simple ID and bingo, the query was valid. By iterating with the intruder, I could access the appointments of the other patients.

3. Not all roads lead to Rome : It would be too easy to talk only about the aspects that led to the discovery of a bug, if I spent so much time on the target it is because I also found myself facing a rabbit hole.

I was indeed convinced that a part of the site was vulnerable. If we go back to point number 6 of my diagram, I indicate that an insert is present on the administration index. I wanted to be able to include data there to see what it did and how it was managed. So there were two ways:

• Modify one of my or another user's appointments to be displayed here
• Modify data that is already displayed

For the first case I suspected a hidden parameter or an additional value to be specified. When canceling, there was a parameter action=cancel, maybe another value could be provided? unfortunately after many attempts, I settled on option 2.

I knew that it was possible to modify the appointment of another user, thanks to the bug explained previously, I knew that it was feasible via the simple ID, so I just had to list the existing IDs and see if an ID matched with the information in the insert.

After a few minutes of running the intruder I could see that two IDs had this information

• 56910419
• 56910619

Unfortunately after an attempt to modify it and other tests I had in mind I understood that it was not modifiable. Too bad, I had lost more than an hour on this :D

What I thought about the event?

I think the most interesting part of the event was the knowledge exchange and this made sense at the end because all participants were allowed to disclose their reports. At this point it was possible to learn from the knowledge and methodology of the other participants.

For those who are interested, the disclosed reports can be seen here : https://www.bugbountyhunter.com/hackevents/firstblood

Reading these reports also makes it easier to realize what we should do next time, for my part try to identify the parameters of the target and replay them on different pages in different contexts.

I would obviously have preferred the inclusion of more server side bugs (SSRF) or logic bugs or complex authorization cases. But creating such an event is not easy, you have to be able to create the target from scratch and include vulnerabilities in a controlled way.

For a first event I think it's a total success. And the next ones will certainly be even better ;)

Conclusion

This first event shows the bright future of bugbountyhunter. It was possible to see during this week that many hunters have learned a lot in a few months and some of them have gained confidence to launch themselves on real targets and earn a few $$$
Over 260 reports were submitted in one week, which is pretty crazy for this target.

Of course I can't wait to see the next event. So if you're just starting out, or not! come sign up on bugbountyhunter to deepen your skills or test yourself while sharing with an amazing community.

Stay tuned !