HackEvent - My Experience

As a member of BugBountyHunter, First Blood HackEvent was one of their latest events to take place. We’ve had numerous events which were called #hacking-fridays in the past where Sean(creator of BugBountyHunter) would walk through some of the hardened programs and talk about his approach to finding vulnerabilities. These were great sessions as they always helped to understand how Sean’s thought process and it’s definitely helped me tweak my thinking when I’m looking at websites. These sessions gave me a huge boost in my confidence while tackling some of the public programs that's been around for years. I’ve almost always preferred hacking on private programs with the same obvious reasons that everyone else had. “Less crowded, more possibility to find bugs?” While that was my thinking, after spending some time on public programs, I can definitely say lots of public programs aren’t explored as much as I thought to be.

This time, Sean decided to do something different. While the sessions were great, this time he just didn’t want everyone to just watch while he’s hacking. Though people helped him with interesting behaviors, recon, and whatnot, he wanted everyone participating in the event to actually ‘hack’ at the same time which creates a hands-on-live-hacking experience similar to HackerOne Live Hacking Event. Not everyone gets a chance to participate on a LHE, Sean also wanted us to experience how an actual live hacking event looks like.

So Sean spent a few weeks building up an exclusive web application from scratch just for this event, he built them with some of the real-world bugs that he's found and announced on our discord that the date for the next event would start on May 9th. There would be 7 complete days for participants to understand how the web application works and report vulnerabilities in that timeframe. Another good part of this is, bounties are up for grabs if you’re the first to report it. Even duplicates would be paid under his own discretion. As soon as the event ends, participants get to understand what bugs they missed and reflect on how they could’ve done better which is one of the best ways to learn IMO.

It’s May 9th, watching his YouTube stream for the opening ceremony and discuss the rules for the event. Web app dubbed “FirstBlood” went live. At first glance, it looked like it was designed to mimic a hospital where you can book appointments and such.

I decided to spin up my instance and rushed to the web application. I tried to understand what the web application was all about. I observed a login panel for doctors, an endpoint to create appointments as well as an endpoint for patients to manage the appointments that they’ve created. Honestly, I hit a wall so quickly, I spent an hour or two but these were the only features that I could find. I saw that patients could also attend events called “HackBack” but they didn’t really seem that interesting to me.

While hunting on bug bounty platforms, once I understand what the web is all about, I usually start messing up with the login form for hours. There can be so many things that can go wrong and if implemented incorrectly can lead to big impactful bugs. I decided to take the same approach here.

Fired up my burp and logging all my requests, I wanted to know what the login form is all about. I looked at my burp history and only a single request was made to the login endpoint. I didn’t suspect any weird behavior at all from the login form. At this point I didn’t have any credentials, so I knew that I’d need to find some way to be a doctor to get in. I decided to modify the request and see if I can really get in with my plans of bypassing authentication - I tried a bunch of things to trigger some unexpected behavior such as manipulating cookies and what not but nothing really worked.

I decided it’s time to move on and play with the next feature. Making and managing appointments. I found a bunch of text fields, first obvious thing to try would be XSS and see if it gets reflected while trying to manage the appointment. But honestly, I don’t really test for XSS at the beginning. I just kept that in mind and added it to my notes. As soon as I noticed this feature, I really wanted to break this - i.e to find a way to leak arbitrary appointments that could leak PII details.

To do that, I created an appointment and looked through the request and it seemed like a simple POST request and was checking for the validity of certain fields server-side. I don’t see anything fishy really just yet. If you’ve included the necessary fields, you’d receive a GUID that can be used later to manage that appointment. I went to the manage appointment endpoint and used this GUID to track my appointment, all good. Intercepting the request while managing the endpoint, I tried a few other things to see if I could access any other appointments such as replacing that GUID with an integer value and etc. Again, all my plans failed.

I wanted to move on again concluding there’s nothing wrong with the previous feature that I tested. Looking at the events tab, it said that the event ended and there wasn’t really much to do here as well. Now so far these are the only features I could find and nothing really worked. I knew Sean wouldn’t make it easy and it was really testing my skills to dig further. Had it been an actual bug bounty program, I’d have given up by now.

I decided to look through my burp history again and no endpoint really seemed to be worth investigating anymore. I really wanted to keep going but I had to sleep early since I had to get an endoscopy done the next day early morning and I didn’t want to take more stress.

Closing all the tabs one by one, I thought of just reading the policy again on bugbountyhunter and Oh boy, I couldn’t believe it. The doctor credentials were actually given. Well, I’ve always told people in the past to read the scope and policy at least 3 times before starting to even test it. In this case, I’ve failed to follow my own advice and that really hit me lol. Quickly I opened a new tab logged in with the doctor's credentials and found a quick IDOR with like 2 minutes of looking. I reported it and went back to sleep as I couldn’t delay it any further. As I was lying down on the bed, I was just thinking to myself ‘wow, had I spent 5 minutes reading the policy, I’d had much more to play with xD'

May 10th, got my endoscopy done and I had a good sleep for the most part during the day as I was sedated. I got up in the evening feeling better, I was just eager to know what’s more in the doctor's panel. Enumerating more on the doctor's panel and just fiddling with it, I found a few more bugs leaking PII. From here on, all I did was to keep enumerating all the features. I also kept writing notes for what all I could find interesting behaviors, for finding one of the bugs my notes really helped me.

Looking through the source and trying to go through javascript, I found an endpoint called /drapi/sitesettings but it returned an error (404 not found). This reminded me of something and I just tried adding an extension to it, most obviously being sitesettings.php since the site was developed on Laravel. Upon doing that, I got a 200 response which looked like a request header but I’ve no idea where to use it. I took a screenshot of it and just added it to my notes.

Later that day, when I was revising my notes, I recall the feature where patients could attend events known as ‘HackerBack’ which also had an endpoint where you could possibly query for people attending the events but it would always return a blank response. I saw this header in my notes and instantly decide to try it and boy was I delighted, with the help of the header, all the members attending the event were leaked with their PII info. Just wanted to highlight how valuable note-taking can be and to always add to your notes what you may find interesting, you never know when you might be able to chain it! 🙂

Here's a glimpse of how I've taken it down:

If you'd like to read more about my note-taking methodology, give this article a read: https://www.bugbountyhunter.com/guides/?type=notetaking

Well, I’ve probably found 7-8 bugs at the end of my second day and it was way better than my first day of hacking. With digging each feature, I’ve found something to play with that has lead to bugs and I’d say this was an incredible learning experience.

Overall, I’d say it was a great experience, I’ve learned loads. Though I’ve always read the scope & policy when testing an actual bug bounty program, this time I’ve failed reminding me to not rush. Once the event ended, the disclosed reports gave me additional insights into the bugs that I’ve missed. I’ve probably missed 5-6 bugs and some of them were right in front of me which again proves that bugs exist if you look at it from a certain angle. People have been really creative with reports and that has definitely helped me to keep more things in mind while performing security testing assessment and I’m sure other members would've felt the same. Lots of talent in our community and I’m sure they’re all going to crush bug bounty programs soon :)

If you haven't tried FirstBlood yet, I'd highly recommend giving it a try (https://www.bugbountyhunter.com/hackevents/firstblood). No matter what level you are at, I'm sure there's something to be learned.