[HackerNotes Ep.91] Zero to LHE in 9 Months (feat gr3pme)

Hacker TLDR;

• Picking a Target: Picking a target can feel daunting if you lack inspiration or are new to hunting. A few methods I use for easy target choice:

  • Hack What You Use: Target services you already use to leverage your familiarity and unlock features, speeding up bug discovery.

  • Turn Purchases into Profits: Before buying something new, check if the vendor has a bug bounty program— you might be able to pick up a few easy bugs simply by purchasing a product.

  • Leverage Regional Access: Focus on services unique to your region to reduce competition and find untouched vulnerabilities.

  • Explore Integrations: Even if a service isn't on a bug bounty program, its integrations might be—opening new avenues for bugs and unlocking additional attack surfaces.

• Bug Classes and Approaching a Target: I dive into this in a lot more depth below, but a high-level overview of some approaches that can be used across targets:

  • Focus on Specific Bug Classes: If you’re new to hunting and don’t have a massive base of technical knowledge across classes to tap into, hone in on one vulnerability type across a target to build expertise and increase success rates.

  • Adopt Threat Modeling: Map all functionalities in their entirety and brainstorm every possible attack vector. Work through this list, add to the list and document all your gadgets and quirks to gain context on the target and perform in-depth hunting. My full approach is detailed below.

  • Applied Learning: Instead of finishing 10’s of labs and taking notes just for them to sit and gather dust, combine lab practice with real-world testing on targets to reinforce concepts and gain practical experience. Have a list of targets ready that you’d like to hunt on and put the knowledge to use.

• ATO on a Fintech target: How being able to respond to payments with an emoji on a payment provider resulted in ATO. I recommend reading this one below, but a quick TL;DR:

  • Explore Novel Features: Functionalities like allowing reactions or emojis in response to an action (or payment) and understand how they're handled differently between mobile and web applications contexts, as these discrepancies may reveal overlooked security gaps.

  • Leverage Public Specifications: Use industry specs (e.g., Open Banking APIs) to understand data formats and find inconsistencies.

• 0 Interaction ATO: A series of bugs across a target, achieving 0 interaction ATO. Some takeaways from this one:

  • Map 'Oracle' Endpoints: Identify endpoints that reveal properties of key objects like users or organizations.

  • Test All Object States: Examine objects in every possible state (deleted, removed, banned, invited, disabled etc) to find inconsistencies in property exposure. Revisiting these endpoints in each different state may result in tokens being leaked, or some other interesting properties being exposed.

• OAuth Configurations & Development Environments: Developer documentation and environments often exist to allow customers to hook into APIs, SDKs and other supported authentication mechanisms on a target. Be sure to:

  • Explore Developer Integrations: Development environments and tools provided for integration often allow you to introduce input on trusted security boundaries, and modify behaviours across a target or application.

  • Manipulate OAuth Parameters: Use an invalid response_type value to automatically hit the redirect_uri value, allowing for arbitrary open redirects.

Well, I will start by saying—this is INCREDIBLY strange to write the HackerNotes for my own episode on the podcast. If you didn’t watch the podcast this week, I (yes, me) was the guest, and we covered my bug bounty journey over the past 9 months (10 now as of writing this).

I went from my first paid bug right up to participating in a Live Hacking Event (LHE), all in just 9 or 10 months. I hope at least someone finds the takeaways from this episode useful in some respect.

Let’s jump in.

LHE Experience

I will start by saying, that competing in an LHE was a great experience and if you get the opportunity to do so, you should most definitely take that opportunity. This was the first time I’d sat and hacked on a target solidly for longer than 2/3 hours a day in my bug bounty career, and it was quite rewarding.

Having only started hunting 9/10 months ago, being able to participate in an LHE and hold my own was quite the experience.

The LHE experience itself is quite unique, typically lasting between 2-3 weeks and ending with an in-person event for around 3 days with all the other hackers, teams and event organisers that made it happen.

Some of the things big takeaways from the LHE for me were:

The hacking ‘feedback’ from the event

