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
Cookie: mycookies


And the response might look like this:

HTTP/1.1 200 OK


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


@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).

Insecure Direct Object Reference

Get as image function pulls any Insights/NRQL data from any New Relic account (IDOR)

This writeup walks you through the full process as to how I found a pretty bad Insecure Direct Object Reference (IDOR) in New Relic. 

In New Relic, there is the ability to add a 3rd party integration to a product line called New Relic Infrastructure. Common integrations include AWS, Azure, and most recently Google Cloud Platform (GCP). In Google Cloud Platform there is also the ability to create dashboards:

new relic dashboards

Dashboards are pretty common in New Relic, but there was something unique about the dashboards that are within the integrations section; the dropdown options for each chart allow you to do the following actions, which are not present in any of the other dashboard areas:

The option that immediately stood out to me was the “Get as image” option. This option converts the NRQL query that generates the dashboard into an image – and this is where the vulnerability lies. For more info on the New Relic Query Language (NRQL) works, check out this link:

The normal POST request to generate the dashboard image is as follows:

{"query":{"account_id":1523936,"nrql":"SELECT count(*) FROM IntegrationError FACET dataSourceName SINCE 1 DAY AGO"},"account_id":1523936,"endpoint":"/v2/nrql","title":"Authentication Errors"}

The application failed to check and see if the account_id parameter belonged to the user making the request. The account number 1523936 belongs to me, but if I changed it to another number, I could pull data from another account.

So now that I had control over this value, I could change the account ID to any other account ID on New Relic. Since the account ID parameter is incremental, if I was malicious I could simply throw this request into Burp Intruder and highlight the account id value to increment by one on each request, enabling me to pull any data I wanted from any or all accounts on New Relic. The NRQL query could be modified as well, so instead of pulling the data that generated the original dashboard, I could instead change the request to something like this:

{"query":{"account_id":any_account_number_here,"nrql":"SELECT * FROM SystemSample"},"account_id":any_account_number_here,"endpoint":"/v2/nrql","title":"Uh oh!"}

This query runs the SystemSample NRQL query on any account ID, which downloads the following photo:

So this is interesting, but it doesn’t really tell me any juicy info. I know that I’m hitting other accounts, but the information I’m retrieving back is useless – it just shows an empty chart! I played around with this for a little while, trying different NRQL queries until I discovered an interesting header that is in the response back from the server when you send this type of request:


I realized that if you add ?type= at the end of the URL it will show you different chart types, allowing you to exfiltrate more data than normal. If you enter a incorrect “?type=” value, it will show you all of the available chart options within the error message:

{"code":"BadRequestError","message":"uhoh is not a valid Vizco chart type. Permitted Types: apdex area bar baseline billboard bullet empty event-feed funnel heatmap histogram json line markdown pie stacked-horizontal-bar scatter table traffic-light vertical-bar"}

Now I can use any of the above chart types of return more information than I normally would from the NRQL query:


Now we’re getting somewhere! Instead of the normal chart type, I’m now returning a JSON dump of the dashboard, downloaded as a photo. This is pretty great considering I can perform this JSON dump against any account – but I want to go one step further. How can I exfiltrate as much data as possible in each request? Just add a &height=2000 at the end of the URL 🙂


I reported this to the New Relic team and they fixed it shortly afterwards within a few days. I was awarded $2,500 for this bug. I asked them if they wanted to include any comment on this post about how they fixed the issue, and they provided the following:

For some background, this report helped us identify a logic error with the validation code we have in place in our backend authentication proxy. A very specific combination of configuration options for an application would result in the validation checks not taking place.

Once we identified that issue, we were able to search for anywhere we were using that combination of configuration options to quickly mitigate the issue. That then led to a permanent fix of the logic issue, ensuring that the account validation always took place before the request was allowed to proceed.

The New Relic security team is one of the best ones out there – they award quickly and their time to resolution is fantastic. It’s really one of the main reasons I enjoy hunting for bugs on them so much!

Follow me on Twitter to stay up to date with what I’m working on and security/bug bounties in general 🙂

Insecure Direct Object Reference

Abusing internal API to achieve IDOR in New Relic

I recently found a nice insecure direct object reference (IDOR) in New Relic which allowed me to pull data from other user accounts, and I thought it was worthy of writing up because it might make you think twice about the types (and the sheer number!) of API’s that are used in popular web services.

New Relic has a private bug bounty program (I was given permission to talk about it here), and I’ve been on their program for quite some time, so I’ve become very familiar with their overall setup and functionality of the application, but this bug took me a long time to find … and you’ll see why below.

Some background first: New Relic has a public REST API which can be used by anyone with a standard user account . This API operates by passing the X-api-key header along with your query. Here’s an example of a typical API call:

curl -X GET '{application_id}/hosts.json' \
     -H 'X-Api-Key:{api_key}' -i

Pretty typical. I tried to poke at this a little bit by swapping the {application_id} with another user account’s {application_id} that belongs to me. I usually test for IDOR’s this way, by having one browser (Usually Chrome) setup as my “victim account” and another browser (usually Firefox) as the “attacker” account, where I route everything through Burp and check the responses after I change values here and there. It’s kind of an old school way to test for IDOR’s and permission structure issues, and there is probably a much more effective way to automate something like this, but it works for me. Needless to say this was a dead end, and it didn’t return anything fruitful.

I looked further and found that New Relic also implements an internal API which occurs on both their infrastructure product and their alerts product. They conveniently identify this through the /internal_api/ endpoint (and put references to their internal API in some of their .js files as well).

The two products operate on different subdomains, and This is what it looks like in Burp, on the domain (where the IDOR originally occurred).

The reason I bring up the fact there are two separate subdomains is because this bug sat there for an excessive amount of time because I didn’t bother checking both subdomains and their respective internal API’s. To make it even more difficult, there are multiple versions of the internal_api, and the bug only worked on version 1. Here’s what the vulnerable endpoint looked like:{ACCOUNT NUMBER}/incidents

The account number increases by 1 every time a new account is created, so I could have literally enumerated every single account pretty easily by just running an intruder attack and increasing the value by one each time. The IDOR was possible because the application did not ensure that the account number being requested through the above internal API GET request matched the account number of the authenticated user. 

This IDOR allowed me to view the following from any New Relic account:

  • Account Events
  • Account Messages
  • Violations (Through NR Alerts)
  • Policy Summaries
  • Infrastructure events and filters
  • Account Settings

This bug has been resolved and I was rewarded $1,000. I’d just like to point out that the New Relic engineering and development team was super quick to remediate this. Special thanks to the New Relic team for running one of, if not the best bug bounty programs out there!

Follow me on Twitter to stay up to date with what I’m working on and security/bug bounties in general 🙂