Sched.com is a popular event planning and management web-site. We discovered that the mobile version leaked API keys for all events, leading to the possibility of accessing password protected events, modifying any events and accessing all the stored data about speakers and registered users.
It all started when we decided to access a password protected event in Sched.com. Accessing the event page through a mobile phone browser would throw something that seemed a lot like a overlay pop-up on top, which, given the correct password, seemingly disappear to reveal the full schedule below.
From the looks of it, it did not seem to post the password to the server and then load the schedule after checking it was correct. This made us wonder if the page had actually pre-fetched the schedule, perhaps encrypted, and did only unlock it in the browser without verifying the credentials against the server. This seemed to not be the approach on a desktop browser, which clearly made a separate request to fetch the event details after submitting the password.
Our surprise came when we curl‘ed the URL https://<our-event>.sched.com/mobile (the /mobile path being used from mobile phone browsers). The returned (unauthenticated) HTML page included an embedded <script> which declared some interesting values, one of them being:
var apikey = <32-char hex encoded key>
The rest was very straightforward: the Sched developer API provides API access to Sched events, with some endpoints requiring an api_key parameter. Could it be the same API key that was hard-coded on the web page? Precisely: using the 32-char key that was included allowed us to list every session in our private event (https://sched.com/api#session-list), along with the attached information to each like the location of the sessions, which we wanted to protect.
This was bad, but the most worrying came when checking the api/user/get endpoint. We had access to every user registered in our private event, including personal data added by the user like the email address. Some more checks revealed that we not only had read access with that API key, but also full access to all the write-endpoints.
Finally, we also discovered that the URL of our event appeared after searching the Sched.com event directory. This directory was not only able to find our event, but also shows a long list of upcoming events. We checked the /mobile endpoint for a 3rd party event and it also included the apikey. This means that, with very little difficulty, anyone could have accessed all the private data from Sched.com registered users for each event in the list, as well as causing havoc to conference organizers by, for example, changing the time, date and location for each of the sessions.
We initiated a responsible disclosure on the 12th of October 2018, contacting Sched.com support. The Sched team reacted quickly and fixed the issue a few days later, resetting all API keys as well. They were very open keeping us informed of the progress of their internal investigation to identify whether the vulnerability had been abused.
The final good news was that, although the issue had gone unnoticed since 2014, they concluded that no sign of abuse existed in the last 30 days prior to the disclosure, so it is probable that the issue was not actively being exploited.