Authentication Bypass

Using Burp Suite match and replace settings to escalate your user privileges and find hidden features

On May 14th, Lew Cirne, the CEO of New Relic, announced a new platform called New Relic One. The platform, featuring a fresh new design and better data visualizations, came as a surprise to investors and New Relic users alike.

But it did not come as a surprise to me, for I had found out about it months prior, using a common trick that I’ve used multiple times in other bug bounty programs to access unreleased beta and admin features; the Burp Suite match and replace rule.

The concept is simple: By changing the server response body from “false” to “true” (I cheekily refer to this as the FALSE2TRUE trick, because everything has to have a catchy name nowadays 😏) – you open up much more on the client side that might previously be hidden or unaccessible, and that’s exactly what happened when I found out about New Relic One. This is not a secret, and has been a method for a long time.

For those of you new to using the Burp Suite match and replace rule, this article goes deeper into where to find it in Burp and how to use it – but it lives under the Proxy settings in Options:

The match and replace rule goes well beyond just changing false responses to true – it can also be used for privilege escalation to change your user permissions from “User” to “Admin”. Let’s use the following example:

Imagine the server performs a check of the permissions of the user with the current session. The request to the server might look something like this:

POST /api/getUserDetails HTTP/1.1
Host: myserver.jonbottarini.com
Cookie: mycookies

{"user":"123"}

And the response might look like this:

HTTP/1.1 200 OK

{"data":{"currentUser":{"userData":[
{"userLevel":READONLY,"subscriptionLevel":"BASIC"}
]}}}

In the response, the client operates under the assumption that the user is in “READONLY” mode, and has a “BASIC” subscription. If we add a match and replace rule to change the “userLevel”:READONLY response to “userLevel”:ADMIN, we can trick the client to display UI elements that are meant only for Administrators:

We can go one step further and display UI elements that are meant only for a “Professional” level subscription as well:

If we were to add the match/replace rules above, the response to the client will now look like this:

HTTP/1.1 200 OK

{"data":{"currentUser":{"userData":[{"userLevel":ADMIN,"subscriptionLevel":"PROFESSIONAL"}]}}}

@daeken has another nifty trick with the Burp match/replace rule: injecting payloads into forms instead of typing out the entire payload:

Back to New Relic. I was using the FALSE2TRUE trick when I realized that there was a feature flag on my account which was always returning false. By simply changing this response to true using Burp match/replace rule, I noticed that there was additional UI elements that appeared on the page.

This is the New Relic landing page when logging in without FALSE2TRUE:

Now, when using the FALSE2TRUE trick, changing all “false” values to “true”:

Bug found!

The Burp match and replace rule gave me access to a completely unreleased feature with a ton of new functionality, where I found other bugs as well, prior to the public release.

A word of warning: Be careful when using the FALSE2TRICK on big websites, because you can really mess up your session, or even your entire account.

I’m curious how you use the match/replace tool in your Burp projects – leave a comment below or ping me on Twitter if you would like to share. If it’s a really good tip, I’ll put it in this post so others can learn!

Until next time 👋

(The New Relic security team reviewed this post in full before it was published and have agreed to let me use one of my reports as an example. I am especially grateful for the New Relic team to be so open and accepting of using their program and bugs I’ve found in examples on my blog).

Authentication Bypass

Inspect Element leads to Stripe Account Lockout Authentication Bypass

A common thing I see happening with many popular applications is that a developer will disable an HTML element through the “class” attribute. It usually looks something like this:

This works pretty well in some situations, but in other situations it can be manipulated to perform actions that really shouldn’t be done by an unauthenticated user. That’s exactly what happened in a bug I submitted to Stripe a few weeks ago.

When you are logged into your Stripe account, you will be timed out after a certain amount of inactivity. Once this you reach this timeout, you aren’t able to make any changes on the account or view other pages until you re-authenticate by entering your password. Herein lies the problem with using a “disabled” class tag – an attacker can simply manipulate the page through inspect element to allow them to delete the disable class tag and view other pages, allowing them to send requests.

In this video below, you’ll see how I’m locked out of a Stripe account because of inactivity, but by navigating to the “invite user” section of the timeout page through inspect element, I am able to invite myself as an administrator on the account that is timed out, without authenticating first.

This, of course, requires a person to first be logged in to their Stripe account and leave their computer out in the open… but using this method you can render the entire lockout process completely useless on a Stripe.com account. It’s interesting nonetheless that the folks at Stripe made sure that a malicious user couldn’t change the web hooks… but inviting an administrator to the account is completely allowed.

Stripe followed up and clarified by saying that simply dismissing the entire modal isn’t enough to bypass the authentication check, it is instead checked at the backend, but that check was accidentally removed in this situation which allowed me to invite another administrator.

Stripe security was very responsive in resolving this issue and it was fixed shortly after I reported it. I asked permission before publishing this article. Bounty: $500.

I have some more bounty writeups that are a bit more technical than this one coming soon, including a writeup on a CVE I discovered, so check back later for more updates. Additionally, you can follow me on Twitter to stay up to date with my bugs and what I’m doing, if you wish.