Compromising OpenDrive’s Cloud Storage Accounts – Or How Not to Design Session Management

While recently comparing cloud storage solutions, I was surprised to learn there are still companies offering unlimited storage plans. OpenDrive is one such company — not to be confused with the OpenDRIVE format specification — offering unlimited options for personal, business, and enterprise customers.

In addition to traditional cloud storage, they also offer backup and content management solutions with software clients available for most desktop and mobile platforms. According to their website, they have some big name customers, including T-Mobile,, and REMAX.


I signed up for a trial account and decided to test drive the web client. After uploading a few test files, I took a look at the markup and API requests. I quickly noticed the UI was mostly powered by WordPress (like OpenDrive’s main site) with some apparent customizations for styling, login, and API consumption:

I also noticed some calls to two API domains in my HTTP proxy: one on the same www subdomain authenticated with cookies, the other on a web subdomain authenticated with a separate session ID:

Note the previously-valid session_id value included in the query string above.

The value is suspiciously close to a Unix Timestamp, meaning it would have likely been derived from the exact time of the user’s initial login request — not good! In fact, the first ten digits of the value convert exactly to that: the date/time of my account first logged in.

It seemed likely that the remaining nine digits from the above session_id were simply more precise values of the same login time, e.g. milliseconds from a server-side function like PHP’s microtime. I attempted to prove this by issuing numerous login requests in succession to compare the generated session_id values — as predicted, they were all sequential. I’ve come across some serious design flaws in the past, but this one seemed to be a top contender.

Next, I decided to see where else this session generation pattern was used and how it might impact the security landscape of OpenDrive’s products as a whole. The usage of this particular API domain within the web client was limited, so I installed the OpenDrive Android app.

While proxying the requests on my device, I logged in and starting browsing files, moving folders, and accessing other details of my account. Almost unsurprisingly, all API endpoints used the same flawed session_id generation scheme from above. Here’s an example request:

And the corresponding JSON response:

Again, this meant that all aspects of this application were controlled by a highly predictable, sequential “session” value. Here’s another example request used to fetch folder contents:

And the results:

It’s hard to even consider this a vulnerability rather than a fundamental design flaw. Any user account in the OpenDrive system could have easily been hijacked and had their private files compromised with a simple script:

Exploit Scenarios

The risks of this session issue were obvious, but two attack scenarios particularly concerned me: first, an attacker with even modest resources could have easily scanned for random valid user sessions in the system; second, targeted attacks of individual users would have only required knowledge of the user’s approximate login time — dramatically narrowing an attacker’s session search range.

These risks were further exacerbated:

  • Sessions never seemed to expire — my February sessions were still active in the system by March
  • Every login produces a new session, meaning any given user was likely to have multiple session entries
  • Vulnerable session generation was not limited to the Android app/client; sessions were generated for all clients (including web and desktop). This means virtually every OpenDrive user was affected.

It’s unclear just how many sessions would have existed in the system prior to OpenDrive’s remediation, but it’s obvious the issue posed a serious threat.


I got in touch with OpenDrive to report the vulnerability through their customer support channel. The experience was fairly smooth at first, but later got confusing and responses trailed off:

2017-02-05 Initial report to OpenDrive Support
2017-02-06 Response received that issue was forwarded to devs
2017-02-13 I follow up – response received that it’s still in progress
2017-02-22 I follow up – response received that OpenDrive will get back shortly. I never heard back.
2017-03-01 I follow up – no response
2017-03-08 I follow up again – response received that there’s no update, “but we’ve heard that it could have been fixed already. Can you confirm, do you still see that it is not fixed?”
2017-03-09 I follow up for clarification on previous response. Support “heard” it was fixed???
2017-03-09 OpenDrive confirms a fix was released

While OpenDrive did eventually release a patch after some prodding, communication was certainly lacking. They also seemed oddly unalarmed with the issue, ostensibly treating it as a low-priority bug rather than a critical vulnerability in their core product.

With that said, their patch was effective and I confirmed previously affected sessions discussed above were invalidated. OpenDrive later sent me a $50 bounty in appreciation of the report.

Share this: Facebooktwittergoogle_pluslinkedin