[HackerNotes Ep. 59] Bug Bounty Gadget Hunting & Hacker's Intuition

Hacker TLDR;

• Caido Updates: Caido has dropped some customization features along with HTTPQL, allowing you to search through requests in a Wiresharkesque format.

• Useful Gadgets When Hunting: The guys detailed 13 gadgets they keep note of when hunting and how they chain them together. Some of the more notable ones below:

• LocalStorage Poisoning: Let’s say we have a gadget that takes input and stores it in local storage, then does some other action with it. If you have control of the entire input, it’s possible to do a window.open to that page. You can then poison the local storage cache for the page, and then race condition to close the tab or redirect the tab away with the value you have in the local storage cell remaining persistent. These types of gadgets can also prove useful in scenarios when you want to hit a specific piece of client-side logic.

• Auth gadgets: Finding places in the application where you can perform a subset of authenticated operations can prove useful in exploit scenarios, as you can take privileges required from low to none, or high to low, etc. Say you can subscribe or self-sign up in an area of an application, this would be a case of being able to modify the privileges required, and therefore the CVSS vector.

• Cookie injection: Cookie injection gadgets can be found on both the server and client side. As a gadget, this can prove to be versatile as cookies are sent with every request (depending on the cookie configuration), can often be reflected in the web application and even be a sink as well as a source.

• Context breaks: The idea here is where can you break out of a scenario or context you are meant to be in? Context breaks are quite a broadly defined gadget and require lots of additional context but check out this thread here covering some examples such as Cookie Injection, CSS Context Escaping, JavaScript String Escape and so on.

• Cookie refresh gadget: If you find a gadget that allows you to refresh the cookie, you can reset the timer on the same site lax configuration on modern browsers.

• CRLF Injection: CRLF injection, in the right context, can allow you to overwrite existing headers, and introduce new headers - It's essentially full HTTP response control in the right context. A good use case in some contexts is to overwrite secure HTTP header directives.

New Caido Updates

We’ve got a tonne of new features being dropped in Caido. A few guys at the most recent LHE exclusively used Caido and provided the Caido team with lots of feedback, which has led to some really nice feature updates.

Some of the notable features:

• HTTPQL dropped, a Wiresharkesque way to search and filter through requests.

• Released customization feature which allows custom CSS and JS. Can customize themes, tabs, and so on.

• Evenbetter is an open-source script for Caido that’s designed to increase some of the UI aspects and enhance features. It includes SSRF support, similar to Burp Collab.

• Upcoming plugin support is anticipated, which will most likely written in JS. Something to consider if you want to port over any of your go-to extensions from Burp!

Caido can be checked out here https://caido.io/ - use CTBBPODCAST for 10% off.

Go-go Gadgets

Arguably one of the best things to hear on the pod is the guys telling us what gadgets they look out for, what gets their hacker sense tingling. And we’ve got a lot of them!

Gadgets are things that might not be exploitable by themselves, but you can often chain them together to turn them into something more impactful.

Think outside of the box when you approach these - how could these be applied to your context when looking at an application.

HTML Injection

HTML Injection can be quite a versatile gadget and one that is often escalated to CSS injection or XSS for additional impact.

Depending on the context, the gadget can also prove impactful. A prime example is NahamSec using HTMLI to land a tasty $40k bounty in a desktop app context (details on this one can be found here if you’re interested)

• Useful when dom clobbering objects - an example being dom clobbering a script that prevented XSS on a target, ultimately resulting in XSS.

• If the application state is stored in a JSON blob somewhere on the page, sometimes seen in SPAs, you can use dangling markup to leak it and sometimes query it. Can be useful when used with other gadgets and what state the app stores.

• It's not uncommon the find HTMLI which ends up in an email template, If you can overwrite the entire HTML form in an email context, it can prove impactful on a finding.

• Dangling markups can be used as a persistent DoS a victim user as you can essentially completely break the page.

A prime example, Justin used an HTMLI himself to inject an img tag that referenced the logout endpoint in an application. This tag was propagated to users via a notification, which loaded every time the user logged in. This meant every time a user authenticates, they just get logged straight back out!

If you want to dive into CSS injection and exfiltration, PortSwiggers research covers this extensively here.

PortSwigger also has great resources on dangling markup attacks here.

Open redirects

Open redirect, by itself, doesn’t hold much weight. Programs are likely to report as an N/A or a low unless you can use it to show additional impact.

Some ways to show impact with open redirects include:

• Chained with an SSRF to bypass filtering, ie the host you have an open redirect on might be allow listed.

• Abused with OAuth flows to bypass filtering leak OAuth-related flow material.

• Iframe source injections with open redirects can allow you to get your own attacker-controlled page embedded, allowing for postMessage-based vectors.

• Client-side path traversals: If you control a part of the path for a fetch request and can specify path traversal sequences, or iframe embedded dynamically using JS and you’re able to inject into the URL with a path traversal such as ../../ you can use this to hit an open redirect and can often abuse it for XSS. JavaScripts fetch auto-follows any redirects, with a small caveat of not being able to read the full response.

You might be wondering why different types of redirects are gadgets, why some aren’t etc. The main reason for this is because depending on the origin of the redirect and type of redirect depends on how the browser handles it and what information, if any, gets carried over in the redirect which we as attackers can abuse.

Clickjacking

Often looked down on but in some scenarios, it can be impactful.