LHEs are unique in the sense that you can get immediate feedback from other hackers on the same scope you’ve been looking at. There are not many other chances in bug bounty unless you collab heavily, where you get this level of feedback.

Being able to speak to hackers, all of which have spent the past 2-3 weeks on the exact same target as you to bounce ideas from, collab with and pull knowledge from really is something. Everyone is also very open about their bugs, so you can literally see where you went wrong and what holes you have in your methodology when approaching a target.

Equally, there’s a show-and-tell portion of the LHE where the most exotic/coolest bugs get shown and demonstrated. This is insane as you get to see other top hunter's bugs, how they popped them and what the impact was.

The LHE ‘mental’

Participating in a Live Hacking Event (LHE) can be mentally exhausting. Knowing that hackers worldwide are working on the same scope as you—and that a leaderboard will eventually be published—can really play mind games.. I didn’t think I’d be hit by this, but oh boy I was.

This led to me falling into a ‘find as many bugs as possible and DO NOT do anything else for the next 3 weeks’ mindset, which really worked against me instead of for me initially. Putting every other human aspect of life on hold to try and crank out more bugs does not do your mental any good, and I don’t recommend it.

Sticking to a solid schedule where you go to the gym, take breaks, eat well and still maintain some form of social life will definitely work for you, not against you.

Once I started relaxing into this flow and becoming more comfortable, this is where I slowly started finding more and more bugs. It felt like everything fell into place.

Ignore the leaderboard and Slack channel as much as possible

When the leaderboard did eventually get published and the Slack channel was pinging every hour, falling into the trap of focusing on both of those things instead of hunting was quite difficult at first.

After I got used to the leaderboard being up and the Slack channel continuously pinging, it didn’t phase me much, but if you’re stuck not finding many bugs and seeing people climb the leaderboard I can imagine it being quite daunting if you focus on it too much.

Big takeaway - focus on hacking, not on the leaderboard and how other people are doing.

Approaching a 3-week long stretch on one single target

Now, my entire bug bounty journey so far has been part-time, meaning I squeeze a few hours in where I can every day. Hitting a target for one long stretch was a bit different, and I had to change my approach slightly for this.

First of all, telling your family and friends that you may not be as accessible during this period is essential. You’ll be occupied for most of the days and probably quite exhausted, so be sure to tell everyone that. Big thanks to Justin for giving me solid advice on all of this stuff before the event.

Being able to mentally work through hurdles and not relying on coming back a few days later with a fresh set of eyes was a very important lesson here. If I was stuck I always knew I could come back to it a few days later, but in this instance, I was under more time constraints than usual and had to work through things faster.

Equally, being able to go as deep on a target for a solid period uninterrupted gives you a tonne of context and a tonne of gadgets (and bugs) in a short space of time. Having a system to thoroughly note these down to come back to at a later point is essential.

All in all, it was an incredibly rich learning experience which will no doubt play a massive part in my hacker development!

Picking a Target

For a while, like many bug bounty hunters, I didn’t know what a good target was or where to even start hacking on one. With time, this feeling starts to shift as you get a better feel for your ideal scope, product or product to hack.

Some of the easier wins I’ve had from targets however are for services that I already use, or have used in the past. Let me dive into some of the more unconventional ways I chose targets which massively helped:

Are any of the current services you know and use on a bug bounty program?

The reason why this is a bit of a cheat code is twofold - one because you already have context as a user with the product, and another is because you’ve previously or currently paid for the service, meaning a lot of the attack surface is likely unlocked with no additional effort from yourself.

This will cut a lot of resistance out from picking a target and get you hacking quicker. Equally, there have been some services which don’t have a bug bounty program, but some targets I’ve looked at offer integrations with the service. This will unlock a tonne of attack surface too, if not more, depending on the target.

Even with some of the private invites I’ve had, I only accepted them because my girlfriend uses the service/company herself.

With targets like this, I’m less concerned about the bounty tables as there’s less run-up to finding bugs, rather than approaching a target you’ve never seen before, meaning there’s a much higher chance you’ll find things quicker.

