Customer Service Data Vulnerability, Intercom [Fixed]

On Sept 18, 2018 at 22:42, Drop Mobility was notified of a potential vulnerability that could have revealed customer metadata on a partner platform, Intercom. This issue was fixed 36 minutes after the initial notification, and at this time, no unauthorized access has been recorded. No financial or other system data, or any of Drop Mobility's own servers were compromised.

Customer Service Data Vulnerability, Intercom [Fixed]

  • Dropbike was using an unrestricted API token in the app, this is a string of text that allows our mobile apps to communicate with our customer service platform, Intercom

  • A UBC engineering student noticed this token could be found by breaking open the application and looking through the source code

  • He was able to use the token and Intercom's API documentation to extract user records from Intercom, these include the number of users that Dropbike had registered with our customer service platform, and basic user metadata

  • This metadata includes full names, emails, phone numbers, and sometimes, the last logged in location (one coordinate, not history, used to identify regions)

  • Dropbike's main database systems and APIs were not compromised, at no point did anybody have access to any of our internal systems, which are behind strong security

  • Dropbike has investigated the logs on this API key and there is no additional record of any malicious actor retrieving or storing data

  • No payment, trip, or other data was compromised, and no customer metadata was accessed as far as we can tell

The Resolution

  • The unrestricted API token was revoked and nobody can use any publicly visible token to access our customer support service, Intercom, any longer

  • We have generated a new, far more restrictive API token that is included in the app. If somebody were to gain access to this token by breaking open the app, they would not be able to read user records.

  • These changes were implemented within 36 minutes of credible notice

Timeline

  • A UBC engineering student notified Dropbike via a customer support channel that he had something of potential interest to share with us (Sept 17, 18:20)

  • A customer service representative responded with our generic message, as we get these types of "notices" often, and they are usually not credible. This customer service representative linked a form that someone can submit any technical information about an issue they may have found. (Sept 18, 18:17)

  • This UBC engineering student had some issues using our form because his email address is non-whitelisted (uncommon email domain), but this issue was later rectified (Sept 18, 18:37)

  • This UBC engineering student then submitted credible documentation of issues he found (Sept 18, 22:42)

  • After verifying that the issue does exist, our engineering team was notified and the issue was first plugged (access restricted) then fixed (36 minutes) (Sept 18, 23:18)

Qiming Weng