In November 2015 I noticed that Microsoft Office 365’s calendar sharing option used an HTTP permalink.
I reported this to Microsoft, and they have since fixed the issue. The rest of this article was written before the issue had been fully resolved.
what is the issue?
Before December 2016, the “share calendar” link Office 365 was giving to users to access their calendars is a bog-standard HTTP GET request permalink to your calendar, which, depending on your settings, can be used by anyone who has the link, to access:
- all of your calendar details
- some of your calendar details
- just your availability
- or nothing
If, like me, you use your calendar for work, to organise and attend video-conferences, online meetings, or discuss anything sensitive, then you will probably at some point have URLs, usernames, passwords, conference IDs, VOIP call numbers and passwords, within the details of your calendar appointments.
If your calendar sharing option is set to “Full Details”, then anyone with the generated URL can get full read-only access to your entire calendar, and also access to all of these details.
The above is all expected behaviour, because you’re supposed to keep the URL secret – the problem is that the generated URL is not prefixed with HTTPS…. (at least it didn’t used to be.)
So all the standard MITM attack stuff applies – anyone with access to see any raw otherwise unprotected network traffic between your browser and the Microsoft Office 365 server will be able to see the content of this GET request.
Microsoft have even done 99% of the work required to fix this issue – when the link is accessed, the following happens:
So the request is immediately upgraded to HTTPS using a 301 Moved Permanently response, with exactly the same URL content.
But the problem is that the GET request has already been sent over HTTP, which contains the secret permalink key (which I have redacted) that you need in order to access the data. Even though an attacker wouldn’t be able to see the second request being made or the content being downloaded over HTTPS, they could just follow the HTTPS redirect themselves to see the content, and then repeat that request when they want to see your latest calendar content.
There is no tracking available through Office 365 to see what devices are using this link, how often, where from, or anything of that nature. It also doesn’t give you the option of resetting the link in case you think someone else might have gotten access to it.
At some point between November 2015 and April 2016, Microsoft have changed the default links being generated, so they default to HTTPS – but this still leaves any existing links vulnerable, and Microsoft haven’t informed users of the problem (to my knowledge).
what can i do?
If the link in your calendar sharing settings begins with HTTP://, then do this:
- Disable calendar sharing completely
- Save the changes
- Re-load the options window
- Re-enable calendar sharing
Your link will now be different, and the old link will now be dead.
so what did Microsoft do?
They changed all new links to be HTTPS instead of HTTP, but they didn’t change any existing links, or provide a nice easy button to press to do this.
what does the content of an ics file look like anyway?
ICS files just contains structured plaintext. So your usernames, passwords, phone numbers, email addresses, dates, times and locations are all sent in a very easy to read format. Any typical off-the-shelf network traffic scanning tool will be able to easily pick out your sensitive information from the data for later abuse.
stampycode 