Equally, I look at it like it's ‘free bugs’ - I already have it, I already use it... so why not hack it?

Do you need to buy something new - aftershave, new subscription etc.. look up targets which have a bug bounty program which also offers that

This touches on the point above, but similarly.. do you have any upcoming purchases you need to make? Maybe check your private invites and the platforms to see if there’s a program which allows you to purchase that product.

Even if you find one thing, you’ve paid for the thing you’re looking to buy and probably have made a bit of money from it!

What (regionally) can you unlock that others can't?

Focusing on regional targets has been huge to my bug bounty success. There’s a lot of applications or APIs that require real data, whether that be a certain type of drivers license, or passport, address data, mobile number, so on.

Hitting a target that you can completely unlock (due to your region) will automatically reduce the total pool of bug bounty hunters that have potentially looked at that same target. This, statistically speaking, means that you’re more likely to find bugs as there’s a higher chance that it’s relatively untouched (from a bug bounty perspective) attack surface.

TL;DR: regional services and targets are your friends! Sign up to them.

Bug Classes and Approaching a Target

So now we have a few ideas spinning, we’ve got some targets we want to look at… how do we approach them? When I was first hunting, I played around with a methodology and listened to a lot of hunters ’ successes in how they found bugs.

I think if you’re still finding your feet and don’t have a style that’s unique to you, here are a few ways I noted to approach a target:

Approach 1 - Specific bug class approach

Only look for a specific class of bug(s) on a target and see what comes up. Depending on the target and the stack they use, results will vary. Equally, if you’re newer to hunting and haven’t mastered many categories of bugs, this might be the route to take and slowly build off of this.

Equally, different stacks and frameworks may or may not cater towards whatever it is that you’re hunting for - research this as it can help!

Approach 2 - Threat model a target

Instead of looking for a specific bug class like XSS, you can take the threat model approach. If you aren’t familiar with this, you map out all functionality in its entirety and essentially note down everything that could go wrong and every single attack vector you can think of. This is my approach, and I quite like it.

If you aren’t familiar with threat modelling, this is what a somewhat traditional approach would look like:

But, as we’re bug hunters, that’s not the exact approach I take. These are real notes from one of the first targets I looked at, and this gives a taste of how I approach it:

The point of this approach is to list every single attack vector you can possibly think of - what could go wrong, where and use it as a point of reference to come back to. No matter how unlikely, still list it down as a potential attack vector to explore.

I find diving into each attack vector and walking through, even if it doesn’t result in a bug straight away, means you’ve gained a lot of context on the application and have one less avenue to explore later down the road.

Taking notes of behaviours observed and gadgets discovered from this process will pay dividends long term too. My go to approach!

Approach 3 - Applied learning

Now I wasn’t too sure what to name this one, but I’ve gone with ‘applied learning’. What do I mean by this?

If you’re a new hunter, or even a seasoned hunter exploring a new bug class this one is useful. Instead of hammering labs for a few weeks on a subject just to never touch it or look at your notes again, do some labs, take some notes on a rough methodology look at prior reports on that category of bug, and THEN look for targets to which this could be applicable.

I commonly see (myself included) the trap of doing labs for weeks on end, taking loads of notes, feeling good about the subject and then forgetting about it and not putting that knowledge to use. If you instead have some targets ready to look at throughout the process to play with, it will stick AND you will be gaining actual hands-on XP. And that’s the part that’s going to get you closer to finding bugs.

For me, this approach helps concepts and attacks stick a hell of a lot better compared to the ‘do loads of labs and forget’ approach (which we’re all probably guilty of at some point)

There are other approaches out there, but these are the ones I’ve observed (and tested) which seem to be effective.

Gr3pme’s Bugs

ATO on a Fintech target

This was one of my first bugs and it was pretty cool. It was all based on a hunch around some strange functionality newer ‘challenger’ fintech banks offer around payments.

Some newer banks now allow you to thank a user for a payment, or react to payments with emojis or send some other action. I often wondered why and how this was implemented, and how this is handled in the context of a program's web application, as this functionality primarily resides on mobile applications.

