![]() 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. Any user account in the OpenDrive system could have easily been hijacked and had their private files compromised with a simple script: url = "" It’s hard to even consider this a vulnerability rather than a fundamental design flaw. "TempStreamingLink": "https:///api/download/file.json/NjlfNzU3MTg3MF8?inline=1", "TempStreamingLink": "https:///api/download/file.json/NjlfNzU3MTg2OV8?inline=1", "DirectFolderLink": "https://od.lk/fl/NjlfMTA2NzgyNF8", Here’s another example request used to fetch folder contents: GET HTTP/1.1 "SupportUrl": "http://",Īgain, this meant that all aspects of this application were controlled by a highly predictable, sequential “session” value. Almost unsurprisingly, all API endpoints used the same flawed session_id generation scheme from above. While proxying the requests on my device, I logged in and starting browsing files, moving folders, and accessing other details of my account. The usage of this particular API domain within the web client was limited, so I installed the OpenDrive Android app. 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. I’ve come across some serious design flaws in the past, but this one seemed to be a top contender. 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. milliseconds from a server-side function like PHP’s microtime. 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. 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. Note the previously-valid session_id value included in the query string above. 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: GET ***REMOVED***?session_id=1517592191112474005&inline=0&preview=1 HTTP/1.1 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: After uploading a few test files, I took a look at the markup and API requests. ![]() I signed up for a trial account and decided to test drive the web client. According to their website, they have some big name customers, including T-Mobile,, and REMAX. In addition to traditional cloud storage, they also offer backup and content management solutions with software clients available for most desktop and mobile platforms. OpenDrive is one such company - not to be confused with the OpenDRIVE format specification - offering unlimited options for personal, business, and enterprise customers. While recently comparing cloud storage solutions, I was surprised to learn there are still companies offering unlimited storage plans.
0 Comments
Leave a Reply. |