├── Bugs_on_NewRelic.md └── README.md /Bugs_on_NewRelic.md: -------------------------------------------------------------------------------- 1 | **New Relic:** 2 | New Relic provides a platform where you can integrate other apps like Grafana dashboard, OpenTelemetry and you can get logs, events, alerts, full software stack information on a single platform. You can analyze, your full stack from one place. 3 | - They have APM(application performance management) section, Browser section(which gives Full-stack visibility, identifies latency from backend services to end-user experiences ), Synthetics(where you can simulate user traffic), infrastrcuture( where we can integrate AWS, GCP and other accounts) and others. 4 | 5 | **Bug Foraging of reports from Jon on New Relic** (https://hackerone.com/jon_bottarini) 6 | 7 | **Bug 1:** https://hackerone.com/reports/197436 8 | Description: Restricted User is able to edit Alert Conditions of Synthetics Monitors even if Synthetics Permissions is enabled by an admin 9 | 10 | 11 | Admin -> User1 12 | 13 | 14 | **Synthetics** has **monitors** 15 | Synthetics -> Permissions -> group1 16 | 17 | Add User1 -> group1 18 | 19 | 20 | **Monitor Permissions for Group1** 21 | 22 | View all monitors = checked 23 | 24 | Edit all monitors = unchecked 25 | 26 | Private locations = checked 27 | 28 | Edit all private locations = unchecked 29 | 30 | 31 | Add Admin -> Group2 32 | 33 | **Monitor Permissions for Group2** 34 | 35 | View all monitors = checked 36 | 37 | Edit all monitors = checked 38 | 39 | Private locations = checked 40 | 41 | Edit all private locations = checked 42 | 43 | - Admin account creates two monitors. The monitors are called: Monitor1 and Monitor2. 44 | 45 | Monitor 1 : Do not notify 46 | 47 | Monitor2: Get Notified with an email filled 48 | 49 | 50 | User1 is part of Group1 and he does not have permission to edit any monitor 51 | 52 | - User1 navigates to Synthetics and clicks on “Monitor1”. The URL should look something like this: https://synthetics.newrelic.com/accounts/1523936/monitors/5b8d01f9-389e-4120-aa83-20baa98e086c/ 53 | - User1 appends /conditions at the end of the URL. The URL now looks like this: https://synthetics.newrelic.com/accounts/1523936/monitors/8f4a3a49-6355-4455-8480-79d93acdfda7/conditions 54 | - User1 should not be able to be here! He isn’t authorized to make edits to Monitors 55 | 56 | 57 | **What do we learn?** 58 | 59 | - Always check the requests of admin user for the privileged endpoint. 60 | - Append the same endpoint to the less privileged user and try to use it. 61 | 62 | **Bug 2:** https://hackerone.com/reports/271393 63 | **Description**: NR Internal_API call allows me to read the events/violations/policies/messages of ANY New Relic account (AND pull data from infrastructure) 64 | 65 | 66 | Normal Rest API: https://api.newrelic.com/v2/applications/{application_id}/hosts.json 67 | 68 | - It uses api.newrelic.com for api requests and `X-api-key` as header for authentication 69 | 70 | - But in some of the .js file, they had reference to "/internal_api" 71 | - You can also found the same by spidering/crawling *infrastructure.newrelic.com* and* alerts.newrelic.com domains.* 72 | - So internal api looks like this: 73 | ` 74 | https://alerts.newrelic.com/internal_api/1/accounts/{ACCOUNT NUMBER}/incidents 75 | ` 76 | 77 | - This "/internal_api/" has the similar endpoint as the main api endpoint. 78 | - By manipulating the ids on this request, any use can see other user account events, messages, polcies etc. 79 | 80 | **What do we learn?** 81 | Check Js files and other subdomains for unique internal endpoints. 82 | 83 | **Bug 3: (Combining 3 reports exposing same confidential info from different endpoints)** https://hackerone.com/reports/267636 84 | https://hackerone.com/reports/320173 85 | https://hackerone.com/reports/271861 86 | 87 | If you invite a new user to your NR account, and they _already have a NR account_ associated with that email address, NR will hide their full name until they accept the invite and log in to your organization. For example, imagine my email was jon@jon.com and my NR name is “Jon Bottarini” - If you were to invite me to your NR account, my email address will be displayed, but my name would say: “j** *********” 88 | Bug in this case is that without the user accepting my invite, I can see there full name. 89 | 90 | **Description**: Ability to see full name associated with other New Relic accounts 91 | 92 | - Found a issue in previous report that full names of a user are coming in the user management section. 93 | - But there is another way to get full names: 94 | - Add a new user to the account (https://account.newrelic.com/accounts/1523936/users/new) 95 | - Ener some name and emailid of the user USER1 and add this user. 96 | - Now go to permission section ( https://synthetics.newrelic.com/accounts/1523936/permissions), as we know from Bug1 that we need to make a group and add permissions to a group. 97 | - Then, we can add user to the permission group, bug was that when a admin user(let's say) Click on the plus button next to "People" to add USER1 in the permission group, it shows fullname of any email on any account. 98 | 99 | **What do we learn?** 100 | - Understand the bussiness logic, if one endpoint shows some info then look for other endpoints too, it might be the case that you find other endpoint which is leaking confidential info. 101 | 102 | **Bug 4:** https://hackerone.com/reports/520623 103 | 104 | **Description:** Giving myself access to NR1 UI / one.newrelic.com without the proper feature flags on my account 105 | 106 | 107 | - Use the Burp Suite match and replace rule to change the feature flag from false to true. 108 | https://www.jonbottarini.com/2019/06/17/using-burp-suite-match-and-replace-settings-to-escalate-your-user-privileges-and-find-hidden-features/ 109 | 110 | **What do we learn?** 111 | - There might be some hiddne feature or functionality in website, try looking at all request in Burp and use match and replace if you see values like "USER", "BASIC", "TRUE", "FALSE". 112 | 113 | 114 | **Bug 5 :** https://hackerone.com/reports/397137 115 | **Description:** Pull any Insights/NRQL data from any NR account 116 | https://www.jonbottarini.com/2018/10/09/get-as-image-function-pulls-any-insights-nrql-data-from-any-new-relic-account-idor/ 117 | 118 | - As I told before, NewRelic allow us to integrate other apps. 119 | - Common integrations include AWS, Azure, Google Cloud Platform (GCP). In Google Cloud Platform there is also the ability to create dashboards. 120 | - Apart from other apps, GCP dashboard shows some unique chart options, one of them is "Get as image" 121 | - This option converts the New Relic Query Language (NRQL) query that generates the dashboard into an image – and this is where the vulnerability lies. 122 | - The normal POST request to generate the dashboard image is as follows: 123 | 124 | {"query":{"account_id":1523936,"nrql":"SELECT count(*) FROM IntegrationError FACET dataSourceName SINCE 1 DAY AGO"},"account_id":1523936,"endpoint":"/v2/nrql","title":"Authentication Errors"} 125 | 126 | - 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. 127 | - In NR, all acountids are incremental, so you can pass this request to burp intruder and fuzz it to get data from other users account. 128 | - Infact, in this case, we can modify the NRQL query as well to get more data than above query will give. NRQL queries are public: https://docs.newrelic.com/docs/insights/nrql-new-relic-query-language/nrql-resources/nrql-syntax-components-functions 129 | 130 | **What do we learn?** 131 | - Go through all the functionality of the app, look for unique feature in any section of the app, try to manipulate requests if you see any id or query. 132 | 133 | **Bug 6 :** https://hackerone.com/reports/202501 134 | **Description:** Restricted user is able to delete filter sets of admin users in https://infrastructure.newrelic.com/accounts/{{ACC#}}/settings/filterSets 135 | 136 | - Admin invites -> User2 as a restricted user (as described in above bugs with less/no privileges by putting User2 in a less privilege permission group) 137 | - he admin creates a filter by navigating to Infrastructure > Inventory > Add Filter (https://infrastructure.newrelic.com/accounts/\/inventory) 138 | - User2 joins the team, then clicks on "Infrastructure" tab 139 | - User2 clicks on "Settings", within Infrastructure. 140 | - At this URL, User2 can click on the trash can icon next to the filter that the admin made, and then refresh the page. 141 | The admin's filter is deleted 142 | 143 | **What do we learn?** 144 | - Make something which only admin or high privilege user can do and then try the deleting privileged action done by admin from restricted/low privileged account. 145 | 146 | **Bug 7:** https://hackerone.com/reports/447975 147 | **Description: ** Upgrade menu exposes the mobile application token meant to only be visible to administrators 148 | 149 | 150 | - As an admin user, create a new mobile app (https://rpm.newrelic.com/accounts/1523936/mobile/setup) 151 | - Once you're done setting it up, create a new user with restricted read-only settings for mobile, and log in as that user. 152 | - As the restricted user, attempt to navigate to the settings page (https://rpm.newrelic.com/accounts/1523936/mobile/{MOBILE_ID}/edit) - you will be denied, and you won't be able to view the page with the application token 153 | - Now, navigate to the upgrade page for the same mobile app (https://rpm.newrelic.com/accounts/1523936/mobile/{MOBILE_ID}/upgrade 154 | and you will get the token for the app. 155 | - This token for the app, is similar to the license token of the NR web, so this can be use to authenticate to app. 156 | 157 | **What do we learn?** 158 | - Look at all the requests that went through the burp when you are serving the application as a privieleged user. 159 | - Send the same request as low privielged user to expose funtionality. 160 | 161 | **Bug 8:** https://hackerone.com/reports/479139 162 | **Description**: Bypass of #447975 - view mobile application token though "Application Information" sidebar on Installation page 163 | 164 | - All steps are same as above but this time, token is exposed on app installation page. 165 | - Navigate to the "Deploy" page which follows the following URL structure with low privileged user: 166 | https://rpm.newrelic.com/accounts/1523936/mobile/{MOBILE_ID}/deploy 167 | The mobile application token will be on the right hand side of the page: 168 | 169 | **What do we learn?** 170 | - As told in above bugs, if one endpoint is exposing confidential info, there can be other endpoints also which are leaking the same info. 171 | 172 | - I will just put out comment here from the report which describe the feeling: 173 | 174 | *Total RIPage, dude! You aint been slacking on yer hacking. Our fix was lacking some backing, so we'll get cracking! Otherwise I better start packing.* 175 | 176 | **Bug 9: ** https://hackerone.com/reports/476958 177 | **Description**: IDOR allows accounts to view full name of other accounts based on email through share notes feature 178 | 179 | - This is the same issue as Bug3, but on a different endpoint. 180 | - Admin add new user to the account (https://account.newrelic.com/accounts/1523936/users/new) 181 | - From your admin account, go and create a note and view the note: 182 | https://rpm.newrelic.com/accounts/1523936/notes/6610 183 | 184 | - From here, click on the "Share this note" button: 185 | - Now this section will show full usernames of other users. 186 | 187 | **What do we learn?** 188 | - Look at all the feature which can expose confidential info. 189 | 190 | **Bug 10**: https://hackerone.com/reports/634692 191 | **Description**: Stored XSS Via NRQL chartbuilder JSON view 192 | - In the Chart Builder, we can put NRQL queries to create the chart by querying the info. 193 | - Within the chart builder, perform the following NRQL query: 194 | ``` 195 | SELECT `"> "' Style=position` FROM SyntheticCheck 196 | ``` 197 | 198 | - This was the stored XSS, as all the recent queries are saved and showed to all the users of acount. 199 | 200 | **What do we learn?** 201 | - Try XSS payloads in all input fields. 202 | 203 | **Bug 11: ** https://hackerone.com/reports/255685 204 | **Description:** Restricted User can still integrate with AWS via forced browsing 205 | 206 | - Admin add -> User1 with restricted role(read only access to infrastructure) 207 | - Now, as a restricted User1 if you go to infrastructure integration page(https://infrastructure.newrelic.com/accounts/%7B%7BACC#%7D%7D/integrations), you will see the message that integration is disabled at this time, contact admin. 208 | - But, you can force browse to the setup page (https://infrastructure.newrelic.com/accounts/%7B%7BACC#%7D%7D/integrations/accounts/wizard/1/step/1) and integrate your AWS account. 209 | 210 | 211 | **What do we learn?** 212 | - Look at the requests which high privileged account is doing, repeat same requests with low privileged account(force browsing). 213 | 214 | **Bug 12:** https://hackerone.com/reports/344309 215 | **Description:** Adding a new user discloses their full name in the "Users" section of NR Alerts notification channels page 216 | - Each user of NR can add himself to a notification under the notification channel. 217 | - As an admin, add a new user USER1 to your NR account. 218 | - Navigate to https://alerts.newrelic.com/accounts/ACCOUNT_ID/channels 219 | - Observe that the full name of the user is disclosed in the "Users" section on this page. 220 | - Optionally, you can directly navigate to the user channel you added as well and the full name is not hidden: 221 | https://alerts.newrelic.com/accounts/ACCOUNT_ID/channels/1081322 222 | ^ 1081322 is the User notification channel for the user USER1. 223 | 224 | **What do we learn?** 225 | Here devs have forgotten to conceal the name of new users added to the account via the "channels" endpoint. 226 | 227 | If one endpoint is fixed, look for same info in other endpoints. 228 | 229 | **Bug 13**: https://hackerone.com/reports/344468 230 | 231 | **Description**: User is able to access and create private synthetics locations without upgrading 232 | 233 | - In a normal/trial plan, if a admin goes to Synthetics->Private Location( https://synthetics.newrelic.com/accounts/1523936/private-locations), he is treated with a message to "contact sales". 234 | - But, by force browsing to: https://synthetics.newrelic.com/accounts/1523936/private-locations/new, you can make a private location synthetics. 235 | 236 | **What do we learn?** 237 | - If you can't upgrade your account and see privielege request which you can force browse as non privilege user then try guessing the enndpoint and force browse it. 238 | 239 | **Bug 14**: https://hackerone.com/reports/200576 240 | 241 | **Description**: Logic flaw enables restricted account to access account license key 242 | 243 | - Admin invites -> User1 as a restricted user to join the team 244 | - User1 joins the team, then clicks on "Infrastructure" tab 245 | - User1 clicks on "Start my 30 day free trial", then they are directed to this url: https://infrastructure.newrelic.com/accounts/1523936/install 246 | - At this URL, User2 then clicks on "Windows" platform 247 | License key(License key is applicable to full account) is in plain view on this page. 248 | 249 | **What do we learn?** 250 | 251 | - Follow the same thing from a restricted account which you can follow with a high privilege account and keep an eye on response for confidential info. 252 | 253 | **Bug 15**: https://hackerone.com/reports/320200 254 | **Description**: User with no Synthetics permissions can view synthetic monitor details through /internal_api/ endpoint 255 | 256 | - Check **Bug 2** to know how to get info on /internal_api/ 257 | - Admin adds -> User1 with restricted/no permissions to view synthetics. 258 | - When a user with no permissions try to view synthetics by navigating directly to the Synthetics monitor list (https://synthetics.newrelic.com/accounts/1523936/monitors), he gets an error "Permission required to view monitors" 259 | - However, the restricted user can bypass this completely by sending this GET request to the internal API at this endpoint `/internal_api/1/accounts//conditions/load_synthetics_monitors` 260 | 261 | **What do we learn?** 262 | - Once you get a internal_api or some api endpoint , try your normal reuests through that internal_api endpoint. 263 | 264 | Bug 16: https://hackerone.com/reports/520518 265 | 266 | **Description: **Full name of other accounts exposed through NR API Explorer 267 | - Admin adds -> User1 268 | - Now using the new api(https://api.newrelic.com/v2/users.json) endpoint, full names of all the users are getting exposed. 269 | 270 | **What do we learn?** 271 | - Monitor new endpoints, or keep an eye on program updates for new api info. 272 | 273 | **Bug 17**: https://hackerone.com/reports/347665 274 | **Description**: Permissions leaks the full name of other NR accounts 275 | 276 | - This is exactly same as **Bug 3** above, and due to the incorrect fix. 277 | - Here the full name will appear in the add user in the group permission list when that particular use has logged in anytime in the past on the NR platform. 278 | 279 | **What do we learn?** 280 | - Bussiness logic :) 281 | 282 | **Bug 18**: https://hackerone.com/reports/334143 283 | 284 | **Descriptions**: Restricted User can add/modify alert conditions on monitors without any synthetics privileges 285 | 286 | - Login as an admin and navigate to Synthetics. Make sure that Synthetics privileges are turned ON and the Restricted User is not given any privileges. 287 | - Create a new monitor 288 | - Navigate to the alert settings for the monitor (https://synthetics.newrelic.com/accounts/1523936/monitors/99657e19-ace3-483d-a5d4-d199f09e177b/conditions) 289 | - Click on the "Add alert condition" button 290 | Choose any alert condition and turn intercept on in Burp Suite before you click "Save". 291 | There will be a POST request, now send this POST request with a restricted user cookies and CSRF token. 292 | - You will see 200 Ok with an alert created. you can check this by logging back to admin account and check on the UI. 293 | 294 | **What do we learn?** 295 | - That's how IDOR can be found, by doing the action from a restriced/low privileged user. 296 | 297 | **Bug 19**: https://hackerone.com/reports/332381 298 | 299 | **Description**: Internal API endpoint discloses full account name of email address associated with unconfirmed user 300 | 301 | - Admin add new user -> User1 (https://account.newrelic.com/accounts/1523936/users/new), notice that in UI, full names are masked. 302 | - But, using /internal_api/ (https://alerts.newrelic.com/internal_api/1/accounts/%7BYOURACCOUNTNUMBER%7D/users/), it is exposing all names of users. 303 | 304 | **What do we learn?** 305 | - User internal apis/api endpoints which you find during crawling or js analysis to find confidential info. 306 | 307 | 308 | **Bug 20**: https://hackerone.com/reports/349291 309 | **Description**: IDOR via internal_api "users" endpoint 310 | 311 | - Again using /internal_api/( https://alerts.newrelic.com/internal_api/1/accounts/1523936/users/517408) endpoint, full name is getting exposed 312 | 313 | **What do we learn?** 314 | - Use internal apis/api endpoints which you find during crawling or js analysis to find confidential info. 315 | 316 | **Bug 21: ** https://hackerone.com/reports/479135\ 317 | 318 | **Description**: GET request to accounts.json on support site leaks the root account license key and the browser license key to a restricted user 319 | 320 | - Admin User creates -> User1 (restricted User) 321 | - Login as User1 and go to https://support.newrelic.com/ 322 | - When User1 clicks on create ticket(/customer/accounts.json), license key is exposed. 323 | 324 | **What do we learn?** 325 | Look at each endpoint in burp, and check their response. 326 | 327 | **Bug 22: ** https://hackerone.com/reports/459443 328 | 329 | **Description**: Modify the filter settings for any NR Insights dashboard through internal_api endpoint 330 | 331 | - An IDOR exists that allows to change the filter settings of any account on New Relic through the PUT request to /internal_api/1/accounts/ACCOUNTID/dashboards/DASHBOARDNUMBER/filter 332 | - dashboard_id within the request body is not being validated in the request body, so it can be changed to victim account. 333 | 334 | 335 | **What do we learn?** 336 | Simple IDOR where we manipulate the id to the victime account. 337 | 338 | **Bug 23 ** https://hackerone.com/reports/320689 339 | 340 | **Description** Restricted user can view synthetics monitors and user permissions through .json endpoint at /permissions/securablemetadata/{GROUP ID} 341 | 342 | - When a restricted user with no permissions to view synthetics monitors tries to navigate to the permissions settings within Synthetics (https://synthetics.newrelic.com/accounts/1523936/permissions). he does not see anything. 343 | - But, there is a request being made which can be seen using proxy to endpoint: https://synthetics.newrelic.com/accounts/accounid/permissions/securablemetadata/groupid.json 344 | - This was exposing all the monitor info. 345 | 346 | **What do we learn?** 347 | - Check all the requests that are happening in background. sometimes you will see request to api/other endpoint which is to query if the user has permission or not but in response it leaks info. 348 | 349 | 350 | **Bug 24:** https://hackerone.com/reports/386556 351 | 352 | **Description** Internal API exposes Synthetics monitor details to a restricted user without view monitor permissions 353 | 354 | - Admin -> User 1(restricted with no permission to synthetics) 355 | - From admin create a Synthetics monitor to fail each time, example: create a monitor with a URL that checks for the ping response from a website that doesn't exist, such as "lakfnas8df8hasfd.com". 356 | - Add an alert monitor that checks for a failure of this monitor. 357 | - once you have this setup, you're going to get a lot of failures in NR Alerts, which will appear in the Events > Violations section. 358 | - Now as a restricted user, if you go this Events > Violations section, you will not see much of the info about monitor. You can see the name of the monitor, and that the monitor had an alert that failed, but you can't tell why or what asset is being monitored. 359 | - However - there is an internal API JSON endpoint that leaks all this hidden info to the restricted user: 360 | 361 | https://alerts.newrelic.com/internal_api/1/accounts/1523936/monitor_failures/MonitorID?limit=1&reverse=true&start_timestamp=1 362 | 363 | - You can get the monitorID as restricted user by just hovering over the monitor on the incident section. 364 | 365 | **What do we learn?** 366 | Use internal apis/api endpoints which you find during crawling or js analysis to find confidential info. 367 | 368 | **Bug 25: ** https://hackerone.com/reports/397483 369 | 370 | **Description** Restricted user can update integration provider account name via integrations API 371 | 372 | - NR Infra allows you to create a GCP integration and set a custom name. 373 | - By default, the restricted user account can't change anything associated associated with this type of infra integration 374 | - But there is a missing check on changing the name of the integration through the integrations API (https://integrations-api.service.newrelic.com/api/v1/accounts/AcountID/provider_accounts/GCPIntegrationID) 375 | - From the restricted user account, send the PUT request to above endpoint and change the name to something else via the {"name":"CHANGED"} parameter within the request. 376 | 377 | **What do we learn?** 378 | - Try to use the api to do some privilege tasks from the low level account. 379 | 380 | **Bug 26: ** https://hackerone.com/reports/462321 381 | 382 | **Description**: Ability to view monitor names of other NR accounts through internal API (v3) via "monitor_id" parameter. 383 | 384 | - In NR, we can see alert policy on a synthetic monitor, to get the alerts on synthetic moitor failure or some condition. 385 | - Create a synthetic monitor from victim's id and note down its monitor id. 386 | - Now, login as attacker, and create a new alery policy. 387 | - Create a condition "Synthetics" and name anything. 388 | - Capture the save request and change the current monitor id to the one which we have taken from victim. 389 | - Send the request through and you'll see that the monitor name has been changed to reflect the monitor belonging to the other account, indicating the IDOR was successful 390 | 391 | 392 | **What do we learn?** 393 | Change the ID in request to victim account to find IDORs. 394 | 395 | **Bug 27: ** https://hackerone.com/reports/380413 396 | 397 | **Description**: Restricted user can bypass permissions restriction to create NR Alert policies 398 | 399 | - When a restricted user navigates to NR Alerts, they don't have the option to create a new alert policy. 400 | - This can be bypassed by sending a custom POST request to infrastructure-data.service.newrelic.com(/accounts/{ACCOUNT_ID}/policies) endpoint 401 | 402 | **What do we learn?** 403 | Have a look at other subdomain requests also, sometimes depending on the funtionality, different endpoints of different subdomains get called. 404 | 405 | **Bug 28: ** https://hackerone.com/reports/388743 406 | 407 | **Description**: Data app permissions setting does not fully prevent other users from modifying/changing data related to your data app 408 | 409 | - Create "data app" as the admin(https://insights.newrelic.com/apps/accounts/account ID) 410 | - Make permissions setting as "Visible to others in my account" and fill any details as title. 411 | - Now, from the "restricted" user who shouldn't have the ability to edit this data app, login to New Relic and head back to the apps section (https://insights.newrelic.com/apps/accounts/account ID) 412 | - Now, In order to set this up correctly, go within Burp Suite Professional, then go to Proxy > Options > scroll down to "Match and Replace" and click on "Add" and fill 413 | 414 | Match: "editable":false 415 | Replace: "editable":true 416 | 417 | - Now, when you visit a data app that is set to "visible to others on my account" made by another user, you get the nice edit options in the upper right hand corner and api is able to accept our change 418 | 419 | **What do we learn?** 420 | Always check response of all requests for keywords like "editable", acceptable, true, false etc. 421 | 422 | 423 | **Bug 29:**: https://hackerone.com/reports/501672 424 | 425 | **Descriptions:** Restricted user can view all account invoices, payment method details, PII of account owner through zoura_api endpoints 426 | 427 | - NR switched to using Zoura (https://www.zuora.com/) to handle your New Relic customer subscriptions. 428 | - A restricted user without administrative privileges cannot view and data associated with the billing page (https://rpm.newrelic.com/accounts/1523936/payments) and the link returns a 403. 429 | - The Zoura API endpoints, however, are available for the restricted user to access, and leads to the exposure of the following sensitive information: 430 | 431 | Last four digits, cardholder name, card type, and expiration date of credit card on file of the account owner or billing contact 432 | https://self-serve.service.newrelic.com/accounts/ACCOUNT_ID/zuora_api/payment_methods 433 | 434 | All invoice amounts processed after November 2018 435 | https://self-serve.service.newrelic.com/accounts/ACCOUNT_ID/zuora_api/invoices 436 | 437 | An account summary showing non-sensitive information about the default payment method and whether the account has future subscriptions 438 | https://self-serve.service.newrelic.com/accounts/ACCOUNT_ID/zuora_api/account_summary 439 | 440 | **What do we learn?** 441 | Look for changes in the app, keep monitoring the js file for endpoint changes. In this case, on seeing the requests to the zuora endpoint during the payment, anyone can get access to confidential info. 442 | 443 | 444 | **Bug 30:**: https://hackerone.com/reports/268541 445 | 446 | **Descriptions:** Individual account permissions are not properly managed and inherited on sub accounts. 447 | 448 | - Since a user management overhaul happened few permissions issues came in the app. 449 | - IN NR, When you have a sub account on your account, you get this message: 450 | `Anybody with permission to access this account will also have the same permissions on these sub-accounts: {{name of the sub account}}` 451 | 452 | - But this seems to be broken. 453 | - Now, if Admin adds a User1 as admin privileges on main account as well as adming privileges on sub account. 454 | - But lets say user1 leave the org and in that case admin removes the User1 from main account but User1 will still remain admin of sub account. 455 | 456 | This is breaking the above statement where a user of sub account inherits the permission of main account, but with the current scenario, a sub account user priviliges always overwrites the main account pivileges. 457 | 458 | **What do we learn?** 459 | - This is purely a bussiness logic error which can be find out by reading docs related to privielges. 460 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # BugForaging 2 | This repo includes my analysis of some public reports. 3 | --------------------------------------------------------------------------------