Take OAuth as an example, and do not have any x-frame-options headers on the page that approve OAuth-related transactions. Clickjack the page, then have ATO.

Equally, the highest bounty I’ve ever seen rewarded for a clickjacking-based attack was by MetaMask, for $120k. The browser extension was vulnerable to clickjacking, meaning an attacker could abuse it to disclose sensitive information or transfer funds without the user realizing it. The writeup for it can be found here.

Equally, missing frame headers can give you flexibility when you need to get a window reference.

Leaking window.location.href

There are multiple ways you could read window.location.href common methods being via XSS or postMessage. Some postMessage implementations echo back the location when sending a message for example.

This can be a powerful gadget as you can leak anything that ends up in the URL - sometimes session material, IDs, OAuth-related info, and so on.

Alternatively, if window.name is used, you can transfer the current.location.href back do a domain you control, allowing you to leak any sensitive info in window.name - 51 min

Checking the window objects that get returned in the console, and checking what properties they have, what they carry over, and what they inherit can be useful when performing research and trying to craft exploits.

Cookie refresh gadget

If you find a gadget that allows you to refresh the cookie, you can reset the timer on the same site lax configuration on modern browsers.

Finding a gadget that does this can provide a means of CSRF, and be especially useful in a wider chain.

Stored XSS

Stored XSS is a tried and tested gadget, with extensive impact and versatility due to the amount you can do with JavaScript.

To increase the impact of stored XSS a good gadget to try and chain with it is an IDOR. This could be used to propagate it to other users and used to demonstrate ATO as an impact.

Wormability is a good one to keep in mind when demonstrating impact - maybe you can’t quite get ATO, but if you can chain with a CSRF to worm to all other users it could be equally as impactful.

Keep an eye out for self-stored XSS when it comes to impact - it can be quite nuanced to prove impact. Chaining it with a CSRF-esque gadget could be the missing piece to get a nice POC crafted.

CRLF Injection

Incredibly versatile gadget due to the flexibility you have with it. You can overwrite existing headers, and introduce new headers - It's essentially full HTTP response control in the right context.

Depending on the context, this could prove to be incredibly useful if the target is hardened and sets the appropriate HTTP header directives - you could abuse CRLF injection to overwrite secure HTTP header directives.

Depending on how much control you have over the HTTP response, you could also inject arbitrary cookies, additional HTML, and JS for XSS.. you can do a tonne with it.

Be sure to note down any CRLF gadgets you find!

ID Oracle

UUIDs are frequently employed as a defense mechanism against specific types of attacks, such as CSRF, or alternatively, they serve as substitutes for access controls.

If you can find a UUID oracle - something that returns a UUID for a given piece of data, whether that be an email address or user info, definitely keep a note of that.

Being able to derive a valid UUID in the application context can prove to be invaluable!

Auth gadgets

Finding places in the application where you can perform a subset of authenticated operations can prove useful in exploit scenarios, as you can take privileges required from low to none, high to low, etc.

Say you can subscribe or self-sign up in an area of an application, this would be a case of being able to modify the privileges required, and therefore the CVSS vector.

Equally, if you’ve been banned, locked out, or have hit some sort of threshold on your account for whatever reason, trying a password reset on the account can often reset that limit.

These types of gadgets are something to take note of as you can increase impact by modifying the PR: CVSS vector to earn more.

Web Cache Deception

The premise of web cache deception is tricking the caching service into storing sensitive information belonging to another user, which can then be later retrieved by the attacker for the duration of the cache.

These types of gadgets are always often high impact, due to the cache being served to any and all users visiting the endpoint the sensitive information has been cached to.

Local storage poisoning

Let’s say we have a gadget that takes input and stores it in a local storage, then does some other action with it.

If you have control of the entire input, it’s possible to do a window.open to that page, poison the local storage cache for the page, and then race condition to close the tab or redirect the tab away, with the value you have in the local storage cell will remaining persistent.

These types of gadgets can also prove useful in scenarios when you want to hit a certain piece of logic client side in a condition such as localStorage.getItem('val') || someFunc()

Cookie injection

Cookie injection gadgets can be found on both the server and client side.

As a gadget, this can prove to be versatile as cookies are sent with every request (depending on the cookie configuration), can often be reflected in the web application and even be a sink as well as a source.

Context is key here as you can do a lot with a little depending on how the cookie is used.

Context breaks

Context breaks are quite a broadly defined gadget. To identify context breaks you need to be familiar with what contexts exist in the browser.

The idea here is where can you break out of a scenario or context you are meant to be in?

Use this with the cookie injection gadget for example, using a semi-colon to terminate the cookie and set unanticipated cookie configurations is a context change.

Let's use double-quoted input in JS as an example. Let’s say we have some filtered JS in between double quotes which is properly escaping tags. If the backslash isn’t being escaped, you can do a backslash at the end of a string you can un-terminate the string. This string will continue until it sees another double quote.

Where is this data intended to be? Look for areas where your data is going beyond the intended defined context and consider how it could break that. Combining other gadgets with this type of gadget can prove to be incredibly impactful.

We dropped some more examples of context break scenarios on a thread here for some further reading.

You may have heard us say this before on Critical Thinking but finding these types of gadgets and taking note of them throughout your journey on a target is where you can expect to find some high-impact findings.

Be sure to take note of some suspicious or interesting behavior - even if it's not exploitable now, it could be useful in the future!

Have fun hunting some gadgets, till next time!