The History Behind My First Bug

Today, I want to tell you the history of my first bug. Actually, it was not only one but a double bug.

Last year, when I started hunting for bugs, the first bug (a double one) I found was a Client-Side Template Injection which became a Stored Cross-Site Scripting (XSS), and I was able to steal admin cookies and hijack the admin session, allowing me to perform a session hijacking.

It was a program in the Synack Red Team platform. This was a brand-new target, so you can imagine the competition.

As it was a brand-new target, other researchers were throwing many payloads, hoping to pop an XSS. But, seeing all the payloads that people were using, I realized they had forgotten the famous {{7*7}}.

If you’re unfamiliar with this payload, it is used to identify if a target is vulnerable to some sort of Template Injection. When injecting this payload, if the target is vulnerable to template injection, the output should be 49.

So, I tried to inject the template injection payload in one of the fields and saved the input. Luckily, when I accessed the page again, I saw 49. Bingo!

From that point, I knew I had something interesting to work on. Before this bug, my only experience with template injection was during CTFs or training. However, most of the time, when we encounter template injection challenges, we are often talking about a Server-Side Template Injection (commonly known as SSTI). In most of the cases I previously had, I dealt with a Remote Code Execution (RCE) exercise.

Consequently, I went down this path; I tried to enumerate the framework using the traditional payloads. You can find more explanations on this type of bug and the recon process on HackTricks or PortSwigger Academy website.

After a few tries, I thought it could be the Jinja2 or Twig framework, so I tried to use the payloads associated with those frameworks.

At that moment, I was confronted with the first barrier, a WAF. The WAF was catching everything I was trying to use when exploiting the SSTI for remote code execution. After a few minutes, one of the commands I tried caused the server to throw a message, which revealed a completely different framework.

I don’t remember exactly which framework it was, but when I googled it, I discovered this framework was associated with Angular. While googling, I found this Client-Side Template Injection cheat sheet.

From that point, I understood I was dealing with a Client-Side vulnerability. Consequently, I needed to abandon the idea of remote code execution.

The goal was to use this Client-Side Template Injection to perform a stored XSS. At that moment, I found a working payload that the WAF was not blocking:

Awesome! I had a stored XSS.

But wait, having a stored XSS is good, but what is the impact? This is one of the parts I enjoy the most: identifying how I can weaponize this vulnerability. To create maximum impact, I needed to understand the application and the particular functionality.

Let’s try to understand the context of this application. For testing in that program, hunters received three types of accounts: Admin, Manager, and Employee. The vulnerable functionality was where the Manager could add a new ‘Skill’ to the platform. When the ‘Skill’ was created, its name was listed in the General Skill Area. Only Managers and Admins had access to this functionality. Furthermore, the vulnerable parameter was the name of the Skill. So, I guess you already have a feeling about what I was trying to do.

My plan was to use the Stored XSS, initiated through Client-Side Template Injection as a Manager, to trick the Admin and perform a malicious action.

In this context, the most impactful attack I could conceive was stealing the Admin’s cookies to perform an account hijack. However, to execute this attack, I needed to be certain that the application was not using HttpOnly cookies. Fortunately, the application wasn’t using HttpOnly, enabling me to use this Stored XSS to hijack an admin session.

Perfect, now I had the bug and a compelling scenario to demonstrate maximum impact.

I wrote a detailed report and submitted it. Then went to take a bath with my fiancée. As we were discussing, I had a huge flash moment.

I said to her: “Wait a sec, there’s another location where I saw 49.”

She replied: “What are you talking about?”

I replied: “When I first started testing, I identified another functionality where I could create an event, and the name of the event became 49. This is also vulnerable.”

She said: “I have no idea what you are talking about.”

As you can imagine, I was just thinking out loud, literally in the zone, thinking about the bug I had just found.

I said: “Listen, let me just write another report, I’ll be back in 15 minutes.”

My fiancée noticed that I was almost shaking. At the same time, I realized I had a second bug, but especially because it was a brand-new program, hunters were trying super hard to find bugs, and I was really afraid of losing my bug.

I didn’t want my discovery to become a worthless duplicate because I lost a few minutes.

She understood and said: “Sure, go, go, go!”

If you hunt on the Synack Red Team platform, you know how strict Synack is with report quality. So, I needed to rush but maintain the excellent report quality, with all the steps, screenshots, and details included. I wrote the second report faster than the first one and submitted it. Indeed, the attack and bug were similar but exploiting a different functionality.

After I submitted the second report, I could finally chill out as the adrenaline rush dropped. It was time to spend some quality time with her and have a proper dinner.

Less than 24 hours later, I received a message regarding the first bug:

“Congratulations, your bug has been accepted!

Nice find, great job!”

At that moment, I was literally jumping with happiness. It was my first valid bug, and it had quite a good payout. I immediately shared a screenshot of the message and the amount with my fiancée. She was super happy for me.

Later on the same day, we were having dinner with my mother because we were going on holiday the next day. It’s kind of a ritual for us, having a good dinner before going on holidays. During the dinner, I received an email on my phone. When I checked it, I saw an email from Synack with a similar subject:

‘Your bug was Accepted!’

I remember that in the restaurant, I reacted exactly like this meme:

As you can imagine, the timing was PERFECT. Two HIGH bugs were found just before the holidays. I can really say that it allowed us to have more financial freedom during the holiday. It enabled us to create truly unforgettable memories. It was even during this trip I made my proposal to her.

Now you understand why the payload {{7*7}} really has a special meaning for me.

The takeaways from this post are:

Don’t limit yourself to basic and traditional payloads.Try to trigger an error; this can reveal sensitive information you can use to your advantage.If you identify a bug, look into other locations. Most of the time, the application has similar bugs in different places.Try to understand the application and create a threat model. It will help you write your report better and demonstrate real impact.Take a break. Sometimes, the best ideas come when you are away from your screen.Take good notes when going through the application, and don’t miss the opportunity to reuse the same bug you found in another location or functionality.Hacking is fun, but don’t forget to spend time with your family, loved ones, and friends.

I hope you enjoyed reading the story behind this bug.

If you’ve found bugs yourself, I hope you also have an interesting story to share with your friends and family. I believe we all have at least one.

If you haven’t found your first bug yet, no worries. It can take time; just keep trying and look for what others might have overlooked. This approach can help you create great leads. Also, always think about creating impact. Sometimes, technically complex bugs aren’t impactful enough to be considered as security issues in bug bounty programs.

I hope to bring more stories like this in the future.

Stay tuned and happy hacking!