So this got me thinking initially. This combined with the Open banking API specification, I started digging around how this stuff was actually implemented. If you aren’t familiar, the OpenBanking API spec is a publicly accessible API spec which essentially defines the APIs most EU-based payment providers should adhere to when banking.

You can read it and check it out here https://openbanking.atlassian.net/wiki/spaces/DZ/pages/23922689/ARCHIVE+-+Specifications - it’s quite interesting to see which providers are compliant with what parts, but more specifically it gives you the length and type of the expected data for each endpoint and field.

Digging into this, I went through the very pleasant process of setting up around 7 accounts with different providers, with the aim of understanding if: Did they allow funky meta-data to be sent with payments, such as emojis and so on? If so, how were they handled from the mobile → app and outside of their payment ecosystem to another provider?

This proved to be useful. There were some discrepancies across the providers, as some did allow emojis which allowed for extended character sets to be associated with payments.

At the end of this research, I found a payment provider which allowed a basic POC to be sent to my target within one of the fields of a payment. After digging deep and bypassing some hard-set character limit limitations, I managed to turn this into a stored XSS which resulted in an ATO from simply clicking on a payment.

Pretty cool bug in my opinion!

0 Interaction ATO

Reflecting back on the episode, I probably could have explained this one a little better. This one uses the concept of oracle endpoints for certain objects, let’s jump in.

When approaching targets, I’d always take note of endpoints which expose some properties of an object I’m targeting. For example, a user object; there might be numerous places in the application that expose certain properties of a user object.

You might have the /api/org endpoint which exposes the user's organisation. You could have api/team which exposes the user objects ‘team’ property, and so on. Taking note of these ‘oracle’ endpoints can always prove to be useful.

Now, when looking at a user object - a user object can have many different states. A user object could, for example, be in states: invited, deleted, removed, active, banned, archived, inactive etc. These states all depend on the context of the application.

Across one target in particular, I found an underlying design flaw of some of these endpoints whereby depending on what state the user object was in, it would expose some pretty nasty properties to every user that had access to the ‘Oracle’ endpoints I mentioned earlier.

In the context of this target, most organisation users could hit these endpoints and read these properties. Equally, endpoints throughout the application would expose these same properties, meaning multiple paths to read the same property.

As the properties exposed were invitation tokens, this meant any user could read and harvest invitation tokens of another user. Due to these being SaaS applications the impact was ATO, and ATO permitting you access to a completely different organisation.

TL;DR here: Take notes of endpoints that expose interesting properties and put objects into every possible state when testing.

OAuth Configurations & Development Environments - Open Redirect

Some targets offer integrations to their services, and host entire development ecosystems in order for you to thoroughly test and play with any integration you might make to hook into their environment.

A lot of these integrations require that you authenticate to them, and support a few different means of authentication. Take note of these authentication methods, as they can come in useful.

One target I approached allowed you to create your own application to tie into their OAuth flow and authenticate by using them as the OAuth provider. The interesting thing about this functionality was you could control quite a lot and it mimicked their existing OAuth flow across some of their services.

More importantly, it allowed you to control the value of the redirect_uri parameter. This parameter is used as a means of redirection upon a successful authentication attempt. What I didn’t realize at the time was how great of a gadget this was - more on this shortly.

A little less known trick about an OAuth flow is that if you input an invalid type value, providing the redirect_uri value is whitelisted on the backend, it will redirect you straight to the redirect_uri value without having to authenticate. Why was this important?

This was now essentially an open redirect within a trusted domain on the target. By utilising a seemingly innocent development area to test integrations and hook into the target, I now had a gadget which allowed a full open redirect.

Looking across development offerings on a few targets, this was a fairly common and useful gadget. In one context I needed, I chained this with an SSRF to achieve some nice impact!

TL;DR: Developer environments and portals, if offered, can provide nice gadgets and bypass some domain dependant controls in place on targets.

Have to admit, it was strange writing my own notes up but I hope you find it useful.

As always, keep hacking!